2

I downloaded some Landsat 8 OLI/TIRS C1 Level-1 images from EarthExplorer. I was hoping to get reflectance data out of the blue, green and red band; however, when I opened those images in ArcMap, the scale does not seem to be reflectance, given that is not in the range between 0 - 1 (theoretical values of reflectance).

The values that I am getting are 0 - 40079 (blue band) and 0 - 40336 (red band). My question is, is there some type of corrections that I need to do? maybe some transformation?

  • 3
    Read the Landsat users manual, it clearly states that level-1 reflectance values are scaled to 16-bit, which is consistent with what your observed data range. If you want a 0-1 just rescale the data. – Jeffrey Evans Mar 26 at 16:09
0

This information is a bit buried but, if you read the USGS Landsat Surface Reflectance-derived Spectral Indices product guide and the associate processing software guide, you can ascertain that reflectance values are scaled to 16-bit, which is consistent with your observed data range. This processing and rescaling occurs in the LEDAPS (TM4,TM5,ETM+7) or L8SR (OLI) software so, you can track down the USGS documentation for technical details. If you want a 0-1 data range just rescale the data accordingly. One confusing factor is that floating point reflectance values do not always bound 0-1 and when rescaled to 16-bit, in the processing workflow, can end up having large negative numbers. I just bound the lower data range to 0 before rescaling as it is functionally the same as doing this on floating point data.

As @Mouad Alami pointed out, if you did not request reflectance as part of the data archive and are working with the DN values, it is necessary to apply a simple workflow to convert the data to reflectance. It should be noted that the equations are sensor specific.

If you want to operate on the DN values directly, here is an R example of DN to reflectance for OLI data that gives the general code syntax.

oli.reflectance <- function(x, sun.elev = NULL, multiplicative.rescaling = 0.00002, 
                            additive.rescaling = -0.100000) {
    if(!class(x) %in% c("RasterLayer", "RasterStack")) 
      stop( "x must be raster class object" ) 
    if(is.null(sun.elev)) 
      stop("Must provide sun elevation angle value from SUN_ELEVATION in metadata")                                                     
       refl <- function(x, m, a, se) {   
           y <- (x * m + a) / sin(as.numeric(se) * pi /180)
        return(y)
       }
  return( refl( x, multiplicative.rescaling, additive.rescaling, sun.elev) )   
}

Model parameters (arguments)

  • m (additive.rescaling) - Additive rescaling factor (REFLECTANCE_MULT_BAND_x)

  • a (multiplicative.rescaling) - Quantized calibrated standard product pixel values (REFLECTANCE_ADD_BAND_x)

  • se (sun.elev) - sun elevation angle (SUN_ELEVATION)

The terms "at-sensor" (4,5,7) and "surface" (8) reflectance are synonymous but are used in the context of the specific sensor as the atmospheric correction algorithms are quite different. The tier 2 products are have terrain and radiometric calibration (cross-sensor and temporal) applied making the bands and indices comparable across scenes. However, this type of temporal comparison should always be carried out on the reflectance data.

1

The values you are getting are NOT real reflectance values like the other comment said. They are actually DN (digital number) values.

You need to go from DN to radiance and then to TOA (Top Of Atmosphere) reflectance. This link shows the necessary steps you need to go through in order to get reflectance values.

  • If you are working with the level 1 reflectance product it is, in fact, the reflectance values, just scaled to 16 bit. It is a bit confusing but, please make sure that advice that directly contradicts somebody is actually correct. And to compound this issue, the data is not always bounded to 0 so, you can have very large negative numbers resulting from the 16-bit scaling process. A colleague of mine at USGS-EROS has confirmed this. – Jeffrey Evans Mar 27 at 17:01
  • @JeffreyEvans Check the Standard Processing Parameters section. It is not a simple rescale, but rather a series of conversions using the formulas provided by the USGS. – Mouad Alami Mar 27 at 17:17
  • You are referring to converting the standard DN values to reflectance. In earth explorer, you can explicitly request the reflectance product and receive reflectance bands, as well as TOA, in addition to DN. These are scaled to 16 bit just like the DN bands. In the case of DN only data, you indeed must use the solar angle band with the standard coefficients to convert to reflectance but, not if you requested the reflectance data in the archive. I have regularly worked with NASA and USGS for 27 years so, please do not be dogmatic and perhaps admit that somebody may know something that you do not – Jeffrey Evans Mar 27 at 17:31
  • @JeffreyEvans I am a total newbie in the fields of remote sensing and GIS. Your years of experience alone exceed how long I've been alive.You are however making a mistake, because the data is in level 1 which means that is it in DN. You sir are talking about level 2 data. – Mouad Alami Mar 27 at 17:41
  • Documentation is very confusing and the USGS keeps contradicting itself on what constitutes a processing level and tier. In the indices handbook this would be level 1, tier 2. Honestly, we are both correct but thank you for pointing this discrepancy out because it should likely be referred to as level 2, or even 3. The TIRS collections are really confusing matters in regard to historic terminology. Historically, level 1 was minimally processed, 2 was geometrically corrected and 3 terrain and radiometrically corrected. Ideally now we want L1TP (level 1, tier 1). – Jeffrey Evans Mar 27 at 18:01

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.