Setting stats and histogram to JP2 compressed NITF corrupts the aux.xml

[gaopeng]

The generated aux.xml contains lots of blanks in the begining of the file, and the real xml string is written after. It looks like the PAM info is written at an offset.

The PAM file name is

/vsisubfile/3695_819597544,C:\Data\5V090501M0002453694A222002700532M_001519096.ntf.aux.xml

[gaopeng]

The bad aux.xml file

[warmerdam]

Could you look at this as well? I made the following change in gdalpamdataset.cpp. It fixed the problem, but it is likely not a proper fix.

Thanks, Gao

/* -------------------------------------------------------------------- */
/*      Try a proxy lookup, otherwise just add .aux.xml.                */
/* -------------------------------------------------------------------- */
    const char *pszProxyPam = PamGetProxy( pszPhysicalFile );
    if( pszProxyPam != NULL )
        psPam->pszPamFilename = CPLStrdup(pszProxyPam);
    else
    {
        const char* pszFile = strchr( pszPhysicalFile, ',' );
        if (pszFile)
          ++pszFile;
        else
          pszFile = pszPhysicalFile;

        psPam->pszPamFilename = (char*) CPLMalloc(strlen(pszFile)+10);
        strcpy( psPam->pszPamFilename, pszFile );
        strcat( psPam->pszPamFilename, ".aux.xml" );
    }

[warmerdam]

This fix is pretty risky, and could mess up other files that happen to have a comma in them.

I think a more proper fix would likely for the NITF file to instantiate it's own GDALPamRasterBand derived proxy raster band which forwards imagery requests on to the JP2KAKRasterBand rather than the current approach of returning the JP2KAKRasterBand directly as if it were a band of the NITF file.

If this is the best approach, it may apply in a number of other similar circumstances.

I will do some prototyping.

[warmerdam]

I have taken a simplier approach where I ensure that a dirty pam flag on the j2k dataset is propagated to the nitf dataset and that the j2k dataset is marked GPF_NOSAVE. The pam marker propagation was already done for jpeg. I also modified the jpeg to be marked GPF_NOSAVE.

Now, nitf files using the jpeg and jpeg2000 drivers should still save pam information such as stats in through the normal pam channels for the nitf file. This seems to be working fine and I have applied the change in trunk (r17351) and 1.6-esri (r17352).

Please reopen if you still see issues. I am hesitant to backport this into 1.6 general though if there are no problems I suppose it could be.