Opened 14 years ago

Last modified 14 years ago

#1249 closed defect (wontfix)

JP2KAK Creation Options Needed

Reported by: gregcoats@… Owned by: warmerdam
Priority: highest Milestone:
Component: GDAL_Raster Version: unspecified
Severity: blocker Keywords:


1. Although GDAL provides for the creation of tiled GeoTIFF images, and for the creation of tiled GeoJPEG2000 images via its JasPer based module, GDAL does not provide for the creation of tiled GeoJPEG2000 images via its JP2KAK Kakadu based module.  This is a serious limitation that effectively limits the use of the JP2KAK module to relatively small images.  This is especially bad because Kakadu can handle large images up to an order of magnitude faster than JasPer.  Please add to the JP2KAK module Creation Options that allow the user to specify the JP2 image tile size, which is done natively within Kakadu using Stiles={kdutiley,kdutilex}
2. Additionally, beginning with Kakadu version 5.1 (Kakadu version 5.2 is now available), Kakadu uses the "-num_threads <positive integer>" option to support multiple processors, and multi core processors.  This can greatly speed up processing.
3. Also, when processing large images I find it necessary to use the Kakadu option -flush_period <number of image lines> without which the processing tries to hold the entire input and output images in RAM, and when that fails it gives up, and produces no JP2 file.  Usually I set the -flush_period to the number of lines in the tile being created.  There may be no good reason for setting -flush_period to exceed the number of lines in the tile, but setting it to less than the number of lines in the tile could possibly adversely effect image compression.  Apparently JP2KAK tries to flush every 1024 lines.  That is probably a good default, but it would seem advantages to allow the user to set -flush_period, particularly for large images.
In summary, please add to the JP2KAK Creation Options the ability to pass to Kakadu

Change History (1)

comment:1 Changed 14 years ago by warmerdam


(1) I don't see why the JP2KAK driver is limited to small images.  I have
routinely compress 10GB+ images using this driver, and some clients have done
substantially larger images.   I will conceed I don't support multi-tile images
in jpeg2000.  This is mostly because it keeps the code simpler, and because
knowledgable folks have told me that tiling in JPEG2000 is mostly a bad idea.

(2) The -num_threads stuff requires non-trivial changes to the code, not just
passing a parameter.  The kdu_compress takes care of this for you, but 
at the api level it has two distinct implementation for threaded and unthreaded.
I'm not keen to add this complexity to an already overcomplex driver.

(3) The JP2KAK driver automatically uses a flush period of 1000 lines (I 
believe).   I really don't know why you are experiencing the problem you report.

So, flush period is automatic, Stiles also requires substantial code changes
beyond adding the parameter, and -num-threads requires substantial code

Note: See TracTickets for help on using tickets.