[GRASS5] d.photo

[Glynn Clements]

Radim Blazek wrote:

> I am currently digitizing vectors using many large orthophotos 
> on background. I had been a bit annoyed by speed of d.rgb
> so I wrote d.photo (slightly modified d.rgb) which can display
> orthophoto raster map created from 3 (RGB) raster maps (1 byte/cell) by
> r.mapcalc pok2="043130.r + 043130.g * 256 + 043130.b * 65536"
> (3 bytes/cell in result)
> 
> d.photo is significantly faster than d.rgb:
> 
> time d.rgb r=043130.r g=043130.g b=043130.b
> real    0m6.810s
> user    0m6.000s
> sys     0m0.393s
> 
> time d.photo map=pok2
> real    0m3.199s
> user    0m2.760s
> sys     0m0.211s
> 
> Does it make sense to add d.photo to GRASS?

Probably not; see below.

> As it is so simple
> and d.photo take less than 50% of time of d.rgb I think that 
> I am missing something. Maybe we already have such module?

Some issues to consider:

1. d.rgb uses the maps' colour tables to obtain the intensity values,
rather than assuming a direct translation. This could be expensive,
particularly if the colour tables have 256 individual entries rather
than a single rule.

2. r.composite does the equivalent of the above r.mapcalc command, but
again it uses the colour tables (and it isn't limited to powers of 2).

3. You are presumably creating a very large colour table for the
composite raster (either ~16 million discrete entries, or 65536
rules).

4. d.rast quantises images to at most 32768 colours (5 bits per
component, 15 bits total). d.rgb doesn't do any quantisation; on a
24-bpp display, you should actually get 24-bpp on-screen.

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

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.

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.

Try replacing the G_get_raster_color() calls in D_raster_of_type_RGB()
in src/libes/display/raster_rgb.c with simple CELL -> byte truncation.

The fact that d.rgb is using proportionally more "user" time suggests
that the issue is with the client (i.e. d.rgb or libdisplay), not
XDRIVER or I/O overhead.

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