Spike: can Cantaloupe support JP2 streams?

[tomcrane]

At the moment, Cantaloupe's performance is poor with OpenJPEG or Grok processors because it needs to copy files before accessing streams. This also means it can't make byte-range requests to S3 with those processors.

It does work fine with Kakadu though - so can we make it work the same way for OpenJPEG and Grok and therefore support byte-range S3 requests without Kakadu?

Spike to investigate.

[garyttierney]

I've created a branch here that uses the JNR wrapper by Johannes Baiter: https://github.com/dbmdz/imageio-jnr.

Some initial comments/thoughts:

• Grok has diverged too far from OpenJpeg to use this same wrapper for both decoders. We'd need to maintain 2 slightly different wrappers.
• Streaming works end-to-end with JP2s now, in addition, the full color bitmap copy is avoided -- reducing disk thrashing and memory usage when dealing with images that have components smaller than RGBA32.
• There is a work in progress to move all current Cantaloupe Processors into the ImageIO codec system. I've done this for imageio-openjpeg but there's likely a larger piece of work to get everything lined up as expected by the maintainer.
  • Related to above, metadata now comes from the ImageIO plugin instead of the reader itself. This could regress or expose new properties to the API, needs testing.

Observations:

• Micro-benchmarks are noticeably faster when processing a JP2 stream
• Byte range requests are never cached, even when desirable

[garyttierney]

• Avoid communicating with S3 unless necessary cantaloupe-project/cantaloupe#616
• Use ImageIO based OpenJPEG codec for JP2s cantaloupe-project/cantaloupe#617