Stefan,

I’m operating over a single layer and 3 bands on that layer.

Nick

> On Jul 31, 2015, at 2:48 AM, Stefan Kiefer <[email protected]> wrote:
> 
> Hi Nick,
> you are absolutely right. My thought was, that you get A layer with distinct 
> values to identify the road. For a mask you are on the right way, and I 
> either don't understand the behaviour except that you operate over three 
> layers, which of course should work.
> Have you tryed to generate a composit of the three layers and mask the single 
> values resulting for road structures? (it's more or less what I expected from 
> my first approach.)
>  
> cheers
>  
> Stefan
> 
> > Nick Papadonis <[email protected]> hat am 31. Juli 2015 um 08:31 
> > geschrieben:
> > 
> > 
> > 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

_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user

Reply via email to