Bug 132959 - Save Image to PNG has no DPI written into the file
Summary: Save Image to PNG has no DPI written into the file
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 139152 (view as bug list)
Depends on:
Blocks: Graphics-Export Image-DPI
  Show dependency treegraph
 
Reported: 2020-05-11 18:00 UTC by Telesto
Modified: 2021-01-04 17:45 UTC (History)
2 users (show)

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


Attachments
Example file (865.77 KB, application/vnd.oasis.opendocument.text)
2020-05-11 18:02 UTC, Telesto
Details
Testfile for export (9.58 KB, application/vnd.oasis.opendocument.graphics)
2020-12-21 16:09 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-11 18:00:54 UTC
Description:
Save Image to PNG has no DPI written into the file

Steps to Reproduce:
1. Select image. Format -> Image -> Save -> Choose file name & PNG & Press save
2. PNG options dialog popups up.. also having an resolution setting
3. Save the file -> open it with Irfan view -> No DPI Resolution within file
4. Repeat for image with DPI. Dialog shows 96 -> the file exported has 100 (also wrong)


Actual Results:
No DPI or wrong DPI

Expected Results:
DPI as in dialog


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded

and in 4.4.7.2
Comment 1 Telesto 2020-05-11 18:02:26 UTC
Created attachment 160695 [details]
Example file
Comment 2 Telesto 2020-05-11 18:02:43 UTC
Already confirmed by Regina
Comment 3 Regina Henschel 2020-05-12 00:00:06 UTC
Same happens with compress, see bug 132961
Comment 4 Robert Großkopf 2020-12-21 16:08:31 UTC
I'm not an expert in informations of a image file, but when I export a *.png with LO 6.1.5.2 in 300dpi it shows an image for printing in 300dpi. GIMP sees this in the properties of the file.
If I do the same with LO 6.4.6.2 it shows an image for printing in 72dpi. Tested this also with GIMP.

So there must be a information inside the file which will show other program to set the right dpi in older LO-versions. Couldn't test LO 4.4.7.2 here, but tested LO 6.1.5.2 and there it works. So I would say it is an regression in the last 6.*-versions.

All tests made with the attached *.odg-file. Exported the star with 300dpi and x=6cm y=6cm. My system: OpenSUSE 15.1 64bit rpm Linux.
Comment 5 Robert Großkopf 2020-12-21 16:09:10 UTC
Created attachment 168385 [details]
Testfile for export
Comment 6 Telesto 2020-12-21 19:22:32 UTC
(In reply to Robert Großkopf from comment #5)
> Created attachment 168385 [details]
> Testfile for export

You appear to have found another bug (or another facet)

My PNG without DPI (initial sample) and you're drawing do export with DPI in 6.2 when using DRAW. The PNG without DPI doesn't export a DPI with Writer with 6.2 either.. (which was topic here)

I copy/pasted my PNG from Writer to Draw with 7.1. It's not only lacking DPI. It's apparently even a thumbnail (640 x 480 pixels) instead of the source file. Similar kind of thing happens with the Star (it's low res image..)
Comment 7 WN 2020-12-22 11:43:59 UTC
I'd like to second Roberts remark.
Exporting the same odg-File with LO 6.1 gives the following png information
obtained by imagemagicks identify -verbose:
Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 1183x925+0+0
  Resolution: 118.3x118.3
  Print size: 10x7.8191
  Units: PixelsPerCentimeter
  Type: TrueColorAlpha
  ...

Exporting the same file with LO 6.4 and 7.0 from LO website the header reads now:
Image: TCP-Header.png
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 1183x925+0+0
  Units: Undefined
  Type: TrueColorAlpha
Obviously, the fields resolution, print size are missing and 
the field units is left undefined. 

Using the standard equation:
  no_of_pixels = dpi * inches
the information in the new header format is not sufficient to deduce the size
and/or the resolution. gimp, inkscape, imagemagick et al thus have to assume a resolution ... and choose the standard of 72.

IMHO this looks really like a regression in the 6* series to me...

BTW: platform for tests is Linux Mint 19.3
Comment 8 Luboš Luňák 2021-01-04 17:45:43 UTC
*** Bug 139152 has been marked as a duplicate of this bug. ***