Apparently the issue with my example (PARROTS.JPG) is that the file simply contains no EXIF data. It seems like a tool like jpegexiforient should emit some sort of message in this case, ideally output to stderr and return a non-zero exit code, since the whole point of jpegexiforient is to get or set the Orientation tag value and it's apparently unwilling to add EXIF data if it's missing.
While looking into this bug some more I noticed that this package (libjpeg9) does not have an Ubuntu maintainer, only an upstream maintainer. So I looked around in Debian's bug reports and found this, which may be related: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=947182 If the EXIF data doesn't appear in the spot that's ostensibly required by the standard, jpegexiforient throws up its hands and gives up. The Debian maintainer refuses to apply the patch that someone submitted which would give the tool the ability to look for the EXIF data elsewhere in the file. Behold the power of open source! I suppose we're all free to build the tool ourselves with the patch applied but sadly that's a bit outside of my wheelhouse. It's also worth noting that jpegexiforient will ONLY operate on a file which not only has EXIF data, but has the Orientation tag set to some value. Sadly neither of these requirements are mentioned in the extremely short man page. In the case of a file which has no EXIF data, it can be added with the tool "exif": exif --output=parrots-1.jpg --create-exif --ifd=0 --tag=Orientation --set-value=1 PARROTS.JPG At this point I was able to use jpegexiforient to modify the orientation tag. However if the file already contains EXIF data but in a place that jpegexiforient is unhappy about, using exif to set the orientation works: # ifd 0 seems to be the main image exif --output=my_photo-3.jpg --ifd=0 --tag=Orientation --set-value=3 my_photo.jpg # ifd 1 seems to be the thumbnail exif --output=my_photo-3.jpg --ifd=1 --tag=Orientation --set-value=3 my_photo-3.jpg (Where my_photo.jpg is a photo I took with a Panasonic G7 and scaled down with GIMP.) I'm not sure about any solution to the use-case described in #5 , but my main interest was simply getting images to display correctly without any lossy re-encoding, and using "exif" seems to solve that problem for me. It sounds like exifautotran will continue to be broken until the maintainer for the libjpeg-turbo-progs package in Debian decides to stop cutting off their nose to spite their face and allows jpegexiforient to look for EXIF data in "non-standard" locations. (Which seems to be substantially more widespread than they think it is.) ** Bug watch added: Debian Bug tracker #947182 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947182 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842116 Title: jpegexiforient does not reliably detect EXIF orientation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libjpeg9/+bug/1842116/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
