Cannot extract EXIF Orientation tag on certain images #4073
Replies: 7 comments 2 replies
-
Hi @winterstefan, I enabled debugging for the libvips EXIF loader and for
So it looks like libexif is failing to parse anything useful from the 1035 bytes of EXIF in APP1. With
Which looks more reasonable. I'll see if I can get any more information from libexif about this read failure. |
Beta Was this translation helpful? Give feedback.
-
The provided
|
Beta Was this translation helpful? Give feedback.
-
Ah! Good sleuthing @lovell It sounds like there's not much libvips can do in this case. |
Beta Was this translation helpful? Give feedback.
-
Oh, that indeed sounds reasonable! Thank you so much forgiving me a hint on this! Then, your last comment @lovell at lovell/sharp#3947 is a great summary: For me as a consumer, it would be cool having libexif being able to also parse out-of-order tags (since I have a couple of customer images to process that seem to have this problem). But that explains why trying another golang package failed as well and thus is not a matter for libvips. Thanks for checking that! |
Beta Was this translation helpful? Give feedback.
-
I'll move this to the discussions section should anyone fancy looking at the upstream libexif to see what might be possible. An alternative solution might be to tell all your friends to stop buying Samsung devices ;) |
Beta Was this translation helpful? Give feedback.
-
I was wrong about this relating to tag-ordering, but it is still ultimately a dodgy Samsung software problem. It looks like some Samsung devices generate EXIF metadata with invalid thumbnail offsets and/or lengths. libexif added protection against this when recursively handling EXIF directories via commit libexif/libexif@cdf1e32 but this resulted in tag parsing aborting early, hence everything after the I've proposed that libexif relaxes this logic slightly via libexif/libexif#183 |
Beta Was this translation helpful? Give feedback.
-
@lovell We're seeing this issue with photos uploaded by some of our Samsung users. Photos are oriented correctly in their photo libraries before uploading, so this is difficult to prevent. I can't think of another way around it other than adding an in-app tool to rotate photos after uploading (not something I can take on right now). If that proposal doesn't get merged, do you foresee a way around for Sharp users this without modifying libexif? Validation with ExifTool:
Result after Sharp: https://www.patinaproject.com/photos/nicks-ranger-seidel-1964-ash-gray/LmQKV1q |
Beta Was this translation helpful? Give feedback.
-
Bug report
Having two different
jpg
images with an EXIFOrientation
tag present, for imagea.jpg
I can extract this tag where for imageb.jpg
vips doesn't return the orientation information. For these images, it's 100% reproducible. Other exif tools (e.g.exiftool
or the Mac preview can extract the orientation for both images.Unfortunately I cannot spot any technical differences between these two images, that my result in this behavior. Could you please take a look verifying the issue? Do you have any idea / hint? :-)
To Reproduce
Steps to reproduce the behavior:
vipsheader -a
for both imagesOrientation
tagExpected behavior
Both commands display the exif orientation info
Actual behavior
For
a.jpg
I see an orientation, forb.jpg
I don't.Using e.g.
exiftool
, I see the following (also, when opening in Mac preview)In addition, here's the output of using
autorot
directly:Environment
vips-8.15.0
Additional context
In general, I have a golang script using govips. At one location I use
vipsheader -a
as binary to get all headers for anio.Reader
. At another location I tried usingim.GetExif()
on avips.ImageRef
. Both failed providing the orientation fora.jpg
(I also have a couple other images likea.jpg
that doesn't work).Being able to get the orientation tag is key for in order to rotate the image accordingly. At best, I'd use
im.Autorotate()
, but without it being able to extract the tag correctly it fails.Important I also need to find a solution that works with streaming the image (because of large images being handled)
Thank you very much in advance; best regards
Beta Was this translation helpful? Give feedback.
All reactions