Windows build of current SVN available

5 views
Skip to first unread message

Pablo d'Angelo

unread,
Jan 1, 2008, 1:18:43 PM1/1/08
to hugin and other free panoramic software
Hi all,

I have updated the CMake build system, it should be relatively easy to use
together with the updated precompiled libraries (for MSVC 2003). I have
updated http://wiki.panotools.org/Hugin_Compiling_Windows accordingly.

The snapshot itself is available at:
http://hugin.panotools.org/testing/hugin/hugin_0.7.0.2587_win32.msi

It includes all required programs such as enblend and pano13, as well as
utilities such as fulla and align_image_stack.

This is a largely untested release, I have only stitched a small test pano
with it. Any feedback welcome. It is probably quite useful to check if many
older bug reports on http://sourceforge.net/tracker/?group_id=77506&atid=550441
still apply to the current state. I will make better use of the bugtracker
in the future and will primarily fix bugs reported there.

Note that I don't have the resources to provide regular windows builds, so
help by a windows developer is still needed in the pre-release testing phase.

Happy new year,
Pablo

Yuval Levy

unread,
Jan 1, 2008, 2:24:56 PM1/1/08
to hugi...@googlegroups.com
Pablo d'Angelo wrote:
> The snapshot itself is available at:
> http://hugin.panotools.org/testing/hugin/hugin_0.7.0.2587_win32.msi

just a quick initial Installer feedback.

It did not remove/upgrade properly the previous version installed with
the installer. I ended up with double enblend and double panotools
because the new installer has a better folder logic.


> It includes all required programs such as enblend and pano13, as well
as utilities such as fulla and align_image_stack.

Does it include Autopano as well, particularly Autopano-C? I don't see it.

Another little detail: is it hugin or Hugin? although Windows is not
case-sensitive, it looks weird to have it installed in C:\Program
Files\hugin\Hugin

I quickly fired it up. The splash screen still says "0.7 Lucerne
edition". I assume this is all manual work - edit of the graphic as well
as copying of the files to the right location for the installer packaging?

If my assumption is right, would it be possible for the compiler to
output the version of hugin to a simple text file, and take that text
file as an input to an ImageMagick script to set the version right
automatically at compile time?

<http://sourceforge.net/tracker/index.php?func=detail&aid=1861776&group_id=77506&atid=550441>

So far I have only quickly looked at the preferences. It is nice to see
Rotation seach enabled by default. The disposition of the tabs on the
left hand side is not what I recall from previous ubuntu versions where
they are nicely aligned on the top. Is it difficult to put them on top,
or at least to make the space on the left wider so that the tabs text
can fully fit in it?

<http://sourceforge.net/tracker/index.php?func=detail&aid=1861778&group_id=77506&atid=550441>

I might have some time later on tonight for a full stitch.

HAPPY NEW YEAR
Yuv

Jim Watters

unread,
Jan 1, 2008, 3:42:42 PM1/1/08
to hugi...@googlegroups.com
Yuval Levy wrote:
> Pablo d'Angelo wrote:
> > The snapshot itself is available at:
> > http://hugin.panotools.org/testing/hugin/hugin_0.7.0.2587_win32.msi
>
> just a quick initial Installer feedback.
>
> It did not remove/upgrade properly the previous version installed with
> the installer. I ended up with double enblend and double panotools
> because the new installer has a better folder logic.
>
Are you sure the previous version on your system was not just an
unpacking of a zip file. I thought the same thing at first.

> > It includes all required programs such as enblend and pano13, as well
> as utilities such as fulla and align_image_stack.
>

I have been working on panotools over the holidays and plan on a new
release including updated plugins that will be Vista happy. 95% of
reported problems is with Vista. about 1 every other week.

I was going to include the helper tools with the plugins but now that
they will be statically linked to pano13 it wont make much difference.
Hugin is including most of the helper tools with its installation.

What I don't want to do is mess up peoples systems.
- Pano12.dll is still required for some yet duplicated tools that are
not being distributed with Hugin but are included with panotools installer.
- I don't want to have multiple copies of the same file installed in
different location.

*Proposal*
I will make the new plugin installer leave the previous version of the
tools behind.
Install only the plugins and install over the old plugins.
Ensure if panotools is uninstaller the plugins remain. Or can be easily
reinstalled.

What I then can do is recommend the installation of Hugin to get the new
PanoTools helpers.

The other option is to make panotools a merge module that other
installers will include. This will mean that the tools will get
installed into the same folder every time. As I am doing now with the
current plugin installation. It will probably mean that the previous
installation of panotools & Hugin must be uninstalled before installing
new version that includes merge modal.

I have a few bugs to track down before I am ready to commit more changes.

This is a better question for the panotools dev list but ....
Why was a bunch of files duplicated for the gimp-plugin and
gimp-plugin-ng? Why can they not just statically link to pano13 like
the rest of the tools? Has anyone ever built and released these?

If I have some time in a couple days I will look at the Hugin installer
and make some tweaks to fix the items Yuval mentioned and a couple
others if no one does it first.

--
Jim Watters

Yahoo ID: j1vvy ymsgr:sendIM?j1vvy
jwatters @ photocreations . ca
http://photocreations.ca

Bruno Postle

unread,
Jan 1, 2008, 4:57:24 PM1/1/08
to Hugin ptx
On Tue 01-Jan-2008 at 15:42 -0500, Jim Watters wrote:

>Why was a bunch of files duplicated for the gimp-plugin and
>gimp-plugin-ng? Why can they not just statically link to pano13 like
>the rest of the tools? Has anyone ever built and released these?

'gimp-plugin' is Helmut's original sources patched-up to work with
more recent versions of the gimp. This includes most of the files
from an older version of pano12, I don't know why, it does mean that
it doesn't require pano12. The PanoTools.exe binary on the
sourceforge download area is this code.

This is obviously a bit of a mess, so 'gimp-plugin-ng' was forked to
clean up the sources, remove all this cruft, add help, and link
against pano12. This job was never finished.

Anyone working on the gimp plugin should use the 'gimp-plugin-ng'
code as this is in a much better state.

I don't think there has ever been a tarball release of either
branch, though they both compiled on Linux last time I checked.

--
Bruno

Yuval Levy

unread,
Jan 1, 2008, 5:25:17 PM1/1/08
to hugi...@googlegroups.com
Jim Watters wrote:
> Are you sure the previous version on your system was not just an
> unpacking of a zip file. I thought the same thing at first.

pretty sure. I keep the unzipped version of hugin, panotools etc. in a
folder C:\prg_files to make sure that no space in the path name is the
cause of errors.

I run John Navas' installer first when he published it, and this is
where the old files came from.


> What I don't want to do is mess up peoples systems.

Excellent intention.


> - Pano12.dll is still required for some yet duplicated tools that are
> not being distributed with Hugin but are included with panotools installer.
> - I don't want to have multiple copies of the same file installed in
> different location.
>
> *Proposal*
> I will make the new plugin installer leave the previous version of the
> tools behind.

can you make it an option? default leave behind, with the possibility to
select a "clean up" option that would search the whole drive for
"legacy" versions and ask the user if he wants to delete them?


> Ensure if panotools is uninstaller the plugins remain. Or can be easily
> reinstalled.

again, why not making each item of the installer an option, with a
sensible default choice? then the default deinstall should be
*everything* that has been installed IMO.


> What I then can do is recommend the installation of Hugin to get the new
> PanoTools helpers.

Why not leave the helpers and make them one of the options?


> The other option is to make panotools a merge module that other
> installers will include. This will mean that the tools will get
> installed into the same folder every time.

Looks like a sensible option to me.

The current hugin installer works well for testing, but for the release
I'd like to see a more modular solution, with options to install only
parts. Some people might be interested in Enblend only, it is their
right. They should not have to install the whole thing.

Another option I would like to see there is what is being placed on my
desktop. The current hugin installer placed an hugin icon on my desktop
without permission. It is already bad enough that the typical windows
installer defaults to a start menu folder, an icon on the desktop and
often even a quick launch icon. And I have to custom-install every time,
only to deselect the clutter.

I propose a menu entry only, with optional desktop icon.


> It will probably mean that the previous
> installation of panotools & Hugin must be uninstalled before installing
> new version that includes merge modal.

is it possible for the installer to search for such "legacy"
installations and suggesting to the user they be uninstalled? or asking
the user for permission and doing the uninstall?


> If I have some time in a couple days I will look at the Hugin installer
> and make some tweaks to fix the items Yuval mentioned and a couple
> others if no one does it first.

Thanks, Jim! I only have experience with InnoSetup and I don't recall
what tool has been used for this installer?

Yuv


Jim Watters

unread,
Jan 1, 2008, 6:04:40 PM1/1/08
to hugi...@googlegroups.com
Bruno Postle wrote:
> On Tue 01-Jan-2008 at 15:42 -0500, Jim Watters wrote:
>
>> Why was a bunch of files duplicated for the gimp-plugin and
>> gimp-plugin-ng? Why can they not just statically link to pano13 like
>> the rest of the tools? Has anyone ever built and released these?
>>
>
> 'gimp-plugin' is Helmut's original sources patched-up to work with
> more recent versions of the gimp. This includes most of the files
> from an older version of pano12, I don't know why, it does mean that
> it doesn't require pano12. The PanoTools.exe binary on the
> sourceforge download area is this code.
>
Then maybe gimp-plugin should only be with the panotools12 branch.

> This is obviously a bit of a mess, so 'gimp-plugin-ng' was forked to
> clean up the sources, remove all this cruft, add help, and link
> against pano12. This job was never finished.
>
and the gimp-plugin-ng only be with the trunk.

> Anyone working on the gimp plugin should use the 'gimp-plugin-ng'
> code as this is in a much better state.
>
> I don't think there has ever been a tarball release of either
> branch, though they both compiled on Linux last time I checked.
>
A look at the SVN log history will verify that no unique changes have
been added to the trunk release of the gimp-plugin folder.

Bruno Postle

unread,
Jan 1, 2008, 6:18:07 PM1/1/08
to Hugin ptx
On Tue 01-Jan-2008 at 18:04 -0500, Jim Watters wrote:
>
>Then maybe gimp-plugin should only be with the panotools12 branch.

>and the gimp-plugin-ng only be with the trunk.

Yes this makes sense.

--
Bruno

Pablo dAngelo

unread,
Jan 2, 2008, 5:09:22 AM1/2/08
to hugi...@googlegroups.com
Hi Yuv and Jim.

> Jim Watters wrote:
> > Are you sure the previous version on your system was not just an
> > unpacking of a zip file. I thought the same thing at first.
>
> pretty sure. I keep the unzipped version of hugin, panotools etc. in a
> folder C:\prg_files to make sure that no space in the path name is the
> cause of errors.
>
> I run John Navas' installer first when he published it, and this is
> where the old files came from.

Hmm, I had hoped that the .msi installer would remove the other
version before installing anything.

> The current hugin installer works well for testing, but for the release
> I'd like to see a more modular solution, with options to install only
> parts. Some people might be interested in Enblend only, it is their
> right. They should not have to install the whole thing.

Then they should download enblend separately.

I don't like depending on external packages, simpley because they
can change in incompatible ways, or people think, great, I have
already enblend 3.0, but hugin requires enblend 3.1 etc. Writing an
installer that reliably takes care of all that is a probably close to
impossible (with a resonable amount of time).

> > It will probably mean that the previous
> > installation of panotools & Hugin must be uninstalled before installing
> > new version that includes merge modal.
>
> is it possible for the installer to search for such "legacy"
> installations and suggesting to the user they be uninstalled? or asking
> the user for permission and doing the uninstall?

Hmm, given the many ways people could install hugin and panotools
in the past, I fear this is a hopeless quest. Note that the hugin
windows installer does not install anything (except start menu entry)
into the system folder, so it is pretty self contained.

> > If I have some time in a couple days I will look at the Hugin installer
> > and make some tweaks to fix the items Yuval mentioned and a couple
> > others if no one does it first.
>
> Thanks, Jim! I only have experience with InnoSetup and I don't recall
> what tool has been used for this installer?

Warsetup and WiX. I have streamlined the process, as can be seen on the build instructions
on the wiki. No manual file copying etc. is required.

Actually, CMake includes a build in support for NSIS, so NSIS installers can be build with a single click,
from within MSVC, too. But in order to be useful, it probably needs some customisation.

ciao
Pablo
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

Pablo dAngelo

unread,
Jan 2, 2008, 5:18:19 AM1/2/08
to hugi...@googlegroups.com
Hi Jim,

> This is a better question for the panotools dev list but ....

> Why was a bunch of files duplicated for the gimp-plugin and
> gimp-plugin-ng? Why can they not just statically link to pano13 like
> the rest of the tools? Has anyone ever built and released these?
>

> If I have some time in a couple days I will look at the Hugin installer
> and make some tweaks to fix the items Yuval mentioned and a couple
> others if no one does it first.

Sure, please go ahead. I'm not an expert with Windows installer, nor do I
have the time, to become one, so any help is greatly appreciated. For example,
I don't know why the hugin logo isn't displayed in the installer I created.

If you want to modify the installer without building hugin, just place the files installed
by the msi installer in a FILES directory in the platforms/windows/msi folder:

msi/FILES/bin/hugin.exe (etc...)

Then it should be possible to run warsetup on the hugin.warsetup file to
create the installer.

ciao
Pablo

______________________________________________________________________________
Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit
Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134

Seb Perez-D

unread,
Jan 4, 2008, 3:11:56 AM1/4/08
to hugin and other free panoramic software
On Jan 1, 2008 7:18 PM, Pablo d'Angelo <pablo....@web.de> wrote:
> The snapshot itself is available at:
> http://hugin.panotools.org/testing/hugin/hugin_0.7.0.2587_win32.msi

The installer requires admin privileges, even though I am installing
in a personal folder ? this is very constraining and I'm not sure this
is needed, since Pablo mentioned that the installer writes nothing to
the system folder - except the menu entry. Maybe we need a checkbox
that asks "Install for all users, or for current user only?"

Cheers,

Seb

Yuval Levy

unread,
Jan 4, 2008, 8:05:20 AM1/4/08
to hugi...@googlegroups.com
Seb Perez-D wrote:
> Maybe we need a checkbox
> that asks "Install for all users, or for current user only?"

the whole installer is to be redone. we need the above. we need the
option to put or not icons. we need the option to select/deselect
individual components, like the installers for other suites of tools.

i am willing to look into that. i have experience with InnoSetup, but
this is WarSetup and Pablo mentioned that MSIS can be supported directly
from CMake.

Pablo: can you make a decision about which of the three you want to use?
then I will look into that. If it is MSIS, I'll need a bit of help to
understand where and how CMake is involved.

Also: is it possible from CMake to call ImageMagick and add an overlay
of the revision compiled on the splash screen graphic? I can script the
ImageMagick if I know the location of the version text and of the splash
graphic. But I don't know to script CMake (yet).

Yuv

Pablo dAngelo

unread,
Jan 4, 2008, 8:46:20 AM1/4/08
to hugi...@googlegroups.com
Hi Yuv,

> Seb Perez-D wrote:
> > Maybe we need a checkbox
> > that asks "Install for all users, or for current user only?"
>
> the whole installer is to be redone. we need the above. we need the
> option to put or not icons. we need the option to select/deselect
> individual components, like the installers for other suites of tools.

Please do NOT make it possible for the user to install a broken hugin by
making vital components such as panotools or enblend optional. Even
if they have their own, probably incompatible version installed
elsewhere on their system.

> i am willing to look into that. i have experience with InnoSetup, but
> this is WarSetup and Pablo mentioned that MSIS can be supported directly
> from CMake.
>
> Pablo: can you make a decision about which of the three you want to use?
> then I will look into that. If it is MSIS, I'll need a bit of help to
> understand where and how CMake is involved.

NSIS: http://nsis.sourceforge.net/Main_Page based on scripts.

warsetup + wix: Based on windows installer (msi), seems to be more
complex to handle, but probably has better integration with windows
if done right. For example, I had hoped that the installer would
automatically uninstall other hugin versions, but I guess more work
is needed on that.

I don't really care about the installer technology, but it should be reliable,
easy to use for the developers too (when new files are added etc.)
and it is an advantage, if the tools used are open source.

> Also: is it possible from CMake to call ImageMagick and add an overlay
> of the revision compiled on the splash screen graphic? I can script the
> ImageMagick if I know the location of the version text and of the splash
> graphic. But I don't know to script CMake (yet).

first, please subscribe to the SVN change log mailing list at:
http://sourceforge.net/mail/?group_id=77506, and maybe the tracker list, if you like
to keep an overview of changes to the bug reports.

I already added code to hugin to embed the version number during runtime,
this is much easier (and works on all platforms) than imagemagick scripting.

ciao
Pablo
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

J. Schneider

unread,
Jan 5, 2008, 7:32:43 AM1/5/08
to hugi...@googlegroups.com
Pablo dAngelo schrieb:
> ...For example, I had hoped that the installer would

> automatically uninstall other hugin versions, but I guess more work
> is needed on that.

I'm not sure if this is a good thing when installing a new snapshot. Of
course I want to test it, but maybe it doesn't work correctly and I want
to keep a working hugin installation on my computer. I also want to be
able to compare between versions.

If it is possible to integrate this kind of interaction into an
installer it could be helpful if the installer detected existing
installations or their fragments and told users about the result,
possibly informing about conflicts, and gave them the choice to
uninstall. Of course this is a good deal more complex. As long as this
is not possible to implement, I would like to have automatic
uninstallation only in thoroughly tested releases. (Wouldn't these be
updates then, not uninstall and new install? Preferences should be kept
if they are still applicable and have been changed by the user)

regards
Joachim

Yuval Levy

unread,
Jan 5, 2008, 8:24:42 AM1/5/08
to hugi...@googlegroups.com
J. Schneider wrote:
> Pablo dAngelo schrieb:
>> ...For example, I had hoped that the installer would
>> automatically uninstall other hugin versions, but I guess more work
>> is needed on that.
>
> I'm not sure if this is a good thing when installing a new snapshot.

You are right and we should set a different default location for the
snapshot to install to, and a different name too. A new snapshot
overrides an old snapshot but does not touch the working install.

Yuv

J. Schneider

unread,
Jan 5, 2008, 8:34:26 AM1/5/08
to hugi...@googlegroups.com
Yuval Levy schrieb:

This would be a possibility. But if a snapshot proves usable I continue
to use it (as releases are seldom and I want to use new functionality).
Then it should not be replaced by a possibly not working installation.

regards
Joachim

Yuval Levy

unread,
Jan 5, 2008, 8:41:10 AM1/5/08
to hugi...@googlegroups.com
J. Schneider wrote:
> if a snapshot proves usable I continue
> to use it (as releases are seldom and I want to use new functionality).
> Then it should not be replaced by a possibly not working installation.

Sorry, at this point you are on your own. The reason to provide
snapshots is to get testing feedback, not to give early access to new
functionality that will eventually will be released.

Of course I understand your impatience if the release takes too long to
come.

Yuv

Yuval Levy

unread,
Jan 5, 2008, 9:08:23 AM1/5/08
to hugi...@googlegroups.com
Hi Pablo,

Pablo dAngelo wrote:
> Please do NOT make it possible for the user to install a broken hugin by
> making vital components such as panotools or enblend optional. Even
> if they have their own, probably incompatible version installed
> elsewhere on their system.

I want to make hugin optional, so that those who download the package
can install enfuse only if they wish to do so.


> NSIS: http://nsis.sourceforge.net/Main_Page based on scripts.

> I don't really care about the installer technology, but it should be reliable,
> easy to use for the developers too (when new files are added etc.)
> and it is an advantage, if the tools used are open source.

I am used to InnoSetup but I like what I read in the NSIS documentation.
Sicne you said that CMake can create / manipulate NSIS scripts, I
suggest we give it a try?

I need to get my build process from source in Windows ready (and I am
ready to use either Visual C++ 2005 Express Edition or MinGW, but not a
tool chain for which I must pay a license fee) before looking into this,
but I am confident I could script an NSIS installer to specifications.


> first, please subscribe to the SVN change log mailing list at:
> http://sourceforge.net/mail/?group_id=77506, and maybe the tracker list, if you like
> to keep an overview of changes to the bug reports.

DONE.


> I already added code to hugin to embed the version number during runtime,
> this is much easier (and works on all platforms) than imagemagick scripting.

so it will appear on top of the splash image? cool!

Yuv

Pablo d'Angelo

unread,
Jan 5, 2008, 1:10:09 PM1/5/08
to hugi...@googlegroups.com
Hi Yuv,

Yuval Levy wrote:
> Hi Pablo,


>
>> I don't really care about the installer technology, but it should be reliable,
>> easy to use for the developers too (when new files are added etc.)
>> and it is an advantage, if the tools used are open source.
>
> I am used to InnoSetup but I like what I read in the NSIS documentation.
> Sicne you said that CMake can create / manipulate NSIS scripts, I
> suggest we give it a try?

Actually, it will automatically create the installer ;-)

> I need to get my build process from source in Windows ready (and I am
> ready to use either Visual C++ 2005 Express Edition or MinGW, but not a
> tool chain for which I must pay a license fee) before looking into this,
> but I am confident I could script an NSIS installer to specifications.

Ok, here are some infos on the NSIS installer integration within CMake:

There is some information how to modify the default installer:
http://www.cmake.org/Wiki/CMake:CPackConfiguration

The default installer is the rather complicated script located at:
/usr/share/cmake-2.4/Modules/NSIS.template.in (on your linux box ;-)

You can probably add stuff to it, to customize it and place it in the
CMakeModules folder in the hugin source.

Unfortunately there is little other documentation about it, except some
posts on the email lists. I fear that is might be quite hard to add the
selection of sub-packages to the default script though.

http://www.mail-archive.com/cm...@cmake.org/msg04720.html
http://www.cmake.org/pipermail/cmake/2006-October/011490.html

Since Jim wanted to work a bit on the installers too (or was it only the
panotools installer?), we should ask him as well, he might have some
additional knowledge about installers on windows.

>> I already added code to hugin to embed the version number during runtime,
>> this is much easier (and works on all platforms) than imagemagick scripting.
>
> so it will appear on top of the splash image? cool!

Yes.

ciao
Pablo

Jim Watters

unread,
Jan 5, 2008, 5:08:45 PM1/5/08
to hugi...@googlegroups.com
Pablo d'Angelo wrote:
>
> Ok, here are some infos on the NSIS installer integration within CMake:
>
> There is some information how to modify the default installer:
> http://www.cmake.org/Wiki/CMake:CPackConfiguration
>
> The default installer is the rather complicated script located at:
> /usr/share/cmake-2.4/Modules/NSIS.template.in (on your linux box ;-)
>
> You can probably add stuff to it, to customize it and place it in the
> CMakeModules folder in the hugin source.
>
> Unfortunately there is little other documentation about it, except some
> posts on the email lists. I fear that is might be quite hard to add the
> selection of sub-packages to the default script though.
>
> http://www.mail-archive.com/cm...@cmake.org/msg04720.html
> http://www.cmake.org/pipermail/cmake/2006-October/011490.html
>
> Since Jim wanted to work a bit on the installers too (or was it only the
> panotools installer?), we should ask him as well, he might have some
> additional knowledge about installers on windows.
>
What I said was I would work on it if no one else does. I do know a few
things about making msi but have yet used NSIS and CMake so I don't mind
if anyone else picks this up. I have also found some more things to fix
with panotools and the plugins.

What I was hoping to make sure both installers are similar.

Reply all
Reply to author
Forward
0 new messages