Opened 9 years ago

Closed 6 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: mloskot

Description (last modified by mloskot)

When converting the image ( 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 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 changed from default to GDAL_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 mloskot

  • Cc mloskot added
  • Description modified (diff)
  • Keywords ecw jpg2000 nitf added

comment:4 Changed 6 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 6 years ago by warmerdam

  • Resolution set to fixed
  • Status changed from new to closed

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.