Hi Stefan, It’s my understanding black has a value of 0 in the resulting layer.
I tried this and it results in similar image to step (a) and also includes other colors at lower intensities mixed in with the red. The red has the highest intensity in the greyscale. I’m looking to create a binary image with just the colors of red in the palette I choose and using this trace vectors over the paths. Thanks, Nick > On Jul 31, 2015, at 2:04 AM, Stefan Kiefer <[email protected]> wrote: > > Hi Nick, > I believe it is black bcause you always get a value of "1". Unfortunately I > can not verify this, because I have no QGis by this moment. Most propably you > wanted to calculate: > > (“m@1" < 238 AND “m@1" > 213 AND “m@2" < 123 AND “m@2" > 98 AND “m@3" < 125 > AND “m@3” > 99) * ((“m@1" < 238 AND “m@1" > 210) * "m@1") + ((“m@2" < 123 AND > “m@2" > 94) * “m@2") + ((“m@3" < 130 AND “m@3" > 98) *“m@3")) > > cheers > > Stefan > > > Nick Papadonis <[email protected]> hat am 31. Juli 2015 um 07:49 > > geschrieben: > > > > > > One more comment. The resulting layer histogram is showing the pixel range > > spread over frequency in floating point values. Is the raster calculator > > performing floating point math with potential rounding error? > > > > I found it also interesting that the following expression resulted in a > > layer, which when inspected for band values, has integer values of 2 and 3. > > 3 being the value I want for the red route. > > > > a) ((“m@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2" > 94) * 1) > > + ((“m@3" < 130 AND “m@3" > 98) * 1) > > > > I then change the expression to only use values 2 and greater and this > > shows properly: > > b) ((“m@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2" > 94) * 1) > > + ((“m@3" < 130 AND “m@3" > 98) * 1) > 2 > > > > I then changed the expression to ensure all three values are obtained and > > it results in a black image of 0’s. I was expecting only the red route to > > appear as it resulted in value of 3 in step (a). > > > > ((“m@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2" > 94) * 1) + > > ((“m@3" < 130 AND “m@3" > 98) * 1) > 2.1 > > ((“m@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2" > 94) * 1) + > > ((“m@3" < 130 AND “m@3" > 98) * 1) >= 3 > > > > I’m wondering how much testing the Raster Calculator has gone through and > > if there is a possible bug here. Perhaps something to do with floating > > point? > > > > Thanks again > > > > > On Jul 31, 2015, at 12:39 AM, Nick Papadonis <[email protected]> wrote: > > > > > > 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@1" < 238 AND “m@1" > 213 AND “m@2" < 123 AND “m@2" > 98 AND “m@3" > > > < 125 AND “m@3” > 99) * 1 > > > b) ((“m@1" < 238 AND “m@1" > 210) * 1) * ((“m@2" < 123 AND “m@2" > 94) * > > > 1) * ((“m@3" < 130 AND “m@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@1" < 238 AND “m@1" > 213) * 1 > > > d) (“m@2" < 123 AND “m@2" > 98) * 1 > > > e) (“m@3" < 125 AND “m@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@1" < 238 AND “m@1" > 210) * 1) + ((“m@2" < 123 AND “m@2" > 94) * > > > 1) + ((“m@3" < 130 AND “m@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 > > > > _______________________________________________ > > Qgis-user mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
