[gdal-dev] alpha mask to data value

[William Kyngesburye]

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!

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?

-----
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