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

Markus Neteler neteler at geog.uni-hannover.de
Fri Mar 9 04:29:29 EST 2001


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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list