Bug 479356

The question is what your rotation settings are in the digiKam settings under Metadata-> Rotation. In any case, digiKam rotates the embedded thumbnail in the event of a lossless or lossy rotation. If you just do a metadata rotation, of course not.

Please also note that the automatic rotation during import is only carried out on JPG files.

Maik

Created attachment 164662 [details]
Screenshot of DigiKam vs Gimp, GeoSetter and XnViewMP

In this screenshot, we can see that:
- the image rotated by Digikam is badly seen (horizontally or deformed) by Gimp, GeoSetter and XnViewMP
- the thumbnail generated by DigiKam (B) corresponds to a 180° rotation of the thumbnail of the original image (A) (whereas the thumbnail of XnViewMP has been correctly rotated by 90° to be vertical)

(In reply to Maik Qualmann from comment #1)
> The question is what your rotation settings are in the digiKam settings
> under Metadata-> Rotation. In any case, digiKam rotates the embedded
> thumbnail in the event of a lossless or lossy rotation. If you just do a
> metadata rotation, of course not.
> 
> Please also note that the automatic rotation during import is only carried
> out on JPG files.
> 
> Maik

Thanks for your quick reply.

My rotation settings are exactly the same as in the documentation (https://docs.digikam.org/en/setup_application/metadata_settings.html#rotation-settings) :
- Rotate by changing the content if possible
- Write flag to metadata if possible
- Show images/thumbnails according to orientation tag
- Set orientation tag to normal after rotation

I think I have found the root cause of my problem: 
When DigiKam does a 90° rotation to the image, it rotates the thumbnails by 180°
I have join a screenshot to show it.

https://invent.kde.org/graphics/digikam/-/commit/4d3bd40d0431c7382f0d520630502c3a36e464cd

Maik

Git commit fcafdd4d0fcad88d7f2fb0ecf00cd703dbfeb2c8 by Maik Qualmann.
Committed on 06/01/2024 at 16:33.
Pushed by mqualmann into branch 'master'.

Revert "apply intermediate steps to the metadata during image transformation"

M  +23   -30   core/libs/jpegutils/jpegutils.cpp
M  +1    -2    core/libs/jpegutils/jpegutils.h

https://invent.kde.org/graphics/digikam/-/commit/fcafdd4d0fcad88d7f2fb0ecf00cd703dbfeb2c8

(In reply to Maik Qualmann from comment #4)
> https://invent.kde.org/graphics/digikam/-/commit/
> 4d3bd40d0431c7382f0d520630502c3a36e464cd
> 
> Maik

Thanks for this very quick fix.

Of course, I am not able to validate your commit.
But if I can help to test a beta version, don't hesitate to ask me.(In reply to Maik Qualmann from comment #5)
> Git commit fcafdd4d0fcad88d7f2fb0ecf00cd703dbfeb2c8 by Maik Qualmann.
> Committed on 06/01/2024 at 16:33.
> Pushed by mqualmann into branch 'master'.
> 
> Revert "apply intermediate steps to the metadata during image transformation"
> 
> M  +23   -30   core/libs/jpegutils/jpegutils.cpp
> M  +1    -2    core/libs/jpegutils/jpegutils.h
> 
> https://invent.kde.org/graphics/digikam/-/commit/
> fcafdd4d0fcad88d7f2fb0ecf00cd703dbfeb2c8

Thanks for this very quick fix.

Of course, I am not able to validate your commit.
But if I can help to test a beta version, don't hesitate to ask me.

8.3.0 pre-release windows installer is available here to test :

https://files.kde.org/digikam/

Gilles Caulier

There was currently no change because I reset it again. I played with various images and XnViewMP. I can't reproduce any problem. Please send me an image that the problem occurs when importing and rotating.

Maik

(In reply to Maik Qualmann from comment #8)
> There was currently no change because I reset it again. I played with
> various images and XnViewMP. I can't reproduce any problem. Please send me
> an image that the problem occurs when importing and rotating.
> 
> Maik

I have put an example of a picture here: https://drive.google.com/drive/folders/1qrvFQMHzTXKsP506ovbGaIIvwSOZ2HCV?usp=sharing
You will find:
- Original.jpg: the JPG file generated by my canera (Olympus EM1 II)
- Rotate_with_xxx.jpg: the original image rotated by DigiKam and XnViewMP based on the orientation tag
- xxx_thumbnail.jpg: the thumbnails extracted by 'exiftool.exe -b -ThumbnailImage xxx.jpg > xxx_thumbnail.jpg'

Thanks for the sample images. The problem is that Exiv2 has a problem with the Olympus metadata to decode the preview image, so it won't rotate either.

Exiv2 ( 2 ) :  No image data to encode Exif.OlympusCs.PreviewImageStart.

In principle the problem should be reported to Exiv2. Let's see if we can do a workaround here.

Maik

Git commit b15d00a9c6e74dc8aede955efa09fd86a5bde365 by Maik Qualmann.
Committed on 07/01/2024 at 20:04.
Pushed by mqualmann into branch 'master'.

fix rotate EXIF thumbnail
FIXED-IN: 8.3.0

M  +1    -1    NEWS
M  +1    -1    core/libs/jpegutils/jpegutils.cpp

https://invent.kde.org/graphics/digikam/-/commit/b15d00a9c6e74dc8aede955efa09fd86a5bde365

The reason I couldn't reproduce it is because my test images (Nikon, Canon, etc.) all have a preview image. But your Olympus only has an Exif thumbnail image, which we didn't rotate correctly.

Maik

Happy to see that the problem is finaly understood.

I am not sure if I can test the version digiKam-8.3.0-20240107T194535-Win64.exe (retrieve here https://files.kde.org/digikam/) ???
It seems to have been built before your commit.

The version already contains the change.

Maik

I have tested on digiKam-8.3.0-20240107T194535-Win64.exe: 
Everything work fine now.
It seems to also fix another strange behavior when I do the rotation in XnViewMP and see the image in DigiKam (the thumbnail was badly oriented) even if I don't understand how your commit could have fixed that.

Thank you very much for your fix.