Scaled YCbCr JPEGs showing incorrect 'pink' colours

[tyrex1975]

Hi,

Have read some of the YCbCr pink-background issues with interest and have come across a strange situation regarding different browser types. Sorry to bring this up again 😥

I have an app which takes photos uploaded by a user, resizes them (using Blueimp's load-image library) and sends them in Base64 format to our server. Our server then decodes the package and attempts to thumbnail the resulting image using a straightforward Java InputStream, BufferedImage and Graphics2d.DrawImage() process. We have TwelveMonkeys running on all servers, nothing unusual.

We've seen the pink-background issues in the past and successive versions of TwelveMonkeys has always fixed the issue. However today we have noticed these types of images again and noticed that they occurred when uploaded from a Firefox browser, but not when the same images were uploaded in Chrome.

Despite the two browsers using an identical source image, the resulting files received have very different file sizes. I gather from this, therefore, that the browser APIs being used by load-image are causing a subtly different image to be created which is perhaps confusing TwelveMonkeys? I've attached both images below - reading the Firefox version will cause the incorrect colours to be shown.

DSC07053 (Firefox)

DSC07053 (Chrome)

TwelveMonkeys library: 3.8.0
Java runtime version: 8.0.5.40 - pwa6480sr5fp40-20190807_01(SR5 FP40)
JVM version: JRE 1.8.0 Windows 8 amd64-64-Bit 20190802_424001 (JIT enabled, AOT enabled) OpenJ9 - 106f6ce OMR - fe07f6f IBM - af2a365

Thank you!

[haraldk]

I'm afraid I'm not able to reproduce the incorrect "pink" tint with any of your images. Both images are visually identical, and looks just the same here, using TM 3.8.1 (don't think there's important changes for JPEG since 3.8.0) and Oracle JRE 1.8.0.

Both contain an APP2/"MPF" segment, making these potential "Multi-Picture Format" files, but there seems to be only a single image in each file. The big difference I see is that the Chrome version contains an ICC profile and uses chroma subsampling, while the FireFox one does not (would be interesting to see the original file, and try to understand why the browsers think it's a good idea to change the data). These properties make the decoding follow two different code paths, the Chrome versions color conversion is handled by our plugin, while the FireFox version is completely delegated to the platform JPEG plugin. I only have Oracle/OpenJDK builds available, so I think perhaps the problem is related to different JREs.

I assume you have good reasons for using IBM OpenJ9, but are you able to test using an Oracle build? If you like to look further into this, help is greatly appreciated, as I don't have the resources to test and develop for all the various JREs out there.

A potential fix I see, is to create a system property switch, to force the "good" code path being executed always (at the cost of performance in some cases). It would also be nice to have a complete implementation of JPEG decoding in Java, to avoid differences like this. But that's a much bigger task.

[tyrex1975]

Thank you Harald, that's very helpful.

We use IBM OpenJ9 because our web servers are HCL Domino, so using other builds is likely not possible, but I'll check.

Interestingly, our use of TwelveMonkeys was due to these pink issues occurring in the first place, so your idea that the Firefox is essentially bypassing it could very well be the issue.

If it helps, here's the original image:
DSC07053

I'll spend some time researching OpenJ9 to see if any switches are available.

Thank you again.

[haraldk]

If you are able to test the lastes SNAPSHOT release, I've added an experimental system property switch:

-Dcom.twelvemonkeys.imageio.plugins.jpeg.raster=force

This forces the code to do a full raster conversion (ie. the "good" code path), even if it would normally read using the delegate.

Please report back your findings. 😀

[tyrex1975]

Wow, thank you. I'd love to test this.

I'm not the most proficient Github user and have simply been using the downloadable JARs so far, so I don't currently have the ability to compile the source, but I have read the build instructions in your README and see the tools I need (Git, Maven and a suitable JDK by the looks of things).

I'll dedicate some time to this over the next few days and get it built, installed on our servers, tested and report back.

Thank you again!

[haraldk]

There should also be prebuilt SNAPSHOTs available now, so you don’t need to build yourself. Then again, hacking the code is fun. 😀

[tyrex1975]

I pulled the following files from SNAPSHOT and configured my server. Are these the best ones to use?

common-image-3.9.0-20220112.185641-6.jar
common-io-3.9.0-20220112.185641-6.jar
common-lang-3.9.0-20220112.185641-6.jar
imageio-core-3.9.0-20220112.185641-6.jar
imageio-jpeg-3.9.0-20220112.185641-6.jar
imageio-metadata-3.9.0-20220112.185641-6.jar
imageio-tiff-3.9.0-20220112.185641-6.jar

Unfortunately the images are still coming through pink.

It is possible my server is not recognising the configuration option as I have to use a fairly obscure Domino feature to pass the -Dcom.twelvemonkeys.imageio.plugins.jpeg.raster=force parameter, is there any way to tell whether it is being observed?

[haraldk]

Dependencies looks good!

It's possible to enable some debug information (printed to console), it's enabled by a system property... Not sure if that works if you can't specify system properties easily. Anyway, here it is:

-Dcom.twelvemonkeys.imageio.plugins.jpeg.debug=true

You should see either

Reading using delegate

or

Reading using raster and extra conversion
ICC color profile: ...

Setting the -Dcom.twelvemonkeys.imageio.plugins.jpeg.raster=force should force only the "raster and extra conversion" variant, where the color space conversions are done in Java by our code.

[haraldk]

This is now part of the 3.8.2 release.

Closing the issue for now, but feel free to reopen or suggest further enhancements for the plugin to properly work with other JVMs.