Opened 18 years ago

Closed 17 years ago

Last modified 16 years ago

#1313 closed defect (fixed)

GDAL can't read this VQ compressed NITF image

Reported by: pgao@… Owned by: warmerdam
Priority: highest Milestone: 1.4.3
Component: GDAL_Raster Version: unspecified
Severity: blocker Keywords:
Cc:

Description (last modified by Mateusz Łoskot)

GDAL can't read this VQ compressed NITF image, NITF21_CGM_ANNO.ntf. This is a valid NITF image, and can be displayed using, e.g. Geo*View.

Change History (3)

comment:1 by warmerdam, 18 years ago

Gao, 

This image is killing me! 

It seems the RPFHDR has an incorrect pointer to the location table. 
I worked around this by finding the RPFIMG TRE on the image to get
the location table, instead of using the RPFHDR to find it. 

It also turns out that the location table offsets for stuff like the
spatial coverage (location) are wrong.  I figure out how to offset these 
by checking how far wrong the location table's pointer to the RPFHDR TRE 
is and applying the same offset to the rest of the locations.  This got the
geolocation information working.

Next I discovered that the VQ LUTs offset in the location table was also
wrong!  I worked around this by search on from the apparent location till
I found a particular signature indicating I was at the VQ LUTs. 

Now after all this, I discover I'm still not getting a correct image
out.  I'm pretty confident I have the right LUTs, and there is no clear
sign that my image offset is wrong. 

Could you email me a screen snap of what the image looks like in Geoview?
I tried the image with Erdas Freeview but it doens't include NITF support.
The image crashes PCI's Freeview (presumably for the same reason it used to
crash GDAL). 

Best regards,

comment:2 by warmerdam, 17 years ago

Description: modified (diff)
Milestone: 1.4.3
Resolution: fixed
Status: assignedclosed

see bug #1714 for more details, but we have come to the conclusion that the location table is corrupt and that trying to compensate is dangerous. Now LoadLocationTable() ignores the location table if the RPFHDR is not where it is expected to be.

Changes (per #1714) are in 1.4.x (for 1.4.3), 1.4-esri and trunk.

comment:3 by Mateusz Łoskot, 16 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.