Bug 132959 - Save image to PNG does not use dialog's target resolution, metadata is not modified (comment 15)
Summary: Save image to PNG does not use dialog's target resolution, metadata is not mo...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 132961 155521 (view as bug list)
Depends on:
Blocks: Graphics-Export Image-DPI Image-Compression-Dialog
  Show dependency treegraph
 
Reported: 2020-05-11 18:00 UTC by Telesto
Modified: 2024-06-18 06:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


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 Comment hidden (off-topic)
Comment 5 Robert Großkopf 2020-12-21 16:09:10 UTC Comment hidden (off-topic)
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 Comment hidden (off-topic)
Comment 8 Luboš Luňák 2021-01-04 17:45:43 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2023-01-05 03:20:20 UTC Comment hidden (obsolete)
Comment 10 Robert Großkopf 2023-01-05 07:06:28 UTC
Bug is still the same in LO 7.4.3.2 on OpenSUSE 15.3 64bit rpm Linux.
Comment 11 Stéphane Guillou (stragu) 2023-07-19 15:12:13 UTC
*** Bug 132961 has been marked as a duplicate of this bug. ***
Comment 12 Stéphane Guillou (stragu) 2023-07-19 15:18:02 UTC
*** Bug 155521 has been marked as a duplicate of this bug. ***
Comment 13 Stéphane Guillou (stragu) 2023-07-19 15:19:25 UTC Comment hidden (obsolete)
Comment 14 Stéphane Guillou (stragu) 2023-07-19 16:39:19 UTC
(In reply to WN from comment #7)
> IMHO this looks really like a regression in the 6* series to me...

This regression was introduced in 6.3 and is still present in master at 24.2. I set bug 139152 from "duplicate" back to "new" as the offending commit is identified there.
Comment 15 Stéphane Guillou (stragu) 2023-07-20 15:28:37 UTC
(In reply to Telesto from comment #0)

I also tested in 4.4.7 with attachment 160695 [details] to check Telesto's findings. (No export dialog in that version.)

I used this ImageMagick command to check the metadata:

identify -verbose png44nodpi.png | head -10

- for top picture: no resolution, no print size, no unit:

  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 640x480+0+0
  Units: Undefined
  Colorspace: sRGB
  Type: TrueColorAlpha
  Base type: Undefined
  Endianess: Undefined

- for bottom picture: 

  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 640x480+0+0
  Resolution: 39.37x39.37
  Print size: 16.256x12.192
  Units: PixelsPerCentimeter
  Colorspace: sRGB
  Type: TrueColor

The resolution does correspond to the original 100 DPI. (39.37*2.54)

In 6.0 (when dialog became available), 7.0, and a recent master build at 24.2:

- for top picture, target is 96 dpi:

  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 640x480+0+0
  Units: Undefined
  Colorspace: sRGB
  Type: TrueColorAlpha
  Base type: Undefined
  Endianess: Undefined

- for bottom picture, target is 96 dpi:

  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 640x480+0+0
  Resolution: 39.37x39.37
  Print size: 16.256x12.192
  Units: PixelsPerCentimeter
  Colorspace: sRGB
  Type: TrueColor

So resulting files are the same in 4.4, 6.0, 7.0 and 24.2.

The difference is that the DPI settings displayed in the dialog available since 6.0 have no impact on resulting files.
Exact same results if changing the DPI to e.g. 150 or reducing it to 50 in the dialog before exporting. (Which is bug 150310, currently duplicate of bug 144195.)

So my conclusion is:
- Export of image was OK in 4.4, because we had no resolution/size dialog: it matched the original file.
- Now that we have the dialog, we notice that it does nothing when changing the DPI setting.

I will review the duplicate here and in bug 144195, when I check how full-document export and compress dialog differ to the above.

Using 6.0 as earliest version, as that's when the dialog appeared.
Comment 16 Telesto 2024-02-18 12:45:58 UTC
Appears to be OK
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 125fc2ce861c82592b261f2992c893b414396e56
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded
Comment 17 Stéphane Guillou (stragu) 2024-02-18 23:46:00 UTC
I tested with:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5a4ab8cb3a3fbf15de11afc5d8876aaa8a7784c9
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

and get the same results as version 24.2 in comment 15.

What exactly did you test, Telesto?
Comment 18 Telesto 2024-02-19 18:47:33 UTC
(In reply to Stéphane Guillou (stragu) from comment #17)
Well I'm surely mistaken. Not sure what I did. 

Side-note: The marking the status to FIXED is accidental. I'm blaming the bugtracker for it. I haven't exact steps, yet: it's something like pressing back button in browser when status is set to RESOLVED, WFM. Where RESOLVED remains, but secondary part (WFM) being reset to the top of the list (FIXED), if not reconfigured again. The reason for pressing back: posting failed (time-out) or something like that. I'm simply pressing post again after pressing back-button without checking...