You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not strictly a bug, but I wanted to post some important pitfalls in regards to the checkOrientation option. I have worked with photo.gallery and files.gallery for 10+ years, and have lots of experience with the challenges of EXIF-oriented images in website photo galleries.
First of all, checkOrientation set to false does not seem to work. From my tests, it is ALWAYS rotates the image from EXIF value, even when set to false. I don't actually see how anyone would want to set it to false, but my tests show it always rotates according to EXIF. Could it be a browser thing? Because the image might get rotated from CSS image-orientationfrom-image as this is now default in most browsers. I am guessing the blob is already rotated.
Even if checkOrientation could be disabled, who would want that? If someone uploads an EXIF-oriented image and Compressor.js deletes the image's EXIF data, the image will become incorrectly rotated with no way to retrieve the true orientation of the image.
I'm not sure if this is worth of a bug, but the whole concept of checkOrientation in Compressor.js is a bug. When disabled (if it works), it will simply cause incorrectly rotated images as soon as Compressor.js removes the EXIF. I can't see any thinkable scenario where this would be useful.
This is also request to consider writing EXIF back into images after compression. EXIF is a crucial feature for photo gallery type websites, and users ultimately want compression/resize without sacrificing EXIF. I know that EXIF orientation and writing EXIF back into images are complicated matters, but I thought I'd post.
The text was updated successfully, but these errors were encountered:
The first version of Compressor.js was released on December 10, 2018. At that time, most browsers did not support the image-orientation CSS property, which meant that the checkOrientation option worked fine.
Understood. But then surely the option can be removed to avoid confusion? For 95% of browsers, it simply has no effect, which at best is confusing. Besides, even if it did work to set checkOrientation false, this will simply break images with EXIF rotation when EXIF is removed by compressorjs. Thanks
This is not strictly a bug, but I wanted to post some important pitfalls in regards to the
checkOrientation
option. I have worked with photo.gallery and files.gallery for 10+ years, and have lots of experience with the challenges of EXIF-oriented images in website photo galleries.checkOrientation
set tofalse
does not seem to work. From my tests, it is ALWAYS rotates the image from EXIF value, even when set to false. I don't actually see how anyone would want to set it tofalse
, but my tests show it always rotates according to EXIF. Could it be a browser thing? Because the image might get rotated from CSS image-orientationfrom-image
as this is now default in most browsers. I am guessing the blob is already rotated.checkOrientation
could be disabled, who would want that? If someone uploads an EXIF-oriented image and Compressor.js deletes the image's EXIF data, the image will become incorrectly rotated with no way to retrieve the true orientation of the image.I'm not sure if this is worth of a bug, but the whole concept of
checkOrientation
in Compressor.js is a bug. When disabled (if it works), it will simply cause incorrectly rotated images as soon as Compressor.js removes the EXIF. I can't see any thinkable scenario where this would be useful.This is also request to consider writing EXIF back into images after compression. EXIF is a crucial feature for photo gallery type websites, and users ultimately want compression/resize without sacrificing EXIF. I know that EXIF orientation and writing EXIF back into images are complicated matters, but I thought I'd post.
The text was updated successfully, but these errors were encountered: