[GRASS5] d.photo

[Glynn Clements]

Radim Blazek wrote:

> > If this type of raster is worth treating as a special case (and it
> > quite possibly is), d.rgb (and possibly r.composite) should have a
> > flag to ignore the colour tables (assuming that's where the
> > performance hit actually lies).
> 
> As I mentioned above, input maps have only 1 rule in color tables.
> d.photo is also using D_draw_raster_RGB() with color tables
> containing 1 rule. So it seems that here is not the problem.

OK; because you were creating a composite map, I had assumed that you
were using the paletted raster functions. So, ignore most of what I
said earlier.

Given that you aren't, what's the point in creating the composite map
rather than just reading the three separate maps directly?

> > Basically, it doesn't make sense (to me) to display an RGB image by
> > generating a composite layer and a colour table, which are passed to
> > the display driver only to be converted back to RGB.
> 
> D_draw_raster_RGB() doesn't do that, right?

Right.

> > If you try comparing like-for-like, and find that a composite raster
> > seems to be *inherently* faster than using the RGB raster functions,
> > something's wrong with the RGB raster functions.
> 
> As both d.rgb and d.photo are using D_draw_raster_RGB(), the difference 
> seems to be between reading 1 (3 bytes/cell) and 3 (1 byte/cell) rasters. 

Except that the r.mapcalc command is having to read 3 rasters. Is the
time taken by the r.mapcalc command included in the overall times?

Or were you effectively just pointing out that, if you only time part
of the process, you get a lower number?

Bear in mind that the composite map isn't much use for anything, other
than displaying it, and then only with d.photo. Displaying it with
d.rast would require it to have a valid colour table (65536 rules). 
Ditto for use as a colour layer in NVIZ.

AFAICT, the problems which d.photo gets around (for one very specific
application are):

1. The underlying libgis functionality for reading raster maps is
slow.

2. GRASS' colour handling sucks (both the colour table handling in
libgis and the display issues in libraster/libdisplay and the
drivers).

Solving the underlying problems would be worthwhile (but not trivial);
creating special-case work-arounds isn't, IMHO.

Note that solving either of the two problems listed above would be
sufficient in this particular case.

Solving point 1 would reduce the performance gap between d.rgb and
d.photo (both use the same drawing functions, but differ in how they
obtain the data). It would also improve most of the raster modules.

Solving point 2 (e.g. by supporting RGB colour tables directly in
libgis, libraster, libdisplay and the drivers) would make it practical
to use r.composite and d.rast with 256 levels.

AFAICT, d.photo is an attempt to solve point 2 for a single specific
case, limiting the RGB support into a single program.

Maps which work with d.photo either won't work with d.rast, ps.map,
r.out.{png,ppm,tga,tiff}, NVIZ etc, or (if you provide a suitable
colour table, which d.photo will ignore) will be impractically slow.

With three separate R/G/B maps, the individual channels are themselves
valid raster maps, and suitable commands exist for processing the
group as a whole. The composite maps generated by r.composite are also
valid maps; you just have to trade quality for performance.

-- 
Glynn Clements <glynn.clements at virgin.net>