Opened 11 years ago

Closed 11 years ago

#2249 closed defect (fixed)

Writing NITF Paletted Images in 1.5.0 Corrupted?

Reported by: warmerdam Owned by: Even Rouault
Priority: high Milestone: 1.5.1
Component: GDAL_Raster Version: 1.5.0
Severity: normal Keywords: nitf
Cc: Even Rouault

Description

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)

Change History (2)

comment:1 Changed 11 years ago by Even Rouault

Owner: changed from warmerdam to Even Rouault

comment:2 Changed 11 years ago by Even Rouault

Resolution: fixed
Status: newclosed

Augus's analysis is perfectly correct.

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

Note: See TracTickets for help on using tickets.