bugGNU Octave - Bugs: bug #48873, Matlab incompatibilities in plot...


bug #48873: Matlab incompatibilities in plot routines revealed through dump_plot_demos

Submitter:  Rik <rik5>
Submitted:  Tue 23 Aug 2016 05:23:09 PM UTC
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 16 Jan 2019 12:47:51 AM UTC, comment #40: 

This bug is ancient.  There is a new bug covering Matlab incompatibilities ahead of the 5.0 release at bug #55481.

Closing this report.

Rik <rik5>
Group administrator
Tue 20 Sep 2016 04:19:21 PM UTC, comment #39: 

Image viewers also has option "smooth images" or some such.


Dmitri A. Sergatskov <dasergatskov>
Tue 20 Sep 2016 04:06:29 PM UTC, comment #38: 

I can manage pdf output on my side by changing the settings of my viewer (acroread, gv, or okular) to disable graphics smoothing.  It is annoying that a format that is supposed to be portable (Portable Document Format = PDF) is in fact not portable and depends on the user's settings.  In this case, a rasterized graphics format like png is much more portable and looks the same in every image viewer.

Rik <rik5>
Group administrator
Tue 20 Sep 2016 09:00:41 AM UTC, comment #37: 

@Rik: Note that the actual gl2ps PDF output (revealed through -dpdflatex print format) doesn't have those antialising lines (at least using evince viewer). Unfortunately, the PDF output also has it's own bugs, e.g. when it comes to print lit surfaces: I tried  to print "demo light 1" and light spots come to be really ugly.

Pantxo Diribarne <pantxo>
Group Member
Tue 20 Sep 2016 05:30:11 AM UTC, comment #36: 

I pushed your patch to disable anti-aliasing in rasterize outputs.  It helps a lot.

Rik <rik5>
Group administrator
Mon 19 Sep 2016 10:39:19 PM UTC, comment #35: 

@Rik: I attched a new patch a per your comments.
Unfortunately for ps, pdf and other vector outputs this is not as easy: antialiasing is the work of the rasterizing engine of your viewer/printer.
There seems to be an "/interpolate" directive in postscript language that is off by default, and that gl2ps doesn't change. So gl2ps is not guilty here.

(file #38560)

Pantxo Diribarne <pantxo>
Group Member
Mon 19 Sep 2016 09:07:16 PM UTC, comment #34: 

After playing around with

graphics_toolkit fltk
demo area 2
print -GraphicsAlphaBits=1 tst1.png
print -GraphicsAlphaBits=2 tst2.png
print -GraphicsAlphaBits=4 tst4.png

it seems like a value of 1 is the closest match to Matlab.

I think it would also be a good idea to turn off aliasing for the directly produced formats like PostScript and PDF.  This would prevent ugly looking output where the triangulation from OpenGL is faintly visible.

Rik <rik5>
Group administrator
Mon 19 Sep 2016 08:54:40 PM UTC, comment #33: 

@Panxto: I think you're right that we probably want to disable Graphics Anti-aliasing.  However, could you take a look at modifying the existing configuration, rather than hardcoding the values?  There is currently code that allows the user themselves to set these values as options when they print.  From 'help print'

          Octave is able to produce output for various printers,
          bitmaps, and vector formats by using Ghostscript.  For bitmap
          and printer output anti-aliasing is applied using
          Ghostscript's TextAlphaBits and GraphicsAlphaBits options.
          The default number of bits for each is 4.  Allowed values for
          N are 1, 2, or 4.

And if I grep for antialias in scripts/plot/util/private I find

__ghostscript__.m:36:  opts.antialiasing = false;
__ghostscript__.m:37:  opts.antialiasing_textalphabits = 4;,
__ghostscript__.m:38:  opts.antialiasing_graphicsalphabits = 4;
__ghostscript__.m:75:  if (opts.antialiasing && isempty (strfind (opts.device, "write")))
__ghostscript__.m:78:                       gs_opts, fix (opts.antialiasing_textalphabits),
__ghostscript__.m:79:                       fix (opts.antialiasing_graphicsalphabits));
__print_parse_opts__.m:51:  arg_st.ghostscript.antialiasing = false;
__print_parse_opts__.m:52:  arg_st.ghostscript.antialiasing_textalphabits = 4;
__print_parse_opts__.m:53:  arg_st.ghostscript.antialiasing_graphicsalphabits = 4;
__print_parse_opts__.m:126:          arg_st.ghostscript.antialiasing_textalphabits = str2num (arg(end));
__print_parse_opts__.m:133:          arg_st.ghostscript.antialiasing_graphicsalphabits = str2num (arg(end));
__print_parse_opts__.m:310:    arg_st.ghostscript.antialiasing = true;
__print_parse_opts__.m:322:    arg_st.ghostscript.antialiasing = false;

Probably, all that needs to be done is to change the documentation and the initial values of

antialiasing_graphicsalphabits = 4


antialiasing_graphicsalphabits = 1

I also see there is a spare ',' at the end of _gostscript_.m:37 that should be removed.

Rik <rik5>
Group administrator
Sun 18 Sep 2016 06:17:08 PM UTC, comment #32: 

About anti-aliasing in png output:
If I zoom in firefox I am under the impression that Matlab's png has crisp edges (see e.g. area #2) which could mean that they disable anti-aliasing when rasterizing to png.

Ghostscript has two options to do this separately for text and other graphics: respectively "-dTextAlphaBits=n" and "-dGraphicsAlphaBits=n". Chossing n=4 for the former and n=1 for the latter eliminates spurious lines inside patches from the png outputwithout degrading the text appearance. I attached a patch for testing.

(file #38543)

Pantxo Diribarne <pantxo>
Group Member
Mon 12 Sep 2016 08:59:59 PM UTC, comment #31: 

The output by running through svg, rather than eps, is very nice.  Given the magnitude of the change, this should happen after the 4.2 release.

Rik <rik5>
Group administrator
Sun 11 Sep 2016 08:49:39 PM UTC, comment #30: 

Actually I have a printinkscape.m in my path that lets me write "Temp*é*rature" as I like :-).

I also though about this. The advantages are:

  • native utf8 support
  • basic support for super/subscript (at least sufficient for the tex interpreter) using a subset of html.
  • eventually have latex support through the toolchain webkit+mathjax to svg for printout, or to pixels for on screen rendering.

Now having the monolithic inkscape as a dependency is not realistic. I don't know if librsvg (which means gtk??) is a good solution either. Maybe qt's support for svg tiny is enough?

Pantxo Diribarne <pantxo>
Group Member
Sun 11 Sep 2016 06:42:23 PM UTC, comment #29: 

Apparently also inkscape has a command-line mode.
here is proof of principle:

set(0, 'DefaultAxesFontname', 'NotoSans')
set(0, 'DefaultTextFontname', 'NotoSans')
set(0, 'DefaultAxesFontsize', 14)
set(0, 'DefaultTextFontsize', 14)
set(0, 'DefaultLineLinewidth', 1)
set(0, 'DefaultAxesLinewidth', 1)
grid on
ylabel("距離 (Ångström)")
xlabel("時間 (seconds)")
print t1.svg

and then in terminal

inkscape -z -A t1.pdf t1.svg

The output is attached. I think this is the best-looking
plot output I have ever been able to produce with gl-based backend.


(file #38477, file #38478)

Dmitri A. Sergatskov <dasergatskov>
Sun 11 Sep 2016 06:22:31 PM UTC, comment #28: 

One option is to change printing toolchain to:
gl --> svg --> other

One of the advantages is that we do not have fonts limitations imposed by gl-->eps conversion and should be able to use
 any utf fonts. An obvious drawback is yet another tool dependancy for svg conversion. The only tool I know is python-svgcairo.


Dmitri A. Sergatskov <dasergatskov>
Sun 11 Sep 2016 09:51:03 AM UTC, comment #27: 

@Rik: I am under the impression that blending is not fully/consistently implemented. One of the examples in gl2ps sources shows that only svg has blending support (based on the alpha channel, hence it works from Octave without even enabling blending).

Furthermore there is a warning in gl2ps doc

... To enable blending for selected primitives only, you should use gl2psEnable(GL2PS_BLEND) and gl2psDisable(GL2PS_BLEND) pairs around the OpenGL calls that need blending. (Warning: this might change in future releases.)

I'll ask for clarification on the gl2ps list and post back here.
The attached patch implements Rik's idea but to no avail as no terminal has real support for blending.

(file #38476)

Pantxo Diribarne <pantxo>
Group Member
Fri 09 Sep 2016 07:29:57 PM UTC, comment #26: 

I can confirm that svg output works for transparency, although it has other issues when the linewidth is < 1.

This seems to be a gl2ps issue.  In gl2ps-print.cc we start out gl2psBeginPage by including the option GL2PS_NO_BLENDING.  That alone disables the alpha channel.  However, I commented that out and re-compiled and it still doesn't work.

I think the problem may be that we call

  glEnable (GL_BLEND);

in the code when displaying on-screen.  But for printing I think we need to use the gl2ps version and call

  gl2psEnable (GL2PS_BLEND);

We already do this for other GL/GL2PS options such as GL_LINE_STIPPLE.  There appear to be only 3 places in gl-render.cc where the value for GL_BLEND is changed.  But even so, this will take a bit of work to get it right.  Pantxo can probably tell me whether this idea makes sense or is only a false path.

Rik <rik5>
Group administrator
Fri 09 Sep 2016 05:57:18 PM UTC, comment #25: 

If I set

set(0, 'defaultLineLineWidth', 1);
set(0, 'defaultAxesLineWidth', 1);

then svg looks good, but eps still has the same problem.
(t2.svg, t2.eps attached)

(file #38464, file #38465)

Dmitri A. Sergatskov <dasergatskov>
Fri 09 Sep 2016 05:50:49 PM UTC, comment #24: 

Also attached is svg file that also looks wrong but differently wrong.


(file #38463)

Dmitri A. Sergatskov <dasergatskov>
Fri 09 Sep 2016 05:42:46 PM UTC, comment #23: 

Yes PS has a problem.
Actually gl2ps write eps file, so I saved -depsc2.
(ps is made from eps by piping through gs.)
Attached is a screenshot of a plot and the postscript.


file #38462)

Dmitri A. Sergatskov <dasergatskov>
Fri 09 Sep 2016 04:27:09 PM UTC, comment #22: 

@Dmitri: The fact that on-screen works, but the print-out is wrong, suggests maybe gl2ps or maybe the transformation from postscript to png.

Does the alpha transparency work if you go only to PostScript?

graphics_toolkit qt
plot (1:10)
grid on
print -dpsc2 tst.ps

If tst.ps is okay, then gl2ps is working and it is the second part from ps to png that is the problem.  But if tst.ps is solid, then it is gl2ps that is at fault.

Rik <rik5>
Group administrator
Fri 09 Sep 2016 06:50:00 AM UTC, comment #21: 

I ran

scatter (1:100, 1:100, 1:100)

under Matlab, printed it to a PNG file and uploaded the resulting scatter.png as requested on the help mailing list. Matlab version is (R2012a).

Martin Kunz <mkunz>
Fri 09 Sep 2016 04:39:31 AM UTC, comment #20: 


What you are suggesting changes on-screen appearance which is fine already. The problem is with the png/pdf file. You can see in in dump_plot_demos:

(scroll to grid demos).

It is also quite visible in 3-d plots. There (in gl plots) the
front y axis (e.g. ezsurf01, z=0, x=-3 line) is noticeably lighter then the other axes or grid lines. Gnuplot gets this part
right (though it has some other problems).


Dmitri A. Sergatskov <dasergatskov>
Fri 09 Sep 2016 03:31:40 AM UTC, comment #19: 

For the OpenGL renderers there seems to be a difference between what different hardware configurations produce.  For some people, the alpha channel works perfectly and the grid is partially translucent.  I find that the value of GridAlpha has to be very small before I notice anything.

Try experimenting with GridAlpha

plot (1:10, "b", "linewidth", 4)
grid on
set (gca, "GridAlpha", .005)

Rik <rik5>
Group administrator
Fri 09 Sep 2016 02:30:08 AM UTC, comment #18: 

May be there is a dedicated bug report, but i could not find it:

the grid lines are all too heavy with all toolkits except gnuplot/cairo (pngcairo, pdfcairo, epscairo).

A simple example is

plot (1:10)
grid on
print g1.png


Dmitri A. Sergatskov <dasergatskov>
Thu 08 Sep 2016 06:36:29 PM UTC, comment #17: 

another by ml2016b, max screen size

Philip Nienhuis <philipnienhuis>
Group Member
Thu 08 Sep 2016 06:35:01 PM UTC, comment #16: 

I pushed a cset for scatter here (http://hg.savannah.gnu.org/hgweb/octave/rev/809989ceb5d3).

plotmatrix() is still visually different, but the gap between Octave and Matlab is now pretty narrow.

Rik <rik5>
Group administrator
Thu 08 Sep 2016 04:21:02 PM UTC, comment #15: 

@Rik: attached a copy of the output of:

scatter (1:100, 1:100, 1:100)

Guillaume <gyom>
Tue 30 Aug 2016 03:44:15 PM UTC, comment #14: 

Thanks, as long as it is an upstream bug I don't think we need to worry about it right now.  That pretty much leaves scatter() as the last graphics function that needs a big overhaul.  That will be a lot of work so I don't see needing to do that before the 4.2 release.

Rik <rik5>
Group administrator
Tue 30 Aug 2016 08:36:26 AM UTC, comment #13: 

@Rik: Yes, this is a regression in gl2ps 1.3.9 (in http://josoansi.de/octave_plot_compare , Andy obviously used 1.3.8, and the lines are correctly hidden). I'll try to find the time to investigate this in the coming days, but in any event I don't think there is anything we can do on Octave side.

Pantxo Diribarne <pantxo>
Group Member
Mon 29 Aug 2016 07:40:44 PM UTC, comment #12: 

@Pantxo: Are you seeing the same lines in patch demos #6 and #7 that I am?  I'm attaching the onscreen and printed version of demo #6 done with the FLTK toolkit.

This might have to do with polygon offset and how well that is supported by gl2ps.  I'm currently using gl2ps-1.3.9.

Rik <rik5>
Group administrator
Mon 29 Aug 2016 07:37:23 PM UTC, comment #11: 

@Markus: I pushed both of your patches.

Rik <rik5>
Group administrator
Mon 29 Aug 2016 04:06:17 PM UTC, comment #10: 

Attached another changeset that makes the demo in isonormals.m compatible with Matlab.

(file #38380)

Markus Mützel <mmuetzel>
Group administrator
Mon 29 Aug 2016 04:00:50 PM UTC, comment #9: 

Attached is a changeset that fixes demo light 8 in Matlab and adds a new demo that shows the differences to Matlab.
Feel free to not apply it if you think that we should try to mimic Matlab's (imho incorrect) behavior.

(file #38379)

Markus Mützel <mmuetzel>
Group administrator
Fri 26 Aug 2016 04:11:21 PM UTC, comment #8: 

@Pantxo: I pushed your solution for clipping here (http://hg.savannah.gnu.org/hgweb/octave/rev/4dfb28724863).  I made one change.  Since the values being compared were floats I used float constants for comparison.  In other words

x < 0.     // This is comparion to double (0)
x < 0.0f   // This is comparison to float (0).

It probably doesn't make much of a difference since the compiler should be able to see that the value is static at compile time and put in a float rather than a double, but I thought I would make the code clear on that point.

Rik <rik5>
Group administrator
Fri 26 Aug 2016 04:08:41 PM UTC, comment #7: 

@Pantxo: I pushed your patch for edgecolor here (http://hg.savannah.gnu.org/hgweb/octave/rev/c5da5e5e9846).  This seems like the right solution.

Rik <rik5>
Group administrator
Fri 26 Aug 2016 02:33:29 PM UTC, comment #6: 

@Rik: for material #2 (and any patch/surface printing)
There seams to be redundancy in "edgecolor" and "linestyle" properties. According to ML doc for e.g. surface setting either property to "none" should prevent from drawing the edges.
In Octave this works on-screen but when only setting "linestyle" to "none" the lines are actually drawn, but with "glLineStipple (1, 0)". As we don't instruct gl2ps to change line stipple here ...

Modifying the demo to include "edgecolor" -> "none" lets it be printed as on-screen; but I don't think this is the right fix.

I could check in ML2016a that if I change one property to "none", the other is no affected. See attached patch.

(file #38363)

Pantxo Diribarne <pantxo>
Group Member
Thu 25 Aug 2016 04:00:16 PM UTC, comment #5: 

I wrote a test script that produces graphics resembling the graphics on [1].  The script itself together with the results I get in Octave and in Matlab are attached.

The faces in both upper axes are facing outwards. The faces in both lower axes are facing inwards.
The left patches have "BackFaceLighting" set to "reverselit". The right patches to "unlit".

The lighting in the upper left figure looks like all faces are pointing away from the camera. This is not what I expected from reading the docs.

Additionally, the reverse sides seem to be lighted for "unlit" in Matlab although they shouldn't. This is especially prominent in the shape in the lower right. The lighting on the outer side of that shape is the same as for the outer side in the upper left corner (what I would expect for "lit").

I tend towards considering this a bug in Matlab's lighting routines and not fixing this in Octave.
I would rather prefer to work around this Matlab incompatibility by changing demo light 8 in a way that it would produce similar results in Matlab and in Octave. (And maybe add demo_light_new as an additional demo to light.m with a comment that we expect Matlab to fail that test?)

Any opinions?

[1] http://de.mathworks.com/help/matlab/visualize/reflectance-characteristics-of-graphics-objects.html#f1-21877

(file #38349,

Markus Mützel <mmuetzel>
Group administrator
Thu 25 Aug 2016 08:12:49 AM UTC, comment #4: 

@Rik: for imshow #8:
gl2psDrawPixels seems to scale RGB data between max and min. This is what glDrawPixels (the openGL counterpart of gl2psDrawPixels) does for integer data types [1]. So in short gl2ps doesn't fully implement glDrawPixels (only GLFloat data are supported) and the behavior is not correct. The attached patch works around this behavior, and changes the title of the demo (these are not indexed colors).

[1] https://www.opengl.org/sdk/docs/man2/xhtml/glDrawPixels.xml

(file #38346)

Pantxo Diribarne <pantxo>
Group Member
Wed 24 Aug 2016 07:50:00 PM UTC, comment #3: 

For a visual example, try http://de.mathworks.com/help/matlab/visualize/reflectance-characteristics-of-graphics-objects.html and then the section on Back Face Lighting.  There are two examples.  One showing the use of 'reverselit' and the other trying to explain 'lit' versus 'reverselit'.

Maybe we should try and change the demo view() or the shape of the figure that we are working with so we can clearly distinguish inside from outside surface?  But then we would need someone to run the new demo on Matlab.

Face lighting when the vertex normals point away from camera, specified as one of these values:

    'reverselit' — Light the face as if the vertex normal pointed towards the camera.

    'unlit' — Do not light the face.

    'lit' — Light the face according to the vertex normal.

Rik <rik5>
Group administrator
Wed 24 Aug 2016 06:47:09 PM UTC, comment #2: 

To be honest, I do not understand what Matlab is doing. According to [1], I think we are doing the correct thing.
If I understand the following sentences correctly, it should not matter in which direction the surface normals are pointed when "BackFaceLighting" is set to "reverselit":

Face lighting when the vertex normals point away from camera, specified as one of these values:
'reverselit' — Light the face as if the vertex normal pointed towards the camera.

This is what is done in Octave: Normals pointing away from the camera are reversed.

Additionally, I cannot see any visual difference between "lit" and "unlit" in Matlab [2]. According to [1], there should be a difference:

'unlit' — Do not light the face.
'lit' — Light the face according to the vertex normal.

Those short sentences seemed easy enough to understand correctly when I first read them. I might have misunderstood them anyway. Can someone help me out, what else could be meant?

[1] http://de.mathworks.com/help/matlab/ref/primitivesurface-properties.html#property_backfacelighting
[2] http://josoansi.de/octave_plot_compare/compare_plot_demos_04.html#light_08

Markus Mützel <mmuetzel>
Group administrator
Wed 24 Aug 2016 04:00:18 PM UTC, comment #1: 

Adding Pantxo to the CC list as he may know a solution for the gl2ps printing issues.

Adding Markus Muetzel to the CC list as he may understand the "backlit" property option.

Rik <rik5>
Group administrator
Tue 23 Aug 2016 05:23:09 PM UTC, original submission:  

All testing was done with cset 22366:837df5db5710.  After running the dump_plot_demos script and comparing this to results obtained under Matlab (http://josoansi.de/octave_plot_compare) I've found the following problems.

demo imshow 8
 ## Indexed color shows correctly onscreen, but does not print correctly to png.
 ## Seems like an issue with gl2ps

demo light 8
 ## Test of 'light' objects with the "backlit" property is different
 ## Need to redo the algorithms for "backlit"

demo material 2
 ## Plot appears correctly onscreen, but when printed the mesh lines are black.
 ## Seems like an issue with gl2ps

demo patch 6
 ## Hidden lines are showing through when printing
 ## Seems like an issue with gl2ps

demo patch 7
 ## Hidden lines are showing through when printing
 ## Seems like an issue with gl2ps

demo plotmatrix 1
 ## Matlab chooses to hide the xlabels and ylabels of subplots in the 3x3
 ## array in order to better show the data.  Also, for the subplots with
 ## histograms the axis tick marks are disabled.  See plotmatrix.m

demo plotyy 3
 ## I don't know whether this is really a valid use case, but trying to
 ## use 'hold on' with plotyy is running into problems with the ColorOrder
 ## property and creating different results from Matlab.

demo rose 1
 ## The plot is reversed left-to-right.  The maximum value under Octave occurs
 ## at theta=0, whereas it is theta=180 for Matlab.  Have we got the algorithm
 ## reversed in rose.m?

 ## Lots of these demos are different from the ones with Matlab.  It looks like
 ## the sizing of markers for scatter needs to be re-done completely.
 ## See scatter.m

Rik <rik5>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #38560:  aliasing_png3.patch added by pantxo (2KiB - text/x-diff)
file #38543:  aliasing_png.patch added by pantxo (2KiB - text/x-diff)
file #38477:  t1.pdf added by dasergatskov (10KiB - application/pdf)
file #38478:  t1.svg added by dasergatskov (9KiB - image/svg+xml)
file #38476:  blending.patch added by pantxo (5KiB - text/x-diff)
file #38464:  t2.svg added by dasergatskov (7KiB - image/svg+xml)
file #38465:  t2.eps added by dasergatskov (7KiB - application/postscript)
file #38463:  t1.svg added by dasergatskov (7KiB - image/svg+xml)
file #38462:  t1.eps added by dasergatskov (7KiB - application/postscript)
file #38457:  scatter.png added by mkunz (8KiB - image/png)
file #38454:  untitled.fig added by None (17KiB - application/octet-stream - scatter (1:100, 1:100, 1:100) in matlab (R2015b))
file #38451:  scatter.png added by gyom (18KiB - image/png)
file #38383:  patch_demo_6_onscreen.png added by rik5 (15KiB - image/png)
file #38384:  patch_demo_6_print.png added by rik5 (45KiB - image/png)
file #38363:  edges.patch added by pantxo (1KiB - text/x-diff)
file #38349:  demo_light_new.m added by mmuetzel (1KiB - text/x-objcsrc)
file #38346:  imshow8.patch added by pantxo (2KiB - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mkunz (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by gyom (Updated the item)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-16 rik5 Open/ClosedOpen Closed
    2016-09-19 pantxo Attached File- Added aliasing_png3.patch, #38560
    2016-09-18 pantxo Attached File- Added aliasing_png.patch, #38543
    2016-09-11 dasergatskov Attached File- Added t1.pdf, #38477
        Attached File- Added t1.svg, #38478
    2016-09-11 pantxo Attached File- Added blending.patch, #38476
    2016-09-09 dasergatskov Attached File- Added t2.svg, #38464
        Attached File- Added t2.eps, #38465
    2016-09-09 dasergatskov Attached File- Added t1.svg, #38463
    2016-09-09 dasergatskov Attached File- Added Screenshot_from_2016-09-09_12-28-40.png, #38461
        Attached File- Added t1.eps, #38462
    2016-09-09 mkunz Attached File- Added scatter.png, #38457
    2016-09-08 None Attached File- Added untitled.fig, #38454
    2016-09-08 philipnienhuis Attached File- Added scatter_bug#48873_ml2016b.png, #38452
    2016-09-08 gyom Attached File- Added scatter.png, #38451
    2016-08-31 rik5 StatusIn Progress Postponed
    2016-08-29 rik5 Attached File- Added patch_demo_6_onscreen.png, #38383
        Attached File- Added patch_demo_6_print.png, #38384
    2016-08-29 mmuetzel Attached File- Added bug48873_isonormals_demo.patch, #38380
    2016-08-29 mmuetzel Attached File- Added bug48873_light_backfacelighting.patch, #38379
    2016-08-26 pantxo Attached File- Added edges.patch, #38363
    2016-08-25 mmuetzel Attached File- Added demo_light_new.m, #38349
        Attached File- Added light_reverselit_Matlab.png, #38350
        Attached File- Added light_reverselit_Octave.png, #38351
    2016-08-25 pantxo Attached File- Added imshow8.patch, #38346

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code