24.04

[smathermather]

No description provided.

[NathanMOlson]

We should change the following to point away from my personal account before merging this PR. Should I open PRs to each of these repos? If so, should I target them to the main branch, or something else?

• Entwine
• mvs-texturing
• OpenSfM
• PDAL
• pdal-python (upstream)
• draco
• untwine (upstream)

For python dependencies, I've used pip install with --break-system-packages. Is this acceptable? Does anyone know how to do this better?

[smathermather]

We should change the following to point away from my personal account before merging this PR. Should I open PRs to each of these repos? If so, should I target them to the main branch, or something else?

Yes, this pull request isn't ready to merge as-is, but wanted to bundle this as such because it gives us some nominal testing of build by default as well as a place to track changes and discussion.

• Entwine
• mvs-texturing
• OpenSfM
• PDAL
• pdal-python
• draco (currently pointing upstream, which works for my use case but will break some things for others I think)
• untwine (currently pointing upstream, which works for my use case but will break some things for others I think)

Each of these either needs the ODM specific mods upstreamed where appropriate (e.g. Entwine / Untwine) as Piero indicated or for where that isn't appropriate (e.g. OpenSfM / mvs-texturing), then it needs accompanied by pull requests against OpenDroneMap's forks.

It is also appropriate to keep this scoped to only pull requests against OpenDroneMap's forks, with an eye to upstreaming as a next step.

For python dependencies, I've used pip install with --break-system-packages. Is this acceptable? Does anyone know how to do this better?

Not sure. Since we discourage use outside a container, this might be ok. Although until we have an ODM repo maintainer recruited, that's a change I wouldn't endorse without someone more knowledgeable weighing in on the implications. Were you unable to get it to build without?

[NathanMOlson]

Not sure. Since we discourage use outside a container, this might be ok. Although until we have an ODM repo maintainer recruited, that's a change I wouldn't endorse without someone more knowledgeable weighing in on the implications. Were you unable to get it to build without?

I was unable to get it to build without this flag. This is related to how newer versions of Python prefer to relate to system-installed files. https://stackoverflow.com/questions/75608323/how-do-i-solve-error-externally-managed-environment-every-time-i-use-pip-3

[NathanMOlson]

I just attempted to open a PR to the ODM fork of PDAL, but was rejected with this message:

Pull request creation failed. Validation failed: must be a collaborator.

Any guidance on how I can contribute?

[smathermather]

Any guidance on how I can contribute?

I will be offline until Monday, but will check back in then. Just to verify: you did the pull request from your fork of a PDAL repo?

I added classic branch protection rules to the relevant repos (either to main or master) in the meantime. Hopefully this resolves it. Otherwise I'll dive in Monday.

[NathanMOlson]

I will be offline until Monday, but will check back in then. Just to verify: you did the pull request from your fork of a PDAL repo?

I added classic branch protection rules to the relevant repos (either to main or master) in the meantime. Hopefully this resolves it. Otherwise I'll dive in Monday.

Thanks! I originally created a PR from PDAL/PDAL (which does not work), but have now successfully created a PR from NathanMOlson/PDAL.

I'm not sure I understand the branching strategy for all these repos, a pointer to documentation or a brief description of the nominal workflow for making changes would be helpful.

[NathanMOlson]

Re: 9806d91: This pattern is an option when there are only a few minor changes. We use the upstream repository and apply a patch.

This seems like an improvement to me, because I can bump the upstream version, or apply changes to it, without having to send PRs to multiple repos. When the changes are simple, it also seems easier to see exactly what has changed.

I don't think this is a good pattern when the changes are large, like OpenSfM or mvs-texturing.

[smathermather]

Re: 9806d91: This pattern is an option when there are only a few minor changes. We use the upstream repository and apply a patch.

I agree this is a good approach when the changes are small.

[NathanMOlson]

@smathermather Do you have a preferred pattern for PRs to the ODM repos that fork outside projects?

My preference would be to have a main branch that tracks the upstream main branch, and an ODM (or develop) branch that tracks main plus whatever modifications ODM requires. Then ODM would pull from these forks using a git tag or commit hash, rather than branch name as seems to be the current pattern.

For this effort, I think it would make most sense to create the ODM branch from upstream main, so we can review the ODM-specific changes rather than all the changes that have happened upstream.

If we go this way, I think the workflow for each repo would be:

1. Sync main branch with upstream main. (@smathermather or someone else with write privileges)
2. Create ODM branch from main. (@smathermather or someone else with write privileges)
3. Port ODM-specific changes, issue pull request to ODM branch (@NathanMOlson)
4. Review changes and merge (@smathermather or someone else with write privileges)
5. Update this PR to point to the commit hash of ODM branch after the merge (@NathanMOlson)

This will need to happen for entwine, OpenSfm, mvs-texturing, and draco.

This is just one approach and I'm happy to do something different. @smathermather Let me know if there's a different approach I should take. If we follow my approach, the first two steps in each repo are on you :)

[NathanMOlson]

I've got PRs open for OpenSfM, mvs-texturing, entwine, and draco.

So far I've only made changes to support the Docker build. Changes will also be required for Mac and Windows, but I don't have dev/test environment for those. Any ideas for extending support to Mac and Windows?

[smathermather]

I've got PRs open for OpenSfM, mvs-texturing, entwine, and draco.

Excellent. I'll dive in a bit more on testing.

So far I've only made changes to support the Docker build. Changes will also be required for Mac and Windows, but I don't have dev/test environment for those. Any ideas for extending support to Mac and Windows?

Good question. I'll tag in @Saijin-Naib.

[smathermather]

On draco -- did the bot-proposed changes make sense and do they function as expected? That likely doesn't cross our threshold for prompt engineering (which is good), but I'm not qualified to review the impact of those changes, so I'm hoping you've checked them carefully.

[NathanMOlson]

On draco -- did the bot-proposed changes make sense and do they function as expected? That likely doesn't cross our threshold for prompt engineering (which is good), but I'm not qualified to review the impact of those changes, so I'm hoping you've checked them carefully.

One of the recommendations was a legitimate performance enhancement. I was indifferent to the other two, they seemed like purely stylistic changes. I accepted them because I thought it would help the PR get merged.

I manually reviewed the changes and ran the unit tests that I wrote for this functionality, so I'm confident that the changes are functional.

[smathermather]

I've got PRs open for OpenSfM, mvs-texturing, entwine, and draco.

To verify: if I test and build on NathanMolson/ODM:24.04, I should be testing with the same library versions that are present on the pull requests, correct?

[NathanMOlson]

To verify: if I test and build on NathanMolson/ODM:24.04, I should be testing with the same library versions that are present on the pull requests, correct?

Not quite, I've let them fall a few commits behind. I will make it so and let you know.

[NathanMOlson]

@smathermather the external libraries are up-to-date.

[smathermather]

@smathermather the external libraries are up-to-date.

Pulled in latest and now the build fails on my machine. I kicked off a docker build here so you can take a look. I haven't dug in yet as I was mostly off yesterday.

[NathanMOlson]

It's building again.

[smathermather]

@Saijin-Naib, this is ready for testing on Windows / Mac builds. Do you have time this week to dive in? I'm still testing the docker build, but it's looking quite good.

[Saijin-Naib]

As long as we have built binaries from the pipeline, I'm good to test

[NathanMOlson]

@Saijin-Naib The windows build is not building yet. I haven't worked on it because I don't have a Windows dev environment.

Could I have permission to run Github actions on this repo? That would let me test Windows changes. Does ODM have enough build minutes for me to use a bunch on versions that won't build?

[smathermather]

@NathanMOlson -- sent an invite.

[NathanMOlson]

Thanks, I'll see how far I can get this week. I don't have much experience developing for Windows so any help will be appreciated.

I notice the Github actions tell us this:

Windows Server 2019 has been retired. The Windows Server 2019 image has been removed as of 2025-06-30.
For more details, see https://github.com/actions/runner-images/issues/12045
--
The windows-2019 runner image is being deprecated, consider switching to windows-2022(windows-latest) or windows-2025 instead.
For more details see https://github.com/actions/runner-images/issues/12045.

Do we need to keep supporting windows-2019, or should I switch to windows-2022 (or windows-2025)?

Also, I notice there's a configure_macos.sh. Do we still support Mac?

[smathermather]

The build on window-2019 works, but unless we want to tether in an off-github build environment, we have to migrate.

I don't have strong opinions on 2022 vs 2025 vs window-latest (which is currently 2022 moving to 2025). I suppose, if it gets solved for 2022, and then we also find it works for 2025, we pin it to 2025 or latest. But we can cross that bridge once it works on 2022.

And yes: we still support mac.

[Saijin-Naib]

I like tracking latest. One way or another, any issues in a newer release will bite us, and staying behind is not sustainable.

If we keep up, at least we have a chance to pin a prior version for a cycle if needed and get back out ahead again.

[smathermather]

I like tracking latest. One way or another, any issues in a newer release will bite us, and staying behind is not sustainable.

If we keep up, at least we have a chance to pin a prior version for a cycle if needed and get back out ahead again.

Yes, I like this. Run with latest and get notified early for any breaking changes. Pin if/when needed.

[smathermather]

@Saijin-Naib -- do we have any thermal and MS datasets I can test with? I have limited of each.

[Saijin-Naib]

I'll need to dig, but likely internal usage only.