Opened 19 years ago

Closed 17 years ago

#913 closed defect (fixed)

NITF driver fails for some CADRG tiles

Reported by: warmerdam Owned by: Even Rouault
Priority: high Milestone: 1.5.0
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: nitf cadrg
Cc: Mateusz Łoskot, warmerdam

Description (last modified by Mateusz Łoskot)

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.

Attachments (5)

001DR00B.LF2 (190.3 KB ) - added by Mateusz Łoskot 17 years ago.
Sample data file linked by Alan, attached so we don't lose it.
openev.png (336.1 KB ) - added by Mateusz Łoskot 17 years ago.
Screenshot from OpenEV linked from Alan's website (attached so we won't lose it).
globalmapper.png (369.6 KB ) - added by Mateusz Łoskot 17 years ago.
Screenshot from Global Mapper linked from Alan's website (attached so we won't lose it)
005YM00A.LF2 (94.5 KB ) - added by Even Rouault 17 years ago.
gdal_svn_cadrg_bug1744_and_913.patch (10.7 KB ) - added by Even Rouault 17 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 by Mateusz Łoskot, 17 years ago

Cc: Mateusz Łoskot added
Description: modified (diff)

by Mateusz Łoskot, 17 years ago

Attachment: 001DR00B.LF2 added

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

by Mateusz Łoskot, 17 years ago

Attachment: openev.png added

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

by Mateusz Łoskot, 17 years ago

Attachment: globalmapper.png added

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

comment:2 by Mateusz Łoskot, 17 years ago

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?

comment:3 by warmerdam, 17 years ago

Milestone: 1.4.3

comment:4 by Even Rouault, 17 years ago

Maybe related with #1744

comment:5 by Even Rouault, 17 years ago

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.

comment:6 by Even Rouault, 17 years ago

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

by Even Rouault, 17 years ago

Attachment: 005YM00A.LF2 added

comment:7 by Even Rouault, 17 years ago

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)

by Even Rouault, 17 years ago

comment:8 by Even Rouault, 17 years ago

Keywords: nitf cadrg added

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)

comment:9 by warmerdam, 17 years ago

Cc: warmerdam added
Milestone: 1.4.31.5.0
Owner: changed from warmerdam to Even Rouault

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.

comment:10 by Even Rouault, 17 years ago

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.

comment:11 by Even Rouault, 17 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.