[GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)

[Nikos Alexandris]

Nikos wrote:
> > Just FYI, results look nice!  I even convert back to 0-1.0 via

> > r.mapcalc --o "${HistoMatchedMap} = ${HistoMatchedMap} / 1000.0"
> > ps- I wonder if *10000 is *better* for higher precision?

By the way, that was Landsat5!


> depending on the sensor's 8-bitnesss or not, you can probably calculate by
> hand now many significant digits are useful. A little bit extra probably
> doesn't hurt.
> 
> 1 / 2^8 = 0.00390625

I didn't pay too much attention back then as I was under enormous time 
pressure.  But, I think I didn't miss much of the precision with respect to 
the final product's scope.  Except if the last 4 (or 3, can't remember) digits 
make up a great deal when histo-matching.


Back to present.  QuickBird is an 11-bit sensor [1] and data are delivered as 
either 8-bit or 16-bit. In this case we have

1 / 2^11 = 0.0004882812

Does that say anything about the significant digits?  I want to rescale 
QuickBird bands in order to use'em with i.pansharpen.  I am thinking to go 
from Reflectance (double precision) to integer (as above, only this time I'd 
multiply with a number as big as it takes to keep all decimals) and then 
rescale to [0, 255].

Makes non-/sense?  Any idea how many decimals should be preserved for 
analysis?  I might be hunting "fine digits" for nothing...


In any case, conversions from DNs to Reflectance should be done in a 32-bit 
level [2] (that corresponds to: 1 / 2.328306e-10).  The same is done with 
Landsat imagery though both L5 and L7 data are delivered as 8-bit [3].

Nikos


---
[1] also mentioned in the document 
<http://www.digitalglobe.com/downloads/QuickBird_technote_raduse_v1.pdf>, page 
7

[2] same document, page 8: "...conversion equations are to be
performed on all pixels in a given band of a QuickBird image and should use 
32-bit floating point calculations."

[3] http://landsat.usgs.gov/how_is_radiance_calculated.php