#1882 closed defect (fixed)
Geotiff photometric minimum is white
Reported by: | tomvr | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.5.0 |
Component: | GDAL_Raster | Version: | 1.3.2 |
Severity: | normal | Keywords: | gtiff |
Cc: |
Description
I tried to open a GEOTIFF file where the TIFFTAG_PHOTOMETRIC has been set to PHOTOMETRIC_MINISWHITE. It causes a segmentation fault (floating point exception). The problem occurs on line 2894 of the frmts/gtiff/geotiff.cpp file; here you try to build an inverse color pallette.
nColorCount = 1 << nBitsPerSample; nBitsPersample is 32 in my case ... for ( iColor = 0; iColor < nColorCount; iColor++ ) {
oEntry.c1 = oEntry.c2 = oEntry.c3 =
(255 * (nColorCount - 1 - iColor)) / (nColorCount-1);
oEntry.c4 = 255; poColorTable->SetColorEntry( iColor, &oEntry );
}
'nColorCount' results to 1, resulting in a floating point exception since you are dividing by 0.
In attachment you can find the geotiff file I've used.
Attachments (1)
Change History (6)
by , 16 years ago
Attachment: | geotiff.tiff added |
---|
comment:1 by , 16 years ago
This bug still exists with GDAL trunk. I've commited in trunk in r12294 the following patch that checks that nBitsPerSample is 8 or 16 before creating a colormap. So in the case exhibited here, where the type is GDT_Float32, no colormap is created. But we don't handle the PHOTOMETRIC_MINISWHITE indication. I don't know how we could handle this situation without changing the values of the data...
Index: frmts/gtiff/geotiff.cpp =================================================================== --- frmts/gtiff/geotiff.cpp (révision 12286) +++ frmts/gtiff/geotiff.cpp (copie de travail) @@ -2984,7 +2984,7 @@ { // Build inverted palette if we have inverted photometric. // Pixel values remains unchanged. - if( nPhotometric == PHOTOMETRIC_MINISWHITE ) + if( (nBitsPerSample == 8 || nBitsPerSample == 16) && nPhotometric == PHOTOMETRIC_MINISWHITE ) { GDALColorEntry oEntry; int iColor, nColorCount;
Frank, do you think it should be backported to 1.4 branch ?
comment:3 by , 16 years ago
Milestone: | → 1.5.0 |
---|
Should we consider the fix commited in r12294 as enough to close the bug ?
comment:4 by , 16 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | gtiff added; geotiff removed |
Resolution: | → fixed |
Status: | new → closed |
Even,
I have modified the test a bit so that odd numbers of bits (4/12, etc) will also get color tables. With this minor adjustment I think things are fine. The situation is pretty esoteric, so I'm not going to back port into 1.4 branch.
test geotiff file