[hugin-ptx] Windows 64-bit Build

[Tom Glastonbury]

Whilst I used Hugin a few years ago, I've recently returned to it. I'm
running Windows 7 64-bit on a fairly beefy machine (quad core, 8gig
ram), but found that it was impossibly slow and crash-prone when
working with large (eg, 300-400 MB) image files (I'm stitching
together tiles from a flatbed scanner). It was also tricky to find
recent 64-bit builds. A brief communication with Pablo confirmed that
Windows releases are somewhat orphaned at present.

So I now have a working 64-bit build based on svn rev 5145 which is
usable with large image files. I followed the instructions at the wiki
[1], with a few changes:

1. Because I have VC 2010 Express on my system in addition to 2008 I
had to tell boost to specifically use the right compiler version
replacing:

toolset=msvc

with:

toolset=msvc-9.0.

2. More recent revs have a dependency on GLUT which is not mentioned
in the SDK docs. Looking at the GLUT library suggested by the author
who introduced the dependency, it did not look like it would compile
for a Win x64 target easily, and is not true open source, so I used
freeglut instead. I had to modify CMakeModules\FindGLUT.cmake as it
would always raise an error if GLUT was not found, even though the
make CMakeLists.txt file provided a fall-through mechanism which would
then look for freeglut.

3. The main problem I was having with Hugin was that it would take
forever to add images, and sometimes just crash. Having run up and
debugged the build, I discovered that the version of exiv suggested in
the SDK doc (0.18.1) did not support memory mapped access to image
files under WIndows, and would therefore always load the whole file
into memory just to extract exif info.This did not work well with
multiple 400MB files. Luckily 0.19 does support memory mapping under
windows, and this makes reading exif info from large files under
windows almost instantaneous. I have modified CMakeLists.txt to
support this new version. Note that 0.19 appears to split out the XMP
SDK into a different lib, so I had to fix the library dependencies to
handle this too.

--

I'm sure this would be of use to others, so I'd like to make it
available. What should I do?

Thanks,

Tom

[1]
http://wiki.panotools.org/Hugin_SDK_(MSVC_2008)

--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[dex Otaku]

On May 12, 10:35 am, Tom Glastonbury <t...@tomglastonbury.com> wrote:
> I'm sure this would be of use to others, so I'd like to make it
> available. What should I do?

Hi Tom,

I can't advise anything in terms of putting the files up for download,
but I'd like to test your build if you don't mind. I'm also using
Hugin on Win7/64, not with large images as you are, but to build full
equirectangular panos using 37 or 38 5-10Mp images.

Please drop me a line if you don't mind sharing.

Thanks,
DBFG

[Nicolas Pelletier]

I second that. Enblend and Enfuse in my case (and sometime nona) are IO bound, not CPU bound since my images are typically 800 megs in size. (I have 64 bit quad with 8gig ram)

I could help test this build if you would like!

Drop me a line or send me a link!

nick

[dsp]

I'd test it as well. I have been running a 64 bit version of 3.2 that
I built following ref [1], and it works well, but was not successful
in getting the new release to work the few times I tried to build it.
If you just need a server to throw up your files, let me know, I can
probably dig one up...
cheers, Darcy

[Tom Glastonbury]

A number of people have asked to try out this build, so here it is:

http://tg73.net/2010/05/hugin-windows-x64-64-bit-build/

I'd like to hear from any active developers/admins at the Sourceforge
project about the possibility of getting the changes mentioned in my
original post checked in, and updating the SDK instructions on the
wiki.

Thanks,

Tom

[Harry van der Wolf]

2010/5/14 Tom Glastonbury <t...@tomglastonbury.com>

A number of people have asked to try out this build, so here it is:

http://tg73.net/2010/05/hugin-windows-x64-64-bit-build/

I'd like to hear from any active developers/admins at the Sourceforge
project about the possibility of getting the changes mentioned in my
original post checked in, and updating the SDK instructions on the
wiki.

Thanks,

Tom

Thanks Tom,

Thomas Modes already applied your exiv and cmake (freeglut) patches to the trunk (svn 5152: Improved finding in cmake for Freeglut 2.6.0 and Exiv 0.19 under Windows).

best,
Harry

[Nicolas Pelletier]

Got the version, will test it through the weekend!

Thanks!

BTW, I brought panomatic to 64 bit. if you want the code and\or the exe, don't hesitate. For my it enabled using the 4 cores on large images.

nick

[Tom Glastonbury]

I've just tried 5154, and get the following when running cmake:

CMake Error at CMakeModules/FindGLUT.cmake:87 (MESSAGE):

Could not find GLUT

Call Stack (most recent call first):

CMakeLists.txt:184 (FIND_PACKAGE)

By default, the x64 builds of freeglut end up at:

\freeglut-2.6.0\VisualStudio2008Static\x64\Release

whereas FindGLUT.cmake looks in

\freeglut-2.6.0\VisualStudio2008Static\Release

Adding the following after line 22 in FindGLUT.cmake sorts it out:
    ${SOURCE_BASE_DIR}/freeglut-2.6.0/VisualStudio2008/x64/Release
    ${SOURCE_BASE_DIR}/freeglut-2.6.0/VisualStudio2008Static/x64/Release

Note that I coincidentally had the 32-bit Debug config of freeglut built too, which lives at \freeglut-2.6.0\VisualStudio2008Static\Debug. Had I also prepared the 32-bit release version, it would have found that in preference to the 64-bit version which would be unfortunate. What's not entirely clear to me is if and how the cmake/build process handles the availability of 32-bit and 64-bit libraries. Clearly it handles debug and non-debug versions so that you can build debug and release targets from the same cmake configured build directory. Is the implication that (at present) I need to have two entire copies of the sdk and source if I want to build 32-bit and 64-bit versions?

Anyhow, with that minor tweak 5154 builds fine, and can be found here:

http://tg73.net/

Thanks,

Tom

On 14/05/2010 12:41 PM, Harry van der Wolf wrote:

Thanks Tom,

Thomas Modes already applied your exiv and cmake (freeglut) patches to the trunk (svn 5152: Improved finding in cmake for Freeglut 2.6.0 and Exiv 0.19 under Windows).

best,
Harry

[T. Modes]

Hi Tom,

checked in you latest modification (rev 5158).

> Adding the following after line 22 in FindGLUT.cmake sorts it out:
> ${SOURCE_BASE_DIR}/freeglut-2.6.0/VisualStudio2008/x64/Release
> ${SOURCE_BASE_DIR}/freeglut-2.6.0/VisualStudio2008Static/x64/Release
>

The best place to provide patches is hugins patch tracker
(http://sourceforge.net/tracker/?group_id=77506&atid=550443) There you
can also attach a diff file, which contains all of your changes

Thomas

[dex Otaku]

On May 14, 6:25 am, Tom Glastonbury <t...@tomglastonbury.com> wrote:
> A number of people have asked to try out this build, so here it is:

Thanks, Tom. Trying it out here [on an Athlon II x4 w/4GB & Windows 7
x64] and everything appears to be good so far.

[Yuv]

On May 14, 7:25 am, Tom Glastonbury <t...@tomglastonbury.com> wrote:
> I'd like to hear from any active developers/admins at the Sourceforge
> project about the possibility of getting the changes mentioned in my
> original post checked in, and updating the SDK instructions on the
> wiki.

Hi Tom,

I'm sorry nobody got back to you yet - we're all in our spare time
here, so replies tend to take some time.

Thank you for your contribution. Yes, the windows build (and
specifically the 64bit one) could use some love and attention and your
time and effort are appreciated.

Thomas Modes has committed some of your changes to the codebase. If
you post your Sourceforge user name here, I'll add you to the
project's contributors so that you can make your changes directly.
We're currently transitioning from a Subversion-based repository to a
Mercurial-based one - you'll be pushing your changes to Mercurial.

For the SDK, there have been on and off discussions with previous
win32 and win64 contributors to maintain and update a set of scripts
to build it. We even opened an Hg repository for this, but... well...
look at it yourself: http://hugin.hg.sourceforge.net/hgweb/hugin/windowsSDK/

Ideally there should be there a batch script to download the necessary
source or binary files to the right location and put together the SDK.
Bits and pieces are spread in the past three years of archives of this
mailing list. Pieces are in the Hugin main repo. Pieces are in the
Wiki and its history. And pieces are missing.

For the Wiki, account opening is self-service and you're welcome to
edit what you deem necessary. It has a natural tendency to become
obsolete as documentation does not always have the high priority it
deserves and contributor's time is limited.

Again, thank you for your effort, and welcome to the team if you want
to join the active team of builders / developers.

Yuv

[Tom Glastonbury]

Hi Yuv,

Thanks for that - my Sourceforge user id is "glastonbury". I noticed the
chatter re Hg, and I'm set up ready to pull a copy of the repo when it's
ready. Like you other developers, I too have limited time (most of mine
is happily sucked up by a 2.5yr old son :-) ), but I'll do what I can to
get it going.

I note that there are no official Win32 (let alone x64) builds for 0.8.0
and 2010.0. Is there a reason for this other than lack of someone to
produce them? Would it make sense for me to (attempt to) produce them?

I was interested to read that the idea worked on in the past for the Win
SDK is based around a script that downloads 3rd party source/binaries as
needed. I'll see what I can find in the Wiki, but notably I'd be
interested to know which scripting system was being suggested - perhaps
NSIS is a good choice?

The other issue that I've mentioned before is that of producing x64 and
Win32 builds from one source tree/SDK. It seems to me that the hugin
CMake stuff will differentiate between debug and release libs (at least
for some 3rd party dependencies), but not for 32 vs 64 bit - it
generally seems to look for and generate link info for "somelib.lib" and
"somelibd.lib", but not "somelib32.lib", "somelib32d.lib",
"somelib64.lib" and "somelib64d.lib". Ideally, I'd like to be able to
freely choose between any combo of x64/Win32 and Debug/Release within
Visual Studio, and have the build process work. Is there a CMake master
in the project who might be able to comment on this?

Thanks,

Tom

[Ryan Sleevi]

Hey Tom,

I'm commenting out of order here, but hopefully it makes sense this
way :)

>
> The other issue that I've mentioned before is that of producing x64 and
> Win32 builds from one source tree/SDK. It seems to me that the hugin
> CMake stuff will differentiate between debug and release libs (at least
> for some 3rd party dependencies), but not for 32 vs 64 bit - it
> generally seems to look for and generate link info for "somelib.lib"
> and
> "somelibd.lib", but not "somelib32.lib", "somelib32d.lib",
> "somelib64.lib" and "somelib64d.lib". Ideally, I'd like to be able to
> freely choose between any combo of x64/Win32 and Debug/Release within
> Visual Studio, and have the build process work. Is there a CMake master
> in the project who might be able to comment on this?

As far as I know, I was the first to really pursue the x64 builds.
What you're describing re: CMake is arguably a limitation both of CMake
itself (and more aptly, it's Visual Studio project generation ability) and a
limitation of the CMake recipes (for lack of a better word). The distinction
between Debug and Release is something that CMake (tool) itself supports via
a language-specific + compiler-specific extension that allows creators of
CMake files (FindGLUT, for example) to specify what the filenames will be.
No such directives exist for platform-specific definitions (that would allow
one to create a .sln that supports Win32 and x64 development). So, at a
minimum, we're talking two .sln files (or nmake, if you prefer) generated
from a single CMake, with a generic variable tracking target platform (which
CMake already sets for you, mind you).

However, once there, it becomes a bit tricker. This is because some
of the (third-party) libraries use MSVC extensions (namely, #pragma
comment(lib, "libname")) to specify what the library name will be, which is
based on arguments you pass to their (non-CMake) build scripts. I recall it
being Boost and STLplus that did this, but it may be more. So you'll still
need to be specifying separate build arguments to these tools, and hoping
to get them to dump their compiled output into separate directories with a
sane naming scheme, which ends up with multiple copies of the include files
as well (since they "deploy" the library once compiled).

At one point, right before enblend-enfuse-4.0 was released, I did
have a system and a set of batch and CMake files that could compile the
entire set of libraries through, but unfortunately I lost those with a drive
crash. It involved touching every Find*.cmake and changing the
paths/libnames it would check based on whether the target platform was Win32
or x64 - which further involved copying/modifying some of the .cmake files
that come with the standard CMake distribution, and copying them into the
local repository so they'd be picked up first. I say that to clarify that
it's definitely do-able, it just requires a lot of CMake hacking, and even
what I had, was so messy that I didn't feel confident committing upstream.

I haven't followed up with CMake development, but they may now
support multi-platform targeting within a single solution, they just didn't
when I last worked on it. Hope that helps.

> I was interested to read that the idea worked on in the past for the
> Win
> SDK is based around a script that downloads 3rd party source/binaries
> as
> needed. I'll see what I can find in the Wiki, but notably I'd be
> interested to know which scripting system was being suggested - perhaps
> NSIS is a good choice?

NSIS is more of an installer system than a build system. The build
system needs to be scriptable, capable of applying patches, and executing
the various custom build scripts (bjam, for example, for Boost compilation).
I've got a lot of experience with NSIS, and feel confident saying "This is
not the tool you're looking for". My original solution was simply a batch
script, but depending on what the lowest common denominator is, you may feel
more comfortable with either a Windows Script Host script (VBScript,
JScript), a PowerShell script, or even a third-party language like
Perl/Python via ActivePerl/ActivePython (though introducing that dependency
just for a build-helper script seems overkill)

Just let me know if you have any further questions and I'll do what
I can to help.

[Yuv]

Hi Tom,

On May 16, 5:40 pm, Tom Glastonbury <t...@tomglastonbury.com> wrote:
> my Sourceforge user id is "glastonbury".

welcome on board! you now have write privilege to the Hg repo.

> I too have limited time (most of mine
> is happily sucked up by a 2.5yr old son :-) ), but I'll do what I can to
> get it going.

you're 0.75yr ahead of me :-) and since my son will go to full time
school in September, this summer is his summer with me.

> I note that there are no official Win32 (let alone x64) builds for 0.8.0
> and 2010.0. Is there a reason for this other than lack of someone to
> produce them? Would it make sense for me to (attempt to) produce them?

2010.0 makes sense. 0.8.0 I don't think. At some point in history
there were some really badly broken dependencies that had serious
consequences on Windows releases but not on Linux (where they are
distributed separately). IIRC it was Autopano-SIFT-C before the
release of 2.5.1; and buggy Enblend-Enfuse binaries for a long time.
And lack of time / volunteers to test the whole combination to be of
equal or better quality than 0.7.0 which had a lot of intensive
testing and polishing.

The main difference between Windows-Hugin and Linux-Hugin from a user
perspective is that in Windows the Hugin installer also delivers
Enblend-Enfuse and Autopano-SIFT-C because of the lack of package
manager on that platform. In Linux, the Hugin package only delivers
Hugin and describes its dependencies, making updates and maintenance
easier.

> I was interested to read that the idea worked on in the past for the Win
> SDK is based around a script that downloads 3rd party source/binaries as
> needed. I'll see what I can find in the Wiki, but notably I'd be
> interested to know which scripting system was being suggested - perhaps
> NSIS is a good choice?

AFAIK NSIS is an installer script. Hugin currently uses InnoSetup for
the installer. IIRC there is some NSIS cruft from an old (pre 0.7.0)
installer. Back then I tried to understand NSIS and found it easier
to implement InnoSetup (of which I had previous experience) from
scratch. Since then I moved to Linux almost completely. IIRC Ad
Huikeshoven contributed a whole script to build Hugin and the
installer inside the SDK and I think it was simple batch scripting.

> The other issue that I've mentioned before is that of producing x64 and
> Win32 builds from one source tree/SDK.

If you find it easier to have two separate SDKs, one for x64 and one
for Win32, go ahead. In the documentation on the Wiki Guido worked
mainly on Win32 and Ryan contributed x64 patches and changes. On
Sourceforge we can have unlimited Hg repos, so having one for each Win
architecture would not be a problem. When I was still on Windows and
maintaining my own SDK I had written some notes for each of the
packages / subfolders that together made the SDK. I shall try to find
copies of them on my old HDDs.

I envisioned a mix between two extremes: the "stable" SDK and the
"bleeding edge" SDK, with two different purposes. The stable SDK
would contain stable versions of the dependencies for the generation
of binaries for productive use by the general public. The bleeding
edge SDK would contain the latest versions of the dependenciesfor
testing purposes so that we can give early warning / feedback to
upstream dependencies in case of bugs there; and we can be alert to
changes upstream that affect Hugin.

IIRC there are about two dozens packages in the SDK. Not all of them
are so dynamic. Ideally there would be a script that fetches them
from the web (with wget or something similar); applies patches if
applicable; triggers the building process for fetched source packages
and re-create the whole SDK from scratch. A less ambitious idea was
to create an up to date SDK, make it available for download, and then,
as upstream packages update, put up drop-in updates for individual
components.

Since moving to Ubuntu (and then to Kubuntu late last year) there is
no way back for me. I was lured by Microsoft's 40$ student licenses
for Windows 7 last autumn but have not been able to make sense of it
for me. I occasionally boot my aging Win XP partition for video
editing (was not able to replace SONY Vegas so far, nor to use it with
WIne on Linux).

[Yuv]

Hey Ryan,

On May 16, 6:19 pm, "Ryan Sleevi" <ryan+hu...@sleevi.com> wrote:
>         At one point, right before enblend-enfuse-4.0 was released, I did
> have a system and a set of batch and CMake files that could compile the
> entire set of libraries through, but unfortunately I lost those with a drive
> crash.

...

> what I had, was so messy that I didn't feel confident committing upstream.

ouch! next time, don't be shy to commit unfinished work. Just label
it as such and somebody might pick it up from there.

Yuv

[Tom Glastonbury]

Hi Ryan,

Thanks for all that info - I'll digest it and do some research. One
comment re NSIS - I certainly wasn't thinking of using it for building,
but more in response to Yuv's note about downloading dependent
source/binary packages. Windows doesn't come with wget as standard, and
I'm not clued-up on some of the more enterprise-oriented scripting stuff
that later versions of Windows support, so I was thinking that NSIS
would be a useful tool for managing these downloads and for generally
bootstrapping the installation (but not the build) of the SDK without
requiring the user to download and install several utilities by hand in
advance.

Another note: As it stands, there are a few patches required to 3rd
party libs that go beyond .sln file mods, and actually touch source
code. From what various people have said, and the convention in use for
the do-it-yourself SDK, I understand that the desired option is to
download the unmodified source code of a specific version from a given
library's main repository, then apply hugin-specific patches if needed.
Is there general agreement with this (or at least lack of disagreement)?

Tom

[Ryan Sleevi]

> -----Original Message-----
> From: hugi...@googlegroups.com [mailto:hugi...@googlegroups.com] On
> Behalf Of Tom Glastonbury
> Sent: Monday, May 17, 2010 6:26 AM
> To: hugi...@googlegroups.com
> Subject: Re: [hugin-ptx] Re: Windows 64-bit Build
>
> Hi Ryan,
>
> Thanks for all that info - I'll digest it and do some research. One
> comment re NSIS - I certainly wasn't thinking of using it for building,
> but more in response to Yuv's note about downloading dependent
> source/binary packages. Windows doesn't come with wget as standard, and
> I'm not clued-up on some of the more enterprise-oriented scripting
> stuff
> that later versions of Windows support, so I was thinking that NSIS
> would be a useful tool for managing these downloads and for generally
> bootstrapping the installation (but not the build) of the SDK without
> requiring the user to download and install several utilities by hand in
> advance.
>

Have you worked with NSIS before? It's more akin to assembly language than
it is a generic scripting. Registers and stacks make up the core language,
and it's frustratingly limited. The support for downloading files is
rudimentary, and the selection of compression algorithms is limited (which
would affect the source downloads). My comments about Python/Perl earlier
were meant to demonstrate that it's arguably perfectly reasonable to have
some minimal set of dependencies (perhaps even distributed with the file):
ex, you need wget and python, and here's the executables, as well as the
python script that does the work. Or batch, or what have you.

As it relates to the SDK, there isn't much dependency management that needs
resolution: If you're going 32-bit, you need packages X, Y, and Z, and if
you're wanting to compile 64-bit, you equally need packages X, Y, and Z. The
only variation is if you're also wanting to compile enblend/enfuse, as then
you'll also need packages A, B, and Z. There is question, at this point,
whether that rightfully composes the Hugin SDK or not (really, it's just
useful because of the overlap)

I don't want to discourage you from pursuing something you're comfortable
in, I'd just suggest that NSIS wouldn't be the right tool for the job, which
is something Yuv also echoed. Can it be made to do what you want? Possibly -
but my own experiences with NSIS tell me it'll be a bit messy.

>
> Another note: As it stands, there are a few patches required to 3rd
> party libs that go beyond .sln file mods, and actually touch source
> code. From what various people have said, and the convention in use for
> the do-it-yourself SDK, I understand that the desired option is to
> download the unmodified source code of a specific version from a given
> library's main repository, then apply hugin-specific patches if needed.
> Is there general agreement with this (or at least lack of
> disagreement)?

That's the best strategy, IMO, as it allows for flexibility to change/update
the library in the future, and hopefully eliminate the patches once they
become unnecessary (most are minor, I think the closest anything gets to
'major' is just patching the wxWidgets config for third-party libraries)

[T. Modes]

Hi Tom and Ryan

>> Another note: As it stands, there are a few patches required to 3rd
>> party libs that go beyond .sln file mods, and actually touch source
>> code. From what various people have said, and the convention in use for
>> the do-it-yourself SDK, I understand that the desired option is to
>> download the unmodified source code of a specific version from a given
>> library's main repository, then apply hugin-specific patches if needed.
>> Is there general agreement with this (or at least lack of
>> disagreement)?
>>
> That's the best strategy, IMO, as it allows for flexibility to change/update
> the library in the future, and hopefully eliminate the patches once they
> become unnecessary (most are minor, I think the closest anything gets to
> 'major' is just patching the wxWidgets config for third-party libraries)
>

I also think, that is the most flexible solution for the moment. So
everybody which wish can then easily build "its" SDK.
Currently there are only very few people which build hugin on windows.
When there is a compiled version for windows available this number will
further drop.

Thomas

[dex Otaku]

Hey all,

This may seem like a naïve non-developer question, but how much
utility is gained with Hugin being 64-bit when enblend/enfuse isn't?

The only problems I run into with Hugin currently are caused by
enblend running out of memory when trying to use --fine-mask [because
without it, banding or black lines sometimes occur].

[Tom Glastonbury]

Note that enblend/enfuse version 4.0 is what you'll get from my Windows
64-bit hugin builds. As you rightly say, it's not the 64-bit version -
I'll work on that. As for your question - from reading some comments
elsewhere, it looks like enblend/enfuse use some hand-crafted SSE code,
and will use the 64-bit versions for 64-bit builds (note this is a
somewhat speculative comment). I'd imagine that this could make a
meaningful difference to performance. Anyhow, I'll get the 64-bit
version going shortly then you can compare them side-by-side.

Tom

On 18/05/2010 10:27 AM, dex Otaku wrote:
> Hey all,
>

> This may seem like a naīve non-developer question, but how much

[Nicolas Pelletier]

This explains the out of memory I got when I tried to ramp up enblend to 6 gig of ram.

To answer to Dex, I second that enblend is a bottleneck on my side as it is IO bound here... but I did crash up nona for out of memory when remapping an equirectangular to a very large stereographic output. so this part is not lost.

The few test I did with the 64 bit version do work. I'll run my command line process to test... but It may not be in the near future... life is getting int the way.

Thanks for th x64 version.

nick

[dex Otaku]

On May 18, 6:20 am, Tom Glastonbury <t...@tomglastonbury.com> wrote:
> Note that enblend/enfuse version 4.0 is what you'll get from my Windows
> 64-bit hugin builds. As you rightly say, it's not the 64-bit version -
> I'll work on that. As for your question - from reading some comments
> elsewhere, it looks like enblend/enfuse use some hand-crafted SSE code,
> and will use the 64-bit versions for 64-bit builds (note this is a
> somewhat speculative comment). I'd imagine that this could make a
> meaningful difference to performance. Anyhow, I'll get the 64-bit
> version going shortly then you can compare them side-by-side.
>

I'm not even that worried about potential performance hits between
32/64-bit .. What concerns me more is that rendering even modestly-
sized panos [16k*8k equirectangular] from more than a few images [37
or 38 in my case] with --fine-mask turned on [as mentioned above]
causes enblend to exit with out of memory errors [only after doing
most of the job, frustratingly] apparently regardless of the amount of
actual RAM or swap available.. on Windows, at least.
Some digging through the Mac Hugin fora uncovers the same issue which
can apparently be fixed on that platform by using the openmp
version[s] of enblend. On Windows, this is not the case,
unfortunately [at least, not with the openmp version of enblend 3.2
which exits with the same error].

Your work is very much appreciated, Tom, as is Yuval's.

[Tom Glastonbury]

Hi Dex,

You'll be glad to hear that I'm working on the 64-bit Windows build of
enblend/enfuse. I've sorted out 64-bit builds of most of the
dependencies (and their dependencies), so I'm quite close to the actual
build. The following text from the v4.0 readme might be of interest to
you - I'll endeavour to produce builds with a variety of permutations of
these options.

> ***** ENABLE_IMAGECACHE=ON/off
>
> Activate the Image-Cache feature, which allows for processing of large
> images. The Image Cache handles swapping parts of the images to disk.
> The default is "on", i.e., enable the image cache.
>
> The image cache is recommended on systems where memory is scarce, but
> the images to blend or fuse are large.
>
> The image-cache feature and OpenMP support must not be activated
> together.
>
>
> ***** ENABLE_OPENMP=on/OFF
>
> Parallelize parts of Enblend and Enfuse with OpenMP. See
> http://www.openmp.org/
>
> Note that OpenMP support and the image cache must not be activated
> both. The default is to configure with image cache and without
> OpenMP.
>
> If OpenMP support has been enabled, the utilization of special
> features of the actual, underlying OpenMP implementation can be
> controlled as usual with the environment variables OMP_NUM_THREADS,
> OMP_NESTED and OMP_DYNAMIC. See the OpenMP specification for details
> on the usage of these variables.

Tom

[T. Modes]

Hi Tom,

> I'll endeavour to produce builds with a variety of permutations of
> these options.

Please don't. In an early beta phase of enblend 4.0 we did something
similar with the 32 bit version. This wasn't helpful and created more
confusion than it helped to sort out bugs.

There are only 2 resonable settings:
1.) with image cache and without OpenMP
2.) without image cache and with OpenMP

Maybe for a 64 bit build it can be sufficient to build only the OpenMP
version (the OpenMP version is significant faster, the only drawback
is that is can only use a smaller memory. On 64 bit the version can
utilize more memory, so the need for a version with image cache (with
works also with bigger images) is smaller).

Thomas

[Harry van der Wolf]

Hi Tom,

2010/5/20 T. Modes <Thomas...@gmx.de>

Hi Tom,

>  I'll endeavour to produce builds with a variety of permutations of
> these options.

Please don't. In an early beta phase of enblend 4.0 we did something
similar with the 32 bit version. This wasn't helpful and created more
confusion than it helped to sort out bugs.

There are only 2 resonable settings:
1.) with image cache and without OpenMP
2.) without image cache and with OpenMP

Maybe for a 64 bit build it can be sufficient to build only the OpenMP
version (the OpenMP version is significant faster, the only drawback
is that is can only use a smaller memory. On 64 bit the version can
utilize more memory, so the need for a version with image cache (with
works also with bigger images) is smaller).

Thomas

--

I agree with Thomas. The image cache is not thread-safe. That's the reason why you can't combine image-cache with OpenMP, which uses multiple threads.


Harry

[Erik Krause]

Am 20.05.2010 15:04, schrieb Tom Glastonbury:
> You'll be glad to hear that I'm working on the 64-bit Windows build of
> enblend/enfuse.

Very glad indeed! Could you fix bug 2932316 in your builds? It's very
annoying...

-> http://tinyurl.com/2vkdnfx

--
Erik Krause
http://www.erik-krause.de

[dex Otaku]

Suddenly experiencing totally bizarre behaviour since updating to
Tom's newest build -
For some reason everything within the Hugin interface is now taking
significantly longer to do.

* between basically all actions within the main interface, there are
delays from 10-25 seconds during which (Not Responding) appears in the
title bar; monitoring resources shows that one core is being pegged at
100% for the duration .. it almost appears as though all the images
are being reloaded between every single operation
* 'save' take 30-45 seconds with the same effect on CPU
* autopano-sift-c, nona, enblend, enfuse etc. when called all work as
expected

Not sure what I've done that's different [wrote over the old install,
cleared all settings and started from scratch] and might cause this.

Basic system info [to repeat]: AMD Athlon II x4 630, 4GB DDR3-1066
RAM, Windows 7 64-bit.. have tested to see if it's an allergic
reaction between programs to no avail.

[dex Otaku]

On May 22, 12:27 pm, dex Otaku <dexot...@gmail.com> wrote:
> Suddenly experiencing totally bizarre behaviour since updating to
> Tom's newest build -

Argh. DISREGARD - combination of image cache setting [increasing it
to ~256MB helps] and antivirus software strangling things.

[dex Otaku]

On May 22, 12:44 pm, dex Otaku <dexot...@gmail.com> wrote:
> On May 22, 12:27 pm, dex Otaku <dexot...@gmail.com> wrote:
>
> > Suddenly experiencing totally bizarre behaviour since updating to
> > Tom's newest build -
>
> Argh.  DISREGARD - combination of image cache setting [increasing it
> to ~256MB helps] and antivirus software strangling things.
>

Argh again. The settings fixed the general slowness but saving any
project still takes ~30 seconds.

[Tom Glastonbury]

On 22/05/2010 9:52 PM, dex Otaku wrote:
> On May 22, 12:44 pm, dex Otaku<dexot...@gmail.com> wrote:
>
>> On May 22, 12:27 pm, dex Otaku<dexot...@gmail.com> wrote:
>>
>>
>>> Suddenly experiencing totally bizarre behaviour since updating to
>>> Tom's newest build -
>>>
>> Argh. DISREGARD - combination of image cache setting [increasing it
>> to ~256MB helps] and antivirus software strangling things.
>>
>>
> Argh again. The settings fixed the general slowness but saving any
> project still takes ~30 seconds.
>
>

Hi Dex -

Which build exactly are you referring to? Are you saying that it didn't
happen in one of my previous 64-bit builds? If so, which build did not
have the problem?

Tom

[Tom Glastonbury]

On 21/05/2010 8:57 AM, Erik Krause wrote:
> Am 20.05.2010 15:04, schrieb Tom Glastonbury:
>> You'll be glad to hear that I'm working on the 64-bit Windows build of
>> enblend/enfuse.
>
> Very glad indeed! Could you fix bug 2932316 in your builds? It's very
> annoying...
>
> -> http://tinyurl.com/2vkdnfx
>

Hi Erik -

I have not even looked at the source code of enblend/enfuse and have no
familiarity with it whatsoever! At the moment I'm spending what time I
have available focussing on producing the 64-bit builds and the Windows
SDK. As and when I get that body of work out of the way, I might be able
to look at specific bugs, but if it's not a Windows-specific bug, you'd
probably get more joy from someone else...

Tom

[dex Otaku]

On May 22, 4:25 pm, Tom Glastonbury <t...@tomglastonbury.com> wrote:

> Which build exactly are you referring to? Are you saying that it didn't
> happen in one of my previous 64-bit builds? If so, which build did not
> have the problem?

Had no problems with your first posted binaries until the current,
Hugin-2010.1.0.645a8acc3d37-PreRelease-Win-x64-20100517, which has
this issue [here].

[Tom Glastonbury]

On 22/05/2010 11:11 PM, dex Otaku wrote:
> Had no problems with your first posted binaries until the current,
> Hugin-2010.1.0.645a8acc3d37-PreRelease-Win-x64-20100517, which has
> this issue [here].
>

Can you confirm that going back to one of my earlier builds still works
fine, and can you work out the simplest test case that reliably
reproduces this problem? Eg, load one arbitary image, save project -
takes 30 seconds.

Thanks,

Tom

[dex Otaku]

On May 23, 5:17 am, Tom Glastonbury <t...@tomglastonbury.com> wrote:
> On 22/05/2010 11:11 PM, dex Otaku wrote:> Had no problems with your first posted binaries until the current,
> > Hugin-2010.1.0.645a8acc3d37-PreRelease-Win-x64-20100517, which has
> > this issue [here].
>
> Can you confirm that going back to one of my earlier builds still works
> fine, and can you work out the simplest test case that reliably
> reproduces this problem? Eg, load one arbitary image, save project -
> takes 30 seconds.

At somewhat of a loss here.

I've tried your builds 5145 and 5154 as well as 645 .. they now -all-
do the same thing. I can't help but feel this has something to do
with my machine [or more likely, installation of Windows] in
particular, given that everything was working normally and then it
turned.

Notes:
* it depends on the size of the project file, or more precisely, it
seems to depend on the number of control points in it. Very small
panos save quickly without a problem. My 36+ image spherical panos
take 20-30 seconds to save.
* I've been looking at the results of saving a file in Hugin with
sysinternals process monitor: I'm not an expert on the info it can
give but other than constant "FAST IO DISALLOWED" messages for every
write made, nothing weird appears to be happening. Last example:
saved at 11:57:08.xx and there's a gap between a number of initial
writes and it starting to finish the job at 11:57:34.xx. At both
times the actual writing job is less than .5 sec in length.
* other processes occurring during the gap in saving are not
consistent [across logging events during 10 saves], so it would appear
that the issue isn't something else that's running
* this all started after i upgraded versions .. which also caused an
issue with Windows' "open with" menu, not allowing me to point the
association for .pto files at hugin. I tried deleting all hugin-
related registry entries and starting over again with the last
installer version available [2009.10] among other things, but nothing
except forcing the association with 3rd party tools [the equivalent of
editing the registry entries directly] would work. It's almost as
though the path Hugin is at got poisoned somehow by overwriting the
binaries in place.
* running as an administrator [with the thinking that this may be a
permissions issue] does not change anything.

Again, it would appear this has something to do with my machine/
Windows install, not Hugin. No idea what to try now.

D

[dex Otaku]

also,
* turning off/on [Comodo] antivirus et al has no effect
* moving hugin to another location has no effect