Apparent Reflectance Raster Function

apparent reflectanceThe Apparent Reflectance raster function calibrates image brightness values (DN) for some satellite sensors. The main advantage of apparent reflectance function is to adjust the images to a theoretically common illumination condition, so there should be less variation between scenes from different dates and from different sensors. This can be useful for image classification, color balancing, and mosaicking.

The function performs two calibrations. The first calibration is to convert the DN value to the top of atmosphere (TOA) radiance based on the sensor properties (i.e. gain/bias or LMAX/LMIN). The second calibration is to convert the TOA radiance to apparent reflectance, based on sun elevation and acquisition date. The formulas used in the two conversions can be found in section 11.3.1 and 11.3.2 of the Landsat 7 Science Data User Handbook.

Apparent reflectance is a ratio and its native output range is 0-1. For display purposes, in this function, the ratio is multiplied by 255, and the output is therefore stretched from 0-1 to 0-255. When using default 8-bit unsigned integer output data type, the value is rounded down to integers.

Some scientific research (e.g. serving as input of atmospheric model to achieve surface reflectance) requires the original ratio. This can be achieved by 1) selecting apparent reflectance raster function output type to be 32 Bit float, and 2) adding an arithmetic raster function immediately after this function to divide the value by 255.

Before Apparent Reflectance

Before Apparent Reflectance

After Apparent Reflectance

After Apparent Reflectance

This function can only be used with specific imagery and may be automatically applied when adding data to a mosaic dataset using the appropriate raster type. The applicable sensors are Landsat, IKONOS, and QuickBird. If this function is applied to a dataset that is invalid it will slow the function chain but make no adjustments.

This function modifies the image values, so previous statistics and histograms are no longer valid. This function should be applied early in the function chain, after band extraction (reordering) and prior to any stretching or other radiometric function.

Written by: Hua Wei

This entry was posted in Imagery and tagged , , . Bookmark the permalink.

Leave a Reply


  1. uriel80 says:

    Thank you ??, ^_^

    • alex_sivitskis says:

      Thanks for the great article and help thus far! I was hoping that I could get some advice with Worldview 2 imagery. I’ve succesfully run the apparent reflectance raster function, and my images appear to have changed relatively similar to the ones in the post. However, the modified raster values which I am reading appear to be only changed slighly, and are well out of the 0-255 value range.

      I am attempting to complete the final step of converting to the reflectance ratio, however as my initial corrected values seem to be incorrect, the final arithmetic function is not producing to appropriate values. Any advice you could offer would be much appreciated!

      • Simon Woo says:

        Here are 3 things my colleagues thought were important pieces of information that you should know about:

        1. There is a checkbox called albedo, which provides the actual ratio, so user does not need to compute it from math function, it is provided out of box. When ‘Albedo’ is checked on, the output pixel type is always 32 bit float irrespective of the pixel type that is selected on the ‘General’ property page.

        2. If the input data source is 8 bit, the output is also 8 bit, computed as albedox255 (the albedo checkbox is NOT on in this case).

        3. If the input data is more than 8 bit, as 11 in WV2, the output is 16 bit, computed as albedox50000+5000, no clipping. (the albedo checkbox is NOT on in this case).

        If you have any more specific questions or want anything else clarified, please let us know.

        • alex_sivitskis says:

          That makes perfect sense, thank you so much! Just realized my problem was that I was working with a version of 10.1 without the albedo checkbox, that feature fixed it up perfectly, thank you again.

          Another question I would like to ask is do you know if EO1 hyperion imagery would be supported in this function anytime soon? Or would you have any other suggestions in converting Hyperion DN’s to apparent reflectance?

          • Simon Woo says:

            There is no current plan to support EO1 Hyperion imagery within this function. Unfortunately we do not have an expert for this type of sensory yet, so we do not have any suggestions for the conversion. If we find any insight on this soon, we will post if here.

        • lwsbg_at says:

          Hi Simon,
          I am sorry to bother you again. The above information is really important and should be in the help. I find it strange that the albedo output is coded in such a non-standard way. A simpler to read way would be albedo*10000. What is even stranger is that the output logic depends on the data format of the input. That makes two images incomparable if one is 8bit and the other is 11 bit, although achieving comparability is the whole point of doing this conversion.
          I also have a question: I would like to obtain a pansharpened image, which is calibrated to albedo. To this end, I used the standard function chain for the Worldview image and inserted apparent reflectance functions on top of the geometric functions for the multispectral and panchromatic images, respectively. This works fine if the Albedo-checkbox is unchecked, but when I check it (in both apparent reflectance functions), the output is NoData, regardless of the output format I set. Does the pansharpening function not support input data in float format? If so, this should be documented.
          In this case, the workaround to get albedo correctly scaled to 0 to 1 would be to leave the albedo-box unchecked, and to undo the strange number format with two arithmetic functions: “-5000″ and *1/50000 after pansharpening, right?
          Thanks a lot! L.

  2. cheetospuffs4 says:

    Hello, I am trying to use this function but I have no idea where to find this function and how to enter the pre-requisite meta data information? It is not included in any of the documentation. Please help!


    • Simon Woo says:

      The function can be added to a mosaic dataset item or a function rater, via the Function Editor Window. The metadata from several sensors will automatically populate the gains\bias and sun elevation. The sensors that currently read the metadata automatically are: Landsat(MSS & TM), Quickbird and Ikonos. In future releases we will try to support more sensors where we can read the metadata automatically.

  3. dcazar says:

    I am attempting to atmospherically correct a Quickbird image downloaded in NITF format. I would like to use the apparent reflectance function. The .imd information is buried inside an xml document that download with the ntf file, however the nft file has some header information store that ArcGIS is able to read.

    ArcGIS is able to calculate the Sun Elevation, which shows up automatically. I assume the Earth-Sun distance is also being used by the function behind the scenes. The problem is that gain and bias values are not in the imd file, even though the help says that they are. The imd file only provides an absolute calibration factor. Converting to radiance is easy enough but I need to process this quickly and don’t have time to repeat the programming steps of the Julian day to get accurate solar geometry.

    Can you please provide guidance on the relationship of the calibration factor to the gain and offset entries?

    • Simon Woo says:

      Here is a response from one of the developers that worked on the apparent reflectance function:

      The information in this post comes from the DigitalGlobe document “Radiometric Use of QuickBird Imagery”, Technical Note, prepared by Keith Krause, released 11/7/2005. This is the definitive document on the subject and the one we used during development.

      The function does two things: convert DN to radiance based on gain and bias, then convert radiance to reflectance using sun illumination.

      As noted, QuickBird metadata does not store gain and bias, but rather an absolute calibration factor for each band, referred to as “Kband” in the document. It is related to the gain by the effective band width for that band. Bias (or Offset) is applied during product generation is ignored for apparent reflectance.

      On page 8 of that document, the following equation is given (with terms rearranged):

      Radiance = DN * (Kband / bandwidth)

      Where DN is the image value
      Kband is the absolute calibration factor
      And bandwidth is the effective bandwidth in microns.

      The term (kBand/bandwidth) is the inverse gain used to convert the image values to radiance, since DN was previously defined as
      DN = Radiance * radiance_to_DN_Gain + Bias (and we are ignoring Bias)

      So, the gain we calculate for the apparent reflectance function (DN_to_radiance_gain) is the absolute calibration factor divided by the effective band width for each band. Does this answer the question?

      The absolution calibration factors for each band should be stored in the .imd file, but the effective band widths are not. However, they are constants that are listed on page 3 of the document and reprinted here:

      Band Effective Band Width
      Pan 0.398
      Blue 0.068
      Green 0.099
      Red 0.071
      Near Infrared 0.114

      The conversion from radiance to reflectance accounts for differences in illumination based on sun elevation and the solar irradiance constants for each band. As observed, ArcMap calculates the sun elevation and hard-codes the irradiance constants into the function.

      This table is listed in the document on page 4 and is reprinted here:

      Band Spectral Irradiance
      Pan 1381.79
      Blue 1924.59
      Green 1843.08
      Red 1574.77
      Near Infrared 1113.71

      All of this is handled by the QuickBird Builder when an image is loaded into a mosaic dataset. For a raster dataset the dn_to_radiance_gains can be calculated as above and set into the function arguments. The bias values can be set to 0.

      Note: Since QuickBird uses only one gain setting for multispectral bands, the largest improvement from Apparent Reflectance will be as a result of the sun elevation. As observed, the function handles the sun distance behind the scenes.

      Note: These calibration factors apply only to 11-bit imagery. For 8-bit imagery, the values must be scaled. Page 11 of the document addresses this issue.

      Hope this helps.

      • lwsbg_at says:

        Dear Simon,
        you claim in the above posting that the apparent reflectance function accounts for the Earth-Sun-Distance. I am not sure this is correct. The solar irradiance depends on the solar spectrum at the wavelength portion covered by each of the sensor’s bands (which is accounted for), by the solar elevation angle (which is also accounted for), and by the sun-earth-distance. The sun-Earth-distance variation results in a variation of illumination in the order of 5% or so, which is considerable. The above posting does not tell anywhere that this is taken into account. The Sun-Earth distance has to be calculated based on the date of the observation, which can be taken from the metadata.
        To my understanding, the above “Band spectral irradiances” are valid for a Sun-Earth-distance of exactly one astronomical unit, and have to be adapted to the current situation of the observation. At least, that is how I understand the description you posted for worldview2 images:
        For Quickbird, I am not sure, but as you name these values “constants” in the above posting, they must be the irradiance values for 1 AU (otherwise, they would not be constant), so that I assume that the actual Sun-Earth-distance is left unaccounted for.
        An exception are the metadata values provided with Landsat, which already account for sun-earth distance, sun elevation and sensor band widths.
        I suggest that the help files to this topic should be updated to clarify what is accounted for. These kind of things should be clear from the beginning, and not have to be figured out by the comments of other user’s in a blog. You are supposed to be experts on this!
        Also, I would strongly appreciate to get the reference publications for every value that is not taken from the metadata in the helpfiles. These calibration values can change over time, so the user should know on which values the calculations are based on.
        Best wishes,

        • Simon Woo says:

          The Earth-Sun distance is taken into account in the Apparent Reflectance function. It is calculated using the date of capture of the scene (which is the “AcquisitionDate” key property of the Sensor product in ArcGIS). For Landsat 8 data, the Earth-Sun distance is built directly into the Reflectance factors, represented using the REFLECTANCE_MULT_BAND_* and REFLECTANCE_ADD_BAND_* factors read directly from the metadata file. For all the other sensors, the Earth-Sun distance is taken into account, along with he Solar elevation and solar zenith angles.

  4. insyzygy says:

    I have some Landsat 5 data (L1G) that I viewing with Image Analysis module within ArcMap.
    I am having issues applying the Apparent Radiance Function. I insert the function after the composite function but before the stretch function but when I click on the “Key Metadata” tab within the Apparent Radiance Function dialog all the requisite variables such as Radiance_Gain and Radiance_Bias are all zero even though I can see the values in the TXT metadata file.
    A copy of the metadata is below.
    I would appreciate any advice.

    ORIGIN = “Image courtesy of the U.S. Geological Survey”
    REQUEST_ID = “0101309279847_00009″
    LANDSAT_SCENE_ID = “LT52070231984161XXX03″
    FILE_DATE = 2013-09-27T20:26:39Z
    DATA_TYPE = “L1G”
    SENSOR_ID = “TM”
    WRS_PATH = 207
    WRS_ROW = 023
    DATE_ACQUIRED = 1984-06-09
    SCENE_CENTER_TIME = 10:57:17.0770560Z
    CORNER_UL_LAT_PRODUCT = 54.08711
    CORNER_UL_LON_PRODUCT = -10.02581
    CORNER_UR_LAT_PRODUCT = 54.06216
    CORNER_UR_LON_PRODUCT = -6.34432
    CORNER_LL_LAT_PRODUCT = 52.11067
    CORNER_LL_LON_PRODUCT = -9.97984
    CORNER_LR_LAT_PRODUCT = 52.08744
    CORNER_LR_LON_PRODUCT = -6.46319
    THERMAL_LINES = 7331
    FILE_NAME_BAND_1 = “LT52070231984161XXX03_B1.TIF”
    FILE_NAME_BAND_2 = “LT52070231984161XXX03_B2.TIF”
    FILE_NAME_BAND_3 = “LT52070231984161XXX03_B3.TIF”
    FILE_NAME_BAND_4 = “LT52070231984161XXX03_B4.TIF”
    FILE_NAME_BAND_5 = “LT52070231984161XXX03_B5.TIF”
    FILE_NAME_BAND_6 = “LT52070231984161XXX03_B6.TIF”
    FILE_NAME_BAND_7 = “LT52070231984161XXX03_B7.TIF”
    METADATA_FILE_NAME = “LT52070231984161XXX03_MTL.txt”
    CPF_NAME = “L5CPF19840401_19840630.09″
    CLOUD_COVER = 80.00
    SUN_AZIMUTH = 139.98757277
    SUN_ELEVATION = 54.92794410
    RADIANCE_MULT_BAND_1 = 0.671
    RADIANCE_MULT_BAND_2 = 1.322
    RADIANCE_MULT_BAND_3 = 1.044
    RADIANCE_MULT_BAND_4 = 0.876
    RADIANCE_MULT_BAND_5 = 0.120
    RADIANCE_MULT_BAND_6 = 0.055
    RADIANCE_MULT_BAND_7 = 0.066
    RADIANCE_ADD_BAND_1 = -2.19134
    RADIANCE_ADD_BAND_2 = -4.16220
    RADIANCE_ADD_BAND_3 = -2.21398
    RADIANCE_ADD_BAND_4 = -2.38602
    RADIANCE_ADD_BAND_5 = -0.49035
    RADIANCE_ADD_BAND_6 = 1.18243
    RADIANCE_ADD_BAND_7 = -0.21555
    DATUM = “WGS84″
    UTM_ZONE = 29

  5. Simon Woo says:

    Your Landsat 5 metadata file looks much different than those in our collection.
    Where is your Landsat 5 data coming from? Has the meta data been altered in any way?

    Your metadata looks like this:

    USGS data that we have looks like this:
    LMAX_BAND1 = 191.600
    LMIN_BAND1 = -6.200
    QCALMAX_BAND1 = 255.0
    QCALMIN_BAND1 = 1.0

  6. mcj6fd says:

    Hi, I am trying to use this function on a 2011 Ikonos image. I have found the published radiometric calibration coefficients and the gain coefficients in Pagnutti et al. and Dial et al. 2003 and . I am not sure what are the bias values, are these the standard errors (or deviation, not specified) of the gain provided by NASA? Or are we supposed to ignore the bias?
    In short should I enter: 64.1 for Blue, 65.4 for Green, 87.7 for Red, 75.8 for NIR in gains and leave bias empty? or enter the SE/SD provided in bias?
    Many thanks,

    • Simon Woo says:

      I am not an expert on apparent reflectance, so I deferred this question to one of my colleagues. Unfortunately he was a bit confused by your numbers. Can you help clear up the confusion. I will post his response (below):
      I was preparing a response (see below), but then looked more closely at the values they were going to add (I presume as gain values) and they are not correct gain values. Do you think they are referring to bias values in which case they seem way too high (e.g., 64.1)? Or they referring to gain values in which case they have not properly converted to watts/m2/micron? FYI, typical gain values are in the range of:
      For b, g, r, nir respectively.
      If you can please help answers his questions, we will do our best to help you with your issue.


  7. clara_i says:

    Hello! I am working with Landsat 8 scenes, and I cannot seem to make this function work. When I select the band, the bias and gain values are no data/empty field. I can’t seem to find any other documentation than this. Do you have any suggestions for why this is happening or on how to make this function work? Would appreciate an answer. Best, Clara

    • Simon Woo says:

      Landsat 8 metadata does not use gain/bias, but it instead uses similar concepts under name REFLECTANCE_MULT and REFLECTANCE_ADD. So for Landsat 8, the gains/bias are all set to the fixed number of 2.0000E-05 and -0.1 .

      For all sensors that we can calculate Apparent Reflectance, gain/bias (REFLECTANCE_MULT/REFLECTANCE_ADD for Landsat 8), sun elevation and acquisition date will be used together to convert DN to reflectance.

      Under our definition, albedo is the actual ratio (a floating point number range from 0 to 1), while apparent reflectance is a more general term that is scaled to output type.

      • tristan_berg says:

        Hi all,
        Thanks for all the info above. I seem to be almost there, as Simon above is pointing out the albedo has a range between 0 to 1.
        I use Landsat 8 data, I checked the Albedo box within the Raster Function Properties window and I expect to get a raster, comparable to when you make a NDVI raster. But I get a raster with multiple bands, 8, which seems to have all the information for the Albedo analyses, do I need to take an extra step? Can someone please point me out what I am doing wrong and how I can get an Albedo raster ranging from 0 to 1?
        Kind regards, Tristan

        • Simon Woo says:

          The function computes Albedo for each band, so you do indeed get 8 band output. The output data is 32bit floating point, and should range between 0 and 1. Simply stretch it for viewing or for incorporation with other data. (What does your albedo numbers look like?)

          NDVI is an index, and thus is a single band output.

  8. lwsbg_at says:

    Dear Simon,
    thank you very much for this interesting post. I find the raster functions really nice and helpful to streamline image preprocessing. However, I calculated some reflectance values that make me wonder if there might be a bug in the code of the apparent reflectance function.
    1: I load a GeoEye1 scene from South Sudan using “multispectral” from the IMD file in ArcCatalog. I then insert the apparent reflectance function and check “albedo”. Strangely, the values I get are in the order of 0,015 to 0,025 or so. This appears to be one order of magnitude to low. I also have a WV2 scene from a few weeks later. This image shows values around 0.20, which makes more sense to me. Could there be a problem with the handling of the Geoeye1 metadata files?
    2. While values calculated from WV2 appear to be more reasonable, I also have doubts about them. I observe pronounced differences between reflectance values calculated with the raster functions and with another software, with the apparent reason being differences in the underlying exoatmospheric irradiance values. Is there a source somewhere to know from where the irradiances used in the raster functions stem from?
    Thank you very much for your hints!

  9. jamescurra says:

    Does anybody know that if when I use the information function to get the values of the red blue and green values if those are still DN’s or have they been converted to a radiance or brightness value? If so what unit would they be? I’m using Landsat images and I need the reflectance/radiance at certain points for each band.

    • Simon Woo says:

      Identify returns values of the function raster.
      If there is apparent reflectance, it will return the AR value.

    • jliedtke_imagery says:

      The AR values are DNs defined by the scale and offset values you specified in the function. If you specified output as “Albedo”, it is albedo, or brightness, which is a floating point value between 0 and 1.

  10. bicycleman says:

    Is there any chance this function will be updated for the newer Worldview-3 imagery? I tried it and it doesn’t seem to extract the correct data from the metafiles. But, the data are similar to worldview-2 so presumably this could be done?

    • Simon Woo says:

      Which version of ArcGIS are you currently using?

      At ArcMap 10.5.1 and later, apparent reluctance works for both WorldView-3 and WorldView-4.
      Please let us know if you are using a version that should support this and it is still not functioning properly.