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

 
 

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

Submitted by:  Rik <rik5>
Submitted on:  Tue 23 Aug 2016 05:23:09 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: PostponedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 20 Sep 2016 04:19:21 PM UTC, comment #39:

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

Dmitri.
--

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>
Project 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>
Project 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>
Project 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>
Project Member
Mon 19 Sep 2016 09:07:16 PM UTC, comment #34:

After playing around with

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>
Project 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'

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

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

to

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

Rik <rik5>
Project 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>
Project 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>
Project 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>
Project 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:

and then in terminal

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

Dmitri.

(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.
--

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

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>
Project 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

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

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>
Project Administrator
Fri 09 Sep 2016 05:57:18 PM UTC, comment #25:

If I set
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.

Dmitri.

(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.

Dmitri.

(file #38461, 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?

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>
Project Administrator
Fri 09 Sep 2016 06:50:00 AM UTC, comment #21:

I ran

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

(file #38457)

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

Rik,

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:

http://josoansi.de/octave_plot_compare/Matlab_R2016a/grid_01.png
and
http://josoansi.de/octave_plot_compare/compare_plot_demos_03.html
(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.
--

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

Rik <rik5>
Project 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

Dmitri.

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

another by ml2016b, max screen size

(file #38452)

Philip Nienhuis <philipnienhuis>
Project 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>
Project Administrator
Thu 08 Sep 2016 04:21:02 PM UTC, comment #15:

@Rik: attached a copy of the output of:

(file #38451)

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>
Project 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>
Project 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.

(file #38383, file #38384)

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

@Markus: I pushed both of your patches.

Rik <rik5>
Project 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>
Project Member
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>
Project Member
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

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>
Project 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>
Project 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>
Project 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, file #38350, file #38351)

Markus Mützel <mmuetzel>
Project Member
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>
Project 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.

Rik <rik5>
Project 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":

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:

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>
Project Member
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>
Project 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.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

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 8.6.0.267246 (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)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 25 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 19 Sep 2016 10:39:19 PM UTCpantxoAttached File-=>Added aliasing_png3.patch, #38560
    Sun 18 Sep 2016 06:17:08 PM UTCpantxoAttached File-=>Added aliasing_png.patch, #38543
    Sun 11 Sep 2016 06:42:23 PM UTCdasergatskovAttached File-=>Added t1.pdf, #38477
      Attached File-=>Added t1.svg, #38478
    Sun 11 Sep 2016 09:51:03 AM UTCpantxoAttached File-=>Added blending.patch, #38476
    Fri 09 Sep 2016 05:57:18 PM UTCdasergatskovAttached File-=>Added t2.svg, #38464
      Attached File-=>Added t2.eps, #38465
    Fri 09 Sep 2016 05:50:49 PM UTCdasergatskovAttached File-=>Added t1.svg, #38463
    Fri 09 Sep 2016 05:42:46 PM UTCdasergatskovAttached File-=>Added Screenshot_from_2016-09-09_12-28-40.png, #38461
      Attached File-=>Added t1.eps, #38462
    Fri 09 Sep 2016 06:50:00 AM UTCmkunzAttached File-=>Added scatter.png, #38457
    Thu 08 Sep 2016 08:23:50 PM UTCNoneAttached File-=>Added untitled.fig, #38454
    Thu 08 Sep 2016 06:36:29 PM UTCphilipnienhuisAttached File-=>Added scatter_bug#48873_ml2016b.png, #38452
    Thu 08 Sep 2016 04:21:02 PM UTCgyomAttached File-=>Added scatter.png, #38451
    Wed 31 Aug 2016 04:41:12 AM UTCrik5StatusIn Progress=>Postponed
    Mon 29 Aug 2016 07:40:44 PM UTCrik5Attached File-=>Added patch_demo_6_onscreen.png, #38383
      Attached File-=>Added patch_demo_6_print.png, #38384
    Mon 29 Aug 2016 04:06:16 PM UTCmmuetzelAttached File-=>Added bug48873_isonormals_demo.patch, #38380
    Mon 29 Aug 2016 04:00:49 PM UTCmmuetzelAttached File-=>Added bug48873_light_backfacelighting.patch, #38379
    Fri 26 Aug 2016 02:33:29 PM UTCpantxoAttached File-=>Added edges.patch, #38363
    Thu 25 Aug 2016 04:00:16 PM UTCmmuetzelAttached File-=>Added demo_light_new.m, #38349
      Attached File-=>Added light_reverselit_Matlab.png, #38350
      Attached File-=>Added light_reverselit_Octave.png, #38351
    Thu 25 Aug 2016 08:12:49 AM UTCpantxoAttached File-=>Added imshow8.patch, #38346
    Wed 24 Aug 2016 07:50:00 PM UTCrik5StatusNone=>In Progress

    Back to the top


    Powered by Savane 3.1-cleanup1