Ticket #913 (closed defect: fixed)

Opened 3 years ago

Last modified 11 months ago

NITF driver fails for some CADRG tiles

Reported by: warmerdam Assigned to: rouault
Priority: high Milestone: 1.5.0
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: nitf cadrg
Cc: mloskot, warmerdam

Description (Last modified by mloskot)

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

001DR00B.LF2 (190.3 kB) - added by mloskot on 08/14/07 12:56:36.
Sample data file linked by Alan, attached so we don't lose it.
openev.png (336.1 kB) - added by mloskot on 08/14/07 12:58:23.
Screenshot from OpenEV linked from Alan's website (attached so we won't lose it).
globalmapper.png (369.6 kB) - added by mloskot on 08/14/07 13:00:16.
Screenshot from Global Mapper linked from Alan's website (attached so we won't lose it)
005YM00A.LF2 (94.5 kB) - added by rouault on 08/16/07 17:17:40.
gdal_svn_cadrg_bug1744_and_913.patch (10.7 kB) - added by rouault on 08/16/07 18:43:01.

Change History

08/14/07 12:47:09 changed by mloskot

  • cc set to mloskot.
  • description changed.

08/14/07 12:56:36 changed by mloskot

  • attachment 001DR00B.LF2 added.

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

08/14/07 12:58:23 changed by mloskot

  • attachment openev.png added.

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

08/14/07 13:00:16 changed by mloskot

  • attachment globalmapper.png added.

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

08/14/07 13:02:26 changed by mloskot

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?

08/14/07 14:29:35 changed by warmerdam

  • milestone set to 1.4.3.

08/16/07 10:04:37 changed by rouault

Maybe related with #1744

08/16/07 11:58:44 changed by 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.

08/16/07 17:17:19 changed by rouault

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

08/16/07 17:17:40 changed by rouault

  • attachment 005YM00A.LF2 added.

08/16/07 18:02:23 changed by 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)

08/16/07 18:43:01 changed by rouault

  • attachment gdal_svn_cadrg_bug1744_and_913.patch added.

08/18/07 12:21:08 changed by rouault

  • keywords set to nitf cadrg.

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)

08/18/07 12:35:46 changed by warmerdam

  • owner changed from warmerdam to rouault.
  • cc changed from mloskot to mloskot, warmerdam.
  • milestone changed from 1.4.3 to 1.5.0.

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.

08/18/07 12:57:02 changed by 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.

08/18/07 12:57:09 changed by rouault

  • status changed from new to closed.
  • resolution set to fixed.