"installed from: Slackware packages" line is of course not true...was a mistake..sorry

Dubas,

I have no problem to see your 'Spider' photograph in Image editor using current trunk implementation. Really nice picture !

I suspect a problem relevant of your libtiff. Can you give me :

- libtiff version.
- messages from the console when you load this image (after to have updated svn).

Note : here, i'm use Mandriva 2006 with libtiff 3.6.1

Gilles Caulier

SVN commit 531715 by cgilles:

digikam from trunk : Fix broken thumbnail creation by digiKam KIO-slave with 16 bits TIFF images unrecognized properly by dcraw::parse method like a real tiff images.
CCBUGS: 125916
CCMAIL: digikam-devel@kde.org

 M  +32 -8     digikamthumbnail.cpp  
 M  +1 -0      digikamthumbnail.h  


--- trunk/extragear/graphics/digikam/kioslave/digikamthumbnail.cpp #531714:531715
@@ -35,6 +35,7 @@
 #include <qimage.h>
 #include <qdatastream.h>
 #include <qfile.h>
+#include <qfileinfo.h>
 #include <qdir.h>
 #include <qwmatrix.h>
 #include <qregexp.h>
@@ -337,17 +338,22 @@
 
     if (regenerate)
     {
-        // Try JPEG loading : JPEG files without using Exif Thumb.
-        if ( !loadJPEG(img, url.path()))
+        // In first we trying to load image using the file extension. This is mandatory because
+        // some tiff files are detected like RAW files by dcraw::parse method.
+        if ( !loadByExtension(img, url.path()) )
         {
-            // Try to load with dcraw : RAW files.
-            if (!loadDCRAW(img, url.path()))
+            // Try JPEG loading : JPEG files without using Exif Thumb.
+            if ( !loadJPEG(img, url.path()) )
             {
-                // Try to load with DImg : TIFF, PNG, etc.
-                if (!loadDImg(img, url.path()))
+                // Try to load with dcraw : RAW files.
+                if (!loadDCRAW(img, url.path()) )
                 {
-                    // Try to load with KDE thumbcreators : video files and others stuff.
-                    loadKDEThumbCreator(img, url.path());
+                    // Try to load with DImg : TIFF, PNG, etc.
+                    if (!loadDImg(img, url.path()) )
+                    {
+                        // Try to load with KDE thumbcreators : video files and others stuff.
+                        loadKDEThumbCreator(img, url.path());
+                    }
                 }
             }
         }
@@ -427,6 +433,24 @@
     finished();
 }
 
+bool kio_digikamthumbnailProtocol::loadByExtension(QImage& image, const QString& path)
+{
+    QFileInfo fileInfo(path);
+    if (!fileInfo.exists())
+        return false;
+    
+    QString ext = fileInfo.extension().upper();
+
+    if (ext == QString("JPEG") || ext == QString("JPG"))
+        return (loadJPEG(image, path));
+    else if (ext == QString("PNG"))
+        return (loadDImg(image, path));
+    else if (ext == QString("TIFF") || ext == QString("TIF"))
+        return (loadDImg(image, path));
+    
+    return false;
+}
+
 /////////////////////////////////////////////////////////////////////////////////////////
 // JPEG Extraction
 
--- trunk/extragear/graphics/digikam/kioslave/digikamthumbnail.h #531714:531715
@@ -44,6 +44,7 @@
 
 private:
 
+    bool loadByExtension(QImage& image, const QString& path);
     bool loadJPEG(QImage& image, const QString& path);
     bool loadDImg(QImage& image, const QString& path);
     bool loadKDEThumbCreator(QImage& image, const QString& path);

SVN commit 531782 by cgilles:

digikam from stable : Fix broken thumbnail creation by digiKam KIO-slave with 16 bits TIFF images unrecognized properly by dcraw::parse method like a real tiff images.
CCBUGS: 125916
CCMAIL: digikam-devel@kde.org

 M  +55 -34    digikamthumbnail.cpp  
 M  +32 -29    digikamthumbnail.h  


--- branches/stable/extragear/graphics/digikam/kioslave/digikamthumbnail.cpp #531781:531782
@@ -1,30 +1,27 @@
-//////////////////////////////////////////////////////////////////////////////
-//
-//    DIGIKAMTHUMBNAIL.CPP
-//
-//    Copyright (C) 2003-2004 Renchi Raju <renchi at pooh.tam.uiuc.edu>
-//                            Gilles CAULIER <caulier dot gilles at free.fr>
-//
-//    This program is free software; you can redistribute it and/or modify
-//    it under the terms of the GNU General Public License as published by
-//    the Free Software Foundation; either version 2 of the License, or
-//    (at your option) any later version.
-//
-//    This program is distributed in the hope that it will be useful,
-//    but WITHOUT ANY WARRANTY; without even the implied warranty of
-//    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-//    GNU General Public License for more details.
-//
-//    You should have received a copy of the GNU General Public License
-//    along with this program; if not, write to the Free Software
-//    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-//
-//////////////////////////////////////////////////////////////////////////////
+/* ============================================================
+ * Authors: Renchi Raju <renchi@pooh.tam.uiuc.edu>
+ *          Gilles Caulier <caulier dot gilles at kdemail dot net> 
+ * Date   : 2003-01-15
+ * Description : digiKam KIO slave to get image thumbnails.
+ *
+ * Copyright 2003-2005 by Renchi Raju, Gilles Caulier
+ * Copyright 2006      by Gilles Caulier
+ *
+ * This program is free software; you can redistribute it
+ * and/or modify it under the terms of the GNU General
+ * Public License as published by the Free Software Foundation;
+ * either version 2, or (at your option)
+ * any later version.
+ * 
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * ============================================================ */
 
 #define XMD_H
 
-#include <digikam_export.h>
-
 // Qt Includes.
 
 #include <qcstring.h>
@@ -32,6 +29,7 @@
 #include <qimage.h>
 #include <qdatastream.h>
 #include <qfile.h>
+#include <qfileinfo.h>
 #include <qdir.h>
 #include <qwmatrix.h>
 #include <qregexp.h>
@@ -80,6 +78,7 @@
 
 #include "dcraw_parse.h"
 #include "digikamthumbnail.h"
+#include "digikam_export.h"
 
 #define X_DISPLAY_MISSING 1
 #include <Imlib2.h>
@@ -342,20 +341,25 @@
 
     if (regenerate)
     {
-        // Try JPEG loading...
-        if ( !loadJPEG(img, url.path()) )
+        // In first we trying to load image using the file extension. This is mandatory because
+        // some tiff files are detected like RAW files by dcraw::parse method.
+        if ( !loadByExtension(img, url.path()) )
         {
-            // Try to load with imlib2
-            if ( !loadImlib2(img, url.path()) )
+            // Try JPEG loading...
+            if ( !loadJPEG(img, url.path()) )
             {
-                // Try to load with QT/KDELib
-                if (!img.load(url.path()))
+                // Try to load with dcraw : RAW files.
+                if ( !loadDCRAW(img, url.path()) )
                 {
-                    // Try to load with KDE thumbcreators
-                    if (!loadKDEThumbCreator(img, url.path()))
+                    // Try to load with imlib2 : TIFF, PNG, etc.
+                    if ( !loadImlib2(img, url.path()) )
                     {
-                        // Try to load with dcraw
-                        loadDCRAW( img, url.path() );
+                        // Try to load with QT/KDELib
+                        if ( !img.load(url.path()) )
+                        {
+                            // Try to load with KDE thumbcreators : video files and others stuff.
+                            loadKDEThumbCreator(img, url.path());
+                        }
                     }
                 }
             }
@@ -436,7 +440,24 @@
     finished();
 }
 
+bool kio_digikamthumbnailProtocol::loadByExtension(QImage& image, const QString& path)
+{
+    QFileInfo fileInfo(path);
+    if (!fileInfo.exists())
+        return false;
+    
+    QString ext = fileInfo.extension().upper();
 
+    if (ext == QString("JPEG") || ext == QString("JPG"))
+        return (loadJPEG(image, path));
+    else if (ext == QString("PNG"))
+        return (image.load(path));
+    else if (ext == QString("TIFF") || ext == QString("TIF"))
+        return (image.load(path));
+    
+    return false;
+}
+
 /////////////////////////////////////////////////////////////////////////////////////////
 // JPEG Extraction
 
--- branches/stable/extragear/graphics/digikam/kioslave/digikamthumbnail.h #531781:531782
@@ -1,25 +1,24 @@
-//////////////////////////////////////////////////////////////////////////////
-//
-//    DIGIKAMTHUMBNAIL.H
-//
-//    Copyright (C) 2003-2004 Renchi Raju <renchi at pooh.tam.uiuc.edu>
-//                            Gilles CAULIER <caulier dot gilles at free.fr>
-//
-//    This program is free software; you can redistribute it and/or modify
-//    it under the terms of the GNU General Public License as published by
-//    the Free Software Foundation; either version 2 of the License, or
-//    (at your option) any later version.
-//
-//    This program is distributed in the hope that it will be useful,
-//    but WITHOUT ANY WARRANTY; without even the implied warranty of
-//    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-//    GNU General Public License for more details.
-//
-//    You should have received a copy of the GNU General Public License
-//    along with this program; if not, write to the Free Software
-//    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-//
-//////////////////////////////////////////////////////////////////////////////
+/* ============================================================
+ * Authors: Renchi Raju <renchi@pooh.tam.uiuc.edu>
+ *          Gilles Caulier <caulier dot gilles at kdemail dot net> 
+ * Date   : 2003-01-15
+ * Description : digiKam KIO slave to get image thumbnails.
+ * 
+ * Copyright 2003-2005 by Renchi Raju, Gilles Caulier
+ * Copyright 2006      by Gilles Caulier
+ *
+ * This program is free software; you can redistribute it
+ * and/or modify it under the terms of the GNU General
+ * Public License as published by the Free Software Foundation;
+ * either version 2, or (at your option)
+ * any later version.
+ * 
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ * 
+ * ============================================================ */
 
 #ifndef _digikamthumbnail_H_
 #define _digikamthumbnail_H_
@@ -36,6 +35,7 @@
 
 class kio_digikamthumbnailProtocol : public KIO::SlaveBase
 {
+
 public:
 
     kio_digikamthumbnailProtocol(int argc, char** argv);
@@ -44,22 +44,25 @@
 
 private:
 
+    bool loadByExtension(QImage& image, const QString& path);
     bool loadJPEG(QImage& image, const QString& path);
     bool loadImlib2(QImage& image, const QString& path);
     bool loadKDEThumbCreator(QImage& image, const QString& path);
     bool loadDCRAW(QImage& image,  const QString& path);
     void createThumbnailDirs();
 
-    int  cachedSize_;
+private:
 
-    int org_width_;
-    int org_height_;
-    int new_width_;
-    int new_height_;
+    int           cachedSize_;
 
-    QString smallThumbPath_;
-    QString bigThumbPath_;
+    int           org_width_;
+    int           org_height_;
+    int           new_width_;
+    int           new_height_;
 
+    QString       smallThumbPath_;
+    QString       bigThumbPath_;
+
     QApplication *app_;
     int           argc_;
     char**        argv_;

Gilles Caulier wrote:
[bugs.kde.org quoted mail]

Hello Gilles,

After compiling digikam just after your "SVN commit 531715" I got the same result :(
My libtiff is 3.7.3 (from Slackware 10.2).

Here is the digikam output when opening the file:

digikam: Cannot load metadata using Exiv2 
(/home/dudeeg/pics/CanonEOS/2006_04_16/IMG_4224-01.tif: The file contains data 
of an unknown image type)
digikam: Cannot load metadata using Exiv2 
(/home/dudeeg/pics/CanonEOS/2006_04_16/IMG_4224-01.tif: The file contains data 
of an unknown image type)
digikam: Cannot load metadata using Exiv2 
(/home/dudeeg/pics/CanonEOS/2006_04_16/IMG_4224-01.tif: The file contains data 
of an unknown image type)
digikam: Cannot parse EXIF metadata using Exiv2
digikam: Cannot load metadata using Exiv2 
(/home/dudeeg/pics/CanonEOS/2006_04_16/IMG_4224-01.tif: The file contains data 
of an unknown image type)
digikam: enableCMSetting=false
digikam: /home/dudeeg/pics/CanonEOS/2006_04_16/IMG_4224-01.tif : TIFF file 
identified
TIFF Directory at offset 0x31eb44
   Subfile Type: (0 = 0x0)
   Image Width: 923 Image Length: 590
   Resolution: 300, 300 pixels/inch
   Bits/Sample: 16
   Compression Scheme: None
   Photometric Interpretation: RGB color
   Samples/Pixel: 3
   Rows/Strip: 1
   Planar Configuration: single image plane
   ICC Profile: <present>, 3144 bytes
   Make: Canon
   Model: Canon EOS 350D DIGITAL
   EXIFIFDOffset: 3270572


Regards,
Gabor

SVN commit 532147 by cgilles:

digikam from stable : Fix broken thumbnail creation with USM camera with 16 bits TIFF images unrecognized properly by dcraw::parse method like a real tiff images.
CCBUGS: 125916
CCMAIL: digikam-devel@kde.org

 M  +15 -5     umscamera.cpp  


--- branches/stable/extragear/graphics/digikam/utilities/cameragui/umscamera.cpp #532146:532147
@@ -5,7 +5,7 @@
  * Description : 
  * 
  * Copyright 2004-2005 by Renchi Raju
- * Copyright 2005 by Gilles Caulier
+ * Copyright 2005-2006 by Gilles Caulier
  *
  * This program is free software; you can redistribute it
  * and/or modify it under the terms of the GNU General
@@ -138,9 +138,7 @@
     return true;
 }
 
-bool UMSCamera::getThumbnail(const QString& folder,
-                             const QString& itemName,
-                             QImage& thumbnail)
+bool UMSCamera::getThumbnail(const QString& folder, const QString& itemName, QImage& thumbnail)
 {
     m_cancel = false;
 
@@ -173,8 +171,20 @@
            return true;
     }   
 
-    // In 3rd we trying to get thumbnail from RAW files using dcraw parse utility.
+    // In 3rd, if file image type is TIFF, load thumb using KDELib API before to use dcraw::parse method 
+    // to prevent broken 16 bits TIFF thumb.
 
+    if (fi.extension().upper() == QString("TIFF") ||
+        fi.extension().upper() == QString("TIF"))
+    {
+        thumbnail.load(folder + "/" + itemName);
+    
+        if (!thumbnail.isNull())
+            return true;
+    }
+
+    // In 4th we trying to get thumbnail from RAW files using dcraw parse utility.
+
     KTempFile thumbFile(QString::null, "camerarawthumb");
     thumbFile.setAutoDelete(true);
     Digikam::DcrawParse rawFileParser;

Dubas, Your libtiff messages are correct and similar that mine.

But i suspect that your libtiff is an instable release (3.7.3 version). The 3.8.2 stable release is available since a long time : 

http://www.remotesensing.org/libtiff

I recommend you to test with :

- 3.6.x release (like in mandriva).
or 
- 3.8.2 release (last stable).

Thanks in advance

Gilles Caulier

NOTE : All my recent commits in stable and trunk branch fix bugs relevant of wrong thumbnails generation (main interface and camera gui) with your TIFF file.

Dubas,

Marcel have downloaded the tiff file and all is ok (libtiff 3.7.3 - Gentoo)
Paco have downloaded the tiff file too and all is ok (libtiff 3.6.1 - Mandriva 2006 + KDE 3.5.2)

Please check your system

Gilles

Dubas, 

can you give me a fresh report about this problem ?

Gilles Caulier

Hi Gilles,

I have not dealt with this problem in the last couple of weeks (since you have posted that Marcel's libtiff 3.7.3 is working perfectly with my system).
The main problem that I have no idea from where to start the check.
I have an official libtiff 3.7.3. slackware package installed, but I cannot see the 16bit TIFF correctly.

If you can give me a hint what to check closely I can do it in 2-3 days.

Thanks,
Gabor Dudas

ps: a small correction: the second letter in my family name is d; however, please feel free to call me Gabor :)

correction:

...
(since you have posted that Marcel's libtiff 3.7.3 is working perfectly with my _image_)
...

Gabor,

Update svn, and start digiKam from a console. Try to load the tiff image and look the error/warning message from libtiff.

Gilles

Created attachment 16375 [details]
ScreenGrab from digiKam window after opening a 16bit TIFF file

Gilles, 

Fresh svn update is done. The problem still exists (output can be seen on the attached screengrab image).


digiKam output during startup:
----------------
digikam: ScanLib: Finding non-existing Albums: 24 ms
digikam: ScanLib: Finding items not in the database or disk: 839 ms
digikam: ScanLib: Updating items without date: 7 ms
digikam: Cannot parse EXIF metadata using Exiv2
KIPI (loading): KIPI::PluginLoader: plugin KameraKlient is in the ignore list for host application
digikam: ImagePlugin_Core plugin loaded
digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Core
digikam: Cannot load metadata using Exiv2 (/home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif: The file contains data of an unknown image type)


digiKam output during opening the TIFF file:
---------------------
digikam: Cannot parse EXIF metadata using Exiv2
digikam: Cannot load metadata using Exiv2 (/home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif: The file contains data of an unknown image type)
digikam: /home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif : TIFF file identified
digikam: Cannot load metadata using Exiv2 (/home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif: The file contains data of an unknown image type)


Regards,
Gabor

Gabor, 

There is no error messages from libtiff... strange.

Are you using PCC like computer or something like that ? 64 bits computer ?

Gilles

Gilles,

Nope...I am using AMD Athlon. Not really a new model. 1 GHz.
I would like to change my libtiff installation to anothere one, but I don't have too much experience in updating an important system library. I have an official package installed called libtiff-3.7.3-i486-1.
I could easily remove this, but I have found that another official base package, called aaa_elflibs-10.2.0-i486-3 is containing a file: usr/lib/libtiff.so.3.7.3
Any idea about updating?

Thanks,
Gabor

no idea about slackware. sorry. perhaps someone in this room can help you...

Gilles

Gilles,

I have updated the libtiff from 3.7.3 to 3.8.2, but the problem is the same :((
(I have not recompiled digiKam after the libtiff update, but I guess I don't have to...)

I am out of idea about what can cause this, but this is really annoying! :)

Regards,
Gabor

Let me add that e.g. Kuickshow perfectly opens that 16bit TIFF, and eg. Konqueror generates the preview perfectly.

Gabor

Gabor,

Warning : kuickshow and konqueror decode your 16 bits tiff using 8 bits mode. It's not the same way ! The only way to check properlly 16 bits decoding into linux is to use ImageMagick like this :

# display foo.tiff

I will had more debug informations in digiKam tiff loader to trace all options/rules used to decode your image. Let's me some times to commit changes

Gilles 

Gilles,

No problem. Take your time. As I see no one else has this problem, so I guess it is no so urgent.
(BTW: I have tried $display foo_16bit.tiff  no problem, correct picture)

Regards,
Gabor

some addition:

An interesting thing that might mean something: 
I have opened a 8 bit image with digikam, converted to 16 bit from the menu, and saved it as TIFF. 'display' worked fine, however digiKam opened it with the same error as with the spider picture!

Regards,
Gabor

I would like to report that I experience exactly the same problem with opening 16-bit TIFF images. Some details:

* DigiKam 0.9.0-beta1
* KDE 3.5.3
* LibTIFF 3.8.2
* Gentoo Linux
* AMD Athlon 800 MHz

The images look distorted exactly like shown in the attachment. The same image is displayed perfectly in other 16-bit capable applications, like CinePaint and Krita.

Created attachment 17241 [details]
Debug statements

All works perfectly here, I can't reproduce this.
The attached patch adds some debug statements, perhaps we can find any
differences. Just wild guessing, I don't know where this comes from.
Please try with the spider picture, I can test with this one as well.

I would like to really know what can cause this problem. Now I am happy to know that I am not the only one who has this problem with 16bit TIFF images.
Dik, please let me know if my spider image produce the same bad output.

Thanks,
Gabor

Marcel, 

If something is mising in the DImg::TiffLoader implementation, We can compare the ImageMagick TIFF Loader witch run properlly under Dubas system using "display IMG_4224-01.tif"

You can find the url to the ImageMagick implementation into the header on the tiffloader.cpp

Gilles

In reply to Comment #24 to Marcel:

I have compiled the svn with the included debug patch. The image output is the same.
Here is the debug statements from digiKam:


digikam: /home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif : TIFF file identified
digikam: Loading TIFF file 923 x 590 bits_per_sample 16 samples_per_pixel 0 rows_per_strip 1 strip_size 5538 num_of_strips 590
digikam: Read 5538 bytes from strip 0, offset 0
digikam: Read 5538 bytes from strip 1, offset 5538
digikam: Read 5538 bytes from strip 2, offset 11076
digikam: Read 5538 bytes from strip 3, offset 16614
digikam: Read 5538 bytes from strip 4, offset 22152
digikam: Read 5538 bytes from strip 5, offset 27690
digikam: Read 5538 bytes from strip 6, offset 33228
digikam: Read 5538 bytes from strip 7, offset 38766
digikam: Read 5538 bytes from strip 8, offset 44304
digikam: Embedded profile: sRGB IEC61966-2.1


Regards,
Gabor

Thanks for testing.
The problem is "samples_per_pixel 0".
Here it is "samples_per_pixel 3", as one would assume for an RGB image. 0 samples per pixel is a bit problematic ;-)
(We do not check for 0, we assume 3 or 4. Subsequently, the image data will be read as if it has 4 samples per pixel, which explains the interesting output you are getting)

So next we need to have an idea why this value is wrong.

Right Marcel. This is certainly a bug in libtiff...

Look in Exif Metadata tab. We have :

- bits per sample   = 16 16 16.
- samples per pixel = 3.

Certainly, something is missing in Digikam::DImg::TiffLoader to use libtiff against library bugs. I recommend you to check the ImageMagick tiffloader implementation (ReadTIFFImage() method) witch work perfectly with the "Spider" picture.

https://subversion.imagemagick.org/subversion/ImageMagick/trunk/coders/tiff.c

Note: in digiKam, we don't test the TIFFTAG_PHOTOMETRIC interpretation of tiff image. In fact if the image is not RGB, a conversion must be done like libtiff can do to import directly all photometric image types to RGB.

Dik, since you have the same problem than Gabor, can you provide another sample image TIFF to test ? Thanks in advance.

Gilles Caulier

SVN commit 580080 by mwiesweg:

- check that rows_per_strip, bits_per_sample and samples_per_pixel is not 0.
  If these value are invalid, refuse to load.
  - rows_per_strip of 0 results in an endless loop
  - samples_per_pixel of 0 is invalid, leads to bad data
- use TiffGetFieldDefaulted instead of TiffGetField (inspired by ImageMagick)

Note: this does not fix the problem that libtiff returns invalid values,
but now digikam notices the fact.

CCBUG: 125916



 M  +20 -7     tiffloader.cpp  


--- trunk/extragear/graphics/digikam/libs/dimg/loaders/tiffloader.cpp #580079:580080
@@ -124,19 +124,32 @@
     tsize_t   strip_size;
     tstrip_t  num_of_strips;
 
-    TIFFGetField(tif, TIFFTAG_IMAGEWIDTH, &w);
-    TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &h);
+    TIFFGetFieldDefaulted(tif, TIFFTAG_IMAGEWIDTH, &w);
+    TIFFGetFieldDefaulted(tif, TIFFTAG_IMAGELENGTH, &h);
 
-    TIFFGetField(tif, TIFFTAG_BITSPERSAMPLE, &bits_per_sample);
-    TIFFGetField(tif, TIFFTAG_SAMPLESPERPIXEL, &samples_per_pixel);
-    TIFFGetField(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip);
+    TIFFGetFieldDefaulted(tif, TIFFTAG_BITSPERSAMPLE, &bits_per_sample);
+    TIFFGetFieldDefaulted(tif, TIFFTAG_SAMPLESPERPIXEL, &samples_per_pixel);
+    TIFFGetFieldDefaulted(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip);
 
-    if (TIFFGetField(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip) == 0)
+    if (TIFFGetField(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip) == 0 || rows_per_strip == 0)
     {
-        kdDebug() << k_funcinfo << "Can't handle non-stripped images." << endl;
+        kdWarning()  << "TIFF loader: Cannot handle non-stripped images. Loading file " << filePath << endl;
         TIFFClose(tif);
         return false;
     }
+
+    if (bits_per_sample == 0 ||
+        samples_per_pixel == 0 ||
+        rows_per_strip == 0)
+    {
+        kdWarning() << "TIFF loader: Encountered invalid value 0 in image."
+                    << " bits_per_sample " << bits_per_sample
+                    << " samples_per_pixel " << samples_per_pixel
+                    << " rows_per_strip " << rows_per_strip
+                    << " Loading file " << filePath << endl;
+        TIFFClose(tif);
+        return false;
+    }
     
     TIFFGetFieldDefaulted(tif, TIFFTAG_PHOTOMETRIC, &photometric);
 /* 

SVN commit 580300 by cgilles:

digikam from trunk : DImg::TiffLoader : digiKam cannot handle TIFF file without RGB color-space.

Marcel, this is still to do in tiff decoder RGB color-space is used with 90% of tiff files, especially with photograph pictures, but we need to finalize this part to support others tiff color-spaces.

This commit prevent dummy image data decoding in editor.

CCBUGS: 125916

 M  +6 -3      tiffloader.cpp  


--- trunk/extragear/graphics/digikam/libs/dimg/loaders/tiffloader.cpp #580299:580300
@@ -151,15 +151,18 @@
         return false;
     }
     
+    // TODO: check others TIFF color-spaces here. Actually, only RGB is supported.
+    // Complete description of TIFFTAG_PHOTOMETRIC tag can be found at this url: 
+    // http://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation.html
+
     TIFFGetFieldDefaulted(tif, TIFFTAG_PHOTOMETRIC, &photometric);
-/* 
     if (photometric != PHOTOMETRIC_RGB)
     {
-        kdWarning() << k_funcinfo << "Can't handle image without RGB photometric: " << photometric << endl;
+        kdWarning() << "Can't handle image without RGB color-space: " 
+                    << photometric << endl;
         TIFFClose(tif);
         return false;
     }
-  */  
     
     if (samples_per_pixel == 4)
         m_hasAlpha = true;

SVN commit 580303 by cgilles:

digikam from trunk : DImg::TiffLoader : the loader work fine with PHOTOMETRIC_MINISBLACK TIFF color-space (Blacl & white picture converted with ImageMagick). 

Marcel, we need to check the current implementation with others TIFF color-spaces. There are a lots of tiff sample pictures in libtiff repository :

http://www.remotesensing.org/libtiff/images.html

CCBUGS: 125916

 M  +7 -2      tiffloader.cpp  


--- trunk/extragear/graphics/digikam/libs/dimg/loaders/tiffloader.cpp #580302:580303
@@ -21,6 +21,9 @@
  * - http://freeimage.cvs.sourceforge.net/freeimage/FreeImage/Source/Metadata/XTIFF.cpp
  * - https://subversion.imagemagick.org/subversion/ImageMagick/trunk/coders/tiff.c
  *
+ * Test images repository:
+ * - http://www.remotesensing.org/libtiff/images.html
+ *
  * This program is free software; you can redistribute it
  * and/or modify it under the terms of the GNU General
  * Public License as published by the Free Software Foundation;
@@ -151,12 +154,14 @@
         return false;
     }
     
-    // TODO: check others TIFF color-spaces here. Actually, only RGB is supported.
+    // TODO: check others TIFF color-spaces here. Actually, only RGB and MINISBLACK 
+    // have been tested.
     // Complete description of TIFFTAG_PHOTOMETRIC tag can be found at this url: 
     // http://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation.html
 
     TIFFGetFieldDefaulted(tif, TIFFTAG_PHOTOMETRIC, &photometric);
-    if (photometric != PHOTOMETRIC_RGB)
+    if (photometric != PHOTOMETRIC_RGB || 
+        photometric != PHOTOMETRIC_MINISBLACK)
     {
         kdWarning() << "Can't handle image without RGB color-space: " 
                     << photometric << endl;

I have just compiled digiKam 0.9 svn. As Marcel commented at #30 I get an error message from digiKam and it refuses to load to TIFF image.

The message is:
-----------
digikam: /home/dudeeg/pics/digikam_16bit_TIFF_test/IMG_4224-01.tif : TIFF file identified
digikam: Cannot load metadata using Exiv2 (/home/dudeeg/pics/digikam_16bit_TIFF_test/IMG_4224-01.tif: The file contains                      data of an unknown image type)
digikam: WARNING: TIFF loader: Encountered invalid value 0 in image. bits_per_sample 16 samples_per_pixel 0 rows_per_strip 1 Loading file /home/dudeeg/pics/digikam_16bit_TIFF_test/IMG_4224-01.tif
digikam: WARNING: [Digikam::DImg* Digikam::DImgInterface::getImg()] d->image is NULL
digikam: Cannot load metadata using Exiv2 (/home/dudeeg/pics/digikam_16bit_TIFF_test/IMG_4224-01.tif: The file contains                      data of an unknown image type)
digikam: WARNING: Failed to load image IMG_4224-01.tif
---------

Do you have a plan for the future to fix this problem?

Thanks!
Gabor

I would like to fix this, but I am stuck with the question why libtiff returns the value 0, more precisely, why it returns this value only on your system and a few others.

I admit it is very strange. Actually I am using 2 PCs at home, but both of them produce the same "effect". The libtiff versions are different on the two machines, but both of them are running Slackware 10.1.
Just let me know if I can help you by trying out this and that on these boxes.

Thanks and regards,
Gabor

Marcel,

You can get some help from libtiff developper mailing list. This one is very active:

http://lists.maptools.org/mailman/listinfo/tiff

Gilles

Gabor,

before we ask the libtiff mailing list, could you (if not yet done), to rule out problems,

- get latest libtiff release from ftp://ftp.remotesensing.org/pub/libtiff and compile and install it from source
- verify with ldd (ldd `which digikam` | grep tiff) that the same file that you installed from source is used
- the bug still exists

No problem, I will try to do it within the next few days.

Regards,
Gabor

Done! 
- I have compiled the latest digiKam svn just an hour ago.
- My libtiff is v3.8.2 (compiled from source)
- It is used by digiKam (libtiff.so.3 => /usr/local/lib/libtiff.so.3 (0xb78b0000) )


The bug still exists. The output by digiKam:


digikam: /home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif : TIFF file identified
digikam: WARNING: TIFF loader: Encountered invalid value 0 in image. bits_per_sample 16 samples_per_pixel 0 rows_per_strip 1 Loading file /home/dudeeg/pics/CanonEOS/digikam_16bit_TIFF_test/IMG_4224-01.tif
digikam: WARNING: [Digikam::DImg* Digikam::DImgInterface::getImg()] d->image is NULL
digikam: WARNING: Failed to load image IMG_4224-01.tif


Regards,
Gabor

DigiKam 0.9.0 Beta2 fixes this problem for me. All 16bit TIFF files open perfectly now.

Thanks!

Gabor, don't know if you noticed but we have contacted the libtiff mailing list. The thread is here:

http://www.asmail.be/msg0054632618.html

According to the latest message from Joris
http://www.asmail.be/msg0054765738.html
they know just as much about what to do about this as we do (nothing).

With Dik Takken now leaving the "me too" list, it seems to be your system only, and I dont have any more ideas.

Hi Marcel,

Thank You and to Gilles for contacting the libtiff-list. My opinion is the same about this problem: since its only occurs under my system, leave it, and don't put any more efforts to figure out what can cause this.

Today I have installed the new Slackware 11.0 release. It's a fresh install to a blank drive :)
Soon I will grab the latest developer version of digiKam to check if the problem still exists. If yes, I guess I will give it up too :)

Regards,
Gabor

Gabor,

Some fresh news from your new Slackware 11.0 install and digikam 0.9.0-RC2 ?

Gilles

I'm having a problem opening 16bit tiffs, but getting a different error.

Error message in terminal is always: 

 digikam: WARNING: TIFF loader: Cannot handle non-stripped images. Loading file
/home/stmiller/Pictures/libtiffpic/quad-lzw.tif 
 digikam: WARNING: Failed to load image quad-lzw.tif 
 digikam: WARNING: [Digikam::DImg* Digikam::DImgInterface::getImg()] d->image
is NULL 

 Digikam version: 0.9.0-rc2 
 libtiff version: 3.8.2-r2 

 ----------- 
 I'm using PPC 32bitUL/ppc64. Looking for any suggestions.

 stmiller@stmiller ~ $ uname -a 
 Linux stmiller 2.6.18-gentoo-r3 #6 SMP PREEMPT Sat Dec 2 23:19:09 PST 2006
ppc64 PPC970FX, altivec supported PowerMac7,3 GNU/Linux 

 -------- 

[And I do have 'tiff' as a use flag.] 

Digikam DOES load the camera data from the file. So it can read that. And
Kuickshow CAN open these tiffs.

I've tried personal copies as well
as example tiff files from here: 

 http://www.remotesensing.org/libtiff/images.html 

All get the same error as above.

Should I open a new bug report? 

Scott, 

No need to had dupplicate entries in B.K.O. Your problem sound like a similar than Dubas file.

Gilles

Not every file from this package is supported, digikam's TIFF loader handles the TIFF files you usually come across, but does not implement every color space and format that the standard allows.
But: quad-lzw.tif is supported, it loads here.

Marcel,

About to support other color space than RGB* like XYZ, YMCK, etc., it easy to do color-space transformation using lcms (like CM stuff do). In fact, we can load image data as well and transform it to sRGB by default if CM is disable or using work-space color profile if CM is enable. This is true from JPEG, TIFF and JPEG2000 (not PNG witch work only in RGB*).

We can do it later than 0.9.0-final. Fine for you ?

Gilles

Created attachment 18926 [details]
ppc gentoo strace errors

Portion of strace log from ppc gentoo.
Outputs
open("/usr/kde/3.5/lib/tls/ppc970/altivec/power4/libtiff.so.3", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/kde/3.5/lib/tls/ppc970/altivec/libtiff.so.3", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/kde/3.5/lib/tls/ppc970/power4/libtiff.so.3", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/kde/3.5/lib/tls/ppc970/libtiff.so.3", O_RDONLY) = -1 ENOENT (No such
file or directory)

Running strace I noticed lots of libtiff.so.3 errors (along with other errors). 
(See attachment text file)
Could this be my problem?

Note: I can display images with

$ display image.tiff

SVN commit 620252 by mwiesweg:

As found out by Joerg Kuehne, TIFFTAG_ROWSPERSTRIP requires a uint32.
Maybe this was the bug?

Audited the other TIFFSet/GetField calls.

CCBUG: 125916
CCMAIL: joerg.kuehne@gmx.de



 M  +6 -7      tiffloader.cpp  


--- trunk/extragear/graphics/digikam/libs/dimg/loaders/tiffloader.cpp #620251:620252
@@ -128,7 +128,7 @@
     uint16    bits_per_sample;
     uint16    samples_per_pixel;
     uint16    photometric;
-    uint16    rows_per_strip;
+    uint32    rows_per_strip;
     tsize_t   strip_size;
     tstrip_t  num_of_strips;
 
@@ -137,9 +137,8 @@
 
     TIFFGetFieldDefaulted(tif, TIFFTAG_BITSPERSAMPLE, &bits_per_sample);
     TIFFGetFieldDefaulted(tif, TIFFTAG_SAMPLESPERPIXEL, &samples_per_pixel);
-    TIFFGetFieldDefaulted(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip);
 
-    if (TIFFGetField(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip) == 0 || rows_per_strip == 0)
+    if (TIFFGetFieldDefaulted(tif, TIFFTAG_ROWSPERSTRIP, &rows_per_strip) == 0 || rows_per_strip == 0)
     {
         DWarning()  << "TIFF loader: Cannot handle non-stripped images. Loading file " << filePath << endl;
         TIFFClose(tif);
@@ -464,7 +463,7 @@
         TIFFSetField(tif, TIFFTAG_SAMPLESPERPIXEL, 3);
     }
 
-    TIFFSetField(tif, TIFFTAG_BITSPERSAMPLE, imageBitsDepth());
+    TIFFSetField(tif, TIFFTAG_BITSPERSAMPLE, (uint16)imageBitsDepth());
     TIFFSetField(tif, TIFFTAG_ROWSPERSTRIP,  TIFFDefaultStripSize(tif, 0));
 
     // -------------------------------------------------------------------
@@ -823,8 +822,8 @@
 
     QImage thumb = m_image->smoothScale(160, 120, QSize::ScaleMin).copyQImage();
 
-    TIFFSetField(tif, TIFFTAG_IMAGEWIDTH,      thumb.width());
-    TIFFSetField(tif, TIFFTAG_IMAGELENGTH,     thumb.height());
+    TIFFSetField(tif, TIFFTAG_IMAGEWIDTH,      (uint32)thumb.width());
+    TIFFSetField(tif, TIFFTAG_IMAGELENGTH,     (uint32)thumb.height());
     TIFFSetField(tif, TIFFTAG_PHOTOMETRIC,     PHOTOMETRIC_RGB);
     TIFFSetField(tif, TIFFTAG_PLANARCONFIG,    PLANARCONFIG_CONTIG);
     TIFFSetField(tif, TIFFTAG_ORIENTATION,     ORIENTATION_TOPLEFT);
@@ -911,7 +910,7 @@
     QByteArray tag = metaData->getExifTagData(exifTagName);
     if (!tag.isEmpty()) 
     {
-        TIFFSetField (tif, tiffTag, (uint16)tag.size(), (char *)tag.data());
+        TIFFSetField (tif, tiffTag, (uint32)tag.size(), (char *)tag.data());
     }
 }
 

Dubas, Scott,

Wake up men (:=)))...

Please, please, please, give us a fresh feedback using the current implementation from svn. 

Thanks in advance...

Gilles

Dubas, Scott,

No new about the last changes from Marcel in svn ?

Gilles

Am Saturday 27 January 2007 schrieb Gilles Caulier:
[bugs.kde.org quoted mail]
I tried the images from 
ftp://ftp.remotesensing.org/pub/libtiff/pics-3.8.0.tar.gz. Most of them can't 
be opened by digikam Revision 627788 as you can see from the attached 
screenshot.

Typical shell output:
digikam: /home/gerhard/Fotos/Testing/libtiffpic/cramps-tile.tif : TIFF file 
identified
digikam: WARNING: Can't handle image without RGB color-space: 0
digikam: WARNING: Failed to load image cramps-tile.tif
digikam: WARNING: [Digikam::DImg* Digikam::DImgInterface::getImg()] d->image 
is NULL
digikam: /home/gerhard/Fotos/Testing/libtiffpic/ladoga.tif : TIFF file 
identified
digikam: WARNING: Cannot extract preview 
for /home/gerhard/Fotos/Testing/libtiffpic/caspian.tif
QImage::convertDepth: Image is a null image
QImage::smoothScale: Image is a null image


Created an attachment (id=19454)
tif-problems.png

Gerhard,

I know this TIFF image repository. I have already a copy in my computer.

A lot of pictures are not in RGB color space (CMYK for example), and digiKAm cannot yet handle properlly these pictures. It's another problem than Gabor have reported. I have a solution to handle non-RGB color-space picture using lcms library, but i have not yet implemented this one in my computer.

To test, try to open the "spidder" picture provided in this B.K.O file by Gabor. It's in RGB color space.

Gilles

Am Sunday 28 January 2007 schrieb Gilles Caulier:
[bugs.kde.org quoted mail]

The spider opens correctly.

Gerhard

>
> Gilles
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel@kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel

Gabor,

I would to have a fresh report from you about this file before to close it. 

Can you open properlly the spidder picture with digiKam 0.9.1 ?

Thanks in advance

Gilles

Am Wednesday 28 March 2007 schrieb Gilles Caulier:
[bugs.kde.org quoted mail]

I can open it and have EXIF data, no other metadata. I checked with 0.9.1 and 
svn.
Gerhard

> Thanks in advance
>
> Gilles
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel@kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel

Hi Gilles,

Finally it is working!!! :)
I don't what have happened, who have fixed what, but now the "spider" picture opens correctly.

Thanks for it!
And I think now you can close this quite bizarre bug that was openes almost 1 year ago :)

Regards,
Gabor

Thanks Gabor.Closed...

Gilles