[GRASS5] Re: [GRASSLIST:1810] Re: i.ortho.photo on osx

GRASS GRASS developer
1

(cc 'grass5')

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

On Sat, Nov 22, 2003 at 08:18:25PM -0700, Richard Greenwood wrote:

At 09:47 AM 11/20/2003, Markus Neteler wrote:
>Our group has recitified 100+ images without problems, in terrible
>terrain (200-3500m) with an average error of 6 meters which is
>acceptable.

That eliminates one of my theories - that the author of i.ortho.rectify
assumed feet.

> > However, when I converted the vertical units to feet, the results were
> correct.
>
>Mhhh. I think that both horizontal and vertical units should be identical.

Yes, so do I! Or some constant needs to be applied if the horizontal and
vertical units differ, but I do not see any place in i.ortho.rectify where
the vertical units are specified.

> > The example in your book uses Spearfish. I don't have Spearfish loaded
> > right now, but I am guessing that the elevation model is in feet. Possibly
> > I am wrong?
>
>No, the spearfish DEM is in meters:
>
>r.info elevation.dem
>[...]
> | Data Description:
> | Elevation above mean sea level in meters for spearfish database

Yes, you are quite right. I loaded Spearfish and worked thru the example in
your book and arrived at a satisfactory image rectification.

All of this is to say that I have gotten no closer to identifying the
problem. If we rule out an error in the program logic, then it makes me
think that the differences are in the definition of the location, but I do
not see anything there that specifies a unit for vertical data.

I will keep looking at this, but any pointers would be appreciated.

Best regards,
Rich

Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com

--
Markus Neteler <neteler@itc.it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

2

At 10:07 AM 11/26/2003, Markus Neteler wrote:

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.

Markus, Ian;

I revisited my problematic project, converted to DCELL and it worked very nicely. Thanks Markus! But, I am confused on FCELL versus DCELL. I assumed that my metric DEM was integers and that converting to feet created a floating point, or double precision DEM, thus avoiding the problem you describe above. But what is the difference between FCELL and DCELL?

An important note (especially for Ian), my Overall rms error was 17.92 with my DEM in feet, but went down to 1.71 with a DCELL DEM in meters. I believe this is because the vertical units must be the same as the horizontal units. In other words, by converting to feet I was able to bypass the problem Markus has described and create a visually acceptable ortho rectification, but not a 'correct' rectification. I had attributed the high rms error to bad data, but I no longer believe that to be the case.

Two 'off topic' notes:

Markus - I have a 5.0.3 cygwin binary distribution at www.greenwoodmap.com/grasss (see configure.log for configure options) I have been using it for about two weeks and I am reasonably confident with it. In my limited testing, PostgreSQL seems to be working, too!

Ian - my sister and here ex-husband (Helen and Paul Hansma) both teach/research at UCSB in surface biology and physics. Please give them my regards if you happen to know them.

Best regards,
Rich

Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich <at> GreenwoodMap <dot> com
(307) 733-0203
http://www.GreenwoodMap.com

3

Richard Greenwood wrote:

I revisited my problematic project, converted to DCELL and it worked very
nicely. Thanks Markus! But, I am confused on FCELL versus DCELL. I assumed
that my metric DEM was integers and that converting to feet created a
floating point, or double precision DEM, thus avoiding the problem you
describe above. But what is the difference between FCELL and DCELL?

FCELL is single-precision floating-point (32 bits, aka C's "float"
type), while DCELL is double-precision (64 bits, C's "double" type).

DCELL is often used as a "generic" type, because it can exactly
represent any value which CELL and FCELL can represent. OTOH
converting from CELL to FCELL can result in loss of accuracy for
integers outside the range ±2^24.

--
Glynn Clements <glynn.clements@virgin.net>

4

On Fri, Nov 28, 2003 at 05:59:43PM -0700, Richard Greenwood wrote:

At 10:07 AM 11/26/2003, Markus Neteler wrote:

>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.

Markus, Ian;

I revisited my problematic project, converted to DCELL and it worked very
nicely. Thanks Markus! But, I am confused on FCELL versus DCELL. I assumed
that my metric DEM was integers and that converting to feet created a
floating point, or double precision DEM, thus avoiding the problem you
describe above. But what is the difference between FCELL and DCELL?

[ already explained ]

An important note (especially for Ian), my Overall rms error was 17.92 with
my DEM in feet, but went down to 1.71 with a DCELL DEM in meters. I believe
this is because the vertical units must be the same as the horizontal
units.

I think yes.

In other words, by converting to feet I was able to bypass the
problem Markus has described and create a visually acceptable ortho
rectification, but not a 'correct' rectification. I had attributed the high
rms error to bad data, but I no longer believe that to be the case.

Two 'off topic' notes:

Markus - I have a 5.0.3 cygwin binary distribution at
www.greenwoodmap.com/grasss (see configure.log for configure options) I
have been using it for about two weeks and I am reasonably confident with
it. In my limited testing, PostgreSQL seems to be working, too!

Thanks, I am downloading right now, will be in
http://grass.itc.it/grass5/binary/windows_cygnus/wingrass_xserver/
soon.

[...]

Markus