Bug 51509 - FILEOPEN: Resolution in PNG files is ignored
Summary: FILEOPEN: Resolution in PNG files is ignored
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: x86-64 (AMD64) macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-28 01:59 UTC by Bernd Sieker
Modified: 2015-04-22 10:43 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Two PNG files for testing resolution interpretation during import (124.31 KB, application/zip)
2012-06-30 11:11 UTC, Bernd Sieker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Sieker 2012-06-28 01:59:49 UTC
PNG files can have a resolution in pixels-per-inch in their header, which, combined with the pixel resolution of the image, results in a specific size (in centimeres, inches, ...).

LibreOffice appears to open all PNG files as if they were 72 dpi.

Resolution information in JPEG image files is used by LibreOffice.

This bug makes it hard to import several images from the same source, but with different dimensions at the same scaling, since images larger than the textwidth are downscaled to the textwidth, and the relative scaling options are relative to textwidth, and not relative to original image size.

In my case, I have a number of automatically generated images wich contain rendered text at a constant point size. Currently the only way to import them so that the text across all images is consistently exactly the same size, is to use JPEG, which, since the images are black/whilte lineart, is a terrible waste of memory, and still produces suboptimal results due to JPEG's lossy data reduction algorithms.

The only way to use PNG is to manually rescale the images after import, which still does not guarantee consistent scale.
Comment 1 Roman Eisele 2012-06-30 08:05:41 UTC
Thank you very much for your bug report!

However, I have some problems to reproduce it.
To reproduce, I have saved the same 300ppi 24bit RGB TIFF file one time as JPEG file, one time as PNG file, and imported both into LibreOffice Writer; both appeared at the same size, and the Image dialog window reports their resolution as 300ppi, when the image size is set to 100%. For saving the images, I have used PhotoShop CS (yes, the very old version), and for testing LibreOffice 3.5.4.2 on MacOS X 10.6.8.

Therefore, it seems that LibreOffice does not always ignore the resolution information in the PNG file header. We need to find out which images show this problem ... I want to ask you two questions:

1) Which application was used to save the PNG files you report about?

2) Could you attach one of the problematic PNG files as sample to this bug report, or, if they are not too large in size, put 2 or 3 ... into a ZIP file and attach this ZIP file to this bug report? If you could do so, I could try to reproduce the issue with your files.

This would be very helpful, thank you in advance!
Comment 2 Bernd Sieker 2012-06-30 11:11:05 UTC
Created attachment 63649 [details]
Two PNG files for testing resolution interpretation during import
Comment 3 Bernd Sieker 2012-06-30 11:12:40 UTC
I have managed to narrow it down some more.

It happens with PNG files created by ImageMagick ("convert" and "mogrify").

Examining these with ImageMagick's "identify" gives the resolution as set during creation (in my case, 600 dpi). ImageMagick purports to set the PNG's "phys" header.

It works fine with PNG files created with netpbm (using the "-size" option and setting the resolution in "pixels per meter") and created with Gimp.

I attached one PNG created with convert, and one created with netpbm's "pnmtopng". The first does not work properly, treating it as if it were 72dpi (and treated the same way by Gimp, which hints at some ImageMagick problems), the second one works properly, although NetPBM only allows an integer value for "pixels per meter", which do not translate to exactly 600dpi, so Gimp says the image has "599.999" pixels per inch. Close enough for me.


Bernd
Comment 4 Roman Eisele 2012-07-04 00:46:17 UTC
(In reply to comment #3)
> I have managed to narrow it down some more.

@Bernd Sieker:
Thank you very much for your research! Good work ...

> I attached one PNG created with convert, and one created with netpbm's
> "pnmtopng". The first does not work properly, treating it as if it were 72dpi
> (and treated the same way by Gimp, which hints at some ImageMagick problems),
> the second one works properly, although NetPBM only allows an integer value
> for "pixels per meter", which do not translate to exactly 600dpi,
> so Gimp says the image has "599.999" pixels per inch. Close enough for me.

I can confirm this, and I can also confirm that LibreOffice loads the image file "TestPNG-600dpi-NetPBM.png" correctly with ca. 600 dpi resolution, but treats "TestPNG-600dpi-ImageMagick.png" as a 72 dpi (default resoltion) image.

The question is now: where is the error? Who is to blame for it: ImageMagick or LibreOffice?

Not only LibreOffice, but many applications don't understand ImageMagick's way to set the resolution:
* Gimp 2.8.0
* PhotoShop CS (old, of course)
* Apple's Preview 5.0.3
* Scribus 1.4.1
All report that the resolution of "TestPNG-600dpi-ImageMagick.png" was 72ppi.

The only application (besides ImageMagick) I found which reads the 600ppi resoltion from "TestPNG-600dpi-ImageMagick.png" is exiftool (8.38); when called with
  exiftool -a -u -g1 TestPNG-600dpi-ImageMagick.png
it reports
  Pixels Per Unit X: 600
  Pixels Per Unit Y: 600
  Pixel Units      : Unknown

The last line could be the answer to our question (but I don't know for sure, I'm no PNG file format expert): the "Unknown". It should be "Inch" instead. When I test other valid PNG files, there is always some unit here, e.g., like in your "TestPNG-600dpi-NetPBM.png" sample:
  Pixels Per Unit X: 23622
  Pixels Per Unit Y: 23622
  Pixel Units      : Meters
(this means ca. 600 ppi), or, from a 300ppi 24bit RGB png file saved with PhotoShop,
  Pixels Per Unit X: 11811
  Pixels Per Unit Y: 11811
  Pixel Units      : Meters
(this means ca. 300ppi).

I don't know how these units are saved inside the PNG file format, but I get the impression that ImageMagick is to blame for our PNG resolution problem: it seems that ImageMagick saves the resolution in dpi correctly into PNG files, but forgets to save the "Pixel Units" field, and therefore PNG readers just ignore the two "Pixels Per Unit" fields, because a simple resolution number without unit is worthless. Other image formats just use always the same unit (e.h., dpi), but the PNG file format allows to specify the unit, and so it is clearly an error to not specify it.

Therefore I set the status of this bug report to RESOLVED/NOTOURBUG, because it seems that ImageMagick is to blame for this problem, which is confirmed (see above) by the fact that even Gimp, PhotoShop, and Scribus can't read the resolution from ImageMagick's PNG files.

Everybody, feel free to re-open this issue if you have additional evidence that my reasoning is wrong and that there is really a problem *especially* in LibreOffice with PNG files and resolution.
Comment 5 Bernd Sieker 2012-07-04 02:40:05 UTC
Additional information on the PNG format:

http://www.w3.org/TR/PNG-Chunks.html

See the pPHYs chunk: Unit is stored in a byte, and the only specified values are "0": unknown, and "1": meter.

The specs say explicitly that when Unit is "0", the pixels per unit specify pixel aspect only, and not resolution, and as such it is correct for LibreOffice to assume default resolution.

Sorry for wasting your time.


Bernd
Comment 6 Roman Eisele 2012-07-04 04:19:03 UTC
(In reply to comment #5)
> Additional information on the PNG format:
> http://www.w3.org/TR/PNG-Chunks.html
[...]

Thank you for the additional research! This clarifies the problem sufficiently.


> Sorry for wasting your time.

Oh no, it was no waste of time ;-) We both have learned something important about the PNG format, we have analyzed the problem completely, and if/when someone else ever reports about the same problem (that may well happen), we can directly answer his question and refer to the present report. So, thank you again!
Comment 7 Marcel Partap 2015-04-22 10:43:10 UTC
[...]
but would it not, in a case of a file with set resolution and "unknown" pixel units, be the most sensible thing to default to meters? That would gracefully handle existing images created by IM.
Also, a way to specify a wanted DPI resolution would be really great in many cases where you want 'pixel-perfect' pre-press PDFs...