Bug 228483

I wonder if bug 227313 could be related too (same but on Gwenview)

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

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.

What happens when copying transupp.c/.h from libjpeg-8 to digikam's libs/jpegutils?
Does it compile and work?

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...

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

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.

(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).

(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 ;)

(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.

Well, what happens then? What is the problem? So far I only know that it "breaks".

(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."

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.)

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.

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.

If you change your libjpeg (7<->8), you need to recompile Digikam against it...

(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?

After downgrading libjpeg you must remove at least the CMakeCache.txt in the build directory as cmake won't notice the library change otherwise.

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

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 :/

*** Bug 228056 has been marked as a duplicate of this bug. ***

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".

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

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

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.

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)

(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.)

Bump... please reopen this bug, the issue is NOT fixed.

Which digiKam release you use ? 1.2.0 ?

Gilles Caulier

(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.

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.

*** Bug 233346 has been marked as a duplicate of this bug. ***

*** Bug 233744 has been marked as a duplicate of this bug. ***

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.

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?

(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)

Ok thanks, marking as fixed now.

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

if I install lib64jpeg the rotation works. Seems it solves the Gwenview problem too

Too early, but is still there. Can we reopen this?

- 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

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?

Yes, an image affected by this bug (already treated by rotation, but to a wrong result) would be interesting