Hoping someone can short circuit a lot of exploration

Landsat 8 values are stored as unint16 since the sensors work on a range 0 to 4096 whereas the L7+TM was 8 bit and had a digital number range 0 to 255. USGS link

Looking at the unprocessed bands in QGIS, the value tool reports values of ~8000 for band 3, whereas GRASS reports values of ~0.19 . For the same bands in L7+TM band 3 values are ~30

Understandably, the output from my old workflow in GRASS is giving nonsense. i.landsat.toar does read L8 but with the funny numbers I don't expect it is on the right track.

The end use is NDVI, I don't expect a pansharpening workflow to be the same.

Any tips on a new workflow?

  • I guess this question touches on the same issues, but to reclass would be experimenting, hoping someone has some detailed knowledge gis.stackexchange.com/questions/39174/… – Willy Aug 19 '13 at 13:17
  • It's clear that TOAR reads the dn as less than 1, the following from the verbose output of the module BAND 1 (code 1) calibrated digital number (DN): 0.0 to 0.0 calibration constants (L): -0.000 to 0.000 at-surface radiance = 0.00000000 * DN + -0.000 mean solar exoatmospheric irradiance (ESUN): -0.000 at-surface reflectance = radiance / 0.00000 the darkness DN with a least 1000 pixels is 1 the DN mode is 0 – Willy Aug 19 '13 at 13:31

The i.landsat.toar version included in Grass7 supports the new Landsat8 OLI/TIRS sensor and worked flawless in my tries. One thing you have to be careful is that Landsat 8 has different band designations. So band 3 on Landsat 7 is equivalent to band 4 on Landsat 8.

| improve this answer | |

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.