1 (edited by m.newluck 2011-08-08 07:19:04)

Topic: GCP Optimization (Cropped ASTER)

Hi

I have some ASTER images which their overlap area is very small. I cropped the raw images to the overlap area before tie point selection. It is because I think it´s not necessary for the whole image to be orthorectified. But I have a problem in GCP optimization step!! the GCPs can´t be optimized and I get NaN value as the coordinates.
Should I try to orthorectify the whole image extent to measure correlation in a small part of image?

any help would greatly appreciated

Thanks
Mohamad

2

Re: GCP Optimization (Cropped ASTER)

Hi,

You shouldn't crop the raw images unless you can also crop the associated metadata. To make a "clean" crop, simply select a spatial subset of the image when you define the orthorectification grid in COSI-Corr.

Cheers,
Sebastien

3

Re: GCP Optimization (Cropped ASTER)

Thanks for your prompt reply, dear Sebastien.
Can I select the tie points just in the overlap area or I have to select them scattered in the image? Which one will improve the accuracy of orthorectification?

4

Re: GCP Optimization (Cropped ASTER)

It is best to select the tie-points well spread over the entire image, but you don't have to run the ortho/resampling over the entire image (unless it's your first image and you also want to select tie points across the whole area for the second image). Anyway, unless you're already an expert in COSI-Corr, I wouldn't recommend only processing a small area from your image. You'll learn a lot by processing the entire image and will better be able to assess the quality of the results. If it's your first time using it, you'll see that interpretation isn't always easy.

Cheers,
Sebastien

5 (edited by m.newluck 2011-08-09 01:29:53)

Re: GCP Optimization (Cropped ASTER)

I can select the tie-points well spread over the entire image, but it can be done just for the first image. For the second one I have to select tie-points in a small part of the image because its overlap area with the first ortho-image is small. doesn't it affect the accuracy of orthorectification of the second image?
I have also some ASTER L1B and Landsat images over that region, is it better to use them instead of hillshade image as the first reference image?

Cheers,
Mohamad

6

Re: GCP Optimization (Cropped ASTER)

Yes, if the tie points of the second image are only concentrated in a small area, that will affect the ortho accuracy of the second image. Think of it as fitting a line y = x with only a few points that are close to the origin. The slope won't be well constrained and the same will happen with your images. If you have small geometrical artifacts or some noise on your GCP, it may be a bit amplified away from the GCP. But of course it all depends on what "small overlap means". Give it a try anyway. If you're careful in choosing tie-points and if you have some nice features to provide accurate correlation, it might work well enough.

Using the shaded DEM as the first image is never very accurate but it's good to make sure that your ortho-images are well registered to the topography. It's important if you have strong topo features in your images. If the image and your DEM aren't well co-registered, you'll be correcting for topo features that are not well located in the images and will introduce topo residuals. If you think your other sources (Landsat or ASTER 1B) are well registered to the topo model you'll be using to create your ortho-ASTER, using them as reference should work. But remember that 1B images are only projected on an ellipsoid and aren't rectified for topography. Therefore, to avoid being too inaccurate, select only tie-points on areas with smooth or flat topography. However, it might just be better not to use any tie-points than using a bad first reference image. That all depends on the accuracy of the ancillary data in your ASTER L1A. As a test, orthorectify your ASTER image without any tie-points or GCP (still use a DEM in the ortho-generation), and try to assess how far the topo-features in this ortho-image are from the features in the shaded DEM. If they're close, maybe you don't really need GCPs for your first image. You can also try to orthorectify both images without any GCP, and see what the registration looks like. Usually the tie-points are necessary between the second and the first image, but the tie-points on the first image can sometimes be neglected, it depends on the accuracy of the L1A metadata in your image, which can vary.

Cheers,
Sebastien

7

Re: GCP Optimization (Cropped ASTER)

Thanks again dear Sebstien

I mean a small area of overlap by the words "small overlap". I mean the common area of two images is just upper-right part of first image and bottom-left part of the second image. their area of overlap is less than 20%.
anyway, I will follow your appreciated advices and will inform you about the results.

Regards,
Mohamad

8 (edited by m.newluck 2011-08-10 02:00:15)

Re: GCP Optimization (Cropped ASTER)

I get an error message which I have never seen before!!!! when I want to do orthorectification I get an error message that says:

>>
GUI_MAIN_ORTHORESAMP: MAPGRID: A map projection must exist or be specified as a scalar string.

Traceback Report from GUI_MAIN_ORTHORESAMP

%MAPGRID: A map projection must exist or be specified as a scalar string.
%Execution halted at: MAPGRID
%                                 GUI_SAT_ORTHORECTIFICATION_EVENT
%                                 XMANAGER_EVLOOP_STANDARD
%                                 XMANAGER
%                                 GUI_MAIN_ORTHORESAMP
%                                 MAIN_ORTHORESAMP
%                                 COSI_CORR_EVENT
%                                 IDLRTMAIN
%                                 $MAIN$
>>

It doesn't depends on if GCPs are used or not. In both situation I get this error message! I tried SRTM and ASTER DEMs both in UTM projection and error still remains. Would you please help me with this problem?

Regards,
Mohamad

9

Re: GCP Optimization (Cropped ASTER)

Do you get the error just when the ortho-rectification process starts? Did the GCP optimization run successfully?
Are the resampling matrices produced?
What if you don't give any DEM as input?
How do you define the ortho-grid in the orthorectification window? You have 3 choices:
- From raw image
- From georeferenced image
- Manual edit

Sebastien

10 (edited by m.newluck 2011-08-12 06:22:31)

Re: GCP Optimization (Cropped ASTER)

Hi Sebastien

It was a problem with ENVI 4.8! I think Cosi-corr is not compatible with this version of Envi. I used Envi 4.7 and problem solved. Using Envi 4.8 the error message was appearing in all scenarios, I mean if I used GCPs and DEM or not. It was also appeared when I used each method of definition of ortho-grid.
Anyway, I orthorectified the first image using just DEM without GCPs and then to precisely coregister the second image I choosed 9 tie points well spread on the common area of two images. Results of GCP optimization are here:

GCPS optimization report:
;GCP / Easting misregistration (meter) / Northing Misregistration (meter)
;     1     4.780454    -1.827193
;     2    -5.323343    -2.238490
;     3     0.236457     0.163801
;     4     3.831508     3.097527
;     5     2.003073     0.529923
;     6     7.016781    -2.718385
;     7   -10.388031    -0.436438
;     8    -1.091563    -1.429172
;     9    -0.614701     5.007494
;Easting mis-registration in meters (Average / Standard Deviation):      0.0577948     5.0395716
;Northing mis-registration in meters (Average / Standard Deviation):      0.0159609     2.4243506
;Norm mis-registration in meters (Average / Standard Deviation):      0.0599583     5.5923840
;
;Files:
;- Image: /misc/xx10/mohamad/ASTER_Source/prdat0122.dat.hdf
;- Reference Image: /misc/xx10/mohamad/010227_020122/Ortho1
;- DEM: /misc/xx10/mohamad/DEM/AST_DEM_15m
;- Ancillary file: /misc/xx10/mohamad/010227_020122/anc2.anc
;- GCPS/Tied Points/ICP file: /misc/xx10/mohamad/010227_020122/GCP2.txt
;
;Resampling: Sinc
;Correlator: Frequency
;- Window Size X Initial: 64 Final: 32
;- Window Size Y Initial: 64 Final: 32
;- Mask Treshold:0.900000
;- Nb Robust Iteration:4
;- Resampling:0
;Easting ouput pixel size (meter):  15.00
;Northing ouput pixel size (meter):  15.00
;
;Convergence quality report:
;Loop number, Avg x, Avg y, Norm Avg xy, Stdev x, Stdev y, Norm Stdev xy
;     1     0.268477     0.148427     0.306774     5.106358     2.425538     5.653152
;     2    -0.005138    -0.024054     0.024597     5.037530     2.424659     5.590678
;     3     0.060565     0.021650     0.064318     5.039995     2.424824     5.592971
;     4     0.061033     0.017020     0.063362     5.039783     2.424388     5.592590
;     5     0.057795     0.015961     0.059958     5.039572     2.424351     5.592384


I think the results are reasonable for ASTER images. aren't they?

Cheers,
Mohamad

11

Re: GCP Optimization (Cropped ASTER)

Hi Mohamad,

The results do look quite good for ASTER images. I would generally recommend using larger windows for the optimization. For the optimization, you don't have to use multiscale, a simple scale at 128 or 256 pixel is usually quite good.

Regarding compatibility issues, that's weird. We're using ENVI 4.8 all the time and have never seen this pb. Are your under Windows, Mac, or Linux? There are a few bugs in ENVI 4.8 regarding some geographical projections. Maybe your images are between two UTM zones and ENVI gets lost? Anyway, we'd like to investigate the pb. Would you mind sending me your ancillary file? I'll run some tests, we should know whether it's a compatibility issue or an ENVI bug.

Cheers,
Sebastien

12

Re: GCP Optimization (Cropped ASTER)

You are right Sebasien. My DEM is between two UTM zones. I'll send you ancillary file by email.

Cheers,
Mohamad

13

Re: GCP Optimization (Cropped ASTER)

Hi Mohamad,

I ran couple tests with different versions of ENVI and my conclusion thus far is that ENVI 4.7 works fine, 4.8 32-bit works fine, but I'm seeing some weird things in the ENVI 4.8 64 bits. On a first look it seems that the coordinate conversion function may be the pb, and if that's the case, since we're using the IDL built-in function, I'm not sure there's a lot we can do. We'll continue investigating, tks for letting us know.

Cheers,
Sebastien