bugGNU Octave - Bugs: bug #57553, ML/Octave visual differences in...


bug #57553: ML/Octave visual differences in plotting

Submitter:  Rik <rik5>
Submitted:  Wed 08 Jan 2020 12:37:53 AM UTC
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 28 Jan 2020 04:12:23 PM UTC, comment #39: 

Thanks to everyone who worked on this bug report.  I think we have accomplished all we need to for the 6.1 release.  There are already other bug reports for the remaining issues such as listeners on colorbars, spacing of title text, unnecessary tick marks on axes in 2-D plots. 

Closing report.

Rik <rik5>
Project Administrator
Sun 26 Jan 2020 04:10:03 PM UTC, comment #38: 

This additional change makes "__unite_shared_vertices__" behave correctly if faces contain "NaN vertices":

I believe this resolves the errors Rik pointed out in comment #32.

Markus Mützel <mmuetzel>
Project Member
Sun 26 Jan 2020 03:49:09 PM UTC, comment #37: 

The additional faces in "demo light 10" were due to a bug in "isosurface". When "__unite_shared_vertices__" is called with faces that contain NaN vertices, those vertices are changed to a "valid" vertex. "isosurface" when called with "noshare" was not affected.
I resolved this by eliminating all "non-valid" faces in "isosurface" before calling "__unite_shared_vertices__" here:

We probably need another fix for "reducepatch" which also uses "__unite_shared_vertices__".

Markus Mützel <mmuetzel>
Project Member
Sun 26 Jan 2020 01:24:41 PM UTC, comment #36: 

I pushed the following change to use only the ambient light for edge lighting on patches:

It is somewhat inconsistent that specular and diffuse lighting is used for the edge lighting on surfaces. But I guess this is what we need to do if we like to follow Matlab.

Markus Mützel <mmuetzel>
Project Member
Wed 22 Jan 2020 09:35:46 PM UTC, comment #35: 

I pushed a change for "demo isocaps 1" here:

Markus Mützel <mmuetzel>
Project Member
Wed 22 Jan 2020 03:43:13 PM UTC, comment #34: 

I'm glad that it looks like there isn't much work to be done.

It seems that the big issue to focus on is the strange closing of the patch object in "demo light 10"

I do think it is worth following Matlab with respect to "EdgeLighting".

Rik <rik5>
Project Administrator
Wed 22 Jan 2020 08:33:15 AM UTC, comment #33: 

Thanks Rik for pointing those out.

The lighting in "demo isocaps 1" looks more natural to me in Octave than what it does in Matlab. It looks like the lighting is from the wrong side in Matlab.
Looking at the demo, there seems to be an error in the direction of the set VertexNormals. That they are set manually at all seems to be a relic from when Octave didn't calculate the normals automatically. I'll prepare a changeset for the demo when I find some time.

"demo isonormals 1" shows that Matlab doesn't do a perfect job as well when it comes to the sign of the automatically calculated normals. I don't know whether it is worth trying to perfectly mimic Matlab in this case. After all, in this particular case, Octave seems to do a slightly better job.

IIRC, we talked about "demo light 10" before. To be honest, I don't know what Matlab is doing in this case. Reading their documentation for "reverselit", I would expect that the top and bottom subplots on the left look exactly the same (what they do in Octave). Anyway, the lighting in the top left subplot looks unnatural in Matlab to me.
Apart from the lighting, there might be a different bug: The patch seems to close strangely in Octave. It looks like there is an additional triangle (or polygon?) in Octave that I wouldn't expect (and that isn't there in Matlab).

It looks like there is no specular reflection for "EdgeLighting" in Matlab (demo light 12). Did that change with Matlab versions? Do we want to follow that change?

Markus Mützel <mmuetzel>
Project Member
Tue 14 Jan 2020 11:32:11 PM UTC, comment #32: 

Adding Markus to the CC list for this report since several of the earlier comments deal with differences in lighting which he worked on.

Differences were seen for

demo isocaps 1
demo isonormals 1
demo light 10
demo light 12

Rik <rik5>
Project Administrator
Tue 14 Jan 2020 11:27:02 PM UTC, comment #31: 

@pantxo:  That looks nice, and a super easy fix as well.  I pushed it here https://hg.savannah.gnu.org/hgweb/octave/rev/12edd3774db6.

Rik <rik5>
Project Administrator
Fri 10 Jan 2020 03:25:08 PM UTC, comment #30: 

The attached patch is what I had in mind for better looking textarrow annotations.

(file #48197)

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Jan 2020 09:06:20 PM UTC, comment #29: 

Comment #24:

Comment #27:
Yeah, this definitely deserves a separate bug report for a big project. This will probably involve switching to modern OpenGL and using shaders for better control of color interpolation.


[1] https://fr.mathworks.com/help/matlab/ref/matlab.graphics.shape.textarrow-properties.html#buchvf6-1-HorizontalAlignment

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Jan 2020 07:46:35 PM UTC, comment #28: 

@Hg200: This is definitely a big visual difference.  I believe it merits its own bug report though.  Could you file a new bug report and include the script and resulting images there?

I will comment more on the new bug report, but Octave seems to be doing the more literal "interpolation" in that the colors smoothly transform.

Rik <rik5>
Project Administrator
Thu 09 Jan 2020 07:02:58 PM UTC, comment #27: 

A bit off topic but not much: There is also a difference between the interpolation techniques used in patch (). Idon't know if this already known.

Take a patch triangle and put the R, G and B colors of the jet map (or another map that is constructed from more than two colors) into the vertices. One edge goes directly from blue to red (without green). In matlab, all colors appear over the edge.

To be honest, if this affects runtime, I would keep the behavior the way it is. I only want to emphasize there can be also differences between M and O due to interpolation.

The attached picture shows the difference between R2018 and Octave.

file #48190)

Hg200 <hg200>
Wed 08 Jan 2020 11:03:30 PM UTC, comment #26: 

Matlab behavior and documentation are inconsistent (again).  For textarrow annotations the "HorizontalAlignment" property default is "left".  But running the example code from annotation demo #1 and then querying the textarrow graphics objects I see that it is "right" for every single one.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 10:30:28 PM UTC, comment #25: 

As a nicety, I think we could move the colorbar slightly closer to its axes.

See file cbar1.png

The code in colorbar makes it clear that the algorithm is not the best.

## FIXME: The algorithm for positioning in legend.m is much more sophisticated
##        and should be borrowed for colorbar.  One problem is that colorbar
##        positioning does not take in to account multi-line axes labels.
## FIXME: Should handle user-specified "AxisLocation" property (mirror var).
function [axpos, cbpos, vertical, mirr] = calc_cbar_position (loc, props, cf)

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 10:15:06 PM UTC, comment #24: 

Annotation demo #1 is slightly different from Matlab.  The text of the textarrow objects is very close to the arrow itself.  It is a small thing, but for the embedded text objects, should we use "center" for the properties "VerticalAlignment" and "HorizontalAlignment"?

Annotation demo #2 is accurate onscreen, but when printed the innerposition + tightinset dotted box is incorrect as it overlaps the bottom xlabel.

See file axespos.png

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 09:51:30 PM UTC, comment #23: 

@Rik: Yes, this is due to antialising, it also shows up when viewing a pdf file in a pdf viewer. I once tried to go for the strategy you propose -not draw unnecessary ticks and grid lines over box lines- but it was much harder than I had expected and I gave up. I still think that it is the cleanest solution though.

Pantxo Diribarne <pantxo>
Project Member
Wed 08 Jan 2020 09:44:15 PM UTC, comment #22: 

One thing I occasionally notice in the plots is that the tick marks at the end of the axes are not well-joined to the line that makes the axes.  Try this

axes ('linewidth', 2, 'box', 'on')

See file axestick.png (file #48182).

The problem seems to be related to "graphicssmoothing" also being on.

The obvious solution is not to draw tickmarks when they are unnecessary.  This would mean filtering out from the list of tickmarks any tickmark which occurs at the same location as an axis boundary.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 07:55:00 PM UTC, comment #21: 

I agree.  The colorbar differences are most likely due to the lack of listeners, and there is already a bug report for that.

The spacing of title text is captured in bug #55562 and so nothing needs to be done here.

Comment #2 was incorrect.  It is

demo isocaps 1

that shows a difference on the left-hand face.

For comment #8 (spacing of polar labels), I checked in a changeset here https://hg.savannah.gnu.org/hgweb/octave/rev/08630aedc41f which resolves it.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 07:44:58 PM UTC, comment #20: 
  • colorbar 6, comment #1: I am not surprised that the colorbar is a little bit displaced during the print process, which involves resizing (to smaller size by default): colorbar axes don't have listeners on their peer axes position. Try reducing the onscreen figure size to smaller size and you'l obtain the same effect. This is probably part of bug #55441 which is missing listeners in colorbar axes (even though the "position" property is not mentioned).
  • the -svgconvert option should have no effect unless the -painters option is specified as well. You can check that using the -debug (undocumented) option, which will display the pipeline commands when using the -painters renderer, or do nothing when using the -opengl renderer.
Pantxo Diribarne <pantxo>
Project Member
Wed 08 Jan 2020 05:18:21 PM UTC, comment #19: 

I guess I had some stale files from previous installation. i wiped out and reinstall and now I am getting the same png files as you.
The filsize is still slightly off, but that might be due to graphics/display size differences. It is also look to me that the issue is with svg generator. The colorbar looks OK if you go through postscript -> png route.


Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 05:03:26 PM UTC, comment #18: 

Another indication that it is not just my computer is that the reference plots at https://josoansi.de/octave_plot_compare/compare_plot_demos_02.html also show misplaced colorbars for both the "-opengl" and "-painters" tests.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 04:30:10 PM UTC, comment #17: 

@Dmitri.  Good point.  I am not setting the option "-svgconvert" though in any manner.  According to the help text for print, "-svgconvert" is an option if the "-painters" mode is used for rendering.  But, for a raster format like png the default should be "opengl"

          Specifies whether the opengl (pixel-based) or painters
          (vector-based) renderer is used.  This is equivalent to
          changing the figure's "Renderer" property.  When the figure
          'RendererMode' property is "auto" (the default) Octave will
          use the "opengl" renderer for raster formats (e.g., JPEG) and
          "painters" for vector formats (e.g., PDF). Those options are
          only supported for the "qt" graphics toolkit.

I think it must have something to do with subplots and maybe graphic callbacks that fire when a figure is printed.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 02:47:42 AM UTC, comment #16: 

Rik, I get png more like yours if I do print -svgconvert.


Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 02:07:21 AM UTC, comment #15: 

I definitely have 1 pixel there...

Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 01:50:28 AM UTC, comment #14: 

This is a wish, but the position of title() text is right up against the top border.  It would be better to have a little bit of margin (whitespace) between the top of the plot and the top of the first line of title text.  Some sample code is

plot (1:10, 'o-');
title ({"Title Line 1", "Title Line 2", "Title Line 3"})
print title.png

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:45:49 AM UTC, comment #13: 

I'm not so concerned about the fonts.  What I am concerned about is that the colorbar itself (an axes object) is changing position.

I re-ran Octave with "-f" and the colorbars are still positioned incorrectly.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:37:15 AM UTC, comment #12: 

So we are getting different figures just running octave vs octave.
Should we fixe this one first?

Attached is my colorbar6.svg shows FreeSans fonts etc...

My guess it is ghostscript doing some font substitutions.


(file #48179)

Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 01:32:31 AM UTC, comment #11: 

Inline view of colorbar6.png:

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:31:54 AM UTC, comment #10: 

Your fonts are even bigger. Are you running "octave -f" ?


Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 01:31:17 AM UTC, comment #9: 

I attached my printout of colorbar 6 as file colorbar6.png.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:21:27 AM UTC, comment #8: 

demo polar 1

This is just a small detail, but the labels for the various distances (which are drawn as circles) could be spaced just a bit away from the actual lines so it is easier to read.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:18:48 AM UTC, comment #7: 

Here is mine. The only difference I see is the fonts on screen look smaller (if you scale to the axis length e.g.).


Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 01:11:57 AM UTC, comment #6: 

demo light 12

Subtle differences.  It seems as if in Octave there might be reflections even though it is a mesh (not a surface).

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:09:23 AM UTC, comment #5: 

WRT comment 1 -- can you attach the png? They look OK on my computer.


Dmitri A. Sergatskov <dasergatskov>
Wed 08 Jan 2020 01:08:38 AM UTC, comment #4: 

demo light 10

Significant differences in the bottom row.  This might be due to how a patch object is being closed.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 01:01:00 AM UTC, comment #3: 

demo isonormals 1

The subplot in the upper left is different.  No isonormals are set, and yet there is still a reflection.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 12:57:43 AM UTC, comment #2: 

demo isocap 6

The left face is different in Matlab.  This is probably caused by the code for lighting, or possible whether patch or surface objects at the same location are displayed.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 12:39:20 AM UTC, comment #1: 

demo colorbar 6
print tst.png

In this case, the onscreen plot is correct, but the generated png file has the colorbars in slightly different positions than the screen.

Rik <rik5>
Project Administrator
Wed 08 Jan 2020 12:37:53 AM UTC, original submission:  

Plot comparisons are available at https://josoansi.de/octave_plot_compare.

Rik <rik5>
Project Administrator


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

Attach Files:

Attached Files
file #48197:  move_textarrow.patch added by pantxo (1KiB - text/x-patch)
file #48189:  patchinterpolation.png added by hg200 (50KiB - image/png)
file #48190:  patchinterpolation.m added by hg200 (373B - text/x-objcsrc)
file #48186:  cbar1.png added by rik5 (27KiB - image/png)
file #48185:  axespos.png added by rik5 (27KiB - image/png)
file #48184:  axestick.png added by rik5 (10KiB - image/png)
file #48181:  colorbar6_3.png added by dasergatskov (35KiB - image/png)
file #48180:  title.png added by rik5 (14KiB - image/png)
file #48179:  colorbar6.svg added by dasergatskov (94KiB - image/svg+xml)
file #48178:  colorbar6.png added by rik5 (34KiB - image/png)
file #48176:  tst1_screen.png added by dasergatskov (32KiB - image/png)
file #48177:  tst1.png added by dasergatskov (43KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by hg200 (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -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 project members can vote.





    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-28 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2020-01-14 rik5 Carbon-Copy- Added mmuetzel
    2020-01-10 pantxo Attached File- Added move_textarrow.patch, #48197
    2020-01-09 hg200 Attached File- Added patchinterpolation.png, #48189
        Attached File- Added patchinterpolation.m, #48190
    2020-01-08 rik5 Attached File- Added cbar1.png, #48186
    2020-01-08 rik5 Attached File- Added axespos.png, #48185
    2020-01-08 rik5 Attached File- Added axestick.png, #48184
    2020-01-08 rik5 Carbon-Copy- Added pantxo
    2020-01-08 dasergatskov Attached File- Added colorbar6_3.png, #48181
    2020-01-08 rik5 Attached File- Added title.png, #48180
    2020-01-08 dasergatskov Attached File- Added colorbar6.svg, #48179
    2020-01-08 rik5 Attached File- Added colorbar6.png, #48178
    2020-01-08 dasergatskov Attached File- Added tst1_screen.png, #48176
        Attached File- Added tst1.png, #48177

    Back to the top

    Powered by Savane 3.9