Opened 12 years ago
Closed 12 years ago
#4336 closed defect (fixed)
JP2KAK Resiliency Problems with Broken JPEG2000 Files
| Reported by: | warmerdam | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | GDAL_Raster | Version: | unspecified |
| Severity: | normal | Keywords: | JP2KAK |
| Cc: |
Description
Attempting to gdal_translate the file at http://memory.loc.gov/gmd/gmd433/g4332/g4332g/np000131.jp2 results in the error message:
ERROR 1: Kakadu Core Error: Expected to find EPH marker following packet header. Found 0xc092 instead.
I have also encountered similar problems with other apparently improper JPEG2000 files that turn out to be readable using other drivers (ie. JP2ECW). This may be related also to the problem reported in ticket #929.
Note:
See TracTickets
for help on using tickets.
After some debugging of a related file it seems the problems relate to navigation using the PLT marker's precinct sizes. Based on analysis of the low level Kakadu code it seems that with some problem files it is necessary to turn on the resilient flag, turn off persistancy and also disable the seekable flag on the underlying codestream.
I have made changes in r23357 to trigger all of these based off the value of the JP2KAK_RESILIENT flag. So, if enabled all efforts will be made to read the file even if it's internal navigation data is broken from a Kakadu point of view. There is likely a significant performance cost to this (especially in the face of small reads on large files) so we don't really want this to be the default mode.
It might be desirable to back port this to 1.8 though I have not yet done so. Note, I also documented (some) of the JP2KAK config options.