On Wed, Apr 2, 2014 at 8:10 PM, William Kyngesburye <wokl...@kyngchaos.com>wrote:
> On Apr 2, 2014, at 4:33 PM, Even Rouault <even.roua...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev