Compare JPEG2000: Kakadu vs. Jasper (ImageMagick)

[dieter]

Dear all,

we are running some tests to use JPEG2000 as the master format to store the scans of our archives. We'd like to replace TIFF lossless with JPEG2000 lossless. As you might know, there are some ways to convert TIFFs into JPEG2000. One is using the Kakadu library, another one JasPer, as used in ImageMagick.

I have encoded a sample TIFF using Kakadu, using the following options: (defaults as used by Djatoka):

Code: Select all

slope=51651,51337,51186,50804,50548,50232
Clayers=6
Creversible=yes
Cprecincts={256,256},{256,256},{128,128}

This results in an image of 1231 kb.

Converting the same TIFF with ImageMagick, using

Code: Select all

>convert 0001.tif -compress Lossless -quality 100 0001.jp2

results in a 6485kb image.

If I compare both files using IM's compare function, combined with "-metric AE", there are 4.75701e+006 different pixels...
Comparing the original TIFF with a decompressed TIFF-version of the Kakadu JP2, gives the same error rate...

However, both should be lossless (and according to the properties of the files - obtained with kdu_show), both images have been lossless encoded (Creversible = yes)...

Does anyone have an explanation for this quite odd behaviour?

Thanks a lot,
dieter

[^rooker]

I'm not 100% sure, but maybe your imagemagick syntax is wrong. According to the JPEG2000 encoding parameter documentation, lossless encoding would rather be:

Code: Select all

convert image.bmp -define jp2:mode=int image.jp2

I've tried that and reconverted the .jp2 file back to a .bmp to verify if it's lossless. I think the codec thinks it's doing a lossless compression, because comparing the reconverted .bmp to the original gives an interesting (but strange) result:

The pixels match *almost* exactly. By "almost", I mean that some pixel patterns differ by the value "1". Here's an example:

Hex excerpt of pixels within the original bitmap:
0000 0860: 1B 23 39 1F 27 3B 22 2A 3D 20 29 3C 1F 29 3C 23
0000 0870: 2B 3D 22 2A 3B 21 26 32 22 25 2B 27 2B 2D 2E 33
0000 0880: 32 35 3B 37 53 5A 54 7B 84 7F A4 AF AB C5 CD C9
0000 0890: D3 D9 D6 D5 DB D9 CF D6 D5 C1 C8 C8 B0 B6 B7 98
0000 08A0: A5 A7 7B 8E 92

Here's the bmp->jp2->bmp reconverted bitmap:
0000 0860: 1B 23 39 1F 27 3B 22 2A 3D 20 29 3C 1F 29 3C 23
0000 0870: 2B 3D 22 2A 3B 21 26 32 22 25 2B 27 2B 2D 2E 33
0000 0880: 32 35 3B 37 53 5A 54 7B 83 7F A3 AE AA C4 CC C8
0000 0890: D2 D8 D5 D4 DA D8 CE D5 D4 C0 C7 C7 AF B5 B6 97
0000 08A0: A4 A6 7B 8D 91

If you look at the bold hex-bytes, you can see that the copy processed by imagemagick contains almost an identical sequence, but sometimes:

Code: Select all

processed pixel = original value -1

Short excerpt from above example:

Code: Select all

84 => 83
A4 => A3

... and so on.
I wonder if that's normal or if that's a bug in the integer mode implementation of the Jasper library.

[^rooker]

I've just compiled and tested that behavior in the current ImageMagick version (v6.5.8-4), and it seems that everything's fine now: JPEG 2000 in integer mode *is* lossless now.

Ubuntu Hardy's ImageMagick v6.3.7 is the one exhibiting the bit-decreasing behavior shown above.

[fmw42]

convert image.bmp -define jp2:mode=int image.jp2

Interesting. But those docs say that integer mode is the default.

Have you tried

convert image.bmp jp2:image.jp2