NITF driver fails for some CADRG tiles

[warmerdam]

I have just recently started using GDAL to view CADRG data. I have several sets of data, and GDAL is able to load some of them perfectly.

I am having trouble, however, with the data I downloaded from ​http://www.aeroplanner.com/cadrg/ (click the "Sample CADRG (2.78MB)" for a zip file). I put one of the files here (​http://www.signal11.us/~alan/001DR00B.LF2) for download convenience.

The files load fine in Rockware's Global Mapper software (​http://www.rockware.com . free trial download available), but produce weird images in my application. The weird images I get correlate with images produced by OSSIM's ivew and OpenEV 1.8 In (which uses GDAL).terestingly, ivew and OpenEV Seem to produce very similar images to one another (while not correct).

You can see screenshots here: ​http://www.signal11.us/~alan/openev.png (Screenshot from OpenEV) ​http://www.signal11.us/~alan/globalmapper.png (Screenshot from Global Mapper)

I don't currently have a pressing need to be able to view these particular files, so consider this somewhat of a bug report, although it's hard to say what kind of data I may need to view in the future.

Alan.

alan at signal11 dot us ---

I have confirmed that the NITF driver cannot read it properly.

[Mateusz Łoskot]

Sample data file linked by Alan, attached so we don't lose it.

[Mateusz Łoskot]

Screenshot from OpenEV linked from Alan's website (attached so we won't lose it).

[Mateusz Łoskot]

Screenshot from Global Mapper linked from Alan's website (attached so we won't lose it)

[Mateusz Łoskot]

This bug looks like an old and forgotten one :-) Today, Sophia asked about it on the gdal-dev list:

​bbox coordinates are not correctly read in CADRG files

Perhaps, it's worth to check it?

[Even Rouault]

Maybe related with #1744

[Even Rouault]

There are some inconsistences in this file. It says it is a 'C4' compressed file. It's size in pixels is 1536x1536, the number of blocks is 6x6. So we should have 6*6*6144 = 221 184 bytes for the compressed color data, but the file size is only 194 915. This accounts for the warnings of OpenEV not being able to get pixel blocks.

[Even Rouault]

openev or gdal_translate on 005YM00A.LF2 (attached) cause lots of warnings of 'IReadBlock failed'. The display in openev is incorrect.

[Even Rouault]

In fact, those 2 files have not data for all the 6x6 subblocks. Some of the subblocks are fully transparent and thus not included in the file. The current code doesn't look at the mask subsection which indicates the offset of each subblock or 0xffffffff in case of missing subblock.

Attached patch fixes #913 (and #1744. fix for #1744 is necessary too because the colormap wouldn't appear right without it)

[Even Rouault]

Frank,

do you think the patch is appropiate for commit in trunk ? (commiting in branches/1.4 wouldn't help much as this bug also hits #1744 whose fix has just been commited in trunk)

[warmerdam]

Even,

I'm a bit confused. Your comment suggests the issue is not recognising some tiles are NULL, but the patch seems to be mostly related to adding colortable support. I think this changes should only go in trunk since it seems a bit risky, but I think it looks reasonable so go ahead with that.

[Even Rouault]

Yes, it may seem confusing as the patch was cumulating fixes for two different bugs. The specific patch for #913 consists in adding a new function : NITFLoadSubframeMaskTable.

Commited in trunk in r11910.