Rendering vertical images

[kvalev]

I have a vertical image (EXIF Orientation Tag is set to 6, meaning 90°), which is being shown incorrectly in the cropper's image component.

Looking at the image transforms, the orientation itself is read correctly: imageTransforms: {flip: { horizontal: false, vertical: false }, rotate: 90}, but the image is shown horizontally. Looking into the cropper's img tag it seem that a rotate(90deg) transformation was applied to the element, which if removed shows the image in the correct orientation. I suspect that the browser already reads the EXIF data and correctly renders the image, so there is no need to apply those transformations manually. And indeed, if I set checkOrientation to false the image renders the correct way.

[Norserium]

@kvalev, could you provide more details? What's the used version? Could you upload (in an archive) the image? I have got the image samples with different EXIF tags and they are processed correctly as I see.

[kvalev]

I have uploaded the image here. The link expires tomorrow. As far as I can see, there is nothing special about the image, nor the way I use the cropper, but you never know. I use the latest version - 1.10.0 and have configured the cropper as follows:

<cropper
  class="cropper"
  :src="..."
  :stencil-props="{aspectRatio: 1}"
  :defaultSize="{width: 250, height: 250}"
  @change="onChange"
></cropper>

Adding :checkOrientation="false" ironically fixes the display issue. Let me know if you are able to reproduce it, I tried a bunch of different vertical images, from different cameras and all of them have the same problem. This is the image with the least personally identifiable information.

[Norserium]

@kvalev, it looks that it's okay (tested in the codesandbox):

How do you upload the image?

[kvalev]

@Norserium Thanks for taking your time! I dont upload the image, but instead load it directly from an url (something like :src="localhost:8080/images/..."), maybe this is the big difference? I wanted to reproduce it in the sandbox, but none of the public image hosting websites preserve the EXIF metadata.

[Norserium]

@kvalev, I thought so. It's the edge case.

When you upload file localy it can be either Data Url or Blob.

After that the cropper retrieves ArrayBuffer, extracts the image orientation from the corresponding bytes and then resets them to get rid of the difference in browsers that supports EXIF and the browsers that doesn't support one.

Finally, the cropper converts the ArrayBuffer to either Data Url or Blob depends on the format of originally loaded image. In your case the cropper doesn't know what's format to use to store the modified data, so it uses the original src.

From my side there are two solutions:

1. Disable the checking of the orientation for non-local images, because it's useless now.
2. Add the using of modified ArrayBuffer as a Blob if the non default orientation was detected.

From your side there are multiple solutions. The robust one is the clearing EXIF on your backend side, as the most CDNs do.

[Norserium]

I will give a try to the second solution. Blob has pretty good browsers support, good enough for our needs at least.

[kvalev]

@Norserium Thanks again for the support!

I thought this might browser related, but underestimated how many people use the image upload, instead of directly linking them (with preserved metadata). I will leave picking the best solution to you, but no need to hurry - it is not urgent, as I have found a solution for me. Given that I need it for a local application, and not some CDN-backed enterprise app, the overhead of stripping the metadata is way too big, so for now I will stick with ignoring the orientation in the cropper.

[Norserium]

@kvalev, try to update to 1.10.1.

[Norserium]

@kvalev, if it works well, I will transfer this changes to Vue 3 version of this library.

[kvalev]

@Norserium The fix worked, thanks for the quick action!

[Norserium]

@kvalev, it's nice to hear, I close the issue then. Thank you for your report!

[Norserium]

For Vue 3 users: this issue is fixed in 2.8.1.