Image::convertToBufferedImage is indeterministic

[kahlep]

This behavior seems to result from ImageIO internals and can be reproduced with images where only specific readers (from those that claim to be able to read the source) work as expected, e.g. on JPEG compressed images with "tif" filename extensions. See eu.transkribus.interfaces.types.ImageTest::testFromUrlToBufferedImage

Findings so far:

• ImageIO registers Reader/Writer plugins internally in a HashMap and the order of the entry set may thus change over time
• ImageIO::read iterates readers, takes the first one that returns true when calling ImageReaderSpi::.canDecodeInput and if the actual read operation fails throws an IIOException
• IIORegistry::register returns false if a reader of the given type is already registered, according to its JavaDoc. BUT: acutally it deregisters the old instance and puts the new instance into the map, altering the order of the entry set. Subsequent registering of the same plugin will therefore change the behavior of ImageIO::read for certain images.

Steps taken so far:

• Image type does not contain a static block registering Readers and Writers anymore. This was needed by web applications in Tomcat so far but is solved with a context listener that registers plugins on the classpath automatically.
• ImageUtils has an alternative implementation of ImageIO::read that tries other candidate-readers first if one reader fails.

[kahlep]

Alternate implementation of ImageIO::read may fail on images where orginal impl works. The same scheme could be applied and tested when creating the ImageInputStream object. Also seems to depend on the Version of JRE version used. Sometimes reading jpg images with Jdk1.8.0_102 works, in other cases only with Jdk1.8.0_121 (confirmed for BenthamClean set).
Next try could use original implementation and alternative only if null is returned from first try.

[kahlep]

Issue is probably related to incompatibilities between JAI and the twelvemonkeys ImageIO plugins. See haraldk/TwelveMonkeys#433
In ImageUtils this might happen when the JAI plugin is picked for reading the TIFF, but the twelvemonkeys plugin is picked for reading the contained JPEG (mind the order of registered ImageReaders):

Testing readers for format: JPEG
ImageReader: com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader@5ccd43c2 in sun.misc.Launcher$AppClassLoader@2a139a55
ImageReader: com.sun.imageio.plugins.jpeg.JPEGImageReader@7960847b in System ClassLoader
Testing readers for format: TIFF
ImageReader: com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader@5a61f5df in sun.misc.Launcher$AppClassLoader@2a139a55
ImageReader: com.twelvemonkeys.imageio.plugins.tiff.TIFFImageReader@59e84876 in sun.misc.Launcher$AppClassLoader@2a139a55
Testing readers for format: TIF
ImageReader: com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader@61a485d2 in sun.misc.Launcher$AppClassLoader@2a139a55
ImageReader: com.twelvemonkeys.imageio.plugins.tiff.TIFFImageReader@39fb3ab6 in sun.misc.Launcher$AppClassLoader@2a139a55
Testing readers for format: PNG
ImageReader: com.sun.imageio.plugins.png.PNGImageReader@6276ae34 in System ClassLoader
Exception in thread "main" javax.imageio.IIOException: No SOF segment in stream
	at com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader.getSOF(JPEGImageReader.java:762)
	at com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:334)
	at com.sun.media.imageioimpl.plugins.tiff.TIFFJPEGDecompressor.decodeRaw(TIFFJPEGDecompressor.java:224)
	at com.sun.media.imageio.plugins.tiff.TIFFDecompressor.decode(TIFFDecompressor.java:2527)
	at com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader.decodeTile(TIFFImageReader.java:1137)
	at com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader.read(TIFFImageReader.java:1417)
	at javax.imageio.ImageIO.read(ImageIO.java:1448)

[kahlep]

Relying only on the twelvemonkeys ImageIO impl for now. Interoperability with the default ImageIO implementation seems to be fixed in version 3.4 of the lib though.