Prevent images from being rotated if the original contains EXIF orientation metadata

[alanpreed]

Fixes: #49

Adds a rotation operation using sharp immediately prior to resizing, as suggested in Stack Overflow post here.

[jacob]

This looks good based on the Stack Overflow post you mention. One thing that would make this PR stronger is if we add an image to the test directory that exhibits the issue and is not square. Then a similar test to https://github.com/11ty/eleventy-img/blob/master/test/test.js#L233 -- "Try to use a width larger than original (statsSync)" could demonstrate whether the bug is fixed by checking that the width is longer than the length (or vice versa depending on the test image).

The only difficulty is that a test image should be small, an original file from an iPhone would be too large to be good for testing. Perhaps the person who reported issue #49 could help in generating a small image file which has EXIF data that exhibits the bug.

[alanpreed]

Below are a couple of images that I have created for testing. The first has no EXIF header, and the second has the following minimal EXIF data that should set the orientation to be upside down:

$ exiv2 -pt orientation_image.jpg 
Exif.Image.Orientation                       Short       1  bottom, right
Exif.Image.DateTime                          Ascii      20  2021:05:10 20:51:53
Exif.Image.ExifTag                           Long        1  70
Exif.Photo.DateTimeOriginal                  Ascii      20  2021:05:10 20:51:53
Exif.Thumbnail.JPEGInterchangeFormat         Long        1  138
Exif.Thumbnail.JPEGInterchangeFormatLength   Long        1  0

Although the images display with their correct orientation here, in my file browser, and when opened in Firefox, unfortunately it appears that sharp ignores their metadata completely.

This issue is not limited to using the rotate function either. I tried adding sharpInstance.withMetadata(); prior to sharpInstance.resize(resizeOptions);, and found that sharp will not copy over the metadata from these images . The camera image that I originally encountered the rotation issue with does have its metadata transferred correctly when this line is added.

Presumably something is missing from my metadata, although I did try copying all fields over from the camera image and it was still ignored. I can't see anything obvious within sharp's documentation or sourcecode to point me to what might be missing, nor can I see a way to produce verbose output from sharp to work out where things are going wrong internally, so I'm not sure what to try at this point I'm afraid,

[hnrklssn]

This doesn't seem to work when keeping the original resolution: if I pass widths: [600, null] the resized version of my image is rotated correctly, while the original resolution output is unrotated but without the EXIF data to indicate orientation.

[hnrklssn]

This is never reached if stat.width < metadata.width || (options.svgAllowUpscale && metadata.format === "svg" is false.

[jdvivar]

I think that's OK. The issue is caused when resizing only, so the code is reached for the same cases when the bug is happening.

[hnrklssn]

If the image is rotated 90 or 270 degrees getValidWidths will return what will be the height as the "width" for falsy values in the widths array, since that is the width of the input image.

[zachleat]

This seems okay to me but needs another stat.width === metadata.width && metadata.format !== "svg" branch in there I think—to handle the original image width too.

[jdvivar]

LGTM

[zachleat]

Closing for #132