[GRASS5] GRASS very slow with raster maps > 8000 colors

Hi again,

some of you already know: GRASS is very slow displaying raster
maps > 8000 colors. Just curious (as I don't know too much about this
problem): is there are chance to speed up GRASS' color system?
I don't understand the reason for this slowness.

To give you an idea: a 250x250 pixel color infrared image takes
4sec to display (3.5sec black screen, then rather fast display)
on a 1Ghz Athlon. How do "xv", "gimp" etc. manage this color
troubles? 250x250 pixel are not really much.

Regards

Markus

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

Markus Neteler wrote:

Hi again,

some of you already know: GRASS is very slow displaying raster
maps > 8000 colors. Just curious (as I don't know too much about this
problem): is there are chance to speed up GRASS' color system?
I don't understand the reason for this slowness.

To give you an idea: a 250x250 pixel color infrared image takes
4sec to display (3.5sec black screen, then rather fast display)
on a 1Ghz Athlon. How do "xv", "gimp" etc. manage this color
troubles? 250x250 pixel are not really much.

Regards

Markus

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

Markus,

I have looked into this problem a while back. If it helps I have traced
the slow drawing function from d.rast to a call to R_reset_colors in the
raster library. This routine is called from the display library function
D_set_colors in raster2.c.

Unfortunaltely this was as far as I got in tracking down the speed
problem. The R_reset_colors routine is called from Reset_colrs.c in the
raster library.

Hopefully this information is of some help.
--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

On Thu, Mar 08, 2001 at 08:25:51PM +0000, Markus Neteler wrote:

Hi again,

some of you already know: GRASS is very slow displaying raster
maps > 8000 colors. Just curious (as I don't know too much about this
problem): is there are chance to speed up GRASS' color system?
I don't understand the reason for this slowness.

8000 is a *big* colormap. So each cell's color has to be looked up in
a 8000 element long structure of colors.

To give you an idea: a 250x250 pixel color infrared image takes
4sec to display (3.5sec black screen, then rather fast display)
on a 1Ghz Athlon. How do "xv", "gimp" etc. manage this color
troubles? 250x250 pixel are not really much.

You're comparing pure image formats (all they have is color) and cells
that have some information with an associated color map. In the first,
there's a direct correspondance while the second requires a palette/rule
lookup (rules will be faster than large pallette I think). Things like
GIF/TIFF with palette max out at 256 entries -- otherwise you have to
go to 24bit RGB pixels.

It might be useful to have a pure "image" type in GRASS. Then the cell
value is its color. But maybe that's too cumbersome in practice? It's
be nice to be able to use arbitrary images in GRASS displays for
background (or other) purposes. Classic example I use at work all the
time is scanned DRG images stored on CD-ROMs. It's worth thinking
about...

--
Eric G. Miller <egm2@jps.net>

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

On Thu, Mar 08, 2001 at 06:50:57PM -0800, Eric G. Miller wrote:

On Thu, Mar 08, 2001 at 08:25:51PM +0000, Markus Neteler wrote:
> Hi again,
>
> some of you already know: GRASS is very slow displaying raster
> maps > 8000 colors. Just curious (as I don't know too much about this
> problem): is there are chance to speed up GRASS' color system?
> I don't understand the reason for this slowness.

8000 is a *big* colormap. So each cell's color has to be looked up in
a 8000 element long structure of colors.

Yes, but the original image (CIR aerial photo) has 1.3Mcolors. So
8000 are not too much left. Luckily I can import splitted into
R, G and B channel. But if I run d.rgb or i.composite, the same
problem occurs (of course).

> To give you an idea: a 250x250 pixel color infrared image takes
> 4sec to display (3.5sec black screen, then rather fast display)
> on a 1Ghz Athlon. How do "xv", "gimp" etc. manage this color
> troubles? 250x250 pixel are not really much.

You're comparing pure image formats (all they have is color) and cells
that have some information with an associated color map. In the first,
there's a direct correspondance while the second requires a palette/rule
lookup (rules will be faster than large pallette I think). Things like
GIF/TIFF with palette max out at 256 entries -- otherwise you have to
go to 24bit RGB pixels.

Yes, I have:
tiffinfo geociro281b.TIF
TIFF Directory at offset 0x3718112
  Image Width: 4531 Image Length: 4250
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Samples/Pixel: 3
  Rows/Strip: 100
  Planar Configuration: single image plane

It might be useful to have a pure "image" type in GRASS. Then the cell
value is its color. But maybe that's too cumbersome in practice? It's
be nice to be able to use arbitrary images in GRASS displays for
background (or other) purposes. Classic example I use at work all the
time is scanned DRG images stored on CD-ROMs. It's worth thinking
about...

Probably yes. But the way, ARCView is dealing with images/raster data
I don't like! So we would have to think carfully about the problem...

But generally no chance to speed it up (Bob pointed out the routine
being responsible, unfortunately I can't be much help here...)?

Markus

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