PREDICTOR=2 is only supported with 8/16/32/64 bit samples

[pjonsson]

What is the bug?

Running gdal_translate -of COG -co COMPRESS=ZSTD -co PREDICTOR=YES S2A_MSIL2A_20230309T105851_N0509_R094_T31UEB_20230309T184503.SAFE/GRANULE/L2A_T31UEB_A040274_20230309T110129/IMG_DATA/R10m/T31UEB_20230309T105851_B03_10m.jp2 output.tif gives the error message:

ERROR 1: output.tif: PREDICTOR=2 is only supported with 8/16/32/64 bit samples.

I think any Sentinel-2 S2MSI2A product from Copernicus will reproduce the error message. After running gdalinfo on the image and noticing that the band was UInt16, I'm guessing it's the second to last line that is the issue:

<cut>
Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Gray
  Overviews: 5490x5490, 2745x2745, 1373x1373, 687x687
  Overviews: arbitrary
  Image Structure Metadata:
    NBITS=15
    COMPRESSION=JPEG2000

I was trying to measure how much difference the predictor makes, so the main issue is that I found the error message confusing. It would be nice if the error message included the 15 bits part (or is it something else causing the error message?) since the band is UInt16 and I assumed that was a 16 bit sample.

Heading into speculation: I'm also curious if it's technically possible to pad the 15 data bits with a 0 or 1 in the MSB of a 16 bit sample, and use the predictor on that.

Steps to reproduce the issue

Run gdal_translate -of COG -co COMPRESS=ZSTD -co PREDICTOR=YES S2A_MSIL2A_20230309T105851_N0509_R094_T31UEB_20230309T184503.SAFE/GRANULE/L2A_T31UEB_A040274_20230309T110129/IMG_DATA/R10m/T31UEB_20230309T105851_B03_10m.jp2 output.tif. but I believe any recent Sentinel-2 S2MSI2A product should give the same behavior.

Versions and provenance

GDAL 3.10.0 docker image.

Additional context

No response

[rouault]

#11458 will add the hint to specify NBITS=16

Heading into speculation: I'm also curious if it's technically possible to pad the 15 data bits with a 0 or 1 in the MSB of a 16 bit sample, and use the predictor on that.

That's what NBITS=16 will do, but that takes a bit more storage space. In theory doing horizontal differenciation on non power-of-two BitsPerSample value should be possible (the TIFF spec itself mentions that as a possibility), but if that got implemented in libtiff, that would cause backwards compatibility issue with older libtiff-based implementations that couldn't read such files.