Opened 9 years ago

Closed 7 years ago

#2344 closed defect (fixed)

Weird error message when writing a JPG2000 compressed NITF.

Reported by: ReinerBeck Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.5.1
Severity: normal Keywords: ecw jp2ecw jpg2000 nitf
Cc: Mateusz Łoskot

Description (last modified by Mateusz Łoskot)

When converting the image (http://veimages.gsfc.nasa.gov//2430/land_ocean_ice_2048.tif) to NITF, the driver reports an error (see below). However, an image is produced despite the message and can be viewed without problems.

gdal_translate -of NITF -co "IC=C8" land_ocean_ice_2048.tif out.ntf
Input file size is 2048, 1024
'''ERROR 1: An error has occurred: Error 86 "File is invalid or corrupt"  file "" line 0'''
0...10...20...30...40...50...60...70...80...90...100 - done.

Change History (5)

comment:1 Changed 9 years ago by Even Rouault

I can confirm. This error message seems to come from the JP2ECW driver. It's also triggered by the ecw_7 test from the autotest suite.

comment:2 Changed 9 years ago by warmerdam

Component: defaultGDAL_Raster
Keywords: jp2ecw added

This is a subtle problem relating to the ECW driver and the virtual layer. I think the ECW driver tries to seek somewhere silly and it more or less passes by uneventfully with real files, but results in an error with virtual files.

It was not immediately apparent to me how to resolve this problem without either reducing the error checking in the virtual file code, or altering the ecw sdk which is outside our control.

My preference for the time being is to do nothing.

comment:3 Changed 9 years ago by Mateusz Łoskot

Cc: Mateusz Łoskot added
Description: modified (diff)
Keywords: ecw jpg2000 nitf added

comment:4 Changed 7 years ago by warmerdam

I can confirm this is still happening with the ECW 4.2 sdk - I'm going to dig a bit deeper.

comment:5 Changed 7 years ago by warmerdam

Resolution: fixed
Status: newclosed

The message was due to a filename in the J2K_SUBFILE: form being passed to QuietDelete? as part of the CreateCopy? process.

It seemed like the cleanest way to fix this was to dispose of the whole J2K_SUBFILE mechanism in favor of /vsisubfile/. This turns out to have led me on a merry chase through various issues, partly due to some mistakes on my part with the VSIIOStream. In any event, after many commits in trunk (but not 1.8) the NITF and GRIB drivers now use /vsisubfile/ for jpeg2000 embedded streams and this now works with the ECW driver. The ECW driver also supports all vsi sources of input for *jpeg2000* data, but not for ecw which apparently has it's own special hooks in the filename based Open() method on the CNCSFile. It does not seem to be accessable using the iostream mechanism.

Note: See TracTickets for help on using tickets.