Support TIFF files with improperly scaled colortable values

[izzybitsie@…]

"TIFF colors maps are supposed to have colors in the
range 0-65535 for each component instead of the usual 0-255 in other
formats.  If geotiff file has been incorrectly generated to
have the colormap between 0 and 255, GDAL converts it to
0-255 values (roughly by dividing by 256) so everything ends up black.
This may be a fairly common failure with tiff generators
and that some applications may have special logic to look for files
with all colormap values in the 0-255 range and avoid the rescaling
that should happen." Explanation offered by Frank Warmerdam to problem reported in gdal-dev forum.

Input image of the type mentioned can be downloaded from : http://www.mediamax.com/izzybitsie/Hosted/AS_GMSNO_00_20061122205548.tif.gz

When using gdal_merge.py to mosaic several images of this type a black map is obtained as output.

[warmerdam]

Updated summary to be more descriptive. 

[warmerdam]

Updated colortable reading to look guess about the scaling problem, and
fix up on the fly if encountered.  Like this:

        int	nColorCount, nMaxColor = 0;
        GDALColorEntry oEntry;

        poColorTable = new GDALColorTable();

        nColorCount = 1 << nBitsPerSample;

        for( int iColor = nColorCount - 1; iColor >= 0; iColor-- )
        {
            oEntry.c1 = panRed[iColor] / 256;
            oEntry.c2 = panGreen[iColor] / 256;
            oEntry.c3 = panBlue[iColor] / 256;
            oEntry.c4 = 255;

            poColorTable->SetColorEntry( iColor, &oEntry );

            nMaxColor = MAX(nMaxColor,panRed[iColor]);
            nMaxColor = MAX(nMaxColor,panGreen[iColor]);
            nMaxColor = MAX(nMaxColor,panBlue[iColor]);
        }

        // Bug 1384 - Some TIFF files are generated with color map entry
        // values in range 0-255 instead of 0-65535 - try to handle these
        // gracefully.
        if( nMaxColor > 0 && nMaxColor < 256 )
        {
            CPLDebug( "GTiff", "TIFF ColorTable seems to be improperly scaled, fixing up." );
            
            for( int iColor = nColorCount - 1; iColor >= 0; iColor-- )
            {
                oEntry.c1 = panRed[iColor];
                oEntry.c2 = panGreen[iColor];
                oEntry.c3 = panBlue[iColor];
                oEntry.c4 = 255;
                
                poColorTable->SetColorEntry( iColor, &oEntry );
            }
        }

The problem file has been archived in data/geotiff/misc as:
 
   Bug1384_8bit_colortable.tif

[warmerdam]

Due to an unfortunate oversight on my part this change was not committed till
late January 4th 2007, and so it did not make it into GDAL 1.4.0 RC1, and
thus likely not into GDAL 1.4.0 final.

[hobu]

Will this one make it into 1.4.1?

[warmerdam]

I have confirmed that this fix made it into the 1.4.1 branch.