Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#3263 closed defect (fixed)

Fails to load NITF file with large single block

Reported by: mattnott Owned by: Even Rouault
Priority: normal Milestone: 1.10.1
Component: GDAL_Raster Version: 1.9.2
Severity: normal Keywords: NITF
Cc: warmerdam

Description

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?)

Attachments (1)

NitfBigBlockFix.patch (1.2 KB) - added by dadkins 7 years ago.
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.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 7 years ago by mattnott

Version: unspecified1.6.2

comment:2 Changed 7 years ago by 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 ?

comment:3 Changed 7 years ago by 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).

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

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by warmerdam

Cc: warmerdam added
Component: defaultGDAL_Raster
Keywords: NITF added
Owner: changed from warmerdam to Even Rouault

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by Even Rouault

Milestone: 1.6.4
Resolution: fixed
Status: newclosed

Great. Closing now then.

Changed 7 years ago by dadkins

Attachment: NitfBigBlockFix.patch added

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.

comment:9 Changed 7 years ago by dadkins

Milestone: 1.6.41.7.2
Resolution: fixed
Status: closedreopened
Version: 1.6.21.7.1

See attached file NitfBitBlockFix?.patch

comment:10 in reply to:  9 Changed 7 years ago by dadkins

Typo, should be NitfBigBlockFix.patch

Replying to dadkins:

See attached file NitfBitBlockFix?.patch

comment:11 Changed 7 years ago by Even Rouault

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

comment:12 Changed 7 years ago by Even Rouault

Resolution: fixed
Status: reopenedclosed

comment:13 Changed 4 years ago by jaredrubinaz

Milestone: 1.7.21.10.1
Resolution: fixed
Status: closedreopened
Version: 1.7.11.9.2

/* 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

comment:14 Changed 4 years ago by Even Rouault

Resolution: fixed
Status: reopenedclosed

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.

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

Note: See TracTickets for help on using tickets.