[winGRASS] i.ortho.photo

[Richard Greenwood]

T. C. Hales wrote:

> Hi
> 
> I've been trying to use i.ortho.photo in cygwin. I have followed the
> pages in the manual closely yet when I finally set it all going it
> distorts the photo into a series of bands. I've tried messing with
> parameters in the all of the steps but to no avail. I was wondering if
> anyone else was having problems getting it running and/or if anyone
> had any good tips.
> 
> Thanks
> TC
> 
> T.C. Hales

The problem is probably not specific to cygwin (I have had sucess with 
i.ortho.photo on cygwin). You might want to search the grasslist 
archives, because there was a pretty extensive discussion a couple 
months ago of a problem that sounds similar to yours. I have pasted the 
"final" answer from that thread below. Basically be sure that your cells 
are of type DCELL and that your X,Y,and Z units are all the same.

Rich

=== quoting from earlier thread ====

Markus Neteler wrote:

Regarding the "boxes" problem in i.ortho.photo results:

Reference:
http://grass.itc.it/pipermail/grassuser/2003-November/010893.html

Above problems should be fixed now (in 5.3-CVS). Reason was
that a DEM of FCELL type was not read properly.
In case of such troubles either update i.ortho.photo or use
'r.recode' to make the DEM of DCELL type.

If such "boxes" still appear (e.g. with DCELL DEM) there are some
more issues to consider. We have made some more test: The strange
"boxes" (should be 128x128 pixel) seem to appear in the result
under certain conditions, when:
- is independent of the operating system
- seem to be independent of DEM in meters/feet
- resolution of aerial image is much higher than resolution
   of the DEM (e.g 1m vs 10m)
- boxes seem to appear only in mountainous regions with
   high slope. The underlying photo.rectify uses tiles to rectify
   an aerial images. The elevation is taken as a single value for
   all pixels in a tile. With high slope (large elevation range within
   the tile) the deviations are currently large.
   Solution:
   Change
   src/imagery/i.ortho.photo/photo.rectify/global.h
   from
#define TIE_ROW_DIST 128
#define TIE_COL_DIST 128

#define NROWS 128
#define NCOLS 128
   to
#define TIE_ROW_DIST 32
#define TIE_COL_DIST 32

#define NROWS 32
#define NCOLS 32

   (then recompile). The result will be nice (tested with the above 
mentioned
    'calico' data set we received from Ian Macmillan).
   Problem: It's much, much slower.

   A good solution would be to have dynamic tile size selection in
   photo.rectify which takes the elevation/slope (or maybe range vs camera
   height) into account. In plains the tile size might be even larger so
   the the rectification process could be much faster.
   I am unable to implement that and seeking for help (demo locations
   available on request). Maybe it's not too difficult to implement ...

We have left untouched the tile size 128x128 in CVS. You may test with
your local installation and hopefully confirm the observations. Then we
can decide if/how to lower it.

Best regards

  Markus Neteler


-- 
Richard Greenwood
www.greenwoodmap.com