Version: 1.6.0 (using KDE 4.5.4) OS: Linux I have a single image, which I will attach, which shows corrupt in Digikam view and edit modes. It appears like the pitch is being calculated incorrectly as a comb pattern appears over the image. It shows correctly in other photo software including Gimp so I don't think the image is corrupt. I took the photo as a RAW on a Sony DSLR and processed it in to a JPG in Adobe Photoshop in Windows, before saving it out as a greyscale jpg image. Reproducible: Always Steps to Reproduce: 1) Load the attached image with digikam. 2) Open it in either 'edit' or 'view' mode. Actual Results: You will see the corrupt image as described. Expected Results: The image should look the same as when it is opened in other packages such as Gimp. OS: Linux (x86_64) release 2.6.35-23-generic Compiler: cc Ubuntu 10.10
Created attachment 54278 [details] Test image that shows the corruption
Which LibJPEG you use ? Go to Help/Component Info for details. Gilles Caulier
Not reproducible here under Mandriva 2010.1 with current implementation from svn and libjpeg 8.0 Gilles Caulier
LibJPEG just reads '62' on the component information page. digiKam version 1.6.0 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: No Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.19 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.5.1 (KDE 4.5.1) LibKExiv2: 1.1.0 LibKdcraw: 1.1.0 LibLCMS: 118 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.09.44 - internal library LibPNG: 1.2.44 LibQt: 4.7.0 LibRaw: 0.10.0-Beta1 LibTIFF: LIBTIFF, Version 3.9.4 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble widget: 0.10.1 Parallelised demosaicing: Yes Database backend: QSQLITE LibGphoto2: 2.4.8 LibKipi: 1.1.0
Created attachment 54316 [details] Screenshot of digikam opening the test image
Created attachment 54317 [details] Screenshot of Gimp opening the test image
Created attachment 54318 [details] tar of the test image I've attached a tar of the test image that can be downloaded, just in case the bug tracking server has manipulated the jpg when I uploaded it. Try the version in this archive.
Created attachment 54319 [details] showfoto svn (1.7.0) with libjpeg 8.0 : no problem... Showfoto with libjpeg 8.0 running under mandriva 2010.1. No problem to open your test jpeg image. I suspect a broken install of your libjpeg on your system. Can you give us more information about libjpeg package installed on your system, as description, changelog, etc... Do you have more than one libjpeg installed on your system ? Gilles Caulier
I think you may be right, although I haven't done anything special to get that version of libjpeg on to my system. In synaptic I see two versions of libjpeg. The one I have installed is libjpeg62: libjpeg62: Installed: 6b-16.1 Candidate: 6b-16.1 Version table: *** 6b-16.1 0 500 http://gb.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages 100 /var/lib/dpkg/status There's another called libjpeg8 libjpeg8: Installed: (none) Candidate: 8b-1 Version table: 8b-1 0 500 http://gb.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages Apparently digikam is marked as dependent on libjpeg62: digikam Depends: kdebase-runtime Depends: kdepim-runtime Depends: libc6 Depends: libgcc1 Depends: libglib2.0-0 Depends: libgphoto2-2 Depends: libgphoto2-port0 Depends: libjasper1 Depends: libjpeg62 Depends: libkabc4 Depends: libkdcraw8 Depends: libkde3support4 Depends: libkdecore5 Depends: libkdeui5 Depends: libkexiv2-8 Depends: libkfile4 Depends: libkhtml5 Depends: libkio5 Depends: libkipi7 Depends: libkjsapi4 Depends: libknotifyconfig4 Depends: libkparts4 Depends: libkresources4 Depends: libkutils4 Depends: liblcms1 Depends: liblensfun0 Depends: liblqr-1-0 Depends: libmarblewidget10 Depends: libnepomuk4 Depends: libphonon4 Depends: libpng12-0 Depends: libqt4-dbus Depends: libqt4-network Depends: libqt4-qt3support Depends: libqt4-sql Depends: libqt4-svg Depends: libqt4-xml Depends: libqtcore4 Depends: libqtgui4 Depends: libsolid4 Depends: libsoprano4 Depends: libstdc++6 Depends: libtiff4 Depends: libx11-6 Depends: libxau6 Depends: libxdmcp6 Depends: phonon Depends: zlib1g Depends: libqt4-sql-sqlite Suggests: digikam-doc
I have tried installing libjpeg8 alongside libjpeg62, however digikam still seems to use libjpeg62. I can't uninstall libjpeg62 because most programs seem to depend on it.
It's a compile time dependency. to use libjpeg 8.0, digikam need to be recompiled... Gilles Caulier
Created attachment 54550 [details] Digikam 1.6 with no jpeg62 bugg
I'm curious about this too as I have about the same system (Kubuntu 10.10, KDE 4.5.4) as Graham but can't reproduce the bug with the testimage. /Philip
Hi again, After mentioning it to Philip Johnsson, the package maintainer, he noted that he does not see the same bug and he has the same install as I do (albeit KDE whereas I use Gnome). This indicated that it may not be a build issue but some kind of configuration issue on my machine. As a test I tried converting the test image to a PNG using Gimp, and found that the corruption still occurs. The image shows fine in Gimp, Image Viewer, and every other application I have tried, but not in Digikam. I cannot attach the test image as PNG because the server will only allow attachments of 1MB unfortunately. Regards Graham
I believe I have a lead. The bug only occurs when you switch on colour management.
We need to know the full CM config. Also all ICC profile files used in your settings... Gilles Caulier
No problem. I'm using Adobe RGB as my working space and sRGB as my monitor profile, though it also occurs with sRGB as the working space. Is there a settings file located somewhere that I can attach?
I can reproduce. I suspect it indeed happens in color conversion: The image is grayscale and has a grayscale embedded color profile. I am sure our code has so far only been tested with color images.
SVN commit 1206683 by mwiesweg: In our DImg, the input format is always BGRA, never grayscale or CMYK. I cannot really see if the test grayscale image in 259182 is properly color managed, but I hope lcms is clever enough to handle applying a grayscale profile on an BGRA image. BUG: 259182 M +4 -13 icctransform.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1206683
Marcel, you only patch GoSC2010 branch, not trunk ? Gilles Caulier
Ah yes, it should be backported. My SVN checkout from trunk is broken atm, I need to fix it.