Yeah it shouldn't work like that. The parent gets process id of the forked process (or thread) and can coordinate directly using those. I am guessing the issue is related to some shared resource e.g. dynamically linked library. Enblend on Windows seem to work, I have only issues with the Linux build.
On Tuesday, June 30, 2020 at 12:25:49 PM UTC-5, GnomeNomad wrote: > > I wasn't referring to enblend coordinating with nona. I was referring to > one enblend somehow interacting (via signals) with one or more of the > forked enblends. > > On June 30, 2020 6:25:53 AM HST, Jani <[email protected] <javascript:>> > wrote: > >As far as I can tell from Hugin execution log, enblend is never > >executed > >same time as nona. So they don't coordinate anything but enblend is > >(optional) post-processing step. Nona seems to have internal blending > >functionality as well, it's just that enblend produces higher quality > >output at least in my case. > > > >On Monday, June 29, 2020 at 10:33:05 PM UTC-5, GnomeNomad wrote: > >> > >> 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] <javascript:> > wandering the landscape of god > http://dancingtreefrog.com > > Sent from my Android device with F/LOSS K-9 Mail. > -- 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/b8c60ac9-e527-4186-8db6-8eb96db4c58bo%40googlegroups.com.
