[GRASS5] Re: d.rgb: different display in gis.m and d.m

Michael Barton michael.barton at asu.edu
Mon May 1 14:01:00 EDT 2006


Thanks very much. This seems to explain the behavior I got too.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Mon, 1 May 2006 18:07:51 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Maciek Sieczka <werchowyna at epf.pl>, <grass5 at grass.itc.it>, Cedric Shock
> <cedricgrass at shockfamily.net>, Hamish <hamish_nospam at yahoo.com>
> Subject: Re: [GRASS5] Re: d.rgb: different display in gis.m and d.m
> 
> 
> Michael Barton wrote:
> 
>> I *THINK* you've hit a bug I reported in d.rgb and d.his about a month back.
>> I'm pretty sure that they treat "0" as NULL. This is probably a holdover
>> from the old 'pre-NULL' days of GRASS. Does your map use "0"s? If so, try
>> changing to another value and see what happens.
>> 
>> I don't know why it's showing up in gis.m and not in d.m, but probably has
>> to do with the x11 vs. PNG/PPM display driver architecture. I'm adding Glynn
>> to the copy list because he may have some insight into what is going on.
> 
> The PNG driver uses the fallback implementation for RGB rasters, which
> converts the R/G/B values to internal colour numbers then uses the
> RASTER_INT operation. This does the wrong thing if the internal colour
> number is zero (and black on an RGB device probably will be zero) and
> overlay mode is being used.
> 
> I'll change it to provide its own RGB raster operation.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list