Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 2.6.5
-
Fix Version/s: None
-
Component/s: geotiff
-
Labels:None
Description
We have a problem geotiff reported; the file is available as an attachment to the udig bug report.
The geotiff consists of two images:
- A "scanned map" GeoTIFF, which is color-coded with 256 colors (or less) on 1 band.
- A "transparency mask," always present in the file. It identifies the padded pixels wich have the color code "0" in the main picture.
The TIFF tag "SampleFormat" is set to "1" (default) to specify an encoding on an unsigned integer value.
I do not know the library used to generate this file. It is likely a library derived from GDAL.
The 'data' part of a ortho-image product type is composed of a single file GeoTIFF. This file may contain two sub-files (as defined in the "subfile" TIFF specification) and thus two IFD :
one for the image itself and one for the possible transparency mask. The image itself is always described by the first IFD of the file.
The transparency mask is used to encode the notion of padding, in the usual raster-spatial data.
The transparency mask is a dual level image which can be superimposed with the picture described by the first IFD. The pixel value "1" means that the corresponding pixel in the main image is significant (it is part of the active area). Conversely, the pixel value "0" means that the corresponding pixel in the image have an unknown value (it is a padding pixel) and typically must be made transparent to the display.
A transparency mask contains no GeoTIFF tag. As part of this specification, it was decided to use a mask with the same resolution and size as the main image. The transparency mask is thus directly superimposed (pixel by pixel) in the master image.
Issue Links
- is depended upon by
-
UDIG-1694
Can not display correctly some Geotiff
-