RISC6000s, GRASS4.1 ?

Michael Shapiro shapiro at zorro.cecer.army.mil
Thu Aug 20 17:05:39 EDT 1992


i.pca reads the entire inage into memory. I needs to be rewritten to
to only do one row of the image at a time. This might require additional
passes thru the data, but I think that is preferable to requiring so much
memory. 

r.mfilter is a BIG hog about disk space. Since the filters can be applied
more than once, it was designed to use a flat file in .tmp to hold the
"intermediate" results. This module could also be modified to use the
resultant raster map as the intermediate storage as well, thus gaining
the GRASS compression.

One solution for i.pca is to set your resolution "larger" so that i.pca
doesn't read each pixel, but, say, every 3rd pixel. The difference between
the covariance matrices for all pixels and a subsample would probably
not be significant.

A solution for r.mfilter is to write the filter using r.mapcalc which
supports filters (although in a less intuitive and user friendly way).
Since you are only doing a 3x3 it would not be too tedious to write this
using r.mapcalc. With r.mapcalc, results go directly to raster files,
compressed, so they don't have as big a hit on disk space as r.mfilter.

|
|The only image processing functions I have been having problems with are:
|
|1) "i.pca" gives me a G_malloc erros whenever I use it on an image subscene 
|   > than 900*900 pixels i.e. less than 1 Mb in GRASS compressed raster format?
|   ...I don't understand why this is so as we have a 320 H with 32Mb RAM 
|   & 64 Mb swap space (running AIX 3.2.1).
|
|2) "r.mfilter" (and I think i.fft?) is very selfish with disk space...
|   I tried running a 3 * 3 Laplacian edge enhancement filter on 
|   a 1/4 SPOT scene (13Mb approx) and the program needed 8 times this amount
|   of disk space to successfully write out the processed image to the
|   $GISBASE/$Location/$Mapset/.tmp directory. I would like to edge enhance
|   the full scene but can't afford the disk space. I suppose I could use 
|   "r.patch" and accept a couple of erroneous pixels at the  "stitch" boundary
|   between four quarter scenes...
|
|
||The G_malloc() problems are different for vectors and imagery. The
||vector fixes are on moon.cecer.army.mil. The imagery problems are
||probablyu not bugs as much as lack of memory on your machine. Can you describe
||the problems with imagery? Which program(s) run out of memory?
||
|||Hi,
|||
|||Does anyone know if the problems with the vector and image processing
|||functions of the GRASS4.0 port to IBM RISC6000s (particularly the 
|||G_malloc errors) have been solved?
|||
|||Also, does anyone know if RISC6000s will be supported by GRASS4.1?
|||
|||Thanks in advance, 
|||
|||Tony Gale
|||----------------------------
|||Research Specialist
|||City of Austin Electric, Tx.
|||----------------------------
|||
|||
||
||
||
||    Michael
||
|
|
|Tony
|
|
|
|
|
|



Michael



More information about the grass-dev mailing list