SUMMARY Rotating JPEG images via the “Actions” sidebar in Gwenview causes EXIF metadata to be lost upon saving, even in recent versions (e.g. 24.12.3). This appears to perform a destructive recompression instead of a lossless EXIF-based rotation. STEPS TO REPRODUCE 1. Open a JPEG image in Gwenview. 2. Use the “Actions” sidebar > click “Rotate Left” or “Rotate Right”. 3. Close Gwenview; a dialog appears asking whether to save changes — choose “Save”. OBSERVED RESULT The resulting image has no EXIF metadata (e.g. DateTimeOriginal, camera info, orientation tag). The file appears to have been re-encoded, and all original metadata is lost. EXPECTED RESULT Rotation should be performed losslessly by modifying the EXIF orientation flag whenever possible. If actual recompression is necessary, the original EXIF metadata should be preserved and copied to the new file. SOFTWARE/OS VERSIONS Windows: N/A macOS: N/A Linux/KDE Plasma: KDE neon 6.0 (based on Ubuntu 22.04 LTS) KDE Plasma Version: 6.0.x KDE Frameworks Version: 6.x Qt Version: 6.x Gwenview Version: 24.12.3 Install source: Official KDE Neon repositories (not Snap, not Flatpak) ADDITIONAL INFORMATION This behavior is unexpected from an image *viewer*, and may result in silent data loss. Many users expect viewers to handle rotations non-destructively. Suggestion: Gwenview should default to performing **lossless EXIF-based rotations**, preserving all metadata. Only when combining multiple edits (crop, resize, filters, etc.) should destructive save operations be triggered — and even then, metadata should be retained when possible.
sorry, my bad - correct Software Versions featured below: KDE Plasma: KDE neon 6.0 (based on Ubuntu 22.04 LTS) Kernel: x86_64 Linux 6.11.0-21-generic KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Gwenview Version: 24.12.3 Install source: Official KDE Neon repositories (not Snap, not Flatpak)
For what it's worth, I can't reproduce using the same steps on Fedora KDE 42 and Gwenview 25.04.0. Just to double-check, does the issue persist on your device with that updated Gwenview version? If so, I wonder if there's possibly some difference in underlying libraries between the Neon/Ubuntu base and the Fedora base? Thanks!
Well, I have updated my system once again to make sure that I don't cause anyone unnecessary work with my report: Gwenview: 25.04.0 KDE Frameworks: 6.13.0 Qt: 6.8.3 wird verwendet und gebaut wurde mit 6.8.3 KDE neon 6.3 (Wayland) Build ABI: x86_64-little_endian-lp64 Kernel: linux 6.11.0-24-generic I have again rotated 18 jpegs with extensive metadata in Gwenview. I answered the query about saving the changes when closing Gwenview with yes - all images were rotated as desired and again all exif data was lost. Please let me know what further information you need to resolve the issue. best regards, Fritz Sicher versendet mit Proton Mail. John Kizer <bugzilla_noreply@kde.org> schrieb am Montag, 21. April 2025 um 18:56: > https://bugs.kde.org/show_bug.cgi?id=502987 > > John Kizer john.kizer@proton.me changed: > > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Platform|KDE Linux |Neon > CC| |john.kizer@proton.me > Status|REPORTED |NEEDSINFO > > --- Comment #2 from John Kizer john.kizer@proton.me --- > > For what it's worth, I can't reproduce using the same steps on Fedora KDE 42 > and Gwenview 25.04.0. > > Just to double-check, does the issue persist on your device with that updated > Gwenview version? If so, I wonder if there's possibly some difference in > underlying libraries between the Neon/Ubuntu base and the Fedora base? > > Thanks! > > -- > You are receiving this mail because: > You reported the bug.