On Apr 3, 2014, at 4:29 PM, Even Rouault <[email protected]> wrote:
> Le jeudi 03 avril 2014 23:22:17, William Kyngesburye a écrit : >> On Apr 2, 2014, at 6:10 PM, William Kyngesburye <[email protected]> > 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
