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

GRASS GIS GRASS GIS developer
,
1

Still present in 6.1.

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?

Maciek

-------------------------------------------- Managed by Request Tracker

2

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; it's
unlikely to be georeferenced correctly).

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.

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

3

From: "Glynn Clements" <glynn@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

4

On Sun, 24 Jul 2005, Maciek Sieczka wrote:

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.

The only thing I can think that would be useful for was before there were direct monitor output methods like the PNG driver, you could write the monitor to a GRASS raster layer and then use r.out.tiff or whatever to get it into an output file.

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

But I can't think of a reason why you would want a monitor image as a GRASS raster; rather I would put it that it is the CELL driver that requires two images to get to an output graphics file.

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

LIkewise for the CELL driver directly; the output image is not georeferenced as Glynn said.

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

Make the image dump in 8-bit colour 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.

It makes it easy to convert a monitor image into a GRASS raster, but what use is it once you've got it there? I feel it is an historical anachronism.

[...]

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

I suppose it is simpler and doesn't rely in having GDAL working properly; Glynn may be able to describe technical advantages it has over GDAL specifically for the PNG format?

Just thought I'd join in, because I actually used the CELL driver for something years ago and so understand how useless it is :slight_smile:

Paul

5

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@gclements.plus.com>

6

From: "Glynn Clements" <glynn@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

7

On Wed, Jul 27, 2005 at 09:46:01PM +0200, Maciek Sieczka wrote:

From: "Glynn Clements" <glynn@gclements.plus.com>
>Maciek Sieczka wrote:

...

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

Hi Maciek,

you could write a simple script [1]:

- if no frames are visible in the monitor, generate also a
  PNG world file.
- export with PNG driver
- reimport with r.in.gdal (which recognizes the PNG world file)

Not very fancy, but definitly better than the old CELL driver.

Markus

[1] Learning a bit of script programming takes a few hours
    since you can start from existing scripts

8

next two saturdays I won't be propably able to continue cleanup in the bugtracker

will continue ASAP after

sorry

Maciek

9

On Sun, 24 Jul 2005 20:54:13 +0100 (BST)
Paul Kelly <paul-grass@stjohnspoint.co.uk> wrote:

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

The only thing I can think that would be useful for was before there
were direct monitor output methods like the PNG driver, you could
write the monitor to a GRASS raster layer and then use r.out.tiff or
whatever to get it into an output file.

..

But I can't think of a reason why you would want a monitor image as a
GRASS raster; rather I would put it that it is the CELL driver that
requires two images to get to an output graphics file.

..

It makes it easy to convert a monitor image into a GRASS raster, but
what use is it once you've got it there? I feel it is an historical
anachronism.

for the record, an example and work around for this situation.

ps.map will only take one raster for an input image. recently I wanted
to create a hard copy which overlayed one raster image over another
(land+sea satellite images butted up against each other using NULLs).
Each raster had its own unreconcilable color table so I couldn't use
r.patch, and using both the 'rgb' and 'raster' ps.map commands still
would only let me show one raster.

The solution was to set GRASS_WIDTH and GRASS_HEIGHT to the rows &
columns given by g.region, use the PNG driver to dump to a 24-bit image,
reload that rather large image with r.in.gdal, reset the imported maps'
bounds with r.region (trivial as it matched the originial region), then
use d.rgb and ps.map's "rgb" command to display the whole thing. Having
a CELL driver might have made it slightly easier, but more obscure to
use and not useful enough to justify maintaining the code IMO.

Hamish

10

Hamish wrote:

> But I can't think of a reason why you would want a monitor image as a
> GRASS raster; rather I would put it that it is the CELL driver that
> requires two images to get to an output graphics file.
..
> It makes it easy to convert a monitor image into a GRASS raster, but
> what use is it once you've got it there? I feel it is an historical
> anachronism.

for the record, an example and work around for this situation.

ps.map will only take one raster for an input image. recently I wanted
to create a hard copy which overlayed one raster image over another
(land+sea satellite images butted up against each other using NULLs).
Each raster had its own unreconcilable color table so I couldn't use
r.patch, and using both the 'rgb' and 'raster' ps.map commands still
would only let me show one raster.

Yep; "masked" images are a relatively new feature, only available in
PostScript level 3.

The solution was to set GRASS_WIDTH and GRASS_HEIGHT to the rows &
columns given by g.region, use the PNG driver to dump to a 24-bit image,
reload that rather large image with r.in.gdal, reset the imported maps'
bounds with r.region (trivial as it matched the originial region), then
use d.rgb and ps.map's "rgb" command to display the whole thing. Having
a CELL driver might have made it slightly easier, but more obscure to
use and not useful enough to justify maintaining the code IMO.

I would have thought it easier to do:

  r.mapcalc <<EOF
    out.r = if(isnull(top),r#bottom,r#top)
    out.g = if(isnull(top),g#bottom,g#top)
    out.b = if(isnull(top),b#bottom,b#top)
  EOF

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

11

> The solution was to set GRASS_WIDTH and GRASS_HEIGHT to the rows &
> columns given by g.region, use the PNG driver to dump to a 24-bit
> image, reload that rather large image with r.in.gdal, reset the
> imported maps' bounds with r.region (trivial as it matched the
> originial region), then use d.rgb and ps.map's "rgb" command to
> display the whole thing. Having a CELL driver might have made it
> slightly easier, but more obscure to use and not useful enough to
> justify maintaining the code IMO.

I would have thought it easier to do:

  r.mapcalc <<EOF
    out.r = if(isnull(top),r#bottom,r#top)
    out.g = if(isnull(top),g#bottom,g#top)
    out.b = if(isnull(top),b#bottom,b#top)
  EOF

Indeed, much less circuitous. Multiband though so would need to run
r.composite first or:

r.mapcalc <<EOF
   out.r = if(isnull(land_mask), r#sea.r, r#land.r)
   out.g = if(isnull(land_mask), g#sea.g, g#land.g)
   out.b = if(isnull(land_mask), b#sea.b, b#land.b)
EOF

thanks for the tip,
Hamish