Hugin++ : fast geometrical optimization and other features

[Florian Königstein]

Hugin++ is a fork of Hugin that is linked to fastPTOptimizer, a fork of the libpano13 library.

When you have only a small or medium number of images and control points, the original optimizer does the optimization in a fairly short time. However if you have a large number of images (several hundrets or even more than thousand) and many control points, the original optimizer typically needs much time for the optimization of the parameters.

With Hugin++ the time for the geometrical optimization is much shorter for large panoramas. Speedup factors of 100 or more are possible.

Update 28.06.2021:

I have added support for weights for control points. The default weight for each control points is 1. Assigning a weight higher than 1, say 'w', to a control point is equivalent to have 'w' control points with weight 1 at the same position. This causes the control point's error to contribute 'w' times more to the (weighted) sum of squares that the optimizer tries to minimize.

A control point with a high weight tends to have a small error after optimization - if this is

possible. But high weights should be used with care: In the extreme case that all control points have a weight of e.g. 1000 the optimizer finds exactly the same parameters as if the control points had the weight 1. What counts is the relation of the weights for the different control points.

What makes sense is assigning higher weights to control points that are likely placed precisely and lower weights to points that are less precise, e.g. if the object where they are placed may have moved in the meantime between shooting the two images.

You may also assign high weights to control points on objects where larger errors would be visually striking - if you are sure that these objects have not moved much.

For example, I have shot photos for a panorama where are trees, a stream and a bridge over the stream. After optimization without weights for control points (or all CPs having equal weight) there were visually striking errors on the bridge. On the other hand I know that the bridge has not moved noticeably.

So I could assign higher weights to CPs on the bridge. Other CPs, e.g. on the trees, might have moved - especially if they are on leafs of smaller branches of trees. Of course I tried not to place CPs on leafs but instead on trunks or bigger branches of the trees. But this in not always possible - especially if you use a high focal length (low angle of view).

Generally, assigning higher weight to a control point can lead to smaller errors of the CPs - if this it possible. But this is on the cost of getting larger errors on other control points.

If the CP with a higher weight is placed precisely, the increase of errors on other control points will probably be tolerable. A counterexample is the following: If a "bad" control point, e.g. an outlier (placed on different objects) or on a moving object, is assigned a higher weight, the error for this CP might decrease, but all other errors might increase in a non-tolerable way.

The "weights for control points" feature is currently available in a development version of Hugin++:

https://sourceforge.net/projects/huginplusplus/files/development/

Currently the only way to assign weights other than 1 to control points is changing the weight manually in the "control points" tab of Hugin++.  Control points that are generated automatically, e.g. by CPfind, will currently have weight 1.

A nice task for the future would be to change CPfind so that the control points get a weight other than 1 automatically. Some algorithm - including machine learning algorithms - might predict whether the control points might be on a moving object and how large a possible movement might be. With this information the CP detector could assign reasonable weights to the control point.

[Tobias]

Hello,

what is the reason, that fastPTOptimizer is not part of the official hugin.

Regards,

Tobias

[Florian Königstein]

I believe that fast optimization like in fastPTOptimizer will also be available in Hugin in the next official release.

I see fastPTOptimizer and Hugin++ as a possibility to publish my ideas as sources and also binaries a bit earlier - for encouraging discussions and also because I like using these features for my own panoramas.

Maybe there are some features in Hugin++ that shall not be integrated into Hugin for some reasons, e.g. there was a discussion whether weights for control points make sense.

Anyway I try to avoid unnecessary changes to the source code in order to facilitate a possible integration of my new features into Hugin.

Florian

[Bruno Postle]

On Mon, 28 Jun 2021 at 16:19, Tobias <tobias...@gmail.com> wrote:
>
> what is the reason, that fastPTOptimizer is not part of the official hugin.

It is in the

[Bruno Postle]

On Mon, 28 Jun 2021 at 16:19, Tobias <tobias...@gmail.com> wrote:
>

> what is the reason, that fastPTOptimizer is not part of the official hugin.

It is in a branch of libpano13, but this code is still being
worked-on, so ready for testing but not ready for release:
https://sourceforge.net/p/panotools/libpano13/ci/libpano13-2.9.21/tree/

This is an illustration of our creaking infrastructure. Sourceforge
doesn't support the fork/pull-request/merge workflow that we have
become used-to with github/bitbucket, so anyone wanting to work
separately on Hugin needs to create a new repository or create a
branch in the main repository. Florian, do you need access to work on
this in a Hugin branch?

--
Bruno

[Gunter Königsmann]

If weighing control points by cpfind's confidence that this is a valid control point makes sense? If there are repeating structures like window fronts sometimes control points look excellent even at the second glance, though...

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Florian Königstein]

@Bruno: Thanks, but I think for the moment I put my work into Hugin++ / fastPTOptimizer. Maybe later.

[Bruno Postle]

Apologies, I was wrong about this. Sourceforge does support the usual fork/pull-request workflow, with both mercurial and git.

--
Bruno

[Florian Königstein]

I have an update for fastPTOptimizer and also for the Windows installer for Hugin++ that also installs the binaries for fastPTOptimizer.

When there are weights for CPs other than 1, say a weight 'w', it should be exactly as if you had 'w' CPs with weight 1 at the same position. In the old version of fastPTOptimizer the reported error during the optimization wasn't correct. If e.g. all weights are 1000, the reported error should be the same as if all weights were 1 since the error is an average over all CP's errors. In the old version the error was too high if weights > 1 were used. I have corrected it.

[Florian Königstein]

There's a bug both in Hugin++ and in the latest official Hugin release (Hugin-2020.0.0):

To reproduce it, start Hugin, and open a PTO file that is large enough so that the loading takes some seconds.

Before the loading has finished, press the grayed out button for geometrical optimization in the "images" tab TWO times.

After loading has finished, two windows with title "Panorama Tools" will appear. In one the text 012345678901234567890123456789... appears

and nothing changes over time.

The other "Panorama Tools" window behaves normally. When finished optimization, accept the results.

Then Hugin / Hugin++ will crash.

I didn't have the time to fix the bug. Maybe later.

[Florian Königstein]

I did the following changes on Hugin++:

* When stitching the panorama, a temporary file with the image filenames is created if the command line would be longer than about

7000 characters (to be exact: 8191 - 1024, older versions of Windows support only 8191 chars in a command line,

and for other arguments I reserved generously 1024 chars). So Hugin++ works both with enblend and with my modified Multiblend if the command line would be too long.

In the control point list the following is changed:

* Added the buttons "next new image pair" and "previous new image pair". A click on

  "next new image pair" causes the next image pair (down) in the current ordering to

  be selected that is not used by the current or any of the above control points.

  I find it useful because I order the list by descending errors. I begin with image

  pairs with control points with high errors and delete bad CPs or increase weights of good CPs.

  Then I go down in the list, but often there are CPs from the same image pair that I have

  already checked. So by clicking on "next new image pair" I don't loose time by looking at

  the same image pair several times.

  

* "Stable ordering": You know that the list is sorted when clicking on the list header in one column.

  It is sorted by the "sort keys" in that column.

  Stable ordering means that - if there are CPs with equal sort keys - they are sorted by the (subordinated) sort key

  of the column on whose header was previously clicked. If there are CPs whose subordinated sort keys are also

  equal, they are sorted by a sub-subordinated sort key (in the 2nd previously clicked column).

  

* Added "average yaw" and "average pitch" in respective new columns of the list. These are the

  average yaw or pitch of the two images of the CP. The yaw and pitch can be used just for information or for

  sorting. Since yaw and pitch are real (not integer) values, CPs with equal "average" yaw or pitch are typically

  only those belonging to the same pair of images.

  

However you may want to view e.g. all control points with yaw between 20 and 40 and pitch between 0 and 20 and

sort them by descending error.

This is possible by not using the average yaw or pitch directly as sort key. Instead the average yaw and pitch can be

projected into one interval inside a "stack" of equally-sized intervals. Then the number of the intervals can

be used as sorting key.

The sorting from the above example can be achieved as follows: First, click on the "error" column header once

or twice, so that sorting is done by descending errors.

Then click on the header of the "average pitch" column. A dialog appears in that you can specify the pitch interval

from 0 to 20. Chose OK. Now sorting is done by the average pitch interval number, followed by the error as subordinated

sort key. Now click on the "average yaw" column header. In the appearing dialog choose the interval from 20 to 40.

Now sorting is done by the average yaw interval number, followed by the average pitch interval number as subordinated

sort key and by the error as sub-subordinated sort key. All CPs that have an image pair with average yaw and pitch in

the respective interval have yaw and pitch interval numbers 0. Scroll the list to where these CPs are. They are

sorted by descending errors.

[Florian Königstein]

I also changed the columns with the "left image" and the "right image". You know that every control

point connects two images. One of the image is declared to be the "left image" and the other the "right image".

But for the functionality of the control point it doesn't matter whether it's declared so or vice versa (reversing the assignment

of "left image" and "right image".

It seems that when creating CPs with CPfind (Hugin's automatic CP detector), the image with the smaller image number

is declared as "left image" and the other (with bigger number) the "right image". But if you add CPs manually in

the CP editor, you may select an image with a bigger number in the left image pane and the other in the right pane.

Then when adding CPs manually, they have the bigger image number "left" and the smaller number "right".

When using Hugin, I may want to see in the control point list all CPs that connect one special image (say image Nr. 100)

with any other image. In Hugin version 2020 I can sort the column "left image" by clicking on its header.  Sometimes I made the error

to assume that by scrolling to the CPs with "left image" 100 I could see all CPs that connect image 100 with some other.

But this is not right because there are also CPs that have image 100 as "right image" and some other as "left image".

So I decided not to use the columns "left image" and "right image", but instead the columns "Min Image Nr" and "Max Image Nr".

The problem with finding all CPs with and image Nr 100 and any other image is still there in my version of Hugin (with the new columns),

but in my eyes it's clearer with my solution. When sorting by ascending "Min image" and go to where the min images Nr 100 are,

it's clear that the corresponding "Max images" cannot be smaller that 100. So you must afterwards sort by "Max image Nr" and goto

max images 100. So you can see the min images with numbers < 100.

Of course the problem of finding all CPs that connect e.g. image Nr. 100 with some other image can also be solved in the CP editor

by selecting image Nr. 100 left and seeing the images that are highlighted in the drop-down list right.

When selecting two images in the left and right drop-down lists in the image editor all CPs are shown if they connect these

two images - even if the assignment to "left" and "right" image is reversed. This also shows that the order in that "left" and "right" are assigned to the images of a CP doesn't matter for the functionality.

.

[ChameleonScales]

Hi,

I would like to try hugin++ but I get these errors when trying to build on Debian:

$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCPACK_BINARY_DEB:BOOL=ON "~/programs/hugin++-2021-1-1-source"

CMake Error at CMakeLists.txt:92 (FILE):

  FILE failed to open for reading (No such file or directory):

    ~/programs/hugin++-2021-1-1-source/rev.txt

-- Current HG revision is 0

-- Assuming this is a tarball (release) build for 2021.1.1

CMake Error at CMakeLists.txt:112 (include):

  include could not find load file:

    vcpkg/scripts/buildsystems/vcpkg.cmake

CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):

  Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES

  wxWidgets_INCLUDE_DIRS)

Call Stack (most recent call first):

  /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)

  /usr/share/cmake-3.13/Modules/FindwxWidgets.cmake:963 (find_package_handle_standard_args)

  CMakeLists.txt:169 (FIND_PACKAGE)

-- Configuring incomplete, errors occurred!

See also "~/programs/hugin++_build/CMakeFiles/CMakeOutput.log".

[Florian Königstein]

To get rid of the error with the rev.txt file, create a text file rev.txt in the directory ~/programs/hugin++-2021-1-1-source/

with only the following content (one line):

06.10

Further, you must install wxWidgets and some other libraries. Unfortunately, I have limited experience with Linux and didn't

compile Hugin or Hugin++ on Linux yet. Maybe there are some other resources showing how to compile it under Linux.

[ChameleonScales]

Thanks for your help.

I could get rid of the rev.txt error by following your instructions as well as the wxWidgets error by installing the following packages:

• libwxbase3.0-dev
  
• libwxgtk3.0-dev
  
• libwxgtk3.0-gtk3-dev
  

(not sure I need all of them though).

Then to get rid of this error:

include could not find load file:

    vcpkg/scripts/buildsystems/vcpkg.cmake

I built vcpkg into hugin++'s source directory.

However I'm stuck at this error which seems to be the last one:

CMake Error at vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package):

  Could not find a package configuration file provided by "OpenEXR" with any

  of the following names:

    OpenEXRConfig.cmake

    openexr-config.cmake

  Add the installation prefix of "OpenEXR" to CMAKE_PREFIX_PATH or set

  "OpenEXR_DIR" to a directory containing one of the above files.  If

  "OpenEXR" provides a separate development package or SDK, be sure it has

  been installed.

I looked for any -dev version related to openexr, mainly an openexr-dev but all I could find is libopenexr-dev and it didn't help.

[Kornel Benko]

Am Fri, 13 Aug 2021 21:45:07 +0000
schrieb "'ChameleonScales' via hugin and other free panoramic software"
<hugi...@googlegroups.com>:

> Thanks for your help.
> I could get rid of the rev.txt error by following your instructions as well as the
> wxWidgets error by installing the following packages:
>

> - libwxbase3.0-dev
> - libwxgtk3.0-dev
> - libwxgtk3.0-gtk3-dev

>
> (not sure I need all of them though).
>
> Then to get rid of this error:
> include could not find load file:
> vcpkg/scripts/buildsystems/vcpkg.cmake

> I [built vcpkg](https://vcpkg.io/en/getting-started.html?platform=linux) into hugin++'s

> source directory.
>
> However I'm stuck at this error which seems to be the last one:
> CMake Error at vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package):
>
> Could not find a package configuration file provided by "OpenEXR" with any
>
> of the following names:
>
> OpenEXRConfig.cmake
>
> openexr-config.cmake

The package 'extra-cmake-modules' provides FindOpenEXR.cmake, which should be enough.

> Add the installation prefix of "OpenEXR" to CMAKE_PREFIX_PATH or set
>
> "OpenEXR_DIR" to a directory containing one of the above files. If
>
> "OpenEXR" provides a separate development package or SDK, be sure it has
>
> been installed.
> I looked for any -dev version related to openexr, mainly an openexr-dev but all I could
> find is libopenexr-dev and it didn't help.
>

Kornel

[ChameleonScales]

Thank you! that solved it. Unfortunately it gets weird now.

The wxWidgets error is back even though I still have the 3 packages mentioned above installed.
I swear this error was gone yesterday but now even if I uninstall extra-cmake-modules the wxWidgets error is still there.
Here's the full output now:

$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCPACK_BINARY_DEB:BOOL=ON "~/programs/hugin++-2021-1-1-source"

-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Current HG revision is 06.10

-- Assuming this is a tarball (release) build for 2021.1.1

-- Looking for log1p
-- Looking for log1p - found

CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES
wxWidgets_INCLUDE_DIRS)
Call Stack (most recent call first):
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.13/Modules/FindwxWidgets.cmake:963 (find_package_handle_standard_args)

vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package)
CMakeLists.txt:169 (FIND_PACKAGE)

[ChameleonScales]

I may be on to something:
if I move the vcpkg build out of the hugin++ source directory, then wxWidgets is found:

Found wxWidgets: -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_xrc-3.0;-lwx_gtk2u_html-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_gl-3.0;-lwx_baseu_net-3.0;-lwx_gtk2u_qa-3.0 (found version "3.0.4")

but vcpkg is obviously not found :

CMake Error at CMakeLists.txt:112 (include):

include could not find load file:
vcpkg/scripts/buildsystems/vcpkg.cmake

And if vcpkg is in the hugin++ source dir, the opposite happens (see output of my previous message).

I guess I have to install vcpkg on the system, which is what I'm looking for right now.

[Kornel Benko]

Am Sat, 14 Aug 2021 14:47:03 +0000

schrieb "'ChameleonScales' via hugin and other free panoramic software"
<hugi...@googlegroups.com>:

> I may be on to something:
> if I move the vcpkg build out of the hugin++ source directory, then wxWidgets is found:
>
> Found wxWidgets:
> -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_baseu-3.0;-lwx_gtk2u_core-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_xrc-3.0;-lwx_gtk2u_html-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_gl-3.0;-lwx_baseu_net-3.0;-lwx_gtk2u_qa-3.0
> (found version "3.0.4")
>
> but vcpkg is obviously not found :
>
> CMake Error at CMakeLists.txt:112 (include):
> include could not find load file:
> vcpkg/scripts/buildsystems/vcpkg.cmake

There is no such entry at any CMakeLists.txt in the source.
So it could be your change?

> And if vcpkg is in the hugin++ source dir, the opposite happens (see output of my
> previous message).
>
> I guess I have to install vcpkg on the system, which is what I'm looking for right now.
>

Kornel

[ChameleonScales]

line 112 in ./CMakeLists.txt (the one at the root), freshly downloaded from https://sourceforge.net/projects/huginplusplus/ :

> include( vcpkg/scripts/buildsystems/vcpkg.cmake )

We're talking about vcpkg, right?

[Kornel Benko]

Am Sat, 14 Aug 2021 15:24:29 +0000

schrieb "'ChameleonScales' via hugin and other free panoramic software"
<hugi...@googlegroups.com>:

Probably my fail. I am using hugin, not huginplusplus.

Kornel

[Florian Königstein]

I have build Hugin and Hugin++ on Windows also with vcpkg. There I have the vcpkg directory in the root-directory

of Hugin++.

I use the CMake Gui instead of the command line version. As far as I remember WxWidgets was also not found although it

was installed via vcpkg. I entered the paths to WxWidgets manually in CMake Gui, and so it worked. It was necessary

to enter the paths of other libraries manually, too. Maybe I made something "sub-optimal" so that the libraries could

not be found automatically.

Florian

[Gunter Königsmann]

On Ms windows there normally is no good way of telling where libraries are installed.

[smib]

I have tried to run the Windows executable but it is reporting a missing Vcruntime140D.dll. I believe that this is a debug dll  and that you may not have distributed the release version..

Brian

[Florian Königstein]

I have installed Hugin++ on a virtual machine with a "fresh" install of Windows 10. I can confirm that it does not work.

I have compiled it as "release", but it seems that some part is anyway compiled as debug. I will check this in the next days.

For the moment, the following workaround helped:

1. Install Hugin++

2. install vc_redist.x64.exe from

https://support.microsoft.com/de-de/topic/aktuelle-unterst%C3%BCtzte-downloads-f%C3%BCr-visual-c-2647da03-1eea-4433-9aff-95f26a218cc0

3. get the files  Vcruntime140D.dll and ucrtbased.dll from some trustful source and copy them into the Hugin++\bin directory.

[Florian Königstein]

I found the reason for the request of the debug versions: In the installer I accidently included the debug version of iconv-2.dll - it then requested Vcruntime140D.dll and ucrtbased.dll .

Now I have built the installer with the correct (release) iconv-2.dll. So the debug versions of the DLLs should not be needed any more.

The new installer is still here:

https://sourceforge.net/projects/huginplusplus/files/development/Hugin%2B%2BSetup_2021-1.1-Windows-64bit.exe/download

But you may still need to install vc_redist.x64.exe if some DLLs are missing

[ChameleonScales]

I just tried the cmake-qt-gui (for the first time and it seems I've been missing on something).

I had :

wxWidgets_CONFIG_EXECUTABLE-NOTFOUND

so I set the path to /usr/bin/wx-config".

I also had :

Z_VCPKG_CL-NOTFOUND

so I set the path to ~/programs/hugin++-2021-1-1-source/vcpkg/vcpkg

This seems to have fixed both of these errors.

However, I still have :

OPENEXR_DIR-NOTFOUND

I tried setting the path to /usr/share/ECM/find-modules since it contains FindOpenEXR.cmake but it didn't work.

I then tried /usr/include/OpenEXR which contains OpenEXRConfig.h, didn't work either.

I assume I'm supposed to point to a folder containing a file named openexr.cmake but I don't have such a file anywhere in my system, even though I have these 3 packages installed :

- openexr

- libopenexr-dev

- extra-cmake-modules

[Florian Königstein]

Did you install OpenEXR via vcpkg or somehow else ?

On Windows it worked for me setting OpenEXR_DIR to
E:/source/hugin-dev/vcpkg/installed/x64-windows/share/openexr
(after having installed OpenEXR via vcpkg).

Some time ago I tried to build Hugin (not Hugin++) on a Debian-based Linux (Linux Mint).

But it should make not so much difference to Hugin++.

It so happened that I also stopped at an error with OpenEXR.
OpenEXR is installed on the system, and some paths pointed to it. But still "OpenEXR not found".

Now I installed vcpkg and with it OpenEXR.
I inserted the following paths and it worked:

OPENEXR_HALF_LIBRARY                   /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libHalf-2_5.a
OPENEXR_IEX_LIBRARY                      /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libIex-2_5.so
OPENEXR_ILMIMF_LIBRARY              /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libIlmImf-2_5
OPENEXR_ILMTHREAD_LIBRARY        /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libIlmThread-2_5.so
OPENEXR_IMATH_LIBRARY          /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libImath-2_5.a
OPENEXR_INCLUDE_DIR             /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/include

The following was then automatically generated (when configuring):

OPENEXR_LIBRARIES                /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libImath-2_5.a;/home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libIlmImf-2_5;/home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libIex-2_5.so;/home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libHalf-2_5.a;/home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/libIlmThread-2_5.so;;/usr/lib/x86_64-linux-gnu/libz.so

So, OpenEXR seems to be OK. The next error is with VIGRA. On windows, VIGRA cannot be installed
via vcpkg, I installed it in another way.

[ChameleonScales]

I originally had openexr installed on my system. Installing it via vcpkg fixed that issue.

I also built vigra from source and set the path to ./usr/local/bin/vigra-config

But now I have this :

CMake Error at CMakeModules/FindVIGRA.cmake:58 (IF):
if given arguments:

"VERSION_EQUAL" "VIGRA_FIND_VERSION" "OR" "VERSION_GREATER" "VIGRA_FIND_VERSION"

Unknown arguments specified

Call Stack (most recent call first):

vcpkg/scripts/buildsystems/vcpkg.cmake:784 (_find_package)
CMakeLists.txt:223 (FIND_PACKAGE)

When you said "the next error is Vigra", did you mean I should expect several more? Maybe this is destined for people who have good knowledge of cmake. I don't want to waste people's time and clutter the conversation so I may give up.

[Florian Königstein]

With this I meant that (at least on Windows) most of the libraries could not be found automatically and some "doing by hands" and try-and-error will be necessary.

I myself have never CREATED CMakeList.txt and related files for CMake, and so I'm far from beeing an expert with CMake.

I find it good if you ask here, so this thread can also be seen as a help for others who want to compile Hugin or Hugin++.

From your error messages it seems that the variables containing the vigra version information are not defined.

Maybe I find the time to try it myself on Linux.

[Florian Königstein]

I made some errors with the paths that should be entered in CMake for my Hugin build on Linux:

This should be correct:

OPENEXR_HALF_LIBRARY                   /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libHalf-2_5.a
OPENEXR_IEX_LIBRARY                      /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libIex-2_5.a
OPENEXR_ILMIMF_LIBRARY              /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libIlmImf-2_5.a
OPENEXR_ILMTHREAD_LIBRARY        /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libIlmThread-2_5.a
OPENEXR_IMATH_LIBRARY          /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/lib/libImath-2_5.a
OPENEXR_INCLUDE_DIR             /home/user/dev/hugin-2020.0.0/vcpkg/packages/openexr_x64-linux/include/OpenEXR

Now I have built vigra on Linux with OpenEXR support. The CMake for Hugin++ finds my vigra installation, but it claims about missing

OpenEXR support in vigra (before I compiled vigra without OpenEXR support, but then with it).

[Florian Königstein]

I made the following error: On Linux (and Windows) Hugin must probably be - or it is easier if it is - built using dynamic (not static) libraries.

On Linux I now installed "Overlay triplets" like here described:

https://devblogs.microsoft.com/cppblog/vcpkg-2019-06-update/

So I installed OpenExr as dynamic library with:

./vcpkg install openexr:x64-linux-dynamic --overlay-triplets=../custom-triplets

I build vigra with this dynamic OpenExr, so I must correct the paths again:

OPENEXR_HALF_LIBRARY                   /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libHalf-2_5.so
OPENEXR_IEX_LIBRARY                      /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIex-2_5.so
OPENEXR_ILMIMF_LIBRARY              /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmImf-2_5.so
OPENEXR_ILMTHREAD_LIBRARY        /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmThread-2_5.so
OPENEXR_IMATH_LIBRARY          /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libImath-2_5.so
OPENEXR_INCLUDE_DIR             /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/include/OpenEXR

After installing vigra the CMake Gui for Hugin++ does not complain any more about missing OpenExr support.

The next missing library is EXIV2. I hope it works with vcpkg.

[ChameleonScales]

I ran into several errors trying to install vigra after building it using your guidance. Right now it shows this

$ sudo make install

Scanning dependencies of target vigraimpex

[  0%] Building CXX object src/impex/CMakeFiles/vigraimpex.dir/bmp.cxx.o

[  3%] Building CXX object src/impex/CMakeFiles/vigraimpex.dir/byteorder.cxx.o

[  3%] Building CXX object src/impex/CMakeFiles/vigraimpex.dir/codecmanager.cxx.o

[  3%] Building CXX object src/impex/CMakeFiles/vigraimpex.dir/compression.cxx.o

[  7%] Building CXX object src/impex/CMakeFiles/vigraimpex.dir/exr.cxx.o

/home/user/programs/vigra/vigra-1.11.1/src/impex/exr.cxx:48:10: fatal error: ImfRgbaFile.h: No such file or directory

#include <ImfRgbaFile.h>

          ^~~~~~~~~~~~~~~

compilation terminated.

make[2]: *** [src/impex/CMakeFiles/vigraimpex.dir/build.make:115: src/impex/CMakeFiles/vigraimpex.dir/exr.cxx.o] Error 1

make[1]: *** [CMakeFiles/Makefile2:481: src/impex/CMakeFiles/vigraimpex.dir/all] Error 2

make: *** [Makefile:163: all] Error 2

An earlier time, the make install process actually got much further before stopping but I haven't found how to get back to that state, even by restarting the Cmake configuration from scratch. I don't understand how that's even possible.

[ChameleonScales]

Nevermind I'm an idiot, I used the wrong paths. So the Cmake configuration of vigra outputs this at the end :

vigranumpy tests will NOT be executed (nosetests missing)

---------------------------------------------------------

VIGRA configuration information:

---------------------------------------------------------

Using ZLIB libraries: /usr/lib/x86_64-linux-gnu/libz.so

Using PNG libraries: /usr/lib/x86_64-linux-gnu/libpng.so;/usr/lib/x86_64-linux-gnu/libz.so

Using TIFF libraries: /usr/lib/x86_64-linux-gnu/libtiff.so

Using JPEG libraries: /usr/lib/x86_64-linux-gnu/libjpeg.so

Using OpenEXR libraries: /home/caetano/programs/huginplus/huginplus-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmImf-2_5.so;/home/caetano/programs/huginplus/huginplus-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libImath-2_5.so;/home/caetano/programs/huginplus/huginplus-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libHalf-2_5.so;/home/caetano/programs/huginplus/huginplus-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIex-2_5.so;/home/caetano/programs/huginplus/huginplus-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmThread-2_5.so

Using FFTW libraries: /usr/lib/x86_64-linux-gnu/libfftw3.so

Using HDF5 libraries: /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so;/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_hl.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libsz.so

Using Boost Graph Library: /usr/include/boost/graph

LEMON graph library disabled by user (WITH_LEMON=0)

Using Python libraries: /usr/lib/x86_64-linux-gnu/libpython2.7.so;/usr/lib/x86_64-linux-gnu/libboost_python.so

Using Numpy includes: /usr/lib/python2.7/dist-packages/numpy/core/include

---------------------------------------------------------

building shared lib

binaries will be generated in: /home/caetano/programs/huginplus/huginplus-2021-1-1-source/vigra

manuals will be generated in: /home/caetano/programs/huginplus/vigra/vigra-1.11.1/doc

---------------------------------------------------------

includes will be installed at: /usr/local/include

libraries will be installed at: /usr/local/lib

binaries will be installed at: /usr/local/bin

vigra manuals will be installed at: /usr/local/doc/vigra/index.html

vigranumpy will be installed at /usr/local/../lib/python2.7/dist-packages

vigranumpy manuals will be installed at: /usr/local/doc/vigranumpy/html/index.html

---------------------------------------------------------

Configuring done

I tried to get rid of that "nosetests missing" by installing nose with "sudo pip3 install nose" which properly installed it but that didn't make the "missing" go away, although I'm not sure it's problematic.

However, now when I sudo make install in viagra (... I knew I would do this typo eventually), it stops at this :

make[2]: *** [vigranumpy/src/core/CMakeFiles/vigranumpy_filters.dir/build.make:76: vigranumpy/src/core/CMakeFiles/vigranumpy_filters.dir/convolution.cxx.o] Error 1

make[1]: *** [CMakeFiles/Makefile2:4294: vigranumpy/src/core/CMakeFiles/vigranumpy_filters.dir/all] Error 2

make: *** [Makefile:163: all] Error 2

So maybe it was problematic ? But then how to properly install nose in order for the vigra configuration to use it? So many questions!

[Florian Königstein]

I ignored the error with the tests, too. For me it worked.

Maybe before the errors when executing make install is some more useful information ? At the moment, I have no idea why your install fails.

I made some progress and finally managed to compile Hugin++ on Linux.

wxWidgets was installed on my system and was automatically found by CMake GUI, but it lead to problems later when compiling (related to OpenGL).

So I installed wxWidgets via vcpkg:

./vcpkg install wxWidgets:x64-linux-dynamic --overlay-triplets=../custom-triplets

In the CMake GUI I replaced the following:

wxWidgets_CONFIG_EXECUTABLE                /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/wxwidgets_x64-linux-dynamic/tools/wxwidgets/wx-config
wxWidgets_USE_STATIC                                  ====> set to OFF
wxWidgets_wxrc_EXECUTABLE                     /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/wxwidgets_x64-linux-dynamic/tools/wxwidgets/wxrc

Now exiv2:

rename exiv2Config.cmake to EXIV2Config.cmake in directory /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/share/exiv2

Set the following:

EXIV2_DIR                             /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/share/exiv2
EXIV2_INCLUDE_DIR           /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/include
EXIV2_LIBRARIES               /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/lib/libexiv2.so

Download OpenBLAS (source code) from https://github.com/xianyi/OpenBLAS/releases and extract to /home/user/dev/OpenBLAS-0.3.17/

cd /home/user/dev/OpenBLAS-0.3.17/
make

sudo apt-get install libgmp3-dev
sudo apt-get install libmpfr-dev

Download SuiteSparse from https://github.com/DrTimothyAldenDavis/SuiteSparse and extract to /home/user/dev/SuiteSparse
cd /home/user/dev/SuiteSparse
make library BLAS=/home/user/dev/OpenBLAS-0.3.17/libopenblas.so

cd /home/user/dev/hugin++-2021-1-1-source/

mkdir libpano13

cd libpano13

Download libpano13-2021-06-07.zip from https://sourceforge.net/projects/fastptoptimizer/

and extract to /home/user/dev/hugin++-2021-1-1-source/libpano13/libpano13-2021-06-07/

Rename libpano13-2021-06-07   to pano13 :

mv   libpano13-2021-06-07   pano13                                

cp pano13/version.h   .

*** Copying version.h this way is not very pretty, but CMake GUI expects the file here. Maybe create a symbolic link instead. ***

Start CMake Gui and enter source path /home/user/dev/hugin++-2021-1-1-source/libpano13/pano13 and

build path /home/user/dev/hugin++-2021-1-1-source/libpano13/pano13/build

Replace the file FindSUITESPARSE.cmake in the directory /home/user/dev/hugin++-2021-1-1-source/libpano13/pano13/CMakeModules with the file in the attachment of this post.

Press Cconfigure.
Enter the following in the CMake GUI for libpano13:
SUITESPARSE_INCLUDE_DIRS:              /home/user/dev/SuiteSparse/include
SUITESPARSE_CHOLMOD_LIBRARY:   /home/user/dev/SuiteSparse/CHOLMOD/Lib/libcholmod.a
SUITESPARSE_SPQRT_LIBRARY:          /home/user/dev/SuiteSparse/SPQR/Lib/libspqr.a

SUITESPARSE_AMD_LIBRARY               /home/user/dev/SuiteSparse/AMD/Lib/libamd.a
SUITESPARSE_CAMD_LIBRARY            /home/user/dev/SuiteSparse/CAMD/Lib/libcamd.a
SUITESPARSE_CCHOLAMD_LIBRARY        /home/user/dev/SuiteSparse/CCOLAMD/Lib/libccolamd.a
SUITESPARSE_CHOLAMD_LIBRARY           /home/user/dev/SuiteSparse/COLAMD/Lib/libcolamd.a
SUITESPARSE_CONFIG_LIBRARY               /home/user/dev/SuiteSparse/SuiteSparse_config/libsuitesparseconfig.a
SUITESPARSE_METIS_LIBRARY                  /home/user/dev/SuiteSparse/metis-5.1.0/build/Linux-x86_64/libmetis/libmetis.so
Press Generate.

cd /home/user/dev/hugin++-2021-1-1-source/libpano13/pano13/build

make

Go to the CMake GUI for Hugin++. Enter the following:

PANO13_INCLUDE_DIR           /home/user/dev/hugin++-2021-1-1-source/libpano13/
PANO13_LIBRARIES                /home/user/dev/hugin++-2021-1-1-source/libpano13/pano13/build/libpano13.so

Maybe some of the ....INCLUDE_DIR   and   ..._LIBRARIES   don't exist in the CMake GUI for Hugin++. In this case create them by pressing "Add Entry"

(....INCLUDE_DIR is a path and ..._LIBRARIES a file path).

EXIV2_DIR                             /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/share/exiv2
EXIV2_INCLUDE_DIR           /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/include
EXIV2_LIBRARIES                /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/exiv2_x64-linux-dynamic/lib/libexiv2.so

OPENEXR_DIR                    /home/user/dev/hugin++-2021-1-1-source/vcpkg/installed/x64-linux/share/openexr
OPENEXR_INCLUDE_DIR            /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/include/OpenEXR
OPENEXR_LIBRARIES              /home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libHalf-2_5.so;/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIex-2_5.so;/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIexMath-2_5.so;/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmImf-2_5.so;/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmImfUtil-2_5.so;/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libIlmThread-2_5.so;/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib/libImath-2_5.so

Now in the CMake GUI for Hugin++ the "Configure" and "Generate" succeeded. There were some warnings. I ignored them for the moment.

The file

/home/user/dev/hugin++-2021-1-1-source/build/src/hugin_version.h

must be edited as it leads to compile errors. There are line breaks in strings. Remove them: Replace

#if defined _WIN32 || defined __APPLE__
#define PACKAGE_VERSION "2021.1.1 built by "
#define DISPLAY_VERSION "2021.1.1.06.10
 built by "
#else
#define PACKAGE_VERSION "2021.1.1"
#define DISPLAY_VERSION "2021.1.1.06.10
"
#endif

by this:

#if defined _WIN32 || defined __APPLE__
#define PACKAGE_VERSION "2021.1.1 built by "
#define DISPLAY_VERSION "2021.1.1.06.10 built by "
#else
#define PACKAGE_VERSION "2021.1.1"
#define DISPLAY_VERSION "2021.1.1.06.10"
#endif

Something must be fixed related to CMake GUI because these line breaks are inserted every time you press "Generate" in the GUI.

Now compiling Hugin++:

cd /home/user/dev/hugin++-2021-1-1-source/build

make                            (or make -j24 or some other number according to the number of CPU cores / threads)

make install

Start Hugin:
/usr/bin/hugin

Some dynamic libraries were not found. I helped me (****not very pretty****) with something like this:

export LD_LIBRARY_PATH=/home/user/dev/hugin++-2021-1-1-source/vcpkg/packages/openexr_x64-linux-dynamic/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/home/user/dev/hugin++-2021-1-1-source/vcpkg/installed/x64-linux-dynamic/lib:$LD_LIBRARY_PATH

Starting Hugin works now, but a lot of errors and warnings are printed in the console like these:

(hugin:34714): Gtk-CRITICAL **: 07:43:52.394: gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed
(hugin:34714): Gtk-WARNING **: 07:43:52.394: gtk_widget_size_allocate(): attempt to allocate widget with width 0 and height -29
(hugin:34714): Gtk-CRITICAL **: 07:43:52.394: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(hugin:34714): Gtk-WARNING **: 07:43:52.394: Negative content height -7 (allocation 1, extents 4x4) while allocating gadget (node button, owner GtkToggleButton)

Hoping to find a solution to this.

[ChameleonScales]

Ok, I was not expecting it to be this complicated. Plus I tried on the new Debian 11 and got an error I didn't see before when configuring hugin++ (CMAKE_DLLTOOL-NOTFOUND) which means the steps may vary depending on the distro and version.

Have you considered making an appimage of hugin++? I've never done it so I don't know how easy or complicated it is but if it could be done, any Linux distro could just open huginn++ with nothing more than a double-click.

In the current state I prefer to wait for the upcoming features to be implemented in Hugin. Very sorry if if I wasted your time.

[Florian Königstein]

At first, I'd like to say that it's nice that fast geometrical optimization is now included in the latest version of libpano (libpano13-2.9.21 release candidate rc2).
The reason why I made my branches of libpano (fastPTOptimizer) and Hugin (Hugin++) is the following:
In the latest version of libpano is one bottleneck that slows down the optimization especially for very large panoramas: The calculation of the jacobian matrix that is needed by the levenberg marquardt algorithm.

I tested the Hugin 2021.0 beta 1 (Windows binary) and compared it with my current version of Hugin++ (in Hugin 2021.0 beta 1 the libpano13-2.9.21 release candidate rc1 (not rc2) is used, but it should not make much difference in speed).

I performed geometrical optimization for a large panorama with 1351 images and 273471 control points (this pano is a bit pre-optimized).

In Hugin 2021.0 beta 1 it took 485 seconds for 5 iterations in strategy 1 and 2 iterations in strategy 2.

In Hugin++ the optimization took 63 seconds for 4 iterations in strategy 1 and 3 iterations in strategy 2.

So, for this panorama my version is about 8 times as fast as the one in libpano for Hugin 2021 beta.
Probably this speedup factor will get smaller for smaller panoramas.

I know why libpano13-2.9.21 release candidate rc2 is made as it is (especially the calculation of the jacobian matrix): It should be better maintainable compared to my version of libpano (I use a function ChangeAlignParamInImage() in the file adjust.c that does similar jobs than SetAlignParams, but ChangeAlignParamInImage() is necessary to avoid the bottleneck in the calculation of the jacobian matrix).

I'd like to emphasize that libpano13-2.9.21 release candidate rc2 is still a big advantage in speed for large panoramas compared to the version libpano13-2.9.20 that is used in Hugin 2020.0.0. In Hugin 2020.0.0 the optimization of the above large (pre-optimized) panorama would have taken hours.

But in my eyes the speedup factor 8 for my large panorama justifies that I keep my fastPTOptimizer parallel to libpano13-2.9.21 and my Hugin++ branch parallel to Hugin.

In Hugin++ itself I also made some changes compared to Hugin. In my eyes one change (weights for control points) is useful for some "pathological" panoramas that are difficult to optimize (e.g. when moving objects like leaves of a tree are present and you have no alternative to setting some control points onto them).
In these cases you can tell the geometrical optimizer that some control points are less reliable (e.g. those on leaves on a tree): You assign weights less than one (1) to them, e.g. 0.1 or 0.01 . On the other hand you can assign weights larger than one (e.g. 10 or 100) to control points that are more reliable, e.g. those on the trunk of a tree. In fact I used this weight feature and could optimize a panorama satisfactorily than I could not optimize well without the weight feature.

I'd like to know whether some of you find the "weights for control points" feature also useful for some panoramas ?

[Florian Königstein]

I updated the Hugin++ sources and the Windows binaries with David Horman's latest version of multiblend (and with a bugfix in multiblend concerning a crash when input images have only transparent pixels):

https://sourceforge.net/projects/huginplusplus/files/development/

[Florian Königstein]

I have just forked Hugin++ from the latest revision of Hugin and fastPTOptimizer from the latest revision of libpano13 and merged my changes into them.

The updated sources and the Hugin++ build for Windows can be downloaded here:

https://sourceforge.net/projects/huginplusplus/files/development/

The updated fastPTOptimizer is here:

https://sourceforge.net/projects/fastptoptimizer/files/

[Florian Königstein]

For speed testing purposes I append two panorama projects with each having 1351 images and ..... control points.
Since the images need about 12 GB, I replaced all but two images with a black dummy image.
The panorama
pano_preoptimized_without_weights.pto
is pre-optimized and all weights are 1 (I created it before I introduced my "weights for control points" feature).
When pressing the (geometrical) "optimize" button, 8 optimization iterations are performed (on my computer in about 55 seconds).
This panorama is very problematic, e.g. when pressing the GL button you see that there are some unconnected images.
After optimization I was far from getting acceptable stitching results.

I created the second panorama
pano_with_weights_and_optimized.pto
by assigning weights to CPs and do other things in order to get acceptable results. In this pano are still some unconnected images, but I can delete them since in them is only sky and I have no chance to align them. I must do some post-processing after stitching, e.g. with GIMP.
In this pano (pano_with_weights_and_optimized.pto) you cannot test the speed of the optimizer since it is already optimized.

With both panoramas you can see that adding just one CP takes a long time (8 seconds on my Windows system). It would be fine to optimize the code to make it faster.
If you want to test this, go to the CP editor and select the images 181 and 269 since all other images are replaced by black dummy images.

In the second pano (pano_with_weights_and_optimized.pto) you can also see that I assigned higher weights for CPs on the trunk of the trees and lower weights for CPs on the leafs.

https://drive.google.com/file/d/1JafuUj9a__-3E5IhVcroXdPUFVSm3APk/view?usp=sharing
https://drive.google.com/file/d/1dc-w2hxlIWecD7kPwwSIixBuSLAEPXmR/view?usp=sharing
https://drive.google.com/file/d/11gdz6Gl4WQtegIbqINV2L9IxOs1Mg5TT/view?usp=sharing
https://drive.google.com/file/d/1y3P4GCpSyt0sF7OE84di3fQ2kHf1lgsG/view?usp=sharing
https://drive.google.com/file/d/1UqHTSbZu-pk7atSGhTWzu3Kz46FcZ7dQ/view?usp=sharing