Bug 125916 - Problem with opening 16bit TIFF
Summary: Problem with opening 16bit TIFF
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Plugin-DImg-TIFF (show other bugs)
Version: 0.9.0
Platform: Slackware Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-19 22:55 UTC by Gabor Dudas
Modified: 2017-08-01 20:23 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.9.2


Attachments
ScreenGrab from digiKam window after opening a 16bit TIFF file (67.67 KB, image/jpeg)
2006-05-31 12:24 UTC, Gabor Dudas
Details
Debug statements (1.04 KB, patch)
2006-08-05 22:55 UTC, Marcel Wiesweg
Details
ppc gentoo strace errors (476.26 KB, text/plain)
2006-12-14 06:51 UTC, Scott Miller
Details
tif-problems.png (136.60 KB, image/png)
2007-01-28 09:50 UTC, Gerhard Kulzer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Dudas 2006-04-19 22:55:18 UTC
Version:           0.9.0-svn (using KDE KDE 3.5.1)
Installed from:    Slackware Packages
Compiler:          gcc 3.3.6 
OS:                Linux

Opening a 16bit TIFF file (that is generated by an external RAW converter software) is not possible both in digikam or showfoto. More precisely: After clicking on the TIFF file it writes "TIFF file identified" to the console, but the opened editor/viewer shows pretty weird output (black and white overlapped lines, that reminds to the original image).

The file can be downloaded from:
http://amigos.amiga.hu/dudeeg/digikam_tiff/IMG_4224-01.tif


The output from "identify" :

$ identify -verbose IMG_4224-01.tif
IMG_4224-01.tif TIFF 923x590 DirectClass 3.1mb 0.060u 0:01
Image: IMG_4224-01.tif
  Format: TIFF (Tagged Image File Format)
  Geometry: 923x590
  Class: DirectClass
  Type: TrueColor
  Endianess: MSB
  Colorspace: RGB
  Channel depth:
    Red: 16-bits
    Green: 16-bits
    Blue: 16-bits
  Channel statistics:
    Red:
      Min: 2855 (0.0435645)
      Max: 65535 (1)
      Mean: 20836 (0.317938)
      Standard deviation: 9853.33 (0.150352)
    Green:
      Min: 3369 (0.0514076)
      Max: 61791 (0.94287)
      Mean: 23748 (0.362371)
      Standard deviation: 8250.34 (0.125892)
    Blue:
      Min: 875 (0.0133516)
      Max: 59798 (0.912459)
      Mean: 14503.7 (0.221312)
      Standard deviation: 7718.65 (0.117779)
  Colors: 544569
  Rendering-intent: Undefined
  Resolution: 300x300
  Units: PixelsPerInch
  Filesize: 3.1mb
  Interlace: None
  Background Color: white
  Border Color: #DFDFDFDFDFDF
  Matte Color: grey74
  Dispose: Undefined
  Iterations: 0
  Compression: None
  Orientation: TopLeft
  Make: Canon
  Model: Canon EOS 350D DIGITAL
  Signature: 240dfae4e98c9567455d25dbc0ae7eb65cf6717d6e03c1057869d8e3e59d65e3
  Profile-icc: 3144 bytes
0x00000000: 000c484c 696e6f02 1000006d 6e747252 47422058  ---HLino----mntrRGB
0x00000190: 595a2007 ce000200 09000600 31000061 6373704d  XYZ -Î-------1--acsp
..... (HEX dump follows for several lines...looks like an embedded color profile??)
Tainted: False
  User Time: 0.010u
  Elapsed Time: 0:01
  Pixels per second: 7.4mb
  Version: ImageMagick 6.2.3 02/06/06 Q16 http://www.imagemagick.org


Regards,
Gabor
Comment 1 Gabor Dudas 2006-04-19 23:00:40 UTC
"installed from: Slackware packages" line is of course not true...was a mistake..sorry
Comment 2 caulier.gilles 2006-04-19 23:50:22 UTC
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
Comment 3 caulier.gilles 2006-04-20 00:21:36 UTC
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);
Comment 4 caulier.gilles 2006-04-20 09:29:57 UTC
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_;
Comment 5 Gabor Dudas 2006-04-20 22:40:47 UTC
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
Comment 6 caulier.gilles 2006-04-21 13:07:56 UTC
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;
Comment 7 caulier.gilles 2006-04-21 14:19:57 UTC
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.
Comment 8 caulier.gilles 2006-04-21 22:49:59 UTC
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
Comment 9 caulier.gilles 2006-05-30 13:42:48 UTC
Dubas, 

can you give me a fresh report about this problem ?

Gilles Caulier
Comment 10 Gabor Dudas 2006-05-30 13:57:04 UTC
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 :)
Comment 11 Gabor Dudas 2006-05-30 14:42:19 UTC
correction:

...
(since you have posted that Marcel's libtiff 3.7.3 is working perfectly with my _image_)
...
Comment 12 caulier.gilles 2006-05-30 18:44:45 UTC
Gabor,

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

Gilles
Comment 13 Gabor Dudas 2006-05-31 12:24:17 UTC
Created attachment 16375 [details]
ScreenGrab from digiKam window after opening a 16bit TIFF file
Comment 14 Gabor Dudas 2006-05-31 12:32:59 UTC
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
Comment 15 caulier.gilles 2006-06-01 07:59:48 UTC
Gabor, 

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

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

Gilles
Comment 16 Gabor Dudas 2006-06-01 08:45:19 UTC
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
Comment 17 caulier.gilles 2006-06-01 11:24:50 UTC
no idea about slackware. sorry. perhaps someone in this room can help you...

Gilles
Comment 18 Gabor Dudas 2006-06-01 23:25:03 UTC
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
Comment 19 Gabor Dudas 2006-06-01 23:36:30 UTC
Let me add that e.g. Kuickshow perfectly opens that 16bit TIFF, and eg. Konqueror generates the preview perfectly.

Gabor
Comment 20 caulier.gilles 2006-06-02 08:07:41 UTC
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 
Comment 21 Gabor Dudas 2006-06-02 19:06:11 UTC
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
Comment 22 Gabor Dudas 2006-06-02 19:07:59 UTC
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
Comment 23 Dik Takken 2006-08-05 17:45:00 UTC
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.

Comment 24 Marcel Wiesweg 2006-08-05 22:55:16 UTC
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.
Comment 25 Gabor Dudas 2006-08-07 21:53:40 UTC
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
Comment 26 caulier.gilles 2006-08-17 02:54:14 UTC
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
Comment 27 Gabor Dudas 2006-08-17 22:39:28 UTC
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
Comment 28 Marcel Wiesweg 2006-08-18 23:33:47 UTC
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.
Comment 29 caulier.gilles 2006-08-19 11:35:45 UTC
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
Comment 30 Marcel Wiesweg 2006-09-02 17:34:25 UTC
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);
 /* 
Comment 31 caulier.gilles 2006-09-03 10:44:27 UTC
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;
Comment 32 caulier.gilles 2006-09-03 10:52:24 UTC
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;
Comment 33 Gabor Dudas 2006-09-29 22:01:10 UTC
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
Comment 34 Marcel Wiesweg 2006-09-30 15:08:46 UTC
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.
Comment 35 Gabor Dudas 2006-09-30 18:39:07 UTC
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
Comment 36 caulier.gilles 2006-10-01 10:17:57 UTC
Marcel,

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

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

Gilles
Comment 37 Marcel Wiesweg 2006-10-03 15:37:52 UTC
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
Comment 38 Gabor Dudas 2006-10-03 15:53:58 UTC
No problem, I will try to do it within the next few days.

Regards,
Gabor
Comment 39 Gabor Dudas 2006-10-09 00:31:44 UTC
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
Comment 40 Dik Takken 2006-10-15 22:28:47 UTC
DigiKam 0.9.0 Beta2 fixes this problem for me. All 16bit TIFF files open perfectly now.

Thanks!
Comment 41 Marcel Wiesweg 2006-10-21 16:30:11 UTC
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.
Comment 42 Gabor Dudas 2006-10-21 17:52:42 UTC
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
Comment 43 caulier.gilles 2006-12-08 07:56:13 UTC
Gabor,

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

Gilles
Comment 44 Scott Miller 2006-12-13 00:29:26 UTC
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? 

Comment 45 caulier.gilles 2006-12-13 07:32:06 UTC
Scott, 

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

Gilles
Comment 46 Marcel Wiesweg 2006-12-13 19:06:13 UTC
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.
Comment 47 caulier.gilles 2006-12-13 20:20:52 UTC
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
Comment 48 Scott Miller 2006-12-14 06:51:22 UTC
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)
Comment 49 Scott Miller 2006-12-14 06:53:00 UTC
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

Comment 50 Marcel Wiesweg 2007-01-05 15:22:29 UTC
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());
     }
 }
 
Comment 51 caulier.gilles 2007-01-07 16:24:26 UTC
Dubas, Scott,

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

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

Thanks in advance...

Gilles
Comment 52 caulier.gilles 2007-01-27 18:42:19 UTC
Dubas, Scott,

No new about the last changes from Marcel in svn ?

Gilles
Comment 53 Gerhard Kulzer 2007-01-28 09:50:16 UTC
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
Comment 54 caulier.gilles 2007-01-28 10:12:32 UTC
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
Comment 55 Gerhard Kulzer 2007-01-31 07:38:36 UTC
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

Comment 56 caulier.gilles 2007-03-28 09:03:41 UTC
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
Comment 57 Gerhard Kulzer 2007-03-28 11:06:57 UTC
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

Comment 58 Gabor Dudas 2007-03-28 22:02:40 UTC
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
Comment 59 caulier.gilles 2007-03-28 23:32:00 UTC
Thanks Gabor.Closed...

Gilles