Dear Step Community,
I’m trying “simple” band math expression for aCDOM(420nm): 5.13*(B3/B4)^(-2.67)
and outcome isn’t pretty, “SNAP ERROR: java exception /by zero”.
The curious part is: If I create a new band (for instance newBi) has newBi=B3/B4 I obtain a result (image) with the following min and max values (0.3507,21.1111):
If I then apply the following exponent to the previous band image (newBi)^ (-2.67) you get the following min and max values (-21,-1)
which is not true because if you apply (0.3507)^(-2.67) you get 16.41 and (21.11)^(-2.67) you get 290.8E-06. Very strange.
If you compute the statistics for B3:
And B4:
The thing is that we should at least get the correct numbers for the (newBi)^(-2.67) and that isn’t happening.
I don’t know if could explain the problem and if it makes in sense to take a look at it.
I would like to compute this expression in band math, but I’m having a really hard time with the divide by zero error java arithmetic exception.
I recall another instance of unexpected results (using BEAM or NASA SeaDAS 7, so years ago). Bandmath was being applied to raw unscaled data rather than the geophysical values (e.g., after scaling had been applied).
I say something is not right with SNAP band math. I processed this two band raster calculation with S2A B3 and B4 in R studio and take a look at the results:
Hi ABraun,
Thank you for the reply. I don’t know if I really understand what you are trying to explain to me.
But let me share this numbers. I think I’m using (in the case of R processing box) the correct values for the images, for instance, for a Sentinel 2 MS image, take a look:
Besides how can we have in SNAP BandMath the following results:
B3/B4 --> (min, max) = (0.3507,21.1111) and then you apply in exponent (0.3507,21.1111)^(-2.67) and you get min and max values -21 and -1? You should get at least, for those values 290.8E-06. and 16.41.
Moreover the BandMath produces a new Band image for the ratio B3/B4, but it doesn’t produce for the same ratio to the exponent (B3/B4)^(-2.67).
Just a ending note:
In fact for the Landsat 8 image the pixel numbers are in DN, here is brief summary:
the min and max values are quite odd (-1.0000 and -21.0000) so they could rather be a processing artefact of invalid pixels (NoData pixels) instead of the actual minimum after the calculation.
Have you checked one specific pixel before and after calculation? This should be more reliable than the overall statistics.
Similar as @gnwiii I was referring to the scaling of some data in SNAP
Now applying the previous band ratio the following exponent (new_band1)^(-2.67)
we get -3 value for the same pixel, when we should get (3.45)^(-2.67) = 39.8E-03:
The question remains:
How can the Band Math produce a new Band image for the ratio B3/B4, but it doesn’t produce for the same ratio to the exponent (B3/B4)^(-2.67).
Because if I try to create the newband image directly (B3/B4)^(-2.67):
you get error message:
Note that the base image bands are in principle ok, for instance B4
It is always dangerous trying to use multiple languages. I finally looked at the documentation for “Band Maths Expression Editor” and discovered that the “hat” operator is “bitwise XOR”. Use pow(X,Y)
it worked !! Thank you a lot 