Hugin 2017.0 released

[T. Modes]

Hi all,

today we are releasing Hugin 2017.0.

Changes since 2016.2.0
The version 2017.0 is mainly a bug fix release. The biggest fixes regard:
* Several fixes for working with HDR images (display in GUI, photometric optimizer, handling of under/over exposured pixels in merging code).
* Fixes handling of masks in cpfind when images needs remapping for cp finding.
* Sometimes unsaved changes were disregarded without asking the user (e.g. when loading a project via the recently used projects list). Unsaved changes should now always require user confirmation.

Besides the bug fixes some smaller improvements have been implemented.
* Optimizer tabs uses now checkboxes instead of bold underlined font for marking of variables to be optimized.
* Use wxWidgets help windows instead of default browser (Linux&Mac only, this provides table of content, index and full text search in help files).
* Added special assistant variant for single image projects.
* Display of final panorama dimensions on stitcher tab.
* Extended the user defined output sequences:
   ** The shipped user defined output sequences are exposed in the GUI as own sub-menu.
   ** Added some more user defined output sequences (layered TIFF, cube faces).
   ** Added new placeholder %sourceimage% to user defined output sequence.

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

Verify its checksums:
md5: 3b49a905da8ee395774347ee6b3903b0  hugin-2017.0.tar.bz2

sha1: 4ba7f5bf5afdadbea9cf10d15aa14e644ef94ed3  hugin-2017.0.tar.bz2

This is a source code release.
(The release corresponds to changeset eac5e8cc546e in our repository, which is also tagged as 2017.0.0).

Users communities produce executables for their respective platforms. Please announce them here.
Currently the following versions were made available for download:
MacOS: https://sourceforge.net/projects/hugin/files/hugin/hugin-2017.0/Hugin-2017.0.0.dmg/download (md5: 8bc4a503021fbca143b5904c53ed50d6)
Win32: https://sourceforge.net/projects/hugin/files/hugin/hugin-2017.0/Hugin-2017.0-win32.msi/download (md5: ec86c9090af7b8c19f41c40cffa33721)
Win64: https://sourceforge.net/projects/hugin/files/hugin/hugin-2017.0/Hugin-2017.0-win64.msi/download (md5: 434db5bb989a02b528eeb613ff0fe729)

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'.

Know issues
Hugin does not run native on Wayland because of a bug in the underlying wxWidgets library.
The source code contains a workaround which forces the usage of the XWayland emulation layer.
This workaround has be activated during compiling by adding -DUSE_GDKBACKEND_X11=on to the CMake command.

[Abrimaal]

First of all, thanks a lot for single photo straightening mode. It saves a lot of time and manual work.
There is a small problem that can grow into gigabytes. (Windows)
The batch processor does not remove temporary .tif files from single photos, but successfully removes them when stitching a multi-file panorama.
It happens only when the folder with photos is open in another image viewer (it is always open in another image viewer, because everybody knows how little a user can do in Windows Explorer).

[Gunter Königsmann]

On 03.07.2017 23:45, Abrimaal wrote:
> First of all, thanks a lot for single photo straightening mode. It saves
> a lot of time and manual work.
> There is a small problem that can grow into gigabytes. (Windows)
> The batch processor does not remove temporary .tif files from single
> photos, but successfully removes them when stitching a multi-file panorama.
> It happens only when the folder with photos is open in another image
> viewer (it is always open in another image viewer, because everybody
> knows how little a user can do in Windows Explorer).
>

If the problem is that the image viewer prevents the file from being
deleted for a fraction of a second - and by reading the file triggers
the virus scanner and the automatic indexing service which prevent a
deletion of the file. Or if the problem is that dropbox hinders the file
from being deleted while it is uploaded the following can be done:

- try to delete the file
- look if it is actually deleted
- if not: wait a second, try to delete it again and if that fails
another time: give up.

TortoiseSVN and wxMaxima do so in a few places.

If the image viewer keeps the files open indefinitely I don't think
hugin can work around this: For some reason windows doesn't let you
delete mark files that are currently open in any application as deleted
(which prevents a cleanup in this case). On Linux, Android and Mac Os
you can ask the operating system to delete opened files instead: They
will instantly disappear from the directory, but the disk space they
occupy will only be unallocated when the file is closed by all applications.

In theory on windows one could tell hugin to retry deleting all
no-more-used files every few seconds until that try succeeds and to stay
open as long as there still are temporary files left. But no other
application I know does do that.

Kind regards,

Gunter.

[David W. Jones]

Not related to Hugin, but at my office with Windows 7 I have encountered
situations where Windows refuses to let a file be moved because it
appears on the most recently opened files list of a program still open.

Note: the file itself is closed, not open, just the program that had
most recently opened it. The particular offender is MS Excel.

In a few cases, I've had to actually log off of Windows and restart it
to get Windows to finally accept that the file was no longer open.

I rarely work with images on Windows, and have set Windows Explorer to
not generate or show thumbnails, so can't tell you if any of the image
viewers included in Windows/MS Office would do the same thing.

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

[Frederic Da Vitoria]

Interesting. I never thought of the possible relation between a viewer and an antivirus. But I dont't think this is the issue here: Abrimaal wrote that cleanup worked with panoramas but not with straightening.

@Abrimaal: which image viewer are you using?

--

Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

[Abrimaal]

It is possible that the image viewer (FastStone or Machinery Explorer) is reading the file and creating a thumbnail in the same time. The .tif file can be easily deleted after it is displayed it the viewer. They .tif file must be deleted manually, if the user forgets, about 50 MB file remains in the folder.
The files/folders are not connected to dropbox.

 
>If the problem is that the image viewer prevents the file from being
>deleted for a fraction of a second - and by reading the file triggers
>the virus scanner and the automatic indexing service which prevent a
>deletion of the file. Or if the problem is that dropbox hinders the file
>from being deleted while it is uploaded the following can be done:

[Bruno Postle]

On Fri 30-Jun-2017 at 23:49 -0700, Thomas Modes wrote:
>
>today we are releasing Hugin 2017.0.

Thanks!

>Users communities produce executables for their respective platforms.
>Please announce them here.

Fedora packages are available in the panorama 'copr' add-on
repository here: https://copr.fedorainfracloud.org/coprs/bpostle/panorama/

It is too late to get into the imminent fedora 26 release itself,
but it should be part of the usual updates.

BTW, the source file is named hugin-2017.0.tar.bz2, but it contains
a folder called hugin-2017.0.0 - this makes packaging slightly more
complicated than it needs to be.

--
Bruno

[T. Modes]

Hi Bruno

Am Mittwoch, 5. Juli 2017 01:08:31 UTC+2 schrieb Bruno Postle:

BTW, the source file is named hugin-2017.0.tar.bz2, but it contains
a folder called hugin-2017.0.0 - this makes packaging slightly more
complicated than it needs to be.

Should we rename the source tarball?
(At least at sourceforge we can rename the exiting file. For launchpad we would need to upload a renamed file.)

Thomas

[Bruno Postle]

On 5 July 2017 16:26:49 BST, "T. Modes" wrote:
>
>Am Mittwoch, 5. Juli 2017 01:08:31 UTC+2 schrieb Bruno Postle:
>>
>> BTW, the source file is named hugin-2017.0.tar.bz2, but it contains
>> a folder called hugin-2017.0.0 - this makes packaging slightly more
>> complicated than it needs to be.
>
>Should we rename the source tarball?

In this case it makes sense to rename the tarball, it will still have the same checksum.

I do think the previous 2017.0.0 style naming scheme makes sense, but if you want to switch to 2017.0 naming for future releases then this would probably be ok (so far we never needed to use the last digit).

--
Bruno

[T. Modes]

Hi Bruno,

Am Mittwoch, 5. Juli 2017 18:42:41 UTC+2 schrieb Bruno Postle:

>Should we rename the source tarball?

In this case it makes sense to rename the tarball, it will still have the same checksum.

I renamed the 2 source tarballs.
 

I do think the previous 2017.0.0 style naming scheme makes sense, but if you want to switch to 2017.0 naming for future releases then this would probably be ok (so far we never needed to use the last digit).

I will think about it for the next cycle. Then we should also update the path in the archive.

Thomas

[David W. Jones]

I have this in my repositories:

deb http://ppa.launchpad.net/hugin/hugin-builds/ubuntu yakkety main

but that only seems to be offering me

2016.2.0+dfsg-0ubuntu1~yakkety (yakkety)

Changing repository from yakkety to zesty only changes the yakketys to
zestys.

Debian Testing repository offers this version of 2017:

2017.0.0~rx2+dsfg-2 (testing)

No newer build available anywhere?

Tried aligning an image stack today using 2017.0.0 et al from Testing
repository and got an "error 1" message. So figured final release
version less likely to have same problem.

Thanks.

[Greg 'groggy' Lehey]

On Friday, 30 June 2017 at 23:49:08 -0700, T. Modes wrote:
> Hi all,
>
> today we are releasing Hugin 2017.0.

The standard FreeBSD graphic/hugin port is now 2017.0. The package
will update automatically in a couple of days.

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

[Stefan Peter]

Dear David W. Jones

On 07.07.2017 07:57, David W. Jones wrote:
> I have this in my repositories:
>
> deb http://ppa.launchpad.net/hugin/hugin-builds/ubuntu yakkety main
>
> but that only seems to be offering me
>
> 2016.2.0+dfsg-0ubuntu1~yakkety (yakkety)
>
> Changing repository from yakkety to zesty only changes the yakketys to
> zestys.

This ppa only offers the latest source packages and links to the
standard binaries from the official Ubunto release.

But you can take advantage from the more up to date binary releases at
https://launchpad.net/~hugin/+archive/ubuntu/hugin-builds

And yes, I did not yet have the time to package the final 2017.0.0. But
I'm working on it.

But you can find the various release candidates at
https://launchpad.net/~hugin/+archive/ubuntu/next

They are announced on this mailing list, by the way, see
https://groups.google.com/d/msg/hugin-ptx/ZIFLUjmHvHc/KVIqFSaqAAAJ
for an example.

And if you feel adventurous, head over to
https://launchpad.net/~hugin/+archive/ubuntu/nightly
for a bleeding edge experience.

With kind regards

Stefan Peter


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
(See https://en.wikipedia.org/wiki/Posting_style for details)

[Stefan Peter]

On 01.07.2017 08:49, T. Modes wrote:
> Hi all,
>
> today we are releasing Hugin 2017.0.

Binary packages for Ubuntu trusty, vivid, xenial, yakkety, zesty and
artful are available from the Hugin PPA Packagers "latest Hugin builds"
repository at
https://launchpad.net/~hugin/+archive/ubuntu/hugin-builds

If you have installed the beta/release candidates from the "next Hugin
builds" PPA, please make sure you also have the "latest" PPA in your
sources.list.


Enjoy!

[David W. Jones]

Thanks. I just tried the ubuntu builds and the ubuntu next repositories,
nothing newer than a 2017.rc2 appears.

I don't use Ubuntu - I use Debian. Guess I'll keep checking.

[Stefan Peter]

Dear David W. Jones

Am 10.07.2017 um 07:25 schrieb David W. Jones:
>
> Thanks. I just tried the ubuntu builds and the ubuntu next repositories,
> nothing newer than a 2017.rc2 appears.
>
> I don't use Ubuntu - I use Debian. Guess I'll keep checking.

Both the RC2 and the final 2017.0.0 are tagged to the same revision
(7741:eac5e8cc546e) in the hugin source code, so from a functional point
of view, they are identical. This most probably is the reason the Debian
Maintainers did not hurry to repackage the final release.

Anyway, if you are trying to hunt down a bug, self compiling the tip
would be preferred, I think.

[Andreas Metzler]

Stefan Peter <s_p...@swissonline.ch> wrote:
[...]

> Both the RC2 and the final 2017.0.0 are tagged to the same revision
> (7741:eac5e8cc546e) in the hugin source code, so from a functional point
> of view, they are identical.

i.e. except for
dpkg -l hugin\*
there is absolutely no difference.

This most probably is the reason the Debian
> Maintainers did not hurry to repackage the final release.

Yes, I was reluctant to make a zero change upload, wasting buildd
cycles and network traffic.
[...]

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'

[David W. Jones]

On 07/10/2017 08:15 AM, Andreas Metzler wrote:
> Stefan Peter <s_p...@swissonline.ch> wrote:
> [...]
>> Both the RC2 and the final 2017.0.0 are tagged to the same revision
>> (7741:eac5e8cc546e) in the hugin source code, so from a functional point
>> of view, they are identical.
>
> i.e. except for
> dpkg -l hugin\*
> there is absolutely no difference.
>
> This most probably is the reason the Debian
>> Maintainers did not hurry to repackage the final release.
>
> Yes, I was reluctant to make a zero change upload, wasting buildd
> cycles and network traffic.
> [...]
>
> cu Andreas

So if I have:

2017.0.0~rc2+dfsg-2 from Debian Testing repository, I have the same
version as the announced 2017.0?

Thanks.

[Andreas Metzler]

David W. Jones <gnome...@gmail.com> wrote:
[...]

> So if I have:

> 2017.0.0~rc2+dfsg-2 from Debian Testing repository, I have the same
> version as the announced 2017.0?

Yes, that's right.

[Gnome Nomad]

On Thu, Jul 13, 2017, 06:28 Andreas Metzler <amet...@bebt.de> wrote:

David W. Jones <gnome...@gmail.com> wrote:
[...]
> So if I have:

> 2017.0.0~rc2+dfsg-2 from Debian Testing repository, I have the same
> version as the announced 2017.0?

Yes, that's right.

Cool, thanks.

--

David W. Jones
gnome...@gmail.com
authenticity, honesty, community
http://dancingtreefrog.com