Hugin 2026.0 beta1 released

[T. Modes]

Hi all,

today we are releasing beta 1 of Hugin 2026.0.0

Source tarball can be downloaded

https://sourceforge.net/projects/hugin/files/hugin/hugin-2026.0/hugin-2026.0.beta1.tar.bz2/download

Verify its checksums:
md5:

5fc9b508becf8b2e15a0b784236f0912  hugin-2026.0.beta1.tar.bz2

sha1

cde1091e1ff39cff4b4830efb201e4c9a59bdf6c  hugin-2026.0.beta1.tar.bz2

This is a source code release.
Users communities produce executables for their respective platforms. Please announce them here.

(The beta 1 correspond to changeset a5133e8117baour repository, which is also tagged as 2026.0beta1).

Changes since 2025.0

* Added a GUI for hugin_stacker to hugin_toolbox.
* Added some anti-alias interpolators to remapping code for better downsizing of images. These are currently only implemented on the CPU. If requesting GPU remapping nona will automatically switch to CPU remapping.
* Added some more convenience functions to hugin script interface.

Beside there are many small bugfixes.

Upgrading from previous versions of Hugin should be seamless. If you do have problems with old settings, these can be reset in the Preferences window by clicking 'Load defaults'.

Please test and report bug/issues to mailing list or bug tracker https://bugs.launchpad.net/hugin (so issues can be fixed before the final release).

Windows binaries (64 bit) can be found at sourceforge: 

https://sourceforge.net/projects/hugin/files/hugin/hugin-2026.0/Hugin-2026.0.beta1-win64.msi/download

MD5 checksum
038d6dccb387e6697f44bfb9fc95b02b Hugin-2026.0.beta1-win64.msi

Request for translators
Please update the translation file of your language. Some new strings have been added.

[wirz]

Hi Thomas,

With clang-23 / wx-3.2 / debian-linux I'm seeing a few compile warnings,
and one error. They are addressed in the attached diff.
The error is about boolean operations between different enums, but as
GetPath() has a second argument that defaults to wxPATH_NATIVE, just
dropping that should lead to the intended behaviour.

Slightly unrelated, I think it would be a good idea to release a new
enblend / enfuse version some time. There are no new features but there
have been some relevant bug fixes in the last three years or so. As far
as I know there are no new features planned, so the fixes should be
released on their own eventually.

cheers, lukas wirz


On 03/10/2026 10:04, 'T. Modes' via hugin and other free panoramic

[T. Modes]

Hi Lukas,

lukas wirz schrieb am Samstag, 3. Oktober 2026 um 17:56:08 UTC+2:

With clang-23 / wx-3.2 / debian-linux I'm seeing a few compile warnings,
and one error. They are addressed in the attached diff.

thanks for the patch. Commited to repository.

 

Slightly unrelated, I think it would be a good idea to release a new
enblend / enfuse version some time. There are no new features but there
have been some relevant bug fixes in the last three years or so. As far
as I know there are no new features planned, so the fixes should be
released on their own eventually.

Maybe next. We have to aggree on a compromise.

The stable 4.2 branch has OpenCl support removed.

In the default branch which got the most bug fixes can still compiled with OpenCl support.

The OpenCl code is my limited testing not faster than the CPU code, and we have currently nobody which works on these code path or can even fix issue there.

So for a release there should be a decision how to deal with the OpenCL code.

Thomas

[Kyle Maas]

I run quite a bit of OpenCL-based stuff on my Gentoo box.  What needs to be tested/reviewed/benchmarked?

Warm Regards,
Kyle Maas

--
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 visit https://groups.google.com/d/msgid/hugin-ptx/921519dc-4b53-4d30-b828-9ae6b37626b5n%40googlegroups.com.

[wirz]

Hi Thomas,

On 04/10/2026 12:17, 'T. Modes' via hugin and other free panoramic

software wrote:
> thanks for the patch. Commited to repository.

Thanks!

> Slightly unrelated, I think it would be a good idea to release a new
> enblend / enfuse version some time. There are no new features but there
> have been some relevant bug fixes in the last three years or so. As far
> as I know there are no new features planned, so the fixes should be
> released on their own eventually.
>
> Maybe next. We have to aggree on a compromise.
> The stable 4.2 branch has OpenCl support removed.
> In the default branch which got the most bug fixes can still compiled with
> OpenCl support.
> The OpenCl code is my limited testing not faster than the CPU code, and we
> have currently nobody which works on these code path or can even fix issue
> there.
> So for a release there should be a decision how to deal with the OpenCL
> code.

I have never benchmarked that myself, I'll look at that some time. My
one system is not terribly representative, of course.

Maintaining and writing openCL itself is not a problem, I have written
plenty of that on the day job. The surrounding C++ infrastructure is
also not a problem. I'm locally always compiling with ocl, upgraded
from 2.x to 3.0, and with added intel support, and that works fine. The
only component that is problematic from my perspective is the cmake
build infrastructure, including the correct names of header and library
files. That seems to be different on different platforms, and what I'm
using locally does probably not work everywhere.

cheers, lukas wirz

[T. Modes]

Hi Lukas and Kyle,

I think there is a misunderstanding. The OpenCL infrastructure is set up and running.

But only 2 smaller algorithm are rewritten to use it. 

Therefore the whole processing time is not reduced in a high amount - if further tests of enblend show here a higher reduction of processing time it would result in a higher yield.

But I assume to get these speed up more parts of enblend whole algorithm needs to be rewritten in OpenCL.

Thomas

[Kyle Maas]

Ah, that makes sense.  It would be really helpful if more of Hugin was capable of using my graphics cards.  As it is, it takes way longer to process than it seems like it should, and Nona always switches to CPU mode anyway.  I wouldn't mind helping work on that, but looking at it, it looks like the development contribution process isn't quite as streamlined as I'd expect for such a mature process.  But I think that's a topic for a different e-mail chain.  At any rate, I'll see what I can do.

Warm Regards,
Kyle Maas

--
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 visit https://groups.google.com/d/msgid/hugin-ptx/8df03d47-3e4c-4424-8ebd-3af6cb772558n%40googlegroups.com.

[T. Modes]

Hi Kyle,

kylem...@gmail.com schrieb am Dienstag, 6. Oktober 2026 um 18:12:40 UTC+2:

Nona always switches to CPU mode anyway.  

Nona works for me on the GPU. So "always" is not correct.

The new anti-alias interpolator does not work on GPU. 

But this type is the typical report: "does not work." without further details. 

So it is very difficult to fix. Because for me GPU remapping works fine for me and is my default.

Thomas

[Kyle Maas]

I didn't mean to imply it doesn't work for anyone else.  I meant it always switches to CPU mode for me.  I have not troubleshot as to why, because I didn't know that was an area that needed help.  I have AMD cards, which means I'm used to stuff not supporting it.

Warm Regards,
Kyle Maas

--
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 visit https://groups.google.com/d/msgid/hugin-ptx/f7247ae3-0866-4f8c-af66-db13fafd8a29n%40googlegroups.com.

[Kyle Maas]

Just tested the same dataset with just over slightly >1 gigapixel of output made by enblend compiled with different sets of options:

With OpenCL and OpenMP: 11m37.764s

Without OpenCL but with OpenMP: 10m32.471s

With OpenCL but without OpenMP: 10m17.625s

Without OpenCL or OpenMP: 10m21.700s

So at least with my single data point, neither one seems to actually help much.

Warm Regards,
Kyle Maas

--
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 visit https://groups.google.com/d/msgid/hugin-ptx/f7247ae3-0866-4f8c-af66-db13fafd8a29n%40googlegroups.com.

[Kyle Maas]

Downloaded the source today to tinker with it.  Running hugin built from source, unmodified, does allow Nona to use the GPU on my machine.  The Gentoo ebuild package version did not.

Warm Regards,
Kyle Maas

--
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 visit https://groups.google.com/d/msgid/hugin-ptx/f7247ae3-0866-4f8c-af66-db13fafd8a29n%40googlegroups.com.

[T. Modes]

Hi Kyle

kylem...@gmail.com schrieb am Dienstag, 6. Oktober 2026 um 22:11:54 UTC+2:

Just tested the same dataset with just over slightly >1 gigapixel of output made by enblend compiled with different sets of options:

With OpenCL and OpenMP: 11m37.764s

Without OpenCL but with OpenMP: 10m32.471s

With OpenCL but without OpenMP: 10m17.625s

Without OpenCL or OpenMP: 10m21.700s

So at least with my single data point, neither one seems to actually help much.

Thanks, but this smells fishy.

First, check that enblend is correctly compiled with these options by calling "enblend -v -V".

Second, OpenCL needs to opt in at compile time and also at runtime with "--gpu" switch.

For OpenMP check that not an environment variable ( OMP_NUM_THREADS or other like this) is limiting the number of threads.

During execution check also in a process monitor the number of threads. At least for without and with OpenMP there should be a difference.

Thomas

[Kyle Maas]

Interesting.  "enblend -v -V" shows "Extra feature: OpenCL: no" despite cmake feature selection showing:

 feature selection:
   enable debugging support:       no
   enable malloc debugging:        no
   enable dynamic loading          yes (via dl)
   OpenEXR image format            yes
   use OpenMP:                     yes
   use OpenCL:                     yes (search path: /usr/local/share/enblend/kernels:/usr/share/enblend/kernels)
   use Exiv2:                      yes
   use TCMalloc:                   no

I'll have to do some debugging and see if I can figure out why.

No environment variables like OMP_NUM_THREADS, and this system has ample cores, RAM, and two discrete GPUs to work with.

Warm Regards,
Kyle Maas

--
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 visit https://groups.google.com/d/msgid/hugin-ptx/11894e30-f000-4adf-8db4-bd2358e3b5ecn%40googlegroups.com.

[Kyle Maas]

Think I found it.  Excerpt from configure:

checking for CL/cl.hpp... no
checking for OpenCL/cl.hpp... no
checking for windows.h... no
checking for OpenCL library... no

...even with dev-cpp/clhpp and dev-util/opencl-headers installed (on Gentoo).  Looks like it's because this is using the long-deprecated OpenCL 1.x bindings which were finally removed from the OpenCL repo back in 2022:

https://github.com/KhronosGroup/OpenCL-Registry/pull/124

Any objections to me attempting to port it to the new unified OpenCL bindings (CL/opencl.hpp)?

Warm Regards,
Kyle Maas