JP2KAK: using kdu_analysis is not recommended

[dzanaga]

We encountered an issue while building with Kakadu v8.0.2. v8.0.3 should solve the issue and is out now. I am sharing here a note from Kakadusoftware which could be of interest as they suggest improvements of the GDAL driver in order to take advantage of the latest functionalities:

“GDAL seems to be using a very old and very low level method for interacting with Kakadu, so it is vulnerable to changes in the core system. Building GDAL with version 8 of Kakadu, you may run into the following, readily resolved, but important to flag issue:

The old (pre v8) kdu_analysis constructor had signature (2nd, weaker form):

kdu_analysis(kdu_resolution resolution, kdu_sample_allocator *allocator,
                   bool use_shorts, float normalization=1.0,
                   kdu_roi_node *roi=NULL, kdu_thread_env *env=NULL,
                   kdu_thread_queue *env_queue=NULL);

The new one's signature (2nd, weaker form) is:

kdu_analysis(kdu_resolution resolution, kdu_sample_allocator *allocator,
                   kdu_push_pull_params &params,
                   bool use_shorts, float normalization=1.0,
                   int push_offset=0, kdu_roi_node *roi=NULL,
                   kdu_thread_env *env=NULL, kdu_thread_queue *env_queue=NULL);

The arguments are the same, except that the new constructor has the params' andpush_offset' arguments. In GDAL, the push_offset argument can remain 0, and the params argument can just be an instance of a kdu_push_pull_params object that you construct temporarily on the stack before invoking the constructor.

That is, you can use the following:

kdu_push_pull_params tmp_params;
engines[c] = kdu_analysis(res, &allocator, params, bUseShorts, 1.0F, 0, roi_node);

However, Kakadu has come a very long way since GDAL starting using the original not recommended kdu_analysis constructor. Using that approach you absolutely cannot take advantage of Kakadu's extremely efficient complexity-constrained (Cplex-EST) HTJ2K encoding technology, for example. It will be far better (and also simpler) for GDAL to evolve to at least using kdu_multi_analysis, or even kdu_stripe_compressor, since these higher level API's automatically offer all of Kakadu's recent innovations. The low level kdu_analysis interface is not used explicitly by any of Kakadu's demo applications, even though it is a key low level interface.”

[jratike80]

The last message I have received from Kakadusoftware was about Kakadu version v7_A_7. Could it mean that my old academic license does not cover version 8.x?

[thareUSGS]

Interesting the HTJ2K seems have an open implementation ( 2-Clause BSD license and supported by Kakadu Software, the company), but the overall Kakadu SDK is still proprietary. Confusing... https://github.com/aous72/OpenJPH

[rouault]

but the overall Kakadu SDK is still proprietary

I assume that there are some "performance pack" in the proprietary bits not found in OpenJPH. To be noted that OpenJPH doesn't implement "yet" all the features common with JPEG2000-Part1: https://github.com/aous72/OpenJPH/blob/master/src/core/codestream/ojph_codestream.cpp#L753 . That said, that's better than nothing!

[rouault]

The build issue is probably no longer current, but the hints about kdu_analysis not being recommended is interesting