Hello,
I just committed a rewritten i.pca module. It now supports NULL cells
without skewing the data and will work properly with float/double maps.
It's a bit slower than the original, but that's the price we pay for
modules that work. 
My testing has proved good results, but I'd like to have others test.
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
Thanks Brad. I hope to try it out if I have time to recompile this week.
Michael
On 2/19/07 3:59 PM, "Brad Douglas" <rez@touchofmadness.com> wrote:
Hello,
I just committed a rewritten i.pca module. It now supports NULL cells
without skewing the data and will work properly with float/double maps.
It's a bit slower than the original, but that's the price we pay for
modules that work.My testing has proved good results, but I'd like to have others test.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Monday 19 February 2007 14:59, Brad Douglas wrote:
Hello,
I just committed a rewritten i.pca module. It now supports NULL cells
without skewing the data and will work properly with float/double maps.
It's a bit slower than the original, but that's the price we pay for
modules that work.My testing has proved good results, but I'd like to have others test.
I will give this a try as well.
thanks brad!
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
Brad,
I had a chance to try this out tonight. It works very well. It seems to go
quite fast too. Here is a nice result of a PCA of a Terra ASTER bands 1-9
(VNIR and SWIR) for part of the Phoenix metro area. I used d.his to show PCA
bands 1-3. The Salt River Indian Reservation agricultural fields really
stand out as do some of the mountain park areas.
<http://www.public.asu.edu/~cmbarton/files/temp/phoenix_aster1-9_pca.jpg>
Michael
On 2/20/07 7:41 AM, "Michael Barton" <michael.barton@asu.edu> wrote:
Thanks Brad. I hope to try it out if I have time to recompile this week.
Michael
On 2/19/07 3:59 PM, "Brad Douglas" <rez@touchofmadness.com> wrote:
Hello,
I just committed a rewritten i.pca module. It now supports NULL cells
without skewing the data and will work properly with float/double maps.
It's a bit slower than the original, but that's the price we pay for
modules that work.My testing has proved good results, but I'd like to have others test.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Thu, 2007-02-22 at 22:24 -0700, Michael Barton wrote:
Brad,
I had a chance to try this out tonight. It works very well. It seems to go
quite fast too. Here is a nice result of a PCA of a Terra ASTER bands 1-9
(VNIR and SWIR) for part of the Phoenix metro area. I used d.his to show PCA
bands 1-3. The Salt River Indian Reservation agricultural fields really
stand out as do some of the mountain park areas.<http://www.public.asu.edu/~cmbarton/files/temp/phoenix_aster1-9_pca.jpg>
Isn't ASTER great? 
Too bad ALI/Hyperion costs $$.
Is the pinkish area on the right edge supposed to be NULL data? If so,
I would make sure you ran 'r.null setnull=0'. The non-null data may
skew your results, slightly. This was one of my motivations for the
rewrite.
Another of my pie-in-the-sky ideas is to write a module to adjust gains
and calculate top of atmosphere reflectance or emissivity (where it can
then be piped into i.atcorr). Writing the module isn't difficult, but
it requires metadata, which GRASS currently has no real method of saving
or retrieving after r.in.gdal. Currently, I have to look up metadata
via 'gdalinfo' and manually run it through a series of r.mapcalc
transactions. Very tedious even if scripted.
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
Very long time ago (2000/2001?) i started writing a grass script to separate
the Temperature and Emissivity of Aster. I failed, but the main lines of the
equations where separated and laid down. Actually, higher level products were
then available directly (and free at that time!) so it it was not worth the
pain continuing the development.
Well, the emissivity/temperature splitting for Aster may actually be a nice
module to develop.
Besides, in grassaddons SVN, the conversion module for Landsat, the
r.dn2ref.l7/r.dn2full.l7 could be nice to integrate with r.in.gdal (loosely
or tight, is not the question now). I also have the r.dn2ref.ast that would
also be nice to integrate with Aster import (r.in.aster?).
The Aster TOA reflectance conversion from DN should be possible by dumping
gdalinfo into a temp.txt and parse that *somehow*. Unless we could try and
use the GDAL API, but i am in unknown land here...
Brad any way you know to auto-calibrate i.atcorr?
any comments please or more than welcome.
Yann
On Friday 23 February 2007 13:27, Brad Douglas wrote:
On Thu, 2007-02-22 at 22:24 -0700, Michael Barton wrote:
> Brad,
>
> I had a chance to try this out tonight. It works very well. It seems to
> go quite fast too. Here is a nice result of a PCA of a Terra ASTER bands
> 1-9 (VNIR and SWIR) for part of the Phoenix metro area. I used d.his to
> show PCA bands 1-3. The Salt River Indian Reservation agricultural fields
> really stand out as do some of the mountain park areas.
>
> <http://www.public.asu.edu/~cmbarton/files/temp/phoenix_aster1-9_pca.jpg>Isn't ASTER great?
Is the pinkish area on the right edge supposed to be NULL data? If so,
I would make sure you ran 'r.null setnull=0'. The non-null data may
skew your results, slightly. This was one of my motivations for the
rewrite.Another of my pie-in-the-sky ideas is to write a module to adjust gains
and calculate top of atmosphere reflectance or emissivity (where it can
then be piped into i.atcorr). Writing the module isn't difficult, but
it requires metadata, which GRASS currently has no real method of saving
or retrieving after r.in.gdal. Currently, I have to look up metadata
via 'gdalinfo' and manually run it through a series of r.mapcalc
transactions. Very tedious even if scripted.
--
Yann Chemin
Sainte-Anne d'Auray, France
Good point. But I can't just set 0=NULL, because there might well be 0's
that mean something (e.g., water). If I really wanted to work with this
image, I'd probably have to make a 'null mask' with the map calculator,
setting to null any pixel that is 0 in all bands, and setting the rest to 1.
Then I multiply each image by the null mask. If you have a faster way, I'd
love to know about it.
Michael
On 2/22/07 11:27 PM, "Brad Douglas" <rez@touchofmadness.com> wrote:
Is the pinkish area on the right edge supposed to be NULL data? If so,
I would make sure you ran 'r.null setnull=0'. The non-null data may
skew your results, slightly. This was one of my motivations for the
rewrite.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Monday 19 February 2007 14:59, Brad Douglas wrote:
Hello,
I just committed a rewritten i.pca module. It now supports NULL cells
without skewing the data and will work properly with float/double maps.
It's a bit slower than the original, but that's the price we pay for
modules that work.My testing has proved good results, but I'd like to have others test.
Hi Brad,
I just tried it out with some ikonos imagery (r,g,b bands only...) with good
results. The various vegetation communities standout, along with the rock
outcroppings (bright pink) ! I have previously been using NDVI for the rock
outcrops, but it looks like this approach might work better. Good
performance, total time for 13838448 cells was about 1 minute on a 3ghz xeon.
commands used:
i.pca in=ikonos.red,ikonos.green,ikonos.blue output=ikonos.pca
d.rgb r=ikonos.pca.1 g=ikonos.pca.2 b=ikonos.pca.3
see the original ikonos image here:
http://169.237.35.250/~dylan/temp/ikonos.rgb.jpg
and the three PCA rasters combined with d.rgb here:
http://169.237.35.250/~dylan/temp/i.pca-ikonos.jpg
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
On Fri, 2007-02-23 at 11:20 -0800, Dylan Beaudette wrote:
On Monday 19 February 2007 14:59, Brad Douglas wrote:
> Hello,
>
> I just committed a rewritten i.pca module. It now supports NULL cells
> without skewing the data and will work properly with float/double maps.
> It's a bit slower than the original, but that's the price we pay for
> modules that work.
>
> My testing has proved good results, but I'd like to have others test.Hi Brad,
I just tried it out with some ikonos imagery (r,g,b bands only...) with good
results. The various vegetation communities standout, along with the rock
outcroppings (bright pink) ! I have previously been using NDVI for the rock
outcrops, but it looks like this approach might work better. Good
performance, total time for 13838448 cells was about 1 minute on a 3ghz xeon.
Thank you guys for doing a little testing for me!
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
On Fri, 2007-02-23 at 14:01 +0700, Yann wrote:
Very long time ago (2000/2001?) i started writing a grass script to separate
the Temperature and Emissivity of Aster. I failed, but the main lines of the
equations where separated and laid down. Actually, higher level products were
then available directly (and free at that time!) so it it was not worth the
pain continuing the development.Well, the emissivity/temperature splitting for Aster may actually be a nice
module to develop.
That could simply be a module option. The calculations are trivial at
that point, but again, cannot be done without GRASS being aware of
metadata.
Besides, in grassaddons SVN, the conversion module for Landsat, the
r.dn2ref.l7/r.dn2full.l7 could be nice to integrate with r.in.gdal (loosely
or tight, is not the question now). I also have the r.dn2ref.ast that would
also be nice to integrate with Aster import (r.in.aster?).
IIRC, r.in.aster does not work right and should really be renamed
i.in.aster. i.landsat does not work correctly, either (it makes
assumptions it should not - eg. gain corrections, nadir angle,
etc.)...it has no metadata support and it looks like values were hard
coded.
The Aster TOA reflectance conversion from DN should be possible by dumping
gdalinfo into a temp.txt and parse that *somehow*. Unless we could try and
use the GDAL API, but i am in unknown land here...
It is not practical to dump and parse a text file. The GDAL API could
be used to get metadata from embedded formats like HDF. Others are more
difficult.
IMO, the history file is not usable for storing metadata. At least not
in it's present incarnation. Making it so would require a rewrite of
many of the history functions. It is probably easier to create a new
set of metadata functions that also includes much of the history
functionality and eventually deprecate the history file.
Brad any way you know to auto-calibrate i.atcorr?
Not off-hand, no.
--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785
r.in.aster doesn't work right--yet again--presumably because NASA changed
the format for specifying the data layers--yet again. This is the 2nd time
they've done this since I wrote it. I haven't got around to figuring it out
and fixing it again.
Michael
On 2/23/07 9:24 PM, "Brad Douglas" <rez@touchofmadness.com> wrote:
IIRC, r.in.aster does not work right and should really be renamed
i.in.aster. i.landsat does not work correctly, either (it makes
assumptions it should not - eg. gain corrections, nadir angle,
etc.)...it has no metadata support and it looks like values were hard
coded.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Dylan Beaudette wrote:
On Monday 19 February 2007 14:59, Brad Douglas wrote:
> Hello,
>
> I just committed a rewritten i.pca module. It now supports NULL
> cells without skewing the data and will work properly with
> float/double maps. It's a bit slower than the original, but that's
> the price we pay for modules that work.
>
> My testing has proved good results, but I'd like to have others
> test.Hi Brad,
I just tried it out with some ikonos imagery (r,g,b bands only...)
with good results. The various vegetation communities standout, along
with the rock outcroppings (bright pink) ! I have previously been
using NDVI for the rock outcrops, but it looks like this approach
might work better. Good performance, total time for 13838448 cells
was about 1 minute on a 3ghz xeon.commands used:
i.pca in=ikonos.red,ikonos.green,ikonos.blue output=ikonos.pca
d.rgb r=ikonos.pca.1 g=ikonos.pca.2 b=ikonos.pca.3see the original ikonos image here:
http://169.237.35.250/~dylan/temp/ikonos.rgb.jpgand the three PCA rasters combined with d.rgb here:
http://169.237.35.250/~dylan/temp/i.pca-ikonos.jpg
i.oif is interesting to check out too. feed it multi-band data and it
will tell you the three-band combination that will show the most
information. Then experiment with different r= g= b= combinations to
get the best combo.
Hamish
On Sunday 25 February 2007 15:19, Hamish wrote:
Dylan Beaudette wrote:
> On Monday 19 February 2007 14:59, Brad Douglas wrote:
> > Hello,
> >
> > I just committed a rewritten i.pca module. It now supports NULL
> > cells without skewing the data and will work properly with
> > float/double maps. It's a bit slower than the original, but that's
> > the price we pay for modules that work.
> >
> > My testing has proved good results, but I'd like to have others
> > test.
>
> Hi Brad,
>
> I just tried it out with some ikonos imagery (r,g,b bands only...)
> with good results. The various vegetation communities standout, along
> with the rock outcroppings (bright pink) ! I have previously been
> using NDVI for the rock outcrops, but it looks like this approach
> might work better. Good performance, total time for 13838448 cells
> was about 1 minute on a 3ghz xeon.
>
> commands used:
> i.pca in=ikonos.red,ikonos.green,ikonos.blue output=ikonos.pca
> d.rgb r=ikonos.pca.1 g=ikonos.pca.2 b=ikonos.pca.3
>
> see the original ikonos image here:
> http://169.237.35.250/~dylan/temp/ikonos.rgb.jpg
>
> and the three PCA rasters combined with d.rgb here:
> http://169.237.35.250/~dylan/temp/i.pca-ikonos.jpgi.oif is interesting to check out too. feed it multi-band data and it
will tell you the three-band combination that will show the most
information. Then experiment with different r= g= b= combinations to
get the best combo.Hamish
Thanks Hamish!
I will be sure to try this out with our local landsat data.
cheers,
dylan
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
