Bug 36300 - 16bit depth TIFF images render badly
Summary: 16bit depth TIFF images render badly
Status: RESOLVED DUPLICATE of bug 142151
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Images-TIFF
  Show dependency treegraph
 
Reported: 2011-04-16 06:27 UTC by Jos van den Oever
Modified: 2022-04-21 07:57 UTC (History)
10 users (show)

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


Attachments
OpenDocument file that shows the problem (551.28 KB, application/vnd.oasis.opendocument.presentation)
2011-04-16 06:27 UTC, Jos van den Oever
Details
screenshot of the problematic file (173.07 KB, image/png)
2011-04-16 06:27 UTC, Jos van den Oever
Details
png version of the embedded file: no tearing lines visible (524.27 KB, image/png)
2011-04-16 06:29 UTC, Jos van den Oever
Details
screenshot from LibreOffice 5.1 (337.72 KB, image/png)
2016-09-20 11:20 UTC, Jos van den Oever
Details
rendering in calligra: correct (307.71 KB, image/png)
2016-09-20 11:21 UTC, Jos van den Oever
Details
Logo TIFF Breaks in When added to any LO Document (135.87 KB, image/tiff)
2017-07-30 10:11 UTC, Ahmad Harthi
Details
Gimp Message (33.31 KB, image/png)
2017-07-30 10:13 UTC, Ahmad Harthi
Details
attachment 45708 micrograph TIFF extracted but renders just one color Band (252.18 KB, image/png)
2019-06-28 20:04 UTC, V Stuart Foote
Details
test kit 16bit TIFF of attachements converted to 8bit depth TIFFs (924.06 KB, application/x-zip-compressed)
2019-12-31 16:01 UTC, V Stuart Foote
Details
comparison with the patch in place and without it (676.06 KB, image/png)
2022-04-18 10:11 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jos van den Oever 2011-04-16 06:27:18 UTC
Created attachment 45708 [details]
OpenDocument file that shows the problem

When viewing a pptx file with embedded tiff images, the rendering is wrong. Horizontal lines show from top to bottom in the images.
Comment 1 Jos van den Oever 2011-04-16 06:27:54 UTC
Created attachment 45709 [details]
screenshot of the problematic file
Comment 2 Jos van den Oever 2011-04-16 06:29:41 UTC
Created attachment 45711 [details]
png version of the embedded file: no tearing lines visible
Comment 3 Björn Michaelsen 2011-12-23 12:05:16 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:03:16 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:04:11 UTC Comment hidden (obsolete)
Comment 6 Florian Reisinger 2012-08-14 14:08:43 UTC Comment hidden (obsolete)
Comment 7 Florian Reisinger 2012-08-14 14:10:45 UTC Comment hidden (obsolete)
Comment 8 sasha.libreoffice 2012-08-31 09:46:23 UTC
reproduced in 3.3.4 (wrong colors) and 3.5.5, 3.6.1 (vertical lines) on Fedora 64 bit
Compared with extracted from odp file picture. If extract picture and insert into new presentation, then picture looks different, but still wrong.
Comment 9 Alexandr 2014-07-16 07:27:30 UTC
Reproducible with LibreOffice 4.2.5 and 4.3.0.2 on Debian x86_64
Comment 10 tommy27 2014-07-18 19:50:24 UTC
reproducible as well under Win7x64 using 4.4.0.0.alpha0+
Build ID: abc28ffc04067eb24840fbf564c311aaee10f84d
TinderBox: Win-x86@42, Branch:master, Time: 2014-07-15_07:20:05
Comment 11 QA Administrators 2015-09-04 02:49:01 UTC Comment hidden (obsolete)
Comment 12 Jos van den Oever 2015-09-04 06:34:35 UTC
This bug is still present in LibreOffice 5.0.0.5.
Comment 13 QA Administrators 2016-09-20 10:28:37 UTC Comment hidden (obsolete)
Comment 14 Jos van den Oever 2016-09-20 11:19:59 UTC
The tif image is still not displayed correctly in LibreOffice 5.1.2.2.0.
It displays fine in Calligra 2.9.
Comment 15 Jos van den Oever 2016-09-20 11:20:46 UTC
Created attachment 127457 [details]
screenshot from LibreOffice 5.1

Still broken.
Comment 16 Jos van den Oever 2016-09-20 11:21:21 UTC
Created attachment 127458 [details]
rendering in calligra: correct
Comment 17 Ahmad Harthi 2017-07-30 10:11:22 UTC
Created attachment 134996 [details]
Logo TIFF Breaks in When added to any LO Document

This TIFF doesn't render in LO correctly, opening it in Gimp will show the message attached next.
Comment 18 Ahmad Harthi 2017-07-30 10:13:27 UTC
Created attachment 134997 [details]
Gimp Message

Could it be we're using a TIFF library that doesn't support 16bit channels?
Comment 19 Ahmad Harthi 2017-07-30 10:18:34 UTC
Changed title and component since this happens to all kinds of documents.

Tested with Writer and Calc too.
Comment 20 QA Administrators 2018-10-06 02:50:50 UTC Comment hidden (obsolete)
Comment 21 V Stuart Foote 2019-06-28 20:04:34 UTC
Created attachment 152460 [details]
attachment 45708 [details] micrograph TIFF extracted but renders just one color Band

Working with the extracted TIFF from Pictures directory of attachment 45708 [details], or with TIFF of attachment 134996 [details] no longer shows banding--but the TIFF look to now be rendering just one band of sRGB color (Red).

Version: 6.2.4.1 (x64)
Build ID: 170a9c04e0ad25cd937fc7a913bb06bf8c75c11d
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 4808ae1c73597726c89936f5b9cb3f11c9a4a7bf
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-25_01:14:33
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 22 V Stuart Foote 2019-12-31 16:01:11 UTC
Created attachment 156863 [details]
test kit 16bit TIFF of attachements converted to 8bit depth TIFFs

Converting the 16bit TIFF to 8bit depth with ImageMagick's convert tool allows the TIFF to render correctly in LibreOffice.

So looks to be an issue with lib support for 16bit RGB TIFFs.
Comment 23 Julien Nabet 2020-01-01 10:51:02 UTC
Original odp file contains a tiff with these characteristics:
TIFF Directory at offset 0x1f02e0 (2032352)
  Subfile Type: (0 = 0x0)
  Image Width: 582 Image Length: 582
  Resolution: 72, 72 pixels/inch
  Bits/Sample: 16
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Rows/Strip: 2
  Planar Configuration: single image plane
(from tiffinfo 4.1.0)

Looking at download.lst, it seems LO doesn't use any specific lib to deal with tiff format. Instead, LO has some files in filter/source/graphicfilter/itiff.
Tiff is just a container format which can contain several formats (see https://en.wikipedia.org/wiki/TIFF).
Comment 24 Timur 2021-05-05 10:29:52 UTC
*** Bug 74331 has been marked as a duplicate of this bug. ***
Comment 25 Julien Nabet 2022-04-18 09:49:54 UTC
https://gerrit.libreoffice.org/c/core/+/133108 in reviewing may help here.
Comment 26 Xisco Faulí 2022-04-18 10:11:14 UTC
Created attachment 179636 [details]
comparison with the patch in place and without it
Comment 27 Xisco Faulí 2022-04-18 10:21:42 UTC
(In reply to Julien Nabet from comment #25)
> https://gerrit.libreoffice.org/c/core/+/133108 in reviewing may help here.

I think we can close this issue as duplicated of bug 142151.
Thanks for fixing it

*** This bug has been marked as a duplicate of bug 142151 ***
Comment 28 Timur 2022-04-20 14:13:31 UTC
When testing bug, duplicates should also be tested.
Comment 29 Timur 2022-04-20 14:24:27 UTC
I don't see these fixed in 7.4+ bibisect repo 2 days old which contains 49ee1c889665c3539fa9a1c99a865a42fc08ee97 but not dc97aac5cdfa3789d4e71e9d92df6e7e68802825.
Comment 30 Julien Nabet 2022-04-20 17:28:03 UTC
(In reply to Timur from comment #29)
> I don't see these fixed in 7.4+ bibisect repo 2 days old which contains
> 49ee1c889665c3539fa9a1c99a865a42fc08ee97 but not
> dc97aac5cdfa3789d4e71e9d92df6e7e68802825.

The first commit is the fix at least for tdf#142151, here are the 12 first lines from tiffinfo:
TIFF Directory at offset 0x8 (8)
  Image Width: 138 Image Length: 338
  Resolution: 100, 100 pixels/inch
  Bits/Sample: 16
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 128
  Planar Configuration: single image plane

and for the first file attached on the bugtracker, if I unzip the odp file, there's Pictures/100000000000024600000246B37CF7E6.tif
Here's the result of tiffinfo:
TIFF Directory at offset 0x2032352 (1f02e0)
  Subfile Type: (0 = 0x0)
  Image Width: 582 Image Length: 582
  Resolution: 72, 72 pixels/inch
  Bits/Sample: 16
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Rows/Strip: 2
  Planar Configuration: single image plane

so again 16 bits with "RGB Color"


Now, about "Logo TIFF Breaks in When added to any LO Document" attachment, Gimp and LO with fix display the same except the background which is transparent in Gimp.
tiffinfo gives:
TIFFReadDirectory: Warning, Unknown field with tag 37724 (0x935c) encountered.
TIFF Directory at offset 0x8 (8)
  Subfile Type: (0 = 0x0)
  Image Width: 144 Image Length: 60
  Resolution: 72, 72 pixels/inch
  Bits/Sample: 16
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Extra Samples: 1<assoc-alpha>
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 4
  Rows/Strip: 60
  Planar Configuration: single image plane

Now for tdf#74331, LO (even with the fix) displays it as black rectangle.
tiffinfo gives:
TIFF Directory at offset 0x8 (8)
  Image Width: 200 Image Length: 200
  Bits/Sample: 16
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 200
  Planar Configuration: single image plane

So yes it's 16 bits, but we're in the case "min-is-black" not RGB.


Just quoting https://en.wikipedia.org/wiki/TIFF:
"TIFF is a complex format, defining many tags of which typically only a few are used in each file. This led to implementations supporting very varying subsets of the format, a situation that gave rise to the joke that TIFF stands for Thousands of Incompatible File Formats."
Indeed! :-)

That's why ideally, we should use an external lib (eg: libtiff) do deal with tiff images BUT it requires lots of work.
Comment 31 Timur 2022-04-21 07:21:21 UTC
Julien thanks for testing. IIUC this should be reopened? Or just a duplicate?
Comment 32 Julien Nabet 2022-04-21 07:57:27 UTC
(In reply to Timur from comment #31)
> Julien thanks for testing. IIUC this should be reopened? Or just a duplicate?

It depends either this bugtracker gathers all 16 bits TIFF files pbs (and tdf#74331 is a duplicate) or we distinguish subcases (by taking into account Photometric Interpretation) and we may reopen tdf#74331.

I've got no strong opinion here.