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.
Created attachment 45709 [details] screenshot of the problematic file
Created attachment 45711 [details] png version of the embedded file: no tearing lines visible
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
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.
Reproducible with LibreOffice 4.2.5 and 4.3.0.2 on Debian x86_64
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
This bug is still present in LibreOffice 5.0.0.5.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
The tif image is still not displayed correctly in LibreOffice 5.1.2.2.0. It displays fine in Calligra 2.9.
Created attachment 127457 [details] screenshot from LibreOffice 5.1 Still broken.
Created attachment 127458 [details] rendering in calligra: correct
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.
Created attachment 134997 [details] Gimp Message Could it be we're using a TIFF library that doesn't support 16bit channels?
Changed title and component since this happens to all kinds of documents. Tested with Writer and Calc too.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
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.
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).
*** Bug 74331 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/c/core/+/133108 in reviewing may help here.
Created attachment 179636 [details] comparison with the patch in place and without it
(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 ***
When testing bug, duplicates should also be tested.
I don't see these fixed in 7.4+ bibisect repo 2 days old which contains 49ee1c889665c3539fa9a1c99a865a42fc08ee97 but not dc97aac5cdfa3789d4e71e9d92df6e7e68802825.
(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.
Julien thanks for testing. IIUC this should be reopened? Or just a duplicate?
(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.