jrdh
commented
2 months ago That test image I used above has the EXIF orientation value of ExiValue:35=Rotate 90 CW in an EMu export I found it in (emultimedia.export.20220728.gz). So at least for this one, we could read that and rotate. Why it has the non-standard value "Rotate 90 CW" is anyone's guess.
In #51 we started rotating images. Turns out in some (maybe all?) cases this breaks our image processing pipeline because the post-rotation image now has different width and height attributes compared to the data stored in the MSS index. This causes a problem because when we produce an images
info.jsonfile we use the width/height data from the MSS index if it exists to avoid having to load the original just to find out the size of it.An example, https://data.nhm.ac.uk/media/0268bf86-0aca-4d10-af64-07887f4dc6ef produces an internal server error like this:
The original image (and all derivatives) have an EXIF orientation tag value of RightTop (which incidentally is wrong, the images actually don't need an EXIF orientation value, they're already the right way round, but that is a different problem...) and so after acquiring the source image and performing the rotation we end up with a portrait image, for example the source thumbnail file is 60x90. However, if we look at the MSS entry for this file, we find that EMu tells us it is 90x60. This results in the upscaling problem because when a user requests the a thumnail, for example, we use these MSS value to tell us the image size.
We can't completely switch to just using the actual source image size because users can also request different sizes etc using IIIF, so we need to either stop using the MSS values completely and always fetch the source image to get its real size (slow!) or we need to find a way to make the values in the MSS index match the reality. This may be possible because we do get EXIF information in EMu exports, so we might be able to just perform the rotation on index. This needs to be investigated further though to make sure it works as expected.