Writing NITF Paletted Images in 1.5.0 Corrupted?

[warmerdam]

Hi Frank,

I am trying to upgrade GDAL 1.4.2 to 1.5.0. Our testsuite caught one problem in NITF in GDAL 1.5.0. The problem is that when we are trying to write a RGB palette to NITF, the color entries are not in the right place:

For example, the correct color table should look like this:

   Key               Value
0                                                                    1, 1, 1
1                                                                    2, 2, 2
2                                                                    3, 3, 3
3                                                                    ...

The NITF driver in GDAL 1.5.0 may write the following:

   Key               Value
0                       1, ?, ?
1                       2, 1, ?
2                       3, 2, 1
3                       ...

The red component is always correct, but the green and blue components are shifted down or wrong. It doesn't happen all the time. I prove that the changes for Bug #1751 in your bug tracking system cause the problem:

/* -------------------------------------------------------------------- */
/*      Bug #1751: Add a transparent color if there are none. Absent    */
/*      subblocks will be then transparent.                             */
/* -------------------------------------------------------------------- */
    if( !psImage->bNoDataSet
        && psImage->nBands == 1
        && psImage->nBitsPerSample == 8 )
    {
        NITFBandInfo *psBandInfo = psImage->pasBandInfo;
        if (psBandInfo->nSignificantLUTEntries < 256-1
            && psBandInfo->pabyLUT != NULL )
        {
            psBandInfo->pabyLUT[0+psBandInfo->nSignificantLUTEntries] = 0;
            psBandInfo->pabyLUT[256+psBandInfo->nSignificantLUTEntries] = 0;
            psBandInfo->pabyLUT[512+psBandInfo->nSignificantLUTEntries] = 0;
            psImage->bNoDataSet = TRUE;
            psImage->nNoDataValue = psBandInfo->nSignificantLUTEntries;
            psBandInfo->nSignificantLUTEntries ++;
        }
    }

The last line seems to append one nodata entry to the color table. I am not sure if the NELUT field (the number of entries in the NITF color table) needs to be updated to reflect the extra entry.

Thank you,

Angus Lau Raster Team Developer Safe Software Inc. 604-501-9985 (ext. 295)

[Even Rouault]

Augus's analysis is perfectly correct.

Fixed in trunk in r13898 and in branches/1.5 in r13899