Fails to load NITF file with large single block

[mattnott]

I have a NITF 2.1 file that is around 20,000 x 2000 pixels arranged as a single block. When I try and open it with the python bindings I get an error saying :

Bad values in NITF image : nCols=17500, nRows=1866, nBlockWidth=0, nBlockHeight=0

If I look at the metadata tags in RemoteView I see that NPPBV and NPPBH are set to '0000'. If I look at the values of NBPR and NBPC they are both set to 0001. Looking at the NITF spec paragraph 5.4.2.2-d states that these values are correct if the image is a single block but has more than 8192 pixels in width/height in that block - so I think its a bug in gdal (1.6.2). (The file loads fine in RemoteView)

[Even Rouault]

Could you attach the beginning of the file to the ticket, something like the first 10 K should be sufficient to get at least the header ?

[mattnott]

Unfortunately the file is at work and so for a couple of reasons that's not possible. If you're interested in any fields n particular I should be able to provide them.

I can add that I wrote a quick hack just to poke some non-zero numbers into NBBPV & NBBPH into copy of the file, and GDAL can the open the copy fine (although obviously I now get corrupt image in RV but at least I can pull the metadata out of the NITF with gdal now).

[Even Rouault]

Should be fixed by following commits. I'd appreciate your feedback if you're in a position to update from SVN and test. Otherwise if you're on Windows, you could try tomorrow one of the Tamas Szekeres' daily builds at ​http://vbkto.dyndns.org/sdk/ (check that 2nd figure in the 'latest revision' column is at least 18198)

r18196 /trunk/gdal/frmts/nitf/ (nitffile.c nitfimage.c): NITF : support for reading and writing NITF file with large single block (#3263)

r18197 /branches/1.6/gdal/frmts/nitf/nitfimage.c: NITF : support for reading NITF file with large single block (#3263)

r18198 /trunk/autotest/gdrivers/nitf.py: Test reading and writing a NITF file with large single block (#3263)

[mattnott]

Unfortunately the location I'm working in is Windows based, but the download you linked to is for > r1820x. I shall install that soon and get back to you.

Thanks very much for you prompt replies & fixes.

[mattnott]

I installed the version I mentioned above, and it appears to work OK and can now load my files OK.

Thanks very much for your fix.

[Even Rouault]

Great. Closing now then.

[dadkins]

Fixes single big block (either horizontal or vertical, but not necessarily both) in accordance with the text in MIL-STD-2500C 5.4.2.2 paragraph d. Existing code forces both NPPBV and NPPBH to be 0 to allow big blocks; this patch allows either to be set to 0 as should be the case.

[dadkins]

See attached file NitfBitBlockFix.patch

[dadkins]

Typo, should be NitfBigBlockFix.patch

Replying to dadkins:

See attached file NitfBitBlockFix.patch

[Even Rouault]

NitfBigBlockFix.patch commited in trunk (r19271), branches/1.7 (r19272) and branches/1.6 (r19273). Thanks

[jaredrubinaz]

/* See MIL-STD-2500-C, paragraph 5.4.2.2-d (#3263) */

525 if (EQUAL(psImage->szIC, "NC") &&

526 (psImage->nCols > 8192

psImage->nRows > 8192))

The above in nitfimage.c is still wrong. The test for 8192 is not needed. Reread the spec. the above should just be if EQUAL(psImage->szIC, "NC")

so remove line 526

I came across an image that was 100 columns by rows and had NPPBV and NPPBH set to 0

[Even Rouault]

Fixed in trunk r26188 and branches/1.10 r26189

jaredrubinaz: could you tell if the above fix also fixes #4505 that I believe you also created ? It seems related but perhaps not entirely identical. If the issues are different, please update #4505 with the information asked in its last comment.

[jaredrubinaz]

Yes the fix works. That 8192 threshold is not the only case where you could have NPPBV and NPPBH both set to 0 according to the 2500c spec