1

How do I manage floating point calculations in QGIS?

I have carried out 3 consecutive calculations on landsat bands. I end up with 32 bit floating point rasters on which I can't carry out a 4th calculation. The calculation result gives a substantial file but the values of the pixels are shown as "Inf".

I am not able to find a syntax guide for the float() function although I use it successfully in 1 of the preceeding calculations. And I do not have an in-depth understanding of how to manage integer/floating point or how to convert between them in QGIS.

I found these but no big clues

How to reclassify a float raster? Floating point: understanding their inaccuracy

  • 1
    Please share the details of these calculations with us so that we can understand your problem. See our help center for more guidance on asking good questions. – whuber Feb 25 '14 at 22:44
  • I am after a timeless answer, not a comment which leads to "move that bracket one position to the left". Nevertheless, the format of a successful calculation ((b5-b4)/float(b5+b4)) – BillyWill Feb 25 '14 at 22:48
  • What do unsuccessful calculation attempts look like? (I am sympathetic with your opinion of the "move that bracket" type of answer. But before you can get "timeless" answers first you need to ask an answerable question and that means providing sufficient information to pinpoint what might be going on. Otherwise all you will get are generic answers from people who have to guess what you are doing.) – whuber Feb 25 '14 at 23:19
  • Thanks @whuber. I am on another computer now, but for the 4th calculation (float((img1-img2)/img2)) springs to mind. I have tried a lot of combinations of where the float is located, plus iterations like (float(img1-img2)/float(img2*1.0)) – BillyWill Feb 26 '14 at 0:18
  • 1
    I agree that repositioning float in these expressions is unlikely to cure the problem. It seems more likely that you might have a divide-by-zero issue, since all the expressions you offer are divisions and image bands typically do have zero values. Thus you should expect there to be problematic results (such as Inf) anywhere one or more of the denominators is zero (regardless of whether you use integral or floating point arithmetic). You can check this by forming the local minimum of all the bands to see whether it is everywhere zero. – whuber Feb 26 '14 at 14:20
1

So I used Int in the calculation instead of Float and had success. The input rasters were 32 floating and the output raster is also 32 floating, so I can't immediately see what effect Int has had. The resulting raster was 0.2 GB, about the same as each of the input rasters.

Int((img1-img2)/img2)

I hate to admit that a google result for Float in an acrgis troubleshooting thread gave me a clue.....

I also became aware that RASTER|CONVERSION|TRANSLATE, where I ignored most of the dialog options and put in some hand rolled commands (-ot as per http://www.gdal.org/gdal_translate.html), could have provided a pathway to convert the data type, but not sure what my objective would be with that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.