Black rectangles for some JPG files

I have used JPG files as ImageMosaic for years without any problems. Recently, however, I received JPG files that, when uploaded to Geoserver as ImageMosaic, return black rectangles. After performing some diagnostics, it turned out that the metadata in the JPG file was to blame. The following entries appear in the Geoserver logs from GeoTools:

DEBUG [imagemosaic.catalog] - Skipping invalid granule
java.lang.IllegalArgumentException: javax.imageio.IIOException: JFIF APP0 must be first marker after SOI
DEBUG [gce.imagemosaic] - Creating constant image for area with no data

After regenerating the metadata itself (using exiftool) in the JPG file, the problem disappears. But … Assuming that for various reasons I do not want to modify the JPG file every time, is it possible for Geoserver to handle such files in its default configuration?
Mapserver handles them :slight_smile: As does switching to libJPEG-turbo and disabling the “Use JAI ImageRead” option for the layer. But it would be better if it wasn’t necessary :slight_smile:
Tested for the latest Geoserver 2.26.2, GeoTools: 32.2, JRE Eclipse Adoptium 17.0.14, as well as older ones:
Geoserver: 2.23.0, GeoTools: 29.0, Java: 11.0.21+9-post-Ubuntu-0ubuntu122.04
Geoserver: 2.19.0 GeoTools: 25.0 Java: Amazon.com Inc.: 1.8.0_412
JPG file will be attached if possible.

The JPEG reader comes from the Java runtime itself, GeoServer is just using it. So I guess you can try to upgrade to a newer version of Java, like Java 21, and see if it works there, or contribute a fix upstream in OpenJDK. Contributions there are not the easiest, but not impossible either.

Another potential avenue is to use a JDK that leverages JPEG turbo directly, like the Ubuntu own JDK (but you seem to already have one of those in your tests?)

Cheers
Andrea

Thanks Andrea.
This: https://bugs.openjdk.org/browse/JDK-6488904 probably means You are right it can be difficult.
Anyway I will try Java 21 and Ubuntu build-in JPEG-turbo (I have to add plugin to Geoserver) ways.
Another possible suggestion: could it be considered to allow Geoserver to ignore this particular error detected by Java in future Geoserver versions?
Best,
Grzegorz

I haven’t see it in action so I might be wrong, but image decoding errors are hardly ignorable, once the exception is thrown the JPEG decoding stops and no image is returned.
So that granule of the mosaic (that image) is simply not read, that’s why you get a black hole.

Cheers
Andrea