IR17;ve just discovered that when the –n flag is set in d.his, it seems to treat 0’s as NULL, regardless of whether or not they have been defined as NULL (i.e., using r.nulls). I’m guessing that this is a holdover from much earlier versions of GRASS that lacked NULL support. If this is the case, it should probably be changed so that d.his actually respects true NULL values and treats 0’s as real values.
This does not appear to be the case for d.rgb and the –o flag. It appears to respect true NULL values, not 0’s.
Michael
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
I¹ve just discovered that when the n flag is set in d.his, it seems to
treat 0¹s as NULL, regardless of whether or not they have been defined as
NULL (i.e., using r.nulls). I¹m guessing that this is a holdover from much
earlier versions of GRASS that lacked NULL support. If this is the case, it
should probably be changed so that d.his actually respects true NULL values
and treats 0¹s as real values.
If it does, that's a bug, not an oversight. Both d.his and the D_*
functions it uses go to some lengths to handle null values correctly.
Can you provide a recipe to reproduce this?
Note that:
1. d.his doesn't care about the actual cell values for non-null cells,
only their associated colours (for the intensity and saturation maps,
only the red level is used; it's assumed that these maps will have
grey-scale colour tables).
2. A cell should be transparent if that cell is null in any of the
input maps.
--
Glynn Clements <glynn@gclements.plus.com>
I discovered this when I tried to drape an orthophotoquad over a DEM for a
class presentation. There were a series of clear areas. When I displayed it
with d.rast, they were black. I queried them and they had values of 0, not
NULL.
I ran r.nulls anyway, just to be sure, reassigning any NULLs back to 0 for
the orthophoto, making sure that it created a NULL bitmap. D.his still shows
areas with a value of 0 as clear, while d.rast does not.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 19 Mar 2006 20:50:42 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: grass developers list <grass5@grass.itc.it>
Subject: Re: [GRASS5] Bug? In d.his
Michael Barton wrote:
I¹ve just discovered that when the n flag is set in d.his, it seems to
treat 0¹s as NULL, regardless of whether or not they have been defined as
NULL (i.e., using r.nulls). I¹m guessing that this is a holdover from much
earlier versions of GRASS that lacked NULL support. If this is the case, it
should probably be changed so that d.his actually respects true NULL values
and treats 0¹s as real values.
If it does, that's a bug, not an oversight. Both d.his and the D_*
functions it uses go to some lengths to handle null values correctly.
Can you provide a recipe to reproduce this?
Note that:
1. d.his doesn't care about the actual cell values for non-null cells,
only their associated colours (for the intensity and saturation maps,
only the red level is used; it's assumed that these maps will have
grey-scale colour tables).
2. A cell should be transparent if that cell is null in any of the
input maps.
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
I discovered this when I tried to drape an orthophotoquad over a DEM for a
class presentation. There were a series of clear areas. When I displayed it
with d.rast, they were black. I queried them and they had values of 0, not
NULL.
I ran r.nulls anyway, just to be sure, reassigning any NULLs back to 0 for
the orthophoto, making sure that it created a NULL bitmap. D.his still shows
areas with a value of 0 as clear, while d.rast does not.
Can you provide a recipe to reproduce this?
--
Glynn Clements <glynn@gclements.plus.com>
Glynn,
I'm not sure I understand. D.his is simply reading 0's on greyscale (0-255)
images as NULLs on my machine. I can check to see if that's the case for
another machine.
Maybe this is what you need:
Put a shaded relief map in the Hue channel
Put a greyscale drape map (with some 0 values in it) in the Intensity
channel
Display
There will be clear/white areas where there are 0's in the greyscale drape
map.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Glynn Clements <glynn@gclements.plus.com>
Date: Mon, 20 Mar 2006 13:18:54 +0000
To: Michael Barton <michael.barton@asu.edu>
Cc: grass developers list <grass5@grass.itc.it>
Subject: Re: [GRASS5] Bug? In d.his
Michael Barton wrote:
I discovered this when I tried to drape an orthophotoquad over a DEM for a
class presentation. There were a series of clear areas. When I displayed it
with d.rast, they were black. I queried them and they had values of 0, not
NULL.
I ran r.nulls anyway, just to be sure, reassigning any NULLs back to 0 for
the orthophoto, making sure that it created a NULL bitmap. D.his still shows
areas with a value of 0 as clear, while d.rast does not.
Can you provide a recipe to reproduce this?
--
Glynn Clements <glynn@gclements.plus.com>
Michael Barton wrote:
I'm not sure I understand. D.his is simply reading 0's on greyscale (0-255)
images as NULLs on my machine. I can check to see if that's the case for
another machine.
Maybe this is what you need:
Put a shaded relief map in the Hue channel
Put a greyscale drape map (with some 0 values in it) in the Intensity
channel
Display
There will be clear/white areas where there are 0's in the greyscale drape
map.
Not for me.
Can you try to reproduce this in a small test location, and send me
the entire location directory?
--
Glynn Clements <glynn@gclements.plus.com>