[Qgis-user] Raster Calculator bug?

[Nick Papadonis]

Folks,

I’m using QGIS 10.1.  The following expressions result in a black raster of 0’s, when I expected only red pixels to appears in the binary image indicating routes on a map:

a) (“m at 1" < 238 AND “m at 1" > 213 AND “m at 2" < 123 AND “m at 2" > 98 AND “m at 3" < 125 AND “m at 3” > 99) * 1
b) ((“m at 1" < 238 AND “m at 1" > 210) * 1) * ((“m at 2" < 123 AND “m at 2" > 94) * 1) * ((“m at 3" < 130 AND “m at 3" > 98) * 1)

I then tried the following individual expressions for each band as separate steps (sanity check) and they work to cover the pixels in range:
c) (“m at 1" < 238 AND “m at 1" > 213) * 1
d) (“m at 2" < 123 AND “m at 2" > 98) * 1
e) (“m at 3" < 125 AND “m at 3” > 99) * 1

I then tried the following expression which appears to create a proper greyscale image focusing on the red pixels.  I replaced the multiplication with addition to see what was happening:
f) ((“m at 1" < 238 AND “m at 1" > 210) * 1) + ((“m at 2" < 123 AND “m at 2" > 94) * 1) + ((“m at 3" < 130 AND “m at 3" > 98) * 1)

The resulting raster has a Min = 0 and Max = 1.998.  I was expecting it to be Min = 0 and Max = 3.  The value of 3 would indicate all 3 bands were positive on color match.  I then go to the layer properties and load calculate min/max again and it is Min = 0 and Max = 3.  I tried to change the min/max settings on they layer and these settings will not stay set.  The layer goes back to Max = 1.998.  What’s even more odd is the max being a floating point number.  I suspect that may be part of the issue.  Anyone know why this is the case for integer band values?  Has anyone successfully used the Raster Calculator to perform this sort of work before?

Thanks again,
Nick