Weird error message when writing a JPG2000 compressed NITF.

[ReinerBeck]

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.

[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.

[warmerdam]

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.

[warmerdam]

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

[warmerdam]

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.