Bug 228483 - digikam-1.1.0 with system libjpeg-8 breaks image rotation
Summary: digikam-1.1.0 with system libjpeg-8 breaks image rotation
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Bqm-Rotate (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-25 17:00 UTC by Samuli Suominen
Modified: 2017-07-28 03:43 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.2.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuli Suominen 2010-02-25 17:00:17 UTC
Version:           1.1.0 (using KDE 4.4.0)
Compiler:          GNU GCC 4.4.3 
OS:                Linux
Installed from:    Gentoo Packages

This is a clone of http://bugs.gentoo.org/show_bug.cgi?id=306679.

digikam source tree ships a copy of libjpeg-6b, or parts of it, in libs/jpegutils/ , such as transupp.*, which is causing "Image rotation" to break when linked against system jpeg-8

steps to reproduce:

- download and install libjpeg-8 ( http://www.ijg.org/files/jpegsrc.v8.tar.gz )
- compile and link digikam-1.1.0 against it
- try to rotate jpeg files
Comment 1 Dario Andres 2010-02-26 03:17:11 UTC
I wonder if bug 227313 could be related too (same but on Gwenview)
Comment 2 caulier.gilles 2010-02-26 10:26:07 UTC
Darios,

In digiKam core and kipi-plugins/jpeglossless, this want mean to update transupp.* source code with libjpeg version 8.

But we will have regression problem to work properly with older libjpeg, i'm sure...

The uptimate solution will to have transupp.* functions available in libjpeg directly (this code come from 3rdparty from libjpeg), or, as all commercial photo management program do, include all libjpeg source code as well (look xnview for ex.)...

Comments are welcome here.

Gilles Caulier
Comment 3 Samuli Suominen 2010-02-27 13:24:00 UTC
The small but popular image viewer "feh" has the same problem, and with co-ordination with the new upstream, the git is now calling 'jpegtran' binary from the system instead of bundling the jpeg files in the source code. This ensures the compability from jpeg-6b up to soon-to-be-released jpeg-8a.

Maybe not ideal, but works.
Comment 4 Marcel Wiesweg 2010-02-27 14:32:51 UTC
What happens when copying transupp.c/.h from libjpeg-8 to digikam's libs/jpegutils?
Does it compile and work?
Comment 5 caulier.gilles 2010-02-27 20:01:13 UTC
Marcel,

This solution will certainly work with libjpeg 8, but what's about compatibility with version 6 and 7 ???

The best solution : transup source code must be available directly in libjpeg API...

Alternative and fast way, is to include libjpeg 8 in digiKam core as well...
Comment 6 caulier.gilles 2010-02-27 20:05:50 UTC
Marcel,

Forget to said that if we only copy transup version 8 in digiKam core (and jpeglossless plugin too), we must set libjpeg dependency in Cmake script...

Gilles
Comment 7 Marcel Wiesweg 2010-02-27 21:25:34 UTC
My idea was to ship multiple versions of transupp.c. Alternatively, yes, we can include the whole libjpeg and only one transupp.c
The best solution would be to make transupp.h available from libjpeg, as you say. But that does not solve it for us here and now.
Comment 8 Samuli Suominen 2010-03-01 00:01:42 UTC
(In reply to comment #0)
> This is a clone of http://bugs.gentoo.org/show_bug.cgi?id=306679.

(In reply to comment #4)
> What happens when copying transupp.c/.h from libjpeg-8 to digikam's
> libs/jpegutils?
> Does it compile and work?

Seems to work, a user posted a patch here:

http://bugs.gentoo.org/attachment.cgi?id=221563

It bumps the jpeg-6b files to jpeg-8 (slightly modified, like namespace digikam { ... } around it).
Comment 9 Samuli Suominen 2010-03-01 00:19:52 UTC
(In reply to comment #8)
> Seems to work, a user posted a patch here:

Scratch that. It works in "Edit" but not with the arrays you get when you hover mouse over an image. Well, try it out yourself ;)
Comment 10 Andreas K. Huettel 2010-03-01 00:45:27 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Seems to work, a user posted a patch here:
> 
> Scratch that. It works in "Edit" but not with the arrays you get when you hover
> mouse over an image. Well, try it out yourself ;)

True, confirmed. My patch seems to make absolutely no difference. :(
Makes me wonder a bit whether this is really a jpeg-8 issue.
Comment 11 Marcel Wiesweg 2010-03-01 22:06:30 UTC
Well, what happens then? What is the problem? So far I only know that it "breaks".
Comment 12 Andreas K. Huettel 2010-03-02 01:06:26 UTC
(In reply to comment #11)
> Well, what happens then? What is the problem? So far I only know that it
> "breaks".

Well, here's for your convenience all the relevant information from the original report, see also http://bugs.gentoo.org/show_bug.cgi?id=306679

User A reports: 
"Since the Digikam-1.1.0, I can´t rotate any photos, and more there comes a
error message."

1. mark Foto
2. Strg + Umschalt + --> (for rotate right)
3. Enter
-> error message can not rotate this Foto.

Gentoo 64bit
kde-base/kde-meta-4.3.3
media-gfx/digikam-1.1.0
kde-base/gwenview-4.3.3

Later he confirms that this only affects jpeg images. 

User B states:
"Thanks a lot for this bug report (and the cause of it)! I almost despaired of
it, since half of my photos seemed to be corrupt...
As a workaround, I downgraded from media-libs/jpeg-8 to media-libs/jpeg-7 and
now lossless JPEG rotation works again."
Comment 13 Andreas K. Huettel 2010-03-02 01:10:06 UTC
My own observation is that the "rotating arrows" in the main album view have no effect at all. Clicking on them just results in a message on stderr, 

digikam(7864)/KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation =>  1

In the Image Edit window everything works as expected. 

(jpeg-8, tested only with jpeg files.)
Comment 14 k17031965 2010-03-03 18:37:50 UTC
Hallo

Gentoo 64bit

Now i have installed kde-meta-4.3.5
I downgrade to media-libs/jpeg-7 and digikam dosen´t start:

[code]
gentoo64 ~ $ digikam
digikam: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory[/code]

Now i upgarde to media-libs/jpeg-8 and digikam can start, but it can not rotate jpeg files.
Comment 15 k17031965 2010-03-03 18:38:15 UTC
Hallo

Gentoo 64bit

Now i have installed kde-meta-4.3.5
I downgrade to media-libs/jpeg-7 and digikam dosen´t start:

[code]
gentoo64 ~ $ digikam
digikam: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory[/code]

Now i upgarde to media-libs/jpeg-8 and digikam can start, but it can not rotate jpeg files.
Comment 16 Dario Andres 2010-03-03 18:40:50 UTC
If you change your libjpeg (7<->8), you need to recompile Digikam against it...
Comment 17 k17031965 2010-03-03 20:03:43 UTC
(In reply to comment #16)
> If you change your libjpeg (7<->8), you need to recompile Digikam against it...

Ok, Dario Andres

First downgrade to media-libs/jpeg-7
[code]
$ eix media-libs/jpeg
[I] media-libs/jpeg
     Available versions:
        (62)    6b-r9
        (0)     7 [m]8
        (7)     ~7-r1
     Installed versions:  7(20:27:23 03.03.2010)
[/code]

And than recompile media-gfx/digikam-1.1.0.

Digikam can not start.
[code]
~ $ digikam
digikam: error while loading shared libraries: libjpeg.so.8: cannot open shared object file: No such file or directory
[/code]
Do I have something else?
Comment 18 Johannes Wienke 2010-03-03 20:08:02 UTC
After downgrading libjpeg you must remove at least the CMakeCache.txt in the build directory as cmake won't notice the library change otherwise.
Comment 19 Dario Andres 2010-03-03 20:08:49 UTC
Sorry, I forgot about the other dependencies that use libjpeg (Qt and kdelibs).
So, downgrading libjpeg and only some application will break parts of the
system (other apps)
For a full downgrade you will have to downgrade libjpeg and recompile all the
applications/libraries using it..
Regards
Comment 20 Aurelien Gateau 2010-03-04 09:59:56 UTC
I fixed the same bug for Gwenview (Bug #227313). You can have a look at the changes here:
http://websvn.kde.org/?view=revision&revision=1098735

Note that I only tested with libjpeg 6.2 and 8.0, I haven't tried 7.0.

We should try to convince libjpeg devs to include the lossless operation code in the public API :/
Comment 21 Marcel Wiesweg 2010-03-04 18:01:50 UTC
*** Bug 228056 has been marked as a duplicate of this bug. ***
Comment 22 robf 2010-03-04 21:05:21 UTC
Until this is fixed, one quick way to work around it is to batch process the images downloaded by digikam 1.1.0 / libjpeg8 with the utility "jhead" which does exactly what digiKam 1.0.0 /libjpeg7 used to do, i.e. lossless rotation of all jpeg images in the batch that were taken in portrait orientation and setting their exif orientation tag to "normal".  Simply run "jhead -autorot *.jpg".
Comment 23 Marcel Wiesweg 2010-03-07 18:00:56 UTC
SVN commit 1100491 by mwiesweg:

Copying Aurelien's fix

CCBUG: 228483


 A             libjpeg-62 (directory)   trunk/KDE/kdegraphics/gwenview/lib/libjpeg-62#1100490
 A             libjpeg-80 (directory)   trunk/KDE/kdegraphics/gwenview/lib/libjpeg-80#1100490


WebSVN link: http://websvn.kde.org/?view=rev&revision=1100491
Comment 24 Marcel Wiesweg 2010-03-07 18:33:20 UTC
SVN commit 1100511 by mwiesweg:

Completing Aurelien's fix:
Now we use separate directories to compile for libjpeg62 and libjpeg8.
I tested for libjpeg62, and would appreciate testing for libjpeg8.

BUG: 228483

 M  +13 -1     CMakeLists.txt  
 M  +2 -1      NEWS  
 M  +1 -0      digikam/CMakeLists.txt  
 D             libs/jpegutils/jinclude.h  
 D             libs/jpegutils/jpegint.h  
 D             libs/jpegutils/libjpeg-62/transupp.c  
 A             libs/jpegutils/libjpeg-62/transupp.cpp   libs/jpegutils/libjpeg-62/transupp.c#1100505 [License: UNKNOWN]
 M  +5 -0      libs/jpegutils/libjpeg-62/transupp.h  
 M  +68 -63    libs/jpegutils/libjpeg-80/transupp.c  
 M  +6 -0      libs/jpegutils/libjpeg-80/transupp.h  
 D             libs/jpegutils/transupp.cpp  
 D             libs/jpegutils/transupp.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1100511
Comment 25 Andreas K. Huettel 2010-03-17 22:26:08 UTC
Did anyone actually check whether this patch has the desired effect?

I just built digikam from HEAD (rev 1104445) and still cannot rotate images from the main view. No change at all... (see comment #13 for symptoms).

Please reopen.
Comment 26 Marcel Wiesweg 2010-03-18 18:41:34 UTC
Apparently noone checked before. 

When you run CMake, please check the line "Identified libjpeg version:" which should then be 80.
Also please check that libs/jpegutils/libjpeg-80/transupp.cpp is used for compilation (simplest check: rename it and make sure that compilation fails in this case)
Comment 27 Andreas K. Huettel 2010-03-19 00:00:56 UTC
(In reply to comment #26)
> When you run CMake, please check the line "Identified libjpeg version:" which
> should then be 80.

Yes, and that is what I see:
-- Identified libjpeg version: 80

> Also please check that libs/jpegutils/libjpeg-80/transupp.cpp is used for
> compilation (simplest check: rename it and make sure that compilation fails in
> this case)

When I delete libs/jpegutils/libjpeg-80/transupp.cpp between cmake and compilation, the build fails.

[ 21%] make[2]: *** Keine Regel vorhanden, um das Target »/var/tmp/portage/media-gfx/digikam-9999/work/digikam-9999/libs/jpegutils/libjpeg-80/transupp.cpp«, 
  benötigt von »digikam/CMakeFiles/digikamcore.dir/__/libs/jpegutils/libjpeg-80/transupp.o«, zu erstellen.  Schluss.
make[2]: *** Warte auf noch nicht beendete Prozesse...

(tested with current HEAD, Revision 1104930.)
Comment 28 Andreas K. Huettel 2010-04-04 20:34:30 UTC
Bump... please reopen this bug, the issue is NOT fixed.
Comment 29 caulier.gilles 2010-04-04 20:36:38 UTC
Which digiKam release you use ? 1.2.0 ?

Gilles Caulier
Comment 30 Andreas K. Huettel 2010-04-04 21:51:58 UTC
(In reply to comment #29)
> Which digiKam release you use ? 1.2.0 ?
> 
> Gilles Caulier

Yes, 1.2.0. Compiled from sources (Gentoo Linux), with KDE 4.4.2. 
CMake correctly identifies the libjpeg as version 8.
Comment 31 Marcel Wiesweg 2010-04-05 12:05:44 UTC
The fix only affects digikam's version of this code which is used on photo download. I guess the same fix must be applied to the kipi plugin as well.
Comment 32 Marcel Wiesweg 2010-04-05 16:27:20 UTC
*** Bug 233346 has been marked as a duplicate of this bug. ***
Comment 33 caulier.gilles 2010-04-08 16:20:31 UTC
*** Bug 233744 has been marked as a duplicate of this bug. ***
Comment 34 Alex G 2010-05-05 00:00:26 UTC
The rotate/libjpeg8 issue is still present with 1.3:

# emerge -v digikam
...
 *      repository: svn://anonsvn.kde.org/home/kde/trunk/extragear/graphics/digikam
At revision 1122869.
...
-- Identified libjpeg version: 80


Besides the "Digikam::CollectionScanner::scanAlbum: Folder does not exist or is not readable" message, there seemed to be an increase in disk attivity.
Comment 35 Marcel Wiesweg 2010-05-14 18:26:27 UTC
I have seen similar fixes (r1115335, 2010-04-16) have recently been done in the kipi Jpeglossless plugin as well.
Has someone tested with kipi-plugins from SVN?
Comment 36 Bearsh 2010-05-18 13:12:44 UTC
(In reply to comment #35)
> I have seen similar fixes (r1115335, 2010-04-16) have recently been done in the
> kipi Jpeglossless plugin as well.
> Has someone tested with kipi-plugins from SVN?

I applied this commit against kipi-plugins-1.2.0 and it seems to work here (see also https://bugs.gentoo.org/show_bug.cgi?id=306679)
Comment 37 Marcel Wiesweg 2010-05-18 13:45:28 UTC
Ok thanks, marking as fixed now.
Comment 38 Tom Spuhler 2010-08-11 06:01:20 UTC
This bug seems to be still present in 1.3

is this code in cmake correct: 
# Extract version of libjpeg so that we can use the appropriate dir
# See bug #227313, #228483
FILE(READ "${JPEG_INCLUDE_DIR}/jpeglib.h" jpeglib_h_content)
STRING(REGEX REPLACE ".*#define +JPEG_LIB_VERSION +([0-9]+).*" "\\1" jpeglib_version "${jpeglib_h_content}")
MESSAGE(STATUS "Identified libjpeg version: ${jpeglib_version}")

IF ("${jpeglib_version}" LESS 80)
    SET(DIGIKAM_LIBJPEG_DIR libjpeg-62)
ELSE ("${jpeglib_version}" LESS 80)
    SET(DIGIKAM_LIBJPEG_DIR libjpeg-80)
ENDIF ("${jpeglib_version}" LESS 80)

looks like an infinite thing if we have libjpeg8
Comment 39 Tom Spuhler 2010-08-11 07:09:52 UTC
if I install lib64jpeg the rotation works. Seems it solves the Gwenview problem too
Comment 40 Tom Spuhler 2010-08-29 00:01:58 UTC
Too early, but is still there. Can we reopen this?
Comment 41 Marcel Wiesweg 2010-09-01 16:28:04 UTC
- seems to work for most people
- please note the peculiar syntax of CMake IF
http://cmake.org/Wiki/CMake/Language_Syntax#IF_and_WHILE_control_the_flow.
- talking about digikam (camera UI only) or the lossless rotation kipi plugin
Comment 42 Tom Spuhler 2010-09-02 06:48:36 UTC
I think it is the lossless rotation kipi plugin. The picture doesn't turn, only the thumbnail. It has artifacts after downloading from the camera and looked it in slideshow and in preview. I copied it and added it to the Album with the same name, but adding an A. It still showed the problem and the artifacts. I then opened the picture with the Gimp and saved it without doing anything else to it. I now have two picture in the slideshow, one with artifacts, one without.
(BTW this same thing happens on all of may real boxes and the virtual systems.)
Most of the pictures have people on it, but I have a couple w/o a person on it that I could e-mail.If I upload it, then it gets processed and the problem goes away.
The problem doesn't show, if I move the picture file to an old digikam 1.2.0 on a virtual box.kipi-plugins 1.1.0 the same picture looks good too.
I see this mostly from one camera, not from the other. Could it be a EXIF problem?
Comment 43 Marcel Wiesweg 2010-09-02 12:02:11 UTC
Yes, an image affected by this bug (already treated by rotation, but to a wrong result) would be interesting