bugGNU Octave - Bugs: bug #53056, LineWidth interpreted as pixels,...

 
 

bug #53056: LineWidth interpreted as pixels, not points

Submitted by:  Rik <rik5>
Submitted on:  Sat 03 Feb 2018 12:04:31 PM 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

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)

Mon 11 Feb 2019 10:26:12 PM UTC, comment #11:

Fixed in this changeset (https://hg.savannah.gnu.org/hgweb/octave/rev/9a678e0de658). Reslts seem to match Matlab now and I tried a variety of print formats (png, svg, pdf) and everything seems correct.

Rik <rik5>
Project Administrator
Mon 11 Feb 2019 04:28:37 PM UTC, comment #10:

I'll fix this temporarily with the call to get. Given that set_linewidth is called tens of times even for simple plots I think it would be a good idea to move the overall conversion factor in to a member variable (like m_devpixratio) that is calculated only once, or when the screen changes.

In that vein, I would also store the single conversion factor so that instead of two multiplications per call

there would just be one

Rik <rik5>
Project Administrator
Mon 11 Feb 2019 03:45:54 PM UTC, comment #9:

I think fixing graphics_toolkit::get_screen_resolution and the returned root "screenpixelsperinch" (which IIUC is very wrong on Windows platform) is probably part of a larger discussion, see bug #49627.

For the time being, I'd just use something like

Pantxo Diribarne <pantxo>
Project Member
Mon 11 Feb 2019 04:51:42 AM UTC, comment #8:

@Pantxo: Could you review this patch? Conceptually, it is correct. In order to change the LineWidth measured in points, to one measured in pixels for glLineWidth, one only needs to multiply by a conversion factor. This conversion factor is the monitor's pixels per inch divided by the factor 72 points/inch.

The problem is that the code doesn't work because toolkit.get_screen_resolution always returns 72. It is declared as a virtual function graphics-toolkit.h and is meant to be overloaded by _init_fltk_, _init_gnuplot_, or _init_qt_. Unfortunately, they don't seem to do that, or they overload it by just returning the constant 72 without checking the actual monitor resolution.

This information is, somehow, available because

returns a value on my system which is close to 96. The root object's value is initialized in graphics.cc by this function.

Earlier I tested my patch by hardcoding the screen resolution at 96 so I know that it is only get_screen_resolution which is not working.

(file #46232)

Rik <rik5>
Project Administrator
Tue 13 Feb 2018 04:26:02 PM UTC, comment #7:

@Rik Sorry about that. Must have been in a hurry.
Here is lwidth3_13_Feb.png attached.

(file #43271)

Michael Godfrey <godfrey>
Project Member
Tue 13 Feb 2018 05:29:58 AM UTC, comment #6:

@Michael: The screenshot you attached turns out to be the m-file tst_lwidth3.m. Could you re-post?

Rik <rik5>
Project Administrator
Wed 07 Feb 2018 09:36:19 PM UTC, comment #5:

Matlab output for tst_width3.m:

>> h1 = line ([0 1], [0.1 0.1], 'linewidth', 0.5);
>> h2 = line ([0 1], [0.2 0.2], 'linewidth', 1);
>> h3 = line ([0 1], [0.3 0.3], 'linewidth', 2);
>> h4 = line ([0 1], [0.4 0.4], 'linewidth', 2.75);
>> h5 = line ([0 1], [0.5 0.5], 'linewidth', 3);
>> h6 = line ([0 1], [0.6 0.6], 'linewidth', 6);
>> h7 = line ([0 1], [0.7 0.7], 'linewidth', 12);
>> h8 = line ([0 1], [0.8 0.8], 'linewidth', 18);
>> ylim ([0 1]);
>> set (gcf, 'graphicssmoothing', 'off');
>>

screenshot attached.

(file #43202)

Michael Godfrey <godfrey>
Project Member
Wed 07 Feb 2018 04:13:28 PM UTC, comment #4:

@Michael: The tests showed that the print outs have nearly the same width (Octave is always exactly 1 pixel larger than Matlab).

However, the on-screen display does seem off. Could you try my latest test script, tst_lwidth3.m, which is attached. It disables anti-aliasing so I can get a true idea of the line width. Also, you will need to do a window screen capture, rather than a print, to capture the data since the print code path is different and we have already verified that it works.

(file #43201)

Rik <rik5>
Project Administrator
Sun 04 Feb 2018 04:45:48 PM UTC, comment #3:

Finally got back on. File attached in case you missed my
email.

(file #43169)

Michael Godfrey <godfrey>
Project Member
Sun 04 Feb 2018 03:12:28 PM UTC, comment #2:

The sizes are definitely different. It's my mistake on the error message since I never use Matlab and guess at their syntax. I updated the m-file after reading their documentation more closely. Could you try the new m-file and see if it is able to generate the png file from print?

(file #43168)

Rik <rik5>
Project Administrator
Sat 03 Feb 2018 03:35:53 PM UTC, comment #1:

Rik,
Here is screen but no file was generated likely due to
error message. A screen capture of the displayed file is attached. I ssh'ed to a remote system.

>> close all
>> ver % Show what version is running

-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.3.0.713579 (R2017b)
MATLAB License Number: 569029
Operating System: Linux 4.14.14-200.fc26.x86_64 #1 SMP Fri Jan 19 13:27:06 UTC 2018 x86_64
Java Version: Java 1.8.0_121-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
-----------------------------------------------------------------------------------------------------
MATLAB Version 9.3 (R2017b)
Simulink Version 9.0 (R2017b)
Control System Toolbox Version 10.3 (R2017b)
DSP System Toolbox Version 9.5 (R2017b)
Image Processing Toolbox Version 10.1 (R2017b)
Instrument Control Toolbox Version 3.12 (R2017b)
Optimization Toolbox Version 8.0 (R2017b)
Signal Processing Toolbox Version 7.5 (R2017b)
Simulink Control Design Version 5.0 (R2017b)
Statistics and Machine Learning Toolbox Version 11.2 (R2017b)
Symbolic Math Toolbox Version 8.0 (R2017b)

>> h1 = line ([0 1], [0.1 0.1], 'linewidth', 0.5);
>> h2 = line ([0 1], [0.2 0.2], 'linewidth', 1);
>> h3 = line ([0 1], [0.3 0.3], 'linewidth', 2);
>> h4 = line ([0 1], [0.4 0.4], 'linewidth', 2.75);
>> h5 = line ([0 1], [0.5 0.5], 'linewidth', 3);
>> h6 = line ([0 1], [0.6 0.6], 'linewidth', 6);
>> h7 = line ([0 1], [0.7 0.7], 'linewidth', 12);
>> h8 = line ([0 1], [0.8 0.8], 'linewidth', 18);
>> ylim ([0 1]);
>> print -r300 lwidth.png

Error using alternatePrintPath
Invalid or unsupported printer '' specified.

Error in print (line 82)
pj = alternatePrintPath(pj);

>> quit


(file #43159)

Michael Godfrey <godfrey>
Project Member
Sat 03 Feb 2018 12:04:31 PM UTC, original submission:

According to Matlab documentation, LineWidth and MarkerSize for line objects are specified in points. In Octave, we use the OpenGL function glLineWidth which sets line width in pixels.

Given that Matlab interprets pixels to mean 1/96 of an inch and points are defined to be 1/72 of an inch, this should mean that Octave merely needs to inflate sizes by 96/72 == 4/3.

In order to test this, could someone try the following script in Matlab (also attached) and upload the resulting file?

Rik <rik5>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46232:  bug53056.cset added by rik5 (1KiB - application/octet-stream)
file #43271:  lwidth3_13_Feb..png added by godfrey (15KiB - image/png)
file #43201:  tst_lwidth3.m added by rik5 (500B - text/x-matlab)
file #43169:  lwidth.png added by godfrey (32KiB - image/png)
file #43168:  tst_lwidth2.m added by rik5 (475B - text/x-matlab)
file #43158:  tst_lwidth.m added by rik5 (459B - text/x-matlab)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

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

    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 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-11 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2019-02-11 rik5 Dependencies- => Depends on bugs #49627
    2019-02-11 rik5 StatusPatch Submitted => In Progress
    2019-02-11 rik5 Attached File- => Added bug53056.cset, #46232
        StatusIn Progress => Patch Submitted
        Carbon-Copy- => Added pantxo
    2019-02-06 rik5 Attached File#43202 => Removed
    2018-02-13 godfrey Attached File- => Added lwidth3_13_Feb..png, #43271
    2018-02-07 godfrey Attached File- => Added tst_lwidth3.m, #43202
    2018-02-07 rik5 Attached File- => Added tst_lwidth3.m, #43201
    2018-02-04 godfrey Attached File- => Added lwidth.png, #43169
    2018-02-04 rik5 Attached File- => Added tst_lwidth2.m, #43168
        StatusNone => In Progress
    2018-02-03 godfrey Attached File- => Added Screenshot from 2018-02-03 15-26-02.png, #43159
    2018-02-03 rik5 Attached File- => Added tst_lwidth.m, #43158

    Back to the top


    Powered by Savane 3.4