Opened 17 years ago

Closed 17 years ago

#1744 closed defect (fixed)

Bad colors for a CADRG file

Reported by: Even Rouault Owned by: Even 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 (5)

0058X00A.LF2 (286.9 KB ) - added by Even Rouault 17 years ago.
CADRG file coming from http://www.aeroplanner.com/cadrg/Samples/CADRG_SNYA.zip
0058X00A.LF2.OpenEV.jpg (297.4 KB ) - added by Even Rouault 17 years ago.
Screenshot made with OpenEV
0058X00A.LF2.GlobalMapper.jpg (221.7 KB ) - added by Even Rouault 17 years ago.
Screenshot made with Global Mapper
0058X00A.LF2.OpenEV_OGDI.jpg (403.2 KB ) - added by Even Rouault 17 years ago.
Screenshot made with OpenEV using OGDI bridge
gdal_svn_cadrg_colormap.patch (7.6 KB ) - added by Even Rouault 17 years ago.

Download all attachments as: .zip

Change History (9)

by Even Rouault, 17 years ago

Attachment: 0058X00A.LF2 added

by Even Rouault, 17 years ago

Attachment: 0058X00A.LF2.OpenEV.jpg added

Screenshot made with OpenEV

by Even Rouault, 17 years ago

Screenshot made with Global Mapper

comment:1 by Even Rouault, 17 years ago

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'

by Even Rouault, 17 years ago

Screenshot made with OpenEV using OGDI bridge

comment:2 by Even Rouault, 17 years ago

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

by Even Rouault, 17 years ago

comment:3 by warmerdam, 17 years ago

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

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.

comment:4 by Even Rouault, 17 years ago

Resolution: fixed
Status: newclosed

Commited in trunk in r11895

Note: See TracTickets for help on using tickets.