Ticket #1744 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

Bad colors for a CADRG file

Reported by: rouault Assigned to: rouault
Priority: normal Milestone: 1.5.0
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: CADRG
Cc: warmerdam

Description

This may be directly related with bug #913, as the data come forom the same source. With some files coming from http://www.aeroplanner.com/cadrg/Samples/CADRG_SNYA.zip, we have an incorrect display of colors in OpenEV, whereas it seems correct in Global Mapper. See for example 0058X00A.LF2. I've attached the CADRG file, a screenshot made with OpenEV and one made with Global Mapper.

Attachments

0058X00A.LF2 (286.9 kB) - added by rouault on 08/16/07 10:02:42.
CADRG file coming from http://www.aeroplanner.com/cadrg/Samples/CADRG_SNYA.zip
0058X00A.LF2.OpenEV.jpg (297.4 kB) - added by rouault on 08/16/07 10:03:14.
Screenshot made with OpenEV
0058X00A.LF2.GlobalMapper.jpg (221.7 kB) - added by rouault on 08/16/07 10:03:32.
Screenshot made with Global Mapper
0058X00A.LF2.OpenEV_OGDI.jpg (403.2 kB) - added by rouault on 08/16/07 14:21:35.
Screenshot made with OpenEV using OGDI bridge
gdal_svn_cadrg_colormap.patch (7.6 kB) - added by rouault on 08/16/07 17:13:06.

Change History

08/16/07 10:02:42 changed by rouault

  • attachment 0058X00A.LF2 added.

CADRG file coming from http://www.aeroplanner.com/cadrg/Samples/CADRG_SNYA.zip

08/16/07 10:03:14 changed by rouault

  • attachment 0058X00A.LF2.OpenEV.jpg added.

Screenshot made with OpenEV

08/16/07 10:03:32 changed by rouault

  • attachment 0058X00A.LF2.GlobalMapper.jpg added.

Screenshot made with Global Mapper

08/16/07 13:33:34 changed by rouault

But the whole CADRG mosaic is displayed correctly when using the OGDI bridge like in : 

openev 'gltp:/rpf/home/even/data/RPF:"1:500K@2@CADRG@DMAAC@0":Image'

08/16/07 14:21:35 changed by rouault

  • attachment 0058X00A.LF2.OpenEV_OGDI.jpg added.

Screenshot made with OpenEV using OGDI bridge

08/16/07 17:12:41 changed by rouault

The attached patch fixes the issue. However as I'm not (yet, lol) a CADRG or NITF specialist, I can't guarantee this is always correct.

Basically, I ported a function from the RPF OGDI driver that reads the colormap section, which was ignored in the GDAL NITF driver. Why it is necessary for this image ? I've observed that for that image the LUT located at offset 937 of the file is not in the expected format R1,R2,...,R176,G1,G2,...,G176,B1,B2,...B176 but in the follwing one : R1,G1,B1,A1,R2,G2,B2,A2..... !!! and it's truncated around color index 130 by other header fields (chIMODE, nBlocksPerRow, etc...)

08/16/07 17:13:06 changed by rouault

  • attachment gdal_svn_cadrg_colormap.patch added.

08/17/07 14:30:13 changed by warmerdam

  • owner changed from warmerdam to rouault.
  • cc set to warmerdam.
  • milestone set to 1.5.0.

Even,

Go ahead and apply this patch, but only in trunk since it is non-trivially risky. Based on a quick scan it looks fine.

08/17/07 16:04:53 changed by rouault

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

Commited in trunk in r11895