Bug 274947

Created attachment 60633 [details]
The debug-output from "additional information" without the disturbing newlines

Even worse:
If I only import the two portrait pictures "img_1123.jpg" and "img_1124.jpg", I end up with:

  - img_1123.jpg:
     - album view: thumbnail ok (orientation and content)
     - Image Editor: picture content _broken_: reduced to the leftmost 91 pixels (but orientation ok ;)

  - img_1124.jpg:
     - album view: thumbnail ok (orientation and content)
     - Image Editor: requires one "Rotate Left" to be correct (looks like no
auto-rotation took place; but content is ok)

The album I importet those pictures to, lists (dolphin) a file called ".digikam-exifrotate-5917.jpg" with 0 Byte length and timestamp of the last import.

Debug-info from STDOUT will be attached.

Created attachment 60634 [details]
Debug-Output of the case, described in Comment #2

Starts with the click on "Download Selected" in "Import" Window.

Behaviour, described in Comment #2, is not always completely reproduceable:

 - dataloss (reduction of picture width) happens not always. Seems you have to restart digikam. Restarting the Importer or simply deleting ".digikam-exifrotate-5917.jpg" and the imported images did not trigger the failure. Once the running digikam application did an import, another import won't loose data.

 - the file ".digikam-exifrotate-5917.jpg" is always written.

Created attachment 60635 [details]
Debug output for the case of comment #4.

This is the output of a second import-run during the live-cycle of a digikam process. No data was lost in this run.

Difference between #5 and #3:
"Digikam::exifTransform: ExifRotate" is only called once in a digikam process.

The first import-run calls "Digikam::exifTransform: ExifRotate", which kills the content of the first picture (if not exif-orientation == 1). All following pictures of this import and all following imports don't "suffer" under this function call.

Thanks Peter for your complete hack on this file. 

Can you test with 2.0.0-beta6 (or git master source code) to see if problem still reproducible. 1.x version is not maintained now, 2.0.0 is on the way for this summer.

Thanks in advance

Gilles Caulier

I've tried to install digikam 2.0.0_beta6 on my gentoo machine from "kde"-overlay. But this would require me to switch whole KDE to > 4.6.2, which is currently marked unstable in gentoo portage.
This is something I just don't want to do with my productive system.

I'm upgrating a kubuntu installation on my other machine at the moment. But this will take few hours.
Maybe I can reproduce the bug there with 1.9.0 and see it fixed with 2.0.0. ;)

More info tomorrow...

Sequel to #8: (I know I should test 2.0.0_beta6)
I've installed digikam 1.9.0 on my kubuntu machine (kde 4.6.2) and could not reproduce the error there. Importing the same two images (img_1123.jpg and img_1124.jpg) did work flawless.
(That's great for kubuntu users, but does not help me fix the bug.)

To narrow the error down, I compared both of digikam's "Components Information" lists and found the following differences:

gentoo (fails)      |  kubuntu (works)
--------------------+---------------------
LibExiv2: 0.19      |  LibExiv2: 0.21.1
LibJPEG: 80         |  LibJPEG: 62
LibGphoto2: 2.4.10  |  LibGphoto2: 2.4.10.1

There are differences in LibClapack, LibLCMS and LibPNG versions. But I think they don't matter.

The difference in LibJPEG reminds me of last years Bug 228483 (https://bugs.kde.org/show_bug.cgi?id=228483). Maybe it's not yet fixed for "Digikam::exifTransform: ExifRotate".

But as you say: I should test digikam 2.0.0_beta6. But I have not yet an idea how, without putting my productive system at risk of instability. (Maybe I'll setup a virtual machine or something else...)

=> You may close this bug. If I'll find new valuable information, I'll reopen it. Thanks so far for your great work!

Good news: I've managed to install digikam-2.0.0_beta6 on my gentoo test system.
Bad news: Autorotate still does not work on Import from SD-card via USB-Adapter.

Details about the gentoo test system:
  - media-gfx/digikam-2.0.0_beta6
  - kde-base/kdelibs-4.6.80-r1
  - media-libs/jpeg-8b

I took a new testpicture and imported it at:
  - my gentoo test system
  - another machine running kubuntu (see comment #9)

Data from both imports follow:

Created attachment 61143 [details]
The original test picture (copied from sd card via dolphin)

Created attachment 61144 [details]
The test picture after importing it with digikam on my gentoo test system.

Created attachment 61145 [details]
The test picture after importing it with digikam on my kubuntu system.

Everything ok with this file.

Created attachment 61146 [details]
The console output of the import process on the gentoo test system.

Created attachment 61147 [details]
The console output of the import process on the kubuntu system.

Created attachment 61148 [details]
Digikam component information on the gentoo test system.

From "Help" -> "Components Information"

Created attachment 61149 [details]
Digikam component information on the kubuntu system.

Summary of the previous files:


++ Most important component differences:
gentoo:  LibJPEG: 80, LibKDE: 4.6.80 (4.7 Beta1)
kubuntu: LibJPEG: 62, LibKDE: 4.6.2 (4.6.2)


++ Important differences in the import logs:
gentoo_import.log is missing the following lines:
----------------- 8< -------------------
> digikam (core) Digikam::exifTransform: ExifRotate: set Orientation tag to normal:  "/home/px79/Pictures/.digikam-camera-tmp1-1769IMG_1350.JPG"
> KEXIV2 KExiv2Iface::KExiv2::setImageOrientation: Exif.Image.Orientation tag set to:  1
> KEXIV2 KExiv2Iface::KExiv2::KExiv2Priv::saveToFile: File Extension:  "jpg"  is supported for writing mode
> KEXIV2 KExiv2Iface::KExiv2::save: Metadata for file ' .digikam-exifrotate-1769.jpg ' written to file.
----------------- >8 -------------------

The last line with "KEXIV2 KExiv2Iface::KExiv2::getImageOrientation: Orientation => Exif.Image.Orientation =>"
gentoo: 8
kubuntu: 1


++ Further steps
I'm going to try to do some debugging with gdb/Eclipse. But I can't say whether I'll find time for this in the next hours.

The last line with "KEXIV2 KExiv2Iface::KExiv2::getImageOrientation:
Orientation => Exif.Image.Orientation =>"
gentoo: 8
kubuntu: 1

This information is provided by Exiv2 library through libkexiv2, by this method :

https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/revisions/master/entry/libkexiv2/kexiv2image.cpp#L220

Check libkexiv2 and exiv2 library version used for each digiKam. Go to "Help/Components Info" for details

Gilles Caulier

(In reply to comment #19)
> Check libkexiv2 and exiv2 library version used for each digiKam. Go to
> "Help/Components Info" for details

Those are attachment 61148 [details] (comment #16) and attachment 61149 [details] (comment #17). There is no difference: Both are "LibExiv2: 0.21.1"

I have a different theory: 
Somehow "Digikam::exifTransform: ExifRotate" fails (maybe, because of LibJPEG: 80)
And since rotation could not finish, "Exif.Image.Orientation" stays "8" at the gentoo system.

Debugging finished!

Result: I guess there is some wrong header-file mixup with libjpeg-80 at gentoo:

Autorotation terminates premature with error (but does not print an error message, see bug #276154):


The error is recognized and autorotation is terminated:
>  info->crop_yoffset >= info->output_height
>   (= 3067336080)         (= 2352)

at Thread [3] 24951 (Suspended : Step)	
>	Digikam::jtransform_request_workspace() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/libs/jpegutils/libjpeg-80/transupp.cpp:974  	
>	Digikam::exifTransform() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/libs/jpegutils/jpegutils.cpp:500  	
>	Digikam::CameraController::executeCommand() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/utilities/cameragui/controller/cameracontroller.cpp:595  	
>	Digikam::CameraController::run() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/utilities/cameragui/controller/cameracontroller.cpp:392  	
>	0xb4e05bf3	
>	start_thread() at 0xb42d4d23	
>	clone() at 0xb4876c3e	


the reason for this:
 "info->crop_yoffset_set" should be "JCROP_UNSET", but is set to: 
>   crop_yoffset_set	Digikam::<anonymous enum>	134814873	

at 
>	Digikam::jtransform_request_workspace() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/libs/jpegutils/libjpeg-80/transupp.cpp:972


the reason for this:
 the second parameter to "jtransform_request_workspace(...)" at line 500 is already "defect"


the reason for this:
 "jpeg_transform_info transformoption" initializes wrong with:

>	transformoption	struct {...}	{...}	
>		transform	Digikam::<anonymous enum>	3060823808	
>		perfect	boolean	-1342727432	
>		trim	boolean	-2122803149	
>		force_grayscale	boolean	173864816	
>		crop	boolean	120	
>		crop_width	JDIMENSION	3077679352	
>		crop_width_set	Digikam::<anonymous enum>	Digikam::JCROP_UNSET	
>		crop_height	JDIMENSION	0	
>		crop_height_set	Digikam::<anonymous enum>	5	
>		crop_xoffset	JDIMENSION	6501	
>		crop_xoffset_set	Digikam::<anonymous enum>	Digikam::JCROP_UNSET	
>		crop_yoffset	JDIMENSION	3067352464	
>		crop_yoffset_set	Digikam::<anonymous enum>	134814873				# << defekt!
>		num_components	int	-1234082352	
>		workspace_coef_arrays	jvirt_barray_ptr *	0x805df14	
>		output_width	JDIMENSION	1	
>		output_height	JDIMENSION	3077676996	
>		x_crop_offset	JDIMENSION	2822188688	
>		y_crop_offset	JDIMENSION	3077679792	
>		iMCU_sample_width	int	-1472778648	
>		iMCU_sample_height	int	-1217373654	

at Thread [3] 25175 (Suspended : Step)	
>	Digikam::exifTransform() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/libs/jpegutils/jpegutils.cpp:343  	
>	Digikam::CameraController::executeCommand() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/utilities/cameragui/controller/cameracontroller.cpp:595  	
>	Digikam::CameraController::run() at /var/tmp/portage/media-gfx/digikam-2.0.0_beta6/work/digikam-2.0.0-beta6/core/utilities/cameragui/controller/cameracontroller.cpp:392  	
>	0xb4e0fbf3	
>	start_thread() at 0xb42ded23	
>	clone() at 0xb4880c3e

I filed a bug at the gentoo bug tracker:
http://bugs.gentoo.org/show_bug.cgi?id=372429

Thanks for your work Peter. As you filed a Gentoo bug, is this a Gentoo-only problem that needs to be fixed in Gentoo, or can we do anything?

I would say the "gentoo-only" nature is based on the fact, that gentoo seems one of few linux distros using libjpeg-80 in favour to libjpeg-62 at the moment. (Or gentoo is one of few distros using 80 _and_ has users posting at bugs.kde.org.)

I believe it's closely related to Bug #228483. So I think, you could help, too.

According to bug 228483 comment 24 (https://bugs.kde.org/show_bug.cgi?id=228483#c24) the following files have been removed and replaced version-62 / version-80:
 - libs/jpegutils/transupp.cpp  
 - libs/jpegutils/transupp.h  

"transupp.h" contains the troublemaking structure: jpeg_transform_info
And its very different in version 62 and version 80.

The failed structure initialization (see comment 21) takes place at "core/libs/jpegutils/jpegutils.cpp" (line 343). And jpegutils.cpp is _not_ splitted into version 62 and version 80. Maybe this is the problem.

I'm no expert at gentoo's unpack, prepare, configure, compile, ... process. 
I'm also no C(++) pro. So all I can do further is guessing or learning. ;)
But the latter would take some time...

The file header of "core/libs/jpegutils/jpegutils.cpp" says:
> ...
> Copyright (C) 2006-2011 by Gilles Caulier
> ...

Maybe that's hint to get help. ;)

I'd love to help, but I'll go on a four-week trip in a few days and still have lots of stuff to do before... :| Bugfixing for Gentoo may slow down a bit during that time.

@Andreas:
I thought of you, secretly. ;)
But I guess it would not be polite to add someone else to the CC-List.

But don't worry. It's not a urgent bug.
> jhead -autorot *.jpg
is a workaround I can live with. But we should not forget this bug.

I wish you a nice trip! 

---
Of course everybody else, feeling like to "kick some bugs ass", is welcome to look at this bug. I believe there are plenty of bugs left for Andreas, when he comes back. ;)

Git commit 129c057de2258196396413895bd329b534598644 by Marcel Wiesweg.
Committed on 01/07/2011 at 14:44.
Pushed by mwiesweg into branch 'master'.

Initialize additional parameters that were added to the structure.

CCBUG: 274947

M  +5    -0    libs/jpegutils/jpegutils.cpp     

http://commits.kde.org/digikam/129c057de2258196396413895bd329b534598644

I assume we need to initialize the two additional parameters as well that were 
added to transform_info, in particulat, setting crop to false so that all the 
crop parameters are ignored. So far, crop was unitialized.
Please test my commit, as I have libjpeg-62 and cannot test.

(In reply to comment #28)
> I assume we need to initialize the two additional parameters as well that were 
> added to transform_info, in particulat, setting crop to false so that all the 
> crop parameters are ignored. So far, crop was unitialized.
> Please test my commit, as I have libjpeg-62 and cannot test.

Yes, your patch in comment #27 did fix the bug! (*hurray*)

How I compiled:

 - I "started to install" digikam-2.0.0_rc
    # ebuild digikam-2.0.0_rc.ebuild configure
 - applied your patch in comment #27 (although the line numbers differed a little bit, I could find the correct place to insert those 5 lines)
 - and finally compiled and installed digikam
    # ebuild digikam-2.0.0_rc.ebuil merge

How I tested:
 - I took a new photo in portrait layout
 - imported this photo from sd card with "auto-rotate/flip image" enabled

The test results:
 - the missing four log lines of comment #18 are now printed to stdout
 - the photos in digikam are rotated correctly
 => everything fine! :)

Further steps todo:
 - this bugfix should find it's way to digikam-2.0.0_rc or digikam-2.0.0[_final]
 - this bug can be closed (FIXED!)

Thanks to everyone!