Tried to build on Ubuntu Mate and got this:

/usr/include/Vc/scalar/../common/../sse/intrinsics.h:601:13: error: 
argument to '__builtin_ia32_vec_ext_v4sf' must be a constant integer
            _MM_EXTRACT_FLOAT(f, v, i);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/lib/llvm-10/lib/clang/10.0.0/include/smmintrin.h:876:11: note: 
expanded from macro '_MM_EXTRACT_FLOAT'
  { (D) = __builtin_ia32_vec_ext_v4sf((__v4sf)(__m128)(X), (int)(N)); }
          ^                                                ~~~~~~~~
1 error generated.
make: *** [makefile:61: pv_avx.o] Error 1


On Saturday, 6 March 2021 at 19:03:45 UTC Yuv wrote:

> On Wed, 2021-03-03 at 17:54 +0100, 'Kay F. Jahnke' via hugin and other
> free panoramic software wrote:
> > Am 03.03.21 um 13:27 schrieb yuv:
> > 
> > > why not adding to pv the
> > > missing functions from Hugin rather than the other way around?
> > 
> > In a way this is what I've been doing.
>
> From far away, it looks like there are four alternatives:
> (a) do nothing;
> (b) distribute pv along Hugin;
> (c) integrate pv's functionalities into Hugin; or
> (d) integrate Hugin's functionalities into pv.
>
> How far is pv from being a replacement to Hugin, and do you see it
> going there?
>
> Conversely, how different is pv from Hugin and how difficult would be
> that integration work? I suspect that the use of a different GUI
> Toolkit is a major obstacle, but your expertise my intuition wrong?
>
> Which brings us to what I understand is your proposal, to distributed
> pv along Hugin. The cost to Hugin are "only" more build/distribution
> complexity. Or am I missing something? And it does not seem to be
> such a heavy toll, based on Harry's feedback here. Do the benefits to
> Hugin's users justify the extra build/distribution complexity? And are
> there things that can be done to reduce that complexity, e.g. moving pv
> from bitbucket to the same repo as Hugin?
>
> Distributing pv along Hugin would give pv more visibility, and
> photographers would receive an additional, valuable tool in their
> toolbox. But what would it give Hugin other than more
> build/distribution complexity? Note that the question is only meant to
> be thought-provoking and does not represent an opinion. It is only the
> opinion of those who do the heavy lifting that counts; and ultimately,
> like all open source project, the driver is user's need.
>
> Hugin is already a bundle of more or less integrated tools and
> libraries. It is proof that the unix philosophy of one tool for one
> task is not universal. One such limit is a GUI workflow tool like
> Hugin, where the integration of editing / stitiching / blending tools
> has enabled usability that was not available when all of these
> functions were in isolated single-purpose tools.
>
> Does it make sense to distribute Multiblend with Hugin as well, and
> integrate it as a possible worklfow option?
>
>
> > I decided [...] to *not* use a traditional GUI library 
> > like wxWidgets or Qt
>
> Maybe that is the technical obstacle, and need reconsideration? 
> Integration is a two-way street.
>
>
> > Look at my implementation of the B&A algorithm, and compare it
> > to 'traditional' approaches, and judge for yourself:
> > 
> > https://bitbucket.org/kfj/pv/src/master/pv_combine.cc
> > 
> > Compared to traditional code, this is alien technology.
>
> I am sure there are experts in alien technology. I am not one, don't
> ask for my judgment. All I see is a beautiful and useful tool that has
> fulfilled a niche left open by the existing tools. I see the same in
> Multiblend. And I recall how Hugin started as an overall GUI to
> visualize, control, and synchronize different such specialized tools.
>
> The general question becomes: what test need to be met for a tool to:
> (a) be distributed with Hugin (the minimum common denominator)?
> (b) get a tab or other UI element within Hugin as an addition to the
> existing tabs (i.e. pv as the third view mode)?
> (c) replace a tool within Hugin (IIRC some control point finders have
> been deprecated/removed)?
>
> With a clear set of rules for the above, you'd have a target to work
> toward.
>
> I, as an external spectator who no longer has the time to shoot, edit,
> stitch panos, can only cheer from the sidelines the efforts of
> developers and builders sharing their newest development and trying to
> make them work for the rest of us. 
> --
> Yuval Levy, JD, MBA, CFA
> Ontario-licensed lawyer
>
>
>

-- 
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/668f2c79-a410-450c-8e16-342069ad0c8an%40googlegroups.com.
    • Re: [hugi... T. Modes
      • Re: [... 'Kay F. Jahnke' via hugin and other free panoramic software
    • Re: [hugi... 'Kay F. Jahnke' via hugin and other free panoramic software
  • Re: [hugin-ptx... Harry van der Wolf
    • Re: [hugi... 'Kay F. Jahnke' via hugin and other free panoramic software
      • Re: [... Harry van der Wolf
        • R... 'Kay F. Jahnke' via hugin and other free panoramic software
          • ... yuv
          • ... 'Kay F. Jahnke' via hugin and other free panoramic software
          • ... yuv
          • ... Monkey
          • ... 'Kay F. Jahnke' via hugin and other free panoramic software
          • ... Harry van der Wolf
          • ... Bruno Postle
          • ... 'Kay F. Jahnke' via hugin and other free panoramic software
          • ... yuv
          • ... Gunter Königsmann
          • ... 'Kay F. Jahnke' via hugin and other free panoramic software
          • ... yuv
          • ... 'Kay F. Jahnke' via hugin and other free panoramic software
          • ... yuv

Reply via email to