[GRASSLIST:3631] Re: more r.mapcalc troubles

[Glynn Clements]

Maciek Sieczka wrote:

> Thanks for the support so far! Here is one more strange thing in r.mapcalc I
> encountered during my low-level computing :).
> 
> I'm using Grass 5.03 installed from the binaries from the Grass www.
> 
> I made a following raster for my vignetting correction purposes:
> 
>     r.mapcalc 'kor_lx = ( 1218.01 / ( sqrt(  (double(x()) - 941.0) ^2.0 +
>     (double(y()) - 928.0)^2.0) ^2.0 + 1218.01^2.0) ) ^4.0'
> 
> the value range for 'kor_lx' file is (read from the color file in the 'colr'
> folder):
> 
>     0.00000000000002026206628416476 - 0.000000000000454355718931865126
> 
> I checked if r.mapcalc hadles the 'kor_lx''s values properly by doing:
> 
>     r.mapcalc 'copy=kor_lx'
> 
> the data range in the 'colr' file for 'copy' was DIFFERENT (the min value is
> higher than in 'kor_lx'):
> 
>     0.000000000000028123670807620238 - 0.000000000000454355718931865126

FWIW, I can't reproduce that behaviour.

Having created an X/Y location with the following region:

	GRASS:~ > g.region -p
	projection: 0 (x,y)
	zone:       0
	north:      1824
	south:      0
	west:       0
	east:       1868
	nsres:      1
	ewres:      1
	rows:       1824
	cols:       1868

I ran the above r.mapcalc command, followed by "r.colors kor_lx color=grey",
and obtained the same range as yourself in the colour table:

	% 0.00000000000002026206628416476 0.000000000000454355718931865126
	0.00000000000002026206628416476:0 0.000000000000454355718931865126:255

However, if I run "r.mapcalc 'copy=kor_lx'", the copy has an identical
colour table:

	% 0.00000000000002026206628416476 0.000000000000454355718931865126
	0.00000000000002026206628416476:0 0.000000000000454355718931865126:255

Also, I get the same results with both 5.0.2 and a recent 5.3
snapshot.

BTW, if I do:

	r.mapcalc 'kor256=#kor_lx'
	r.info -r kor256

	GRASS:~ > r.mapcalc 'kor256=#kor_lx'
	 100%
	GRASS:~ > r.info -r kor256
	min=0
	max=255

Presumably, you are using a different colour table; which one?

-- 
Glynn Clements <glynn.clements at virgin.net>