[gdal-dev] alpha mask to data value

[Even Rouault]

Le vendredi 04 avril 2014 16:08:47, William Kyngesburye a écrit :
> On Apr 3, 2014, at 4:29 PM, Even Rouault <even.rouault at mines-paris.org> 
wrote:
> > 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:
> >>> 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.
> 
>  -wo UNIFIED_SRC_NODATA=YES works on a nodata value vrt.  So I do all the
> work (clean, rectify, project) with alpha-masked tifs, then convert to
> nodata values for the the vrt (because it doesn't like alpha masks), back
> to alpha mask tif for the whole merged image using the UNIFIED_SRC_NODATA
> and INIT_DEST options, then strip out the alpha band to get a white
> background.  phwew!

Hum, I confess I've not followed all your attempts and may have confused 
nodata and alpha. But I think that gdalwarp + INIT_DEST should normally do the 
job.

> 
> It stills seems like there is something wrong with a vrt and alpha nodata
> bands.  I understand how it overlays each source over the previous ones. 
> So, it should take into account the nodata mask in what form it is for a
> source, then overlay the remaining pixels on the full image.  This is what
> it does when the sources have nodata values.  But when the sources have
> alpha nodata masks (if I leave the generated vrt alone and don't change it
> to a MaskBand), it appears to instead combine the alpha bands and data
> bands separately and apply the merged alpha band to the merged data bands.
> 
> Is this normal (and why)?  Or a bug?

Normal in the sense that what you observe is the consequence of the code ;-)

There's specific code to deal with nodata values when overlaying sources in the 
VRT band, but no for alpha currently. I'm not sure if there are use cases 
where the current behaviour would make sense. If not, then it could likely be 
fixed. If there are use cases for the current behaviour, an option in the VRT 
could select the intended behaviour.

> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> "I ache, therefore I am.  Or in my case - I am, therefore I ache."
> 
> - Marvin

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