Hugin 2025.0 beta 1 released

[T. Modes]

Hi all,

today we are releasing beta 1 of Hugin 2025.0.0

Source tarball can be downloaded
https://sourceforge.net/projects/hugin/files/hugin/hugin-2025.0/hugin-2025.0beta1.tar.bz2/download

Verify its checksums:
md5:
5ce87268bc9fa43a7bedd84f3d0e5813  hugin-2025.0beta1.tar.bz2
sha1:
02e70e93c817872c3ff30f5c206eabf3d469bcfb  hugin-2025.0beta1.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 2eb1e558a243 our repository, which is also tagged as 2025.0beta1).

Changes since 2024.0

The most changes are under the hood and affect mainly the builders.

Now a C++17 compiler is needed. Therefore the boost library is not needed anymore. Also libjpeg and libpng are not needed when building the shared version (which is the default).

wxWidgets 3.2 or later is now required. The code has be refactored to follow the modern wxWidgets code style. With this change Hugin is now using vector SVG files instead of raster PNG files for the toolboor and buttons. This should improve the appearance on hdpi displays.

A new GUI has be added: hugin_toolbox. It provides a GUI for enfuse and for simple perspective correction.

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-2025.0/Hugin-2025.0beta1-win64.msi/download

MD5 checksum
8a4d4ea7e3bbdbca42e4f1f8bff6fbe5  Hugin-2025.0beta1-win64.msi

Request for translators
Please update the translation file of your language. New strings have been added, mainly by hugin_toolbox.

[Marius Loots]

New release!

Can I take a moment and give a big THANK YOU to all the developers.
Your time and dedication is highly appreciated.

Groetnis
Marius
mailto:marius...@up.ac.za
BMedSci (Hons) UP, PGCHE (UP) HCM (FPD)

add some chaos to your life and put the world in order

> --
> 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/29b6e30f-9b73-4f58-a55f-45c1f4a6444dn%40googlegroups.com.

--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[David W. Jones]

On October 2, 2025 9:10:57 PM HST, "'T. Modes' via hugin and other free panoramic software" <hugi...@googlegroups.com> wrote:
> Hi all,
>
> today we are releasing beta 1 of Hugin 2025.0.0

Hurrah! Unfortunately, I'll be away from home for two weeks, so cannot try building and playing with it. Me sad. But thank you, thank you, thank you!

> Changes since 2024.0
> The most changes are under the hood and affect mainly the builders.
> Now a C++17 compiler is needed. Therefore the boost library is not needed
> anymore. Also libjpeg and libpng are not needed when building the shared
> version (which is the default).

What is this "shared" version?

It supports BigTIFF output?

> wxWidgets 3.2 or later is now required.

Of course, the question is, will it build on Debian Bookworm. I guess I'll get to find that out.

> The code has be refactored to
> follow the modern wxWidgets code style. With this change Hugin is now using
> vector SVG files instead of raster PNG files for the toolboor and buttons.
> This should improve the appearance on hdpi displays.

Excellent! My 4K display will say thank you, as will my eyes.

> A new GUI has be added: hugin_toolbox. It provides a GUI for enfuse and for
> simple perspective correction.

Sounds interesting. I guess it can process an exposure or focus stack by itself?


--
David W. Jones
gnome...@gmail.com
exploring the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

[Frédéric Da Vitoria]

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

software wrote:
> Hi all,
>
> today we are releasing beta 1 of Hugin 2025.0.0

Hello and thank you Thomas.

If I find anything wrong, can write about it in this thread or do you
prefer me to create a separate thread ?

[Frédéric Da Vitoria]

... or add an entry in the launchpad bug tracker ?

[T. Modes]

I would prefer to open a bug report on launchpad.

But you can also write in this thread.

[Harry van der Wolf]

Op vr 3 okt 2025 om 11:23 schreef David W. Jones <gnome...@gmail.com>:

> wxWidgets 3.2 or later is now required.

Of course, the question is, will it build on Debian Bookworm. I guess I'll get to find that out.

bookworm comes with libwxgtk3.2-1 (sudo apt install libwxgtk3.2-1 libwxgtk3.2-dev) 

The problem is libtiff-dev

The following packages have unmet dependencies:
 libwebp-dev : Depends: libwebp7 (= 1.2.4-0.2+deb12u1) but 1.5.0-5 is to be installed
               Depends: libwebpmux3 (= 1.2.4-0.2+deb12u1) but 1.5.0-5 is to be installed
               Depends: libwebpdemux2 (= 1.2.4-0.2+deb12u1) but 1.5.0-5 is to be installed

I just did a quick check. I will look further this weekend.

[Bruno Postle]

Thanks Thomas!

As usual there is a preview build for fedora here: https://copr.fedorainfracloud.org/coprs/bpostle/panorama/ and 2025.0.0 will get pushed to official fedora when it is released.

-- 

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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/29b6e30f-9b73-4f58-a55f-45c1f4a6444dn%40googlegroups.com.

--

Bruno

[Robert Clausecker]

Greetings!

An initial test build on FreeBSD fails when selecting a C++17 compiler,
as the codebase uses the register keyword in some files, a keyword that
has been removed from the language. Please make up your mind on
whether you want C++17 or not.

I can work around this temporarily, but I'd rather not.

Will report additional errors as I encounter them.

Yours,
Robert Clausecker

Am Freitag, dem 03.10.2025 um 00:10 -0700 schrieb 'T. Modes' via hugin
and other free panoramic software:

[Robert Clausecker]

Hi again,

So turns out all problems are in dependencies. The "register" use is
in libpano13, perhaps a new release could be made that fixes this.
Another issue is in vigra, which can be fixed by updating the package.
Port seems to build fine then.

As libjpeg and libpng, are these not required at all or only at
runtime? This is relevant for declaring package dependencies.

Yours,
Robert Clausecker

Am Freitag, dem 03.10.2025 um 00:10 -0700 schrieb 'T. Modes' via hugin
and other free panoramic software:

[T. Modes]

fuz...@gmail.com schrieb am Sonntag, 5. Oktober 2025 um 02:44:02 UTC+2:

Hi again,

So turns out all problems are in dependencies. The "register" use is
in libpano13, perhaps a new release could be made that fixes this.

This is already fixed in repository some time ago. I tested it before. For testing the used gcc version compiled fine in C++17 mode. 

So there are differences between different compilers and even between different versions of the same compiler. 

@Bruno Could you release a new libpano version? (The repository contains also more fixes for newer compilers.)

As libjpeg and libpng, are these not required at all or only at
runtime? This is relevant for declaring package dependencies.

Hugin is using libjpeg/libpng only indirect via libvigraimpex. So if libvigraimpex has the correct dependencies it should not be needed for Hugin explicitly.

Thomas

[Bruno Postle]

On Sun, 5 Oct 2025, 08:20 'T. Modes' wrote:

This is already fixed in repository some time ago. I tested it before. For testing the used gcc version compiled fine in C++17 mode. 

So there are differences between different compilers and even between different versions of the same compiler. 

@Bruno Could you release a new libpano version? (The repository contains also more fixes for newer compilers.)

Ok, I'll try and do this soon. 

-- 

Bruno

[T. Modes]

That's just a reminder.

Until now only some minor bugs have been reported. So please test the new function (and check for regressions in older functions)

Also the first translation files have been updated:

de.po / ja.po / pt_BR.po
1861 translated messages.

But there are still some untranslated string in other languages:
cs_CZ.po
1786 translated messages, 52 fuzzy translations, 23 untranslated messages.
hu.po
1786 translated messages, 52 fuzzy translations, 23 untranslated messages.
it.po
1778 translated messages, 53 fuzzy translations, 30 untranslated messages.
nl.po
1786 translated messages, 51 fuzzy translations, 24 untranslated messages.
ru.po
1786 translated messages, 52 fuzzy translations, 23 untranslated messages.
sk.po
1784 translated messages, 48 fuzzy translations, 29 untranslated messages.

en_GB.po
66 translated messages, 40 fuzzy translations, 1755 untranslated messages.

And there are language files which requires more attention:
ca_ES.po
1644 translated messages, 142 fuzzy translations, 75 untranslated messages.
ca...@valencia.po
1644 translated messages, 142 fuzzy translations, 75 untranslated messages.
fr.po
1638 translated messages, 139 fuzzy translations, 84 untranslated messages.

da.po
1404 translated messages, 309 fuzzy translations, 148 untranslated messages.
es.po
1255 translated messages, 468 fuzzy translations, 138 untranslated messages.
eu.po
866 translated messages, 554 fuzzy translations, 441 untranslated messages.
fi.po
693 translated messages, 642 fuzzy translations, 526 untranslated messages.
pl.po
1149 translated messages, 446 fuzzy translations, 266 untranslated messages.
ro.po
573 translated messages, 719 fuzzy translations, 569 untranslated messages.
sv.po
941 translated messages, 592 fuzzy translations, 328 untranslated messages.
zh_CN.po
1189 translated messages, 436 fuzzy translations, 236 untranslated messages.
zh_TW.po
1149 translated messages, 455 fuzzy translations, 257 untranslated messages.

[Henk Tijdink]

Here is the dutch translation. Tested it in the beta version and it seems OK

Kind regards

Henk Tijdink

Op vrijdag 17 oktober 2025 om 16:41:13 UTC+2 schreef T. Modes:

[T. Modes]

Thanks Henk.

I commited your changes. But there is still one untranslated (fuzzy) translation?

Thomas

[Henk Tijdink]

Thomas I checked the file again and found in 1 line that I didn't toggle off Needs work in Poedit. Possibly that's the cause?

 Henk

Op donderdag 23 oktober 2025 om 17:04:28 UTC+2 schreef T. Modes:

[T. Modes]

Hi Henk,

h.ti...@gmail.com schrieb am Donnerstag, 23. Oktober 2025 um 20:57:52 UTC+2:

Thomas I checked the file again and found in 1 line that I didn't toggle off Needs work in Poedit. Possibly that's the cause?

yes, there is one fuzzy translation (= needs work in poedit)

The english string is "&Close without saving"

and the current Dutch translation is "Afsluiten zonder opslaan".

If this is ok, I can fix it by myself. 

Also which character should be used as shortcut? (see the ampersand sign in the Englisch string)

Thomas

[Henk Tijdink]

Hello Thomas

I thought that the ampersand  sign needed to be with the same character in english and dutch translation.
therefore I didn't put the ampersand.  If it doesn't conflict with other shortcuts you can do the A.
Other possibility is the s (english shut is in dutch  sluit), but possibly that conflicts with the save shortcut.

The string is OK.

Henk

Op vrijdag 24 oktober 2025 om 16:02:00 UTC+2 schreef T. Modes:

[Jeff]

Hello Everyone,

I'm a long-time user of Hugin, and a one-time bugfix contributor (back in 2011). I'm between jobs right now, so finally had some time to dig into a small bug/inconvenience that I've encountered with Hugin. I worry that it's so minor that no one else has encountered it. 

It's also not really a bug with Hugin, but there is a source code change that could be made to remove this inconvenience. Let me explain: I sometimes use Max Lyon's Tufuse (a closed-source, Windows-only command line application) when stacking images. When I've tried to set Tufuse as an alternative to Enfuse in Hugin's settings, I get an error when Tufuse is called in the stitching process. The error says something like "Cannot open file: <prefix>_stack_ldr_0000.tif". 

This error happens because Tufuse cannot accept command line arguments of the form "--arg=param", it only accepts arguments of the form "--arg param", but Hugin uses "--compression=<value>" when setting up all the arguments it passes to Enfuse (or the alternative you set in Hugin's settings). In src/hugin1/base_wx/StitchingExecutor.cpp, there are 7 instances of " --compression=". These are used to build the argument array that will be passed to Enblend or Enfuse. Both Enblend and Enfuse use the getopt_long() function to interpret command line parameters. According to https://linux.die.net/man/3/getopt_long,  "A long option may take a parameter, of the form --arg=param or --arg param." So, I think there shouldn't be a problem changing those instances of " --compression=" to " --compression " (replacing the equal sign with a space) in StitchingExecutor.cpp because Enblend and Enfuse should correctly interpret either format. Does anyone else see an issue with that? If not, what's the preferred method of a user submitting a change? Back in 2011 I think I emailed a patch file, but is it better to do a merge request in SourceForge? Please advise.

Thanks for listening,

Jeff

[Greg 'groggy' Lehey]

On Friday, 24 October 2025 at 20:13:01 -0700, Jeff wrote:
>
> This error happens because Tufuse cannot accept command line arguments of
> the form "--arg=param", it only accepts arguments of the form "--arg param",
> but Hugin uses "--compression=<value>" when setting up all the arguments it
> passes to Enfuse (or the alternative you set in Hugin's settings). In
> src/hugin1/base_wx/StitchingExecutor.cpp, there are 7 instances of "
> --compression=". These are used to build the argument array that will be
> passed to Enblend or Enfuse. Both Enblend and Enfuse use the getopt_long()
> function to interpret command line parameters. According to
> https://linux.die.net/man/3/getopt_long, "A long option may take a

> parameter, of the form *--arg=param* or *--arg param*." So, I think there

> shouldn't be a problem changing those instances of " --compression=" to "
> --compression " (replacing the equal sign with a space) in
> StitchingExecutor.cpp because Enblend and Enfuse should correctly interpret
> either format. Does anyone else see an issue with that?

Yes, I see an issue.

The change is invasive: people with scripts using compression= will
have to change the invocation to get it to work. The problem is
clearly with TuFuse, and my guess is that Microsoft users are in the
minority in this forum, and TuFuse users an even smaller minority.

My suggestion: find a way to include this change in the configuration
that chooses TuFuse over enfuse. I haven't investigated the best way
to do this, but presumably the configuration setup will offer a way to
do this.

Greg
--
Sent from my desktop computer.
Finger groo...@gmail.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[T. Modes]

Hi Henk,

h.ti...@gmail.com schrieb am Freitag, 24. Oktober 2025 um 19:56:54 UTC+2:

I thought that the ampersand  sign needed to be with the same character in english and dutch translation.
therefore I didn't put the ampersand.  If it doesn't conflict with other shortcuts you can do the A.

in your translation you can use the ampersand sign on a character which suits best in your language.

One example: the English string "&Quit"

in German translated with "&Beenden" and in Dutch with "S&top"

I removed the fuzzy (needs work) flag on this Dutch string and added the ampersand sign for A.

Thomas

[T. Modes]

Hi Jeff,

Jeff schrieb am Samstag, 25. Oktober 2025 um 05:13:01 UTC+2:

In src/hugin1/base_wx/StitchingExecutor.cpp, there are 7 instances of " --compression=".

There are also other parameters which are passed in the --arg= form.

So for consitent behaviour I don't want to change this for a single parameter for a single extern program not used by default by Hugin.

For using other programs the easiest way would be to use an user defined output sequence. There you have better control above all switches without the need to re-compiling.

The format is written in doc/executor_file_format.txt and Hugin come with an example file for smartblend (share/hugin/data/output/normal_smartblend.executor)

The only drawback is that you loose the ability to choose the output format on the stitcher tab. Instead you would need several user defined output sequences.

Thomas

[Jeff]

Thanks for the feedback Greg and Thomas. As I suspected, this is a problem only I have, and I have my workarounds. The first is to just export layers, the drag and drop the files into a batch script that calls TuFuse. The second is to adjust the command line parameters to Enfuse so that I get a more pleasing result. Enfuse and TuFuse are based on the same algorithm, but sometimes the default settings for TuFuse produce a slightly more pleasing result to my eye when compared to the default Enfuse settings.

Thanks again,

Jeff