I don't know the internals of the programs. It's possible that nona is
actually only working on one image at a time while enblend is working
out a seam between two images (possibly more? depending on image
overlaps). Since it's already multiprocessing as it does this, my guess
is it uses signals to coordinate the seaming process.
When you have multiple enblends running via fork, maybe the signals are
no longer good for coordinating; maybe they cross from one enblend to
another enblend session. The second session might well be in a different
state than the first session, leading to confusion and errors.
Just guessing, I'm sure the enblend and nona developers are laughing
right now. ;) Anyway, I have an i9 - before that I had an i7 - and
enblend happily uses all cores and threads without me having to do anything.
On 6/28/20 7:28 PM, Jani wrote:
Thanks, I didn't realize the 2020 version was already in beta. I will
try that one. Or maybe I try to compile Hugin & tools from sources,
might be good for debugging this.
Yeah I agree with you, it looks like the multiprocessing support in
enblend somehow gets messed up when called from multiple processes. Kind
of funny. Nona works without any issues.
Jani
On Sunday, June 28, 2020 at 5:05:55 PM UTC-5, GnomeNomad wrote:
On June 28, 2020 10:35:05 AM HST, Jani <[email protected]
<javascript:>> wrote:
Background:
I'm generating (on Ubuntu 20.04 LTS & Hugin
2019.2.0.b690aa0334b5) a sequence of 12947x2483 OpenEXR
360-panoramas from 4x OpenEXR image streams of 6144x3456 each.
The good parts (nona):
Nona works well! I can fork 12 processes and speed up the "nona
-r hdr -m EXR_m -o out rig1.pto A.exr B.exr C.exr D.exr" part
from 56s per frame to 7s per frame (on average).
The problem (enblend):
To get the best final results, I need to use enblend.
I pre-saved the masks hoping it would speed up the process a bit
so using enblend like this:
enblend --load-masks=rig1/mask-%n.tif -v -f12947x2483
--output=pano0001.exr pano0001_stack_hdr_0000.exr
pano0001_stack_hdr_0001.exr pano0001_stack_hdr_0002.exr
pano0001_stack_hdr_0003.exr
Problem is that if I try to split up the enblend part to
multiple processes, enblend fails randomly with signal(2) and
signal(9). Enblend works well as long as I call it exactly from
one process at a time, so I'm very sure the issue is related to
calling it multiple times simultaneous. The file names are
prefixed uniquely with frame number so there shouldn't be any
collisions.
Right now my compromise is to split up nona part to 12 processes
and then queue up enblend part and do it frame-by-frame from a
single process. That is far from ideal because the enblend is
the bottleneck in the first place.
Any thoughts or suggestions?
Thanks,
Jani
Just some thoughts.
My understanding is enblend already supports multiprocessing. Maybe
the manual attempt at multiprocessing via fork is interfering with that?
What version of enblend are you using? There was a time when we had
to use enblend-mp to get enblend's MP support.
Hugin is up to 2020.something now. Maybe an update is in order?
--
David W. Jones
[email protected]
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/7234fe1e-ad4d-dd8f-759d-9ab2eea8e0a3%40gmail.com.
