ortho-rectification of low oblique images

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

ortho-rectification of low oblique images

Sebastian Rohde

Dear all,

 

I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.

Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.

I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.

 

Therefore, I’d like to know:

A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.

B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.

 

At the link below you may find an example dataset that produces the mentioned error.

http://depot.tu-dortmund.de/get/7pgh2 .

Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.

To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.

 

As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?

 

Regards,

Sebastian


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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: ortho-rectification of low oblique images

Garrett Potts-2
<base href="x-msg://3378/">Hello Sebastian:

Let me take a peep at it before responding with any comments or statements.  I got the data downloaded.  I am on a trip this week so will peep at it at nights.  There is always a possibility that it is such a low oblique that depending on the elevation used and the elevation of that area it might think it's below the surface due to in accuracies in the floating precision.  But,  let me take a look this week and see.  I just did a quick run on my current mack build and I noticed the width height of the view is blowing up.  So it is erring out on both your build and my MAC build.  

Any submissions please send full files to me that is compiled against the current SVN baseline.

Thank you for the input and the sample image!

Take care

Garrett

On May 26, 2013, at 8:57 AM, Sebastian Rohde <[hidden email]> wrote:

Dear all,
 
I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.
Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.
I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.
 
Therefore, I’d like to know:
A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.
B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.
 
At the link below you may find an example dataset that produces the mentioned error.
Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.
To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.
 
As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?
 
Regards,
Sebastian
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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: ortho-rectification of low oblique images

Garrett Potts-2
In reply to this post by Sebastian Rohde
<base href="x-msg://168/">Hello Sebastian:

I am a little confused on the format of the EO file.  Usually when its a UTM EO file the filed names are of the form:

Record Format:

 ID, # EVENT, TIME (s), EASTING, NORTHING, ELLIPSOID HEIGHT, OMEGA, PHI, KAPPA, LAT, LONG


But in your EO file you have:

Record Format:

 ID, # EVENT, TIME (s), X, Y, Z, ROLL, PITCH, HEADING

which is an EO for an ECEF output.


In yours I see header information indicating that it is suppose to be a UTM?  Can you verify that the EO file you have is properly generated for the data, or try to generate a pure ECEF EO file and try again so that the header information does not indicate a UTM.


I will keep peeping on my end as well.  Do you know the center lat lon height of the image?


Take care

Garrett


On May 26, 2013, at 8:57 AM, Sebastian Rohde <[hidden email]> wrote:

Dear all,
 
I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.
Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.
I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.
 
Therefore, I’d like to know:
A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.
B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.
 
At the link below you may find an example dataset that produces the mentioned error.
Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.
To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.
 
As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?
 
Regards,
Sebastian
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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: ortho-rectification of low oblique images

Garrett Potts-2
Hello Sebastian:

I just did some debugging and with a 1 kilometer elevation the ECEF position in the EO file puts the aircraft underneath my 1 kilometer elevation.  The ECEF X,Y,Z indicates that the aircraft is at:

( 51.778414000000026, 7.271060999999996, 148.555, WGE )

which is 148 meters above ellipsoid.  With a 1 kilometer elevation my readouts are:

Opened cell:            /data/elevation/dted/1k/e007/n51.dt1
MSL to ellipsoid delta: 44.8749715766663
Height above MSL:       176.366849703993
Height above ellipsoid: 221.24182128066
Geoid value:            44.8749715766663

putting the aircraft below the surface.


You might want to verify the EO file and also use a much more accurate elevation model.  The last option is to try to turn off elevation so readouts are NaN and use a constant/default height for that area in your keywordlist:

elevation_manager.default_height_above_ellipsoid: <height in meters above ellipsoid>

Take care

Garrett


On May 27, 2013, at 2:05 PM, Garrett Potts <[hidden email]> wrote:

<base href="x-msg://168/">
Hello Sebastian:

I am a little confused on the format of the EO file.  Usually when its a UTM EO file the filed names are of the form:

Record Format:

 ID, # EVENT, TIME (s), EASTING, NORTHING, ELLIPSOID HEIGHT, OMEGA, PHI, KAPPA, LAT, LONG


But in your EO file you have:

Record Format:

 ID, # EVENT, TIME (s), X, Y, Z, ROLL, PITCH, HEADING

which is an EO for an ECEF output.


In yours I see header information indicating that it is suppose to be a UTM?  Can you verify that the EO file you have is properly generated for the data, or try to generate a pure ECEF EO file and try again so that the header information does not indicate a UTM.


I will keep peeping on my end as well.  Do you know the center lat lon height of the image?


Take care

Garrett


On May 26, 2013, at 8:57 AM, Sebastian Rohde <[hidden email]> wrote:

Dear all,
 
I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.
Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.
I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.
 
Therefore, I’d like to know:
A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.
B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.
 
At the link below you may find an example dataset that produces the mentioned error.
Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.
To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.
 
As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?
 
Regards,
Sebastian
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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: ortho-rectification of low oblique images

Sebastian Rohde
<base href="x-msg://168/">

Hello Garrett,

 

thanks for your efforts. The sample data was taken from a plane. I was also in that plane an we were flying close to the takeoff location, which has a well known takeoff height of around 44m. above MSL.

 

Indeed, there was an error in the data I provided, because I accidentally copied the barometric value relative to takeoff height, which is why it’s 44m (take-off height) too low.

 

Though, I think I don’t understand your conclusions entirely as my elevation model says that I have a height above ellipsoid of 89.342m which makes me think that the above error of 44m does not really matter regarding the mentioned problem.

 

ossim-info.exe --height 51.778414000000026 7.271060999999996

 

Opened cell:            D:\svn\ossim\data\srtm3\N51E007.hgt

MSL to ellipsoid delta: 44.8749715766663

Height above MSL:       44.4670627200029

Height above ellipsoid: 89.3420342966692

Geoid value:            44.8749715766663

 

My elevation setup is:

N51E007.hgt as SRTM3 Dataset

egm96 as geoid Dataset

 

Regarding the EO File you are right. For historical reasons (I tried first to use the UTM Sensor model) I had used the UTM template and modified the relevant (as I thought) aspects manually towards the ECEF file format.

Do you see a problem with that? I had quick look at the source code and had the impression, that the parameters from the header weren’t used at all. I will try to modify that tomorrow and start from a fresh ECEF applanix template. To clarify: I am using the applanix files in order to get my IMU and GPS data from my own sensor equipment into OSSIM.

 

I will also try to set a fixed height above ellipsoid.

 

That said, I also did some more investigations and found that the following loop never returns:

 

      for(yIndex = requestedRectAtValidRLevel.ul().y;yIndex < requestedRectAtValidRLevel.lr().y; yIndex += tileSize.y)

      {

         for(xIndex = requestedRectAtValidRLevel.ul().x; xIndex < requestedRectAtValidRLevel.lr().x; xIndex+=tileSize.x)

         {

 

I saw yIndex or xIndex having negative values while tileSize was quite big. It seems that there was an overflow of the respective variable.

 

I will keep searching for the issue. Maybe I’ll find out more next days…

 

Cheers,

Sebastian

 

Von: Garrett Potts [mailto:[hidden email]]
Gesendet: Montag, 27. Mai 2013 20:22
An: Sebastian Rohde
Cc: ossim users
Betreff: Re: [OSSIM] ortho-rectification of low oblique images

 

Hello Sebastian:

 

I just did some debugging and with a 1 kilometer elevation the ECEF position in the EO file puts the aircraft underneath my 1 kilometer elevation.  The ECEF X,Y,Z indicates that the aircraft is at:

 

( 51.778414000000026, 7.271060999999996, 148.555, WGE )

 

which is 148 meters above ellipsoid.  With a 1 kilometer elevation my readouts are:

 

Opened cell:            /data/elevation/dted/1k/e007/n51.dt1

MSL to ellipsoid delta: 44.8749715766663

Height above MSL:       176.366849703993

Height above ellipsoid: 221.24182128066

Geoid value:            44.8749715766663

 

putting the aircraft below the surface.

 

 

You might want to verify the EO file and also use a much more accurate elevation model.  The last option is to try to turn off elevation so readouts are NaN and use a constant/default height for that area in your keywordlist:

 

elevation_manager.default_height_above_ellipsoid: <height in meters above ellipsoid>

 

Take care

 

Garrett

 

 

On May 27, 2013, at 2:05 PM, Garrett Potts <[hidden email]> wrote:



Hello Sebastian:

 

I am a little confused on the format of the EO file.  Usually when its a UTM EO file the filed names are of the form:

 

Record Format:

 

 ID, # EVENT, TIME (s), EASTING, NORTHING, ELLIPSOID HEIGHT, OMEGA, PHI, KAPPA, LAT, LONG

 

 

But in your EO file you have:

 

Record Format:

 

 ID, # EVENT, TIME (s), X, Y, Z, ROLL, PITCH, HEADING

 

which is an EO for an ECEF output.

 

 

In yours I see header information indicating that it is suppose to be a UTM?  Can you verify that the EO file you have is properly generated for the data, or try to generate a pure ECEF EO file and try again so that the header information does not indicate a UTM.

 

 

I will keep peeping on my end as well.  Do you know the center lat lon height of the image?

 

 

Take care

 

Garrett

 

 

On May 26, 2013, at 8:57 AM, Sebastian Rohde <[hidden email]> wrote:



Dear all,

 

I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.

Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.

I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.

 

Therefore, I’d like to know:

A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.

B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.

 

At the link below you may find an example dataset that produces the mentioned error.

Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.

To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.

 

As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?

 

Regards,

Sebastian

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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: ortho-rectification of low oblique images

Garrett Potts-2
<base href="x-msg://168/">Hello Sebastian:

My elevation is only 1 kilometer.  You have 90 meter so you will have much more accurate readouts.  I think you have an elevation problem in general.  I was using my 1 kilometer elevation and the platform position falls below the 1 kilometer terrain.  I don't have 90 ore even 30 or better in this area.

For a test.  Disable elevation all together and I bet it will generate the model and reproject.  If it does then we know it's elevation.  You can keep the geoid as is.

The EO will not make a difference only if it is truly UTM oriented We read the zone information out of the header file if the EO values are for easting northing locations.  Because you use the ECEF parameters instead then that header part will be ignored or should be ignored.  If it was suppose to be UTM oriented then at worst you will have a small yaw error that was not undone using the ECEF model.

I find that if elevation values are not exact for very low altitude flights you might have problems.  You might even need to be better than 90 meter.  You can also add an offset to the elevation that is global.   Use this to test.   So if you want to lower the terrain by a global offset of 44 meters you can modify the keyword:

elevation_manager.elevation_offset: -44

This should subtract 44 meters from the result before returning.


Also,  are there holes in the SRTM3 that you have?  Sometimes there are holes in SRTM cells that return nan values in parts of the image.

You can also run in debug by doing this as a parameter to any ossim applicaiton:

-T ".*"

Which turns trace on for everything and you can see the model output for the image to ground and ground to image calculations when you create the geometry.


Take care

Garrett


On May 27, 2013, at 6:07 PM, Sebastian Rohde <[hidden email]> wrote:

Hello Garrett,
 
thanks for your efforts. The sample data was taken from a plane. I was also in that plane an we were flying close to the takeoff location, which has a well known takeoff height of around 44m. above MSL.
 
Indeed, there was an error in the data I provided, because I accidentally copied the barometric value relative to takeoff height, which is why it’s 44m (take-off height) too low.
 
Though, I think I don’t understand your conclusions entirely as my elevation model says that I have a height above ellipsoid of 89.342m which makes me think that the above error of 44m does not really matter regarding the mentioned problem.
 
ossim-info.exe --height 51.778414000000026 7.271060999999996
 
Opened cell:            D:\svn\ossim\data\srtm3\N51E007.hgt
MSL to ellipsoid delta: 44.8749715766663
Height above MSL:       44.4670627200029
Height above ellipsoid: 89.3420342966692
Geoid value:            44.8749715766663
 
My elevation setup is:
N51E007.hgt as SRTM3 Dataset
egm96 as geoid Dataset
 
Regarding the EO File you are right. For historical reasons (I tried first to use the UTM Sensor model) I had used the UTM template and modified the relevant (as I thought) aspects manually towards the ECEF file format.
Do you see a problem with that? I had quick look at the source code and had the impression, that the parameters from the header weren’t used at all. I will try to modify that tomorrow and start from a fresh ECEF applanix template. To clarify: I am using the applanix files in order to get my IMU and GPS data from my own sensor equipment into OSSIM.
 
 
That said, I also did some more investigations and found that the following loop never returns:
 
      for(yIndex = requestedRectAtValidRLevel.ul().y;yIndex < requestedRectAtValidRLevel.lr().y; yIndex += tileSize.y)
      {
         for(xIndex = requestedRectAtValidRLevel.ul().x; xIndex < requestedRectAtValidRLevel.lr().x; xIndex+=tileSize.x)
         {
 
I saw yIndex or xIndex having negative values while tileSize was quite big. It seems that there was an overflow of the respective variable.
 
I will keep searching for the issue. Maybe I’ll find out more next days…
 
Cheers,
Sebastian
 
Von: Garrett Potts [mailto:gcpotts@mac.com] 
Gesendet: Montag, 27. Mai 2013 20:22
An: Sebastian Rohde
Cc: ossim users
Betreff: Re: [OSSIM] ortho-rectification of low oblique images
 
Hello Sebastian:
 
I just did some debugging and with a 1 kilometer elevation the ECEF position in the EO file puts the aircraft underneath my 1 kilometer elevation.  The ECEF X,Y,Z indicates that the aircraft is at:
 
( 51.778414000000026, 7.271060999999996, 148.555, WGE )
 
which is 148 meters above ellipsoid.  With a 1 kilometer elevation my readouts are:
 
Opened cell:            /data/elevation/dted/1k/e007/n51.dt1
MSL to ellipsoid delta: 44.8749715766663
Height above MSL:       176.366849703993
Height above ellipsoid: 221.24182128066
Geoid value:            44.8749715766663
 
putting the aircraft below the surface.
 
 
You might want to verify the EO file and also use a much more accurate elevation model.  The last option is to try to turn off elevation so readouts are NaN and use a constant/default height for that area in your keywordlist:
 
elevation_manager.default_height_above_ellipsoid: <height in meters above ellipsoid>
 
Take care
 
Garrett
 
 
On May 27, 2013, at 2:05 PM, Garrett Potts <[hidden email]> wrote:


Hello Sebastian:
 
I am a little confused on the format of the EO file.  Usually when its a UTM EO file the filed names are of the form:
 
Record Format:
 
 ID, # EVENT, TIME (s), EASTING, NORTHING, ELLIPSOID HEIGHT, OMEGA, PHI, KAPPA, LAT, LONG
 
 
But in your EO file you have:
 
Record Format:
 
 ID, # EVENT, TIME (s), X, Y, Z, ROLL, PITCH, HEADING
 
which is an EO for an ECEF output.
 
 
In yours I see header information indicating that it is suppose to be a UTM?  Can you verify that the EO file you have is properly generated for the data, or try to generate a pure ECEF EO file and try again so that the header information does not indicate a UTM.
 
 
I will keep peeping on my end as well.  Do you know the center lat lon height of the image?
 
 
Take care
 
Garrett
 
 
On May 26, 2013, at 8:57 AM, Sebastian Rohde <[hidden email]> wrote:


Dear all,
 
I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.
Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.
I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.
 
Therefore, I’d like to know:
A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.
B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.
 
At the link below you may find an example dataset that produces the mentioned error.
Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.
To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.
 
As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?
 
Regards,
Sebastian
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
 
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
 
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
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: ortho-rectification of low oblique images

Sebastian Rohde
<base href="x-msg://168/">

Hello Garrett,

 

I tried your suggestion regarding disabling elevation.

However, as that didn’t solve the issue I reviewed my camera settings.

 

I don’t exactly understand the camera file format and I added the distortion parameters I had in my calibration protocol in the first place.

Now, after adding several more values it seems that that solved my issues.

 

Though, I don’t understand whether I introduced accuracy problems by that as I only guessed the additional values continueing the trend.

 

Thank you very much for your help. I can now continue to discover ossim J

 

Regards,

Sebastian

 

 

 

Von: Garrett Potts [mailto:[hidden email]]
Gesendet: Dienstag, 28. Mai 2013 00:27
An: Sebastian Rohde
Cc: 'Garrett Potts'; 'ossim users'
Betreff: Re: [OSSIM] ortho-rectification of low oblique images

 

Hello Sebastian:

 

My elevation is only 1 kilometer.  You have 90 meter so you will have much more accurate readouts.  I think you have an elevation problem in general.  I was using my 1 kilometer elevation and the platform position falls below the 1 kilometer terrain.  I don't have 90 ore even 30 or better in this area.

 

For a test.  Disable elevation all together and I bet it will generate the model and reproject.  If it does then we know it's elevation.  You can keep the geoid as is.

 

The EO will not make a difference only if it is truly UTM oriented We read the zone information out of the header file if the EO values are for easting northing locations.  Because you use the ECEF parameters instead then that header part will be ignored or should be ignored.  If it was suppose to be UTM oriented then at worst you will have a small yaw error that was not undone using the ECEF model.

 

I find that if elevation values are not exact for very low altitude flights you might have problems.  You might even need to be better than 90 meter.  You can also add an offset to the elevation that is global.   Use this to test.   So if you want to lower the terrain by a global offset of 44 meters you can modify the keyword:

 

elevation_manager.elevation_offset: -44

 

This should subtract 44 meters from the result before returning.

 

 

Also,  are there holes in the SRTM3 that you have?  Sometimes there are holes in SRTM cells that return nan values in parts of the image.

 

You can also run in debug by doing this as a parameter to any ossim applicaiton:

 

-T ".*"

 

Which turns trace on for everything and you can see the model output for the image to ground and ground to image calculations when you create the geometry.

 

 

Take care

 

Garrett

 

 

On May 27, 2013, at 6:07 PM, Sebastian Rohde <[hidden email]> wrote:



Hello Garrett,

 

thanks for your efforts. The sample data was taken from a plane. I was also in that plane an we were flying close to the takeoff location, which has a well known takeoff height of around 44m. above MSL.

 

Indeed, there was an error in the data I provided, because I accidentally copied the barometric value relative to takeoff height, which is why it’s 44m (take-off height) too low.

 

Though, I think I don’t understand your conclusions entirely as my elevation model says that I have a height above ellipsoid of 89.342m which makes me think that the above error of 44m does not really matter regarding the mentioned problem.

 

ossim-info.exe --height 51.778414000000026 7.271060999999996

 

Opened cell:            D:\svn\ossim\data\srtm3\N51E007.hgt

MSL to ellipsoid delta: 44.8749715766663

Height above MSL:       44.4670627200029

Height above ellipsoid: 89.3420342966692

Geoid value:            44.8749715766663

 

My elevation setup is:

N51E007.hgt as SRTM3 Dataset

egm96 as geoid Dataset

 

Regarding the EO File you are right. For historical reasons (I tried first to use the UTM Sensor model) I had used the UTM template and modified the relevant (as I thought) aspects manually towards the ECEF file format.

Do you see a problem with that? I had quick look at the source code and had the impression, that the parameters from the header weren’t used at all. I will try to modify that tomorrow and start from a fresh ECEF applanix template. To clarify: I am using the applanix files in order to get my IMU and GPS data from my own sensor equipment into OSSIM.

 

I will also try to set a fixed height above ellipsoid.

 

That said, I also did some more investigations and found that the following loop never returns:

 

      for(yIndex = requestedRectAtValidRLevel.ul().y;yIndex < requestedRectAtValidRLevel.lr().y; yIndex += tileSize.y)

      {

         for(xIndex = requestedRectAtValidRLevel.ul().x; xIndex < requestedRectAtValidRLevel.lr().x; xIndex+=tileSize.x)

         {

 

I saw yIndex or xIndex having negative values while tileSize was quite big. It seems that there was an overflow of the respective variable.

 

I will keep searching for the issue. Maybe I’ll find out more next days…

 

Cheers,

Sebastian

 

Von: Garrett Potts [mailto:gcpotts@mac.com] 
Gesendet: Montag, 27. Mai 2013 20:22
An: Sebastian Rohde
Cc: ossim users
Betreff: Re: [OSSIM] ortho-rectification of low oblique images

 

Hello Sebastian:

 

I just did some debugging and with a 1 kilometer elevation the ECEF position in the EO file puts the aircraft underneath my 1 kilometer elevation.  The ECEF X,Y,Z indicates that the aircraft is at:

 

( 51.778414000000026, 7.271060999999996, 148.555, WGE )

 

which is 148 meters above ellipsoid.  With a 1 kilometer elevation my readouts are:

 

Opened cell:            /data/elevation/dted/1k/e007/n51.dt1

MSL to ellipsoid delta: 44.8749715766663

Height above MSL:       176.366849703993

Height above ellipsoid: 221.24182128066

Geoid value:            44.8749715766663

 

putting the aircraft below the surface.

 

 

You might want to verify the EO file and also use a much more accurate elevation model.  The last option is to try to turn off elevation so readouts are NaN and use a constant/default height for that area in your keywordlist:

 

elevation_manager.default_height_above_ellipsoid: <height in meters above ellipsoid>

 

Take care

 

Garrett

 

 

On May 27, 2013, at 2:05 PM, Garrett Potts <[hidden email]> wrote:




Hello Sebastian:

 

I am a little confused on the format of the EO file.  Usually when its a UTM EO file the filed names are of the form:

 

Record Format:

 

 ID, # EVENT, TIME (s), EASTING, NORTHING, ELLIPSOID HEIGHT, OMEGA, PHI, KAPPA, LAT, LONG

 

 

But in your EO file you have:

 

Record Format:

 

 ID, # EVENT, TIME (s), X, Y, Z, ROLL, PITCH, HEADING

 

which is an EO for an ECEF output.

 

 

In yours I see header information indicating that it is suppose to be a UTM?  Can you verify that the EO file you have is properly generated for the data, or try to generate a pure ECEF EO file and try again so that the header information does not indicate a UTM.

 

 

I will keep peeping on my end as well.  Do you know the center lat lon height of the image?

 

 

Take care

 

Garrett

 

 

On May 26, 2013, at 8:57 AM, Sebastian Rohde <[hidden email]> wrote:




Dear all,

 

I am trying to create ortho-rectified images from some low oblique source images taken at around 100m above MSL.

Unfortunately, as soon as I have a roll angle above 45 degrees my call to ortho-igen ends up taking a LOT (4GB+) of memory at around 70-85% progress (reproducibly per image/sensor configuration) and crashes even afterwards. I tried to perform some debugging and it seems that the program stops working in the „recursiveResample“ function of the ossimImageRenderer.

I believe that this has something to do with calls to „rectInfo.canBilinearInterpolate“ returning false and thus splitting rectangles into four subtiles ad infinitum. Though, I don’t yet really understand what is happening here.

 

Therefore, I’d like to know:

A: Am I doing something wrong? I am new to ossim. Elevation is set up correctly as far as I can see.

B: Does anybody have an Idea what the reason for this issue might be and how I could avoid it? I know that 45 degree oblique images are far from optimal for orthorectification without a really exact surface model, but for now it’s the only data I have to test my workflow. However, these are low obliques and I cannot see a reason why this should’t work at all.

 

At the link below you may find an example dataset that produces the mentioned error.

Please look at Georef.cmd to see my commandlines for calling applanix2ogeom and ortho-igen.

To be complete, my development environment currently is Visual Studio 2010, 64 Bit. However, from my point of view it currently does not appear to be a platform issue.

 

As a side note: I was successful in modifying the Applanix ECEF model for reading msl height together with lat/long coordinates. Would that be of any interest for anyone? What is the suggested way for submitting a patch?

 

Regards,

Sebastian

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 


------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer