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

[Michael Barton]

Nikos,

What about just using r.rescale to rescale this?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu












On Jul 31, 2013, at 8:07 PM, <grass-dev-request at lists.osgeo.org<mailto:grass-dev-request at lists.osgeo.org>>
 wrote:

From: Nikos Alexandris <nik at nikosalexandris.net<mailto:nik at nikosalexandris.net>>
Subject: Re: [GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Date: July 31, 2013 3:38:24 PM MST
To: Hamish <hamish_b at yahoo.com<mailto:hamish_b at yahoo.com>>
Cc: <grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>>, Markus Metz <markus.metz.giswork at gmail.com<mailto:markus.metz.giswork at gmail.com>>


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130801/a2832eef/attachment-0001.html>