https://bugs.kde.org/show_bug.cgi?id=415460
--- Comment #9 from Anselm Lingnau <anselm+...@anselms.net> --- I've looked into this some more and it seems to get even worse. When I import a portrait-orientation image into Digikam from my digital camera, Digikam turns it upright for display according to the Exif orientation flag, but the actual file is unchanged (as can be seen when opening such a file in The GIMP, which offers to turn it according to its Exif orientation). This is fine. If I export the same image as an e-mail attachment using the Digikam e-mail plugin, it is actually physically turned upright (i.e., if you inspect the temporary image file with “file” it says it is, e.g., “768x1024”, but according to “exiv2” it keeps its original Exif orientation flag. This means that programs like “jpegexiforient”, which insist that the Exif data must come immediately after the SOI and disregard it if it occurs elsewhere in the file, do nothing, which is appropriate as the image has already been rotated by Digikam. OTOH, programs like Gwenview or The GIMP, which are apparently more tolerant (i.e., non-compliant with the Exif standard) when it comes to finding Exif tags in an image file, will turn the image *again* because they react to the erroneous Exif orientation flag written by Digikam. This is clearly wrong. (As a funny side observation, if you use Gwenview to turn the file upright again, save it, and re-open it in Gwenview you will find that it is now actually turned too far, because Gwenview will alter both the image data and the Exif orientation flag. In The GIMP this is less of an issue as the program will prompt you to approve or deny the Exif-based rotation when it opens the file.) All of this suggests to me that you should either make sure that the Exif info ends up where it belongs according to the Exif standard (so programs like “jpegexiforient” and “Gwenview” will behave the same) or else omit the Exif info from the exported attachments altogether so programs like “Gwenview” and The GIMP, which implement the Exif standard incorrectly, don't get confused. In any case Digikam should stop writing files that conform neither to the JFIF standard (because they include erroneous Exif data not specified by the JFIF standard) nor the Exif standard (because the Exif data is in the wrong place according to the Exif standard). At the very least you should ensure that the Exif orientation flag that is erroneously included in the wrong place in the attachment file so only non-compliant software will find it to begin with, agrees with the actual orientation of the data in the file, so the non-compliant software doesn't get confused by it. (For the record, I did all these experiments using the 6.4.0 appimage version of Digikam.) -- You are receiving this mail because: You are watching all bug changes.
