Version: 0.6.0 (using KDE KDE 3.5.5) OS: Linux The attached TIFF image is not loaded correctly by ShowFoto. It displays two small versions of the correct image in the upper left corner, the rest of the image is black. The image loads fine in Krita and CinePaint.
Created attachment 21309 [details] Testcase TIFF image
Created attachment 21423 [details] another fail case Here is a similar case which cause SF shows four "thumbnails" instead of the image.
Marcel, Sound like another problem with DImg::TIFFLoader ? Gilles Caulier
Dik, This report still valid with Showfoto 0.7.0 ? Gilles Caulier
I can confirm with recent version. This is certainly a problem with the Tiffloader. At a quick glance I could not find where these photos are different from other TIFFs, more debugging is needed.
I can confirm the bug in 0.7.0 as well. Four thumbnails of the image are shown at the top of the image, the remaining part is black.
I think, I have found (and solved) the bug. According to tiffloader.cpp digikam only knows about TIFF with three or four samples per pixel. A greyscale image, as one can confirm easily using "identify -verbose" has only one sample per pixel. The word in the strip provided by libtiff has thus to be written in all three channels. I've written a small patch providing the additional routines. But beware, the PPC for BigEndian is probably still faulty, as I am not experienced enough to deal with Big-/LittleEndian properly. After applying the patch, thumbnails and previews are generated properly. Also Showfoto loads and displays the pictures as it ought to. The only problem I encountered so far is that the image viewer for the previews cannot rotate the images...Maybe someone knows more about this than I. But get to the facts, here is the patch as produced by svn diff > my.patch Max, who know can also use digikam for the 16bit greyscale scans of his slides. --------------------------------------------------------------------------- Index: tiffloader.cpp =================================================================== --- tiffloader.cpp (revision 813472) +++ tiffloader.cpp (working copy) @@ -262,9 +262,10 @@ ushort *dataPtr = (ushort*)(data + offset); ushort *p; - // tiff data is read as BGR or ABGR - if (samples_per_pixel == 3) + // tiff data is read as BGR or ABGR or Greyscale + + if (samples_per_pixel == 3) // BGR { for (int i=0; i < bytesRead/6; i++) { @@ -291,8 +292,35 @@ offset += bytesRead/6 * 8; } - else - { + else + if (samples_per_pixel == 1) // Greyscale pictures only have _one_ sample per pixel + { + for (int i=0; i < bytesRead/2; i++) // We have to read two bytes for one pixel + { + p = dataPtr; + + // See B.K.O #148037 : take a care about byte order with Motorola computers. + // I don't touch this... In this context it might produce nonsense. + if (QImage::systemByteOrder() == QImage::BigEndian) // PPC + { + p[3] = 0xFFFF; + p[0] = *stripPtr; + p[1] = *stripPtr; + p[2] = *stripPtr++; + } + else + { + p[0] = *stripPtr; // RGB have to be set to the _same_ value + p[1] = *stripPtr; + p[2] = *stripPtr++; + p[3] = 0xFFFF; // set alpha to 100% + } + dataPtr += 4; + } + offset += bytesRead*4; // The _byte_offset in the data array is, of course, four times bytesRead + } + else // ABGR + { for (int i=0; i < bytesRead/8; i++) { p = dataPtr; @@ -319,7 +347,6 @@ offset += bytesRead; } } - delete [] strip; } else // Non 16 bits images ==> get it on BGRA 8 bits. ---------------------------------------------------------------------------
Thanks Maximilian, I will test your patch today. Note: Are you grayscale TIFF images in 8 and 16 bits color depth to test ? Gilles Caulier
SVN commit 813740 by cgilles: digikam from KDE3 branch : patch from Maximilian Schultz to support Grayscale tiff image BUGS: 148400 M +89 -62 tiffloader.cpp M +8 -8 tiffloader.h WebSVN link: http://websvn.kde.org/?view=rev&revision=813740