[gdal-dev] alpha mask to data value
Etienne Tourigny
etourigny.dev at gmail.com
Thu Apr 3 14:56:40 PDT 2014
On Wed, Apr 2, 2014 at 8: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.
you may wish to file a bug report in the QGIS tracker (if there is none
yet).
> 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.
>
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
>
> Earth: "Mostly harmless"
>
> - revised entry in the HitchHiker's Guide to the Galaxy
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140403/51aadcd2/attachment.html>
More information about the gdal-dev
mailing list