Problems making JPEG2000 lossless files truly lossless

[JoakimZiegler]

Code: Select all

Version: ImageMagick 6.9.3-7 Q16 x86_64 2016-03-13 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC OpenMP
Delegates (built-in): bzlib fontconfig freetype jp2 lcms pangocairo png tiff x xml zlib

I'm having some trouble generating lossless JPEG2000 files with ImageMagick. I have a source TIFF image (10 bits per component, sRGB TrueColor), and I do this:

Code: Select all

$ convert -quality 0 -verbose uncompressed.tif -depth 10 -type truecolor -colorspace sRGB uncompressed.jp2
uncompressed.tif TIFF 2048x768 2048x768+0+0 10-bit TrueColor sRGB 5.905MB 0.120u 0:00.129
uncompressed.tif=>uncompressed.jp2 TIFF 2048x768 2048x768+0+0 10-bit TrueColor sRGB 2.657MB 4.220u 0:04.040

I get a JPEG2000 file which visually looks to be identical, however, this indicates it isn't:

Code: Select all

compare -metric PSNR uncompressed.jp2 uncompressed.tif compare.tif
63.2285

On the other hand, if I use OpenJPEG2000's opj_compress utility:

Code: Select all

opj_compress -i uncompressed.tif -o uncompressed-2.j2k

[INFO] tile number 1 / 1
[INFO] Generated outfile uncompressed-2.j2k
encode time: 3927 ms

I do get an identical file:

Code: Select all

compare -metric PSNR uncompressed-2.j2k uncompressed.tif compare.tif
inf

File sizes are similar enough that I assume the difference is due to headers and such. But why isn't ImageMagick generating a file that doesn't match when using compare? Just to specify, not explicitly specifying any of

Code: Select all

-quality 0 -depth 10 -type truecolor -colorspace sRGB

when invoking convert gives the same result. Source file is a photographic image, an uncompressed still frame from a film, actually DCI-P3 RGB color space, but interpreting it consistently as sRGB should be fine.

Am I missing something?

[snibgo]

In my v6.9.2-5 experiments with JP2 from 16 bit/channel/pixel sRGB tiffs, conversion to JP2 is lossless. That is to say:

Code: Select all

convert in.tiff out.jp2
compare -metric RMSE in.tiff out.jp2

... returns 0, and so does "-metric AE".

There may be something in your TIFF file that forces a conversion to make a valid JP2 file. Perhaps the problem is "DCI-P3 RGB color space". If you have a small file that shows the problem, and can upload it somewhere, someone might take a look.

[snibgo]

I don't know how IM handles 10->16 or 16->10 bit conversions. Promotion from 8->16 bits is done by replicating the byte, so for example #AB becomes #ABAB. 10->16 could be similar, but a demotion back to 10 bits might simply ignore the bottom 6 bits.

[JoakimZiegler]

That should also not matter, because the original image this came from is also 10 bits, I've never done any bit depth conversion on it.

Testing a bit further, converting the source image to an 8-bit TIFF and then making an 8-bit JPEG2000 file of that gives me a lossless match between the TIFF and the JPEG2000.

Also, grabbing another TIFF file in 16 bits that I had laying around, and converting that to a 16-bit JPEG2000 file also gives me a match between source and destination.

However, taking that very same 16-bit TIFF file and converting it to a 10-bit TIFF file, using convert image-16b.tif -depth 10 image-10b.tif, and then making a JPEG2000 file from the 10-bit version, using convert image-10b.tif image-10b.jp2 gives me a non-matching file (PSNR 63.2441).

Note that the original 16-bit TIFF had nothing to do with the 10-bit file I tested with originally.

So, am I wrong, or does this look like a bug in ImageMagick? If you grab a 16-bit TIFF, do "convert 16-bit-image.tif -depth 10 10-bit-image.tif" and then do "convert 10-bit-image.tif 10-bit-image.jp2", do 10-bit-image.tif and 10-bit-image.jp2 match for you?

[snibgo]

There seems to be a problem in IM (or a delegate).

Code: Select all

%IM%convert mypic.tiff -strip -depth 10 tiff10.tiff

%IM%convert tiff10.tiff jp10.jp2

%IM%compare -metric RMSE tiff10.tiff jp10.jp2 NULL:
44.2324 (0.000674943)

%IM%convert jp10.jp2 tiff10b.tiff

%IM%compare -metric RMSE tiff10.tiff tiff10b.tiff NULL:
44.2324 (0.000674943)

%IM%compare -metric RMSE tiff10b.tiff jp10.jp2 NULL:
0 (0)

I conclude that converting a 10-bit tiff to jp2 slightly changes the data, by more than trivial rounding error. Converting in the opposite direction, from jp2 to tiff, doesn't change data.

[JoakimZiegler]

Something like that would be my conclusion too (note that there shouldn't even be a rounding error, but that's neither here nor there). How would I go about filing a bug report?

[fmw42]

Something like that would be my conclusion too (note that there shouldn't even be a rounding error, but that's neither here nor there). How would I go about filing a bug report?

Post a note to the Bugs forum and point back to your topic here with a link.

[JoakimZiegler]

Bug posted. Thanks. I assume further follow-up will take place on that forum.

[JoakimZiegler]

Copying this additional info from me from the bug forum post over here in case someone needs it:

I did some additional testing. This also fails for 12-bit and 14-bit depth TIFF images to JPEG2000. (I'm basically using ImageMagick to do convert image-16b.tif -depth 12 image-12b.tif and so on, then compressing those output images to JPEG2000).

Additionally, using a 12-bit TIFF as input when converting to JPEG2000 gives the following warning message:

Code: Select all

convert: Deprecated fields cp_cinema or cp_rsiz are used
Please consider using only the rsiz field
See openjpeg.h documentation for more details
 `OpenJP2' @ warning/jp2.c/JP2WarningHandler/236.