Subject: bad target region calculations with i.rectify order=3
Hi,
i.rectify (both 6.0.0, 6.1cvs) is creating rasters with incorrect regions and
resolutions when doing a 3rd order transform. It works fine with 1st or second
order transforms. 'i.rectify -c' (or lower order) is needed to get a good
transform.
Starting with unreferenced simple XY map (PNG imported with r.in.gdal)
and re-regioned to positive values with r.region, keeping res=1 pixel.
Target location is lat/lon (both wgs84 and none/intl datums fail)
e.g. eastern boundary ends up being +2 degrees east of what it should be,
resolution is calculated from e-w/cols so that ends up very coarse...
southern boundary is wrong too.
CRS_georef() in imagery/i.rectify/crs.c ?
more info available upon request.
thanks,
Hamish
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 20 Apr 2005 15:25:10 +0200
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3166] (grass) bad target region calculations with i.rectify order=3
|
Message-ID |
<20050420132510.GC8579@thuille.itc.it>
|
Mail-Followup-To |
Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
|
References |
<20050420050011.A14781005DD@lists.intevation.de>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
In-Reply-To |
<20050420050011.A14781005DD@lists.intevation.de>
|
User-Agent |
Mutt/1.4.1i
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On Wed, Apr 20, 2005 at 07:00:11AM +0200, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3166
> -------------------------------------------------------------------------
>
> Subject: bad target region calculations with i.rectify order=3
>
> Hi,
>
> i.rectify (both 6.0.0, 6.1cvs) is creating rasters with incorrect regions and
> resolutions when doing a 3rd order transform. It works fine with 1st or second
> order transforms. 'i.rectify -c' (or lower order) is needed to get a good
> transform.
>
> Starting with unreferenced simple XY map (PNG imported with r.in.gdal)
> and re-regioned to positive values with r.region, keeping res=1 pixel.
>
> Target location is lat/lon (both wgs84 and none/intl datums fail)
>
> e.g. eastern boundary ends up being +2 degrees east of what it should be,
> resolution is calculated from e-w/cols so that ends up very coarse...
> southern boundary is wrong too.
>
> CRS_georef() in imagery/i.rectify/crs.c ?
>
> more info available upon request.
Hamish,
you may compare with GDAL:
gdal/alg/gdal_crs.c
- is the algorithm identical?
- does gdalwarp produce the same (error)
If GDAL performs better for above operation, its improvements
might be worth backporting.
Markus
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 21 Apr 2005 17:07:59 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Markus Neteler <neteler@itc.it>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it, Frank Warmerdam <fwarmerdam@gmail.com>
|
Subject |
Re: [bug #3166] (grass) bad target region calculations with i.rectify order=3
|
Message-Id |
<20050421170759.5736bfd7.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20050420132510.GC8579@thuille.itc.it>
|
References |
<20050420050011.A14781005DD@lists.intevation.de> <20050420132510.GC8579@thuille.itc.it>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
multipart/mixed; boundary="Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o"
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
This is a multi-part message in MIME format.
--Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=3166
> > -------------------------------------------------------------------
> >
> > Subject: bad target region calculations with i.rectify order=3
[1st and 2nd order work fine]
> >
> > i.rectify (both 6.0.0, 6.1cvs) is creating rasters with incorrect
> > regions and resolutions when doing a 3rd order transform. It works
> > fine with 1st or second order transforms. 'i.rectify -c' (or lower
> > order) is needed to get a good transform.
> >
> > Starting with unreferenced simple XY map (PNG imported with
> > r.in.gdal) and re-regioned to positive values with r.region, keeping
> > res=1 pixel.
> >
> > Target location is lat/lon (both wgs84 and none/intl datums fail)
> >
> > e.g. eastern boundary ends up being +2 degrees east of what it
> > should be, resolution is calculated from e-w/cols so that ends up
> > very coarse... southern boundary is wrong too.
> >
> > CRS_georef() in imagery/i.rectify/crs.c ?
> >
> > more info available upon request.
>
> Hamish,
>
> you may compare with GDAL:
>
> gdal/alg/gdal_crs.c
ok.
> - is the algorithm identical?
I think so.
The CRS_georef() fns are essentially the same (GRASS 6/GDAL 1.2.5).
I have cut the top off of both files to CRS_compute_georef_equations(),
diff -wi attached.. No difference there that I can see.
Note that Frank has some comments in his:
* $Log: gdal_crs.c,v $
[gdal 1.2.6]
+ * Revision 1.8 2004/12/26 16:12:21 fwarmerdam
+ * thin plate spline support now implemented
+ *
[nice..]
* Revision 1.7 2004/08/11 19:01:56 warmerda
* default to 2nd order if we have enough points for 3rd order but 0 requested
*
* Revision 1.6 2004/08/09 14:38:27 warmerda
* added serialize/deserialize support for warpoptions and transformers
*
* Revision 1.5 2004/03/19 15:22:02 warmerda
* Fixed double free of padfRasterX. Submitted by Scott Reynolds.
*
* Revision 1.4 2002/12/07 17:09:50 warmerda
* re-enable 3rd order even though unstable
*
* Revision 1.3 2002/12/06 17:58:00 warmerda
* fix a few bugs
*
* Revision 1.2 2002/12/05 05:46:08 warmerda
* fixed linkage problem
*
* Revision 1.1 2002/12/05 05:43:23 warmerda
* New
which tells us 3rd order is not stable...?
If we can get the inputs out, maybe we can try doing the matrix math
in Matlab/Octave and see what answers it gives... (polyfit() fn.)
> - does gdalwarp produce the same (error)
I am starting with a flat PNG(Tiff) image with no georefencing.
I assume you can use something in GDAL to insert GCPs as defined
in the GRASS group/POINTS file, but not the four corners of the
map - that's where it all goes wrong in i.rectify.
So I don't know how to try gdalwarp on it.
?
> If GDAL performs better for above operation, its improvements
> might be worth backporting.
I think GDAL will have the same.
?
Hamish
--Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o
Content-Type: text/plain;
name="crs.diff"
Content-Disposition: attachment;
filename="crs.diff"
Content-Transfer-Encoding: 7bit
--- irec_crs_crop.c 2005-04-21 16:50:03.000000000 +1200
+++ gdal_crs_crop.c 2005-04-21 16:48:10.000000000 +1200
@@ -4,8 +4,11 @@
*/
/***************************************************************************/
-int
-CRS_compute_georef_equations (struct Control_Points *cp, double E12[], double
N12[], double E21[], double N21[], int order)
+static int
+CRS_compute_georef_equations (struct Control_Points *cp,
+ double E12[], double N12[],
+ double E21[], double N21[],
+ int order)
{
double *tempptr;
int status;
@@ -77,22 +80,22 @@
/* INITIALIZE MATRIX */
- m.v = (DOUBLE *)G_calloc(m.n*m.n,sizeof(DOUBLE));
+ m.v = (double *)CPLCalloc(m.n*m.n,sizeof(double));
if(m.v == NULL)
{
return(MMEMERR);
}
- a = (DOUBLE *)G_calloc(m.n,sizeof(DOUBLE));
+ a = (double *)CPLCalloc(m.n,sizeof(double));
if(a == NULL)
{
- G_free((char *)m.v);
+ CPLFree((char *)m.v);
return(MMEMERR);
}
- b = (DOUBLE *)G_calloc(m.n,sizeof(DOUBLE));
+ b = (double *)CPLCalloc(m.n,sizeof(double));
if(b == NULL)
{
- G_free((char *)m.v);
- G_free((char *)a);
+ CPLFree((char *)m.v);
+ CPLFree((char *)a);
return(MMEMERR);
}
@@ -101,9 +104,9 @@
else
status = calcls(cp,&m,a,b,E,N);
- G_free((char *)m.v);
- G_free((char *)a);
- G_free((char *)b);
+ CPLFree((char *)m.v);
+ CPLFree((char *)a);
+ CPLFree((char *)b);
return(status);
}
--Multipart=_Thu__21_Apr_2005_17_07_59_+1200_I1tsNuLxYLct+J3o--
|
|