ODM 80MP image frames as inputs

Hi all,
I’m wondering would it be possible to process 80 megapixel frames from commercial Medium Format sensors?
I’ve run some preliminary tests and can get results through up to around 65 megapixels, but get issues above this. When I attempt 80 megapixel frames I get a failure when running ‘running /code/SuperBuild/install/bin/texrecon’ specifically:

    Generating texture atlases:
        Sorting texture patches... done.
    Killed
    Traceback (most recent call last):
    ...
    File "/code/stages/mvstex.py", line 104, in process
    system.run('{bin} {nvm_file} {model} {out_dir} '
    File "/code/opendm/system.py", line 79, in run
    raise Exception("Child returned {}".format(retcode))
    Exception: Child returned 137

I’m running the latest docker and in Ec2 on a r5a.4xlarge instance (16vcpu, 128GB RAM) in Ubuntu and I’m passing all memory to the docker and unlimited swap. Any thoughts on if this is possible, or if there is a particular recipe I could try to get 80 megapixel frames through?.. or is this a little too ambitious?

Thanks in advance.
Dale

1 Like

Are you able to get adjust your VM Size for more physical memory? Maybe mvstex doesn’t play well with SWAP.

Hi @Saijin_Naib, thanks for the suggestion.
I switched my EC2 instance to a r6gd.16xlarge (64 vcpus / 512 GB RAM) and no luck. I tried this with the docker version of ODM, passing through all of the memory and unlimited swap to the docker, then I also pulled the code from git and ran it natively, and it also failed at the same spot, with the same error.
I’m wondering if I’m hitting an upper limit with mvstex / texrecon, rather than running out of memory?

1 Like

That’s where I’m leaning at the moment, too, though I’m not sure how we’d address that.

Thanks for taking the time to help us test!

Yeah, been meaning to weigh in. I’d have my money on some integer or memory allocation being too small in texturing. I won’t have bandwidth for a few weeks to look and I know Piero is on holiday for a couple weeks, so it may be a while before anyone can do a deeper dive. You could open a ticket on the MVSTexturing repo and see if there’s any bandwidth there to investigate in the interim.

1 Like

Hi Saijin_Naib & smathermather-cm, thanks both for the feedback, I really appreciate it. I’ll keep digging deeper, but will also log some tickets to see if we can get this on the backlog.
If I get anywhere with it, I’ll report back.
Thanks,
Dale

2 Likes

Hi Saijin_Naib & smathermather-cm, I followed your lead smathermather-cm and had a deeper dive into the MVSTexturing repo , and indeed there was a hardcoded upper limit. Specifically in generate_texture_atlases.cpp:
#define MAX_TEXTURE_SIZE (8 * 1024)
With that defined as the max dimension (smaller than what I was trying to push through), it kept falling over. A quick clone, update and build locally, et voila, I got some of my test data through. It was actually 60 MP (9000 x 6732), next stop seeing if I can get 80 MP through.
Thanks for the help gents.
Cheers,
Dale

3 Likes

Oh, that’s amazing!

Do you see any reason you couldn’t push the code to allow even higher resolutions?

1 Like

To be honest, I can’t pretend to understand all that’s going on in the MVSTexturing library… was lucky to stumble across this constant, and it just worked increasing it slightly. I can, and will (when I get some more data), try pushing it up higher and testing it out… it may work, I can’t really say… but I do think there was probably a reason these constants were set to what they were… but I’ll try increasing further and will see, and report back… but it wont be until I get my hands on some more data (probably not for a few days).
Cheers,
Dale

2 Likes

Sometimes they are just magic numbers that the developer figures are big enough not to be a problem (until they are), and sometimes they are there to reduce the probability of an OOM under typical conditions. I am not sure for this, but I suspect it is fine to increase.

2 Likes

Hey guys, so @ smathermather-cm, you were right, I just pushed a bunch of 100 MP imagery through and it worked a treat :slight_smile: Happy days!

Cheers,
Dale

2 Likes

So, do you think we can have an arbitrarily-sized texture, provided it remains power-of-two sized?

Pull Request when :rofl:

Yeah it would be great if we could get this parameterised some how… what would the process be, a feature enhancement request for the MVSTexturing project, and a corresponding one for ODM?.. sorry new to this.

1 Like

Ideally, we’d like to contribute what we can upstream so more folks benefit (and we reduce maintenance burden on us), so an issue/PR with OpenMVS seems like a good first move.

1 Like