[Qgis-user] Raster Calculator bug?

[Stefan Kiefer]

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 <npapadonis at gmail.com> 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 <st_kiefer at web.de> 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 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) * ((“m at 1" < 238 AND “m at 1" > 210) * "m at 1") + ((“m at 2" < 123
> > AND “m at 2" > 94) * “m at 2") + ((“m at 3" < 130 AND “m at 3" > 98) *“m at 3"))
> >
> > cheers
> >
> > Stefan
> >
> > > Nick Papadonis <npapadonis at gmail.com> 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 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 change the expression to only use values 2 and greater and this
> > > shows properly:
> > > 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) > 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 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) > 2.1
> > > ((“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) >= 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 <npapadonis at gmail.com>
> > > > 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 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
> > >
> > > _______________________________________________
> > > Qgis-user mailing list
> > > Qgis-user at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/qgis-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20150731/6b4924b3/attachment.html>