Some RSets are not identified as overviews

[gaopeng]

Some RSets don't have r0. In this case, r1,... should be used as the overviews of the base image, but they are currently not.

Attached is a fix. It seems to work for non-JP2 compressed nitf, but the overviews are not used if it's JP2 compressed.

Could you look at it?

[warmerdam]

Gao,

Robin filed a ticket (#3545) on this earlier today or yesterday and has incorporated the change in 1.6-esri. I have migrated it to trunk.

I gather you need me to still investigate why the overviews are not used for JP2 compressed nitf - is that right? Can you provide a sample dataset I can use for debugging?

[gaopeng]

Frank,

Yes. We are working a small sample dataset so you can download.

[gaopeng]

Frank, We can't create a smaller test dataset. We are sending you a DVD containing the original image.

[warmerdam]

In the data sent on the CD the .aux.xml file contains an OVERVIEW_FILE setting (pointing to an .ovr) which is being used instead of rsets. But later when an attempt is made to open the .ovr it fails since the file does not exist. Do you have reason to believe files in the field will have this sort of OVERVIEW_FILE setting? It looks like something left over from earlier testing.

[gaopeng]

There is no reason to believe files in the field will have this sort of OVERVIEW_FILE setting. Robert retested with .aux.xml removed. Here is what he found:

It doesn't seem to help. I renamed the aux.xml file but level of pyramids is still 5 (instead of 4 with the renamed 5th rset level). Also, display is in the minutes rather than seconds it should take with rset pyramids. I also tried editing the aux.xml to remove the <metadata> tag which includes the faulty .ovr reference, but dataset still shows as 5 pyramid layers.

[warmerdam]

I will review further. I had tested with trunk so perhaps there is a distinction in the 1.6-esri branch.

[warmerdam]

I found no issues with 1.6-esri, but I have discovered that accessing the subdatasets of this file does lose the rset support. So while this works fine:

gdal_translate -outsize 2314 6784 ntf_single_rsets.ntf out.tif

this ends up ignorning the rsets:

gdal_translate -outsize 2314 6784 NITF_IM:0:ntf_single_rsets.ntf out.tif

What are the chances that ArcGIS might be accessing through the subdatset name(s)?

[gaopeng]

When there are more than one subdatasets, ArcGIS always opens a subdataset using a subdataset name even for the first subdataset.

[warmerdam]

I have applied a change to search for rset's using the physical filename, rather than the subdataset name which seems to correct subdataset handling for the problem dataset when addressed using the NITF_IM:0: prefix for the filename.

Note that it may be that this file is a problem because it contains two images rather than because it is jpeg2000 compressed.

The change is in trunk (r19570) and 1.6-esri (r19571).

Could Robert retry with this adjustment?

[gaopeng]

Yes.