-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rotation exif data lost after resize #63
Comments
As far as I know EXIF data should be preserved. I certainly don't do anything to actively strip it out. If you can come up with a reproducible case, that would certainly be helpful. I haven't observed anything like this myself. |
Interesting. So when you proxy it with no resizing, it is oriented properly: http://pulseconnection.com:8080//http://s3.amazonaws.com/co.ifwe.heartbeat.photos/bd6c353f-ce72-4bac-84b8-9ad32e54fc2a.jpg However, when I run it through my server it gets rotated, even with no resizing: https://willnorris.com/api/imageproxy/sYwItOwfiXif7JTX5qVF3j0YyoDMTblWn1h6O8M97YlA/https://s3.amazonaws.com/co.ifwe.heartbeat.photos/bd6c353f-ce72-4bac-84b8-9ad32e54fc2a.jpg Definitely something I'll need to dig into. |
I think you must be inadvertently stripping out the EXIF tags. Is there maybe an option to preserve them? I will experiment with node-exif to verify and post back. Otherwise I have to store the correct orientation before the photo is uploaded and apply the rotation programmatically--lame! :) |
So yeah, the image decoding and encoding process is definitely dropping EXIF tags. I confirmed this by parsing out the tags before and after transform, but this is also discussed at golang/go#4341 and golang/go#12202. Ideally, I'd want to completely preserve EXIF data through the transform, but that seems to be difficult since most libraries only support parsing the data, but not writing it back out (from what I can see). The best we can probably do is to just apply the appropriate transform ourselves to orient the image properly, similar to what camlistore does. Incidentally, this also revealed a separate bug (#64), so that's kinda nice. |
All of us resizing mobile phone uploads will be grateful for the orientation fix. If I weren't such a noob I'd gladly propose the fix myself. |
You can see this live with the test image noted in the comments above at https://willnorris.com/api/imageproxy/300x,sYwItOwfiXif7JTX5qVF3j0YyoDMTblWn1h6O8M97YlA/https://s3.amazonaws.com/co.ifwe.heartbeat.photos/bd6c353f-ce72-4bac-84b8-9ad32e54fc2a.jpg |
EXIF data is lost in the transform of any image that we proxy since writing it back out to the file is [non-trivial][1]. Therefore, when any transform is applied to an image the EXIF data is examined and rotations are applied so the resulting image is presented in its "preferred orientation". When requesting the big beautiful recipe page image, request an image that is 1% smaller to transform the image. This ensures EXIF data is applied and the resulting image will always be the correct orientation. Fix #258 [1]: willnorris/imageproxy#63 (comment)
EXIF data is lost in the transform of any image that we proxy since writing it back out to the file is [non-trivial][1]. Therefore, when any transform is applied to an image the EXIF data is examined and rotations are applied so the resulting image is presented in its "preferred orientation". When requesting the big beautiful recipe page image, request an image and rotate it 360 degrees to transform the image. This ensures EXIF data is applied and the resulting image will always be the correct orientation. Fix #258 [1]: willnorris/imageproxy#63 (comment)
Does imageproxy preserve EXIF data? When users upload portrait photos under some conditions that haven't been able to nail down, they are rotated incorrectly after imageproxy has processed them, even though they render correctly in the browser natively.
I seem to be having the same problem as described here: http://stackoverflow.com/questions/13971491/captured-photo-automatically-rotated-during-upload-in-ios-6-0-or-iphone
Any ideas how to solve? Thanks!
The text was updated successfully, but these errors were encountered: