Hugin 2016.02 released

There is a new release of hugin: Hugin-2016.2.0 release notes


Changes Since 2016.0.0

  • Allow reading of image positions from Papywizard XML files: First add the image to a new project and then select File, Import settings from Papywizard XML file… This will read the lens settings, the image positions and also, if applicable, the bracket settings. After this, the usual workflow is to run cpfind with --prealigned switch and then geocpset to connect orphanded images.

  • The internal blender and verdandi got the possibility to blend seams as alternative to current hard seam: For each seam the color of second image is adapted to the match the color of the first seam. For this blender, the blender order changes according to the overlap. The blending starts with the exposure anchor and blends then all overlapping images. This blending mode is not suited if there are bigger misalignments or bigger parallax errors.

  • The display of the control point error (after optimizing and in fast preview window) and the control point list window can now limited to take only control points in active images into account (menu Edit, Optimize only active images, connected with the setting on the optimizer tab).
    Improvements to mask tab in Hugin (edit crop of all images of the same lens at once) and find panorama dialog in PTBatcherGUI (remove images from found panoramas, split found panorama into two).

  • Several improvements for Mac OS.

  • uFixes several issues with fast preview window which could result in random crashes (uninitialized variables, memory leaks).

1 Like

Thanks, made the original post from my phone which is not condusive to doing anything :slight_smile:

It would be HUGE if @Carmelo_DrRaw could make a Hugin AppImage. :grin:


You can give it a go yourself:

Guess who wrote that page :blush:


So you’re saying you’re an expert :wink:

1 Like

This will eventually come in the near future, but first I want to finalise some pending stuff, namely:

  • the AppImage for GIMP, which has still some issues with gdk-pixbuf on some systems
  • make sure that the HDRmerge appimage works fine
  • complete the make-based build system for gmic
  • get finally out next photoflow release…

Otherwise I’ll get lost in too many parallel projects :upside_down:

1 Like

I don’t have anything of substance to add other than to point out that the exchange between @probono and @paperdigits gave me a good laugh this monday morning… :laughing:

Also, @Carmelo_DrRaw do you think it might be helpful to host what you’re doing on github (or should we push it into the pixls organization?) so that others might be able to help you? I’m not sure if will happen, but you’re doing all this awesome work lately, and maybe we can convince some other smart folks to help out?

The AppImage recipe for GIMP is kept as a github gist, so anyone is in principle able to fork it, modify it and send a pull request… The github version is not completely up-to-date, as I am doing some experiment to solve the issues that @paperdigits reported when running on Debian Jessie.

My final goal is to adapt the recipe so that it can be run from a Ubuntu 14.04 Live CD. In fact, the Recipe is nothing but a bash script that performs all the steps needed to create the AppImage, from installing the required packages, downloading and compiling the sources, and bundling the libraries into an executable disk image.

Once this will be done, anyone will have the possibility to fire up an Ubuntu 14.04 Live CD in a virtual machine, run the script, and upload the resulting appimage… This way, the result will be totally user-independent, in the sense that the resulting appimage will be the same regardless of who has produced it, as long as the sources do not change.

I will first test this with the HDRMerge appimage, because then I can easily hand over the script to the HDRMerge maintainers if they want to have control over the appimage release…

1 Like

You can also use Travis CI as a cloud-based service to run the recipe (script that generates the AppImage). That is what I use for the sample AppImages I provide.

I would be very interested in that…
Could you point me to an example? How does one retrieve the generated appimage?

Travis CI runs your recipe script, so your recipe script needs to upload the generated AppImage somewhere. I use Bintray (releases) and (nightlies) for this purpose.

The starting point for using Travis CI is here:

Examples for projects which are using Travis CI to generate AppImages:

Still work in progress… I have now a running GUI (after some patching of the cmake build system), with still some not found icons, but the external commands (like cpfind) do not work yet.

For those who want to try this preliminary version, here is the link:

1 Like

Launches but seems not to find some of its resources:

can't open file './share/hugin/xrc/data/tips.txt' (error 2: No such file or directory)


Did you know... Tips not available, sorry!

Could it be that Hugin does some chdir? In that case, loading from ./share won’t work because we are not in usr/ inside the AppDir anymore…

So a bit of digging finds:

$ sudo strace -echdir -f '/home/me/Downloads/Hugin-2016.2.0.be8da0221960.glibc2.14-x86_64.AppImage' 2>&1 | grep chdir
[pid 13424] chdir("/")                  = 0
[pid 13429] chdir("/home")              = 0
[pid 13429] chdir("me")                 = 0
[pid 13429] chdir(".cache")             = 0
[pid 13429] chdir("thumbnails")         = 0
[pid 13421] chdir("/tmp/.mount_rAxj8k") = 0
[pid 13421] chdir("usr")                = 0
[pid 13435] chdir("/proc")              = 0
[pid 14058] chdir("/")                  = 0
[pid 14059] chdir("/")                  = 0
[pid 13449] chdir("/tmp")               = 0

It actually does a lot of chdirs, and this does not work with patching the absolute /usr to a relative ././ or ./.

So it would be best if Hugin could be made properly relocatable by the upstream authors.

1 Like