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

[Maciek Sieczka]

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

> 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?

That's what I wanted to sort out as well - whether we need the CELL driver
in 6.

>> > 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.

Thanks for explaining that. Like I said I never used the CELL driver as it
was never present in 5.7-6.1. I hoped it would store the image neatly
georeferenced.

>> 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.

Yuck!

> 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.

Right.

> 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.

I see. Actually, v.digit is upgraded accordingly already, since one can
use -bgcmd=d.rgb. Neat if nviz could do as well...

>> 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.

Ok. I didn't know all the drawbacks of CELL driver (only 8 bit, no
georeferencing, disgusting). Just didn't expect them. My fault, should have
read the 5.4 manual.

>> 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.

Fine, I'd like to close my report and a similar reported soon after
http://intevation.de/rt/webrt?serial_num=3076&display=History. Anybody
negative?

Should the reminments of CELL driver code in 6.1 code be removed? That would
assure that reports like "d.mon CELL doesn't work" would never happen again.

Thanks
Maciek