bugGNU Octave - Bugs: bug #58704, png plot does nor respect dpi and...

 
 

bug #58704: png plot does nor respect dpi and produces unreadable results

Submitter:  Ich selber <octavian>
Submitted:  Sat 04 Jul 2020 12:37:01 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Need Info Assigned to:  None
Originator Name:  Octavian Open/Closed:  * Open
Release:  * 5.2.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 24 Jul 2020 12:04:29 AM UTC, comment #9: 

EMF, as I wrote in comment #4 is never going to be an easy format for Octave to support because it is a Windows-native format and Octave is based on UNIX-native tools and formats like Postscript and PDF.

SVG is probably the best intermediate format.  You can convert multiple SVG files to EMF on the command line with


libreoffice --convert-to emf *.svg



Rik <rik5>
Group administrator
Thu 23 Jul 2020 07:50:01 PM UTC, comment #8: 

Still one comment:
My opinion is that octave has a problem with the dpi settings together with size.
See the file MyPlot_BugReport_ScreenShot.png.
It is done on a 4K monitor with 150 dpi on Windows 10 as a screenshot. The font is too small for the size like in PNG pictures. The drawing routine does not respect size and dpi togehter!

Ich selber <octavian>
Thu 23 Jul 2020 07:37:49 PM UTC, comment #7: 

I see the state more info needed.
Which info do you need exactly?

Ich selber <octavian>
Thu 23 Jul 2020 06:30:29 PM UTC, comment #6: 

Soory, I forgot a little bit: We are talking about more than 100 diagrams so it is not a possible way to generate SVG and manually work with inkjet to PNG or EMF.

Ich selber <octavian>
Thu 23 Jul 2020 06:16:27 PM UTC, comment #5: 

As a answer to Rik:
First of all the reason why I use EMF Format is that it is a vector bades format and it is the best format supported under windows.
PostScript has his best times behind, many modern programs have bugs when using it.
And dokument format like postscript and pdf seems to me too much for a single diagram. Of course I tried SVG, this is a modern format which seems to me the right one but unfortunatly the software I used has many bugs with SVG, the support is small.
EMF Format was up to Octave 4.2 the best solution.

Second the comments of my bugs vor 5.1 and the comments to this bug show me that there some people don't understand what is the important things. And because they are fixed month before 5.2 was available and they are very important because a functionality doesn't work anymore is not comprehensible for me not to be released ion 5.2.

Third you the the plot commands and the result as pictures. Do you find any of that are really nice and as expected? For publisching they are useless in my eyes.
But I'm open for an other set of parameter to solve the problem.


Thanks a lot to Mr Leitner! That's it. Exactly what I wanted to say.


Ich selber <octavian>
Mon 06 Jul 2020 11:34:12 PM UTC, comment #4: 

To the original poster, you will have better graphical results with a vector-based format such as PostScript, Portable Document Format, or Scalable Vector Graphics.  "EMF" is effectively a Windows-format and, although Octave tries to support it, results are not always that good because Octave is based on UNIX tools rather than native Windows libraries (whereas Matlab seems to have gone the other way and is now developed on Windows, and ported to UNIX).  In particular, a good path might be to export to SVG and then touch up any inconsistencies with a WYSIWYG editor such as Inkscape.

Second, the next version of Octave (6.1.0) already resolves a number of these issues.  It is annoying that users keep tripping over the same bugs that have been solved, but there is a developer meeting tomorrow and hopefully we can pick a release date.

Third, Matlab does not support the '-S' option so just ignore it entirely for the moment.  Can you not produce a graphic which has the correct size and resolution by using a combination of the figure paper properties and the -r option of print?  If there is an example where this occurs that should be resolved.

Rik <rik5>
Group administrator
Mon 06 Jul 2020 08:26:30 PM UTC, comment #3: 

I am disinterested in how fast this is fixed, as I do not have the ambition to use the octave output for publishable printing. However, I also do not see why -S and -r should be incompatible. As Rik said in closed #55907, the two options are for different (in my view even orthogonal) things. In this sense I think I am totally with the original reporter here, and I will try to explain it clearly: In my view, both resolution and size in pixel should have some default values. For the sake of argument, let's say the default resolution is 150 dpi. Actually, I think we should be talking about pixel per inch, not dots per inch, see the introduction in https://en.wikipedia.org/wiki/Dots_per_inch. So as I see it, 150 dpi mean 150 pixel per inch. On the other hand, one typographical point is about 1/72 inch (see https://en.wikipedia.org/wiki/Point_(typography) for the different definitions), meaning about 2 pixel per typographical point, meaning in turn that a 10-point font should have a height of about 20 pixel (again this is not strictly correct, as it is more about the horizontal space of the em than about the font height...). Further, let us assume a standard size of 600x400 pixels. Thus, you could fit about 20 lines of text onto the figure.

So much for the default values. If I now specify only the size of the figure, while keeping the resolution fixed, let's say I set the height to 200 pixels. Then I would expect to be able to fit 10 lines of text into the figure.

On the other hand, if I specify the resolution, let's say to 300 dpi, I would expect the size in pixel to remain at 600x400 (I have not requested non-default sizes), while a 10-point font would now have a height of 40 pixels (as I have more pixels to the typographical point). So I would have again 10 lines of text, but with a better resolution of the letters (and that's intended, after all I increased the resolution).

And finally, if I set both to non-default values, let's say 300x200 pixels with a resolution of 75 dpi, then I would expect the 10-point font to have a height of about 10 pixels, and I would again expect to have 20 lines of text, but now with quite coarse letters.

So you see, in this view resolution and size are quite orthogonal concepts. Of course, e.g. increasing the resolution at constant size in pixels would be perfectly equivalent to increasing the font size, line widths, point sizes... at constant resolution (and figure size), so there are work-arounds. But as the original reporter, I do not see why the two options should be incompatible, specifically I do not think that closing #55907 was the right thing to do. Note that I have not checked how octave behaves with the last changesets, and I also cannot check how matlab behaves. Of course, octave should follow matlab, but I would indeed be surprised if also in matlab the resolution would be ignored if a size is specified.

Michael Leitner <mleitner>
Mon 06 Jul 2020 08:16:25 AM UTC, comment #2: 

The new legend function.

(file #49439)

Pantxo Diribarne <pantxo>
Group Member
Mon 06 Jul 2020 08:15:40 AM UTC, comment #1: 

@octavian: Thanks for report.

>> The screenshot font is too small and unreadable.

This is already a know issue: bug #45600.

>> All png shows problems with the legend at all

The problem with the legend box size has been fixed and the fix will be part of Octave 6.0. Provided you don't use gnuplot, the new legend function (attached) can replace the old one in Octave 5.

>> As descriped in bug #55907, the scaling in png files does not work correctly.

IIUC this bug has been fixed by deciding that -SNX,NY and -rRES options are incompatible and -S overrides -r. This looks like a sensible choice to me and I don't understand why you think it is wrong.

>> there is a need of having size in pixels AND the resolution in dots per inche (dpi) for solving the fontsize and the distances which messured in logical font size.

Can you give an example and be more specific?

>> ! I'm sorry to say so, it is very urgent and important for me to get good looking drawings for printing purpose !

Do you really think that exclamation marks will help having it fixed faster? I myself tend to find them irritating rather than motivating.

Pantxo Diribarne <pantxo>
Group Member
Sat 04 Jul 2020 12:37:01 PM UTC, original submission:  

As descriped in bug #55907, the scaling in png files does not work correctly. Especially font size does not work. Lines are not drawn in the right way, look at the edges!
On Screen the font size scaling is also terrible.

Please have a look at the attached files. One is done with dpi 150, one with dpi 1200, one tried the normal Parameter and one is a screen shot.
The screenshot font is too small and unreadable.
The dpi 1200 variant shows best the error with the lines.
All png shows problems with the legend at all.


print -dpng "-S2400,1800" -r1200 MyPlot_BugReport.png
set (gcf, "paperunits", "inches", "paperposition", [0, 0, 4, 3]);
print -dpng -r150 MyPlot150_BugReport.png
print -dpng -r1200 MyPlot1200_BugReport.png


That's the way I do. The first line I wrote in the first bug report. I try to shorten the answer to it:
The "-r" and "-S" options are for different things.  The "-r" option sets the resolution (DPI).  It does not set the size of the figure.  If you want a particular output size, use the paperXXX properties.  See Matlab documentation (https://www.mathworks.com/help/matlab/ref/print.html) for which Octave has to maintain compatibility.
The "-S" option is for setting the size of the output in pixels.  Normally, the number of pixels would be determined automatically by Octave as
number of pixels = physical_size (in inches) * DPI
But by using the "-S" option you have explicitly said how many pixels you want and the resolution is irrelevant. 
AND that's the point I disagree: Because there is a need of having size in pixels AND the resolution in dots per inche (dpi) for solving the fontsize and the distances which messured in logical font size. This logical font size must be resolved to pixel and this only can work if I know how many pixels are one inch. If I use the option S I only overwrite the automatic calculation and now the physical_size can be calculated for the two parameters S and r.

Sorry to say so, the attached png pictures show that distance and font size resolving does not work.

! I'm sorry to say so, it is very urgent and important for me to get good looking drawings for printing purpose !
The prefereed format would be emf, does not work at all. ESP does not work because of character support and png does not work of layout.

Ich selber <octavian>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49439:  legend.m added by pantxo (58KiB - text/x-objcsrc)
file #49427:  MyPlot_BugReport.png added by octavian (241KiB - 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 rik5 (Posted a comment)
  • -email is unavailable- added by mleitner (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by octavian (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-06 pantxo Attached File- Added legend.m, #49439
    2020-07-06 pantxo StatusNone Need Info
    2020-07-04 octavian Attached File- Added MyPlot150_BugReport.png, #49425
        Attached File- Added MyPlot1200_BugReport.png, #49426
        Attached File- Added MyPlot_BugReport.png, #49427
        Attached File- Added MyPlot_BugReport_ScreenShot.png, #49428

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code