[hugin-ptx] Errors building latest hugin default source

[Terry Duell]

Hello All,
I've just attempted to do an rpmbuild of the current default source
(06c12feee548 8336 default) on Fedora 33, using my normal build methods which
have been working OK of late.
Attached is a partial listing of the rpmbuild output showing the initial error
messages.
Has anyone else had similar problems?
I thought it best to check prior to lodging a bug report, as it may be (often is
😊️) an issue at my end.

Cheers,
-- 
Terry Duell 

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/81e154636a1c003e878024d906f84dd9483bfeca.camel%40iinet.net.au.
cd 
/home/terry/rpmbuild/BUILD/hugin-2020.1.0/x86_64-redhat-linux-gnu/src/hugin_script_interface
 && /usr/bin/cmake -E cmake_link_script CMakeFiles/_hsi.dir/link.txt --verbose=1
/usr/lib64/ccache/g++ -fPIC -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g 
-DNDEBUG -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fopenmp -shared  -o _hsi.so 
CMakeFiles/_hsi.dir/CMakeFiles/_hsi.dir/hsiPYTHON_wrap.cxx.o  
-Wl,-rpath,/home/terry/rpmbuild/BUILD/hugin-2020.1.0/x86_64-redhat-linux-gnu/src/hugin_base:
 /usr/lib64/libpython3.9.so ../hugin_base/libhuginbase.so.0.0 
/usr/lib64/libpano13.so ../foreign/levmar/libhuginlevmar.a 
/usr/lib64/libGLEW.so /usr/lib64/libboost_filesystem.so 
/usr/lib64/libboost_system.so /usr/lib64/libfftw3.so 
/usr/lib64/libvigraimpex.so /usr/lib64/libImath.so /usr/lib64/libIlmImf.so 
/usr/lib64/libIex.so /usr/lib64/libHalf.so /usr/lib64/libIlmThread.so 
/usr/lib64/libz.so /usr/lib64/libjpeg.so /usr/lib64/libtiff.so 
/usr/lib64/libpng.so /usr/lib64/libz.so /usr/lib64/libz.so 
/usr/lib64/libexiv2.so /usr/lib64/liblcms2.so /usr/lib64/libjpeg.so 
/usr/lib64/libpng.so -pthread /usr/lib64/libX11.so /usr/lib64/libpano13.so 
/usr/lib64/libboost_filesystem.so /usr/lib64/libboost_system.so 
/usr/lib64/libvigraimpex.so /usr/lib64/libtiff.so /usr/lib64/libexiv2.so 
/usr/lib64/libOpenGL.so /usr/lib64/libGLX.so /usr/lib64/libGLU.so 
/usr/lib64/libGLEW.so /usr/lib64/libsqlite3.so /usr/lib64/liblcms2.so 
In file included from 
/home/terry/rpmbuild/BUILD/hugin-2020.1.0/src/hugin1/hugin/TextureManager.cpp:28:
/usr/include/wx-3.0/wx/display.h:27:28: error: aggregate 'WXDLLIMPEXP_FWD_CORE 
wxWindow' has incomplete type and cannot be defined
   27 | class WXDLLIMPEXP_FWD_CORE wxWindow;
  |^~~~
/usr/include/wx-3.0/wx/display.h:28:28: error: aggregate 'WXDLLIMPEXP_FWD_CORE 
wxPoint' has incomplete type and cannot be defined
   28 | class WXDLLIMPEXP_FWD_CORE wxPoint;
  |^~~
/usr/include/wx-3.0/wx/display.h:29:28: error: aggregate 'WXDLLIMPEXP_FWD_CORE 
wxRect' has incomplete type and cannot be defined
   29 | class WXDLLIMPEXP_FWD_CORE wxRect;
  |^~
/usr/include/wx-3.0/wx/display.h:30:28: error: aggregate 'WXDLLIMPEXP_FWD_BASE 
wxString' has incomplete type and cannot be defined
   30 | class WXDLLIMPEXP_FWD_BASE wxString;
  |^~~~
/usr/include/wx-3.0/wx/display.h:32:28: error: aggregate 'WXDLLIMPEXP_FWD_CORE 
wxDisplayFactory' has incomplete type and cannot be defined
   32 | class WXDLLIMPEXP_FWD_CORE wxDisplayFactory;
  |^~~~

Re: [hugin-ptx] Announcement - Viewer for geoaligned photographs

[giuseppe porciani]

Thank you very much: I will try.


Il giorno sab 6 mar 2021 alle ore 22:06 'H.Dersch' via hugin and other free
panoramic software  ha scritto:

> Should be possible, but it will be displayed as flat image.
>
> giuseppe...@gmail.com schrieb am Samstag, 6. März 2021 um 11:05:07 UTC+1:
>
>> Hi.
>> Thank you for posting your interesting project!
>>
>> Is it possible to use in a 360 degree cylindrical projection image?
>> Thank you,
>>
>> Giuseppe
>>
>> Il giorno ven 5 mar 2021 alle ore 16:37 'H.Dersch' via hugin and other
>> free panoramic software  ha scritto:
>>
>>> See Project Page 
>>>
>>> Not for immersive imaging, but might be interesting
>>> for this list nevertheless since
>>> * the PanoTools camera model is used. Any lens
>>> with known PanoTools parameters can be used.
>>> * PanoTools compatible software (Hugin / PTGui, ...)
>>> can be used to remap images for the viewer, and
>>> to calibrate lenses.
>>>
>>> Helmut Dersch der(at)hs-furtwangen.de March 2021
>>>
>>> --
>>> 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 hugin-ptx+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/hugin-ptx/4898a886-20db-4c1b-8be5-b3d1cd4aac15n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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 hugin-ptx+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hugin-ptx/025d720c-3937-4888-a2cf-b802ff8e748bn%40googlegroups.com
> 
> .
>

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAO0N8z07Yy4oNgyu7Ls7Fcs%2BRQL-B6dB_9uYUpZXDdhEywdEmA%40mail.gmail.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 07.03.21 um 14:16 schrieb yuv:

On Sun, 2021-03-07 at 09:22 +, Bruno Postle wrote:

currently there is a single person doing code maintenance,
collecting translations, _and_ doing the releases - these could
easily be different roles.


This!  What made Hugin great and successful in years past was the co-
operation and co-ordination of the different teams / authors to the
point of trusting and sharing full access to their respective code
repositories; being able to inter-changeably assume the different roles
for the different packages; reaching mutual agreement on repositories
and other tools to use to simplify interchangeability of roles; co-
ordinate releases, bug fixes, etc.


I felt it was difficult to keep my foot in the door. Sort of 
disheartened. Like, I got stern admonishments rather than friendly 
encouragement. I prefer to run 'my own show' now, where I don't step on 
anyone's toes.



That co-ordination seems to have gone missing, and re-building it will
require sacrifices and compromises on all ends.


I'm not sure if there is the will to rebuild stuff, much less sacrifice 
anything. I have tried to help keep my python interface afloat, but 
apart from that really I wouldn't want to touch any of hugin's code 
anymore. I'd even let that go and not be too sad about it, if someone 
came up with a better free stitcher, but I'm used to it and it does it's 
job, more or less. And I can tweak the sources locally to bend them to 
my will. And fuse my stacks separately, when hugin insists that my 
assignment of stacks is irrelevant to it's heuristic approach. When it 
comes to python, what I now use is cppyy 
(https://cppyy.readthedocs.io/en/latest/index.html), that's much cooler 
than swig.



I have just taken a half-hour stroll down memory lane.  The main
comment I have:  Why have no admins been added to Hugin / Panotools /
Enblend in ages?  My memory fades, but all the names I see are people
that were either there before me, or were added on my initiative.  Who
has taken care of the team after I moved on because life?

* have any new contributors been invited?
* if yes, why have they not accepted the invitation?
* if no, why?
* how many other contributors has the ecosystem missed? not just admins
(the highest level of access/trust).


Look at the hugin website: 'hugin is now stable'. I suppose that's the 
idea. Yes, there have been great innovations in the past few years - the 
control point tool, entering names of raw files to be converted to TIFF 
by external helper programs, a dynamic range compression button, and I 
discovered one can even use the mouse wheel to change the hfov in the 
openGL preview! And that's only mentioning the stuff that immediately 
springs to my mind!


A couple of weeks ago I even managed to unlock the positions of images 
in a stack! It was easy! I only had to find the right submenu and click 
on a bit of empty white space to get the dialog offering me to do so. 
Only took me half an hour to figure it out, with the help of looking 
through a few postings on hugin-ptx, which I would quote now if I could 
find them again with the search tool, I suppose I need other keywords 
than 'stack' and 'unlock'.



Below follow a longish (and incomplete) list of signs of what is in my
view organizational rot.  Those signs point to extra work.  I am not
asking the exisisting and dwindling team to take on that extra work.  I
am saying that the organizational rot is the consequences of the
failure to welcome and embrace new contributors.  Who wants to join a
dwindling team who does not welcome change?


Good question.


adding team members requires two thrusts:
(a) individuals inspired to become team members, to bring new energy,
new ideas, new code, and eventually change to the projects;
(b) an existing team that is welcoming new contributors and accepts the
change that they bring.

where are those thrusts?



And now for the longish list.

* why are the projects still using Mercurial?  IIRC back when the
switch to a unified VCS was made, Mercurial won because it was the one
with most even support amongst operating system (Windows!).  Meanwhile,
the landscape has shifted, git is the tool.  That would require some
flexibility from all individuals, including Kay (bitbucket? exotic! I
would not adopt it at this time).


I've been on bitbucket with all my projects for many years - for 
upstream git repos, online presence and issue tracking bitbucket is just 
fine, and I like that they are independent. They've been good to me, 
nice and helpful, and I won't turn my back on them just because they are 
'exotic'.
Downstream - that would be hugin, when it comes to pv - can be anything 
doing git. The debian science team, where I maintain vspline, has moved 
to gitlab, and I was happy about it, the old solution was a bit awkward. 
gitlab is clean and capable, I think it's a good choice. But it's 
definitely git now wherever it's hosted, I agree.



* why are the projects still on Source

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

[Gunter Königsmann]

As a user the only thing I wonder about is if multiblend2 will be the new 
default instead of enblend. And we could try harder to explain the projection 
types to the users. And we could add a mosaic wizard. Besides that I cannot 
complain.

Kind regards,

   Gunter.

Am 7. März 2021 14:16:12 MEZ schrieb yuv :
>On Sun, 2021-03-07 at 09:22 +, Bruno Postle wrote:
>> currently there is a single person doing code maintenance, 
>> collecting translations, _and_ doing the releases - these could 
>> easily be different roles.
>
>This!  What made Hugin great and successful in years past was the co-
>operation and co-ordination of the different teams / authors to the
>point of trusting and sharing full access to their respective code
>repositories; being able to inter-changeably assume the different roles
>for the different packages; reaching mutual agreement on repositories
>and other tools to use to simplify interchangeability of roles; co-
>ordinate releases, bug fixes, etc.
>
>That co-ordination seems to have gone missing, and re-building it will
>require sacrifices and compromises on all ends.
>
>I have just taken a half-hour stroll down memory lane.  The main
>comment I have:  Why have no admins been added to Hugin / Panotools /
>Enblend in ages?  My memory fades, but all the names I see are people
>that were either there before me, or were added on my initiative.  Who
>has taken care of the team after I moved on because life?
>
>* have any new contributors been invited?
>* if yes, why have they not accepted the invitation?
>* if no, why?
>* how many other contributors has the ecosystem missed? not just admins
>(the highest level of access/trust).
>
>Below follow a longish (and incomplete) list of signs of what is in my
>view organizational rot.  Those signs point to extra work.  I am not
>asking the exisisting and dwindling team to take on that extra work.  I
>am saying that the organizational rot is the consequences of the
>failure to welcome and embrace new contributors.  Who wants to join a
>dwindling team who does not welcome change?
>
>adding team members requires two thrusts:
>(a) individuals inspired to become team members, to bring new energy,
>new ideas, new code, and eventually change to the projects;
>(b) an existing team that is welcoming new contributors and accepts the
>change that they bring.
>
>where are those thrusts?
>
>And now for the longish list.
>
>* why are the projects still using Mercurial?  IIRC back when the
>switch to a unified VCS was made, Mercurial won because it was the one
>with most even support amongst operating system (Windows!).  Meanwhile,
>the landscape has shifted, git is the tool.  That would require some
>flexibility from all individuals, including Kay (bitbucket? exotic! I
>would not adopt it at this time).
>
>* why are the projects still on Sourceforge?  History is past, and they
>may have corrected they blunders.  But there is no going back and today
>Gitlab is the place to be (which would also replace Launchpad, that I
>introduced ages ago).
>
>* it pains me to see F*book promoted on the Hugin's website.  Really? 
>it surely explain less traffic to this mailing list, which means less
>potential contributors coming its way.  Don't expect an
>influencing/advertising tool that has an interest to isolate users into
>echo chambers to be a positive to this community.  if I was around the
>time that decision came up for discussion, I would have vehemently
>opposed it.
>
>* the Enblend/Enfuse website is still... mine!  What is the new
>generation of contributors waiting to leave their mark?  Last news from
>five years ago?  OK, the tool has matured and no need for new releases,
>but someone with a little bit of marketing flair could point out to the
>continued flow of Hugin releases, and now to Multiblend, a very
>interesting development?
>
>* the Panorama Tools website list the last new to almost eight years
>ago!  the latest release tarball is two years ago.
>
>I could probably find a bunch more, but the point is: encourage new
>contributors to take over and replace the current generation and take
>this community to its future with as little interference as possible
>from us oldies.  Else, the community will die when we inevitably do. 
>So please, please, please, make this a more welcoming place to new
>contributions.  Kay and Harrie are no newbies, so imagine how difficult
>this is for someone who has not been around for that long.  The
>alternative is to fade into irrelevance, which is why I asked the
>thought-provoking question of whether pv is already a replacement to
>Hugin.
>
>--
>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 hugin-ptx+unsub

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

[yuv]

On Sun, 2021-03-07 at 09:22 +, Bruno Postle wrote:
> currently there is a single person doing code maintenance, 
> collecting translations, _and_ doing the releases - these could 
> easily be different roles.

This!  What made Hugin great and successful in years past was the co-
operation and co-ordination of the different teams / authors to the
point of trusting and sharing full access to their respective code
repositories; being able to inter-changeably assume the different roles
for the different packages; reaching mutual agreement on repositories
and other tools to use to simplify interchangeability of roles; co-
ordinate releases, bug fixes, etc.

That co-ordination seems to have gone missing, and re-building it will
require sacrifices and compromises on all ends.

I have just taken a half-hour stroll down memory lane.  The main
comment I have:  Why have no admins been added to Hugin / Panotools /
Enblend in ages?  My memory fades, but all the names I see are people
that were either there before me, or were added on my initiative.  Who
has taken care of the team after I moved on because life?

* have any new contributors been invited?
* if yes, why have they not accepted the invitation?
* if no, why?
* how many other contributors has the ecosystem missed? not just admins
(the highest level of access/trust).

Below follow a longish (and incomplete) list of signs of what is in my
view organizational rot.  Those signs point to extra work.  I am not
asking the exisisting and dwindling team to take on that extra work.  I
am saying that the organizational rot is the consequences of the
failure to welcome and embrace new contributors.  Who wants to join a
dwindling team who does not welcome change?

adding team members requires two thrusts:
(a) individuals inspired to become team members, to bring new energy,
new ideas, new code, and eventually change to the projects;
(b) an existing team that is welcoming new contributors and accepts the
change that they bring.

where are those thrusts?

And now for the longish list.

* why are the projects still using Mercurial?  IIRC back when the
switch to a unified VCS was made, Mercurial won because it was the one
with most even support amongst operating system (Windows!).  Meanwhile,
the landscape has shifted, git is the tool.  That would require some
flexibility from all individuals, including Kay (bitbucket? exotic! I
would not adopt it at this time).

* why are the projects still on Sourceforge?  History is past, and they
may have corrected they blunders.  But there is no going back and today
Gitlab is the place to be (which would also replace Launchpad, that I
introduced ages ago).

* it pains me to see F*book promoted on the Hugin's website.  Really? 
it surely explain less traffic to this mailing list, which means less
potential contributors coming its way.  Don't expect an
influencing/advertising tool that has an interest to isolate users into
echo chambers to be a positive to this community.  if I was around the
time that decision came up for discussion, I would have vehemently
opposed it.

* the Enblend/Enfuse website is still... mine!  What is the new
generation of contributors waiting to leave their mark?  Last news from
five years ago?  OK, the tool has matured and no need for new releases,
but someone with a little bit of marketing flair could point out to the
continued flow of Hugin releases, and now to Multiblend, a very
interesting development?

* the Panorama Tools website list the last new to almost eight years
ago!  the latest release tarball is two years ago.

I could probably find a bunch more, but the point is: encourage new
contributors to take over and replace the current generation and take
this community to its future with as little interference as possible
from us oldies.  Else, the community will die when we inevitably do. 
So please, please, please, make this a more welcoming place to new
contributions.  Kay and Harrie are no newbies, so imagine how difficult
this is for someone who has not been around for that long.  The
alternative is to fade into irrelevance, which is why I asked the
thought-provoking question of whether pv is already a replacement to
Hugin.

--
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/0562231dc798a651f9d108242aa2553787bd31d2.camel%40levy.ch.

Re: [hugin-ptx] Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

[Sergio Amateis]

Hi David, thank you for your help.  I will try another stitch removing the 
sky's photos and generating a partial panorma.  For the sky, Hugin can't 
obvioulsy find any control point. So I have entered some points very 
roughly, just to keep the photos of the sky in the right place. Is there 
another way to position them better, perhaps manually without using control 
points?

Il giorno domenica 7 marzo 2021 alle 00:14:00 UTC+1 Monkey ha scritto:

> Sorry, I didn't get around to looking into your project too much. Neither 
> Enblend nor Multiblend can do much about such misalignments, as they come 
> from Hugin's processing of control points, and you have some problematic 
> control points in your project. If you open the Control Point table and 
> sort by distance (highest first) you'll see a lot of control points in sky 
> (click on each one to see them in the Control Point editor) with very high 
> distances, which you should delete - they are either in blue sky, which 
> can't make a good alignment and will drag the rest of the pictures out of 
> alignment, or they are on clouds which move between shots. After deleting 
> those and re-optimising, you should get a better final result - altough you 
> could use more control points on the building, rather than (for example) on 
> the tree behind it (right corner).
>
> David
>
> On Saturday, 6 March 2021 at 22:50:33 UTC ginos...@gmail.com wrote:
>
>> Hi Monkey, 
>> I have done some tests with the same 56 photos 360° Panorama I already 
>> sent to you. I have a pto with some masks to avoid bad seams on the 
>> buildings.
>> Stitching this with Multiblend is much much faster but the result is not 
>> better than the enblend one. There are stitching errors in the same zones 
>> as enblend did, just displaced a little bit. Then I tried to remove all 
>> masks and again stitch with enblend and multiblend. This time multiblend 
>> shows a few more errors than enblend, but again, results are similar.
>>
>> Aside from speed, should I find other advantages in multiblend? Is there 
>> any parameter I can try, to improve the stiching precision ?
>>
>> Thank you
>> Ginosergio
>>
>>
>> Il giorno sabato 6 marzo 2021 alle 17:50:43 UTC+1 Monkey ha scritto:
>>
>>> I uploaded both .exes to VirusTotal. 11/69 reported the x86 version as 
>>> suspect, and 1/69 reported the x64 version as suspect.
>>>
>>> I think this is just a hazard of the ubiquity of viruses. You can 
>>> probably find something that vaguely resembles some virus in any piece of 
>>> code. There's nothing particularly clever or unusual in Multiblend's code - 
>>> no self-modifying code and no built-in compiler, one of which I have 
>>> previously written and which caused a lot of false positives. It could be 
>>> something as simple as its use of threads of memory-mapped files that 
>>> raises suspicions.
>>>
>>> As for the site itself, it might be blocked just because it doesn't have 
>>> HTTPS (my current host is pretty terrible and their Let's Encrypt option 
>>> doesn't work).
>>>
>>> On Saturday, 6 March 2021 at 15:44:27 UTC ginos...@gmail.com wrote:
>>>
 Hi Monkey

 I am only writing to report that my BITDEFENDER TOTAL SECURITY: 
 - reports the site   http://horman.net/multiblend/  as dangerous, and 
 blocks it. 
 - in the zip with windows binaries, it reports multiblend_x86.exe as a 
 virus, and deletes it. (not a great problem as I think everyone is now on 
 64bit)
 I'm starting to think I'll throw Bitdefender away when my subscription 
 expires.

 I will report again after some tests with my big 360 panoramas.

 Cheers
 Ginosergio



 Il giorno sabato 6 marzo 2021 alle 13:42:13 UTC+1 Monkey ha scritto:

> Thanks Harry.
>
> On Saturday, 6 March 2021 at 12:24:17 UTC hvd...@gmail.com wrote:
>
>> And a distributable macos build for multiblend *2.0rc2*: 
>> https://mega.nz/file/lQtlgKRI#wNYpcmE4-XuZJOsXmxtBkBmB6Ekji-Vp65c38FCaGws
>> Unzip to a folder of your liking with paths. It should give:
>> multiblend-dist/
>> multiblend-dist/Libraries/
>> multiblend-dist/Libraries/libz.1.2.11.dylib
>> multiblend-dist/Libraries/libpng16.16.dylib
>> multiblend-dist/Libraries/libzstd.1.4.8.dylib
>> multiblend-dist/Libraries/libtiff.5.dylib
>> multiblend-dist/Libraries/liblzma.5.dylib
>> multiblend-dist/Libraries/libjpeg.8.2.2.dylib
>> multiblend-dist/multiblend
>>
>> Removed a few "sloppy" things from the script:  
>> https://mega.nz/file/FR9CxCpB#ucZGem59Z6n8jVP7NriuqKS9YwGvMtIok9DZqX75vro
>>
>> Harry
>>
>> Op za 6 mrt. 2021 om 13:02 schreef Monkey :
>>
>>> Fixed and updated, plus a fix to ignore (properly) an Enblend 
>>> parameter that was stopping Hugin from successfully calling Multiblend.
>>>
>>> http://horman.net/multiblend/
>>>
>>> David
>>> On Saturday, 6 March 2021 at 11:22:47 UTC hvd...@gmail.com wrote:

Re: [hugin-ptx] Alignment of multi-row images

[Mike Cowlishaw]

Thanks for the thanks :-).  Glad it was useful!

On Sun, Mar 7, 2021 at 8:54 AM Thomas Käfer  wrote:

> Thanks for publishing this. I've used what I've learned from your script
> to make this much simpler much more rigid script for a panorama poor in
> features that I'm currently trying to stich togetether:
>
> #!/bin/bash
>
> pto_gen -o scripting_step1_images.pto IMG_*.JPG
>
> # https://wiki.panotools.org/Panorama_scripting_in_a_nutshell
>
> # https://groups.google.com/g/hugin-ptx/c/ImcaDTH7KMY/m/GcHI-wNnFAAJ
> # https://wiki.panotools.org/Pto_var
> # simplified layout asuming 360° panorama
> # rows are not needed in calculation, it's assumed that rows = number of
> pictures / columns
> columns=8
> degrees_below_horizon=55 # how far below the horizon does the panorama
> start?
> field_of_view_horizontal=$((360/$columns)) # not the real field_of_view,
> subtract half of the overlap..
> echo "field_of_view_horizontal = $field_of_view_horizontal"
> field_of_view_vertical=$(($field_of_view_horizontal/4*3))
> pto_var
> --set="y=(i%$columns)*$field_of_view_horizontal,p=floor(i/$columns)*$field_of_view_vertical-$degrees_below_horizon,r=0"
> --output=scripting_step2_align_rows_and_columns.pto
> scripting_step1_images.pto
>
> pto_mask --process=CLIP --mask=mask.msk@0 --mask=mask.msk@1
> --mask=mask.msk@2 --mask=mask.msk@3 --mask=mask.msk@4 --mask=mask.msk@5
> --mask=mask.msk@6 --mask=mask.msk@7 --output=scripting_step3_masks.pto
> scripting_step2_align_rows_and_columns.pto
>
> # https://wiki.panotools.org/Cpfind
> # --multirow --sieve2width=10 --sieve2height=10 --sieve2size=20
> --minmatches=1
> cpfind --verbose --prealigned --fullscale --cache
> --output=scripting_step4_prealigned_cpfind.pto scripting_step3_masks.pto
>
> linefind --output=scripting_step5_vertical-lines.pto
> scripting_step4_prealigned_cpfind.pto
>
> # https://wiki.panotools.org/Geocpset
> geocpset --each-overlap --output=scripting_step6_geocpset.pto
> scripting_step5_vertical-lines.pto
>
> autooptimiser -a -m --output=scripting_step7_autoptimized.pto
> scripting_step6_geocpset.pto
>
> hugin scripting_step7_autoptimized.pto
>
>
> Thank you :)
>
> mfc.s...@gmail.com schrieb am Samstag, 7. November 2015 um 13:45:39 UTC+1:
>
>>
>>> Ah!!  That works perfectly!   Very many thanks.   Presumably I can add
>>> that step to the script by calling cpfind  again (with --prealigned?) ?
>>>
>>
>> Ignore that last question .. I see that won't work.
>>
>> Here, as promised, is the script I put together.  Plenty of room for
>> improvement...
>>
>> /* --- */
>> /* huginpan.rex --- run Hugin with layout hints*/
>> /* --- */
>> /* */
>> /* Call as:*/
>> /* */
>> /*   huginpan pattern lens columns rows order  */
>> /* */
>> /* where:  */
>> /* */
>> /*   pattern -- source files pattern (e.g., P*.jpg)*/
>> /*   lens-- lens length (mm, 35mm equivalent)  */
>> /*   columns -- number of images in X dimension*/
>> /*   rows-- ditto in Y */
>> /*   order   -- mapping of image sequence to rectangle */
>> /* */
>> /* pattern, lens, and columns are required */
>> /* rows default=1, order default=0 */
>> /* */
>> /* order is:   */
>> /* */
>> /*   0 -- rows, left->right, top->bottom (start top-left)  */
>> /*   1 -- columns, top->bottom, left->right (start top-left)   */
>> /* */
>> /* Before using this, it is suggested that you copy the source */
>> /* files to their own subdirectory, then run this command with */
>> /* that as the current directory.  */
>> /* */
>> /* Return codes from pto_ commands are not documented, so ignored. */
>> /* --- */
>> -- 2015.11.04 mfc initial vesrion
>> -- 2015.11.06 add lens length as parameter
>>
>> -- ensure path to Hugin 64-bit programs [needed for cpfind]
>> 'SET PATH=c:\Program Files\Hugin\bin;%PATH%'
>>
>> parse arg pattern lens columns rows order .
>> if columns='' then do
>>   

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 07.03.21 um 10:22 schrieb Bruno Postle:

On Sun 07-Mar-2021 at 10:05 +0100, Harry van der Wolf wrote:

Op za 6 mrt. 2021 om 20:03 schreef yuv:


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.


My vote would be for (b), just like Kay himself also mentions.


I think this would be good, it makes sense to have a panorama viewer in 
the Hugin bundle.  Though aside from getting it working on all 
architectures, there is a question of who maintains it once it is in the 
Hugin codebase?  There will be bugs that need fixing, weird new 
compiler/library combinations, translations etc...  Note that currently 
there is a single person doing code maintenance, collecting 
translations, _and_ doing the releases - these could easily be different 
roles.


I propose that for now I remain upstream and responsible for the code. I 
can fork out releases which I consider sufficiently stable. The hugin 
builders can simply clone my git repo, *there are already branches for 
all major platforms*. What's missing is the *platform integration* - 
like where it is installed, if it is installed at all (my Windows 
bundles are stickware, so people can just put them on a DVD alongside 
with their images and give their users a free viewer to look at them), 
what icon is displayed for it, what mime types are associated - and I 
don't know enough about Windows or macOS to provide that, and when it 
comes to Linux, I already have a debian package to maintain, so I'd be 
happy if someone else could do that part - maybe somone who can build 
AppImages or flatpaks. The hugin builders/packagers would be in a good 
position to do so, because they already know how to roll out stuff to 
their platform. Harry has demonstrated that for macOS this is not 
terribly hard to do - but I could not have done this, I don't even have 
a mac.


We don't know if pv will be well-received by the users - it may be too 
complicated, not international enough, too slow for dual core laptops... 
but throwing it out from a bundle is just as easy as putting it in and 
helping it to a wider audience. Then people can decide whether they like 
it or not. If people do like it, there will be ways to keep it afloat, 
I'm sure. I'll do my best to keep offering a stand-alone version, and 
when I get around to it, I'll try and set up a CI/CD pipeline to build 
automatically and have binary for every push, but it would be nice to 
get some help for that as well, just as Harry has done for macOS. And I 
did also propose that packagers might offer a 'flavour' of the hugin 
bundle offering my code as an addition. No reason to make an either/or 
decision.


For now I'm quite busy getting the code up to the features I intend it 
to have, and that's what I think I'm good at.


Kay

--
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/18878b08-376e-9644-3bc0-6ff4025791e5%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 07.03.21 um 10:05 schrieb Harry van der Wolf:

Sorry. Long mail.

Op za 6 mrt. 2021 om 20:03 schreef yuv


 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.


My vote would be for (b), just like Kay himself also mentions.


That's also what I would propose. The distribution process is already 
established, and building pv as yet another binary to 'ride out' with a 
hugin bundle should not be too hard - I have already put a lot of work 
into making porting easy, as you can see from the fact that we have 
proof of build and execution on Linux, macOS, Windows and even on the 
Raspi's ARM processor.


Due to my licensing, everyone who complies with the GPLv3 is of course 
free to 'rip my code apart' or fork pv, but I think there's not so much 
interest for that - maybe after some time. And I like being upstream - 
the debacle with hugin's python interface which has never made it far 
beyond linux and broke with every new release is a warning to me: I'd 
rather be responsible for my own code, remain upstream, and fork out 
'release' versions which might be packaged with hugin, if the hugin crew 
thinks that's a good idea. Packagers might also simply provide a 
'flavour' of hugin which includes pv, and let the user choose which she 
picks.




How far is pv from being a replacement to Hugin, and do you see it
going there?

Not there (yet). Hugin has way more tweaking options to create great 
looking panos. Translations for example are not supported by pv (yet?), 
and neither are masks.


That is correct. Really, pv is a panorama *viewer*, and so far the 
stitching and blending capabilities are 'nice to have' extra features. 
They are also a playground for my new technology, my library 'vspline' 
which does all the 'heavy lifting' in the background - and for it's 
application to image processing. I use pv as a showcase of how image 
processing applications can profit from vspline, and as a handy test bed 
to work on my image processing ideas. I hope that some of my development 
work turns out to be attractive to other people so that they may *want* 
to use vspline or some of pv's code - for example for blending and 
stitching. I'm making an offer.


Having an application out which exhibits desirable features may help 
popularize the underlying technology. It's interesting stuff, and it's 
sad that so far it's largely ignored - I put a lot of effort into it, 
and vspline is now quite mature and stable. Releasing it through debian 
makes new versions 'trickle down' quite slowly, that's why I enclude 
full vspline source code in pv's repo - vspline is header-only.


Next to that: The Hugin assistant makes things way more easy than 
currently in pv. Of course: also getting the most out of Hugin, as in 
pv, requires some in-depth knowledge.
Also: pv's goal is to also improve your already created images (or 
panoramas).


And to *display* them adequately. With smooth zooms and pans, QTVR-like 
control, easy snapshotting, slideshows, etc. pp. - this is pv's core 
functionality. Display your images and panoramas. Under a common 
surface, with high quality, and an interface which 'puts nothing between 
you and your images'. And with many options for experts who want to go 
'deeper'.



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?


I can't and won't say anything about the difference in code. I leave 
that to the experts.

But indeed: I see it as a supplementary tool. At least for the time being.
It can be added to Hugin as an extra app bundle (apple) or as a tool, or 
as an extra exe (on windows). Linux is of course the easiest one.
When looking at Hugin, like yuv described, Hugin is really a combination 
of all kind of tools.
Enblend and enfuse need to be dragged in (or multiblend for that 
matter). libpano13 is often too old and needs to be built as well. Both 
on windows and mac almost everything needs to be downloaded and compiled.


For me integration is not one big monolithic binary doing everything, 
but a suite consisting of nicely integrated tools via APIs.


I say it again: pv and hugin are complementary. If, eventually, it turns 
out that one may benefit from the other in a mor

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

[Bruno Postle]

On Sun 07-Mar-2021 at 10:05 +0100, Harry van der Wolf wrote:

Op za 6 mrt. 2021 om 20:03 schreef yuv:


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.


My vote would be for (b), just like Kay himself also mentions.


I think this would be good, it makes sense to have a panorama viewer 
in the Hugin bundle.  Though aside from getting it working on all 
architectures, there is a question of who maintains it once it is in 
the Hugin codebase?  There will be bugs that need fixing, weird new 
compiler/library combinations, translations etc...  Note that 
currently there is a single person doing code maintenance, 
collecting translations, _and_ doing the releases - these could 
easily be different roles.


--
Bruno

--
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/YESbYOIcJxfs4HdG%40postle.net.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

[Harry van der Wolf]

Sorry. Long mail.

Op za 6 mrt. 2021 om 20:03 schreef yuv :

>
> 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.
>
>
My vote would be for (b), just like Kay himself also mentions.


> How far is pv from being a replacement to Hugin, and do you see it
> going there?
>
> Not there (yet). Hugin has way more tweaking options to create great
looking panos. Translations for example are not supported by pv (yet?), and
neither are masks.
Next to that: The Hugin assistant makes things way more easy than currently
in pv. Of course: also getting the most out of Hugin, as in pv, requires
some in-depth knowledge.
Also: pv's goal is to also improve your already created images (or
panoramas).


> 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?
>
>
I can't and won't say anything about the difference in code. I leave that
to the experts.
But indeed: I see it as a supplementary tool. At least for the time being.
It can be added to Hugin as an extra app bundle (apple) or as a tool, or as
an extra exe (on windows). Linux is of course the easiest one.
When looking at Hugin, like yuv described, Hugin is really a combination of
all kind of tools.
Enblend and enfuse need to be dragged in (or multiblend for that matter).
libpano13 is often too old and needs to be built as well. Both on windows
and mac almost everything needs to be downloaded and compiled.

For me integration is not one big monolithic binary doing everything, but a
suite consisting of nicely integrated tools via APIs.
If you look at web technology where all kind of technologies need to be
connected, you see that APIs (or interfaces or "command line" parameters on
a local platform, if you like) are the way forward to connect and integrate
different technologies.
This also allows for developments (leaps in developments) in the separate
tools as long as the API or interfaces remains consistent. Adding an extra
option will not break anything.
I am not a programmer (weel, an amateur at best), but in my work we bring a
lot to the cloud where you have saas, paas, iaas solutions on a number of
platforms (AWS, Microsoft, Google to name the biggest ones) which you want
to talk to each other (in a safe and secure way). Nobody nowadays does
everything in one "tool".

Why not pv also? It uses the same libraries as already necessary for Hugin
and all the tools, with one "extra": Vc, and Vc needs to be of high enough
version. Which means it can be treated like libpano.

And with regard to integration: pv started as panorama viewer. In Hugin you
could add as setting: "Open created panorama in pv", just like we do with
another non-C, non WxWidgets, non-integrated tool being exiftool acting on
our created pano from our original images.
Opening pv from Hugin after creation gives you an immediate view on your
results.
And pv can in that case also give you immediate options to tweak your
created panorama.

And in 5 years or 10 years? Who knows.

Harry

-- 
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 hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/CAGARPpvdWgtwmO1mDYSju_perkzXisT-n0UUXx-tZDNpNxtxYg%40mail.gmail.com.

Re: [hugin-ptx] Alignment of multi-row images

[Thomas Käfer]

Thanks for publishing this. I've used what I've learned from your script to 
make this much simpler much more rigid script for a panorama poor in 
features that I'm currently trying to stich togetether:

#!/bin/bash

pto_gen -o scripting_step1_images.pto IMG_*.JPG

# https://wiki.panotools.org/Panorama_scripting_in_a_nutshell

# https://groups.google.com/g/hugin-ptx/c/ImcaDTH7KMY/m/GcHI-wNnFAAJ
# https://wiki.panotools.org/Pto_var
# simplified layout asuming 360° panorama
# rows are not needed in calculation, it's assumed that rows = number of 
pictures / columns
columns=8
degrees_below_horizon=55 # how far below the horizon does the panorama 
start?
field_of_view_horizontal=$((360/$columns)) # not the real field_of_view, 
subtract half of the overlap..
echo "field_of_view_horizontal = $field_of_view_horizontal"
field_of_view_vertical=$(($field_of_view_horizontal/4*3))
pto_var 
--set="y=(i%$columns)*$field_of_view_horizontal,p=floor(i/$columns)*$field_of_view_vertical-$degrees_below_horizon,r=0"
 
--output=scripting_step2_align_rows_and_columns.pto 
scripting_step1_images.pto

pto_mask --process=CLIP --mask=mask.msk@0 --mask=mask.msk@1 
--mask=mask.msk@2 --mask=mask.msk@3 --mask=mask.msk@4 --mask=mask.msk@5 
--mask=mask.msk@6 --mask=mask.msk@7 --output=scripting_step3_masks.pto 
scripting_step2_align_rows_and_columns.pto

# https://wiki.panotools.org/Cpfind
# --multirow --sieve2width=10 --sieve2height=10 --sieve2size=20 
--minmatches=1
cpfind --verbose --prealigned --fullscale --cache 
--output=scripting_step4_prealigned_cpfind.pto scripting_step3_masks.pto

linefind --output=scripting_step5_vertical-lines.pto 
scripting_step4_prealigned_cpfind.pto

# https://wiki.panotools.org/Geocpset
geocpset --each-overlap --output=scripting_step6_geocpset.pto 
scripting_step5_vertical-lines.pto

autooptimiser -a -m --output=scripting_step7_autoptimized.pto 
scripting_step6_geocpset.pto

hugin scripting_step7_autoptimized.pto


Thank you :)

mfc.s...@gmail.com schrieb am Samstag, 7. November 2015 um 13:45:39 UTC+1:

>
>> Ah!!  That works perfectly!   Very many thanks.   Presumably I can add 
>> that step to the script by calling cpfind  again (with --prealigned?) ?
>>
>
> Ignore that last question .. I see that won't work.
>
> Here, as promised, is the script I put together.  Plenty of room for 
> improvement...
>
> /* --- */
> /* huginpan.rex --- run Hugin with layout hints*/
> /* --- */
> /* */
> /* Call as:*/
> /* */
> /*   huginpan pattern lens columns rows order  */
> /* */
> /* where:  */
> /* */
> /*   pattern -- source files pattern (e.g., P*.jpg)*/
> /*   lens-- lens length (mm, 35mm equivalent)  */
> /*   columns -- number of images in X dimension*/
> /*   rows-- ditto in Y */
> /*   order   -- mapping of image sequence to rectangle */
> /* */
> /* pattern, lens, and columns are required */
> /* rows default=1, order default=0 */
> /* */
> /* order is:   */
> /* */
> /*   0 -- rows, left->right, top->bottom (start top-left)  */
> /*   1 -- columns, top->bottom, left->right (start top-left)   */
> /* */
> /* Before using this, it is suggested that you copy the source */
> /* files to their own subdirectory, then run this command with */
> /* that as the current directory.  */
> /* */
> /* Return codes from pto_ commands are not documented, so ignored. */
> /* --- */
> -- 2015.11.04 mfc initial vesrion
> -- 2015.11.06 add lens length as parameter
>
> -- ensure path to Hugin 64-bit programs [needed for cpfind]
> 'SET PATH=c:\Program Files\Hugin\bin;%PATH%'
>
> parse arg pattern lens columns rows order .
> if columns='' then do
>   say 'Pattern, lens, and columns must be specified'
>   exit -1
>   end
> if rows='' then rows=1
> if order='' then order=0
>
> -- set up constants (could be parameters or options, later)
> -- short-edge equivanet sensor size is