bugGNU Octave - Bugs: bug #57552, Marker sizes in OpenGL raster...


bug #57552: Marker sizes in OpenGL raster plots (png, jpg, etc.) are larger than onscreen

Submitted by:  Rik <rik5>
Submitted on:  Tue 07 Jan 2020 11:56:04 PM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  6.0.90 Operating 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)

Tue 07 Apr 2020 12:34:09 AM UTC, comment #7: 

I reviewed the patch and made some small changes.  I moved the division by 72.0 to occur in the const declaration so it is done only once.  I also changed print.m so that it redraws the figure after printing to solve the problem in comment #6.  The patch went here https://hg.savannah.gnu.org/hgweb/octave/rev/5624fd0c5efb.

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Fri 13 Mar 2020 09:06:30 PM UTC, comment #6: 

This appears to work.  There is something funny with updates of the window after the print command has completed.   I used the following code in a file tst_marksz.m (uploaded as well)

plot (1:10, 'o-', 'markersize', 36);
print -opengl tst.png



Now look at the size of the markers in the onscreen plot.  They are too small.  I can restore them to the correct size by executing "refresh" at the command line or by clicking in the figure window.  Perhaps we need to call refresh or drawnow in print.m at the end of the function.

(file #48595)

Rik <rik5>
Project Administrator
Thu 12 Mar 2020 09:18:29 PM UTC, comment #5: 

@Rik: Sorry for the big delay. The attached patch seems to do the job, but I didn't test it carefully.

@Dmitri: I also get a png image which is 873x655, almost the same as yours. This is the expected size with an original, onscreen, figure which is 560x420 pixels (the default) and a screen resolution which is 96 dpi: since the default print resolution for raster outputs is 150 dpi, the printout is 150/96 times larger. Now I don't understand why you obtain the same final size as me with an original figure 418x314 pixels large, unless you have a 72 dpi display.

The only problem I see on my machine is that an image viewer software have no way to know the intended resolution of the image (imwrite doesn't currently support writing those metadata), and thus renders it at screen resolution.

(file #48588)

Pantxo Diribarne <pantxo>
Project Member
Fri 21 Feb 2020 10:11:23 PM UTC, comment #4: 

Also "print -opengl -svgconvert tst1.png' still wrong, and the file size is approximately 2x2 times larger (875x656 pixels vs 418x314 on my computer).


Dmitri A. Sergatskov <dasergatskov>
Fri 21 Feb 2020 09:46:08 PM UTC, comment #3: 

@Pantxo: Could you take a look at this bug report before the 6.1 is released?  I've fixed bug #57651 so you only need to print once.  Test code is

plot (1:10, 'o-', 'markersize', 36);
print -opengl tst.png

Possible clues:

1) -painters or -opengl option doesn't make a difference.
2) svg format works (print -opengl tst.svg)
3) this worked in 5.1.

Rik <rik5>
Project Administrator
Thu 23 Jan 2020 04:36:49 AM UTC, comment #2: 

I realize that my fix only works for the -painters backend.  Using the -opengl option fails.

plot (1:10, 'o-', 'markersize', 36);
print -opengl tst.png
unlink tst.png
print -opengl tst.png
open tst.png

Printing twice is required to work around bug #57651.

Rik <rik5>
Project Administrator
Thu 23 Jan 2020 04:15:51 AM UTC, comment #1: 

I checked in a change that fixes this issue here https://hg.savannah.gnu.org/hgweb/octave/rev/46fe22bf1458.

Marking as "Ready For Test".

One thing I note is that we are using a static variable for the conversion factor between points and pixels.  What if the user has two monitors and moves the plot window between the two?  It seems possible that this variable should not be calculated once (static), but calculated every time there is something printed in case the monitor has changed.

Rik <rik5>
Project Administrator
Tue 07 Jan 2020 11:56:04 PM UTC, original submission:  

Code to reproduce

plot (1:10, 'o-')
print tst.png

By opening up the resulting tst.png and resizing the window to be the same as the plot window that is already open in Octave one can see that the size of the 'o' marker is larger in the plot.

This is likely due to the fact that Octave switched to measuring marker sizes in points (1/72 of an inch) rather than pixels.  In gl2ps-print.cc there is an overloaded function set_linewidth which simply calls gl2psLineWidth().  It would seem that we need something similar for the markers.

There is already an overload of init_markers in gl2ps-print.cc.

    void init_marker (const std::string& m, double size, float width)
      opengl_renderer::init_marker (m, size, width);

      // FIXME: gl2ps can't handle closed contours and we set linecap/linejoin
      //        round to obtain a better looking result for some markers.
      if (m == "o" || m == "v" || m == "^" || m == ">" || m == "<" || m == "h"
          || m == "hexagram" || m == "p" || m == "pentagram")
          set_linejoin ("round");
          set_linecap ("round");
          set_linejoin ("miter");
          set_linecap ("square");

It calls the init_marker function in gl-render.cc which eventually calls make_marker_list() and that function has

    // FIXME: See bug #53056 (measure LineWidth in points).
    const static double pts2pix
      = (gh_mgr.get_object (0).get ("screenpixelsperinch").double_value ()
         / 72.0);

    double sz = size * pts2pix;

For an average screen, "screenpixelsperinch" is ~96 so this piece of code inflates the size by 4/3.

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 #48595:  tst_marksz.m added by rik5 (64B - text/x-matlab)
file #48588:  bug57552.patch added by pantxo (6KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


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

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

    Only project members can vote.




    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-04-07 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2020-03-13 rik5 Attached File- => Added tst_marksz.m, #48595
    2020-03-12 pantxo Attached File- => Added bug57552.patch, #48588
        StatusConfirmed => Patch Submitted
    2020-02-21 rik5 Releasedev => 6.0.90
        SummaryMarker sizes in OpenGL printed plots are larger than onscreen => Marker sizes in OpenGL raster plots (png, jpg, etc.) are larger than onscreen
    2020-01-28 rik5 StatusReady For Test => Confirmed
    2020-01-23 rik5 StatusConfirmed => Ready For Test
    2020-01-07 rik5 Carbon-Copy- => Added pantxo

    Back to the top

    Powered by Savane 3.5