Remove TurboJPEG from Cantaloupe (disabling as processor is not enough?) to allow PDF Y coordinate level tiling

[DiegoPino]

See cantaloupe-project/cantaloupe#482

For some reason (explained there) when turbojpeg is around PDF tiling on Y coordinate is dead. Unmaintained lately, was fixed in 5.02, broke again in 5.04, and of course broken on our 6.x. I will try to fix our Fork's and might also introduce the PDF rendering flag we discussed a few months ago to make rendering more memory efficient

[DiegoPino]

See cantaloupe-project/cantaloupe#482 (comment)

I will fork and point our docker to a new branch instead

[patdunlavey]

@DiegoPino fyi, we found that switching to the 6.0.0-noturbojpeg-multiarch container image fixed our grayscale jp2 problem! I did test the 6.0.1-multiarch image, and it does not fix it.

We're going to test that noturbojpeg image on a staging site for a while to see if we find any problems.

[DiegoPino]

@patdunlavey thanks. So turbojpeg is to blame? It is deeply built into Cantaloupe so other than removing it from the build (and disabling it from the output) there is nothing I can do. Did you test https://hub.docker.com/layers/esmero/cantaloupe-s3/6.0.1-multiarch/images/sha256-a0b56db3d40dd7818e5c2fd3e62668af8ef5e045c45f23fe0e5bfb45ad60d0e4?context=explore with JPEG processing being Java2D?

[patdunlavey]

I did not try that. I will give that a test!

[patdunlavey]

Thanks for pointing out what I should have noticed would be an obvious change needed in cantaloupe.properties when libjpeg-turbo is removed. But in further testing, what I didn't expect, is that having processor.ManualSelectionStrategy.jpg = TurboJpegProcessor, when using the 6.0.0-noturbojpeg-multiarch image, seems to work just fine!
Perhaps cantaloupe's TurboJpegProcessor fails back to use Java2D automatically if TurboJpeg is not found?

Update: I'm sorry that I did not answer your question about testing with 6.0.1-multiarch.

I tested esmero/cantaloupe-s3/6.0.1-multiarch, with and without the jpg processing being Java2D. For jpg files it makes no difference - they succeed. For jp2 files, it also makes no difference - they fail.

[patdunlavey]

I should clarify/emphasize that the jp2 files that fail are grayscale. It seems that color jp2s work fine with libjpeg-turbo installed.

[DiegoPino]

@patdunlavey yes Derek explained your issue with B&W JP2s on slack. Only real way of getting TurboJPEG out of the way is removing the library as I did in https://hub.docker.com/layers/esmero/cantaloupe-s3/6.0.0-noturbojpeg-multiarch/images/sha256-6ab80b37755c4cdb97b093fe5283aaa47c73aa19e8421235ac841ff3c3f7bf67?context=explore

Probably the issue is on the writer (which as you detected will not be used if the library is not present)...

https://github.com/cantaloupe-project/cantaloupe/blob/21057cf72071840e2a984450bf8845c6e6490ec9/src/main/java/edu/illinois/library/cantaloupe/processor/codec/jpeg/TurboJPEGImageWriter.java#L18

but also there is this very old ISSUE open which matches the issue you are seeing with greyscale...
cantaloupe-project/cantaloupe#190

There is a pull that addressed one of the problems but not the actual intermediate BMP issue with low bit colors. You all sure Kakadu did not work for this?

[DiegoPino]

Wonder also if you have write permissions to the temporary file system...
See this:

https://github.com/cantaloupe-project/cantaloupe/blob/21057cf72071840e2a984450bf8845c6e6490ec9/src/main/java/edu/illinois/library/cantaloupe/processor/OpenJpegProcessor.java#L395-L405