Seamlines on Orthophoto - Specific image regions on orthophotos

Hi community,

After generating an orthophoto, I would like to understand if it’s possible to know which image and specifically what part of that image was used to generate the corresponding area within the orthophoto. Is it possible to pull this information?

I would like to know the image name and specifically the pixel region (numbers) within that image used to generate the ortho.

I’ve heard of this function referred to as seamlines. An orthophoto created from 300 images with the seamlines overlaid on it will look like a checkerboard with 300 squares, sometimes odd shaped polygons. Each tile of the checkerboard representing the individual images used to display that region of the orthophoto.

Any support here would be super, duper appreciated!

Thanks,

1 Like

There is no function to do it directly, but it is possible with a small modification to the mvs-texturing library to texture with the image boundaries rather than the texture itself. See this issue for some bread crumbs that will lead you in the right direction:

2 Likes

Excellent. I’ll dig into this. Thank you so much for the support. R

1 Like

I know I’m not alone in thinking that having Orthophoto Seamlines as an extra output product behind a flag would be an amazing addition!

Would you be able to help bring that to fruition?

Morning Saijin,

Definitely interested in trying. Would you be able to recommend next steps?

Thanks,

1 Like

I am going to be next to useless for that, sadly. I can’t really code haha. I think Piero and Stephen will be your best resources.

However, with a ton of hand-waving, I’d say looking where Stephen pointed you in OpenMVS, investigating how we define flags/arguments in ODM/opendm/config.py to create something like --orthophoto-seamlines and dump them to a format we use for other products. I’d personally like to see them as Geopackage so we’re not limited to 10char attribute names, can mix/match geometry types in one table, etc.

Then, I think we’d need to figure out where the --orthophoto-seamlines should go. First-blush, I’d say right next to the orthophoto in the output folder.

For extra extra niceness, it’d be neat to add the seamline overview into the Report PDF as a new page. Might not always be legible on 8.5x11, but still could be quite useful.

Copy that. I am keen on developing this functionality but our team doesn’t have any C++ coders. You mentioned Piero and Stephen, would you be able to help get me in contact with them? Funding development of this functionality through a community member who is an experienced C++ dev would be amazing.

1 Like

We’ve disabled @ notifications in the forum software, but if you’d like I can setup a private message thread between us all to chat in to get the ball rolling. Check your notifications later, if you wouldn’t mind :slight_smile:

Happy to help in whatever way possible. That said, this is (almost) entirely a python problem to solve, not a C++ problem. The flag is already there in OpenMVS to generate the texture as seamlines (write_view_selection_model). It does include some index numbers that would need to be commented out (or a flag added to optionally comment out).

So, the steps are as follows:

  • C++:
    • Comment out or add flag to selectively apply section in openMVS that uses index numbers to label texture boundaries per the issue I linked to above. That line is after 217.
  • Python:
    • Write appropriate code in opendm/config.py, stages/odm_seamlines (or similar) etc. to generate directory tree, call openMVS with texture boundary flag, use that output in a copy of textured model, etc.
    • Optionally write out a separate orthophoto by orthorectifying the new textured mesh.

The C++ portion is sufficiently simple to modify, I would be surprised if you needed a C++ dev.

Edit: I am saying that in a non-judgmental way and as someone who has very little C++ experience, only slightly more acuity in python, and nevertheless have munged my way through a hack version of this problem in the past. It seems a harder problem than it is, until you realize that the core of it is already solved in openMVS and just needs exposure in the rest of ODM.

1 Like