Incorrect image returned after adding dimension metadata

[cweinard]

Hello, The IIIF service was working as expected with jpgs that had no user-defined metadata. We replaced the images with jpgs containing user-defined metadata (including height and width), the IIIF service now returns image regions instead of resizing the image.

This returns a region (it should resize):

https://wta2nm4c3qiy3ubm7g24zwkrre0olysv.lambda-url.us-west-2.on.aws/iiif/3/tms-media/1963_09_v01_M.jpg/full/200,/0/default.jpg

I uploaded a new image to the bucket without user-defined metadata (height and width), and it works as expected.

Any suggestions appreciated! Thanks.

[mbklein]

Would you be able to share the pyramidal TIFF file with me? If you don't want to attach it here, feel free to email to mbklein at gmail dot com. I assume the S3 width/height metadata is 1024x700?

[cweinard]

Thanks so much for your help. Source is a jpg. S3 user-defined metadata shows 1024x700.

[mbklein]

I was just coming back to comment with the realization that you said your source was a JPEG, not a TIFF. I'll see what I can do.

[mbklein]

I've identified the source of the issue and should have a fix within a few days.

[cweinard]

Thank you!

[mbklein]

This fix is going to introduce a breaking change to how serverless-iiif handles dimension calculations, which is going to require a major version update, so it's going to take a little longer. In the meantime, try one of the following and see if it fixes the problem:

• Redeploy with the PyramidLimit parameter set to 0
• Remove the pyramidLimit environment variable from the deployed lambda
• Update the S3 Metadata for your .jpg to include x-amz-meta-pages with a value of 1

Note: The first two options will remove the server's ability to auto-calculate pyramid levels for source files that do have them. In those cases, you'd need to add the correct number of levels to each image's x-amz-meta-pages metadata. How you find the correct value for each image depends on which image processing utilities you have on hand.

For ImageMagick: identify file.tif | wc -l For vips: vipsheader -f n-pages file.tif For tiffinfo: tiffinfo file.tif | grep "TIFF Directory" | wc -l

This does unfortunately depend on having the files on a local volume – none of the above utilities can read (efficiently) directly from S3. It wouldn't be hard to use sharp to write a lambda that would inspect all of your images in S3 and write the appropriate metadata, which I might include in a future release.

[cweinard]

Thank you! Very much appreciate your help.