Using orthoigen w/o the ortho part?

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

Using orthoigen w/o the ortho part?

Andyjo

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

oscarkramer
Andy, 

Orthoigen is the app you want. It really outgrew its name and now serves a lot of purposes -- as evidenced by the extensive options list. If you leave out the projection spec from the command line (options like --srs, --geo, --utm, etc.), then orthoigen will use the same projection as the first image in the list of images being projected, provided that first image is map (or geographic) projection. You said your images are already ortho'd, presumably to a map projection so you're OK. If the first image were a sensor model projection (e.g., RPC), then orthoigen would default the product to a geographic proj.

If all the images are the same projection and GSD, you might want to try the option "--combiner-type ossimOrthoImageMosaic". That tells oigen not to use a renderer in the input chains and mosaic directly using the input pixels (they will need to be aligned at the seams). You can still specify a different output GSD and a renderer (a.k.a. resampler) will be inserted downstream of the mosaic combiner object. Warning: I never tried/tested this so it may not work, in which case just leave the combiner-type option out and play with "--resample-type" option. The default resampler I believe is nearest-neighbor.

You may need to worry about things if your mosaic is very big. For example if your input images were in UTM and spanning a couple of zones, then I'm not sure what would happen to the output. I suspect it would still work.

Good luck!
Oscar


From: Andrew D. Johnson [[hidden email]]
Sent: Thursday, June 27, 2013 18:09
To: [hidden email]
Subject: [OSSIM] Using orthoigen w/o the ortho part?

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this Communication to the intended recipient, or if you have received this Communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Garrett Potts-2
<base href="x-msg://1062/">Hello All:

To add to what Oscar has stated.

We have been contemplating "the large number of files problem" because operating systems have file pointer limitations.  The default usually for most are no more than 100 - 200  files for a user at one time can be opened.  On UNIX I tried jacking this up to around 64K but the OS itself begins to act very funny after about 1200 images opened.

For future I would love to integrate a ossimFile interface that interfaces into an ossimFilePool.  The ossimFilePool would maintain the pool and will never exceed a certain number.  If more is needed it will close out the Least recently used and allocate a file request to the calling system.

This would give us the ability to do a large number of files without having to keep all of them opened.   This would be a future consideration.

Take care

Garrett


On Jun 27, 2013, at 10:10 PM, Oscar L. Kramer <[hidden email]> wrote:

Andy,  

Orthoigen is the app you want. It really outgrew its name and now serves a lot of purposes -- as evidenced by the extensive options list. If you leave out the projection spec from the command line (options like --srs, --geo, --utm, etc.), then orthoigen will use the same projection as the first image in the list of images being projected, provided that first image is map (or geographic) projection. You said your images are already ortho'd, presumably to a map projection so you're OK. If the first image were a sensor model projection (e.g., RPC), then orthoigen would default the product to a geographic proj. 

If all the images are the same projection and GSD, you might want to try the option "--combiner-type ossimOrthoImageMosaic". That tells oigen not to use a renderer in the input chains and mosaic directly using the input pixels (they will need to be aligned at the seams). You can still specify a different output GSD and a renderer (a.k.a. resampler) will be inserted downstream of the mosaic combiner object. Warning: I never tried/tested this so it may not work, in which case just leave the combiner-type option out and play with "--resample-type" option. The default resampler I believe is nearest-neighbor.

You may need to worry about things if your mosaic is very big. For example if your input images were in UTM and spanning a couple of zones, then I'm not sure what would happen to the output. I suspect it would still work.

Good luck!
Oscar


From: Andrew D. Johnson [[hidden email]]
Sent: Thursday, June 27, 2013 18:09
To: [hidden email]
Subject: [OSSIM] Using orthoigen w/o the ortho part?

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!
-Andy

 

This electronic communication and any attachments may contain confidential and proprietary information of DigitalGlobe, Inc. If you are not the intended recipient, or an agent or employee responsible for delivering this Communication to the intended recipient, or if you have received this Communication in error, please do not print, copy, retransmit, disseminate or otherwise use the information. Please indicate to the sender that you have received this communication in error, and delete the copy you received. DigitalGlobe reserves the right to monitor any electronic communication sent or received by its employees, agents or representatives. ------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Peter Borissow
In reply to this post by Andyjo
Andy-
    Hate to sound like a broken record but why not use the .rpf image handler?


It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.


Peter



From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?
 
Thanks!
-Andy


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Andyjo

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [mailto:[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Peter Borissow
Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter





From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

Peter,
I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.
So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.
I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.
Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation
 
I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…
 
Thanks
-Andy
 
From: Peter Borissow [mailto:[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?
 
Andy-
    Hate to sound like a broken record but why not use the .rpf image handler?
 
 
It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.
 
I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!
 
If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.
 
 
Peter
 
 

From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?
 
So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?
 
Thanks!
-Andy
 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Andyjo

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [mailto:[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

David Burken
In reply to this post by Peter Borissow
Peter, Pretty sure all that's in the trunk.

Dave

On 7/2/13 4:09 AM, Peter Borissow wrote:
Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter





From: Andrew D. Johnson [hidden email]
To: Peter Borissow [hidden email]; [hidden email] [hidden email]
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

Peter,
I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.
So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.
I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.
Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation
 
I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…
 
Thanks
-Andy
 
From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?
 
Andy-
    Hate to sound like a broken record but why not use the .rpf image handler?
 
 
It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.
 
I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!
 
If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.
 
 
Peter
 
 

From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?
 
So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?
 
Thanks!
-Andy
 




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Peter Borissow
Hey Dave,
    I really don't think its in there because:

(1) Andy should be able to generate tiles using the tiling template I provided (i.e. without the delta keywords). I have an old build from the spadac/geoeye days I can share that works as advertised.


(2) Last time we talked about the delta keywords, you said:

"delta and delta_type are used to compute the output gsd or meters/degrees per pixel." ...
"Your example is missing those keywords.  Don't fight it man:-)"


(3) I talked to Oscar a couple weeks ago and he confirmed that alot of stuff still didn't get merged over


I may be wrong but perhaps you can share your copy of the spadac trunk anyway, assuming you still have it. Maybe Andy can compare the 2 baselines with respect to the tiling stuff and do a merge.



Hope all is well,
Peter





From: David Burken <[hidden email]>
To: [hidden email]
Sent: Tuesday, July 2, 2013 8:56 AM
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

Peter, Pretty sure all that's in the trunk.

Dave

On 7/2/13 4:09 AM, Peter Borissow wrote:
Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter





From: Andrew D. Johnson [hidden email]
To: Peter Borissow [hidden email]; [hidden email] [hidden email]
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

Peter,
I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.
So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.
I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.
Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation
 
I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…
 
Thanks
-Andy
 
From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?
 
Andy-
    Hate to sound like a broken record but why not use the .rpf image handler?
 
 
It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.
 
I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!
 
If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.
 
 
Peter
 
 

From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?
 
So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?
 
Thanks!
-Andy
 




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

David Burken
In reply to this post by Andyjo
Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Andyjo

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [mailto:[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter


 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev




_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Andyjo

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [mailto:[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev



_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

David Burken
Andy,

I duplicated the null output.  Let me see what happened...

Dave


On 7/2/13 10:23 AM, Andrew D. Johnson wrote:

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev



_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Andyjo

So after poking around a little…

In ossimIgen theProductProjection is updated correctly, clipRect stays the same, and tileName changes, which I believe is the correct behavior.

It looks like the writer never gets an updated ‘theAreaOfInterest’ per tile (I’m assuming it should),

I think this comes from the ImageSourceSequencer via inputConnection->getBoundingRect() in the writer

-Andy

 

 

From: David Burken [mailto:[hidden email]]
Sent: Tuesday, July 02, 2013 10:51 AM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

I duplicated the null output.  Let me see what happened...

Dave


On 7/2/13 10:23 AM, Andrew D. Johnson wrote:

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter


 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev




_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

David Burken
They're using a cutter, i.e.  ossimRectangleCutFilter.  So the area of interest gets pulled from the input.  I'm looking at this now...
Dave


On 7/2/13 1:29 PM, Andrew D. Johnson wrote:

So after poking around a little…

In ossimIgen theProductProjection is updated correctly, clipRect stays the same, and tileName changes, which I believe is the correct behavior.

It looks like the writer never gets an updated ‘theAreaOfInterest’ per tile (I’m assuming it should),

I think this comes from the ImageSourceSequencer via inputConnection->getBoundingRect() in the writer

-Andy

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 10:51 AM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

I duplicated the null output.  Let me see what happened...

Dave


On 7/2/13 10:23 AM, Andrew D. Johnson wrote:

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter


 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev




_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

Andyjo

Dave,

Just thinking out loud here so I understand how it works:

It starts w/ the AOI from the inputs, then starts applying things sequentially from the image chain, in this case the RectangleCutFilter if the first item in the image chain list (per theProductChain->addFirst(cut);), so it should get chopped down to 10x10px, and eventually the file gets written.

 

I guess it’s a little deeper than I’ve looked so far, but where does the image chain get executed? I expected to find something in ossimImageFileWriter like this (in horrible python representation):

for chain in image_chain:

chain.execute()

 

Thanks

-Andy

 

From: David Burken [mailto:[hidden email]]
Sent: Tuesday, July 02, 2013 1:35 PM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

They're using a cutter, i.e.  ossimRectangleCutFilter.  So the area of interest gets pulled from the input.  I'm looking at this now...
Dave


On 7/2/13 1:29 PM, Andrew D. Johnson wrote:

So after poking around a little…

In ossimIgen theProductProjection is updated correctly, clipRect stays the same, and tileName changes, which I believe is the correct behavior.

It looks like the writer never gets an updated ‘theAreaOfInterest’ per tile (I’m assuming it should),

I think this comes from the ImageSourceSequencer via inputConnection->getBoundingRect() in the writer

-Andy

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 10:51 AM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

I duplicated the null output.  Let me see what happened...

Dave


On 7/2/13 10:23 AM, Andrew D. Johnson wrote:

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter



 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 





------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev





_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

 

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

David Burken
It's in:

ossimIgen::writeToFile

   try
   {
      writer->execute();
   }

First bug I found is when I turn on trace for:  "ossimIgen:log" this call wrecks my writer!

 writer->fillContainer(*container.get());

Dave



On 7/2/13 1:51 PM, Andrew D. Johnson wrote:

Dave,

Just thinking out loud here so I understand how it works:

It starts w/ the AOI from the inputs, then starts applying things sequentially from the image chain, in this case the RectangleCutFilter if the first item in the image chain list (per theProductChain->addFirst(cut);), so it should get chopped down to 10x10px, and eventually the file gets written.

 

I guess it’s a little deeper than I’ve looked so far, but where does the image chain get executed? I expected to find something in ossimImageFileWriter like this (in horrible python representation):

for chain in image_chain:

chain.execute()

 

Thanks

-Andy

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 1:35 PM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

They're using a cutter, i.e.  ossimRectangleCutFilter.  So the area of interest gets pulled from the input.  I'm looking at this now...
Dave


On 7/2/13 1:29 PM, Andrew D. Johnson wrote:

So after poking around a little…

In ossimIgen theProductProjection is updated correctly, clipRect stays the same, and tileName changes, which I believe is the correct behavior.

It looks like the writer never gets an updated ‘theAreaOfInterest’ per tile (I’m assuming it should),

I think this comes from the ImageSourceSequencer via inputConnection->getBoundingRect() in the writer

-Andy

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 10:51 AM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

I duplicated the null output.  Let me see what happened...

Dave


On 7/2/13 10:23 AM, Andrew D. Johnson wrote:

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote:

I’m very open to using rpf, especially since my current method is to generate my 1sqkm ‘tiles’, then figure out horizontal strips of them, stitch those together, and then merge the horizontal strips into the full mosaic.

Going from my ‘tiles’ to a full mosaic would be great!

 

I’ve been playing with the tiling template a little, but haven’t had any great luck yet, and the other problem is that I need a portable solution, so I can distribute my tiles to other systems once the cuts are figured out. I might be able to hook into the tiling code and do a save state and go from there…

 

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Tuesday, July 02, 2013 4:10 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Well, it sounds like you are open to the .rpf solution if you could somehow create the tiles. Perhaps Dave Burken or Oscar can share the code we wrote for that a couple years ago? We did some extensive work with tiling templates. I don't think any of that made its way into the osgeo trunk. Your tiling template should be as simple as this:


igen.tiling.tile_size: 512 512
igen.tiling.use_offset: 0.0 0.0
igen.tiling.padding: 0.0 0.0
igen.tiling.units: pixel
igen.tiling.clip_to_aoi: true
igen.tiling.output_file_name: %r%_%c%.jpg


No delta keywords or anything that complicated.


Oscar had prepared a huge merge a couple years ago but was a little skiddish to commit because he didn't want to break anything on the osgeo side. Dave should have all the code as well. Not sure what else to suggest if you want to stay within the confines of ossim.


Good Luck!
Peter



 

 


From: Andrew D. Johnson <[hidden email]>
To: Peter Borissow <[hidden email]>; "[hidden email]" <[hidden email]>
Sent: Monday, July 1, 2013 5:57 PM
Subject: RE: [OSSIM] Using orthoigen w/o the ortho part?

 

Peter,

I gave RPF a try a while back, but ended up having issues tiling ‘perfectly’ like is required. The other problem is that my area is so large, and there are so many overlapping images that I had to break up my ‘tiles’ into ~1sqkm blocks, and distribute to multiple machines (so no one process does it all). To do this I build a ossimDrect for my boundaries, and then chop it up. At first I was using ossimGrect:: computeEvenTiles() but it calls stretchToEvenBoundary, which I didn’t like because it does exactly what it says… clamps up/down (floor/ceil), and I wanted a tight area around my imagery.

So long story short, I took the computeEvenTiles code, ditched the stretching, and built tiles that way, the only problem is they’re never perfect to on the # of pixels, which breaks *.rpf – also I’m using this code to spit out cut arguments to pass into orthoigen, so sometimes there is some rounding error, since I only write out ~14 decimal points.

I was playing around with using –cut-box-ll, along with –cut-pixels-width-height, and forcing the GSD.. but haven’t have very good success yet.

Looking at the tiling template stuff, it doesn’t look like I could just give it an area, and # of x/y tiles, and tell it to give me back the exact boundaries. But perhaps I can look at the ossimTiling code a little closer and see if I can pull that and make that work for this situation

 

I played around with gdal_merge.py a little bit, it seems to works pretty well, but I’d rather use the ossim framework, since everything else I build is using it…

 

Thanks

-Andy

 

From: Peter Borissow [[hidden email]]
Sent: Monday, July 01, 2013 9:58 AM
To: Andrew D. Johnson; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy-

    Hate to sound like a broken record but why not use the .rpf image handler?

 

 

It can easily process tens of thousands of files. I know it requires a little more prep work but it's still a valid solution.

 

I think we gave up on it last time because you ran into an issue creating the image tiles. As I recall, you were getting black borders or something because the tiling template we were using. If you can't clip the images correctly using ossim, maybe you can try using gdal? Once you have your image tiles you should be good to go!

 

If you like, I can also share with you my ossim binaries. Its a windows x64 from a couple years ago but the rpf image handler definitely works.

 

 

Peter

 

 


From: Andrew D. Johnson <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 6:09 PM
Subject: [OSSIM] Using orthoigen w/o the ortho part?

 

So I have a ton of tiles, about 1km^2 each, and I’d like to mosaic them together. I’ve been told before to not use ossim-mosaic…. So what should I use? My tiles are already orthorectified, so if I run them through orthoigen again wouldn’t that re-orthorectify the end product?

 

Thanks!

-Andy

 

 





------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
 
Build for Windows Store.
 
http://p.sf.net/sfu/windows-dev2dev





_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

 

 

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
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: Using orthoigen w/o the ortho part?

David Burken
In reply to this post by Andyjo
Andy,

Fixed it just now.   Let me clean up the code and I'll check it in.  Did:

// t1.kwl:
// Thirty km tiles with a pixel size of 15 meters (2k x 2k tiles):
igen.tiling.type: ossimTiling
igen.tiling.tiling_distance: 30000 30000
igen.tiling.tiling_distance_type: meters
igen.tiling.delta: 15 15
igen.tiling.delta_type: per_pixel
igen.tiling.tile_name_mask: tile_%r%_%c%
igen.tiling.padding_size_in_pixels: 0 0

// Output tiles:
$ ossim-orthoigen -w tiff_tiled_band_separate --utm --tiling-template t1.kwl l71024031_03119990929_hpn.fst outputs/test.tif

// Prune null output tiles:
$ cd outputs
$ for i in `ls *.tif`; do ossim-prune $i; done

// Build overviews/histograms:
ossim-preproc -o --ch *.tif

Dave

On 7/2/13 1:51 PM, Andrew D. Johnson wrote:

Dave,

Just thinking out loud here so I understand how it works:

It starts w/ the AOI from the inputs, then starts applying things sequentially from the image chain, in this case the RectangleCutFilter if the first item in the image chain list (per theProductChain->addFirst(cut);), so it should get chopped down to 10x10px, and eventually the file gets written.

 

I guess it’s a little deeper than I’ve looked so far, but where does the image chain get executed? I expected to find something in ossimImageFileWriter like this (in horrible python representation):

for chain in image_chain:

chain.execute()

 

Thanks

-Andy

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 1:35 PM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

They're using a cutter, i.e.  ossimRectangleCutFilter.  So the area of interest gets pulled from the input.  I'm looking at this now...
Dave


On 7/2/13 1:29 PM, Andrew D. Johnson wrote:

So after poking around a little…

In ossimIgen theProductProjection is updated correctly, clipRect stays the same, and tileName changes, which I believe is the correct behavior.

It looks like the writer never gets an updated ‘theAreaOfInterest’ per tile (I’m assuming it should),

I think this comes from the ImageSourceSequencer via inputConnection->getBoundingRect() in the writer

-Andy

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 10:51 AM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

I duplicated the null output.  Let me see what happened...

Dave


On 7/2/13 10:23 AM, Andrew D. Johnson wrote:

Some more information… ran it w/ trace on ossimTiling:

It looks like it thinks there is only one band?! I’ll dig around to see if there’s a flag to set the number…

 

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,1,1,LH)

theTilingRect:                   (0,0,1,1,LH)

theTileId:                       -1

theTotalHorizontalTiles:         0

theTotalVerticalTiles:           0

theTotalTiles:                   0

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

theMapProjection is not set.

ossimTiling::initialize DEBUG: Entered...

Bounding rect === (0,0,26791,21956,LH)

theTilingDistance:                 ( 10.000000000000000, 10.000000000000000 )

theTilingDistanceUnitType:       1

theDelta:                        ( 1.000000000000000, 1.000000000000000 )

theDeltaType:                    1

thePaddingSizeInPixels:          ( 0.000000000000000, 0.000000000000000 )

theImageRect:                    (0,0,26791,21956,LH)

theTilingRect:                   (324200,4733420,1321,1081,RH)

theTileId:                       0

theTotalHorizontalTiles:         132

theTotalVerticalTiles:           108

theTotalTiles:                   14256

theTileNameMask:                 tile_%r%_%c%.tif

theOutputSizeInBytes:            0

theNumberOfBands:                1

theNumberOfBytesPerPixelPerBand: 1

theEdgeToEdgeFlag:               0

// ossimUtmProjection::print

theZone:  19

theHemisphere:  N

 

// ossimMapProjection::print

type:  ossimUtmProjection

major_axis:  6378137.000000000000000

minor_axis:  6356752.314199999900000

origin_latitude:  0.000000000000000

central_meridian:  -69.000000000000000

origin: ( 0.000000000000000, -69.000000000000000, 0.000, WGE )

datum:  WGE

meters_per_pixel_x:  0.0488649186085659

meters_per_pixel_y:  0.0488576196957212

false_easting_northing: (500000,0)

false_easting_northing_units: meters

pcs_code: 32619

tie_point_xy: (324200.995997693,4734492.80057514)

tie_point_units: meters

pixel_scale_xy: (0.0488649186085659,0.0488576196957212)

pixel_scale_units: meters

ossimErrorStatusInterface::print

theErrorStatus:         0

theErrorStatus string:  OSSIM_OK

 

theMapProjection:

0000000056FDC428

 

ossimTiling::initialize DEBUG: Leaving...

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324200,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_0.tif

origin                        = ( 324200.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324210,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_1.tif

origin                        = ( 324210.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324220,4734500)

type:  ossimUtmProjection

zone:  19

 

tileName                      = tile_0_2.tif

origin                        = ( 324220.000000000000000, 4734500.000000000000000 )

<edited out progress>

100%

ossimTiling::next DEBUG: rect = (0,0,10,10,LH)

proj                          = central_meridian:  -69

datum:  WGE

elevation_lookup_flag:  0

ellipse_code:  WE

ellipse_epsg_code:  7030

ellipse_name:  WGS 84

false_easting_northing:  (500000,0)

false_easting_northing_units:  meters

hemisphere:  N

major_axis:  6378137

minor_axis:  6356752.3142

origin_latitude:  0

pcs_code:  32619

pixel_scale_units:  meters

pixel_scale_xy:  (1,1)

srs_name:  EPSG:32619

tie_point_units:  meters

tie_point_xy:  (324230,4734500)

type:  ossimUtmProjection

zone:  19

etc...

 

From: Andrew D. Johnson [[hidden email]]
Sent: Tuesday, July 02, 2013 9:51 AM
To: David Burken; [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Dave, i‘ve looked at those examples before, and always ended up with black images.

I ran an svn update as well, and it looks like I’m up to date w/ trunk

 

Here’s my setup:

Have a *.src file w/ 35 files, all have an associated geometry file (buckeyeSensorModel)

I save off the tiling template:

igen.tiling.type: ossimTiling

igen.tiling.tiling_distance: 10 10

igen.tiling.tiling_distance_type: meters

igen.tiling.delta: 1 1

igen.tiling.delta_type: per_pixel

igen.tiling.tile_name_mask: tile_%r%_%c%.tif

igen.tiling.padding_size_in_pixels: 0 0

 

From that I assume I’m going to end up with tiles that are 10x10 meters, 10x10 pixels, since it’s 1 ‘delta’ per pixel (1 pix = 1 meter), named tile_0_0.tif, etc…

Because I chose meters I have to force –utm (get: “Map projeciton requires tiling in angular units but the spacing is in non angular” otherwise)

So here’s my final command line construction:

ossim-orthoigen -w tiff_strip --utm --tiling-template E:\10x10m_1m_gsd.kwl E:\test_src_file.src E:\tiling_template_output_goes_here

 

When I run that I end up with a ton of 3.3gb tif’s, until the hard drive is full….. named appropriately, but they’re all black.

-rwx------+ 1 Users None 3428071810 Jul  2 09:39 tile_0_0.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_1.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_2.tif

-rwx------+ 1 Users None 3428071810 Jul  2 09:40 tile_0_3.tif

Etc…

 

Info on the first few files… It looks like the corners are moving a little… the gsd is correct, but the image size is crazy

 

Could it be that I’m reading from jp2s?

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87881898996509e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281194048797

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9904766379485

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355432,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6469243625603

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6469243625603

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.909422974849

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87882991327141e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7281979706608

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9905555633219

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355422,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470029685996

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470029685996

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.90950194482

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

ossim-info tile_0_0.tif

image0.band0.max_value:  255

image0.band0.min_value:  1

image0.band0.null_value:  0

image0.band1.max_value:  255

image0.band1.min_value:  1

image0.band1.null_value:  0

image0.band2.max_value:  255

image0.band2.min_value:  1

image0.band2.null_value:  0

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0

image0.geometry.decimal_degrees_per_pixel_lon:  7.87884083655128e-006

image0.geometry.decimations:  (1,1)

image0.geometry.gsd:  (1,1)

image0.geometry.image_size:  (33318,34291)

image0.geometry.ll_lat:  90

image0.geometry.ll_lon:  -32.7282765365502

image0.geometry.lr_lat:  90

image0.geometry.lr_lon:  -32.9906344888028

image0.geometry.meters_per_pixel_x:  1

image0.geometry.meters_per_pixel_y:  1

image0.geometry.projection.central_meridian:  -69

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (500000,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.hemisphere:  N

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  32619

image0.geometry.projection.pixel_scale_units:  meters

image0.geometry.projection.pixel_scale_xy:  (1,1)

image0.geometry.projection.srs_name:  EPSG:32619

image0.geometry.projection.tie_point_units:  meters

image0.geometry.projection.tie_point_xy:  (-3355412,103241837)

image0.geometry.projection.type:  ossimUtmProjection

image0.geometry.projection.zone:  19

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  90

image0.geometry.tie_point_lon:  -32.6470815747485

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  90

image0.geometry.ul_lon:  -32.6470815747485

image0.geometry.ur_lat:  90

image0.geometry.ur_lon:  -32.9095809148999

image0.lr_x:  33317

image0.lr_y:  34290

image0.number_decimation_levels:  1

image0.number_input_bands:  3

image0.number_lines:  34291

image0.number_output_bands:  3

image0.number_samples:  33318

image0.radiometry:  8-bit

image0.type:  ossimTiffTileSource

image0.ul_x:  0

image0.ul_y:  0

number_entries:  1

 

 

From: David Burken [[hidden email]]
Sent: Tuesday, July 02, 2013 9:18 AM
To: [hidden email]
Subject: Re: [OSSIM] Using orthoigen w/o the ortho part?

 

Andy,

Here's some templates if you haven't seen:

// Meters:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen3.kwl

// Degrees:
http://trac.osgeo.org/ossim/browser/trunk/ossim/etc/templates/orthoigen4.kwl

Dave

On 7/2/13 8:41 AM, Andrew D. Johnson wrote: