(cc to grass5)
On Wed, Mar 21, 2001 at 12:18:03AM -0800, Eric G. Miller wrote:
On Tue, Mar 20, 2001 at 11:30:57PM -0700, Gerald Buckmaster wrote:
> Eric,
>
> I tried d.mon's nlev option, with no change in depth, visually. Let me explain
> what is happening...this may just be ignorance on my part:
>
> I use d.rgb to display separate files (bands), but they look like @#$%.
I agree... The i.composite produces better results (with color levels =10).
> I use i.colors to basically accomplish the same task (without saving to a new
> file) and the display looks great...just what I would expect from any
> multispectral viewer, however, I get a warning about the histogram not found
> for each of the input files...
Run
r.support -r mapname
on each map. I have added a hint for this warning recently, in the next
version of GRASS 5 the user will be told to run r.support on the particular
file (change was done in src/libes/gis/histogram.c).
> I use i.composite to write out to a file, knowing using a screengrabbing
> utility is not really what I'm looking for...and I get the same histogram
> warning and my prompt doesn't return.
Same story: r.support.
> I examine my processes and sure enough, i.composite is leading the pack in CPU
> usage. Great, this is really working...not. 14 hours later, no change...no
> file.
How much color levels did you specify? Note: GRASS becomes *very* slow
with > 8000 colors. The formula for color *levels* is:
number_of_colors = color_level^3
With color_levels=10 you receive 1000 colors. So, I would be interested,
if you specified 256 color levels 
256^3=16777216 -> slooooow GRASS.
[...]
> >One other thing that will degrade the quality of the visuals some is
> > the way GRASS chooses cell values when the "region" settings don't
> > match the raster. It should do some form of interpolation (nearest
> > neighbor, etc...) but instead just chooses the closest cell for the
> > given
> >resolution. This can make the image a bit "pixelated" looking.
>
> This statement interests me...could i.colors be utilizing code that
> could be reused by d.rgb and others?I just looked at d.rgb last night. For some reason, it hardwires the
colors to 8-bit. Hence, it looks like @#$%! I tried hacking it to
do a 24bit color palette, but I wasn't quite getting the match between
cell values and the color palette right (actually, I was getting it
quite wrong <*g*>). Can't guarantee I'll get it "fixed-up" anytime
soon.
Work has to be done here, the d.rgb and friends are already on the TODO/BUGS
list.
As far as the histogram thing goes, "r.support" will give you an option
to update histogram/stats. I believe i.composite uses the histogram to
match up colors better. I've had the same experience with i.composite.
I don't know what it's doing, but it takes forever to get there!
Yes, without a proper map's histogram the i.composite produces ugly
pictures (therefore the warning).
There's seems to be alot of color management stuff centered around 8-bit
color palettes. It definitely needs to be expunged.
Yes.
As far as the region settings go. Say your region cellsize is twice as
large as the resolution of a raster you wish to display. As far as I'm
aware, the library code just grabs the cell that matches on centers the
best with each cell at the current region settings (make sense??). So,
it doesn't do something like a weighted interpolation of the values,
which for continuous data (imagery, etc..) should lead to a smoother
image.
To avoid confusion: At least with calculations (if you use r.mapcalc and
a non-matching resolution) it is using a cell average. Above is only
the (current) limitation for displaying data. Probably the display
lib needs an update here to be compliant with general raster library.
The region idea works well for matching up cell values for analytical
functions, but I don't know that it's such a good idea for display. I
think display stuff should try to optimize resolution for the target
(window, graphics file, etc...).--
Eric G. Miller <egm2@jps.net>
Regards
Markus Neteler
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
