When applying a transformation, Cloudinary automatically rotates images based on their EXIF information. Sometimes an image is manually rotated using software that doesn't delete the EXIF orientation information. When the image is uploaded with this manual rotation to Cloudinary, it may be rotated again because the EXIF information remains unchanged, which may result in an incorrectly oriented image.
A workaround for this issue is to add the a_ignore transformation which disregards the EXIF information. For example: http://res.cloudinary.com/demo/image/upload/a_ignore/sample.jpg
Comments
10 comments
Hi,
How can we add this parameter to the upload of image in a Ruby on Rails Application ?
Hi,
You can add the parameter angle with the value ignore. For example:
This needs to get answered, this should be opted in, and not a required transformation to ignore this data.
If we were to host these same images through ftp, this erroneous rotation would not be happening. I've only encountered this through uploading images to cloudinary.
Hi Jonathan,
Thanks for the feedback. We'll be sure to pass it along and if anything changed in the future we'll update here.
This is weird. While prepping a demo for Google Web Dev — I faced the same issue. It should be ignored by default. Let's make it happen.
Hi Ahmad,
Thanks for the feedback
In my opinion, it's not the correct course of action to ignore the EXIF rotation by default because our behavior will then differ from most image editors and from how web browsers currently handle the image when it's opened (though I realize most browsers have different behavior between opening an image directly and opening it in an <IMG> tag, with the former using the Orientation metadata and the latter not using it).
In particular, files from many mobile phone cameras are always stored in a particular (portrait or landscape) aspect ratio but use the Exif metadata to indicate which way the phone was being held and thus which way the file should be rendered, and these files would appear incorrect if the Exif metadata is not used.
Another option not already mentioned here, if you don't ever want the EXIF Orientation information to be used when we render the image is to use an Incoming Transformation as part of the upload process and include the a_0 transformation mentioned above.
Because performing any transformation strips the Exif metadata unless you use a flag to tell us to keep it, this will mean the file is stored without using the Orientation info from the metadata, and additionally, we'll strip the metadata so other viewers or operations won't rotate or flip it either.
Regards,
Stephen
Howdy, Stephen!
Thanks for explaining all that but at the end of the day I feel like that if we are asking users to use an extra property (just because they have to) makes for a bad User Experience.
Take a look at the images I am dealing with there. The images are part of the Google's Web.dev Image Compression/Optimization Codelabs — very much relevant to Cloudinary.
The main article → https://web.dev/use-imagemin-to-compress-images/
And at the bottom there are three codelabs e.g. https://web.dev/codelab-imagemin-webpack/
As you can see all these codelabs use the same images. So, I used those images to make a Cloudinary codelab here → https://cloudinary-url-api.glitch.me/index.html
Without using Cloudinary → https://cloudinary-url-api.glitch.me/index.html
With Cloudinary `q_auto,f_auto` → https://cloudinary-url-api.glitch.me/optimized.html
As you can see Cloudinary is rotating the images there. In a codelab where I am supposed to share why Cloudinary is super easy to use with `q_auto,f_auto` — I'm stuck with these rotations and are now thinking about why I need to add `a_0` and explain that to the user since it's unnecessary in all other cases of optimizations?
Thoughts?
Thanks for the extra information - I think this is actually a good example of why I was saying that ignoring the file's metadata may not be the correct action either.
If you look at https://cloudinary-url-api.glitch.me/index.html and look at the last image, flower6.jpg, it's in landscape format when shown in your image tag on the page, but if you open that image in a new tab, it's shown rotated 90 degrees counter-clockwise. That's also the case if you open it in Preview.app on OS X and most other image viewers. The reason opening it in a new tab shows it 'sideways' is that the file's metadata indicates that it should be rotated that way. I've attached a screenshot showing the details:
Similarly, when we open the file and start to apply the requested transformations, we apply the same Orientation unless asked not to with the a_0 flag.
In this exact case, it makes sense to ignore it but in others that might be the wrong action, so overall, I think it's better that behavior is configurable depending on your images and your requirements for them. In most cases, the files you're working with won't have this metadata, but it may be important if it's present.
I use Cloudinary for my blog site (built with node js). My problem is that when I upload an image from an iPhone, it rotates 90 degrees. I have already tried
angle: "ignore"but this does not seem to work. Am I using the wrong cloudinary parameters? (also it does not work when I include a_ignore in the url)Here is the upload code:
let result = await cloudinary.uploader.upload(req.file.path, {resource_type: type, angle:"ignore"});Hi Fabian,
Can I ask you to please open a support request and let us know the URL of the image after it was uploaded and to please also attach the original file so we can check the Orientation metadata from that file?
Thanks,
Stephen
Please sign in to leave a comment.