[GRASS5] d.photo

[Radim Blazek]

On Friday 18 April 2003 01:54 am, Glynn Clements wrote:
> Radim Blazek wrote:
> > r.mapcalc pok2="043130.r + 043130.g * 256 + 043130.b * 65536"
> >
> > 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.

No, all original maps have only 1 rule in color tables.

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

r.composite r_map=043130.r g_map=043130.g b_map=043130.b output=pok1 levels=32
time d.rast map=pok1
real    0m2.066s
user    0m1.760s
sys     0m0.162s

Yes, this is even faster, but output (even if usually acceptable) is not 
of the same quality as that done by d.rgb/d.photo.

r.composite r_map=043130.r g_map=043130.g b_map=043130.b output=pok1 levels=64
time d.rast map=pok1
real    0m2.796s
user    0m2.492s
sys     0m0.156s

r.composite r_map=043130.r g_map=043130.g b_map=043130.b output=pok1 levels=256
time d.rast map=pok1 
-> killed after 8 minutes still on 0% progress

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

And so I think, that we can compare comparable only (in sense of 
output quality), and comparable are d.rgb and d.photo, I think, 
as d.rast can use 15 bits only.

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

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

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

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

I am not quite sure how, this works:
r_buf[i] = (unsigned char) *r_raster;
g_buf[i] = (unsigned char) *g_raster;
b_buf[i] = (unsigned char) *b_raster;

but the time is the same (as we could expect for one rule in color table)
time d.rgb r=043130.r g=043130.g b=043130.b
real    0m6.837s
user    0m5.959s
sys     0m0.420s

Radim