samvera
Image is served flipped
Hello,
I came across an odd issue I can't seem to figure out. We have an image that is being served from the application flipped 180 degrees. When I open the source image on my computer it appears right side up so I'm figuring that the app is reading something in the image metadata that causing it to flip. The image was generated from a different scanner than we normally use so I image there might something going on there, but I'm wondering if you can take a look at the image and see what you think. I'll send the source image to your email.
source image:
Flipped from app:
Thanks,
Joe
Hi Joe,
Thanks for reporting this; I hadn't noticed it before.
The issue is that your source image actually is rotated 180º, but with an EXIF orientation value of 3 (BottomRight). Most image viewers rotate the image automatically based on the EXIF orientation, but serverless-iiif can't without jumping through a lot of hoops that would make it a lot less efficient. (In short, it would have to generate the response image, then read the EXIF metadata from the source and apply the orientation as a separate in-memory operation.)
Unfortunately, the only reliable way to fix it is to make sure your TIFFs are all in TopLeft orientation (EXIF orientation value 1). I'm trying to figure out how to get vips and ImageMagick and GraphicsMagick to take care of this, but it's proving to be less than straightforward.
Ok, that's very interesting. It must have something to do with this new scanner we were using, and to add more details, this was the only page out of the scans that we didn't then subsequently crop using Lightroom, so the subsequent pages were resaved and Lightroom added the correct EXIF orientation. Whereas this was a TIFF unaltered from the scanner.
I suppose if we do continue to use this scanner we'll just need to make sure everything that passes through it is saved in Lightroom.
Thanks for your help.
In the spirit of “serverless-iiif should be able to handle whatever source images you throw at it,” I'm going to continue to look into whether there's anything I can do about it server-side without too much of a performance hit.
~~After some experimentation, it looks like I might be able to add support for this in the future, but it involves some transformation math that is going to take some time. I'll keep it on the roadmap. In the meantime, I've updated the source image documentation with a cautionary note about EXIF Orientation and included auto-rectification options in the image conversion examples.~~
It seems sharp added support for automatic orientation in the latest release, so I should be able to support it in pretty short order. I'll keep this issue open until the fix is released.
This work has been held up by this issue, but once sharp v0.34.4 is released, I'll be able to add auto-orientation to serverless-iiif.
@fitnycdigitalinitiatives sharp v0.34.4 was released this morning, so I've gone ahead and pushed node-iiif v6.1.3 and serverless-iiif v6.0.0. This is a major upgrade in that it changes the build/package system to include all the supported formats (JPEG2000 input; GIF output) out of the box instead of relying on a hosted layer. So the SharpLayer option has gone away, but everything else should work as always. Please let me know if/when you've had a chance to check it out and we can close this issue.
I will look at it today. This actually came up again recently, and we realized it happened because, in this instance, someone digitized some material and then rotated it in Adobe Bridge, which only applies the rotation in EXIF rather than rotating the pixels: https://community.adobe.com/t5/bridge-discussions/rotate-image-in-bridge-what-is-expected-behavior-do-i-need-to-save-or-export-to-have-the-rotation/td-p/14256860
So, we're gonna change our workflow on that but also I'll check this out today.
Just tested out the new release and pushed it into production. Everything looks like it's working as intended, and does respect any rotation metadata.