Opened 10 years ago

Closed 10 years ago

#3051 closed defect (fixed)

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

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone: 1.6.2
Component: GDAL_Raster Version: 1.6.1
Severity: normal Keywords: JP2KAK NITF PAM
Cc:

Description

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

Attachments (1)

5V090501M0002453694A222002700532M_001519096.ntf.aux.xml (9.1 KB) - added by gaopeng 10 years ago.
The bad aux.xml file

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by gaopeng

The bad aux.xml file

comment:1 Changed 10 years ago by warmerdam

Keywords: JP2KAK NITF PAM added
Status: newassigned

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" );
    }

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.