Created attachment 84247 [details] grayscale TIFF image that is not imported correctly Problem description: Steps to reproduce: 1. Choose Insert - Picture - From File. 2. Select the attached sample TIFF file. Current behavior: A white area is inserted as a picture. Expected behavior: Picture of black circle should be inserted. The TIFF file was created in GIMP by using conversion to grayscale, rotation and crop tool. In case of color image or when no rotation was performed, the image is inserted correctly. It does not work in version 3.6 or newer, 3.5 is OK. Operating System: Windows 7 Version: 3.6.0.4 release Last worked in: 3.5 all versions
Thank you for your bug report, I can reproduce this bug running LibreOffice Version: 4.1.1.1 Build ID: a990db030b8125868501634ff662be1d89d0868 on Mac osx 10.8.4.
same problem with just opening the file in Draw -> not a Writer bug bibsect says: 61d78aca81f08ac3a0f9eb65799d04d56fbad312..0bbf79005a697c6781047c01f05eb660836a18e1 reverting this makes it work: commit 6c719c1585eb1a2dbab86cc73ff871da41765981 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Fri Apr 20 09:21:25 2012 +0100 Related: n#615223 local nbyte1 should have been class-level nByte1
Hmph, so (without debugging it properly yet) IIRC we had a valgrind warning on an initialized nByte1, so that was presumably in TIFFReader::ConvertScanline where there is only one use of nByte1 outside of the initial construction so I guess that suggests that the ancient... if ( nByte1 == 'I' ) pt++; where nByte1 was a random number and never happened was accidentally the right thing to do all along. I wonder if it wanted to set things up to do some byteswapping foo, but I don't see a need for any there ? So, best it probably to revert my fix and add removing the use of the then uninited nByte1.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=98a61a2ae109f3d72940274ceafcf3e84d79aa0b Resolves: fdo#68275 Grayscale TIFF is imported as white The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=27c0a5a0567f617d9899e000e6dcf4e8de681ebc&h=libreoffice-4-1 Resolves: fdo#68275 Grayscale TIFF is imported as white It will be available in LibreOffice 4.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=69480705d9785296888a5543781d963bdab39a1c&h=libreoffice-4-0 Resolves: fdo#68275 Grayscale TIFF is imported as white It will be available in LibreOffice 4.0.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Checked in: 4.0 (Build ID: 69480705d9785296888a5543781d963bdab39a1) 4.1 (Build ID: d422eeed14f34e8595f795135be847fe5b6c555) master (Build ID: 6aac349140436a40cfbe84e3fce61a8dc7be4b3f) Everything works, marking as verified. Thank you for the quick fix!