[gdal-dev] alpha mask to data value

[Even Rouault]

Le jeudi 03 avril 2014 23:22:17, William Kyngesburye a écrit :
> On Apr 2, 2014, at 6:10 PM, William Kyngesburye <woklist at kyngchaos.com> 
wrote:
> > On Apr 2, 2014, at 4:33 PM, Even Rouault <even.rouault at mines-paris.org> 
wrote:
> >> Le mardi 01 avril 2014 22:14:11, William Kyngesburye a écrit :
> >>> I've wrestled with various nodata issues in the past, now it's hitting
> >>> me again...
> >>> 
> >>> I'm using Photoshop to delete collars on scanned maps, creating an
> >>> alpha mask.  GDAL has no problem with this.  What I want to do is
> >>> merge maps together (after rectification), then set any remaining
> >>> nodata areas to white, RGB 255,255,255.  Just dropping the extra alpha
> >>> band doesn't work because nodata is set to 0,0,0, which is black.  The
> >>> a_nodata option in gdal_translate just defines what existing value in
> >>> the data is nodata.
> >>> 
> >>> I tried using gdalwarp with the -dstnodata option which should set
> >>> nodata values in the output to a specific value, but it carries along
> >>> the alpha band and ignores dstnodata.
> >>> 
> >>> gdalwarp -dstnodata "255 255 255" in.tif out.tif
> >>> Processing input file in.tif.
> >>> Using band 4 of source image as alpha.
> >>> Using band 4 of destination image as alpha.
> >> 
> >> You can perhaps try adding  -wo INIT_DEST="255,255,255,0"
> > 
> > That appears to work, though not immediately.  The raster has 255 in the
> > nodata areas, but it's not until I strip out the alpha band with
> > gdal_translate that it shows.
> > 
> > Now I see an odd artifact, or maybe bug somewhere - with nodata values in
> > an RGB image, if any one or two of the bands for a pixel are 255 while
> > the other bands are not, the pixel as a whole is treated as nodata when
> > displaying in QGIS.  Though identifying such a pixel will show nodata
> > for just the band(s) that are 255.  Photoshop has no concept of nodata
> > values, so it displays correctly (and with white for fully nodata
> > pixels).
> > 
> > I think this explains another issue I saw at one point when I had ovelap
> > when merging 2 rasters: the pixels of the top raster covered the pixels
> > of the lower at the band level, which caused the band of the lower to
> > show through when the upper band was 255, and resulted in a wild color
> > mix. ie:
> > 
> > result 127 127 127 (grey) but should have been 255 127 127
> > 
> >        ^
> > 
> > upper  255 127 127 (pink)
> > 
> >        ^
> > 
> > lower  127 127 127 (grey)
> > 
> > I think I'll save the nodata flattening to white until the end, after
> > merging.
> 
> Well, now I'm running into another problem I had previously, which is also
> why I wanted change the alpha mask to a nodata value: I can't get a vrt to
> recognize the alpha bands as nodata.
> 
> If I use a simple gdalbuildvrt with a collection of images with alpha
> masks, gdal tells me:
> 
> Band 1 Block=128x128 Type=Byte, ColorInterp=Red
>   Mask Flags: PER_DATASET ALPHA
> Band 2 Block=128x128 Type=Byte, ColorInterp=Green
>   Mask Flags: PER_DATASET ALPHA
> Band 3 Block=128x128 Type=Byte, ColorInterp=Blue
>   Mask Flags: PER_DATASET ALPHA
> Band 4 Block=128x128 Type=Byte, ColorInterp=Alpha
> 
> Which looks correct.  But displaying in QGIS I get an alpha mask with the
> overlap areas null.
> 
> Same if I gdal_translate that to geotiff, (photoshop checkered background):
> 
> 
> 
> I tried changing the alpha band in the vrt to a mask band as described in
> the vrt tutorial docs
> 
>   <MaskBand>
>     <VRTRasterBand dataType="Byte">
>       <SimpleSource>
>       <SourceBand>mask,1</SourceBand>
>       ...
>       </SimpleSource>
>     </VRTRasterBand>
>   </MaskBand>
> 
> and then there is no mask/nodata at all.  Though converting to geotif gives
> me an extra .msk file.
> 
> also tried for the mask band:
> 
>       <SourceBand>4</SourceBand>
> 
> with same results.

Yes, (regular) VRT does not do any blending. The last file in the list takes 
precedence over the previous one in case of overlapping.
gdalwarp is the solution for that (or warped VRT).

You may want to try -wo UNIFIED_SRC_NODATA=YES as a gdalwarp option so that 
only the "255 255 255" triplet is considered as the nodata value.

Extract from code (I would have pointed to the html doc if the server wasn't 
out of service for now ):

 * - UNIFIED_SRC_NODATA=YES/[NO]: By default nodata masking values considered
 * independently for each band.  However, sometimes it is desired to treat all
 * bands as nodata if and only if, all bands match the corresponding nodata
 * values.  To get this behavior set this option to YES. 

> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> All generalizations are dangerous, even this one.

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html