Why does Cloudinary Incorrectly rotate my image?

Follow

Comments

8 comments

  • Avatar
    Gregdebrick

    Hi, 

     

    How can we add this parameter to the upload of image in a Ruby on Rails Application ?  

    0
    Comment actions Permalink
  • Avatar
    Aditi Madan

    Hi,

    You can add the parameter angle with the value ignore. For example:

    cl_image_tag("sample.jpg", :angle=>"ignore")
     
    1
    Comment actions Permalink
  • Avatar
    Jonathan

    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.

    1
    Comment actions Permalink
  • Avatar
    Raya Straus

    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. 

    0
    Comment actions Permalink
  • Avatar
    Ahmad Awais

    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.

    0
    Comment actions Permalink
  • Avatar
    Stephen Doyle

    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

    1
    Comment actions Permalink
  • Avatar
    Ahmad Awais

    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?

     

    0
    Comment actions Permalink
  • Avatar
    Stephen Doyle

    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.

     

    1
    Comment actions Permalink

Please sign in to leave a comment.