Unable to set Quality Layers for a JPEG2000 compressed NITF

[chuck1987]

What is the bug?

When attempting to produce a NITF with JPEG2000 compression and multiple quality layers, the quality layers are ignored resulting in an invalid output.

The NITF driver specifies a creation option for QUALITY as :

QUALITY=10-100: Defaults to 75. JPEG quality 10-100

However, when using JPEG2000 compression the documentation specifies :

The QUALITY, BLOCKXSIZE and BLOCKYSIZE, TARGET (target size reduction as a percentage of the original) JP2OpenJPEG-specific creation options can be used. By default BLOCKXSIZE=BLOCKYSIZE=1024 will be used.

The JP2OpenJPEG drivers specifies:

QUALITY=<float_value,float_value,...>: Percentage between 0 and 100. A value of 50 means the file will be half-size in comparison to uncompressed data, 33 means 1/3, etc.. Defaults to 25 (unless the dataset is made of a single band with color table, in which case the default quality is 100). It is possible to specify several quality values (comma separated) to ask for several quality layers. Quality values should be increasing.

I expect to be able to define multiple quality layers for my JPEG2000 compressed NITF, but the software does not allow this.

Warning 6: '0.390625,0.78125,1.5625,3.125,6.25,7.5,8.75,10.0,11.25,12.5,13.75,15.0,16.25,18.75,21.25,25.0,28.749999999999996,43.75,48.74999999999999' is an unexpected value for QUALITY creation option of type int.

Steps to reproduce the issue

gdal_translate input.ntf output.ntf -co IC=C8 -co JPEG2000_DRIVER=JP2OpenJPEG -co QUALITY=0.390625,0.78125,1.5625,3.125,6.25,7.5,8.75,10.0,11.25,12.5,13.75,15.0,16.25,18.75,21.25,25.0,28.749999999999996,43.75,48.74999999999999

Warning 6: '0.390625,0.78125,1.5625,3.125,6.25,7.5,8.75,10.0,11.25,12.5,13.75,15.0,16.25,18.75,21.25,25.0,28.749999999999996,43.75,48.74999999999999' is an unexpected value for QUALITY creation option of type int.

Versions and provenance

Windows/Linux
GDAL 3.10

Additional context

No response

[jratike80]

As comparison, when I was experimenting with DGIWG-style JPEG 2000 I used this command successfully:

gdal_translate -of JP2OpenJPEG -co GMLJP2V2_DEF=YES -co BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co PROFILE=PROFILE_1 -co REVERSIBLE=no -co YCBCR420=YES -co QUALITY=0.390625,0.78125,1.5625,3.125,6.625 -co RESOLUTIONS=6 -co PRECINCTS={256,256},{128,128},{128,128},{128,128},{128,128},{128,128} -co CODEBLOCK_WIDTH=64 -co CODEBLOCK_HEIGHT=64 -co PROGRESSION=RPCL -co PLT=YES -co TLM=YES -co SOP=YES -co EPH=YES input.tif output.jp2

[rouault]

you can safely ignore the warning. Fix in #10930

[chuck1987]

I am not concerned about the warning. But I do not get the expected result.

For example:

If I use
QUALITY=18 I get a 120.5mb result,

but if I use

QUALITY=0.390625,0.78125,1.5625,3.125,6.25,7.5,8.75,10.0,11.25,12.5,13.75,15.0,16.25,18.75,21.25,25.0,28.749999999999996,43.75,48.74999999999999

I get a 2.7mb result.

It would appear that in the code it converts this value to a 'double' which invalidates the comma separated list.

double dfQuality =
    CPLAtof(CSLFetchNameValueDef(papszOptions, "QUALITY", "0"));

// Set it now before the NPJE profiles have a chance to override it
if (dfQuality > 0)
{
    papszJP2Options = CSLSetNameValue(papszJP2Options, "QUALITY",
                                      CPLSPrintf("%f", dfQuality));
}

[rouault]

It would appear that in the code it converts this value to a 'double' which invalidates the comma separated list.

you're right. I got confused. Pull request amended with a proper fix