Bug 479785 - Photo rotation put some line of pixels at the wrong edge
Summary: Photo rotation put some line of pixels at the wrong edge
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Orientation (show other bugs)
Version: 8.1.0
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-14 05:27 UTC by Hieu Van
Modified: 2024-01-14 08:31 UTC (History)
1 user (show)

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


Attachments
Original photo (unrotated, has flag) (1.95 MB, image/jpeg)
2024-01-14 05:27 UTC, Hieu Van
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hieu Van 2024-01-14 05:27:19 UTC
Created attachment 164893 [details]
Original photo (unrotated, has flag)

STEPS TO REPRODUCE
Certain image sensors do not output a rotated photo according to how the device is held (e.g. holding a phone in portrait orientation), rather, it only sets the rotation flag in the photo. As a result, I have to manually rotate my photos to the correct orientation, and set the flag to "Normal".

OBSERVED RESULT
After rotation, it seems that a few line of pixels are wrongly placed on the other end of the photo. In other words, vertically, the photo should be ABCDEFGH, but in fact, after rotation, it becomes CDEFGHAB. Please see the included attachment.

I guess it's related to EXIF orientation or some other metadata, as photos shot with one device may encounter this bug, but those shot with another device won't.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian GNU/Linux 12
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10

ADDITIONAL INFORMATION
This bug is related to bug #463459
Comment 1 Maik Qualmann 2024-01-14 07:00:29 UTC
Fixed in digiKam-8.3.0, read this Bug 479202 for Gwenview and digiKam to understand the cause.
For this sample image, digiKam must be compiled with libjpeg >= 8 to detect that lossless rotation is not possible.

Maik
Comment 2 Maik Qualmann 2024-01-14 08:17:00 UTC
Git commit edc1cc78e846628dccfcaa22cfd97c4799ccb1ff by Maik Qualmann.
Committed on 14/01/2024 at 09:15.
Pushed by mqualmann into branch 'master'.

add blacklist for unsupported camera models in libjpeg < 8

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

https://invent.kde.org/graphics/digikam/-/commit/edc1cc78e846628dccfcaa22cfd97c4799ccb1ff
Comment 3 Hieu Van 2024-01-14 08:22:10 UTC
(In reply to Maik Qualmann from comment #2)
> Git commit edc1cc78e846628dccfcaa22cfd97c4799ccb1ff by Maik Qualmann.
> Committed on 14/01/2024 at 09:15.
> Pushed by mqualmann into branch 'master'.
> 
> add blacklist for unsupported camera models in libjpeg < 8
> 
> M  +21   -1    core/libs/jpegutils/jpegutils.cpp
> 
> https://invent.kde.org/graphics/digikam/-/commit/
> edc1cc78e846628dccfcaa22cfd97c4799ccb1ff

I doubt whether this is an efficient way to filter out the "unsupported" devices. For example, photos shot with Google Pixel 2 XL may also have this behaviour, but not consistent like the Redmi Note 6 Pro.

Anyway, many thanks for your hard work!
Comment 4 Maik Qualmann 2024-01-14 08:31:15 UTC
In addition to the divisibility of the image size, this is just another help for digiKam versions that are compiled with libjpeg < 8. We strongly recommend using libjpeg >= 8.

Maik