Wrong NITF_IREP metadata value if an image segment has zero band

[gaopeng]

I have a NITF image with 2 image segments. One of them is representing the cloud cover, which has zero band. This segment contains NITF_IREP=NODISPLY. I can see it using a 3rdparty NITF viewer. GDAL returns the metadata item, but the value is wrong. It looks like a random string.

The test image is very large. Let me know you need it.

[warmerdam]

Gao,

I can't see any obvious reason this would be occuring, and there isn't really any way for me to investigate further without the data. Often for NITF files it is sufficient to have the first 100K of the file or so to investigate problems. Perhaps you could clip that off the file and make it available?

[gaopeng]

First 32K bytes of the image

[gaopeng]

First 128K bytes of the image

[Even Rouault]

Newly introduced NITFCollectAttachments() in 1.6 branch and in trunk actually caused gdal to crash on this image. I've workaround that in trunk (r16960) and in branches/1.6 (r16961).

I've seen that the first image segment size is 3,489,226,450 bytes and gets truncated to 2,147,483,647 bytes because the NITF driver currently only supports segment size encoded on a int32. That explains why the second segment is not properly read.

[Even Rouault]

Work done for ticket #2989 probably solves the issue of this ticket

[warmerdam]

I'm closing this ticket on the assumption it was primarily a 2GB barrier issue as suggested by Even. Please reopen if that proves not to be the case (that is, that the #2989 fix does not correct the problem).