https://bugs.kde.org/show_bug.cgi?id=516143
Bug ID: 516143
Summary: thumbnails rotated incorrectly - getExifThumbnail()
uses wrong orientation tag
Classification: Applications
Product: dolphin
Version First unspecified
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: view-engine: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
Summary: getExifThumbnail() uses wrong orientation tag — thumbnails rotated
incorrectly
Description:
KExiv2::getExifThumbnail(true) produces incorrectly rotated thumbnails for
JPEG images where the embedded EXIF thumbnail is stored un-rotated.
Root cause:
In kexiv2exif.cpp, getExifThumbnail() with fixOrientation=true checks
Exif.Thumbnail.Orientation first, and only falls back to Exif.Image.Orientation
if the thumbnail tag is not found:
Exiv2::ExifKey key1("Exif.Thumbnail.Orientation");
Exiv2::ExifKey key2("Exif.Image.Orientation");
// ...
it = exifData.findKey(key1);
if (it == exifData.end())
it = exifData.findKey(key2);
Many phone cameras (e.g. Motorola Moto G54) save the embedded EXIF thumbnail
without rotating the pixel data, and set Exif.Thumbnail.Orientation to top,
left (value 1 = no rotation). The actual intended viewing orientation is only
stored in Exif.Image.Orientation (e.g. value 6 =
90° CW, or value 3 = 180°).
Since Exif.Thumbnail.Orientation is present and equals 1, getExifThumbnail()
finds it, determines no rotation is needed, and returns the un-rotated
thumbnail. It never reaches Exif.Image.Orientation.
Impact:
This affects Dolphin's JPEG thumbnail previews via kio-extras's
jpegcreator.cpp, which calls getExifThumbnail(rotate=true). Thumbnails appear
rotated by 90° or 180° while the full image displays correctly.
Example EXIF data from affected images:
┌────────────────────────────┬────────────────────────────┬───────────────────────────┐
│ Tag │ Affected image (90° wrong) │ Correctly
displayed image │
├────────────────────────────┼────────────────────────────┼───────────────────────────┤
│ Exif.Image.Orientation │ right, top (value 6) │ top, left (value
1) │
├────────────────────────────┼────────────────────────────┼───────────────────────────┤
│ Exif.Thumbnail.Orientation │ top, left (value 1) │ top, left (value
1) │
└────────────────────────────┴────────────────────────────┴───────────────────────────┘
Proposed fix:
getExifThumbnail() should use Exif.Image.Orientation (not
Exif.Thumbnail.Orientation) when rotating the embedded thumbnail, since the
purpose is to match the intended viewing orientation of the main image. The
Exif.Thumbnail.Orientation tag merely describes the current pixel
layout of the embedded thumbnail, which is not what the viewer needs.
Reproducible: Always, with any JPEG from a camera that stores un-rotated
embedded thumbnails.
Related: https://bugs.kde.org/show_bug.cgi?id=472038 (kio-extras: poor
quality / wrong orientation thumbnails from jpg images)
Versions: libkexiv2-qt6 25.12.2, kio-extras 25.12.2, Fedora 43 KDE Plasma
Linux/KDE Plasma: Fedora 43, kernel 6.18.9-200.fc43.x86_64
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1
PS: This is my first bug filed. If I did it wrong - sorry, at least I tried.
--
You are receiving this mail because:
You are watching all bug changes.
