Created attachment 68796 [details] Attached: TIFF image LibreOffice/Linux is not able to insert the attached TIFF image in a Writer or Impress document. Error message: "Unknown graphic format". The TIFF is a 1-bit Group-4-compressed TIFF image produced with GIMP. tiffinfo says: TIFF Directory at offset 0x2f1c (12060) Subfile Type: (0 = 0x0) Image Width: 3156 Image Length: 1844 Resolution: 600, 600 pixels/inch Bits/Sample: 1 Compression Scheme: CCITT Group 4 Photometric Interpretation: min-is-white Orientation: row 0 top, col 0 lhs Samples/Pixel: 1 Rows/Strip: 64 Planar Configuration: single image plane Tested with LO 3.5.4.2 and 3.6.2.2 under Ubuntu 12.04 (64 and 32 bit). Other 1-bit TIFFs work, for example one written by ImageMagick with tiffinfo TIFF Directory at offset 0x42fa (17146) Image Width: 500 Image Length: 375 Resolution: 72, 72 pixels/inch Bits/Sample: 1 Compression Scheme: CCITT Group 4 Photometric Interpretation: min-is-white FillOrder: msb-to-lsb Orientation: row 0 top, col 0 lhs Samples/Pixel: 1 Rows/Strip: 375 Planar Configuration: single image plane Page Number: 0-1
Confirmed with: LO 4.0.2.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Error message: "Unknown graphic format". File is viewable and can be inserted in Word or Powerpoint 2010.
confirmed in 4.0.2.2 Linux
Created attachment 93187 [details] a bt at the moment bStatus gets sal_False Bt retrieved on pc Debian x86-64 with master sources updated yesterday
Caolán: I runned a gdb session and retrieved a backtrace with master sources updated yesterday. Any idea what is wrong here? The tiff can be read with Doc displayer (Debian testing)
There's a gadzillion tiff extensions and features and we don't implement them all (yet). I'd *guess* we haven't implemented CCITT Group 4 compression.
Is it me or this feature have been implemented in LO 4.2.4.2 ? I tried and LO succeed to load a Group 4 TIF. There's small issue with the rendering but no critical failure.
Sorry for the noise. The image that I tested worked quite well with Group 4 attribute but the original enclosed image still unreadable.
** 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 (4.4.1 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-07-18
Created attachment 117329 [details] TIFF image loaded in Writer 5.0.0 RC3
Now there is no error message and the TIFF is loaded, however it is still not rendered correctly - see the screenshot from Writer. Tested in 4.4.2, 5.0.0 RC3 and recent master with the same result (OS: Kubuntu 15.04).
** 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 same behaviour as above - the image is loaded, but rendered incorrectly - observed in 5.2.1 and current master (Kubuntu 16.04).
Confirmed with: Version: 5.3.0.0.alpha1+ Build ID: b223028d65d24ffcd8e27974c29c2744a5df6227 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-16_22:50:22 Locale: nl-NL (nl_NL); Calc: CL When drag & drop & with Insert --> Image. It works when I open c.q copy the image from IrfanView and paste it in Writer.
** 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
The incorrect rendering of the image persists in: Version: 6.0.0.0.alpha0+ Build ID: 141fe1c5e7fbf67a083b34e49e19b6ea78a0eb2b
*** Bug 91461 has been marked as a duplicate of this bug. ***
Giving a new try here, I saw that LO enters CCIDecompressor::Read2DScanlineData. It's expected since Group 4 uses 2D. But on several lines (which corresponds about the number of garbage lines), it failed to read "n2DMode" value. See https://opengrok.libreoffice.org/xref/core/vcl/source/filter/itiff/ccidecom.cxx?r=946b17b4#1014 Taking a look at CCIDecompressor::ReadCodeAndDecode, the only case where m_bStatus is false is when nCodeBits = 0 and it happens when the nCode isn't in an initialized area of "pLookUp" (in our case m_p2DModeLookUp). Now the main pb is to find doc about CCITT group 4 for tiff. TIFF specs can be found here: https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf, the 2 related sections are: - Section 10: Modified Huffman Compression - Section 11: CCITT Bilevel Encodings Also found https://www.itu.int/rec/dologin_pub.asp?lang=f&id=T-REC-T.6-198811-I!!PDF-E&type=items which at least explains the table CCI2DModeTable (see https://opengrok.libreoffice.org/xref/core/vcl/source/filter/itiff/ccidecom.cxx?r=946b17b4#266). Now is LO decode process is ok but the tiff is not standard (however no pb to open it on Gimp), is the process ok with just something lacking or is completely ko (but in this case the whole image would be garbage)?
I took a look at what was one in libtiff or in https://github.com/openjdk/jdk, class src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFaxDecompressor.java, they don't search about n2dMode by just reading 10 bits but search about a0, a1, a2, b1, b2. Just wonder where the author found this way to search n2dmode...
Caolán: any idea about how to keep on investigation or whom to ping?
I've committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/22b50f1937de67e4ad9e692d6964aa5b8d33af7a use libtiff for tiff import It will be available in 7.4.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.
I confirm it works, very good (and quick!) job Caolán! :-)