[Gdal-dev] GDAL and Kakadu JPEG2000 performances and quality

[Julien Demaria]

Frank,

>Julien Demaria wrote:
>>First I try with kdu_compress include in binary package ok Kakadu 4.0.3 
>>for Windows :
>>time kdu_compress.exe -i RGB.bmp -o RGB_kakadu_compress.jp2 -rate 
>>2.85,2.85,2.85
>>=> 36 seconds
>
>Julien,
>
>I am a bit vague on some of the kdu_compress options, but my understanding
>is that -rate 2.85 means produce 2.85 bits per pixel in the compressed file
>which would be equivelent to a quality of roughly 35.  Are you sure the
>comparison is equivelent?

Now I have read the kdu_compress help and I understand better the different 
options :

the next 2 commands lines I think are the most equivalent as I can (with 
the actual GDAL KAKADU options) and give me the same compressed size :

gdal_translate.exe -of JP2KAK -co QUALITY=12 -co LAYERS=1 -co Corder=LRCP 
RGB.bmp RGB_kakadu_gdal.jp2
kdu_compress.exe -i win32_executables/RGB.bmp -o RGB_kdu_compress.jp2 -rate 
2.8834698

The results in term of performances and quality as the same : GDAL is 
slower and the JP2 produced by kdu_compress seems visually better...

The only parameters difference I can see is the Cprecincts option which 
isn't used with kdu_compress default options but I can't pass the 
Cuse_precincts=no and don't pass the Cprecincts options to GDAL ... (if I 
have more time I'll recompile GDAL with a hacked code to test this...).


>    Could I get the .jp2 files produced with
>kdu_compress and gdal_translate?

yes :
ftp.fr-acri.com
user : openev
pass : venepo
filenames : RGB_kakadu_gdal.jp2 and RGB_kdu_compress.jp2
size for each : 8 Mo

I'm uploading the 2 files now ; they'll be accessible in 30 minutes I hope.

>Another aspect is that kakadu *may* be converting to YCbCr color space
>which preserves values better than RGB which is the form GDAL will save
>data as.

Is it this option ?

  Cycc[:<T>]={<yes/no>}
        RGB to Luminance-Chrominance conversion?
            [Default is to convert 3 component images]

so for my test this option should be activated by kdu_compress

>>Maybe this virtual tiling is the reason ?
>>(I don't know how kdu_compress write the data...)
>
>This is a read-side thing, and shouldn't have any effect.

oops you're right virtual tiling only affect read... sorry

>   Of course,
>there are a huge number of options which can come into play for JPEG2000
>compression, and some of the GDAL ones are no doubt different than the
>kdu_compress defaults.

Yes I understand.
I'm not a JP2 expert but I see only that for my example the kdu_compress 
defaults seem work (very) better... (but maybe also kdu_compress provide 
some optimizations which aren't provided by the Kakadu library ?)

The parameters differences I can see are :
Clayers : kdu : 1    GDAL : 12
Cprecincts : kdu : no   GDAL : yes : 
{512,512},{256,512},{128,512},{64,512},{32,512},{16,512},{8,512},{4,512},{2,512}
Corder : kdu : LRCP   GDAL : PRCL

I think I can obtain same results with GDAL with some efforts ; maybe I'll 
work on this if I have more time.

All the best,

Julien