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

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@lists.osgeo.org>
wrote:

From: Nikos Alexandris <nik@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@yahoo.com>

Cc: <grass-dev@lists.osgeo.org>, Markus Metz <markus.metz.giswork@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