[GRASS5] d.photo

[Glynn Clements]

Radim Blazek wrote:

> > 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.
> 
> That would be nice.

It's also the most complex option.

Given that the speed difference between d.rgb and d.photo appears to
be almost entirely due to the additional time spent reading three maps
instead of one, it would definitely be worth looking into whether the
reading speed can be improved. If it could, that would benefit
everything.

BTW, the issue definitely isn't the speed of the underlying read()
operations, as that wouldn't be counted as "user" time (which is
definitely the dominant factor).

> Speed of d.rast is critical for interactive use.

Then buy a faster computer ;)

Actually, that's not entirely a joke. There is a legitimate argument
for sacrificing performance in favour of other properties. In this
case, simplicity. You can almost always get performance improvements
by replacing generic functions with multiple specific-case versions,
but doing so creates maintainence problems, and maintenance is GRASS'
biggest problem.

> How RGB CT will look like? Just tells how many bytes are assigned 
> to each chanel? 

The most general option would be to specify a modulus and divisor for
each channel, i.e. not restricted to powers of two. The next most
general would be the number of bits and the ordering (e.g. R8G8B8). 
The least general would be to fix the format as either R8G8B8 or
B8G8R8.

In all cases, the colour "table" would have to begin with a specific
token which identifies the mapping as a direct RGB mapping rather than
a table.

Some new functions would need to be added for use by RGB-aware
programs, and some existing functions would need to be extended to
provide compatibility with non-RGB-aware programs (i.e. generate the
equivalent colour table on the fly).

At a minimum, there would need to be new functions to check whether a
colour table is a direct RGB mapping, and to obtain the parameters
(unless they're fixed).

Also, some key functions (e.g. G__lookup_colors()) would be extended
to use the RGB mapping directly. That should make programs which are
just going to convert to RGB (e.g. r.out.*, ps.map) feasible.

Making R_raster_* feasible would involve extending the monitor
protocol and the drivers to provide an RGB alternative to
R_reset_colors (so that the monitors don't create a 64Mb translation
table). It would probably be easier to extend programs such as d.rast
to use the RGB drawing functions if the raster has a direct RGB
mapping.

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