[GRASS5] i.composite problems verified

[Glynn Clements]

Glynn Clements wrote:

> > > > > What kind of operations might be performed upon the resulting layer? 
> > > > > >From what I can tell, GRASS seems to be oriented towards handling
> > > > > either scalar quantities or discrete categories. The cell values
> > > > > resulting from i.composite certainly aren't scalars, and as categories
> > > > > they don't really have much meaning.
> > > > 
> > > > Purpose would mostly be for display and map making.
> > > 
> > > For display, there's already d.rgb; I don't know about paint drivers.
> > 
> > The d.rgb is not in release branch as it's color quality was
> > very poor. The i.composite produces much better results, unfortunately
> > it cannot be used scripted.
> > 
> > If we could have d.rgb back (fixed), it would be fine :-)
> 
> I wasn't thinking about supporting generating composite images (the
> "out=" parameter), just for rendering (using R_RGB_raster()).

I've now implemented an RGB rendering path which doesn't suffer from
the need to create a colour table with N^3 entries. The main points
are:

1. XDRIVER now supports the RGB_RASTER operation natively; if it's
using a TrueColor or DirectColor visual, it uses logical operations to
convert the data (tested on a 5:6:5 display). No Colormaps,
lookup-tables or similar.

2. libdisplay contains some new functions for RGB raster operations:

	D_draw_raster_RGB
	D_draw_d_raster_RGB
	D_draw_f_raster_RGB
	D_draw_c_raster_RGB
	D_draw_cell_RGB
	D_cell_draw_setup_RGB
	D_raster_of_type_RGB
	D_set_colors_RGB

These are all more or less analogous to the corresponding functions
without the _RGB suffix, the main difference being that they take
three sets of raster data instead of one.

These functions all use the RGB_RASTER operation, so there are no
colour tables involved. The CELL/FCELL/DCELL values are converted to
bytes using the appropriate channel[1] from the specified colour table
(typically the one from the layer).

[1] I.e. the red components are used for the red layer, etc. If the
layers have suitable grey-scale colour tables, that'll work.

3. I've added a new d.rgb program which uses these functions. It
*doesn't* support the "out=" parameter for generating a composite
layer; it just takes three separate R/G/B layers and displays them on
the monitor. If anyone plans on resurrecting the "out=" code, please
turn it into a separate program (e.g. "r.rgb").

So, if you import a 24-bit image with "r.in.ppm -b", then display the
resulting layers with "d.rgb" on a 24-bit display, there should be no
loss of data.

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

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'