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

[Maciek Sieczka]

From: "Glynn Clements" <glynn at gclements.plus.com>

> Maciek Sieczka via RT wrote:
>
>> CELL driver was never ported to 6.1. And there was a discussion about 
>> getting
>> rid of CELL driver for good.
>>
>> What are your conlusions? Is it really a good idea not to support this
>> solution anymore? As I understand (never used it), CELL driver lets me 
>> dump
>> the screen content directly into Grass raster, together with the color 
>> table,
>> right?
>>
>> If so, d.out.png + r.in.gdal (+r.composite in case of over 8 bit image 
>> dumps)
>> is less comfortable and requires an intermediate file. Besides, it will 
>> be
>> hard to obtain an *exact* copy of the over 8-bit colour display with
>> r.composite, no?
>
> 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.

> 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
2. r.region is required to georeference the PNG image dump back after 
r.in.gdal
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
4. alltogether, even if possible to overcome all these problem, CELL driver 
seems much easier in use - one operation instead of 3 or 4.

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. I'm not insisting because I'm 
not actually interested in having this functionality. I'm asking in order to 
sort this issue out and so we had an appropriate information in the 
bugtracker entry for this problem.

> Note that the PNG driver can create 8-, 24- or 32-bpp PNG files, plus
> 24-bpp PPM files with an optional PGM mask file.
>
> [1] Or, preferably, r.in.png once I add it to 6.1; I've only just
> realised it was missing.

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

Maciek