Release 0.7.0 for Win32 available

[Tom Sharpless]

There is a Win32 build of hugin 0.7.0 on http://tksharpless.net (click
the "download" link). It is in my usual package, an executable self-
installing archive. I hope soon to have a proper Windows Installer
package as well.
-- Tom

[Guido Kohlmeyer]

Dear all,

I prepared a setup for Hugin (windows platform), which can be found on
http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe

Maybe one of the admins would be so kind to upload it to SourceForge.

Guido

Tom Sharpless schrieb:

[Yuval Levy]

Hi Guido,

Guido Kohlmeyer wrote:
> http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe

you may want to replace the installer license text. What is displayed
now applies for SVN snapshots, not really to a release.

the text is in platforms/windows/installer/installer_license.txt

other than that, good job, well done. I am happy to see that others have
now the skill to provide windows binary installers.

I succeeded making myself redundant :-)

Yuv

[Guido Kohlmeyer]

Dear Yuv,

I modified the license text slightly and build a new setup file.
It can be found at
http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe
the MD5 checksum is available as well
http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe.md5

Guido

Yuval Levy schrieb:

[Yuval Levy]

Dear Guido,

Guido Kohlmeyer wrote:
> I modified the license text slightly and build a new setup file.

I tested the installer quickly. The text looks good. The files are
installed in the right place.

At the end of the install process the call to the redirect-URL is
missing. The redirect-URL sends the user to a welcome page or to a
"sorry, you installed an old version" page based on the SVN number.

Other than that, the installer looks fine.

Yuv

[Guido Kohlmeyer]

Dear Yuv,

Thank you for a quick test of the installer. It was my first work with
the setup tool.
As you surely percieved I changed your install template a little bit to
match the available applications.

You are right, the call of the URL is missing. I removed it due to
following facts:
1. After a test install I got an error message, that the file was not
found, but after confirmation of the dialog my firefox started and
showed the welcome page. I expect this may be confusing to users and
guess them that something went wrong with the setup. This was the main
reason to remove it.
2. I don't like software or installer that "call home". Certainly
Hugin's setup is quite harmless, but in general a setup should install
the software on a local machine and nothing more. Maybe your point of
view is little different.

Can you provide the setup on panospace blog as well? I guess many
windows follower are waiting for it.

Tanks,
Guido

Yuval Levy schrieb:

[Yuval Levy]

Dear Guido,

Guido Kohlmeyer wrote:
> As you surely percieved I changed your install template a little bit to
> match the available applications.

I have not really tested all details.

> You are right, the call of the URL is missing. I removed it

OK, do as you please.

> Can you provide the setup on panospace blog as well? I guess many
> windows follower are waiting for it.

I'll link to Sourceforge from my blog when the binary is up there.

Yuv

[Pablo d'Angelo]

Hi Guido,

Guido Kohlmeyer wrote:
> Dear Yuv,
>
> I modified the license text slightly and build a new setup file.
> It can be found at
> http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe
> the MD5 checksum is available as well
> http://hugin.panotools.org/testing/hugin/hugin-0.7.0_win32-setup.exe.md5

I have just uploaded this installer to the sourceforge. Thanks a lot for
building it!

ciao
Pablo

[Ippei UKAI]

Hi all,

Just a quick question to the Windows users: how is the autopano-sift
available for Windows? Is it included in the package and asked during
install, or available separately somewhere else?

Cheers,
Ippei

[Yuval Levy]

Ippei UKAI wrote:
> Just a quick question to the Windows users: how is the autopano-sift
> available for Windows? Is it included in the package and asked during
> install, or available separately somewhere else?

short answer: included in the package (0.7.0 release).

long answer:

I had made provision for an installer with all CP generators and one for
an installer without CP generators

<http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/installer/hugin.iss?revision=3024&view=markup>
<http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/installer/hugin_no_patents.iss?revision=3199&view=markup>

The main reason for the two installers is patent compliance.

I had used the full installer for my snapshot builds as they are for
educational purpose only and are not built in or distributed from the USA.

I used the no_patents installer for distribution builds, e.g. the ones
that are shipped with Nodal Ninja.

The intention was to add match-n-shift once we have a 100% SIFT-free
solution, and ship it all in one package. But I like your idea of a
pluggable architecture in OSX (although I have not had access to a Mac
to see it in action yet).

Yuv

[Guido Kohlmeyer]

Dear Ippei and Yuv,

as Yuv already explained, the current installer has autopano-sift
included, but it is possible to exclude it during installation process
(selection of custom install, and deselecting of autopano-sift).

As noted in the output of autopano-sift, the usage seems to be prohibited
in the U.S.A. Additional the autopano-sift component has a note in the
installer.

I guess this is sufficient to point-out, that it should not be used in the
U.S.A.

If another kind of installation would be necessary, give me a note.

Guido

[Harry van der Wolf]

Hi Guys,

This has been discussed before and I have stated the same back then.

Below the SIFT license:
====
        Notice: The SIFT algorithm is restricted by patents in the United
        States and hence this software is not completely free to use. For
        details see the LICENSE file included in the distribution,
        before you start to use this software.

        The University of British Columbia has applied for a patent on
        the SIFT algorithm in the United States. Commercial
        applications of this software may require a license from the
        University of British Columbia.
====

It very specifically states "Commercial applications of this software...". I've been in contact with one of the developers (months back) and that commercial statement is exactly what matters. Non-commercial applications (use of), whether or not within other non-commercial applications (software and/or use of ) also in non-commercial applications (again use of), are also free in the USA.
The term applications (use of) and applications (software) makes it a bit unclear, but the license as such is clear enough.

So, please use the license accordingly. It is perfectly OK to include the software (and license) with Hugin as long as we (the packagers) state that it is only allowed to use it on a non-commercial basis in the USA and that we are not liable in case end users do not act according the license, e.g. use it commercially. (Like we are not liable if we hire cars to customers and the customers drive to fast with it).

Packaging could then take places as Yuv did (but with a little twist):
- deliver a full package for: a. non-commercial users in the USA
                                       b. both non-commercial and commercial users in the rest of the world
- deliver a "non CP" package for commercial users in the USA.

And yes: a completely free CP generator / matcher would be the ideal solution as this would also broaden the use of Hugin for commercial use also in the USA. As restricted by the license: Currently Hugin can only be used commercially without a CP generator / matcher.

Hoi,
Harry

2008/10/22 Guido Kohlmeyer <d...@gekko-design.de>

[Guido Kohlmeyer]

Dear Harry,

Thank you for the explanations. Thus Yuv's aproach should be continued. I
will take it into account, if I'll generate a new setup. What's the
approch on the other paltforms? Single installs or one package with a
control flow similar to my current windows setup?

By the way, is it planned to do maintenance releases, e.g. hugin 0.7.1?
This would be a good point to integrate bugfixes as well as to generate a
new setup.

Guido

Currently

> Hi Guys,
>
> This has been discussed before and I have stated the same back then.
>
> Below the SIFT license:
> ====
> Notice: The SIFT algorithm is restricted by patents in the United
> States and hence this software is not completely free to use. For
> details see the LICENSE file included in the distribution,
> before you start to use this software.
>
> The University of British Columbia has applied for a patent on
> the SIFT algorithm in the United States. Commercial
> applications of this software may require a license from the
> University of British Columbia.
> ====
>

> It very specifically states "*Commercial* *applications* of this

[Yuval Levy]

Dear Guido and Harry,

Guido Kohlmeyer wrote:
> Thus Yuv's aproach should be continued.

my approach was to look at those who are more experienced and have more
resources than me. Red Hat, Novell, Canonical are all large corporations
producing popular Linux distributions. Canonical is based in U.K. and
AFAIK has nothing that makes it subject to US jurisdiction. Red Hat is
100% US jurisdiction. Novell is an interesting case because it is a US
company that bought Suse, an off-shore subsidiary in Germany.

All of them have their own lawyers and it can be safely assumed that
they are looking at all legal aspects pertinent to their distribution.

Latest since the SCO lawsuits it has become clear how important it is to
know where the code comes from and what IP rights are attached to it.

In an ideal world, those companies have legal compliance processes in
place that examine each piece of code before letting it into the
distribution. The processes may not be perfect, but they are better than
mine simply because they have the necessary resources.

None of them includes SIFT code.

> I will take it into account, if I'll generate a new setup. What's the
> approch on the other paltforms? Single installs or one package with a
> control flow similar to my current windows setup?

The current windows setup is more or less the same as my snapshot
installer. It was done for educational purposes, i.e. learning to master
the control flow. I am not sure what the best architecture would be for
a distribution that is not bound to a particular purpose.

It could be a monolithic distribution with all the CP generators (and
all the blenders) in one single installer. Or it could be a pluggable
architecture, with each CP generator having its own installer.

The installer is not so much critical as is the choice of tool within
the process. Right now, I must go into the preferences to choose which
of the many CP generators to use, and to set its parameters. But much of
that is project related, and should IMO not be set in the general
program preferences, but in the project itself.

If the software can identify automatically, by a set of logical rules,
which CP generator would work best, then it should be done so (with an
option for the user to override it).

Specifically, on the Assistant tab I would like to see a box under the
2. Align... button similar to the box that is currently under the 1.
Load images...

Similar to 1. Load images..., I would like to see the software pre-fill
the values with defaults or with the result of some logic; and I would
like to have the option, as a user, to override the software.

In that box I would like to have:
- a dropdown with a list of the available CP detectors.
- an input field with their parameters (as they are now in the preferences)
- a checkbox to run Celeste on cloudy skies (and later a list of
checkbox when Celeste is trained against foliage, water, crowds, etc.)

in the current interface, for the advanced user, the choice of CP
detector / CP pruning mechanism would IMO belong on the Images tab where
the functionality/buttons to "Create control points" and "Remove points"
can be expanded to select the tool used for the task.

> By the way, is it planned to do maintenance releases, e.g. hugin 0.7.1?
> This would be a good point to integrate bugfixes as well as to generate a
> new setup.

http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/branches/release-0.7.0/
has been branched out, so if you want to integrate bug fixes you can
commit them there. And of course to trunk.

Yuv

[Harry van der Wolf]

2008/10/23 Yuval Levy <goo...@levy.ch>

Dear Guido and Harry,

Guido Kohlmeyer wrote:
> Thus Yuv's aproach should be continued.

my approach was to look at those who are more experienced and have more
resources than me. Red Hat, Novell, Canonical are all large corporations
producing popular Linux distributions. Canonical is based in U.K. and
AFAIK has nothing that makes it subject to US jurisdiction. Red Hat is
100% US jurisdiction. Novell is an interesting case because it is a US
company that bought Suse, an off-shore subsidiary in Germany.

All of them have their own lawyers and it can be safely assumed that
they are looking at all legal aspects pertinent to their distribution.

Latest since the SCO lawsuits it has become clear how important it is to
know where the code comes from and what IP rights are attached to it.

In an ideal world, those companies have legal compliance processes in
place that examine each piece of code before letting it into the
distribution. The processes may not be perfect, but they are better than
mine simply because they have the necessary resources.

None of them includes SIFT code.

 

 

The ones you mentioned may not include it in their distro's. Debian however, one of the strictest, does include it, and (K)Ubuntu, by now the biggest, also includes it.

Red Hat and Novell do have big commercial interests with "big bugs" license contracts, maintenance contracts and support contracts with DELL, IBM, HP/Compac and others, where these contracts are expanded to (second line) commercial business partners of DELL, IBM, but also resellers and finally end-users (customers). Their commercial "part" is the part that keeps them alive these days and where they can't take risk. Their lawyers ONLY look at their commercial interests and risks and not to the (non interesting and risk less) GPL, open source "no bugs generating" part of it.

That's a huge difference with Hugin and therefore not comparable at all (imo).

 

 

As soon as Hugin is at the same level as RedHat (or MySQL as another example), it might be wise to spend more time to these kind of legal aspects.

I have no fear whatsoever that "The university of British Columbia" will ever start a trial at a (commercial) panoVR photographer from the USA, using a Hugin "full package" from an Open Source packager. This will not be worth the effort (unless this photographer wins the world press photo or something like that and maybe even in that case I expect them (UBC) to use it as a showcase rather than a case for trial).

Big businesses or organisations (organizations for USA residents, also different here) starting to use a "full package" hugin to generate money for their businesses/organisations might be a completely different case for UBC.

 

 

 

@Guido: I suggested that "my" approach, a derivation of Yuv's approach, could be used. In Open Source it's still the packager who more or less decides what he/she wants to package (or risk). (And who is uncertain what is happening to him/her while he/she is serving the community with only the best intents as a volunteer spending many hours for others).

Also a big difference with RedHat, who deliver "products and services" for "mainframe, server, desktop, small/medium/big companies" with the above mentioned (big bugs) contracts (and yes also for the non-commercial end-user).

Also Ippei and I interpret things differently when it comes to these license cases. We've come to an agreement which we both feel serves us well (delivering autopano-sift-c as plugin as a separate, installable package within the Hugin package). However, we are both also not 100% happy with the situation.

I am however a fan of Ippei's plugin solution as it gives the packager the flexibility and possibility to deliver a hugin and their accompanying plugins from one single webpage, but not as one package. This keeps it save (next to making it more flexible for the packager to create hugin svn packages and occasionally do a CP plugin upgrade).

 

 

Hoi,

Harry

 

 

[Harry van der Wolf]

Hi all,

BTW:
- autopano-sift is part of redhat/fedora since Thu 28 Jul 2005.
- autopano-sift-c is part of fedora 8/9
- panotools is not part of Redhat: no license issue there afaik.

I think it is more related to "undiscovered area"  than to legal restrictions.

Harry

2008/10/23 Harry van der Wolf <hvd...@gmail.com>

[Bruno Postle]

On Thu 23-Oct-2008 at 17:30 +0200, Harry van der Wolf wrote:
>
>- autopano-sift is part of redhat/fedora since Thu 28 Jul 2005.
>- autopano-sift-c is part of fedora 8/9
>- panotools is not part of Redhat: no license issue there afaik.
>
>I think it is more related to "undiscovered area" than to legal
>restrictions.

Neither autopano-sift or autopano-sift-c are in fedora. pano13 is
in fedora but with the 160 HFoV limitation intact.

--
Bruno

[Bruno Postle]

On Thu 23-Oct-2008 at 17:01 +0100, Bruno Postle wrote:
>
>Neither autopano-sift or autopano-sift-c are in fedora. pano13 is
>in fedora but with the 160 HFoV limitation intact.

..and hugin-0.7.0 & enblend-3.2 should appear in fedora fc9 in a few
days, they will also be in fc10 when it is released in November.

--
Bruno

[Harry van der Wolf]

Sorry for the mis-information. I searched a Redhat package server that claimed to have all (standard) Redhat/Fedora packages indexed.
If Yuv and Bruno claim it's not there I immediately follow their info.

Harry

2008/10/23 Bruno Postle <br...@postle.net>

[Andreas Metzler]

Harry van der Wolf <hvd...@gmail.com> wrote:
> 2008/10/23 Yuval Levy <goo...@levy.ch>
[...]

>> my approach was to look at those who are more experienced and have more
>> resources than me. Red Hat, Novell, Canonical are all large corporations
>> producing popular Linux distributions. Canonical is based in U.K. and
>> AFAIK has nothing that makes it subject to US jurisdiction. Red Hat is
>> 100% US jurisdiction. Novell is an interesting case because it is a US
>> company that bought Suse, an off-shore subsidiary in Germany.

[...]

>> None of them includes SIFT code.

> The ones you mentioned may not include it in their distro's. Debian however,
> one of the strictest, does include it, and (K)Ubuntu, by now the biggest,
> also includes it.

[...]

Debian does _not_ ship autopano-sift(-c), not even as part of the
non-free archive.

There are unofficial Debian packages available on the web, eg on
Christian Marillat's debian-multimedia.org.

http://bugs.debian.org/325180
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'

[Yuval Levy]

Harry van der Wolf wrote:

> If Yuv and Bruno claim it's not there I immediately follow their info.

I don't claim anything. I just use the package manager to search for the
packages and they are not there.

> In Open Source it's still the packager who more
> or less decides what he/she wants to package (or risk)

Indeed, and since *my* approach was mentioned, I just described it, and
my own evaluation of my own risk. Your mileage might vary.

> As soon as Hugin is at the same level as RedHat (or MySQL as another
> example), it might be wise to spend more time to these kind of legal
> aspects.

My approach has nothing to do with Hugin's level or size. It has to do
with my own personal situation. Yours might vary.

> Their lawyers ONLY look at their commercial interests and risks and
> not to the (non interesting and risk less) GPL, open source "no bugs
> generating" part of it.

Indeed their lawyers (and they as companies) look at their commercial
interests and risks first (not only). But make no mistakes, they also
look at the GPL and other open source licenses which do not exclude
commerce. In fact, there are many viable business models that thrive on
the GPL and other open source licenses.

> I am however a fan of Ippei's plugin solution as it gives the packager
> the flexibility and possibility to deliver a hugin and their
> accompanying plugins from one single webpage, but not as one package.
> This keeps it save (next to making it more flexible for the packager
> to create hugin svn packages and occasionally do a CP plugin upgrade).

I am a fan of Ippei's plugin solution too (based on desk research, I
have not had access to OS X in more than a month and so I could not try
it out).

I've spelled out earlier this morning how and why I would like to plug
in different CP generators in different stitching projects.

Yuv

[Harry van der Wolf]

To start with:

>Debian does _not_ ship autopano-sift(-c), not even as part of the
>non-free archive.
>
>There are unofficial Debian packages available on the web, eg on
>Christian Marillat's debian-multimedia.org.
>
>http://bugs.debian.org/325180
>cu andreas

My debian check (and double check this evening) proves you're right (which you knew off course).
Sorry again for providing mis-information.

2008/10/23 Yuval Levy <goo...@levy.ch>

I've spelled out earlier this morning how and why I would like to plug
in different CP generators in different stitching projects.

Yuv

You have mentioned this before. Do you have experience where one generator gives better results than another? Or do you try them all in a project?
I'm also interested in bracketed pano series where I find all performing less good.

My default is panomatic because it's fastest and gives good results, especially at sky points. But celeste might be the solution there right now. I only switch to match-n-shift and/or autopano-sift-c when panomatic doesn't give good results. In those cases though I mostly find none of them give good results which means that I need to pick CP's by hand (I check CP's anyway after an auto CP run).

Harry

[Bruno Postle]

On Thu 23-Oct-2008 at 22:57 +0200, Harry van der Wolf wrote:
>
>I'm also interested in bracketed pano series where I find all performing
>less good.
>
>My default is panomatic because it's fastest and gives good results,
>especially at sky points. But celeste might be the solution there right now.
>I only switch to match-n-shift and/or autopano-sift-c when panomatic doesn't
>give good results.

If you use the match-n-shift --stacks option (available with the
latest Panotools::Script 0.19), then it does a reasonable job with
bracketed stacks.

Though you need to use the camera's shutter-speed bracketing
feature, and the shutter-speed needs to be in the photo EXIF, or the
sequence will be treated as a 'normal' panorama.

--
Bruno

[Guido Kohlmeyer]

Dear all,

I prepared an update for hugin 0.7.0 release version.
This is only a maintenance version to fix the crash during save of pto
file, more precisely the crash occurs during export of makefile.

The problems was discussed in following posts:
1. "0.7.0 crash on vista"
2. "User bug reports, sort of"

It can be downloaded here:
http://hugin.panotools.org/testing/hugin/hugin-0.7.0.3519-win32-update.exe

The file is an self-extracting archive that can be extracted directly in
the /bin directory of the hugin installation. The old files will be
overwritten. Please make an update of the files in the directory!

Feel free to test the new file versions.

Guido

Tom Sharpless schrieb:

[Stefan F.]

Since october 30. There is a new Ubuntu Release 8.10 (intrepid).
It was not possible to run the existing precompiled package from
Synaptic (Hugin 0.7.0, beta5).

I compiled Hugin 0.8.0.3524, Enblend & Co. as described in <http://
wiki.panotools.org/Hugin_Compiling_ubuntu> against the new Ubuntu
Release.
Apart from many warnings concerning code safety or depricated
functions everything worked fine.

My suggestions:
- Document how to checkout the stable release branch insted of trunk
(Hugin and Enblend)
- Correct typo for Exiftool: cd Image-ExifTool-7.48 (NOT 46)

For shure it would be helpful if there where a precompiled package for
Ubunt 8.10.

Thanks for all your work you are doing here!

--
Stefan

[Ippei]

Hi all,

Lately, I've assisted a friend of mine to install hugin on his PC. The
following are what I, a mac user, realised:

- General: It felt more stable than Mac version, but lacking quality
assuarance leaving tools that appeal only to geeks and detemined
users.
- Installer: By default, leaves tons of aliases on desktop. None
except one for hugin.exe is relevant for 90% of the users. Most users
do not know what to launch if there are so many choices presented.
Besides, why the hell do they all have same icons? It also is
desireable to add just the "Hugin" 'program' in Start menu rather than
forcing users to find the "hugin.exe" 'executable file' from among
many.
- Autopano-SIFT: Is the warning against patent violation subtle?
Didn't realise one being displayed. I guess it was mentioned in the
loong license text.
- Documents: The README and other files are installed without
extension. How can I read those files? Who knows... That's how Windows
works, so please take care.
- Icons: First, they are unly; uglier than other Windows icons. Could
someone take a look at the icon files to be used on Windows? Is there
any way to use antialiasing or alpha channel, or at least to fill
background colour to make it less ugly? You can reuse the graphics
that Mac version uses. Secondly, has someone thought about what file
should use which icon? I don't see why other than hugin.exe should
have the Hugin icon. We have the icon designed for .pto files. I can't
stand to see .pto files having the same icon as application.
- Lastly, could README_JP file be attached for the Japanese users? I
can provide converted PDF or HTML files if that's needed, though I
remember Shift-JIS is considered default for Japanese Windows.

Cheers,
Ippei

[Ippei]

One more thing:
- The file downloaded from Sourceforge was compiled from SVN, hence
appears as a release build. In future we should upload binary releases
compiled from the source release.

Ippei

[Yuval Levy]

Ippei wrote:
> Hi all,
>
> Lately, I've assisted a friend of mine to install hugin on his PC. The
> following are what I, a mac user, realised:
>
> - General: It felt more stable than Mac version, but lacking quality
> assuarance leaving tools that appeal only to geeks and detemined
> users.

can you specify what you mean by "lacking quality assurance" and
"leaving tools that appeal only to geeks and determined users" ?

what would you expect to be different?

> - Installer: By default, leaves tons of aliases on desktop. None
> except one for hugin.exe is relevant for 90% of the users.

I can't comment about the installer that is on Sourceforge since I have
not built it and do not know the details.

I have built and distributed snapshot installers whose purpose was
testing. As such, the default of that installer was to install plenty of
things - things that I would not install in a production installer
geared at the general public. I agree with your comment that the default
install should satisfy the majority of users, not the power users; and
it should leave advanced features as options, not as default.

In general, there is one single icon for hugin on the desktop. All other
icons are droplets for enblend and enfuse, which indeed appeal to power
users.

In a testing setting I decided that installing them by default was the
right thing to do. Accidentally, it also appeal to power users.

Erik Krause's droplets are one of the things I do keep on my desktop
(and no hugin icon - I start programs from the QuickLaunch). Because
they are convenient, and easy to use. But I agree they are not relevant
to the majority of users, and should be optional, with default not to
install them.

> why the hell do they all have same icons?

The droplets don't have an icon at all. This is the default look of a
windows shortcut to an executable BAT file, and they are all BAT files.
To assign different icons is an effort, and obviously nobody has judged
it important enough. Windows users have different aesthetic values as
Mac users.

> It also is desireable to add just the "Hugin" 'program' in Start menu
> rather than forcing users to find the "hugin.exe" 'executable file'
> from among many.

I am not sure I understand what you mean. In Windows, the "All Programs"
entry inside the Start menu is the equivalent of the "Applications"
entry in the Mac's finder. But this is where the analogy stops.

To my understanding, Mac users are used to only have the program in
"Application". I have too little experience of the Mac to know where
documentation and other things go. I have seen only a Utilities
subfolder - all the rest are apps, all at the same level.

In Windows, the commonly accepted practice is for every software
publisher to add their own folder insode "All Programs" and to put many
things in there, including documentation links, readme files, and
uninstaller.

Moreover, Windows software publishers engage in a competition for "user
mindshare", which result in a nearly unbearable pollution of the
desktop, the quick launch bar, the status bar and the All Programs
folder with icons designed to remind the user of that particular
software. I find myself very often re-arranging things to be more
adapted to my way of working:
- I leave everything intact in the "All Programs" folder, but copy from
there those icons that I need (the equivalent to the mac's .app icons,
if I understand the Mac correctly) into my own "Apps" folder, from where
I launch them.
- I keep my own "Apps" folder in the quick launch bar, so that it opens
with a list of small icons that I click to start the app I intend to start.
- I ignore the pollution in the "All Programs" folder. My only reasons
to go in there is to search for an app that I just installed or that I
seldom used. "All Programs" is so useless, that I even have to re-sort
it alphabetically from time to time.
- after installing a program, I often have to clean up / delete icons
that are installed on the desktop and in the quick-launch bar, and I
have to look at the startup items to remove useless resource hogs that
are installed to start on startup and occupy the visually important
status bar.

within this context, I think that the hugin Windows installer does a
decent job, and I am not sure if what you mean would not mean changing
the metaphore to the Mac's metaphore.

> - Autopano-SIFT: Is the warning against patent violation subtle?
> Didn't realise one being displayed. I guess it was mentioned in the
> loong license text.

AFAIK it is displayed in the flurry of text that is outputted when
autopano-SIFT-C runs.

> - Documents: The README and other files are installed without
> extension. How can I read those files? Who knows... That's how Windows
> works, so please take care.

This is a regression compared to my snapshot installer. When preparing
my snapshot installers, I would *manually* convert all the README files
(Windows is CR+LF, while those in SVN are not) and add the .txt
extension. I have not thought of how to automate this in the build.
Probably it is possible, and in any case, whoever builds the installer
should indeed take care.

> - Icons: First, they are unly; ...

plenty of good and valid points. I guess many of them could be
implemented by people with enough time and motivation. I don't know much
about the technical issues of icons on the Windows platform: I consider
it generally an ugly platform, so maybe this is why I don't bother that
much about those things that seems to bother you? I know Mac users value
aesthetics more than Windows users.

> - Lastly, could README_JP file be attached for the Japanese users? I
> can provide converted PDF or HTML files if that's needed, though I
> remember Shift-JIS is considered default for Japanese Windows.

that should definitely happen. When I worked through the different
readme files in deciding whether to put them into my snapshot installer
(and thus in files used to generate the installer as they are still
recorded in SVN), I tried to open the README_JP file and it displayed
gibberish. Windows is known to have problem with charsets. Other
non-Latin charsets open well on my Windows XP box. An HTML or a PDF
would surely help.

> One more thing:
> - The file downloaded from Sourceforge was compiled from SVN, hence
> appears as a release build. In future we should upload binary releases
> compiled from the source release.

This was an issue with the CMake build, and I corrected it to the best
of my knowledge with Rev 3503.

Before that, there was a TODO mentioned in the root level CMakeLists.txt
(actually the comment is still there):
# TODO: at each release, set current SVN revision here!

This has not happened when the 0.7.0 tarball was released, so that
building it would call the release 0.7.0.0, which is inherently wrong,
and has further consquences on the Windows build, because unlike the
Linux (and Mac?) build extracting the SVN revision number was not
automated. I have automated that, and also the above mentioned TODO at
each release (although it would need to be tested), so that when
stripping the .svn folders from the filesystem tree that will eventually
become a tarball, everything should work automatically. Then building
from the tarball should also work effortless and as intended in Windows.

I hope my comments shed some lights on the particularities of the
windows build. Maybe they may motivate some of the windows contributors
to do those things you are suggesting, most of which make sense to me
but are just too low on my list of priorities to bother.

And if there are still open questions (I know I lack a lot of
Mac-knowledge) or misunderstandings, please keep the thread going.

Yuv

Yuv

[Ippei]

Yuval Levy wrote:

> Ippei wrote:
> > Lately, I've assisted a friend of mine to install hugin on his PC. The
> > following are what I, a mac user, realised:

> > - General: It felt more stable than Mac version, but lacking quality
> > assuarance leaving tools that appeal only to geeks and detemined
> > users.
>
> can you specify what you mean by "lacking quality assurance" and
> "leaving tools that appeal only to geeks and determined users" ?
> what would you expect to be different?

I meant the impression of the installed files is somewhat of technical
tools, like when I install command line academic tools. Once hugin is
launched, it's the familiar hugin interface, which isn't common to all
platforms.

> > - Installer: By default, leaves tons of aliases on desktop. None
> > except one for hugin.exe is relevant for 90% of the users.
>
> I can't comment about the installer that is on Sourceforge since I have
> not built it and do not know the details.
>
> I have built and distributed snapshot installers whose purpose was
> testing. As such, the default of that installer was to install plenty of
> things - things that I would not install in a production installer
> geared at the general public. I agree with your comment that the default
> install should satisfy the majority of users, not the power users; and
> it should leave advanced features as options, not as default.
>
> In general, there is one single icon for hugin on the desktop. All other
> icons are droplets for enblend and enfuse, which indeed appeal to power
> users.
>
> In a testing setting I decided that installing them by default was the
> right thing to do. Accidentally, it also appeal to power users.
>
> Erik Krause's droplets are one of the things I do keep on my desktop
> (and no hugin icon - I start programs from the QuickLaunch). Because
> they are convenient, and easy to use. But I agree they are not relevant
> to the majority of users, and should be optional, with default not to
> install them.

That's definitely a TODO then. My friend's first question was "which
program should I open?"
Also, the alias should be named "Hugin", not "hugin.exe" if that's
possible.

> > why the hell do they all have same icons?
>
> The droplets don't have an icon at all. This is the default look of a
> windows shortcut to an executable BAT file, and they are all BAT files.
> To assign different icons is an effort, and obviously nobody has judged
> it important enough. Windows users have different aesthetic values as
> Mac users.

Weird. When I saw it, those aliases on the desktop all bore the same
Hugin icon including the enblend ones.

> > It also is desireable to add just the "Hugin" 'program' in Start menu
> > rather than forcing users to find the "hugin.exe" 'executable file'
> > from among many.
>
> I am not sure I understand what you mean. In Windows, the "All Programs"
> entry inside the Start menu is the equivalent of the "Applications"
> entry in the Mac's finder. But this is where the analogy stops.

What I meant is that how Hugin is organised inside the Start menu. I
know Windows organises Start menu with folders and aliases (or
"shortcut" or whatever), and all hugin stuff would be found under the
"Hugin" folder. But using alias means "hugin.exe" can be shown as
"Hugin" there instead, right? Also, the other tools can be organised
into subfolders like "droplets" "tools" "command line tools" etc.

> > - Autopano-SIFT: Is the warning against patent violation subtle?
> > Didn't realise one being displayed. I guess it was mentioned in the
> > loong license text.
>
> AFAIK it is displayed in the flurry of text that is outputted when
> autopano-SIFT-C runs.

So no approval while installation or before the autopano process
happens?

> > - Documents: The README and other files are installed without
> > extension. How can I read those files? Who knows... That's how Windows
> > works, so please take care.
>
> This is a regression compared to my snapshot installer. When preparing
> my snapshot installers, I would *manually* convert all the README files
> (Windows is CR+LF, while those in SVN are not) and add the .txt
> extension. I have not thought of how to automate this in the build.
> Probably it is possible, and in any case, whoever builds the installer
> should indeed take care.

I guess another TODO then. I actually put .txt manually for the Mac
package too. Couldn't we just break the UNIX convention and put .txt
on the SVN?

> > - Icons: First, they are unly; ...
>
> plenty of good and valid points. I guess many of them could be
> implemented by people with enough time and motivation. I don't know much
> about the technical issues of icons on the Windows platform: I consider
> it generally an ugly platform, so maybe this is why I don't bother that
> much about those things that seems to bother you? I know Mac users value
> aesthetics more than Windows users.

Well, the problem is not that Windows icons are ugly but that Hugin's
ones are too much uglier than Windows norm. I hope someone would take
a look. I can provide the icons for Mac in PNG (actually I have put
the png icon on my homepage, which was soon after copied to Hugin's
homepage and still there).

Also, icons for the .pto files should be taken care. I actually
couldn't spot it in the source. Is it properly displayed on Linux?

Mac icons are not based on the files in the source but on an original
design acquired through a personal communication, so there might be
some difference in the situation.

If anyone is going to work on something new, rather than improvement
just for Windows, please consider to make it as large as 512 pixels.
Apple has declared the conventional 128 pixels is "minimum".

> > - Lastly, could README_JP file be attached for the Japanese users? I
> > can provide converted PDF or HTML files if that's needed, though I
> > remember Shift-JIS is considered default for Japanese Windows.
>
> that should definitely happen. When I worked through the different
> readme files in deciding whether to put them into my snapshot installer
> (and thus in files used to generate the installer as they are still
> recorded in SVN), I tried to open the README_JP file and it displayed
> gibberish. Windows is known to have problem with charsets. Other
> non-Latin charsets open well on my Windows XP box. An HTML or a PDF
> would surely help.

Okay. I can do that. If anyone needs the converted file, please
specify in what format you want the file in. However, I think the text
file uses a standard encoding that most applications can handle if you
specify the charset properly and display with Japanese font.

> > One more thing:
> > - The file downloaded from Sourceforge was compiled from SVN, hence
> > appears as a release build. In future we should upload binary releases
> > compiled from the source release.
>
> This was an issue with the CMake build, and I corrected it to the best
> of my knowledge with Rev 3503.
>
> Before that, there was a TODO mentioned in the root level CMakeLists.txt
> (actually the comment is still there):
> # TODO: at each release, set current SVN revision here!
>
> This has not happened when the 0.7.0 tarball was released, so that
> building it would call the release 0.7.0.0, which is inherently wrong,
> and has further consquences on the Windows build, because unlike the
> Linux (and Mac?) build extracting the SVN revision number was not
> automated. I have automated that, and also the above mentioned TODO at
> each release (although it would need to be tested), so that when
> stripping the .svn folders from the filesystem tree that will eventually
> become a tarball, everything should work automatically. Then building
> from the tarball should also work effortless and as intended in Windows.

That sort of makes sense. My 0.7.0 build for Mac is manually specified
to build release build instead of prerelease. There's a sort of
failsafe as release tar ball has no svn hence leading to automatic
revision retrieval failing and demanding manual intervention. (I think
that's how cmake is written also.)

> I hope my comments shed some lights on the particularities of the
> windows build. Maybe they may motivate some of the windows contributors
> to do those things you are suggesting, most of which make sense to me
> but are just too low on my list of priorities to bother.

Same here. Would be really nice if anyone could take a look. The last
small details like above make a huge difference in the users' first
impression of Hugin. That's the fine line whether the user would go
straight to uninstall or not. In my experience, users often have more
patience to a nice looking software with bugs than to stable software
with unwelcoming impression.

Ippei

[Yuval Levy]

Ippei wrote:

> Yuval Levy wrote:
>> I agree they are not relevant to the majority of users, and should
>> be optional, with default not to install them.
>
> That's definitely a TODO then. My friend's first question was "which
> program should I open?"

Guido built the Windows installer. He modified for that my .iss file,
which is in SVN. If he shares his .iss file, anybody could have a look
at that.

> Also, the alias should be named "Hugin", not "hugin.exe" if that's
> possible.

I have no desktop icon (I hate program's that put an icon on the
desktop) but the icon inside the Program Files folder is called only
Hugin here.

What version of Windows does your friend have?

> Weird. When I saw it, those aliases on the desktop all bore the same
> Hugin icon including the enblend ones.

very well possible - as I said, my comment is a general one, based on
the snapshots installers I used to produce. Guido has modified the .iss
file. It may be one of the changes he implemented there. Or it may be
something weird with your friend's Windows box. Registry pain comes to
my mind...

> What I meant is that how Hugin is organised inside the Start menu. I
> know Windows organises Start menu with folders and aliases (or
> "shortcut" or whatever), and all hugin stuff would be found under the
> "Hugin" folder. But using alias means "hugin.exe" can be shown as
> "Hugin" there instead, right? Also, the other tools can be organised
> into subfolders like "droplets" "tools" "command line tools" etc.

OK, I understand. AFAIK the droplets need to be on the desktop to work.
Or has somebody got them to work from the Start menu? yes, hugin.exe can
be shown as Hugin. It is like that currently on my desktop. SUre, the
other tools could be organized into subfolders. It's relatively easy to
do and a good idea.

> So no approval while installation or before the autopano process
> happens?

I am afraid not. Well, standard windows installer ask people to click on
a button to accept a license (that they never read), and the license
text with my snapshot installer was
<http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/installer/installer_license.txt?revision=2839&view=markup>

I don't know how the text looks like on the current binary on SF. We
definitely should do something about this.

> I guess another TODO then. I actually put .txt manually for the Mac
> package too. Couldn't we just break the UNIX convention and put .txt
> on the SVN?

I second that request.

> Mac icons are not based on the files in the source but on an original
> design acquired through a personal communication, so there might be
> some difference in the situation.

If Mac icons are nicer, shouldn't they be adopted also on other
platforms? I'd like to see them. Are they in SVN? or how do you apply them?

> If anyone is going to work on something new, rather than improvement
> just for Windows, please consider to make it as large as 512 pixels.
> Apple has declared the conventional 128 pixels is "minimum".

I'd say: draw them in SVG...

> Okay. I can do that. If anyone needs the converted file, please
> specify in what format you want the file in.

HTML would be best IMO. Can you add it to SVN?

> There's a sort of
> failsafe as release tar ball has no svn hence leading to automatic
> revision retrieval failing and demanding manual intervention. (I think
> that's how cmake is written also.)

that's how it used to be. and with windows there was no retrieval at
all, so it always demanded manual intervention.

the way I have implemented it now is that if there is svn, it does
automatic revision retrieval and stores the revision in a simple text
file. automatic revision retrieval works for windows too. once the tree
is stripped of svn for producing the tarball, the small text file with
the revision number is preserved. when the tarball is built, it
retrieves the revision number from the text file. last but not least, if
the text file is not found, manual intervention is required.

>> I hope my comments shed some lights on the particularities of the
>> windows build. Maybe they may motivate some of the windows contributors
>> to do those things you are suggesting, most of which make sense to me
>> but are just too low on my list of priorities to bother.
>
> Same here. Would be really nice if anyone could take a look. The last
> small details like above make a huge difference in the users' first
> impression of Hugin. That's the fine line whether the user would go
> straight to uninstall or not. In my experience, users often have more
> patience to a nice looking software with bugs than to stable software
> with unwelcoming impression.

yes, you are right. i have not had time to toy with hugin this weekend,
and I am unlikely to find time in the coming days. right now on my todo
list is to solve the Olympus EXIF thing. I actually have the solution,
am bogged down in implementation details. Debugging / playing this with
Windows is a nightmare. I need to reboot to Linux, but my Ubuntu install
is out of order at the moment.

Yuv

[Ippei]

Yuval Levy wrote:
> Ippei wrote:
> > Yuval Levy wrote:
> >> I agree they are not relevant to the majority of users, and should
> >> be optional, with default not to install them.
> >
> > That's definitely a TODO then. My friend's first question was "which
> > program should I open?"
>
>
> Guido built the Windows installer. He modified for that my .iss file,
> which is in SVN. If he shares his .iss file, anybody could have a look
> at that.
>
>
> > Also, the alias should be named "Hugin", not "hugin.exe" if that's
> > possible.
>
> I have no desktop icon (I hate program's that put an icon on the
> desktop) but the icon inside the Program Files folder is called only
> Hugin here.
>
> What version of Windows does your friend have?

Maybe it was nicely called "Hugin". Sorry, I'm writing from my
unprecise memory. I only assited his install standing in the back,
don't remember the details very well. My friend definitely uses XP
though.

> > Mac icons are not based on the files in the source but on an original
> > design acquired through a personal communication, so there might be
> > some difference in the situation.
>
> If Mac icons are nicer, shouldn't they be adopted also on other
> platforms? I'd like to see them. Are they in SVN? or how do you apply them?

Icon files are in the mac directory. The large size application icon
is identical to:
http://hugin.sf.net/css/hugin-icon.png

The original file I had wasn't transparent, and I think was smaller
than 128 piexels. I smoothed all the edges and put alpha channel for
transparency and added white shadow to make it visible on dark
background. Easier said than be done. Took me hours. If Windows icon
can't have alpha channel though, this means nothing.

> > If anyone is going to work on something new, rather than improvement
> > just for Windows, please consider to make it as large as 512 pixels.
> > Apple has declared the conventional 128 pixels is "minimum".
>
> I'd say: draw them in SVG...

I think the norms of icon designing is to draw in vector and finalise
in the target resolution.
Anyway, we have a good design now. Just need some rework to get the
image quality up on Windows.

> > Okay. I can do that. If anyone needs the converted file, please
> > specify in what format you want the file in.
>
> HTML would be best IMO. Can you add it to SVN?

I'd rather keep the original on SVN as text file for now following how
the main README file is saved. Besides, I'm stuck with dial up
connection at least for another week. I'll see.

Ippei

[Thomas Steiner]

>> I'd say: draw them in SVG...
>
> I think the norms of icon designing is to draw in vector and finalise
> in the target resolution.
> Anyway, we have a good design now. Just need some rework to get the
> image quality up on Windows.

...and dance tango!
http://tango.freedesktop.org/
thomas

[Yuval Levy]

Ippei wrote:
> Icon files are in the mac directory. The large size application icon
> is identical to:
> http://hugin.sf.net/css/hugin-icon.png

is it
<http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/mac/Hugin.icns?revision=2494&view=markup>
? what format is this file?

> The original file I had wasn't transparent, and I think was smaller
> than 128 piexels. I smoothed all the edges and put alpha channel for
> transparency and added white shadow to make it visible on dark
> background. Easier said than be done. Took me hours. If Windows icon
> can't have alpha channel though, this means nothing.

To be honest I don't know about Windows icons, but from the look on the
desktop they do have some sort of transparency. If it is a real alpha
channel or a simple one bit mask, I don't know.

>> I'd say: draw them in SVG...
>
> I think the norms of icon designing is to draw in vector and finalise
> in the target resolution.
> Anyway, we have a good design now. Just need some rework to get the
> image quality up on Windows.

well, if somebody decides to rework, it would be good if the work
happens in SVG. As you said, "took you hours". If it's SVG, next time it
will only take minutes.

Yuv

[Yuval Levy]

Hi Stefan,

Stefan F. wrote:
> I compiled Hugin 0.8.0.3524, Enblend & Co. as described in <http://
> wiki.panotools.org/Hugin_Compiling_ubuntu> against the new Ubuntu
> Release.
> Apart from many warnings concerning code safety or depricated
> functions everything worked fine.

oh, so you had libglew-dev already on your machine? it is a new
dependency introduced about a month ago, and it was missing in the
documentation. I added it.

> My suggestions:
> - Document how to checkout the stable release branch insted of trunk
> (Hugin and Enblend)

for hugin it is documented just under the box documenting how to fetch
trunk - in the example it is revision 2906 which is quite old. you can
find a list of working revisions and comments at
<http://wiki.panotools.org/Development_of_Open_Source_tools#Specific_revisions>

for enblend, I do not recall the switch to request a given timestamp, in
Windows I use TortoiseCVS and I can set it in a GUI :-(

in both cases, you can download the tarballs from sourceforge if what
you are looking for is the stable release.

> - Correct typo for Exiftool: cd Image-ExifTool-7.48 (NOT 46)

done, thanks. There is a newe version of Exiftool, so it is now 7.52

> For shure it would be helpful if there where a precompiled package for
> Ubunt 8.10.

does anybody know how to build and distribute such precompiled packages?

Yuv

[Stefan F.]

On 8 Nov., 06:25, Yuval Levy <goo...@levy.ch> wrote:
> for enblend, I do not recall the switch to request a given timestamp, in
> Windows I use TortoiseCVS and I can set it in a GUI :-(

Bruno once gave me the following commandline:
# cvs -z3 -d:pserver:anonym...ous@enblend.cvs.sourceforge.net:/cvsroot/
enblend co -D '2008-07-18 21:00:00' -P enblend

Instead of posting revision numbers or dates, it would be better to
post a commandline to get a release branch that always contains the
latest fixes to the official release.
I read somewhere you have such a branch at least for hugin.

> > For shure it would be helpful if there where a precompiled package for

> > Ubuntu 8.10.

>
> does anybody know how to build and distribute such precompiled packages?

Maybe the ubuntu-guys do it themselves ?
They have hugin at <http://packages.ubuntu.com/intrepid/hugin>, but it
is an old rev. 3191

cheers
Stefan