[GRASS-dev] [GRASS GIS] #3130: r.out.gdal: add alpha channel support

GRASS GIS trac at osgeo.org
Fri Aug 12 12:02:12 PDT 2016


#3130: r.out.gdal: add alpha channel support
--------------------------+---------------------------------
  Reporter:  neteler      |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.2.0
 Component:  Raster       |    Version:  svn-releasebranch72
Resolution:               |   Keywords:  r.out.gdal
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+---------------------------------

Comment (by mmetz):

 Replying to [comment:2 neteler]:
 > Replying to [comment:1 mmetz]:
 > > Replying to [ticket:3130 neteler]:
 > ...
 > > According to Landsat metadat, 0 is not a valid data value, valid range
 is 1 - 255. Also, r.info -r shows that 0 is not present, therefore 0 can
 be used for nodata.
 >
 > Well, this was just intended as simple example to reproduce the issue.
 Indeed I am using different data. At least there is no guarantee that 0 is
 never a valid dataset while having 8 bit to be exported.

 If there are NULL cells in the bands to be exported, a valid value
 according to the selected output data type needs to be selected to
 represent nodata, otherwise NULL cells can not be encoded, e.g. for Byte,
 the value representing nodata must be in the range 0-255. This is why you
 see "Checking GDAL data type and nodata value..." in the output of
 r.out.gdal. The module does not always choose 0 as nodata value, this
 depends on the input bands and the selected output data type.

 >
 > > > The only solution seems to be an extra alpha channel to be stored in
 the resulting GDAL file (here: GeoTIFF).
 > >
 > > You mean r.out.gdal should create this extra alpha channel internally?
 >
 > Yes, I thought so.
 >
 > > You could also try the PHOTOMETRIC and ALPHA creation options for
 GeoTIFF with a corresponding alpha channel created manually.
 >
 > Interesting - do you have an example? Would be happy to close this
 ticket as "worksforme" :)

 You would need to create an alpha channel that encodes NULL cells and in
 the bands to be exported replace NULL cells with some value in the range
 0-255. For example

 {{{
 RMAP="lsat7_2000_30"
 GMAP="lsat7_2000_20"
 BMAP="lsat7_2000_10"

 OUTNAME="lsat7_2000.tif"

 # extract alpha
 r.mapcalc "out_a = if(isnull($RMAP) || isnull($GMAP) || isnull($BMAP), 0,
 255)"

 # replace NULL cells with a valid value, extract colors

 # extract red
 r.mapcalc "out_r = if(isnull($RMAP), 0, #$RMAP)"
 # extract green
 r.mapcalc "out_g = if(isnull($GMAP), 0, #$GMAP)"
 # extract blue
 r.mapcalc "out_b = if(isnull($BMAP), 0, #$BMAP)"

 # create group
 i.group group=out_rgba input=out_r,out_g,out_b,out_a

 # remove any MASK because this works only if there are
 # no NULL cells in the bands to be exported
 r.mask -r

 # export the group
 # add PROFILE=BASELINE to createopt to produce a standard TIFF file
 without out GTiff extensions
 r.out.gdal in=out_rgba out=$OUTNAME -cm
 createopt="PHOTOMETRIC=RGB,ALPHA=YES"
 }}}

 A nice enhancement to r.out.gdal would be to accept multiple input raster
 maps, this would avoid the need to create a group just for exporting
 multiple raster maps into a single GDAL raster dataset.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3130#comment:3>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list