Bug 98743 - TIFF EXPORT saves weird image: in different x-y resolution and dimensions
Summary: TIFF EXPORT saves weird image: in different x-y resolution and dimensions
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Graphics-Export Images-TIFF
  Show dependency treegraph
 
Reported: 2016-03-18 12:09 UTC by sikiratou86
Modified: 2022-06-14 09:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
fabric pattern for settee and armchairs (22.72 KB, application/vnd.oasis.opendocument.graphics)
2016-03-18 21:17 UTC, sikiratou86
Details
original bug report's file, exported as a tif from paint.net (276.35 KB, image/tiff)
2022-06-14 09:42 UTC, xordevoreaux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sikiratou86 2016-03-18 12:09:03 UTC
LibreOffice 5.0.4.2 - Draw

If Image is exported to TIFF the resulting image has resolution x: 0,017 pixel/inch and y: 0,167 pixel/inch.
Resolution should be 96 pixel/inch for both, x and y.

Also, the amount of pixels of the image drops to one third, e.g. from 1000 to 350.
-----
In LibreOffice 4.3 - Draw it has always been correct.
Comment 1 Usama 2016-03-18 16:27:10 UTC Comment hidden (obsolete)
Comment 2 sikiratou86 2016-03-18 21:17:55 UTC
Created attachment 123704 [details]
fabric pattern for settee and armchairs

Do export the attached draw-file as TIFF and open the imagefile in GIMP, par example and check the x/y-resolution and amount of x/y-pixels compared to an export to PNG of the same draw-file.

If I do export to PNG then the background of the pattern is missing. So I cannot use PNG. JPEG makes the quality worse. It's a pity.

Remark: I do need the export to TIFF for splitting the whole image into 6 sheets of A4 size for printing. It is impossible to print this draw-file directly from LibreOffice.
Comment 3 MM 2016-03-19 10:12:55 UTC
Confirmed with ubuntu 14.04 x64.

Output to tiff is 2048*223, while output to png is 5557*605.

> If I do export to PNG then the background of the pattern is missing. So I cannot use PNG.

You can fix that by turning 'save transparency' in the png options off.
Comment 4 Usama 2016-03-19 11:19:40 UTC
Confirm it on: Version: 5.2.0.0.alpha0+
Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35
Locale: en-US (en_US) OS: Windows 7 Enterprise

If image saved using tiff it would be hard to read.
Comment 5 sikiratou86 2016-03-23 11:03:41 UTC
If I export a draw-file to PNG, BMP or JPEG then a window pops up "PNG options" where dimension, resolution, compression, modus an so on can be changed.

There is no window "TIFF option" when export to TIFF is done. LibreOffice does this quietly and the result is weird, i.e. useless.

(In reply to Usama from comment #4)
> If image saved using tiff it would be hard to read.
Do check the resolution: It is x: 0,017 pixel/inch and y: 0,167 pixel/inch.
Comment 6 QA Administrators 2017-05-22 13:18:57 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2017-07-13 10:56:54 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 8 QA Administrators 2018-07-25 02:40:59 UTC Comment hidden (obsolete)
Comment 9 Andrea Giudiceandrea 2019-11-30 23:11:24 UTC
Still an issue in 6.3.3.2 on Windows 7 64 bit.

There is no "TIFF Options" windows when exporting in TIFF format from Draw, so it's impossible to set Width/Height/Resolution of the exported image.

Moreover, in the exported TIFF image file the x and y resolution parameters are both set to very weird values.
Comment 10 raal 2019-12-08 08:30:11 UTC
LO 41max oldest- resolution 0,0172414 × 0,166667 ppi. Is it really regression?
Comment 11 Andrea Giudiceandrea 2019-12-15 10:54:25 UTC
The bug reporter wrote that the tiff files exported by LibreOffice Draw 4.3 were correct.
Comment 12 Buovjaga 2020-06-08 15:37:17 UTC
Bibisect request is bogus. The resolution is always 2048x223 or 2048x302 pixels when tested with older versions, Linux bibisect repos 43all (oldest, 3.5.0), 41max, 43max, 44max, 50max.
Comment 13 sdc.blanco 2020-10-06 14:19:32 UTC
(In reply to Andrea Giudiceandrea from comment #9)
> There is no "TIFF Options" windows when exporting in TIFF format from Draw,
> so it's impossible to set Width/Height/Resolution of the exported image.
Workaround:  1. Export to PNG/JPG (setting values). 2. Open in image-editing program that can save as TIFF.
Comment 14 xordevoreaux 2021-04-10 13:54:41 UTC
(In reply to sdc.blanco from comment #13)
> (In reply to Andrea Giudiceandrea from comment #9)
> > There is no "TIFF Options" windows when exporting in TIFF format from Draw,
> > so it's impossible to set Width/Height/Resolution of the exported image.
> Workaround:  1. Export to PNG/JPG (setting values). 2. Open in image-editing
> program that can save as TIFF.

Which negates the entire point of having a TIFF export option at all in LO draw.

This bug is similar to mine which no one's ever looked at 

https://bugs.documentfoundation.org/show_bug.cgi?id=139161
Comment 15 sikiratou86 2022-03-15 16:29:21 UTC
(In reply to sdc.blanco from comment #13)
> Workaround:  1. Export to PNG/JPG (setting values). 2. Open in image-editing
> program that can save as TIFF.
Sorry, this in no workaround, because with PNG the background of the pattern is missing and JPG makes the the quality worse.
(see Comment #2 2016-03-18 21:17:55 UTC)

Six years later, there is still no "TIFF Options" window when exporting your work from Draw into TIFF format. Still, the amount of pixels of the image drops to one third, e.g. from 1000 to 350.

Version: 7.2.3.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.utf8); UI: de-DE
Calc: threaded
Comment 16 Julien Nabet 2022-06-10 20:42:03 UTC
I submitted a patch to just indicate that we use 96 DPI when exporting in TIFF.
https://gerrit.libreoffice.org/c/core/+/135631

As I indicated in the comment:
"Next step would be to use the dialog box for compressing options (like for png or jpg).
But for this I think we should take benefit of external lib "libtiff" since we now use it now for import."
but this part would take more time.
Comment 17 Julien Nabet 2022-06-11 19:33:18 UTC
About "dialog box for compressing options", there's already tdf#92944 about this.
Comment 18 Commit Notification 2022-06-11 19:35:49 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/988285410f8883ad49f32c4b804c4f5bd14569d0

tdf#98743: TIFF export uses 96dpi by default

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 xordevoreaux 2022-06-12 20:03:18 UTC
Not exactly sure what the test is supposed to be here, but in using this:

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 988285410f8883ad49f32c4b804c4f5bd14569d0
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

The original bug attachment, exported as TIFF, was 2048x233
Comment 20 xordevoreaux 2022-06-12 20:08:20 UTC
Probably a distraction in regard to the current bug, but saving out the attachment in 7.5 LO produced a 477k file, while exporting using paint.net using default TIFF settings (auto-detect depth) the file size was 277k.  Same dimensions.
Comment 21 Julien Nabet 2022-06-13 18:30:11 UTC
xordevoreaux: LO Debian package 7.3.4.1 (so without the patch) exports a file of 453302 bytes with these info (from tiffdump):
Magic: 0x4d4d <big-endian> Version: 0x2a <ClassicTIFF>
Directory 0: offset 8 (0x8) next 0 (0)
SubFileType (254) LONG (4) 1<2>
ImageWidth (256) LONG (4) 1<2048>
ImageLength (257) LONG (4) 1<223>
BitsPerSample (258) SHORT (3) 1<8>
Compression (259) SHORT (3) 1<5>
Photometric (262) SHORT (3) 1<2>
StripOffsets (273) LONG (4) 1<198>
SamplesPerPixel (277) SHORT (3) 1<3>
RowsPerStrip (278) LONG (4) 1<223>
StripByteCounts (279) LONG (4) 1<453104>
XResolution (282) RATIONAL (5) 1<0.0172414>
YResolution (283) RATIONAL (5) 1<0.166667>
PlanarConfig (284) SHORT (3) 1<1>
ResolutionUnit (296) SHORT (3) 1<2>

with master sources updated today, it exports a file of 453302 bytes too.
Magic: 0x4d4d <big-endian> Version: 0x2a <ClassicTIFF>
Directory 0: offset 8 (0x8) next 0 (0)
SubFileType (254) LONG (4) 1<2>
ImageWidth (256) LONG (4) 1<2048>
ImageLength (257) LONG (4) 1<223>
BitsPerSample (258) SHORT (3) 1<8>
Compression (259) SHORT (3) 1<5>
Photometric (262) SHORT (3) 1<2>
StripOffsets (273) LONG (4) 1<198>
SamplesPerPixel (277) SHORT (3) 1<3>
RowsPerStrip (278) LONG (4) 1<223>
StripByteCounts (279) LONG (4) 1<453104>
XResolution (282) RATIONAL (5) 1<96>
YResolution (283) RATIONAL (5) 1<96>
PlanarConfig (284) SHORT (3) 1<1>
ResolutionUnit (296) SHORT (3) 1<2>

So imageWidthxImageLength is 2048x223 in both cases.
The only thing changed here is XResolution and YResolution as expected.

About the size of the file, you can attach here since it depends on the options used by Paint but perhaps it would need a brand new bugtracker.
Comment 22 Commit Notification 2022-06-13 19:14:59 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2b7979d781b9e46161dcdfcab0e258af5e0b12b6

Revert "tdf#98743: TIFF export uses 96dpi by default"

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 23 Julien Nabet 2022-06-13 19:16:58 UTC
I reverted the patch since it doesn't work with the file attached.
It's not normal that the nb of pixels drops.
Comment 24 xordevoreaux 2022-06-14 09:42:52 UTC
Created attachment 180750 [details]
original bug report's file, exported as a tif from paint.net

Paint.net uses three parameters with TIF exports:
a dithering level (1 to 8)
bit depth (1, 4, 8, 24, 32)
and a quantization algorithm dependent on selected bit depth (Median Cut, Octree)

With me using paint.net's auto-detect setting, paint.net selected Octree for the algorithm and a dithering level of 7 when re-saving the original bug reporter's attachment as a TIF file.

Paint.net forces use of the octree quantization algorithm for bit depths 24 and 32, and the user is given the choice between octree and median cut for depths 1, 4, and 8, but does not report on the UI what the actual bit depth was if set to auto-detect (but because Octree was defaulted, the auto-detected bit depth had to be either 24 or 32).

Wild guess here, perhaps the engine you're using for the TIF export is not reporting everything it's implementing during the export process and is locked to a particular export format, or is using an optimization algorithm other than the one paint.net is using (which wouldn't of itself be a bug, just a different approaching to performing the export).

I did not see any visual difference between the original and paint.net's export, so I'm not sure what information got lost between the original's 417K and paint.net's 277K export.