Bug 144167 - exported PNG image has wrong size when page has border
Summary: exported PNG image has wrong size when page has border
Status: RESOLVED DUPLICATE of bug 144195
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
7.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
 
Reported: 2021-08-29 21:29 UTC by Valerio Messina
Modified: 2024-06-07 17:38 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
test case (44.61 KB, application/vnd.oasis.opendocument.graphics)
2021-08-29 21:32 UTC, Valerio Messina
Details
export as 32x22 cm (274.66 KB, image/png)
2021-08-29 21:33 UTC, Valerio Messina
Details
export as 30x20.63 (255.76 KB, image/png)
2021-08-29 21:33 UTC, Valerio Messina
Details
expected export without 10 mm page border (425.25 KB, image/png)
2022-05-26 06:33 UTC, Valerio Messina
Details
expected export with 10 mm page border (433.35 KB, image/png)
2022-05-26 06:34 UTC, Valerio Messina
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Valerio Messina 2021-08-29 21:29:42 UTC
Description:
the exported PNG loss the right scale

Steps to Reproduce:
1. open the attached .odg
that is 32x22 cm with 1 cm border, so has 30x20 cm area rectangle
2. Go to pag.1, export as so:

3. menu File, Export...,
4. File format: PNG, Save
5. Modify resolution: 300 pixels/inch
6. Modify dimensions, Width: 32 cm
7. the Height is set to 22 cm (so form factor is page not area rectangle)
8. OK

Actual Results:
the exported image is wrong, see attach
"shape20x30cm_scale1:1_libreoffice7.2margin32x22.png"

It has:
1. the right canvas extention 3786x2603 px
2. the right form factor
3. the image miss the 1 cm page border (may be OK)
4. the 30x20 cm (3543x2362 px) rectangle is stretched to 32x22 cm (3786x2603 px)

Note: This does not happen if the page has no border, so 30x20 cm


Expected Results:
export a rectangle sized 30x20 cm (3543x2362 px) without border OR
export a rectangle sized 30x20 cm (3543x2362 px) with 1 cm border so 32x22 cm (3786x2603 px


Reproducible: Always


User Profile Reset: No



Additional Info:
knowing that the exported PNG does not have the border, one can try to selecting:
5. Modify resolution: 300 pixels/inch
6. Modify dimensions, Width: 30 cm
7. the Height is set to 20.63 cm (so form factor is page not area rectangle)
but the exported PNG has wrong form factor, so is worse

In both cases the exported PNG is unusable as lost the right scale
Comment 1 Valerio Messina 2021-08-29 21:32:10 UTC
Created attachment 174616 [details]
test case
Comment 2 Valerio Messina 2021-08-29 21:33:00 UTC
Created attachment 174617 [details]
export as 32x22 cm
Comment 3 Valerio Messina 2021-08-29 21:33:47 UTC
Created attachment 174618 [details]
export as 30x20.63
Comment 4 Buovjaga 2022-05-25 13:30:06 UTC
The dimensions I get for the exported image are 4940 x 3396. Not sure what else to comment. I don't think you are supposed to be using both Modify dimensions and resolution as they are radio buttons that exclude each other.

Arch Linux 64-bit
Version: 7.4.0.0.alpha1+ / LibreOffice Community
Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495
CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 25 May 2022
Comment 5 Valerio Messina 2022-05-25 17:43:52 UTC
If you ever select only dpi or size in mm, you will always get a un-useful image, because LibreOffice cannot know how many output pixels need in the vector to raster conversion.
By definition the WxH [pixels] is the results of dpi [pixel/inch] x size [inch],
so you have to define both, I think this is normal for a vector program.

If you select only the output resolution 300 dpi, with this reference "test_case", you got an image sized 1210x832 pixels, that at 300 dpi, has a size of 102x70 mm
If you select only the output size to 320 mm wide, with this reference "test_case", you got an image sized 1210x832 pixels, that at 300 dpi, has a size of 102x70 mm

In both case it is wrong, as LibreOffice use the default of 96 dpi (grayed) to output for a monitor (not a printer) in case of 320 mm wide fixed size, and a default wide size of 102 mm in case of 300 dpi (printer range) fixed resolution.

Seems to me that the only working method to export with the wanted pixels size is to specify both mm size and dpi resolution.
But here export is not perfect and miss the border, so this bug report.

Tested also on LibreOffice 7.2.5.2 do the same
Comment 6 Valerio Messina 2022-05-25 17:45:25 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2022-05-25 17:46:23 UTC
(In reply to Valerio Messina from comment #6)
> What are the settings you used to get the 4940 x 3396 pixels output image?

Same as yours:

5. Modify resolution: 300 pixels/inch
6. Modify dimensions, Width: 32 cm
Comment 8 Buovjaga 2022-05-25 17:51:16 UTC
(In reply to Valerio Messina from comment #5)
> If you ever select only dpi or size in mm, you will always get a un-useful
> image, because LibreOffice cannot know how many output pixels need in the
> vector to raster conversion.
> By definition the WxH [pixels] is the results of dpi [pixel/inch] x size
> [inch],
> so you have to define both, I think this is normal for a vector program.

Pay attention to what happens when you modify the resolution and then switch to dimensions radio button: the width and height have changed. As you see, one of the options is always *disabled* based on which radio button is selected. You can't modify both independently.
Comment 9 Valerio Messina 2022-05-25 17:58:14 UTC
take note that 320x220 mm at 300 dpi is an image sized 3780x2598 pixels, and not 4940x3396. What version of LO are you using?

When you modify the resolution, LO adjust the size with a not know logic, this is why then I had to force the size in mm too. Then switching back to resolution, LO keep both size and resolution, and this work, but cut out the page border.
Comment 10 Valerio Messina 2022-05-25 18:03:04 UTC
4940x3396 pixels @300dpi is 418x287 mm
Comment 11 Buovjaga 2022-05-25 18:09:04 UTC Comment hidden (obsolete)
Comment 12 Valerio Messina 2022-05-25 19:17:21 UTC
so seems the output image size changed from LO 7.2 to 7.4, and both are wrong.

Do you get the 10 mm page border in the resulting PNG?

Take note that 320x220 mm source page has an espect ratio of 1.45454545 periodic
the 300x200 mm rectange in the source page has an espect ratio of 1.5
The image I got with LO 7.2 is 3786x2603 px, so aspect ratio of 1.45447560507
The image you got with LO 7.4 is 4940x3396 px, so aspect ratio of 1.45465253239

The output image is out of scale and streched too
Comment 13 Buovjaga 2022-05-26 05:58:43 UTC
(In reply to Valerio Messina from comment #12)
> so seems the output image size changed from LO 7.2 to 7.4, and both are
> wrong.
> 
> Do you get the 10 mm page border in the resulting PNG?

I don't understand what you mean, so can't answer. You can test with 7.4 yourself: https://dev-builds.libreoffice.org/daily/master/current.html
Comment 14 Valerio Messina 2022-05-26 06:33:32 UTC
Created attachment 180393 [details]
expected export without 10 mm page border

expected export without 10 mm page border
Comment 15 Valerio Messina 2022-05-26 06:34:33 UTC
Created attachment 180394 [details]
expected export with 10 mm page border

expected export with 10 mm page border
Comment 16 Valerio Messina 2022-05-26 06:37:20 UTC
I attached the expected PNG export with and without the 10 mm page border (those are generated with GIMP, specifying both 300 dpi resolution and image size 320 or 300 mm).

The export you get with LO 7.4 is with or without the 10 mm page border?

I will try by myself on Linux and Win too
Comment 17 Valerio Messina 2022-05-26 16:43:58 UTC
I made some tests with a just installed

Version: 7.4.0.0.alpha1+ / LibreOffice Community
Build ID: fd45045cc3029b41c02a2634e6fe2e5456f716ad
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3
Locale: it-IT (it_IT.UTF-8); UI: en-US
Calc: threaded

on Debian 11/x86_64


On first run, LO is configured with this export settings default:
1) Dimensions unit: cm
2) Resolution: 37 pixel/cm
3) Compression: 6

I changed to:
1) Dimensions unit: mm
2) Resolution: 96 pixel/inch
3) Compression: 9


Then perform some extractions with:
. Modify resolution: 300 pixels/inch
. Modify dimensions, Width: 320 mm
. the Height is set by LO to 220.03 mm and width to 320.03 mm

Results:
- The output aspect ratio is the one of page, and not the one of the rectangle
- the output images is sized: 3786x2603 px, that at 300 dpi, has a size of 320.55x220.39 mm
- LO7.4 export to PNG the rectangle without the 10 mm page border (like LO7.2)
  and in contrast to export as PDF (but may be reasonable)

So the 300x200 mm source rectangle is stretched to 320.55x220.39 mm in exported PNG
This is out of scale of about 320/300=1.06 periodic,
and worse the image is still with the wrong aspect ratio like was with LO7.2
This is still wrong but better than LO7.2


As the 10mm border is always omitted in exported PNG, I repeated the tests with:
. Modify resolution: 300 pixels/inch
. Modify dimensions, Width: 300 mm
. the Height is set by LO to 206.26 mm while width remain to 300.00 mm

Results:
- The output aspect ratio is the one of page, and not the one of the rectangle
- the output images is sized: 3549x2440 px, that at 300 dpi, has a size of 300.48x206.59 mm

So the 300x200 mm source rectangle is stretched to 300.48x206.59 mm in exported PNG
this is out of scale of about 300.48/300=1.0016  on X asis, 0.5 mm error maybe acceptable, but
this is out of scale of about 206.59/200=1.03295 on Y asis, 6.59 mm error this is wrong.
So the image is still with the wrong aspect ratio:
original rectangle has 300/200=1.5 aspect ratio
exported rectangle has 300.48/206.59=1.454475 aspect ratio


Note 1: LO should export the drawing area (the 300x200 mm rectangle) keeping his aspect ratio,
and not use the one of the page (that include the 10 mm border).

Note 2: There are various approximation in LO compute for output pixels, that round the numbers in the wrong way too.
Maybe caused by the use of a float instead of a double in some variables.

Note 3: I cannot test on Win, as the only PC with Win I had access, is the company PC, but I cannot install an Alpha level application on it
Comment 18 Valerio Messina 2022-08-12 08:41:18 UTC Comment hidden (obsolete)
Comment 19 Buovjaga 2022-08-12 10:33:33 UTC
(In reply to Valerio Messina from comment #18)
> (In reply to Buovjaga from comment #13)
> 
> @Buovjaga
> can you please change the status from UNCONFIRMED?

Sorry, I did not have time to understand it.

I asked others to look at it in the QA chat and someone suggested that you could try an unstable build, which includes a new PNG exporter. As part of Google Summer of Code, PNG export is now handled by the libpng library. One way to test is to create an appimage: https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Automated_installation

Or do the manual way https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Manual_installation
Comment 20 Roman Kuznetsov 2022-08-12 11:55:47 UTC
(In reply to Buovjaga from comment #4)
> The dimensions I get for the exported image are 4940 x 3396. Not sure what
> else to comment. I don't think you are supposed to be using both Modify
> dimensions and resolution as they are radio buttons that exclude each other.
> 
> Arch Linux 64-bit
> Version: 7.4.0.0.alpha1+ / LibreOffice Community
> Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495
> CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb)
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 25 May 2022

The same here in latest LO Draw 7.5


Paris, could you please look at it and say us your opinion?
Comment 21 Paris Oplopoios 2022-08-12 12:32:02 UTC
(In reply to Roman Kuznetsov from comment #20)
> (In reply to Buovjaga from comment #4)
> > The dimensions I get for the exported image are 4940 x 3396. Not sure what
> > else to comment. I don't think you are supposed to be using both Modify
> > dimensions and resolution as they are radio buttons that exclude each other.
> > 
> > Arch Linux 64-bit
> > Version: 7.4.0.0.alpha1+ / LibreOffice Community
> > Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495
> > CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb)
> > Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> > Calc: threaded
> > Built on 25 May 2022
> 
> The same here in latest LO Draw 7.5
> 
> 
> Paris, could you please look at it and say us your opinion?

If I understand this bug correctly this shouldn't have anything to do with the png writer itself, but with the bitmap passed to the exporter when you export the .odg. Correct me if I'm wrong.

Also as Buovjaga said I don't think you should use modify resolution and modify dimensions together. If you make changes to modify resolution then select modify dimensions and make changes there, shouldn't the modify resolution changes be ignored? Can you reproduce this bug while using only one of the two?
Comment 22 Telesto 2022-08-12 12:49:56 UTC
Didn't read the whole bug report, but bug 150310 maybe related or interfering with the bug here.
Comment 23 Valerio Messina 2022-10-09 12:28:43 UTC
94 dpi = 94/25.4 = 3.7 px/mm
94 dpi = 94/2.54 = 37 px/cm
300 dpi = 300/25.4 = 11.811 px/mm
300 dpi = 300/2.54 = 118.11 px/cm
aspect ratio=Width/Height

same source drawing:
320x220 mm page     , aspect ratio=1.4545...
300x200 mm rectangle, aspect ratio=1.5

All test made on Debian 11 Bullseye 


I take the time to build the appImage from daily sources:

/opt/LibreOffice$ make_libreoffice_appimage.sh daily x86-64 N N N N Y

/opt/LibreOffice$ LibreOfficeDev-7.5.0.0.alpha0_2022-10-09-x86_64.AppImage


(tests 1-4 made setting size OR resolution)
1)
set size: 32x22 cm (or 320x220 mm)
resolution gray: 37 px/cm (or 3.7 px/mm)
==> PNG 1210x832 px, rectagle, aspect ratio=1.4543

2)
set resolution: 37 px/cm (or 3.7 px/mm)
==> PNG 1210x832 px, rectagle, aspect ratio=1.4543

3)
set resolution: 118 px/cm (or 11.811 px/mm)
gray size change to 102.54x70.61 mm
==> PNG 1210x832 px, rectagle, aspect ratio=1.4543

4)
set resolution: 300 dpi (or 11.811 px/mm)
gray size change to 102.28x70.33 mm
==> PNG 1210x832 px, rectagle, aspect ratio=1.4543

expected results:
32x22 cm @37 px/cm is 1184x814 px, page    , aspect ratio=1.4545...
30x20 cm @37 px/cm is 1110x740 px, rectagle, aspect ratio=1.5

-------------------------------------------------
(tests 5-7 made setting both resolution AND size)
5)
set resolution: 118 px/cm
gray size change to 102.28x70.33 mm
set size Width: 300 mm
Height resize to 206.27 mm (and not 200 mm)
==> PNG 3540x2434 px, rectagle, aspect ratio=1.454396

6)
set resolution: 300 dpi
gray size change to 102.28x70.33 mm
set size Width: 300 mm
Height resize to 206.26 mm (and not 200 mm)
==> PNG 3549x2440 px, rectagle, aspect ratio=1.4545

7)
set resolution: 300 dpi
set size Height: 200 mm
Width resize to 290.87 mm (and not 300 mm)
==> PNG 3441x2366 px, rectagle, aspect ratio=1.4544

expected results:
32x22 cm @118 px/cm is 3776x2596 px, page    , aspect ratio=1.4545...
30x20 cm @118 px/cm is 3540x2360 px, rectagle, aspect ratio=1.5

Comment:
1, 2, 3, 4) larger than expected on both WxH and aspect ratio is wrong
5) right Width, smaller that expected Height and so wrong aspect ratio
6) larger than expected on both WxH and aspect ratio is wrong
7) smaller that expected Width, larger than expected Height, wrong aspect ratio

So best result is get with method 5), setting both resolution and size Width,
at least one pixel size is right, but still got stretched PNG image

Repeated the test with a page with no page border, and the exported rectangle is perfect, like happen with LO7.2

To me seems in no way this bug is fixed with LO7.5a, neither is better that 7.2
The bug is still unconfirmed
Comment 24 Valerio Messina 2022-10-09 13:05:23 UTC
You insist on the fact that you have to select either only the size or only the resolution, but for the definition:
px = inch * dpi = mm * dpmm
to find out which pixel size to generate for the PNG, LibreOffice will always need two data: size and resolution.

In fact, when you create (or resize) an image in GIMP (but also with Inkscape, Scribus or other graphics programs), two quantities are always specified to define an image, pixel and DPI, or size mm and DPI (maybe one is set at default but changeable), so that the third is calculated with the formula above.

The fact that the two voices are in alternate with LO, can be a GUI bug itself.
Or perhaps the designer wanted to undergo that when changing the resolution, it means that the size must be kept by default to that of the page (or to the size of the area without border), but, for unknown reason, as now LO change that with an unknown logic.

If changing the resolution, LO would keep the output size to the size of the area without border, in the simplest case, it would not be necessary to set both.
In any case, in the most general case of export, both items can be specified by the user (with the dimension default to that of the area without edge).
Comment 25 Valerio Messina 2022-10-28 14:40:12 UTC
older version of LO (and current AOO) let select both quantities (size and resolution) at the same time in export dialog
Comment 26 Stéphane Guillou (stragu) 2024-06-05 15:24:31 UTC
Isn't this the same as bug 101106?
Comment 27 Telesto 2024-06-05 23:32:01 UTC
(In reply to Valerio Messina from comment #25)
> older version of LO (and current AOO) let select both quantities (size and
> resolution) at the same time in export dialog

Comment 24 and 25 are likely covered by bug 144195
Comment 28 Valerio Messina 2024-06-06 17:50:12 UTC
just tested on LO24.2.3.2

Setting 32x22 cm or 30x20 cm and 300 dpi I always got an image sized 4940x3396px
Both images miss the 1 cm border all around.

In the first case the 300x200 mm image is stretched to 320x220 mm with a resolution of 15.43 px/mm, and an aspect ratio of 1.4545 (right for 320x200 but the original is 300x200 with 1.5)

In the second image the 300x200 mm image is stretched to 300x206.27 mm with a resolution of 16.46 px/mm, and an aspect ratio of 1.4545 (right is 1.5)

Tomorrow will do more tests
Comment 29 Valerio Messina 2024-06-07 00:23:06 UTC
In bug 101106 the reporter ask to have the Page border in exported PNG like happen with JPEG and PDF.
This is a nice feature that I want too, better activable by the user via a check button.

While in this bug I'm asking to have right sized (both pixel size and aspect ratio) exported PNG. This to be used in CAD (mechanical and architecture) applications where right scale of drawings must be preserved
Comment 30 QA Administrators 2024-06-07 03:16:25 UTC Comment hidden (obsolete)
Comment 31 Valerio Messina 2024-06-07 08:43:43 UTC
I made a test setting resolution to 102 px/inch=40px/cm

In this mode the exported PNG still miss the page border so is only the gray rectangle.

The X size is right to 1210 px and 299.9 mm.
Anyway the Y size is still stretched to 832 px and 206.2 mm, so aspect ratio is damaged

Note: 102 px/inch is an approximation of 1024/10 px/mm so 2^10/10, this is a wrong rounding somewhere in the code
Comment 32 Valerio Messina 2024-06-07 08:44:58 UTC
why the bug is still unconfirmed?
Comment 33 Buovjaga 2024-06-07 08:50:06 UTC
(In reply to Valerio Messina from comment #32)
> why the bug is still unconfirmed?

Because bug 144195 is already confirmed. Do you think it does not cover what you need?
Comment 34 Valerio Messina 2024-06-07 09:00:19 UTC
will read the comments there
Comment 35 Valerio Messina 2024-06-07 09:28:08 UTC
I re-made test with LO7.5.9.2.
The export there is better.

The page border is still removed.

But with the same settings 300 dpi and 300x206 mm, it generate a PNG sized 3549x2440px so 300.48x206.59mm, so at least the X asis in quite good, but the y is stretched and so aspect ratio is damaged.

LO24.2 generate 4940x3396px @418 dpi, GIMP say it is sized 300.03x206.26mm,
so the same stratching on Y axis, and more dpi than requested on both axis

I do now know from which version was changed the behaviour, there should be a regression here
Comment 36 Buovjaga 2024-06-07 16:57:36 UTC
(In reply to Valerio Messina from comment #35)
> I re-made test with LO7.5.9.2.
> The export there is better.
> 
> The page border is still removed.
> 
> But with the same settings 300 dpi and 300x206 mm, it generate a PNG sized
> 3549x2440px so 300.48x206.59mm, so at least the X asis in quite good, but
> the y is stretched and so aspect ratio is damaged.
> 
> LO24.2 generate 4940x3396px @418 dpi, GIMP say it is sized 300.03x206.26mm,
> so the same stratching on Y axis, and more dpi than requested on both axis

With attachment 174616 [details], that is not what we see in the export dialog. Both with LibreOffice 7.5 and 24.2, if I set resolution to 300 pixels/inch and click on the dropdown so it refreshes the dialog, I see 102.28x70.33 mm in the Dimensions fields. The exported file is 1210x832 px.

With dimensions set to 300x206 mm, the exported file is 1134x780 px.
Comment 37 Valerio Messina 2024-06-07 17:23:07 UTC
I got the results you just post if I select only the resolution OR the size.
In the bug Description I put those procedure to reproduce the bug:

knowing that the exported PNG does not have the border, one can try to selecting:
5. Modify resolution: 300 pixels/inch
6. Modify dimensions, Width: 30 cm
7. the Height is set to 20.63 cm (so form factor is page not area rectangle)
but the exported PNG has wrong form factor, so is worse

The point is that LO (and the user) need to know both size (in mm) and resolution (in dpi) to calculate the size in pixel.
If you select only one of the two, you do not control the other quantity, LO assume a default.

The default LO is using for the other input is:
1) in case of resolution set by the user, the default size in mm is not the page size in mm
2) in case of size set by the user is 96 dpi for display output and right for print output)

So the resultant image size in pixel is even more random as your test show
Comment 38 Buovjaga 2024-06-07 17:38:18 UTC
(In reply to Valerio Messina from comment #37)
> I got the results you just post if I select only the resolution OR the size.

Reading bug 155889 and bug 151649, I finally understand what is the issue. I will close as duplicate of bug 144195 as this is clearly so.

*** This bug has been marked as a duplicate of bug 144195 ***