Mostly jp2 images are not opening it is working in cantaloupe.Attaching error screenshot

[ranjeetsinghthirdrock]

[ranjeetsinghthirdrock]

Image url=https://uat-iiif.newmanstudies.org/iiif/2/TRT%2F01_Franciscan_Christocentrism_page-0003.jp2/full/full/0/default.jpg

[mbklein]

@orangewolf Is this something you've seen before?

[guillenjs]

I was wondering if this was resolved. I ran into the same problem when using jp2 images.

[mbklein]

@ranjeetsinghthirdrock @guillenjs Do you have any jp2 source images you can share with me so that I can try to reproduce and fix this issue? You can either attach them here or email them to [my github username] at gmail.

[mbklein]

@ranjeetsinghthirdrock After some debugging with a sample file provided by @guillenjs, I have narrowed the issue down to the JP2 loader in the underlying libvips image processing library. I have submitted a bug report in hopes of getting things working. If either of you would be willing to let me attach any of the files that are giving you trouble to that issue (or even attach them yourselves in comments), it would go a long way to helping resolve the issue.

[ranjeetsinghthirdrock]

@mbklein here is another sample image that is not opening
https://4slvho3i5lch7kp6zdultsdumq0ihqta.lambda-url.us-east-1.on.aws/iiif/2/TRT%2F01_A8.jp2/full/100,/0/default.jpg

[mbklein]

@ranjeetsinghthirdrock Would it be possible to share the source JP2 file for that image? Either by zipping/attaching it here, or by emailing it to mbklein at gmail?

[mbklein]

@ranjeetsinghthirdrock @guillenjs The underlying issue is with the OpenJPEG library that provides JPEG 2000 support. It looks like there's going to be a libvips release with a workaround – not an ideal one, as it depends on loading the entire frame instead of just the tiles required to complete the request, but I've tested it on my development server and the lag isn't terrible. But it's the best option available until the upstream issue is addressed.

I've also reached out to the team at Kakadu to ask how their licensing might work given the way our distribution works. It would require downstream users (i.e., you) to obtain a valid license for the Kakadu libraries, but if you've had this working in Cantaloupe, it's possible you've already been using the KakaduNativeProcessor with a license? (If you've been using the Cantaloupe OpenJpegProcessor, you may not even notice the performance hit from the libvips workaround mentioned above.)

[guillenjs]

@mbklein Thank you for all the work on this front! Is there a projected date when this update may be released so we can start testing on our end?

[mbklein]

I'm currently testing with the libvips branch with the fix in it. Once it's stable, the maintainer will have to approve, merge, and release it, and then I can build and push a Lambda layer with support for it. I hope it'll be soon – closer to "a couple weeks" than "a few weeks."

[mbklein]

I'm afraid I didn't quite understand the libvips release schedule, so it might be six months or so before the fix is in a release. That said, there's nothing stopping me from building a lambda layer with the pre-release workaround in it, so I'll let you know when it's available.

[mbklein]

@ranjeetsinghthirdrock @guillenjs I've just released serverless-iiif v5.1.1 with support for the sharp/libvips/openjpeg workaround for this issue. It uses as-yet unreleased code from libvips and a forked version of sharp that enables the workaround code. I'll update to the released versions as the code make it into upstream releases.

If you have a chance, could you install or upgrade to that version and see if it fixes the problems you're having?