Correlation plugin does not recognize southern UTM

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Correlation plugin does not recognize southern UTM

Hernán De Angelis
Hi guys!

It's me again with problems of the same sort (please do not hate me!).
I have a bunch of images in UTM 18S which I want to registrate to one
reference image. I did some quick and dirty experiments with
correl/modopt/rejout some months ago and I was delighted with the
results. Now I wanted to do it properly. After Garrett's fix two days
ago these images can be now displayed correctly in imagelinker but I
noticed that "correl" is also screwing up the UTM South projection.
Luckily I spared some tie point xml files from my old experiments and
saw that applying modopt to those files still makes good results. So I
looked into correl's results and what I found is that the
difftiepts.txt file reports the wrong hemisfere, making a wrong
tiepts.xml file and thus introducing a problem into the geom file
produced by modopt.

I also noticed that executing correl always produces the following
complain at the end:

ossimCommon.cpp:99
Unhandled scalar type:  0
ossimCommon.cpp:159
Unhandled scalar type:  0
ossimCommon.cpp:99
Unhandled scalar type:  0
ossimCommon.cpp:159
Unhandled scalar type:  0


Below I paste the information given by image_info on both images and
the output of correl:


IMAGE_INFO:

Description:
class_name:  ossimTiffTileSource
enabled:  1
entry:  0
file_type:  TIFF
image0.band0.max_value:  255.000000000000000
image0.band0.min_value:  1.000000000000000
image0.band0.null_value:  0.000000000000000
image0.band1.max_value:  255.000000000000000
image0.band1.min_value:  1.000000000000000
image0.band1.null_value:  0.000000000000000
image0.band2.max_value:  255.000000000000000
image0.band2.min_value:  1.000000000000000
image0.band2.null_value:  0.000000000000000
image0.central_meridian:  -75.000000000000000
image0.datum:  WGE
image0.elevation_lookup_flag:  1
image0.ellipse_code:  WE
image0.ellipse_name:  WGS 84
image0.entry:  0
image0.false_easting_northing:  ( 500000.000000000000000,
10000000.000000000000000 )
image0.false_easting_northing_units:  meters
image0.hemisphere:  S
image0.ll_lat:  -48.968788450835120
image0.ll_lon:  -72.655728311733583
image0.lr_lat:  -48.953542612214051
image0.lr_lon:  -71.998242520912868
image0.lr_x:  3212.000000000000000
image0.lr_y:  5394.000000000000000
image0.major_axis:  6378137.000000000000000
image0.minor_axis:  6356752.314199999906123
image0.number_input_bands:  3
image0.number_lines:  5395.000000000000000
image0.number_output_bands:  3
image0.number_samples:  3213.000000000000000
image0.origin_latitude:  0.000000000000000
image0.pixel_scale_units:  meters
image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
image0.radiometry:  8-bit
image0.tie_point_units:  meters
image0.tie_point_xy:  ( 671566.500000000000000, 4654275.500000000000000 )
image0.type:  ossimUtmProjection
image0.ul_lat:  -48.241504234006257
image0.ul_lon:  -72.689166817043144
image0.ul_x:  0.000000000000000
image0.ul_y:  0.000000000000000
image0.ur_lat:  -48.226640960629410
image0.ur_lon:  -72.041029431527008
image0.zone:  18
number_entries:  1


DIFFTIEPTS.TXT:

central_meridian: -75.000000000000000
datum: WGE
elevation_lookup_flag: 1
ellipse_code: WE
ellipse_name: WGS 84
false_easting_northing: ( 500000.000000000000000, 0.000000000000000 )
false_easting_northing_units: meters
hemisphere: N
major_axis: 6378137.000000000000000
minor_axis: 6356752.314199999906123
origin_latitude: 0.000000000000000
pixel_scale_units: meters
pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
tie_point_units: meters
tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
type: ossimUtmProjection
zone: 18
68.000000000000000 666711.000000000000000 9.000000000000000 4.000000000000000 0.921372054978033
125.000000000000000 666700.000000000000000 10.000000000000000 6.000000000000000 0.926256942020091
349.000000000000000 666697.000000000000000 10.000000000000000 6.000000000000000 0.955136745663088
343.000000000000000 666710.000000000000000 10.000000000000000 5.000000000000000 0.931595123368421
430.000000000000000 666704.000000000000000 11.000000000000000 5.000000000000000 0.958003218739443
........................................................


Is this too hard to fix?


Hernán




--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Garrett Potts
Hello:

Just a quick question while I am looking,  are both images UTM S or  
within the Souther hemisphere?

Take care

Garrett

On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:

> Hi guys!
>
> It's me again with problems of the same sort (please do not hate me!).
> I have a bunch of images in UTM 18S which I want to registrate to one
> reference image. I did some quick and dirty experiments with
> correl/modopt/rejout some months ago and I was delighted with the
> results. Now I wanted to do it properly. After Garrett's fix two days
> ago these images can be now displayed correctly in imagelinker but I
> noticed that "correl" is also screwing up the UTM South projection.
> Luckily I spared some tie point xml files from my old experiments and
> saw that applying modopt to those files still makes good results. So I
> looked into correl's results and what I found is that the
> difftiepts.txt file reports the wrong hemisfere, making a wrong
> tiepts.xml file and thus introducing a problem into the geom file
> produced by modopt.
>
> I also noticed that executing correl always produces the following
> complain at the end:
>
> ossimCommon.cpp:99
> Unhandled scalar type:  0
> ossimCommon.cpp:159
> Unhandled scalar type:  0
> ossimCommon.cpp:99
> Unhandled scalar type:  0
> ossimCommon.cpp:159
> Unhandled scalar type:  0
>
>
> Below I paste the information given by image_info on both images and
> the output of correl:
>
>
> IMAGE_INFO:
>
> Description:
> class_name:  ossimTiffTileSource
> enabled:  1
> entry:  0
> file_type:  TIFF
> image0.band0.max_value:  255.000000000000000
> image0.band0.min_value:  1.000000000000000
> image0.band0.null_value:  0.000000000000000
> image0.band1.max_value:  255.000000000000000
> image0.band1.min_value:  1.000000000000000
> image0.band1.null_value:  0.000000000000000
> image0.band2.max_value:  255.000000000000000
> image0.band2.min_value:  1.000000000000000
> image0.band2.null_value:  0.000000000000000
> image0.central_meridian:  -75.000000000000000
> image0.datum:  WGE
> image0.elevation_lookup_flag:  1
> image0.ellipse_code:  WE
> image0.ellipse_name:  WGS 84
> image0.entry:  0
> image0.false_easting_northing:  ( 500000.000000000000000,
> 10000000.000000000000000 )
> image0.false_easting_northing_units:  meters
> image0.hemisphere:  S
> image0.ll_lat:  -48.968788450835120
> image0.ll_lon:  -72.655728311733583
> image0.lr_lat:  -48.953542612214051
> image0.lr_lon:  -71.998242520912868
> image0.lr_x:  3212.000000000000000
> image0.lr_y:  5394.000000000000000
> image0.major_axis:  6378137.000000000000000
> image0.minor_axis:  6356752.314199999906123
> image0.number_input_bands:  3
> image0.number_lines:  5395.000000000000000
> image0.number_output_bands:  3
> image0.number_samples:  3213.000000000000000
> image0.origin_latitude:  0.000000000000000
> image0.pixel_scale_units:  meters
> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
> image0.radiometry:  8-bit
> image0.tie_point_units:  meters
> image0.tie_point_xy:  ( 671566.500000000000000,  
> 4654275.500000000000000 )
> image0.type:  ossimUtmProjection
> image0.ul_lat:  -48.241504234006257
> image0.ul_lon:  -72.689166817043144
> image0.ul_x:  0.000000000000000
> image0.ul_y:  0.000000000000000
> image0.ur_lat:  -48.226640960629410
> image0.ur_lon:  -72.041029431527008
> image0.zone:  18
> number_entries:  1
>
>
> DIFFTIEPTS.TXT:
>
> central_meridian: -75.000000000000000
> datum: WGE
> elevation_lookup_flag: 1
> ellipse_code: WE
> ellipse_name: WGS 84
> false_easting_northing: ( 500000.000000000000000, 0.000000000000000 )
> false_easting_northing_units: meters
> hemisphere: N
> major_axis: 6378137.000000000000000
> minor_axis: 6356752.314199999906123
> origin_latitude: 0.000000000000000
> pixel_scale_units: meters
> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
> tie_point_units: meters
> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
> type: ossimUtmProjection
> zone: 18
> 68.000000000000000 666711.000000000000000 9.000000000000000
> 4.000000000000000 0.921372054978033
> 125.000000000000000 666700.000000000000000 10.000000000000000
> 6.000000000000000 0.926256942020091
> 349.000000000000000 666697.000000000000000 10.000000000000000
> 6.000000000000000 0.955136745663088
> 343.000000000000000 666710.000000000000000 10.000000000000000
> 5.000000000000000 0.931595123368421
> 430.000000000000000 666704.000000000000000 11.000000000000000
> 5.000000000000000 0.958003218739443
> ........................................................
>
>
> Is this too hard to fix?
>
>
> Hernán
>
>
>
>
> --
>
> Hernán De Angelis
> Linux user # 397217
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Garrett Potts
Hello:

Could you try to test the latest svn now?

Take care

Garrett

On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:

> Hi Garrett,
>
> Both images are UTM S. I am sending to you reduced resolution images.
>
> Hernán
>
>
> 2008/8/20 Garrett Potts <[hidden email]>:
>> Hello:
>>
>> Just a quick question while I am looking,  are both images UTM S or
>> within the Souther hemisphere?
>>
>> Take care
>>
>> Garrett
>>
>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>
>>> Hi guys!
>>>
>>> It's me again with problems of the same sort (please do not hate  
>>> me!).
>>> I have a bunch of images in UTM 18S which I want to registrate to  
>>> one
>>> reference image. I did some quick and dirty experiments with
>>> correl/modopt/rejout some months ago and I was delighted with the
>>> results. Now I wanted to do it properly. After Garrett's fix two  
>>> days
>>> ago these images can be now displayed correctly in imagelinker but I
>>> noticed that "correl" is also screwing up the UTM South projection.
>>> Luckily I spared some tie point xml files from my old experiments  
>>> and
>>> saw that applying modopt to those files still makes good results.  
>>> So I
>>> looked into correl's results and what I found is that the
>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>> tiepts.xml file and thus introducing a problem into the geom file
>>> produced by modopt.
>>>
>>> I also noticed that executing correl always produces the following
>>> complain at the end:
>>>
>>> ossimCommon.cpp:99
>>> Unhandled scalar type:  0
>>> ossimCommon.cpp:159
>>> Unhandled scalar type:  0
>>> ossimCommon.cpp:99
>>> Unhandled scalar type:  0
>>> ossimCommon.cpp:159
>>> Unhandled scalar type:  0
>>>
>>>
>>> Below I paste the information given by image_info on both images and
>>> the output of correl:
>>>
>>>
>>> IMAGE_INFO:
>>>
>>> Description:
>>> class_name:  ossimTiffTileSource
>>> enabled:  1
>>> entry:  0
>>> file_type:  TIFF
>>> image0.band0.max_value:  255.000000000000000
>>> image0.band0.min_value:  1.000000000000000
>>> image0.band0.null_value:  0.000000000000000
>>> image0.band1.max_value:  255.000000000000000
>>> image0.band1.min_value:  1.000000000000000
>>> image0.band1.null_value:  0.000000000000000
>>> image0.band2.max_value:  255.000000000000000
>>> image0.band2.min_value:  1.000000000000000
>>> image0.band2.null_value:  0.000000000000000
>>> image0.central_meridian:  -75.000000000000000
>>> image0.datum:  WGE
>>> image0.elevation_lookup_flag:  1
>>> image0.ellipse_code:  WE
>>> image0.ellipse_name:  WGS 84
>>> image0.entry:  0
>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>> 10000000.000000000000000 )
>>> image0.false_easting_northing_units:  meters
>>> image0.hemisphere:  S
>>> image0.ll_lat:  -48.968788450835120
>>> image0.ll_lon:  -72.655728311733583
>>> image0.lr_lat:  -48.953542612214051
>>> image0.lr_lon:  -71.998242520912868
>>> image0.lr_x:  3212.000000000000000
>>> image0.lr_y:  5394.000000000000000
>>> image0.major_axis:  6378137.000000000000000
>>> image0.minor_axis:  6356752.314199999906123
>>> image0.number_input_bands:  3
>>> image0.number_lines:  5395.000000000000000
>>> image0.number_output_bands:  3
>>> image0.number_samples:  3213.000000000000000
>>> image0.origin_latitude:  0.000000000000000
>>> image0.pixel_scale_units:  meters
>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>> image0.radiometry:  8-bit
>>> image0.tie_point_units:  meters
>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>> 4654275.500000000000000 )
>>> image0.type:  ossimUtmProjection
>>> image0.ul_lat:  -48.241504234006257
>>> image0.ul_lon:  -72.689166817043144
>>> image0.ul_x:  0.000000000000000
>>> image0.ul_y:  0.000000000000000
>>> image0.ur_lat:  -48.226640960629410
>>> image0.ur_lon:  -72.041029431527008
>>> image0.zone:  18
>>> number_entries:  1
>>>
>>>
>>> DIFFTIEPTS.TXT:
>>>
>>> central_meridian: -75.000000000000000
>>> datum: WGE
>>> elevation_lookup_flag: 1
>>> ellipse_code: WE
>>> ellipse_name: WGS 84
>>> false_easting_northing: ( 500000.000000000000000,  
>>> 0.000000000000000 )
>>> false_easting_northing_units: meters
>>> hemisphere: N
>>> major_axis: 6378137.000000000000000
>>> minor_axis: 6356752.314199999906123
>>> origin_latitude: 0.000000000000000
>>> pixel_scale_units: meters
>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>> tie_point_units: meters
>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>> type: ossimUtmProjection
>>> zone: 18
>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>> 4.000000000000000     0.921372054978033
>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>> 6.000000000000000     0.926256942020091
>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>> 6.000000000000000     0.955136745663088
>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>> 5.000000000000000     0.931595123368421
>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>> 5.000000000000000     0.958003218739443
>>> ........................................................
>>>
>>>
>>> Is this too hard to fix?
>>>
>>>
>>> Hernán
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Hernán De Angelis
>>> Linux user # 397217
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> www.ossim.org
>>> Ossim-developer mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>
>
>
>
> --
>
> Hernán De Angelis
> Linux user # 397217
> <1984r.tif><2001r.tif>


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Hernán De Angelis
Hi garrett,

I tried one image and seems to be working fine. Thanks again!

I just wonder what the garbage at the end means:

ossimCommon.cpp:99
Unhandled scalar type:  0
ossimCommon.cpp:159
Unhandled scalar type:  0
ossimCommon.cpp:99
Unhandled scalar type:  0
ossimCommon.cpp:159
Unhandled scalar type:  0


Hernán



2008/8/20 Garrett Potts <[hidden email]>:

> Hello:
>
> Could you try to test the latest svn now?
>
> Take care
>
> Garrett
>
> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>
>> Hi Garrett,
>>
>> Both images are UTM S. I am sending to you reduced resolution images.
>>
>> Hernán
>>
>>
>> 2008/8/20 Garrett Potts <[hidden email]>:
>>> Hello:
>>>
>>> Just a quick question while I am looking,  are both images UTM S or
>>> within the Souther hemisphere?
>>>
>>> Take care
>>>
>>> Garrett
>>>
>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>
>>>> Hi guys!
>>>>
>>>> It's me again with problems of the same sort (please do not hate
>>>> me!).
>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>> one
>>>> reference image. I did some quick and dirty experiments with
>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>> days
>>>> ago these images can be now displayed correctly in imagelinker but I
>>>> noticed that "correl" is also screwing up the UTM South projection.
>>>> Luckily I spared some tie point xml files from my old experiments
>>>> and
>>>> saw that applying modopt to those files still makes good results.
>>>> So I
>>>> looked into correl's results and what I found is that the
>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>> produced by modopt.
>>>>
>>>> I also noticed that executing correl always produces the following
>>>> complain at the end:
>>>>
>>>> ossimCommon.cpp:99
>>>> Unhandled scalar type:  0
>>>> ossimCommon.cpp:159
>>>> Unhandled scalar type:  0
>>>> ossimCommon.cpp:99
>>>> Unhandled scalar type:  0
>>>> ossimCommon.cpp:159
>>>> Unhandled scalar type:  0
>>>>
>>>>
>>>> Below I paste the information given by image_info on both images and
>>>> the output of correl:
>>>>
>>>>
>>>> IMAGE_INFO:
>>>>
>>>> Description:
>>>> class_name:  ossimTiffTileSource
>>>> enabled:  1
>>>> entry:  0
>>>> file_type:  TIFF
>>>> image0.band0.max_value:  255.000000000000000
>>>> image0.band0.min_value:  1.000000000000000
>>>> image0.band0.null_value:  0.000000000000000
>>>> image0.band1.max_value:  255.000000000000000
>>>> image0.band1.min_value:  1.000000000000000
>>>> image0.band1.null_value:  0.000000000000000
>>>> image0.band2.max_value:  255.000000000000000
>>>> image0.band2.min_value:  1.000000000000000
>>>> image0.band2.null_value:  0.000000000000000
>>>> image0.central_meridian:  -75.000000000000000
>>>> image0.datum:  WGE
>>>> image0.elevation_lookup_flag:  1
>>>> image0.ellipse_code:  WE
>>>> image0.ellipse_name:  WGS 84
>>>> image0.entry:  0
>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>> 10000000.000000000000000 )
>>>> image0.false_easting_northing_units:  meters
>>>> image0.hemisphere:  S
>>>> image0.ll_lat:  -48.968788450835120
>>>> image0.ll_lon:  -72.655728311733583
>>>> image0.lr_lat:  -48.953542612214051
>>>> image0.lr_lon:  -71.998242520912868
>>>> image0.lr_x:  3212.000000000000000
>>>> image0.lr_y:  5394.000000000000000
>>>> image0.major_axis:  6378137.000000000000000
>>>> image0.minor_axis:  6356752.314199999906123
>>>> image0.number_input_bands:  3
>>>> image0.number_lines:  5395.000000000000000
>>>> image0.number_output_bands:  3
>>>> image0.number_samples:  3213.000000000000000
>>>> image0.origin_latitude:  0.000000000000000
>>>> image0.pixel_scale_units:  meters
>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>> image0.radiometry:  8-bit
>>>> image0.tie_point_units:  meters
>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>> 4654275.500000000000000 )
>>>> image0.type:  ossimUtmProjection
>>>> image0.ul_lat:  -48.241504234006257
>>>> image0.ul_lon:  -72.689166817043144
>>>> image0.ul_x:  0.000000000000000
>>>> image0.ul_y:  0.000000000000000
>>>> image0.ur_lat:  -48.226640960629410
>>>> image0.ur_lon:  -72.041029431527008
>>>> image0.zone:  18
>>>> number_entries:  1
>>>>
>>>>
>>>> DIFFTIEPTS.TXT:
>>>>
>>>> central_meridian: -75.000000000000000
>>>> datum: WGE
>>>> elevation_lookup_flag: 1
>>>> ellipse_code: WE
>>>> ellipse_name: WGS 84
>>>> false_easting_northing: ( 500000.000000000000000,
>>>> 0.000000000000000 )
>>>> false_easting_northing_units: meters
>>>> hemisphere: N
>>>> major_axis: 6378137.000000000000000
>>>> minor_axis: 6356752.314199999906123
>>>> origin_latitude: 0.000000000000000
>>>> pixel_scale_units: meters
>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>> tie_point_units: meters
>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>> type: ossimUtmProjection
>>>> zone: 18
>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>> 4.000000000000000     0.921372054978033
>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>> 6.000000000000000     0.926256942020091
>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>> 6.000000000000000     0.955136745663088
>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>> 5.000000000000000     0.931595123368421
>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>> 5.000000000000000     0.958003218739443
>>>> ........................................................
>>>>
>>>>
>>>> Is this too hard to fix?
>>>>
>>>>
>>>> Hernán
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Hernán De Angelis
>>>> Linux user # 397217
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> www.ossim.org
>>>> Ossim-developer mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> www.ossim.org
>>> Ossim-developer mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>
>>
>>
>>
>> --
>>
>> Hernán De Angelis
>> Linux user # 397217
>> <1984r.tif><2001r.tif>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Garrett Potts
Hello :

Hmmm, not completely sure.  That equates to OSSIM_SCALAR_UNKNOWN and  
something may e executing before a full connection which is ok when  
initializing and setting up initial connections for some chains may  
not have a connection yet to valid source inputs.


Take care

Garrett

On Aug 20, 2008, at 9:49 AM, Hernán De Angelis wrote:

> Hi garrett,
>
> I tried one image and seems to be working fine. Thanks again!
>
> I just wonder what the garbage at the end means:
>
> ossimCommon.cpp:99
> Unhandled scalar type:  0
> ossimCommon.cpp:159
> Unhandled scalar type:  0
> ossimCommon.cpp:99
> Unhandled scalar type:  0
> ossimCommon.cpp:159
> Unhandled scalar type:  0
>
>
> Hernán
>
>
>
> 2008/8/20 Garrett Potts <[hidden email]>:
>> Hello:
>>
>> Could you try to test the latest svn now?
>>
>> Take care
>>
>> Garrett
>>
>> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>>
>>> Hi Garrett,
>>>
>>> Both images are UTM S. I am sending to you reduced resolution  
>>> images.
>>>
>>> Hernán
>>>
>>>
>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>> Hello:
>>>>
>>>> Just a quick question while I am looking,  are both images UTM S or
>>>> within the Souther hemisphere?
>>>>
>>>> Take care
>>>>
>>>> Garrett
>>>>
>>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>>
>>>>> Hi guys!
>>>>>
>>>>> It's me again with problems of the same sort (please do not hate
>>>>> me!).
>>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>>> one
>>>>> reference image. I did some quick and dirty experiments with
>>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>>> days
>>>>> ago these images can be now displayed correctly in imagelinker  
>>>>> but I
>>>>> noticed that "correl" is also screwing up the UTM South  
>>>>> projection.
>>>>> Luckily I spared some tie point xml files from my old experiments
>>>>> and
>>>>> saw that applying modopt to those files still makes good results.
>>>>> So I
>>>>> looked into correl's results and what I found is that the
>>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>>> produced by modopt.
>>>>>
>>>>> I also noticed that executing correl always produces the following
>>>>> complain at the end:
>>>>>
>>>>> ossimCommon.cpp:99
>>>>> Unhandled scalar type:  0
>>>>> ossimCommon.cpp:159
>>>>> Unhandled scalar type:  0
>>>>> ossimCommon.cpp:99
>>>>> Unhandled scalar type:  0
>>>>> ossimCommon.cpp:159
>>>>> Unhandled scalar type:  0
>>>>>
>>>>>
>>>>> Below I paste the information given by image_info on both images  
>>>>> and
>>>>> the output of correl:
>>>>>
>>>>>
>>>>> IMAGE_INFO:
>>>>>
>>>>> Description:
>>>>> class_name:  ossimTiffTileSource
>>>>> enabled:  1
>>>>> entry:  0
>>>>> file_type:  TIFF
>>>>> image0.band0.max_value:  255.000000000000000
>>>>> image0.band0.min_value:  1.000000000000000
>>>>> image0.band0.null_value:  0.000000000000000
>>>>> image0.band1.max_value:  255.000000000000000
>>>>> image0.band1.min_value:  1.000000000000000
>>>>> image0.band1.null_value:  0.000000000000000
>>>>> image0.band2.max_value:  255.000000000000000
>>>>> image0.band2.min_value:  1.000000000000000
>>>>> image0.band2.null_value:  0.000000000000000
>>>>> image0.central_meridian:  -75.000000000000000
>>>>> image0.datum:  WGE
>>>>> image0.elevation_lookup_flag:  1
>>>>> image0.ellipse_code:  WE
>>>>> image0.ellipse_name:  WGS 84
>>>>> image0.entry:  0
>>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>>> 10000000.000000000000000 )
>>>>> image0.false_easting_northing_units:  meters
>>>>> image0.hemisphere:  S
>>>>> image0.ll_lat:  -48.968788450835120
>>>>> image0.ll_lon:  -72.655728311733583
>>>>> image0.lr_lat:  -48.953542612214051
>>>>> image0.lr_lon:  -71.998242520912868
>>>>> image0.lr_x:  3212.000000000000000
>>>>> image0.lr_y:  5394.000000000000000
>>>>> image0.major_axis:  6378137.000000000000000
>>>>> image0.minor_axis:  6356752.314199999906123
>>>>> image0.number_input_bands:  3
>>>>> image0.number_lines:  5395.000000000000000
>>>>> image0.number_output_bands:  3
>>>>> image0.number_samples:  3213.000000000000000
>>>>> image0.origin_latitude:  0.000000000000000
>>>>> image0.pixel_scale_units:  meters
>>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>>> image0.radiometry:  8-bit
>>>>> image0.tie_point_units:  meters
>>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>>> 4654275.500000000000000 )
>>>>> image0.type:  ossimUtmProjection
>>>>> image0.ul_lat:  -48.241504234006257
>>>>> image0.ul_lon:  -72.689166817043144
>>>>> image0.ul_x:  0.000000000000000
>>>>> image0.ul_y:  0.000000000000000
>>>>> image0.ur_lat:  -48.226640960629410
>>>>> image0.ur_lon:  -72.041029431527008
>>>>> image0.zone:  18
>>>>> number_entries:  1
>>>>>
>>>>>
>>>>> DIFFTIEPTS.TXT:
>>>>>
>>>>> central_meridian: -75.000000000000000
>>>>> datum: WGE
>>>>> elevation_lookup_flag: 1
>>>>> ellipse_code: WE
>>>>> ellipse_name: WGS 84
>>>>> false_easting_northing: ( 500000.000000000000000,
>>>>> 0.000000000000000 )
>>>>> false_easting_northing_units: meters
>>>>> hemisphere: N
>>>>> major_axis: 6378137.000000000000000
>>>>> minor_axis: 6356752.314199999906123
>>>>> origin_latitude: 0.000000000000000
>>>>> pixel_scale_units: meters
>>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>>> tie_point_units: meters
>>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>>> type: ossimUtmProjection
>>>>> zone: 18
>>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>>> 4.000000000000000     0.921372054978033
>>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>>> 6.000000000000000     0.926256942020091
>>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>>> 6.000000000000000     0.955136745663088
>>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>>> 5.000000000000000     0.931595123368421
>>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>>> 5.000000000000000     0.958003218739443
>>>>> ........................................................
>>>>>
>>>>>
>>>>> Is this too hard to fix?
>>>>>
>>>>>
>>>>> Hernán
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Hernán De Angelis
>>>>> Linux user # 397217
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> www.ossim.org
>>>>> Ossim-developer mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> www.ossim.org
>>>> Ossim-developer mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Hernán De Angelis
>>> Linux user # 397217
>>> <1984r.tif><2001r.tif>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>
>
>
>
> --
>
> Hernán De Angelis
> Linux user # 397217
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Hernán De Angelis
OK. Hopefuly is not a sign of something serious.

Thanks again Garrett!


Hernán



2008/8/20 Garrett Potts <[hidden email]>:

> Hello :
>
> Hmmm, not completely sure.  That equates to OSSIM_SCALAR_UNKNOWN and
> something may e executing before a full connection which is ok when
> initializing and setting up initial connections for some chains may
> not have a connection yet to valid source inputs.
>
>
> Take care
>
> Garrett
>
> On Aug 20, 2008, at 9:49 AM, Hernán De Angelis wrote:
>
>> Hi garrett,
>>
>> I tried one image and seems to be working fine. Thanks again!
>>
>> I just wonder what the garbage at the end means:
>>
>> ossimCommon.cpp:99
>> Unhandled scalar type:  0
>> ossimCommon.cpp:159
>> Unhandled scalar type:  0
>> ossimCommon.cpp:99
>> Unhandled scalar type:  0
>> ossimCommon.cpp:159
>> Unhandled scalar type:  0
>>
>>
>> Hernán
>>
>>
>>
>> 2008/8/20 Garrett Potts <[hidden email]>:
>>> Hello:
>>>
>>> Could you try to test the latest svn now?
>>>
>>> Take care
>>>
>>> Garrett
>>>
>>> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>>>
>>>> Hi Garrett,
>>>>
>>>> Both images are UTM S. I am sending to you reduced resolution
>>>> images.
>>>>
>>>> Hernán
>>>>
>>>>
>>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>>> Hello:
>>>>>
>>>>> Just a quick question while I am looking,  are both images UTM S or
>>>>> within the Souther hemisphere?
>>>>>
>>>>> Take care
>>>>>
>>>>> Garrett
>>>>>
>>>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>>>
>>>>>> Hi guys!
>>>>>>
>>>>>> It's me again with problems of the same sort (please do not hate
>>>>>> me!).
>>>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>>>> one
>>>>>> reference image. I did some quick and dirty experiments with
>>>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>>>> days
>>>>>> ago these images can be now displayed correctly in imagelinker
>>>>>> but I
>>>>>> noticed that "correl" is also screwing up the UTM South
>>>>>> projection.
>>>>>> Luckily I spared some tie point xml files from my old experiments
>>>>>> and
>>>>>> saw that applying modopt to those files still makes good results.
>>>>>> So I
>>>>>> looked into correl's results and what I found is that the
>>>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>>>> produced by modopt.
>>>>>>
>>>>>> I also noticed that executing correl always produces the following
>>>>>> complain at the end:
>>>>>>
>>>>>> ossimCommon.cpp:99
>>>>>> Unhandled scalar type:  0
>>>>>> ossimCommon.cpp:159
>>>>>> Unhandled scalar type:  0
>>>>>> ossimCommon.cpp:99
>>>>>> Unhandled scalar type:  0
>>>>>> ossimCommon.cpp:159
>>>>>> Unhandled scalar type:  0
>>>>>>
>>>>>>
>>>>>> Below I paste the information given by image_info on both images
>>>>>> and
>>>>>> the output of correl:
>>>>>>
>>>>>>
>>>>>> IMAGE_INFO:
>>>>>>
>>>>>> Description:
>>>>>> class_name:  ossimTiffTileSource
>>>>>> enabled:  1
>>>>>> entry:  0
>>>>>> file_type:  TIFF
>>>>>> image0.band0.max_value:  255.000000000000000
>>>>>> image0.band0.min_value:  1.000000000000000
>>>>>> image0.band0.null_value:  0.000000000000000
>>>>>> image0.band1.max_value:  255.000000000000000
>>>>>> image0.band1.min_value:  1.000000000000000
>>>>>> image0.band1.null_value:  0.000000000000000
>>>>>> image0.band2.max_value:  255.000000000000000
>>>>>> image0.band2.min_value:  1.000000000000000
>>>>>> image0.band2.null_value:  0.000000000000000
>>>>>> image0.central_meridian:  -75.000000000000000
>>>>>> image0.datum:  WGE
>>>>>> image0.elevation_lookup_flag:  1
>>>>>> image0.ellipse_code:  WE
>>>>>> image0.ellipse_name:  WGS 84
>>>>>> image0.entry:  0
>>>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>>>> 10000000.000000000000000 )
>>>>>> image0.false_easting_northing_units:  meters
>>>>>> image0.hemisphere:  S
>>>>>> image0.ll_lat:  -48.968788450835120
>>>>>> image0.ll_lon:  -72.655728311733583
>>>>>> image0.lr_lat:  -48.953542612214051
>>>>>> image0.lr_lon:  -71.998242520912868
>>>>>> image0.lr_x:  3212.000000000000000
>>>>>> image0.lr_y:  5394.000000000000000
>>>>>> image0.major_axis:  6378137.000000000000000
>>>>>> image0.minor_axis:  6356752.314199999906123
>>>>>> image0.number_input_bands:  3
>>>>>> image0.number_lines:  5395.000000000000000
>>>>>> image0.number_output_bands:  3
>>>>>> image0.number_samples:  3213.000000000000000
>>>>>> image0.origin_latitude:  0.000000000000000
>>>>>> image0.pixel_scale_units:  meters
>>>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>>>> image0.radiometry:  8-bit
>>>>>> image0.tie_point_units:  meters
>>>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>>>> 4654275.500000000000000 )
>>>>>> image0.type:  ossimUtmProjection
>>>>>> image0.ul_lat:  -48.241504234006257
>>>>>> image0.ul_lon:  -72.689166817043144
>>>>>> image0.ul_x:  0.000000000000000
>>>>>> image0.ul_y:  0.000000000000000
>>>>>> image0.ur_lat:  -48.226640960629410
>>>>>> image0.ur_lon:  -72.041029431527008
>>>>>> image0.zone:  18
>>>>>> number_entries:  1
>>>>>>
>>>>>>
>>>>>> DIFFTIEPTS.TXT:
>>>>>>
>>>>>> central_meridian: -75.000000000000000
>>>>>> datum: WGE
>>>>>> elevation_lookup_flag: 1
>>>>>> ellipse_code: WE
>>>>>> ellipse_name: WGS 84
>>>>>> false_easting_northing: ( 500000.000000000000000,
>>>>>> 0.000000000000000 )
>>>>>> false_easting_northing_units: meters
>>>>>> hemisphere: N
>>>>>> major_axis: 6378137.000000000000000
>>>>>> minor_axis: 6356752.314199999906123
>>>>>> origin_latitude: 0.000000000000000
>>>>>> pixel_scale_units: meters
>>>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>>>> tie_point_units: meters
>>>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>>>> type: ossimUtmProjection
>>>>>> zone: 18
>>>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>>>> 4.000000000000000     0.921372054978033
>>>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>>>> 6.000000000000000     0.926256942020091
>>>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>>>> 6.000000000000000     0.955136745663088
>>>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>>>> 5.000000000000000     0.931595123368421
>>>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>>>> 5.000000000000000     0.958003218739443
>>>>>> ........................................................
>>>>>>
>>>>>>
>>>>>> Is this too hard to fix?
>>>>>>
>>>>>>
>>>>>> Hernán
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Hernán De Angelis
>>>>>> Linux user # 397217
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>> challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>> great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>> the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> www.ossim.org
>>>>>> Ossim-developer mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> www.ossim.org
>>>>> Ossim-developer mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Hernán De Angelis
>>>> Linux user # 397217
>>>> <1984r.tif><2001r.tif>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> www.ossim.org
>>> Ossim-developer mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>
>>
>>
>>
>> --
>>
>> Hernán De Angelis
>> Linux user # 397217
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

David Burken
In reply to this post by Hernán De Angelis
Hernán,

You could find it by putting an "abort()" in ossimCommon.cpp, line 99  
and then looking at the stack dump.  If I could duplicate it I'd do it.

Dave

Hernán De Angelis wrote:

> Hi garrett,
>
> I tried one image and seems to be working fine. Thanks again!
>
> I just wonder what the garbage at the end means:
>
> ossimCommon.cpp:99
> Unhandled scalar type:  0
> ossimCommon.cpp:159
> Unhandled scalar type:  0
> ossimCommon.cpp:99
> Unhandled scalar type:  0
> ossimCommon.cpp:159
> Unhandled scalar type:  0
>
>
> Hernán
>
>
>
> 2008/8/20 Garrett Potts <[hidden email]>:
>  
>> Hello:
>>
>> Could you try to test the latest svn now?
>>
>> Take care
>>
>> Garrett
>>
>> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>>
>>    
>>> Hi Garrett,
>>>
>>> Both images are UTM S. I am sending to you reduced resolution images.
>>>
>>> Hernán
>>>
>>>
>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>      
>>>> Hello:
>>>>
>>>> Just a quick question while I am looking,  are both images UTM S or
>>>> within the Souther hemisphere?
>>>>
>>>> Take care
>>>>
>>>> Garrett
>>>>
>>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>>
>>>>        
>>>>> Hi guys!
>>>>>
>>>>> It's me again with problems of the same sort (please do not hate
>>>>> me!).
>>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>>> one
>>>>> reference image. I did some quick and dirty experiments with
>>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>>> days
>>>>> ago these images can be now displayed correctly in imagelinker but I
>>>>> noticed that "correl" is also screwing up the UTM South projection.
>>>>> Luckily I spared some tie point xml files from my old experiments
>>>>> and
>>>>> saw that applying modopt to those files still makes good results.
>>>>> So I
>>>>> looked into correl's results and what I found is that the
>>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>>> produced by modopt.
>>>>>
>>>>> I also noticed that executing correl always produces the following
>>>>> complain at the end:
>>>>>
>>>>> ossimCommon.cpp:99
>>>>> Unhandled scalar type:  0
>>>>> ossimCommon.cpp:159
>>>>> Unhandled scalar type:  0
>>>>> ossimCommon.cpp:99
>>>>> Unhandled scalar type:  0
>>>>> ossimCommon.cpp:159
>>>>> Unhandled scalar type:  0
>>>>>
>>>>>
>>>>> Below I paste the information given by image_info on both images and
>>>>> the output of correl:
>>>>>
>>>>>
>>>>> IMAGE_INFO:
>>>>>
>>>>> Description:
>>>>> class_name:  ossimTiffTileSource
>>>>> enabled:  1
>>>>> entry:  0
>>>>> file_type:  TIFF
>>>>> image0.band0.max_value:  255.000000000000000
>>>>> image0.band0.min_value:  1.000000000000000
>>>>> image0.band0.null_value:  0.000000000000000
>>>>> image0.band1.max_value:  255.000000000000000
>>>>> image0.band1.min_value:  1.000000000000000
>>>>> image0.band1.null_value:  0.000000000000000
>>>>> image0.band2.max_value:  255.000000000000000
>>>>> image0.band2.min_value:  1.000000000000000
>>>>> image0.band2.null_value:  0.000000000000000
>>>>> image0.central_meridian:  -75.000000000000000
>>>>> image0.datum:  WGE
>>>>> image0.elevation_lookup_flag:  1
>>>>> image0.ellipse_code:  WE
>>>>> image0.ellipse_name:  WGS 84
>>>>> image0.entry:  0
>>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>>> 10000000.000000000000000 )
>>>>> image0.false_easting_northing_units:  meters
>>>>> image0.hemisphere:  S
>>>>> image0.ll_lat:  -48.968788450835120
>>>>> image0.ll_lon:  -72.655728311733583
>>>>> image0.lr_lat:  -48.953542612214051
>>>>> image0.lr_lon:  -71.998242520912868
>>>>> image0.lr_x:  3212.000000000000000
>>>>> image0.lr_y:  5394.000000000000000
>>>>> image0.major_axis:  6378137.000000000000000
>>>>> image0.minor_axis:  6356752.314199999906123
>>>>> image0.number_input_bands:  3
>>>>> image0.number_lines:  5395.000000000000000
>>>>> image0.number_output_bands:  3
>>>>> image0.number_samples:  3213.000000000000000
>>>>> image0.origin_latitude:  0.000000000000000
>>>>> image0.pixel_scale_units:  meters
>>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>>> image0.radiometry:  8-bit
>>>>> image0.tie_point_units:  meters
>>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>>> 4654275.500000000000000 )
>>>>> image0.type:  ossimUtmProjection
>>>>> image0.ul_lat:  -48.241504234006257
>>>>> image0.ul_lon:  -72.689166817043144
>>>>> image0.ul_x:  0.000000000000000
>>>>> image0.ul_y:  0.000000000000000
>>>>> image0.ur_lat:  -48.226640960629410
>>>>> image0.ur_lon:  -72.041029431527008
>>>>> image0.zone:  18
>>>>> number_entries:  1
>>>>>
>>>>>
>>>>> DIFFTIEPTS.TXT:
>>>>>
>>>>> central_meridian: -75.000000000000000
>>>>> datum: WGE
>>>>> elevation_lookup_flag: 1
>>>>> ellipse_code: WE
>>>>> ellipse_name: WGS 84
>>>>> false_easting_northing: ( 500000.000000000000000,
>>>>> 0.000000000000000 )
>>>>> false_easting_northing_units: meters
>>>>> hemisphere: N
>>>>> major_axis: 6378137.000000000000000
>>>>> minor_axis: 6356752.314199999906123
>>>>> origin_latitude: 0.000000000000000
>>>>> pixel_scale_units: meters
>>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>>> tie_point_units: meters
>>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>>> type: ossimUtmProjection
>>>>> zone: 18
>>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>>> 4.000000000000000     0.921372054978033
>>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>>> 6.000000000000000     0.926256942020091
>>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>>> 6.000000000000000     0.955136745663088
>>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>>> 5.000000000000000     0.931595123368421
>>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>>> 5.000000000000000     0.958003218739443
>>>>> ........................................................
>>>>>
>>>>>
>>>>> Is this too hard to fix?
>>>>>
>>>>>
>>>>> Hernán
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Hernán De Angelis
>>>>> Linux user # 397217
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> www.ossim.org
>>>>> Ossim-developer mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>          
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> www.ossim.org
>>>> Ossim-developer mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>
>>>>        
>>>
>>> --
>>>
>>> Hernán De Angelis
>>> Linux user # 397217
>>> <1984r.tif><2001r.tif>
>>>      
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>
>>    
>
>
>
>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Hernán De Angelis
Hi Dave,

Thanks for the advice. I am far from an expert here. This is line 99:

            << __FILE__ << ":" << __LINE__

where exactly should I add the "abort()" ?


Hernán



2008/8/20 David Burken <[hidden email]>:

> Hernán,
>
> You could find it by putting an "abort()" in ossimCommon.cpp, line 99  and
> then looking at the stack dump.  If I could duplicate it I'd do it.
>
> Dave
>
> Hernán De Angelis wrote:
>>
>> Hi garrett,
>>
>> I tried one image and seems to be working fine. Thanks again!
>>
>> I just wonder what the garbage at the end means:
>>
>> ossimCommon.cpp:99
>> Unhandled scalar type:  0
>> ossimCommon.cpp:159
>> Unhandled scalar type:  0
>> ossimCommon.cpp:99
>> Unhandled scalar type:  0
>> ossimCommon.cpp:159
>> Unhandled scalar type:  0
>>
>>
>> Hernán
>>
>>
>>
>> 2008/8/20 Garrett Potts <[hidden email]>:
>>
>>>
>>> Hello:
>>>
>>> Could you try to test the latest svn now?
>>>
>>> Take care
>>>
>>> Garrett
>>>
>>> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>>>
>>>
>>>>
>>>> Hi Garrett,
>>>>
>>>> Both images are UTM S. I am sending to you reduced resolution images.
>>>>
>>>> Hernán
>>>>
>>>>
>>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>>
>>>>>
>>>>> Hello:
>>>>>
>>>>> Just a quick question while I am looking,  are both images UTM S or
>>>>> within the Souther hemisphere?
>>>>>
>>>>> Take care
>>>>>
>>>>> Garrett
>>>>>
>>>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Hi guys!
>>>>>>
>>>>>> It's me again with problems of the same sort (please do not hate
>>>>>> me!).
>>>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>>>> one
>>>>>> reference image. I did some quick and dirty experiments with
>>>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>>>> days
>>>>>> ago these images can be now displayed correctly in imagelinker but I
>>>>>> noticed that "correl" is also screwing up the UTM South projection.
>>>>>> Luckily I spared some tie point xml files from my old experiments
>>>>>> and
>>>>>> saw that applying modopt to those files still makes good results.
>>>>>> So I
>>>>>> looked into correl's results and what I found is that the
>>>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>>>> produced by modopt.
>>>>>>
>>>>>> I also noticed that executing correl always produces the following
>>>>>> complain at the end:
>>>>>>
>>>>>> ossimCommon.cpp:99
>>>>>> Unhandled scalar type:  0
>>>>>> ossimCommon.cpp:159
>>>>>> Unhandled scalar type:  0
>>>>>> ossimCommon.cpp:99
>>>>>> Unhandled scalar type:  0
>>>>>> ossimCommon.cpp:159
>>>>>> Unhandled scalar type:  0
>>>>>>
>>>>>>
>>>>>> Below I paste the information given by image_info on both images and
>>>>>> the output of correl:
>>>>>>
>>>>>>
>>>>>> IMAGE_INFO:
>>>>>>
>>>>>> Description:
>>>>>> class_name:  ossimTiffTileSource
>>>>>> enabled:  1
>>>>>> entry:  0
>>>>>> file_type:  TIFF
>>>>>> image0.band0.max_value:  255.000000000000000
>>>>>> image0.band0.min_value:  1.000000000000000
>>>>>> image0.band0.null_value:  0.000000000000000
>>>>>> image0.band1.max_value:  255.000000000000000
>>>>>> image0.band1.min_value:  1.000000000000000
>>>>>> image0.band1.null_value:  0.000000000000000
>>>>>> image0.band2.max_value:  255.000000000000000
>>>>>> image0.band2.min_value:  1.000000000000000
>>>>>> image0.band2.null_value:  0.000000000000000
>>>>>> image0.central_meridian:  -75.000000000000000
>>>>>> image0.datum:  WGE
>>>>>> image0.elevation_lookup_flag:  1
>>>>>> image0.ellipse_code:  WE
>>>>>> image0.ellipse_name:  WGS 84
>>>>>> image0.entry:  0
>>>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>>>> 10000000.000000000000000 )
>>>>>> image0.false_easting_northing_units:  meters
>>>>>> image0.hemisphere:  S
>>>>>> image0.ll_lat:  -48.968788450835120
>>>>>> image0.ll_lon:  -72.655728311733583
>>>>>> image0.lr_lat:  -48.953542612214051
>>>>>> image0.lr_lon:  -71.998242520912868
>>>>>> image0.lr_x:  3212.000000000000000
>>>>>> image0.lr_y:  5394.000000000000000
>>>>>> image0.major_axis:  6378137.000000000000000
>>>>>> image0.minor_axis:  6356752.314199999906123
>>>>>> image0.number_input_bands:  3
>>>>>> image0.number_lines:  5395.000000000000000
>>>>>> image0.number_output_bands:  3
>>>>>> image0.number_samples:  3213.000000000000000
>>>>>> image0.origin_latitude:  0.000000000000000
>>>>>> image0.pixel_scale_units:  meters
>>>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>>>> image0.radiometry:  8-bit
>>>>>> image0.tie_point_units:  meters
>>>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>>>> 4654275.500000000000000 )
>>>>>> image0.type:  ossimUtmProjection
>>>>>> image0.ul_lat:  -48.241504234006257
>>>>>> image0.ul_lon:  -72.689166817043144
>>>>>> image0.ul_x:  0.000000000000000
>>>>>> image0.ul_y:  0.000000000000000
>>>>>> image0.ur_lat:  -48.226640960629410
>>>>>> image0.ur_lon:  -72.041029431527008
>>>>>> image0.zone:  18
>>>>>> number_entries:  1
>>>>>>
>>>>>>
>>>>>> DIFFTIEPTS.TXT:
>>>>>>
>>>>>> central_meridian: -75.000000000000000
>>>>>> datum: WGE
>>>>>> elevation_lookup_flag: 1
>>>>>> ellipse_code: WE
>>>>>> ellipse_name: WGS 84
>>>>>> false_easting_northing: ( 500000.000000000000000,
>>>>>> 0.000000000000000 )
>>>>>> false_easting_northing_units: meters
>>>>>> hemisphere: N
>>>>>> major_axis: 6378137.000000000000000
>>>>>> minor_axis: 6356752.314199999906123
>>>>>> origin_latitude: 0.000000000000000
>>>>>> pixel_scale_units: meters
>>>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>>>> tie_point_units: meters
>>>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>>>> type: ossimUtmProjection
>>>>>> zone: 18
>>>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>>>> 4.000000000000000     0.921372054978033
>>>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>>>> 6.000000000000000     0.926256942020091
>>>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>>>> 6.000000000000000     0.955136745663088
>>>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>>>> 5.000000000000000     0.931595123368421
>>>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>>>> 5.000000000000000     0.958003218739443
>>>>>> ........................................................
>>>>>>
>>>>>>
>>>>>> Is this too hard to fix?
>>>>>>
>>>>>>
>>>>>> Hernán
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Hernán De Angelis
>>>>>> Linux user # 397217
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>> challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>> great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>> the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> www.ossim.org
>>>>>> Ossim-developer mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> www.ossim.org
>>>>> Ossim-developer mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> Hernán De Angelis
>>>> Linux user # 397217
>>>> <1984r.tif><2001r.tif>
>>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> www.ossim.org
>>> Ossim-developer mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>
>>>
>>
>>
>>
>>
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

David Burken
Hernán De Angelis wrote:

> Hi Dave,
>
> Thanks for the advice. I am far from an expert here. This is line 99:
>
>             << __FILE__ << ":" << __LINE__
>
> where exactly should I add the "abort()" ?
>
>
> Hernán
>  
Right before the "break;" add a line with "abort();"  No quotes, don't
forget the semi-colon.


Rebuild the library:
cd ossim
make CDEBUGFLAGS=-g

Two ways to do it:

1)
If you're a csh or tcsh do:
limit coredumpsize unlimited

bash:
ulimit -c unlimited

Run your app.  It will do a core dump when it hits the abort().
To examine core do:
gdb your-app-name your-core-dump-file
At the gdb prompt type "where".

2)
Or you can run your app with gdb:
gdb your-app-name
At the gdb prompt do:
run
where

You can send the output of that to me.
Dave

>
>
> 2008/8/20 David Burken <[hidden email]>:
>  
>> Hernán,
>>
>> You could find it by putting an "abort()" in ossimCommon.cpp, line 99  and
>> then looking at the stack dump.  If I could duplicate it I'd do it.
>>
>> Dave
>>
>> Hernán De Angelis wrote:
>>    
>>> Hi garrett,
>>>
>>> I tried one image and seems to be working fine. Thanks again!
>>>
>>> I just wonder what the garbage at the end means:
>>>
>>> ossimCommon.cpp:99
>>> Unhandled scalar type:  0
>>> ossimCommon.cpp:159
>>> Unhandled scalar type:  0
>>> ossimCommon.cpp:99
>>> Unhandled scalar type:  0
>>> ossimCommon.cpp:159
>>> Unhandled scalar type:  0
>>>
>>>
>>> Hernán
>>>
>>>
>>>
>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>
>>>      
>>>> Hello:
>>>>
>>>> Could you try to test the latest svn now?
>>>>
>>>> Take care
>>>>
>>>> Garrett
>>>>
>>>> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>>>>
>>>>
>>>>        
>>>>> Hi Garrett,
>>>>>
>>>>> Both images are UTM S. I am sending to you reduced resolution images.
>>>>>
>>>>> Hernán
>>>>>
>>>>>
>>>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>>>
>>>>>          
>>>>>> Hello:
>>>>>>
>>>>>> Just a quick question while I am looking,  are both images UTM S or
>>>>>> within the Souther hemisphere?
>>>>>>
>>>>>> Take care
>>>>>>
>>>>>> Garrett
>>>>>>
>>>>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>>>>
>>>>>>
>>>>>>            
>>>>>>> Hi guys!
>>>>>>>
>>>>>>> It's me again with problems of the same sort (please do not hate
>>>>>>> me!).
>>>>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>>>>> one
>>>>>>> reference image. I did some quick and dirty experiments with
>>>>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>>>>> days
>>>>>>> ago these images can be now displayed correctly in imagelinker but I
>>>>>>> noticed that "correl" is also screwing up the UTM South projection.
>>>>>>> Luckily I spared some tie point xml files from my old experiments
>>>>>>> and
>>>>>>> saw that applying modopt to those files still makes good results.
>>>>>>> So I
>>>>>>> looked into correl's results and what I found is that the
>>>>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>>>>> produced by modopt.
>>>>>>>
>>>>>>> I also noticed that executing correl always produces the following
>>>>>>> complain at the end:
>>>>>>>
>>>>>>> ossimCommon.cpp:99
>>>>>>> Unhandled scalar type:  0
>>>>>>> ossimCommon.cpp:159
>>>>>>> Unhandled scalar type:  0
>>>>>>> ossimCommon.cpp:99
>>>>>>> Unhandled scalar type:  0
>>>>>>> ossimCommon.cpp:159
>>>>>>> Unhandled scalar type:  0
>>>>>>>
>>>>>>>
>>>>>>> Below I paste the information given by image_info on both images and
>>>>>>> the output of correl:
>>>>>>>
>>>>>>>
>>>>>>> IMAGE_INFO:
>>>>>>>
>>>>>>> Description:
>>>>>>> class_name:  ossimTiffTileSource
>>>>>>> enabled:  1
>>>>>>> entry:  0
>>>>>>> file_type:  TIFF
>>>>>>> image0.band0.max_value:  255.000000000000000
>>>>>>> image0.band0.min_value:  1.000000000000000
>>>>>>> image0.band0.null_value:  0.000000000000000
>>>>>>> image0.band1.max_value:  255.000000000000000
>>>>>>> image0.band1.min_value:  1.000000000000000
>>>>>>> image0.band1.null_value:  0.000000000000000
>>>>>>> image0.band2.max_value:  255.000000000000000
>>>>>>> image0.band2.min_value:  1.000000000000000
>>>>>>> image0.band2.null_value:  0.000000000000000
>>>>>>> image0.central_meridian:  -75.000000000000000
>>>>>>> image0.datum:  WGE
>>>>>>> image0.elevation_lookup_flag:  1
>>>>>>> image0.ellipse_code:  WE
>>>>>>> image0.ellipse_name:  WGS 84
>>>>>>> image0.entry:  0
>>>>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>>>>> 10000000.000000000000000 )
>>>>>>> image0.false_easting_northing_units:  meters
>>>>>>> image0.hemisphere:  S
>>>>>>> image0.ll_lat:  -48.968788450835120
>>>>>>> image0.ll_lon:  -72.655728311733583
>>>>>>> image0.lr_lat:  -48.953542612214051
>>>>>>> image0.lr_lon:  -71.998242520912868
>>>>>>> image0.lr_x:  3212.000000000000000
>>>>>>> image0.lr_y:  5394.000000000000000
>>>>>>> image0.major_axis:  6378137.000000000000000
>>>>>>> image0.minor_axis:  6356752.314199999906123
>>>>>>> image0.number_input_bands:  3
>>>>>>> image0.number_lines:  5395.000000000000000
>>>>>>> image0.number_output_bands:  3
>>>>>>> image0.number_samples:  3213.000000000000000
>>>>>>> image0.origin_latitude:  0.000000000000000
>>>>>>> image0.pixel_scale_units:  meters
>>>>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>>>>> image0.radiometry:  8-bit
>>>>>>> image0.tie_point_units:  meters
>>>>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>>>>> 4654275.500000000000000 )
>>>>>>> image0.type:  ossimUtmProjection
>>>>>>> image0.ul_lat:  -48.241504234006257
>>>>>>> image0.ul_lon:  -72.689166817043144
>>>>>>> image0.ul_x:  0.000000000000000
>>>>>>> image0.ul_y:  0.000000000000000
>>>>>>> image0.ur_lat:  -48.226640960629410
>>>>>>> image0.ur_lon:  -72.041029431527008
>>>>>>> image0.zone:  18
>>>>>>> number_entries:  1
>>>>>>>
>>>>>>>
>>>>>>> DIFFTIEPTS.TXT:
>>>>>>>
>>>>>>> central_meridian: -75.000000000000000
>>>>>>> datum: WGE
>>>>>>> elevation_lookup_flag: 1
>>>>>>> ellipse_code: WE
>>>>>>> ellipse_name: WGS 84
>>>>>>> false_easting_northing: ( 500000.000000000000000,
>>>>>>> 0.000000000000000 )
>>>>>>> false_easting_northing_units: meters
>>>>>>> hemisphere: N
>>>>>>> major_axis: 6378137.000000000000000
>>>>>>> minor_axis: 6356752.314199999906123
>>>>>>> origin_latitude: 0.000000000000000
>>>>>>> pixel_scale_units: meters
>>>>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>>>>> tie_point_units: meters
>>>>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>>>>> type: ossimUtmProjection
>>>>>>> zone: 18
>>>>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>>>>> 4.000000000000000     0.921372054978033
>>>>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>>>>> 6.000000000000000     0.926256942020091
>>>>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>>>>> 6.000000000000000     0.955136745663088
>>>>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>>>>> 5.000000000000000     0.931595123368421
>>>>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>>>>> 5.000000000000000     0.958003218739443
>>>>>>> ........................................................
>>>>>>>
>>>>>>>
>>>>>>> Is this too hard to fix?
>>>>>>>
>>>>>>>
>>>>>>> Hernán
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Hernán De Angelis
>>>>>>> Linux user # 397217
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>> challenge
>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>> great prizes
>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>> the world
>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>> _______________________________________________
>>>>>>> www.ossim.org
>>>>>>> Ossim-developer mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>>>
>>>>>>>              
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>> challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>> great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>> the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> www.ossim.org
>>>>>> Ossim-developer mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>>
>>>>>>
>>>>>>            
>>>>> --
>>>>>
>>>>> Hernán De Angelis
>>>>> Linux user # 397217
>>>>> <1984r.tif><2001r.tif>
>>>>>
>>>>>          
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>> world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> www.ossim.org
>>>> Ossim-developer mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>
>>>>
>>>>        
>>>
>>>
>>>      
>
>
>
>  

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Correlation plugin does not recognize southern UTM

Hernán De Angelis
Thanks Dave,

Will try as soon as possible but it seems to be only irrelevant
garbage. Today I did a lot of registrations and they seem to be fine.

Hernán



2008/8/20 David Burken <[hidden email]>:

> Hernán De Angelis wrote:
>>
>> Hi Dave,
>>
>> Thanks for the advice. I am far from an expert here. This is line 99:
>>
>>            << __FILE__ << ":" << __LINE__
>>
>> where exactly should I add the "abort()" ?
>>
>>
>> Hernán
>>
>
> Right before the "break;" add a line with "abort();"  No quotes, don't
> forget the semi-colon.
>
>
> Rebuild the library:
> cd ossim
> make CDEBUGFLAGS=-g
>
> Two ways to do it:
>
> 1)
> If you're a csh or tcsh do:
> limit coredumpsize unlimited
>
> bash:
> ulimit -c unlimited
>
> Run your app.  It will do a core dump when it hits the abort().
> To examine core do:
> gdb your-app-name your-core-dump-file
> At the gdb prompt type "where".
>
> 2)
> Or you can run your app with gdb:
> gdb your-app-name
> At the gdb prompt do:
> run
> where
>
> You can send the output of that to me.
> Dave
>>
>>
>> 2008/8/20 David Burken <[hidden email]>:
>>
>>>
>>> Hernán,
>>>
>>> You could find it by putting an "abort()" in ossimCommon.cpp, line 99
>>>  and
>>> then looking at the stack dump.  If I could duplicate it I'd do it.
>>>
>>> Dave
>>>
>>> Hernán De Angelis wrote:
>>>
>>>>
>>>> Hi garrett,
>>>>
>>>> I tried one image and seems to be working fine. Thanks again!
>>>>
>>>> I just wonder what the garbage at the end means:
>>>>
>>>> ossimCommon.cpp:99
>>>> Unhandled scalar type:  0
>>>> ossimCommon.cpp:159
>>>> Unhandled scalar type:  0
>>>> ossimCommon.cpp:99
>>>> Unhandled scalar type:  0
>>>> ossimCommon.cpp:159
>>>> Unhandled scalar type:  0
>>>>
>>>>
>>>> Hernán
>>>>
>>>>
>>>>
>>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>>
>>>>
>>>>>
>>>>> Hello:
>>>>>
>>>>> Could you try to test the latest svn now?
>>>>>
>>>>> Take care
>>>>>
>>>>> Garrett
>>>>>
>>>>> On Aug 20, 2008, at 7:55 AM, Hernán De Angelis wrote:
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Hi Garrett,
>>>>>>
>>>>>> Both images are UTM S. I am sending to you reduced resolution images.
>>>>>>
>>>>>> Hernán
>>>>>>
>>>>>>
>>>>>> 2008/8/20 Garrett Potts <[hidden email]>:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hello:
>>>>>>>
>>>>>>> Just a quick question while I am looking,  are both images UTM S or
>>>>>>> within the Souther hemisphere?
>>>>>>>
>>>>>>> Take care
>>>>>>>
>>>>>>> Garrett
>>>>>>>
>>>>>>> On Aug 20, 2008, at 6:45 AM, Hernán De Angelis wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hi guys!
>>>>>>>>
>>>>>>>> It's me again with problems of the same sort (please do not hate
>>>>>>>> me!).
>>>>>>>> I have a bunch of images in UTM 18S which I want to registrate to
>>>>>>>> one
>>>>>>>> reference image. I did some quick and dirty experiments with
>>>>>>>> correl/modopt/rejout some months ago and I was delighted with the
>>>>>>>> results. Now I wanted to do it properly. After Garrett's fix two
>>>>>>>> days
>>>>>>>> ago these images can be now displayed correctly in imagelinker but I
>>>>>>>> noticed that "correl" is also screwing up the UTM South projection.
>>>>>>>> Luckily I spared some tie point xml files from my old experiments
>>>>>>>> and
>>>>>>>> saw that applying modopt to those files still makes good results.
>>>>>>>> So I
>>>>>>>> looked into correl's results and what I found is that the
>>>>>>>> difftiepts.txt file reports the wrong hemisfere, making a wrong
>>>>>>>> tiepts.xml file and thus introducing a problem into the geom file
>>>>>>>> produced by modopt.
>>>>>>>>
>>>>>>>> I also noticed that executing correl always produces the following
>>>>>>>> complain at the end:
>>>>>>>>
>>>>>>>> ossimCommon.cpp:99
>>>>>>>> Unhandled scalar type:  0
>>>>>>>> ossimCommon.cpp:159
>>>>>>>> Unhandled scalar type:  0
>>>>>>>> ossimCommon.cpp:99
>>>>>>>> Unhandled scalar type:  0
>>>>>>>> ossimCommon.cpp:159
>>>>>>>> Unhandled scalar type:  0
>>>>>>>>
>>>>>>>>
>>>>>>>> Below I paste the information given by image_info on both images and
>>>>>>>> the output of correl:
>>>>>>>>
>>>>>>>>
>>>>>>>> IMAGE_INFO:
>>>>>>>>
>>>>>>>> Description:
>>>>>>>> class_name:  ossimTiffTileSource
>>>>>>>> enabled:  1
>>>>>>>> entry:  0
>>>>>>>> file_type:  TIFF
>>>>>>>> image0.band0.max_value:  255.000000000000000
>>>>>>>> image0.band0.min_value:  1.000000000000000
>>>>>>>> image0.band0.null_value:  0.000000000000000
>>>>>>>> image0.band1.max_value:  255.000000000000000
>>>>>>>> image0.band1.min_value:  1.000000000000000
>>>>>>>> image0.band1.null_value:  0.000000000000000
>>>>>>>> image0.band2.max_value:  255.000000000000000
>>>>>>>> image0.band2.min_value:  1.000000000000000
>>>>>>>> image0.band2.null_value:  0.000000000000000
>>>>>>>> image0.central_meridian:  -75.000000000000000
>>>>>>>> image0.datum:  WGE
>>>>>>>> image0.elevation_lookup_flag:  1
>>>>>>>> image0.ellipse_code:  WE
>>>>>>>> image0.ellipse_name:  WGS 84
>>>>>>>> image0.entry:  0
>>>>>>>> image0.false_easting_northing:  ( 500000.000000000000000,
>>>>>>>> 10000000.000000000000000 )
>>>>>>>> image0.false_easting_northing_units:  meters
>>>>>>>> image0.hemisphere:  S
>>>>>>>> image0.ll_lat:  -48.968788450835120
>>>>>>>> image0.ll_lon:  -72.655728311733583
>>>>>>>> image0.lr_lat:  -48.953542612214051
>>>>>>>> image0.lr_lon:  -71.998242520912868
>>>>>>>> image0.lr_x:  3212.000000000000000
>>>>>>>> image0.lr_y:  5394.000000000000000
>>>>>>>> image0.major_axis:  6378137.000000000000000
>>>>>>>> image0.minor_axis:  6356752.314199999906123
>>>>>>>> image0.number_input_bands:  3
>>>>>>>> image0.number_lines:  5395.000000000000000
>>>>>>>> image0.number_output_bands:  3
>>>>>>>> image0.number_samples:  3213.000000000000000
>>>>>>>> image0.origin_latitude:  0.000000000000000
>>>>>>>> image0.pixel_scale_units:  meters
>>>>>>>> image0.pixel_scale_xy:  ( 15.000000000000000, 15.000000000000000 )
>>>>>>>> image0.radiometry:  8-bit
>>>>>>>> image0.tie_point_units:  meters
>>>>>>>> image0.tie_point_xy:  ( 671566.500000000000000,
>>>>>>>> 4654275.500000000000000 )
>>>>>>>> image0.type:  ossimUtmProjection
>>>>>>>> image0.ul_lat:  -48.241504234006257
>>>>>>>> image0.ul_lon:  -72.689166817043144
>>>>>>>> image0.ul_x:  0.000000000000000
>>>>>>>> image0.ul_y:  0.000000000000000
>>>>>>>> image0.ur_lat:  -48.226640960629410
>>>>>>>> image0.ur_lon:  -72.041029431527008
>>>>>>>> image0.zone:  18
>>>>>>>> number_entries:  1
>>>>>>>>
>>>>>>>>
>>>>>>>> DIFFTIEPTS.TXT:
>>>>>>>>
>>>>>>>> central_meridian: -75.000000000000000
>>>>>>>> datum: WGE
>>>>>>>> elevation_lookup_flag: 1
>>>>>>>> ellipse_code: WE
>>>>>>>> ellipse_name: WGS 84
>>>>>>>> false_easting_northing: ( 500000.000000000000000,
>>>>>>>> 0.000000000000000 )
>>>>>>>> false_easting_northing_units: meters
>>>>>>>> hemisphere: N
>>>>>>>> major_axis: 6378137.000000000000000
>>>>>>>> minor_axis: 6356752.314199999906123
>>>>>>>> origin_latitude: 0.000000000000000
>>>>>>>> pixel_scale_units: meters
>>>>>>>> pixel_scale_xy: ( 15.000000000000000, 15.000000000000000 )
>>>>>>>> tie_point_units: meters
>>>>>>>> tie_point_xy: ( 671566.500000000000000, 4654275.500000000000000 )
>>>>>>>> type: ossimUtmProjection
>>>>>>>> zone: 18
>>>>>>>> 68.000000000000000    666711.000000000000000  9.000000000000000
>>>>>>>> 4.000000000000000     0.921372054978033
>>>>>>>> 125.000000000000000   666700.000000000000000  10.000000000000000
>>>>>>>> 6.000000000000000     0.926256942020091
>>>>>>>> 349.000000000000000   666697.000000000000000  10.000000000000000
>>>>>>>> 6.000000000000000     0.955136745663088
>>>>>>>> 343.000000000000000   666710.000000000000000  10.000000000000000
>>>>>>>> 5.000000000000000     0.931595123368421
>>>>>>>> 430.000000000000000   666704.000000000000000  11.000000000000000
>>>>>>>> 5.000000000000000     0.958003218739443
>>>>>>>> ........................................................
>>>>>>>>
>>>>>>>>
>>>>>>>> Is this too hard to fix?
>>>>>>>>
>>>>>>>>
>>>>>>>> Hernán
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Hernán De Angelis
>>>>>>>> Linux user # 397217
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>>> challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>>> great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>>> the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> www.ossim.org
>>>>>>>> Ossim-developer mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>>>> challenge
>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>> great prizes
>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>> the world
>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>> _______________________________________________
>>>>>>> www.ossim.org
>>>>>>> Ossim-developer mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Hernán De Angelis
>>>>>> Linux user # 397217
>>>>>> <1984r.tif><2001r.tif>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>>> prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>>> world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> www.ossim.org
>>>>> Ossim-developer mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Registration...

david.burken
Hi Hernán,

Some of us are interested in your use of the registration process.  For instance, what type of data and your technique for success?  It might be useful to others to submit an article to Mark Lucas for the ossim.org site if you are willing to share?

Best regards and thanks for all the feedback,
Dave



> -----Original Message-----
> From: [hidden email] [mailto:ossim-
> [hidden email]] On Behalf Of Hernán De Angelis
> Sent: Thursday, August 21, 2008 10:26 AM
> To: David Burken
> Cc: Ossim users
> Subject: Re: [OSSIM] Correlation plugin does not recognize southern UTM
>
> Thanks Dave,
>
> Will try as soon as possible but it seems to be only irrelevant
> garbage. Today I did a lot of registrations and they seem to be fine.
>
> Hernán
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Registration...

Hernán De Angelis
Hi Dave,

Of course I am willing to share my experience. It is after all thanks
to your will of sharing that I can freely use this software!

However, I want to make clear first that all I have done is in a very
early experimental stage, based on what I understood of the
registration manuals, my own experience and your help in this list.
Therefore, what I write below should *not* be considered as the
canonical rules of how to work with OSSIM registration.

Together with two colleagues I drive a glaciological project in
Patagonia (Southern South America, thus the need for south UTM
support). We have a bunch of satellite images (Landsat MSS, TM and
ASTER) and some old scanned aerial photographs. The purpose of using
automated registration is to overcome the difficulties/drawbacks of
manually picking up ground control points and to get the best possible
registration.

One of the major difficulties of using automatic registration over
glaciated areas is the fact that glaciers flow and some features over
them are displaced over time. In fact, this principle has been used by
glaciologists for a long time to track features and estimate surface
velocities in glaciers (see IMCORR:
http://www.nsidc.org/data/velmap/imcorr.html). However, glaciers in
our area are relatively small and occupy only a fraction of the image,
so we hope they are not introducing severe errors (though this might
not locally be true). In fact, it would be nice to have the
possibility to mask glacier areas, so they are not included in the
correlation (feature request? mmm may be).

We use one reference ASTER image (we think the original georeference
is excellent), with 15 m pixel size. This image is actually a subset
of a mosaic of two, because our interest area was not covered by only
one image. The mosaic was done with ERDAS. All other satellite images
were cropped to cover the same area as the reference image and also
resampled to 15 m. The aerial photographs were individually geocoded
and orthorectified in GRASS with an SRTM model. The elevation database
is composed of SRTM tiles and covers completely the area of interest.

I start with "correl". The slave images are always geocoded and more
or less within 10-30 pixels of mismatch. Normally I use it in this
way:

correl -m master_band -s slave_band -c 0.90 -d 0.001 master.tif slave.tif

during a registration I might vary the values of -c and -d, but those
two (0.90 and 0.001) are giving good results with most images. I
always try to choose master and slave bands that are radiometrically
similar. Examples: ASTER VNIR 3 with LANDSAT TM 4 or MSS 3. Actually,
I do not know how sensitive the algorithm is to radiometrical
differences in images, but as far as my experience is concerned the
visible near infra-red bands may be interchanged without much trouble
(this is hardly surprising). An interesting issue is that registering
a resampled MSS image to the ASTER reference presented no serious
problems.

After this I work mostly with "modopt". I simply do:

modopt tiepts.xml

(that is with the default polynomial model) and get generally very
acceptable results. Only eventually I might need to do rejout:

rejout -a 2 -i 0.5 tiepts.xml

I follow the manual after this: I change the name of the resulting
.geom file to add the base name of the image (e.g. modopt.geom ->
image.geom). I open both the reference and the slave images in
imagelinker and do a visual control. If I am happy I switch to full
resolution and save the results as a new image. WARNING: before doing
this I must normally tell imagelinker that the UTM is south (somehow
OSSIM is not happy with the Southern Hemisphere). I do this in Edit ->
View.

According to the manual the process should now be finished. However, I
noticed that images produced in this way cannot be displayed correctly
by, for example, OpenEV. I therefore do:

orthoigen --utm image1.tif image2.tif  (where image1.tif would be the
image saved by imagelinker)

to get the metadata correctly written in the geotiff. However, even
after this step, gdalinfo does not report South Hemisphere.

The procedure with the aerial photos is different. The aerial photos
are reported to have abot 4 m ground resolution. After some (not very
lucky) experiments with reduced resolution datasets I used the full
images, which cover only a tiny portion of the reference image:

correl -m 0 -s 0 -c 0.85 -d 0.002 master.tif aerial.tif

Notice that now the correlation coefficient is smaller. That was the
only thing I had to do to make it work more or less acceptably. Modopt
was used to optimize the model (polynomial). Errors in the aerial
photos include severe local distortion near the edges (associated with
traditional radial errors that could not be eliminated during the
orthorectification) and some displacements of relative high peaks.
Otherwise it was reasonably OK.


My results until now can only be said to be very acceptable. They are
not perfect, but I am working on it!


Regards,


Hernán







2008/8/22  <[hidden email]>:

> Hi Hernán,
>
> Some of us are interested in your use of the registration process.  For instance, what type of data and your technique for success?  It might be useful to others to submit an article to Mark Lucas for the ossim.org site if you are willing to share?
>
> Best regards and thanks for all the feedback,
> Dave
>
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:ossim-
>> [hidden email]] On Behalf Of Hernán De Angelis
>> Sent: Thursday, August 21, 2008 10:26 AM
>> To: David Burken
>> Cc: Ossim users
>> Subject: Re: [OSSIM] Correlation plugin does not recognize southern UTM
>>
>> Thanks Dave,
>>
>> Will try as soon as possible but it seems to be only irrelevant
>> garbage. Today I did a lot of registrations and they seem to be fine.
>>
>> Hernán
>>
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Registration...

david.burken

Hernán,

Thank you for the detailed explanation.  That is very good.  Do you care if we put that on ossim.org?  I think it would be very useful to people out there.

I believe I understand the imagelinker UTM zone bug.  On the image side you have a sensor model, like LandSat7, on the view side you switch to UTM but it's not picking up the hemisphere...

I will fix this as soon as I track down an image down under with a sensor model:)

Thanks again,
Dave

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Registration...

Hernán De Angelis
Dave,

I forgot to add that I also experienced the problems reported here:

http://www.nabble.com/Using-the-Registration-Plugin-td16753908.html

with a different set of images. For me it happened when trying to
register a set of ASTER images downloaded from the USGS Glovis
(http://glovis.usgs.gov/). I have no explanation for this except that
the bands in this images are linear combinations of the standard ASTER
bands. Perhaps this is screwing up things, but I am not sure.  As
Scott Arko reported I also often observed that rejout fails to
converge to a model.

I think is fine to past my previous e-mail in the website, as far as
it is clear that these are just experiments so nobody can blame me for
misleading anyone!


Hernán









2008/8/22  <[hidden email]>:

>
> Hernán,
>
> Thank you for the detailed explanation.  That is very good.  Do you care if we put that on ossim.org?  I think it would be very useful to people out there.
>
> I believe I understand the imagelinker UTM zone bug.  On the image side you have a sensor model, like LandSat7, on the view side you switch to UTM but it's not picking up the hemisphere...
>
> I will fix this as soon as I track down an image down under with a sensor model:)
>
> Thanks again,
> Dave
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Registration...

Garrett Potts
In reply to this post by david.burken
HEllo DAve:

I have fixed this and tested under imagelinker in ossim_qt.  The  
hemisphere changes fine


Take care

Garrett


On Aug 22, 2008, at 10:00 AM, [hidden email] wrote:

>
> Hernán,
>
> Thank you for the detailed explanation.  That is very good.  Do you  
> care if we put that on ossim.org?  I think it would be very useful  
> to people out there.
>
> I believe I understand the imagelinker UTM zone bug.  On the image  
> side you have a sensor model, like LandSat7, on the view side you  
> switch to UTM but it's not picking up the hemisphere...
>
> I will fix this as soon as I track down an image down under with a  
> sensor model:)
>
> Thanks again,
> Dave
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: UTM zone bug...

david.burken
Hey cool, I was wondering if the recent changes had already fixed...

Dave


-----Original Message-----
From: [hidden email] on behalf of Garrett Potts
Sent: Fri 8/22/2008 10:13 AM
To: Ossim users
Subject: Re: [OSSIM] Registration...
 
HEllo DAve:

I have fixed this and tested under imagelinker in ossim_qt.  The  
hemisphere changes fine


Take care

Garrett


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: UTM zone bug...

Mark Lucas
Hernan,

Thanks for the summary, it is always very motivating to hear how OSSIM  
is being used.  Most of us haven't experimented with the registration  
plugin - many probably don't realize it exists.  You are probably very  
close to being the resident expert on OSSIM registration :-)

I'll post your notes when I get back in Florida.

Thanks again.

Mark


On Aug 22, 2008, at 10:28 AM, [hidden email] wrote:

> Hey cool, I was wondering if the recent changes had already fixed...
>
> Dave
>
>
> -----Original Message-----
> From: [hidden email] on behalf of  
> Garrett Potts
> Sent: Fri 8/22/2008 10:13 AM
> To: Ossim users
> Subject: Re: [OSSIM] Registration...
>
> HEllo DAve:
>
> I have fixed this and tested under imagelinker in ossim_qt.  The
> hemisphere changes fine
>
>
> Take care
>
> Garrett
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: UTM zone bug...

Hernán De Angelis
Mark,

It's cool to give something back! I will keep experimenting with this.
There is a lot to be tried.

Cheers,

Hernán


2008/8/22 Mark Lucas <[hidden email]>:

> Hernan,
>
> Thanks for the summary, it is always very motivating to hear how OSSIM
> is being used.  Most of us haven't experimented with the registration
> plugin - many probably don't realize it exists.  You are probably very
> close to being the resident expert on OSSIM registration :-)
>
> I'll post your notes when I get back in Florida.
>
> Thanks again.
>
> Mark
>
>
> On Aug 22, 2008, at 10:28 AM, [hidden email] wrote:
>
>> Hey cool, I was wondering if the recent changes had already fixed...
>>
>> Dave
>>
>>
>> -----Original Message-----
>> From: [hidden email] on behalf of
>> Garrett Potts
>> Sent: Fri 8/22/2008 10:13 AM
>> To: Ossim users
>> Subject: Re: [OSSIM] Registration...
>>
>> HEllo DAve:
>>
>> I have fixed this and tested under imagelinker in ossim_qt.  The
>> hemisphere changes fine
>>
>>
>> Take care
>>
>> Garrett
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> www.ossim.org
>> Ossim-developer mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> www.ossim.org
> Ossim-developer mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/ossim-developer
>



--

Hernán De Angelis
Linux user # 397217

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer