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?
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?
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.
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
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
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
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.
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.
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.
Happy days!