| Summary: | PNG and HEIF not rotated correctly | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | ferse_palette.0y |
| Component: | Plugin-DImg-HEIF | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | caulier.gilles, ferse_palette.0y, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 8.7.0 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/16fccfe8e8fa19e31ccac38321fc8e839294a8ae | Version Fixed In: | 8.8.0 |
| Sentry Crash Report: | |||
| Attachments: |
HEIF-file rotated correctly in digikam, but appearing rotated 90 to the left in MacOS Preview and Photos
Screenshot of the rotation options in digikam Screenshot of how the files appear after the rotate based on EXIF tool in the BQM |
||
To share large files uses cloud web service. This isn't actually a digiKam bug. Some of it also depends on the rotation settings in digiKam. Please take a screenshot of your rotation settings in digiKam. Your HEIF sample is only rotated using Exif metadata. By default, digiKam respects Exif rotation. Other graphics programs may not be able to do this, or Exif rotation may need to be enabled. To ensure that users see everything correctly when sharing images, images should be rotated using pixel rotation and the Exif metadata flag should be set back to "normal." digiKam can do all of this via the rotation settings. Note that pixel rotation can lead to image loss, depending on the format. However, digiKam performs lossless rotation for JPG images, for example, if the image allows it. https://docs.digikam.org/en/setup_application/metadata_settings.html#rotation-settings Maik Thank you for your quick replies Gilles and Maik! First of all, here’s the link to the PNG-file: https://lufi.ethibox.fr/r/Cno3AtmQAx#myCc3PjC/xTi8cn/o3LKVa/IlvVNjW6RZAcbQYa/ae0= I’ll try your suggestions Maik and report back! I also use a macbook pro and i can confirm that Apple Applications do not support well the Exif rotation tags. Created attachment 185317 [details]
Screenshot of the rotation options in digikam
Hello again, here’s the screenshot of the rotation options. All the previously shared images have been produced with these settings.
(In reply to caulier.gilles from comment #4) > I also use a macbook pro and i can confirm that Apple Applications do not > support well the Exif rotation tags. Is there a way to force digikam to not use the Exif rotation tags? I thought the option I posted a screenshot of made sure this was the case, but maybe the batch queue manager ignores this setting? And for HEIF specifically: is there a way to make it work somehow? In my case, even using the Item - Auto Rotate/Flip Using Exif Information tool didn’t do anything. I was a bit less surprised that the HEIF-files didn’t turn out so well, since the standard is more recent. What I was more surprised about was the funny behaviour of some of the PNG files, like the one I sent you a link of, and the one I sent to a friend that he received flipped. In any way, thank you very much for your support! If I can send more test data, I’m happy to help! >Is there a way to force digikam to not use the Exif rotation tags? I thought the option I posted a screenshot of made sure this was the case, but >maybe the batch queue manager ignores this setting?
No. These settings are used everywhere in digiKam...
For the HEIF, the problem must come from the read only support of this kind of file type by Exiv2 backend used to manage metadata (the default). To baypass this problem, you can switch to ExifTool backend, which is a little powerful in write support but a little bit slowly. Look in metadata setup page to find the right option to turn on.
Best
Gilles Caulier
(In reply to caulier.gilles from comment #7) > To > baypass this problem, you can switch to ExifTool backend, which is a little > powerful in write support but a little bit slowly. Look in metadata setup > page to find the right option to turn on. Great, thank you. This does at least modify the HEIF-files when I rotate them in digikam, which is a step forward. However, there is still a strong disconnect between how they appear in digikam and how they appear in the MacOS tools. In addition, now the Auto Rotate/Flip Using Exif Information function actually does something with the HEIF-files. But still it doesn’t synchronise what I see in the different tools. In regard to the PNG-file I sent over earlier, is there anything that can be done to prevent this from happening? Do you also see that it appears differently in different tools? Have a great day and week-end ! You just need to check the box for lossy rotation in the settings, that's all. And you should enable writing metadata with ExifTool. Maik (In reply to Maik Qualmann from comment #9) > You just need to check the box for lossy rotation in the settings, that's > all. And you should enable writing metadata with ExifTool. Thank you. What I don’t understand: 1) How does that affect rotation of PNG images? PNGs are always lossless, right? Do you have an explanation for the behaviour of digikam with the file I sent earlier? 2) When I activate the box for lossy rotation, the HEIF gets indeed rotated when I force it through Auto Rotate/Flip Using Exif Information, but then it is also rotated with loss, when before I saved it lossless (I chose the lossless HEIF export). Is there a way to rotate HEIF lossless, or is HEIF-support still too marginal / recent? Have a great day! yes PNG is lossless. In fact it use an opensource LZW compression (zip like). Result files are huge in all case. It support 16 bits color depth. HEIF can be lossless or not. Compression uses wavelets (eg. mp4). It support 12 bits color depth. HEIF is typically the replacement of JPEG in phone, even if it's patented and require more computation to compress/uncompress. HEIF is mature at less to be used in production. More details : https://docs.digikam.org/en/supported_materials/image_formats.html Gilles Caulier Thank you Gilles. Yes, I know the formats, and that’s why I was a bit confused. To make sure we understand each other correctly, I’ll try to rephrase my questions: 1) How come I can’t get digikam to export a PNG that is rotated correctly right away and shows up correctly in all applications? For you to be able to reproduce my issue, I uploaded the following TIFF: https://lufi.ethibox.fr/r/nqyWj_B3Ac#xgihDm7NzPpDGWY7D7sBvNbMM2oygzE3eRK7Moco1SM= Procedure to reproduce: you load this TIFF in your gallery, then go to batch queue manager (doesn’t make sense for one picture of course, but all these images were in a workflow), then select as only action to export to PNG. The result, for me, is a PNG which has some rotation information incorporated, at least the thumbnail is rotated by 90 degrees (it’s the image I uploaded previously: https://lufi.ethibox.fr/r/Cno3AtmQAx#myCc3PjC/xTi8cn/o3LKVa/IlvVNjW6RZAcbQYa/ae0=). Only if I then go to "Item - Auto Rotate/Flip Using Exif Information", the resulting PNG is formatted correctly with a thumbnail that is correct and recognised correctly by all the other programs. But that shouldn’t be a necessary step normally, right? This happens regardless of whether I use ExifTools for the Exif information, and it happens although all the rotation settings are set to prefer rotating the content. 2) Is there a way to export correctly oriented lossless HEIF-files with digikam that can be read by the Apple tools? Steps to reproduce: a) Use the TIFF I shared above (https://lufi.ethibox.fr/r/nqyWj_B3Ac#xgihDm7NzPpDGWY7D7sBvNbMM2oygzE3eRK7Moco1SM=), import it in digikam b) add it to batch queue manager c) as only step select exporting to HEIF (lossless) The result, for me, is a HEIF-file that is rotated by 90 degrees (both thumbnail and real picture), at least as seen by Apple Preview. In that case, I cannot even use the "Item - Auto Rotate/Flip Using Exif Information"-trick, since I didn’t find a way to rotate a HEIF-file in a lossless manner. "Item - Auto Rotate/Flip Using Exif Information" will only do something to the file if I accept lossy rotation. I hope that was clearer, it’s not easy to explain! :) Thank you anyway for your patience, and have a nice evening! 1) When converting from TIFF to PNG, the image is of course not automatically rotated; the PNG is aligned identically to the TIFF. The step of automatically rotating according to Exif information is necessary. The lossy rotation option must be enabled for this. There is no loss with PNG, however, because the compression algorithm is not lossy. 2) The same as with PNG, but the HEIF image must be re-encoded, so loss may occur. It's best to temporarily disable the display of images rotated according to Exif information in digiKam. Then you'll see images as your users see them with programs that don't support this. The only thing we might actually need to do is add an option/tool in BQM to rotate images based on Exif information. Maik I just saw that this tool already exists under Transform/Rotate (not the Auto-Rotate tool). By default, it can rotate based on Exif information. Always add this tool first, then the tool for converting to the appropriate image format. This way, there's no double encoding, for example, with HEIF images. I'm closing this bug report. Maik Thank you, Maik, for your time. I appreciate it. Since you took your precious time, I decided to take some of mine to respond, and test some more things. (In reply to Maik Qualmann from comment #13) > 1) When converting from TIFF to PNG, the image is of course not > automatically rotated; the PNG is aligned identically to the TIFF. The step > of automatically rotating according to Exif information is necessary. That makes sense once you know it, but I can’t help it finding it somehow unintuitive. If I were to program digikam just for me, I’d add a setting in the export options of batch queue manager (BQM) to auto-rotate before saving. I know there could be several opinions on this, just sharing my data point. > The lossy rotation option must be enabled for this. This is the most unintuitive thing for me. I would strongly suggest rewording the UI options then. I read this: Rotate by changing the content if possible → rotate all the lossless formats when it’s possible (or the lossy ones where lossless rotation is possible) Even allow lossy rotation if necessary → even rotate the lossy formats But what you actually say is that I need to check the lossy box for it to rotate lossless formats like TIFF and PNG. This doesn’t make sense to me at all. Again, maybe it’s just me, but for this one, I’m more confident that many other users might feel this way. > 2) The same as with PNG, but the HEIF image must be re-encoded, so loss may > occur. Now that I understood the logic, it worked both with PNG and HEIF — by manually auto rotating (using "Auto Rotate/Flip Using Exif Information") the TIF before exporting. See below. > It's best to temporarily disable the display of images rotated according to > Exif information in digiKam. Then you'll see images as your users see them > with programs that don't support this. Interesting. It’s not quite how MacOS programs show the images, but it’s still useful. > I just saw that this tool already exists under Transform/Rotate (not the Auto-Rotate tool). By default, it can rotate based on Exif information. > Always add this tool first, then the tool for converting to the appropriate image format. This way, there's no double encoding, for example, with > HEIF images. The tool looks indeed like the right one, but unfortunately it produces very surprising results. Neither the PNG or the HEIF that resulted from it were rotated correctly in digikam. Not even the TIF alone was rotated correctly. However, for whatever reason, the HEIF was rotated correctly in MacOS. Anyway, that was all too little reproducible for me. Since I wanted to contribute for future users, I ran some more tests with the options you suggested. Long story short: the only thing that worked fine was: allowing lossy rotation (see above on my opinion on this :) ), manually auto rotating (using "Auto Rotate/Flip Using Exif Information"), then exporting (using BQM) to HEIF or PNG (both worked fine). If lossy rotation was not allowed, things didn’t go well. To allow you to reproduce the steps, I uploaded the images with names that explain the previous steps: https://lufi.ethibox.fr/r/Eep4QQ6T41#5SmthAbR0zjTdt3qBdZ3fbZSg6PnC5nRyUYdBZdu6po= If you think there is a value in one of the three things that I mentioned (1) incorporate rotation before export as an option; 2) rename lossy option or change the way it works; 3) change the working Auto-Rotation option in BQM to work like the option in the Item menu), I’d be happy to rephrase them or create separate items for them. In the meantime, I don’t touch anything. Have a great day, and all the best! Hi again, Since I’m not sure if you can see my last comment if I don’t reopen the bug, I’m reopening it so that you can see it. Have a great day! Git commit 16fccfe8e8fa19e31ccac38321fc8e839294a8ae by Maik Qualmann. Committed on 04/10/2025 at 19:30. Pushed by mqualmann into branch 'master'. rotate the pixels of image formats that are known to be lossless FIXED-IN: 8.8.0 M +15 -29 core/libs/fileactionmanager/fileworkeriface.cpp https://invent.kde.org/graphics/digikam/-/commit/16fccfe8e8fa19e31ccac38321fc8e839294a8ae We read new messages even after the bug report has been closed. Formats like PNG or TIFF are now rotated even if the lossless option isn't enabled. I don't think changing the option description is necessary. An option in the BQM for automatic rotation during export could be added, but even this option wouldn't always achieve the desired result. You just have to know that the correct orientation flag is present in the metadata. For example, with scanned images, it's usually not present. We recently developed an AI tool for rotation that tries to find the correct orientation based on the image. The BQM has the tools to do this; you just have to select the right ones. Maik Hi Maik, Thank you very much for your reply, and for the fix! I tried to reply to all your comments. The most important one, in my view, is my last comment. (In reply to Maik Qualmann from comment #18) > We read new messages even after the bug report has been closed. OK, thank you for letting me know. I’ll take that into account in the future! > Formats like PNG or TIFF are now rotated even if the lossless option isn't > enabled. I don't think changing the option description is necessary. Oh, great, that’s even better! Then of course the description doesn’t need changing! :) > An option in the BQM for automatic rotation during export could be added, > but even this option wouldn't always achieve the desired result. I’m sorry, but I’ve been trying to understand, but I’m not sure I do. Do you mean that even if the images appear to be rotated correctly in digikam, this automatic rotation would not work the same way a manual "Auto Rotate/Flip Using Exif Information" would work? I know there are two kinds of "automatic" rotations (it’s unfortunate they have similar names): 1) is the kind of "Auto Rotate/Flip Using Exif Information", which reads the EXIF rotation information, rotates the pixels accordingly, and removes the EXIF information. 2) is the kind you recently developed in the BQM, and which detects, with AI, the correct orientation of the picture. I tried it, and it’s pretty cool, although it still has some misses of course. When I mentioned the BQM option for automatic rotation during export, I meant the first kind, the one replacing a manual "Auto Rotate/Flip Using Exif Information". > The BQM has the tools to do this; you just > have to select the right ones. This is the most important of my comments: did you manage to reproduce the thing that I think is a small bug in the auto rotation tool in BQM? I’m not sure if I phrased my previous message well on that. I think I have selected the right tools (I didn’t use the auto rotation using AI, I used the tool that is called "Rotate — A tool to rotate images" and kept the default setting "Use Exif Orientation". I thought it is the one supposed to replace the manual "Auto Rotate/Flip Using Exif Information" in the standard interface. But the result I got was very different. This is what I tried to illustrate through the many pictures I uploaded here: https://lufi.ethibox.fr/r/Eep4QQ6T41#5SmthAbR0zjTdt3qBdZ3fbZSg6PnC5nRyUYdBZdu6po= Even inside of digikam, the images were sometimes not rotated correctly after using this tool, although they were initially. Maybe I should open a separate bug report for this, I don’t know. I didn’t want to open too many, but maybe this long conversation is too difficult to follow otherwise. Have a great day, and thanks a lot for your replies! I haven't downloaded the last images, and they're no longer available. Upload an image that you think isn't being processed correctly so I can test it. One more tip: you'll never always achieve the desired result by automatically rotating the image based on the Exif flag. This work well if the images originally came from a camera with an orientation sensor. Depending on the source of the images, there may be no Exif flag present, or an incorrect one may be present because other software rotated the image but didn't set the Exif flag correctly, etc. Maik Thank you Maik for taking the time! (In reply to Maik Qualmann from comment #20) > Upload an image that you think isn't being processed correctly so I can test > it. I took some time to simplify a bit the images that I send you. Here’s the link: https://lufi.ethibox.fr/r/c1LYERg4bE#YkaHm0O9PHpL7gKG3zvzGK1lLi+OzRKPcPq4cGJQsis= What’s in there: 1) the original image from the scanner. I think the scanner already added rotation information in some form of post-processing, in any case it contains rotation information. This information is processed correctly by both digikam and MacOS, so the image appears correctly everywhere. 2) the same image after only using the rotate tool in BQM (not the auto-rotate AI, but the tool that rotates based on EXIF). This image appears incorrectly both in digikam and MacOS. 3) four images where I used the rotate tool (still the same, the one rotating based on EXIF) followed by the conversion tool (to HEIF/PNG). Once with the "lossy allowed" option activated, once without. The result is that all four files appear incorrectly in digikam. The HEIF appear correctly in MacOS, the PNG appear incorrectly in MacOS. I hope this allows you to reproduce what I see! I’ll also add an attachment to the conversation with the screenshot of how the images appear in my digikam. Have a great day / weekend! Created attachment 185641 [details]
Screenshot of how the files appear after the rotate based on EXIF tool in the BQM
Git commit abf2153a2e125e3e576b6c93e5bebf49aeb774a8 by Maik Qualmann. Committed on 10/10/2025 at 20:32. Pushed by mqualmann into branch 'master'. fix reset Exif orientation in the BQM M +10 -3 core/utilities/queuemanager/manager/actiontask.cpp https://invent.kde.org/graphics/digikam/-/commit/abf2153a2e125e3e576b6c93e5bebf49aeb774a8 Thanks for your descriptions and sample images, the problem is now solved. Maik (In reply to Maik Qualmann from comment #24) > Thanks for your descriptions and sample images, the problem is now solved. > > Maik Wonderful, thank you! |
Created attachment 185308 [details] HEIF-file rotated correctly in digikam, but appearing rotated 90 to the left in MacOS Preview and Photos SUMMARY Some PNGs I converted from tif and exported from digikam using the batch queue manager were rotated correctly in digikam, appeared correctly in MacOS preview, but were rotated badly in MacOS photos. I had to go back to digikam, and manually choose Auto Rotate/Flip Using Exif Information to make them appear correctly in both. Even with that, some PNGs appeared flipped when I sent them by email to people using Linux (I’m not sure which distribution, I think he’s on Kubuntu). Maybe that’s all normal, but since it’s the first time it’s happening to me, I thought I’d take the time to report here. With HEIF it’s worse, I never managed to find a solution. I’m not sure if it would be a second bug report, I didn’t want to produce too many in my first posting here. STEPS TO REPRODUCE 1. Batch rotate TIF files in batch queue manager. 2. Export to PNG or HEIF with batch queue manager. OBSERVED RESULT Photos appear rotated by 90 (or 180) degrees in some applications (MacOS photos or MacOS preview for instance), although they’re rotated correctly in digikam. EXPECTED RESULT All apps show the photo in the same way. I don’t need to use the function Auto Rotate/Flip Using Exif Information. The file appears the same on all systems. SOFTWARE/OS VERSIONS macOS: macOS Tahoe, Version 26.0 (also happened with 15.x) ADDITIONAL INFORMATION It’s my first bug report here, apologies if it’s not done correctly. It took me quite some time to find an image that I can share that has the problem. Its thumbnail is rotated incorrectly in MacOS Finder, MacOS preview shows it correctly, and MacOS Photos incorrectly. And digikam of course correctly. I have not applied the Auto Rotate/Flip Using Exif Information tool to this image on purpose. Unfortunately the picture is above the allowed size for attachments, and if I manipulate the file, the bug goes away. With heif, the issue is much easier to reproduce, so I’m attaching an heif. I’m happy to share the PNG file as well, but I’m not sure how (it’s about 8 MB).