Fedora Account System
Red Hat Associate
Red Hat Customer
Since F45, portrait orientation image files are rendered sideways for both generated thumbnails, as well as when viewing them with loupe. Using eog instead (which doesn’t use glycin) works fine. This worked fine on F44. I’ll link the corresponding upstream issue with more technical details. Reproducible: Always Steps to Reproduce: 1. Have an image file with the EXIF Orientation set to 90° or 270°, and a suitably large MakerNote tag (see upstream issue). 2a. Display it with loupe, or 2b. Render a thumbnail with `glycin-thumbnailer --size=256 --input=file:///path/to/image-file.jpg --output=/tmp/thumbnail.png` Actual Results: 2a.: The image file is displayed sideways 2b.: The generated thumbnail file is sideways Expected Results: 2a.: The image file is rendered right side up 2b.: The generated thumbnail file is generated right side up
Hmm, ignore my comment that it works with eog (it doesn’t). GIMP uses its own loaders and asks the user if the files should be rotated when loading, though.
Proposed as a Blocker for 45-final by Fedora user nphilipp using the blocker tracking app because: This bug is a regression over F44 and causes portrait images to be displayed, or their thumbnail files to be rendered, sideways, affecting the final release criteria of basic functionality for the image viewer and file manager, respectively.
Well, I haven't seen this with my own files lately. How common is the "suitably large MakerNote tag"?
Ah, my camera is Fuji, so I guess that explains that. So this is more accurately classed as "quite a lot of" such files.
(In reply to Adam Williamson (Fedora) from comment #4) > Ah, my camera is Fuji, so I guess that explains that. So this is more > accurately classed as "quite a lot of" such files. Right, I should have been more precise. I’ve checked a couple of cameras we’ve had over the years and it seems to depend entirely on the model whether or not portrait pictures are rendered right-side-up.
+5 in https://forge.fedoraproject.org/quality/blocker-review/issues/2203 , marking accepted.
This is now fixed upstream with https://gitlab.gnome.org/GNOME/glycin/-/merge_requests/489 , so setting POST. Not sure if we're expecting a new glycin release or planning to backport this.
There should be no need to backport or wait for a new release as long as I build the pending glycin update after gufo-exif v0.5.2. I hope to have time for that tomorrow.
> There should be no need to backport or wait for a new release as long as I build the pending glycin update after gufo-exif v0.5.2. Please note that gufo-exif v0.5.3 was released shortly after: https://bugzilla.redhat.com/show_bug.cgi?id=2550118
FEDORA-2026-f9ec8977c2 (glycin-2.2.2-1.fc45, rust-glycin-4.0.2-1.fc45, and 5 more) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-f9ec8977c2
FEDORA-2026-7d5c0b0c7d (loupe-51.0-2.fc46) has been submitted as an update to Fedora 46. https://bodhi.fedoraproject.org/updates/FEDORA-2026-7d5c0b0c7d
FEDORA-2026-7d5c0b0c7d (loupe-51.0-2.fc46) has been pushed to the Fedora 46 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-f9ec8977c2 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-f9ec8977c2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-f9ec8977c2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-f9ec8977c2 (glycin-2.2.2-1.fc45, loupe-51.0-2.fc45, and 6 more) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.