Hugin 2019.2.0 rc1 released

[T. Modes]

Hi all,

today we are releasing release candidate 1 of Hugin 2019.2.

Source tarball can be downloaded
at sourceforge: https://sourceforge.net/projects/hugin/files/hugin/hugin-2019.2/hugin-2019.2.0-rc1.tar.bz2/download
or at launchpad: https://launchpad.net/hugin/2019.2/2019.2rc1/+download/hugin-2019.2.0-rc1.tar.bz2

Verify its checksums:

md5:

ed8a602894dcbbe5c96ec0e265a70c9f  hugin-2019.2.0-rc1.tar.bz2

sha1: 

b6818e7eb32475826d67982871168ae059b730df  hugin-2019.2.0-rc1.tar.bz2

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

(The rc1 correspond to changeset 6c8394bb3ce7 in our repository, which is also tagged as 2019.2rc1).

Changes since 2019.0

* Mainly a bug fix release.
* Fixes raw import on Mac OS.
* Fixes bugs in verdandi/internal blender.
* Scripting interface needs now Python3.
* Improvements for high dpi displays (Windows, GTK+3).

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

[T. Modes]

Binaries of Hugin 2019.2 rc1 for Windows (64 bit) can be downloaded from sourceforge:

https://sourceforge.net/projects/hugin/files/hugin/hugin-2019.2/Hugin-2019.2-rc1-win64.msi/download

Checksums

md5: aecc9bbc376786fc57b4b362678883dc
sha1: 32a26998ea52f34b683d8989bf8825e01b1dc41b

[Terry Duell]

Hello Thomas,

On Sat, 23 Nov 2019 22:34:30 +1100, T. Modes <Thomas...@gmx.de> wrote:

> Hi all,
>
> today we are releasing release candidate 1 of Hugin 2019.2.

Thanks Thomas for all your work in getting to this candidate.
I've been a bit slack with my testing of late...not as much time these
days, but I can at least confirm that this candidate builds and starts up
OK on Fedora 31.
When I get a chance I'll try to run a test project.

Cheers,
--
Regards,
Terry Duell

[Harry van der Wolf]

Hi,

I'm currently looking at the Dutch translation (new translations, corrected translations, revised translation, etc.)

The concept of layers and stacks is extremely hard to translate in Dutch, also because they sometimes can be used both, depending on the (Dutch) context.

(And then we have rows, like in mulit-row panoramas. I lately expressed that to a starting friend trying to get him enthusiastic for Hugin. For him rows are like in a brick wall, or in a spreadsheet. He thought that a row was a bracketed exposure set (as he knows that)  and then he said: "Ooh, so you can also have panoramas with multiple layers?" No, dear friend. Those are multi-row panoramas.)

For the Dutch users here (if there are still in this list):

For "layer" I used "laag".

For "stack" I did not(!) use "stapel", but used the completely new Dutch word "belichtings-lagenset".

Please let me know what you think. Is it good? should I use "stapel"? or do you have a better suggestion?

@Thomas: Thanks for your ongoing contribution to Hugin. It is a really great. 

(coming from a now once/twice a year occasional user)

Kind regards,

Harry

Op ma 25 nov. 2019 om 06:08 schreef Terry Duell <tdu...@iinet.net.au>:

--
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/op.0bsojivfrs0ygh%40localhost.

[T. Modes]

Hi Harry,

Am Donnerstag, 28. November 2019 12:23:12 UTC+1 schrieb Harry van der Wolf:

I'm currently looking at the Dutch translation (new translations, corrected translations, revised translation, etc.)

 

Thanks. I committed your changes.

Sorry, I can't help with the Dutch terms.

Thomas

[Bruno Postle]

Fedora packages of Hugin 2019.2 rc1 are here:
https://copr.fedorainfracloud.org/coprs/bpostle/panorama/

(Note that I'm still changing #!/usr/bin/env python3 to #!/usr/bin/python3 to get the build through the fedora tests)
--
Bruno

[David W. Jones]

Hmm, would that work on Debian? Since the only option that seems available is flatpack or something like it that I've never gotten to successfully work at all.



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

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

[Terry Duell]

Hello Bruno,

I don't have any trouble building with rpmbuild in an up-to-date Fedora 31
without those changes, so I assume you are building/testing in a much more
pedantic environment.

[Bruno Postle]

On 29 November 2019 06:06:17 GMT, Terry Duell wrote:

>On Fri, 29 Nov 2019 09:11:47 +1100, Bruno Postle wrote:

>> (Note that I'm still changing #!/usr/bin/env python3 to
>> #!/usr/bin/python3 to get the build through the fedora tests)
>
>I don't have any trouble building with rpmbuild in an up-to-date Fedora 31
>without those changes, so I assume you are building/testing in a much more
>pedantic environment.

Yes the fedora policy on this is much more pedantic. The /usr/bin/env stuff has use-cases for people who need to use weird computer systems, but it can only cause problems for people who get Hugin from a Linux distribution.

--
Bruno

[Harry van der Wolf]

Hi,

Op vr 29 nov. 2019 om 00:18 schreef David W. Jones <gnome...@gmail.com>:

On November 28, 2019 12:11:47 PM HST, Bruno Postle <br...@postle.net> wrote:
>Fedora packages of Hugin 2019.2 rc1 are here:
>https://copr.fedorainfracloud.org/coprs/bpostle/panorama/
>
>(Note that I'm still changing #!/usr/bin/env python3 to
>#!/usr/bin/python3 to get the build through the fedora tests)

Hmm, would that work on Debian? Since the only option that seems available is flatpack or something like it that I've never gotten to successfully work at all.

 I do not understand your question with regard to Debian. I have a Debian 8 (just switched on again), Debian 9 and Raspbian 10 system, and an Ubuntu Bionic system, all having python3 in /usr/bin. I do agree that the "/usr/bin/env python3" is highly preferable, but I do not see why it would not work on Debian.

Your answer about flatpack (should be flatpak I suppose) is a "general purpose" question over all distributions, not specifically for Debian where it should work (I think).

Can you elaborate on this? I think your mail is a little too short.

Harry

[T. Modes]

Hi Bruno,

Am Freitag, 29. November 2019 08:24:58 UTC+1 schrieb Bruno Postle:

Yes the fedora policy on this is much more pedantic. The /usr/bin/env stuff has use-cases for people who need to use weird computer systems, but it can only cause problems for people who get Hugin from a Linux distribution.

I didn't know this. So I let the /usr/bin/env approach.

A short search revealed that BSD like distros are using /usr/local/bin/python3.

So we have

/usr/bin/python3

/usr/bin/env python3

/usr/local/bin/python3

All 3 one are used by different distros, but not a single common usage...

Thomas

[David W. Jones]

Sorry for the confusion, it was too short and not clear. I was wondering if the Fedora Hugin packages mentioned above would work on Debian. Not Python 3. Sorry!

[Harry van der Wolf]

The "/usr/bin/env" command is used for many programs, not only python.

The "env" command checks the linux configuration where the default program has been installed in case of multiple versions like python2 or python3, but also java-8, java-10, java-11 and other multi-version installs.

If there are multiple installs of for example python3 and the OS "knows" about it, it can be overridden by "sudo update-alternatives --config python3" to point to /usr/bin, /usr/local/bin or wherever you have installed (your own) version of python.

It means that by using the "/usr/bin/env python3" (or /usr/bin/env javac") to use an "outside PATH" installation.

So in the case of "/usr/local/bin/python3", the command "/usr/bin/env python3" can point, and therefore use, the /usr/local/bin/python3.

Harry

Op vr 29 nov. 2019 om 16:19 schreef T. Modes <Thomas...@gmx.de>:

--
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/ca481fcd-99b1-4267-a8db-5a8307a7fd5c%40googlegroups.com.

[T. Modes]

Hi Harry,

Am Freitag, 29. November 2019 19:09:50 UTC+1 schrieb Harry van der Wolf:

It means that by using the "/usr/bin/env python3" (or /usr/bin/env javac") to use an "outside PATH" installation.

So in the case of "/usr/local/bin/python3", the command "/usr/bin/env python3" can point, and therefore use, the /usr/local/bin/python3.

So I understand the working of env also. But the usage of /usr/bin/env has been banned from Fedora...

[Harry van der Wolf]

I understand, but actually the "/usr/bin/env" is not a path, but an "alias" to a path set in the ENVIRONMENT.

So actually we need /usr/bin/python3 for linux, and /usr/local/bin/python3 for BSD. 

Note that BSD is Berkely unix (like NetBSD, OpenBSD but also MacOS and many others) and it is NOT linux (like fedora, debian, ubuntu, suse, redhat, etc. etc.). 

For a windows user that might seem a small difference, but it isn't. (well: when comparing windows with linux or bsd, the difference compared to windows is very small)

Harry

Op vr 29 nov. 2019 om 19:26 schreef T. Modes <Thomas...@gmx.de>:

--
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/b9dc107f-ff87-4186-9d32-a0ce1f4fe918%40googlegroups.com.

[Gunter Königsmann]

If fedora does one thing in a completely different way from Debian, BSD, Ubuntu, ArchLinux and MacOs and wants all software projects to decide if to decide for fedora or for the rest... ...why on earth do they do such a thing?

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[Bruno Postle]

It is easy enough for the fedora package to patch this indefinitely. It doesn't need to be changed in the Hugin source if it causes problems for bsd.

--
Bruno

[Andreas Metzler]

On 2019-11-29 "David W. Jones" <gnome...@gmail.com> wrote:
>>> On November 28, 2019 12:11:47 PM HST, Bruno Postle <br...@postle.net>
>>> wrote:
>>>> Fedora packages of Hugin 2019.2 rc1 are here:
>>>> https://copr.fedorainfracloud.org/coprs/bpostle/panorama/

[...]

> Sorry for the confusion, it was too short and not clear. I was
> wondering if the Fedora Hugin packages mentioned above would work on
> Debian. Not Python 3. Sorry!

Hello,

Debian packages of 2019.2.0 rc1 are available in experimental.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[Abrimaal]

I see no differences.
Not much has changed in the new versions (Windows) since 2016, when straightening single photos was introduced (thankful I am for this mode, the only introduced feature from my suggestions).
Thanks also for enabling image preview in "Open"
Thanks for "Cancel" when calculating crop takes too long. Usually it caused crash.

The installer still deletes the previous, stable version - it must be backed up before installing (no portable archive to unzip).

The background is still white what makes the work with night photos impossible.

Horizontal lines are not detected.

If the panorama editor is already open, clicking "View / Panorama editor" does not switch to panorama editor. I suggested to add Panorama editor as a tab of the simple interface (after Crop).

Batch processor still blocks the taskbar from auto-hiding. Even if auto-hide is enabled in the system settings, it is overriden by Batch processor. The visible taskbar makes the lower part of the screen unaccessible (until a "confirm click" on the icon every time a new task is added to the processor).

Filename suffixes "blended_fused" and "fused" are not shortened to "bf" and "fd". Who knows how long the process of photo editing can be. Such names as "Original_filename_2bf_2fd_bf2a_mk3c_e2a_acr_hue_hdr2b_mx" are normal in the process of photo editing. The filename suffix must be short, especially when working on Windows and Android with the same images (Android apps usually do not care for filenames).

Indeed, final panoramas are loaded multiple times to Hugin, often "blended_fused" is stitched together with "fused", then again "blended_fused_fused" with another panorama that is "blended_fused_blended_fused" - it outputs extremely long filenames. "blended_fused" and "fused" may be shortened by renaming software, what does not change names in the project files.

It is possible to load (.jpg +.png) (.png + .bmp) (.jpg + .tif + .png + other supported formats) at once, but (.jpg + .jpg) images cannot be stitched if they differ only by ICC profile. Simply, a dialog to discard color space could appear while loading. Or by default the profile discarded in settings.

There is no option to define the minimal distance between lines for the line detector, to avoid placing lines on the same tree or traffic sign that are never straight.

Why I am writing about the same again? This cannot be a war between a developer and a user who "dreams" of a collab, not ignoring each other.

New proposals to introduce
 
To extend the compression sliders in Panini general to negative values. The value 0 (rectilinear) is sometimes not enough, especially when correcting cylindrical panoramas taken with a mobile device. Adding horizontal lines and de-barrelizing takes a lot of time. Typing numbers by guessing is just guessing. This is the main difference between being a programmer and a photographer. The first one depends on numbers, the other on visuals - this is why I always use the simple interface, even with advanced work.
To extend the preview sliders to smaller angles in rectilinear and panini general. The image preview is sometimes 2x2 mm on the screen.

"Darker color priority" mode. The standard stitching mode (both by enblend and enfuse) includes all photography errors, such as sun flares, reflections (if they are not masked) in panoramas, because it bases on "brighter color priority".

"Open project location" from the batch processor right-click menu.

[Alister Ling]

THANK YOU THANK YOU!  Now I can use "Panini general" with sliders on my Gear360 images, which I could not on the 2016 Win version. 

Regards, Alister Ling