ome.tiff with JPEG-2000 lossy compression ignores -quality parameter (constant output size)

[ftucos]

When using bfconvert with JPEG-2000 compression in lossy mode, the -quality parameter does not appear to have any effect on the output file size (and presumably bitrate). Regardless of the value provided, the resulting OME-TIFF files are identical in size.
I also tried first converting the image to a flat TIFF in Fiji and then converting that TIFF to OME-TIFF, but I still observed the same behavior.

This happens both when explicitly specifying -compression "JPEG2000 Lossy" compression and when relying on -quality to trigger lossy encoding.

Commands used

test image: https://doi.org/10.5281/zenodo.19591867

bfconvert \
  -bigtiff \
  -pyramid-resolutions 4 \
  -pyramid-scale 2 \
  -compression "JPEG2000 Lossy" \
  -quality 100 \
  test_image.nd2 test_image_JPEG200_Lossy_Q100.ome.tiff 

Log

ND2Reader initializing test_image.nd2 Searching for blocks Parsing block 'ND2 FILE SIG' 0% Parsing block 'ImageCalibra' 0% Parsing block 'ImageMetadat' 0% Parsing block 'ImageTextInf' 0% Parsing block 'CustomDataVa' 0% Parsing block 'ImageDataSeq' 0% Parsing block 'ImageDataSeq' 0% Parsing block 'CustomDataVa' 99% Parsing block 'CustomData|C' 99% Parsing block 'CustomData|C' 99% Parsing block 'CustomData|C' 99% Parsing block 'CustomData|C' 99% Parsing block 'CustomData|C' 99% Parsing block 'CustomData|P' 99% Parsing block 'CustomData|P' 99% Parsing block 'CustomData|X' 99% Parsing block 'CustomData|Y' 99% Parsing block 'CustomData|Z' 99% Parsing block 'CustomData|Z' 99% Parsing block 'CustomData|Z' 99% Parsing block 'ImageAttribu' 99% Parsing block 'CustomData|A' 99% Parsing block 'ND2 FILEMAP ' 99% [Nikon ND2] -> test_image_JPEG200_Lossy_Q100.ome.tiff [OME-TIFF] Tile size = 8256 x 64 Converted 1/3 planes (33%) Converted 2/3 planes (66%) Converted 3/3 planes (100%) Tile size = 4128 x 64 Converted 1/3 planes (33%) Converted 2/3 planes (66%) Converted 3/3 planes (100%) Tile size = 2064 x 64 Converted 1/3 planes (33%) Converted 2/3 planes (66%) Converted 3/3 planes (100%) Tile size = 1024 x 64 Converted 1/3 planes (33%) Converted 2/3 planes (66%) Converted 3/3 planes (100%) [done] 791.811s elapsed (98.166664+65389.668ms per plane, 5432ms overhead)

The issue persists regardless of whether "JPEG2000" or "JPEG2000 Lossy" is specified with varying `-quality` values.

Observed behavior

Output file size remains identical (~5.8 MB) across a wide range of -quality values (e.g., 3, 5, 10, 50, 100, 1000)
No apparent change in compression ratio or visual quality

Compression	Quality	File size
Original (.nd2)	–	403.3 MB
JPEG2000 Lossy	8	5.8 MB
JPEG2000 Lossy	1000	5.8 MB
JPEG2000 Lossy	-	5.8 MB
JPEG2000 (no explicit quality)	-	222.4 MB
LZW	–	344.1 MB

Expected behavior

The -quality parameter should affect JPEG-2000 compression bitrate
Lower quality → smaller file size
Higher quality → larger file size (approaching lossless)

Environment

bftools versions tested:

• 8.1.1 (in conda environment)
• 8.5.0 (downloaded from the website)

OS: Rocky Linux 9.5 (Blue Onyx)
Hardware: AMD EPYC 9224 (HPC environment)
Input format: Nikon .nd2

[melissalinkert]

Thanks for providing a sample file, @ftucos.

Using this base command:

bfconvert -bigtiff -pyramid-resolutions 4 -pyramid-scale 2 -compression "JPEG-2000 Lossy" test_image.nd2 output.ome.tiff

I do see that there is a small difference in file size when adding the -quality 1 option compared to the -quality 10 option. There are a couple of other options that can be used to more clearly improve compression performance though, in particular -merge (which will pack the 3 channels together so they are not compressed individually) and -tilex/-tiley which sets the dimensions of the compressed tile that will be written. See also https://bio-formats.readthedocs.io/en/latest/users/comlinetools/conversion.html#cmdoption-bfconvert-tilex.

Using a few combinations of these 3 sets of options, I see the following file sizes:

Additional options	File size (bytes)
-quality 10	5821377
-quality 1	5812507
-merge -quality 10	2671095
-merge -quality 1	2662227
-merge -tilex 1024 -tiley 1024 -quality 10	2432353
-merge -tilex 1024 -tiley 1024 -quality 1	2428965

That does indicate that the -quality setting impacts the file size, so is not ignored, even though the difference is not obvious when rounding to the nearest tenth of a MB.

Keep in mind that this is 16 bit data, and the value of -quality for JPEG-2000 Lossy is a bitrate in bits per pixel. -quality values greater than or equal to the original number of bits per pixel are expected to be more or less indistinguishable.

[ftucos]

Thanks for the clarification, I ran a few additional tests to better understand the behavior.

While I do observe some variation in output size when changing the -quality parameter, the differences are extremely small (on the order of a few KB for an original ~400 MB image), which initially made it seem like the parameter had no effect.

Digging further, I realized the issue is largely related to the input data distribution, particularly for 16-bit images, where some channels have intensity values heavily skewed near zero.

After experimenting, I found that rescaling the intensity range before conversion significantly affects JPEG-2000 lossy compression:

Input condition	Compression	Quality	Output size
Original image (test_image.nd2)	–	–	403.3 MB
Flat TIFF (no rescaling)	JPEG2000 Lossy	1	1.1 MB
Flat TIFF (no rescaling)	JPEG2000 Lossy	10	1.1 MB
TIFF with intensity rescaling	JPEG2000 Lossy	1	22.7 MB
TIFF with intensity rescaling	JPEG2000 Lossy	10	61.4 MB

It seems that when intensity values are concentrated in a very narrow low range (typical for 16-bit microscopy channels), JPEG-2000 performs poorly with small effect of the -quality setting. After rescaling to better use the available dynamic range, the effect of the -quality parameter becomes apparent and behaves as expected.

It might be worth adding a warning or a note in the documentation for 16-bit images.

[melissalinkert]

Thanks, @ftucos. Transferring this issue to the https://github.com/ome/bio-formats-documentation repository as that's where documentation changes are made.