GDAL JP2KAK request to extend QUALITY range

[Coatman]

As the GDAL JP2KAK Quality decreases, the time required by the Kakadu JPEG2000 compressor decreases. Before starting Kakadu-based JPEG2000 compression jobs that are going to run for many hours / several days, I frequently make a test run using a high compression ratio, equivalent to JP2KAK Quality=0.001. Currently, JP2KAK refuses to process requests for Quality < 1.0. I suggest consideration be given to changing line 2226 of 1.6/gdal/frmts/jp2kak/jp2kakdataset.cpp from if( dfQuality < 1.0 to if( dfQuality < 0.001.

[warmerdam]

The goal of the current restrictions is to warn users who mistakenly assume that quality should be a value between 0 and 1 (as opposed up to 100). I would not really like to remove the restriction, and I can't help but think 1% quality should be adequately fast for a test run.

[Coatman]

For large images, the Kakadu compressor is substantially faster with Quality settings much less than 1% because, according to Taubman, there is less processing required. Using a Quality < 1.0 can be a meaningful testing of a complex script that will be used to process many 142 GB images over several days.

The current jp2kakadataset.cpp does not simply warn a user not to create an image with Quality < 1.0, it prevents all users from ever creating any images with Quality < 1.0. In light of your remark, I suggest that when a user enters a Quality < 1.0, a non-fatal warning message be issued, and the total prohibition on creating any images of Quality < 1.0 be removed.

The nature of the Kakadu compressor is that it converts from .tif to .jp2 much more quickly as the compression ratio increases, meaning as the JP2KAK quality decreases, and as more processors are made available via -num_threads. Imposing a restriction of Quality never less than 1.0, particularly when -num_threads more than 1 is not supported, is unnecessary.

[Coatman]

Please feel free to provide a warning in response to a user request for quality < 1.0, but please do not prohibit all users from ever running a quick test using Kakadu at its maximum speed with quality < 1.0.

[Coatman]

Please let users quickly test creating compressed images by requesting Quality < 1.0. I do not object to providing a warning to users requesting Quality < 1.0, but to purposefully prohibit all users from ever creating a quickly compressed image is something that I can not see as justifiable.

[Coatman]

I have made a substantial effort to offer compelling reasons why users should be permitted to request Quality < 1.0. Namely, their JP2 processing will be faster. Particularly given that the 2002 code in JP2KAK is about 4 times slower than the free Kakadu demo applications, I can not think of any good reasons all users should be forever prohibited from obtaining faster processing. There is no reason not to allow users to request Quality < 1.0. If you insist on rejecting this request to improve JP2KAK without even suggesting a reason, then I will present my case as a formal appeal to the appropriate committee. I can not imagine any good reason a committee would not to allow this improvement, this speed up to JP2KAK.

[Coatman]

Why deliberately handicap the GDAL community, particularly when you can not offer any justification for this handicap? Why not provide to the GDAL community at least what Kakadu offers for free to users of Linux, Mac OS X, Solaris, and Windows? I reject your hasty decision, that even you make no effort to defend. Let's move forward now, correct the mistake of the past, and remove this unnecessary limitation, that serves only to make JPEG2000 compression slower for GDAL users that it is for Kakadu users.

[warmerdam]

It appears I neglected to note when I applied this change in trunk (r18657). I have also backported this change to the 1.7 stable branch (r18772).

closing.