[GRASS5] [bug #3011] (grass) d.mon CELL doesn't work

[Glynn Clements]

Maciek Sieczka wrote:

> > The preferred solution is the PNG driver, plus r.in.gdal[1] if you
> > want to import the image as a map
> 
> > (I have no idea why you would
> 
> Because we are talking here about substituting the CELL driver 
> functionality. And as I understand it, CELL driver is for obtaining a Grass 
> layer out of the monitor content (not a particular layer, like r.out.gdal, 
> or a fragment of layer currently displayed, like r.out.tiff -t) with a 
> colortable stored.

Yeah, but why would you want CELL driver functionality?

> > unlikely to be georeferenced correctly).
> 
> Sure.
> 
> So here all arguments for having CELL driver to Grass61:
> 1. d.out.png + r.in.gdal requires an intermediate file to duplicate the CELL 
> driver functionality

Note that d.out.png is just an interface to the PNG driver. It
essentially "grabs" the current monitor by storing its contents using
d.save, then replicating them on the PNG driver.

> 2. r.region is required to georeference the PNG image dump back after 
> r.in.gdal

Exactly the same issue applies to the CELL driver. The resulting map
has an X/Y projection and uses screen coordinates. Also, unless the
aspect ratio of the monitor exactly matches that of the region, the
combination of d.rast and the CELL driver will result in a raster
which has been scaled down and centred.

> 3. if the image dump was over 8 bit, r.composite is required to merge the 3 
> layers output by r.in.gdal; moreover, using r.composite, it is unlikely to 
> obtain an exact copy of the original PNG image dump

The CELL driver only supports 8-bit colour.

And GRASS sucks at 24-bpp images in general. You can create a 24-bpp
image with r.composite, but it will have 16777216 categories, and the
colour table will have 65536 rules. Processing such images is likely
to be extremely slow.

Colour tables are meant for graphical visualisation of raster maps
where the cell values represent categories or scalar quantities. They
aren't meant to turn raster maps into images.

Colour images should always be processed as separate bands. The only
purpose of r.composite is as a workaround for tools which lack the
ability to use separate colour bands in place of a single map (e.g. 
NVIZ surface colours, v.digit background). Ideally, the tools would be
upgraded, but r.composite serves as a workaround until then.

> 4. alltogether, even if possible to overcome all these problem, CELL driver 
> seems much easier in use - one operation instead of 3 or 4.

Other way around. With the CELL driver, you have the added step of
running r.out.png afterwards. AFAIK, the only purpose of the CELL
driver is so that you can use it in conjunction with r.out.* to get
the functionality of the PNG driver.

> My question is if, in the light of above, CELL driver should be ported to 
> Grass61 or not and if it is likely to be done.

No, in both cases.

> Why do we need r.in.png if r.in.gdal provides this functionality?

Because r.in.gdal only provides a subset of r.in.png's functionality. 

-- 
Glynn Clements <glynn at gclements.plus.com>