Bug 259182 - Jpg image shows corrupt in view and edit mode
Summary: Jpg image shows corrupt in view and edit mode
Alias: None
Product: digikam
Classification: Unclassified
Component: ColorManagement-Views (show other bugs)
Version: 1.6.0
Platform: Unlisted Binaries Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2010-12-08 01:23 UTC by Graham Watson
Modified: 2022-02-01 11:31 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0

Test image that shows the corruption (869.51 KB, image/jpeg)
2010-12-08 01:29 UTC, Graham Watson
Screenshot of digikam opening the test image (650.88 KB, image/png)
2010-12-08 19:53 UTC, Graham Watson
Screenshot of Gimp opening the test image (411.41 KB, image/png)
2010-12-08 19:53 UTC, Graham Watson
tar of the test image (864.37 KB, application/x-gzip)
2010-12-08 19:59 UTC, Graham Watson
showfoto svn (1.7.0) with libjpeg 8.0 : no problem... (687.20 KB, image/png)
2010-12-08 21:12 UTC, caulier.gilles
Digikam 1.6 with no jpeg62 bugg (418.12 KB, image/png)
2010-12-14 17:40 UTC, Philip Johnsson

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Watson 2010-12-08 01:23:18 UTC
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
Comment 1 Graham Watson 2010-12-08 01:29:19 UTC
Created attachment 54278 [details]
Test image that shows the corruption
Comment 2 caulier.gilles 2010-12-08 06:51:06 UTC
Which LibJPEG you use ? Go to Help/Component Info for details.

Gilles Caulier
Comment 3 caulier.gilles 2010-12-08 06:53:58 UTC
Not reproducible here under Mandriva 2010.1 with current implementation from svn and libjpeg 8.0

Gilles Caulier
Comment 4 Graham Watson 2010-12-08 19:46:49 UTC
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
Comment 5 Graham Watson 2010-12-08 19:53:07 UTC
Created attachment 54316 [details]
Screenshot of digikam opening the test image
Comment 6 Graham Watson 2010-12-08 19:53:39 UTC
Created attachment 54317 [details]
Screenshot of Gimp opening the test image
Comment 7 Graham Watson 2010-12-08 19:59:53 UTC
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.
Comment 8 caulier.gilles 2010-12-08 21:12:50 UTC
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
Comment 9 Graham Watson 2010-12-08 21:35:43 UTC
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:

  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

  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:

  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
Comment 10 Graham Watson 2010-12-08 21:40:48 UTC
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.
Comment 11 caulier.gilles 2010-12-09 01:03:48 UTC
It's a compile time dependency. to use libjpeg 8.0, digikam need to be recompiled...

Gilles Caulier
Comment 12 Philip Johnsson 2010-12-14 17:40:13 UTC
Created attachment 54550 [details]
Digikam 1.6 with no jpeg62 bugg
Comment 13 Philip Johnsson 2010-12-14 17:41:27 UTC
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.

Comment 14 Graham Watson 2010-12-14 21:23:24 UTC
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.

Comment 15 Graham Watson 2010-12-14 21:28:14 UTC
I believe I have a lead. The bug only occurs when you switch on colour management.
Comment 16 caulier.gilles 2010-12-14 21:41:19 UTC
We need to know the full CM config. Also all ICC profile files used in your settings...

Gilles Caulier
Comment 17 Graham Watson 2010-12-14 22:03:12 UTC
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?
Comment 18 Marcel Wiesweg 2010-12-14 23:14:49 UTC
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.
Comment 19 Marcel Wiesweg 2010-12-15 13:46:03 UTC
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
Comment 20 caulier.gilles 2010-12-15 13:54:07 UTC
Marcel, you only patch GoSC2010 branch, not trunk ?

Gilles Caulier
Comment 21 Marcel Wiesweg 2010-12-15 14:32:17 UTC
Ah yes, it should be backported. My SVN checkout from trunk is broken atm, I need to fix it.