hugin SDK for windows

[Guido Kohlmeyer]

Good morning,

I prepared a SDK to build hugin on windows platform. It is based on
current releases of boost, wxwindows, libpano and other tools.
I applied the aproach to bundle only the necessary includes and libs,
without any documentation. The result is a 350MB package (34MB archive).
Currently I run only a build test with hugin. Before I'll release the
package I want to give the chance to test it. Are there any developers
interessted to do a test.
The other point is web-space. Any suggestions, where I can upload the
package?

Guido

[RizThon]

Hi,
I run Windows XP 32bit so I can definitely test it (for once there's something I have the skills to do ^^).
When you ask for web-space, you're asking for some temporary space so that we can do some tests before releasing it or your asking for some sourceforge credentials?
Cheers,
  RizThon

[Yuval Levy]

Hi Guido,

Guido Kohlmeyer wrote:
> I prepared a SDK to build hugin on windows platform.

great. I'd be interested to know if you can open network files with
Hugin compiled with your SDK, to understand if it is a problem of my SDK.

> It is based on
> current releases of boost, wxwindows, libpano and other tools.

current as in SVN/CVS, or current as in latest releases?

my approach is to use svn:externals properties to "suck in" the latest
dependencies. It takes a full day to build boost on my 3GHz dual core
AMD box, but eventually, when all bits and pieces are in place, I will
commit it to SVN so that people will download their SDK from SVN. It
will give us the ability to easily maintain references to different SDKs
(e.g. against different versions of wxWidgets and other external
dependencies) and to "quickly" (will need some optimizations to compile
only those parts of boost that are needed by Hugin) test if a regression
is due to a dependency or to a change in the Hugin code. Also it should
make it possible for people who are using non-latin language to have
their own SDK-branch with support for the appropriate toolchain.

> The other point is web-space. Any suggestions, where I can upload the
> package?

Thomas Rauscher has kindly given some space on panotools.org. I suggest
using that. I think Harrie uses it for the OSX builds and has the
credentials to access it.

Yuv

[Guido Kohlmeyer]

Dear all,

I prepared a SDK based on following components ...

Contents of the hugin SDK [2009-02-09]

/boost_1_37_0 [http://www.boost.org/]
boost libraries date-time and threads
/Deploy [http://www.openexr.com/]
OpenEXR libraries ilmbase 1.0.1 + openexr 1.6.1
/exiftool [http://www.sno.phy.queensu.ca/~phil/exiftool]
[pre-build] ExifTool 7.67
/exiv2-0.18 [http://www.exiv2.org/][http://sourceforge.net/projects/expat/]
Exiv2 0.18 + Expat 2.0.1
/gettext [http://ftp.gnu.org/gnu/]
[pre-build] gettext runtime 0.13.1 + gettext tools 0.13.1 +
libiconv 1.9.1
/glew
glew library 1.5.1
/libpano
[https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/libpano]
libpano SVN 944
/UnxUtils [http://sourceforge.net/projects/unxutils/]
[pre-build] UnxUtils
/wxWidgets-2.8.9 [http://www.wxwidgets.org/]
wxWidgets 2.8.9

Some of the components are pre-build versions that are already built by
their responsible developers. All other libs were built based on the
current released version. The only exception is libpano (panotools),
which was built from current SVN version 944.

Therefore this SDK is a snapshot of the tools and libs that hugin needs
to be build. Some of them may change over time.

Sure, this is only a snapshot, but I guess that some windows developers
will find it helpful. You approach, Yuv, seems to be more sophisticated,
i.e. to establish a build environment that is flexible over time and can
be rolled back due to usage of configuration management. It is good for
the "core-crew", but maybe a little bit oversized for the guys and/or
girls that want to play with hugin and to get their first steps ...

At that time I was very pleased to find a small SDK package as a good
starting point. Hopefully a small honey pod to get more developers :-)

Ok, let's start with this package a new round of windows builds.

Some questions have to be answered:

Q: Where can I download the SDK?
A: http://hugin.panotools.org/testing/hugin/Hugin_SDK-20090209.exe

Q: How to install the SDK?
A: Execute the file and enter a directory to store the SDK files, e.g.
C:\src. This directory is called <src> in the next answer.

Q: How to build hugin?
A: You can get the latest hugin source code from subversion repository
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk
1) Create folder <src>\hugin
2) Select the folder, right-click > SVN Checkout...
4) In entry <URL of repository> enter
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk
5) Select HEAD revision
6) Press OK
7) Start cmake
8) In entry <Where is the source code> enter: <src>\hugin
9) In entry <Where to build the binaries> enter: <src>\hugin_build
Note: It is recommended to build the project in another folder then the
source code resides in. Applying this procedure the source and build
files are not mixed in one folder stucture.
10) Press Configure
11) In combo box <Build For> select "Visual Studio 9 2008"
12) Press OK
Note: CMake searches for several components to build the solution files.
If some required components are not found, CMake throws error messages
and marks the missing components in red color in the list. The following
error message comes up:
CMake Error at platforms/windows/installer/CMakeLists.txt:6 (MESSAGE):
Need to set builder (HUGIN_BUILDER) manually
Confirm the dialogs with OK
In the list of cached values select the currently empty value of
property HUGIN_BUILDER
Enter you name.
Press Configure button.The following error message comes up:
CMake Error at platforms/windows/installer/CMakeLists.txt:13 (MESSAGE):
Need to set build date (HUGIN_BUILDDATE) manuallyConfirm the dialogs with OK
In the list of cached values select the currently empty value of
property HUGIN_BUILDDATE
Enter the current date in format YYYY-MM-DD
Press Configure button
14) Press OK
15) Open the generated Visual Studio solution file
<src>\hugin_build\hugin.sln
16) Select Build > Configuration Manager
17) Choose Release in Active solution configuration and confirm with Close
18) Select Build > Build Solution
Note: The build process may take some time ...
19) Right-click on project INSTALL, select Build

The files are stored in <src>\hugin_build\INSTALL\FILES
The application in sub-directory bin

Have fun. Feedback is welcome.

Guido

Yuval Levy schrieb:

[RizThon]

Thanks Guido, I'll try when I got time in a few days.

[allard]

Hi Guido,

Thanks for this! I'm trying it right now. In fact, VC is building as
I'm typing. Never done this before. Well not entirely true. Tried once
before to build hugin from an older SDK. It did not work for me at
that time. This time i got similar errors from Cmake about not being
able to find a tiff package. I found a patch to Cmake's finding thingy
here:
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindwxWidgets.cmake?root=CMake&view=markup
That got me past the configuration stage, further than I came last
time.

I know only a tiny bit of programming and I am a total newbie at this
Cmake stuff, I just have my general computer skills to help me. So I
guess I'm a good testcase.

VC is compiling fulla now... Let's see what comes out

thanks,
Allard

[Guido Kohlmeyer]

Dear Allard,

I used cmake 2.6.2 to build hugin and tested the build process with this
version.
It is mandatory to get the latest revision of hugin from SVN, because I
changed some cmake files to find wxWidgets, boost and exiv2.
I even read about problems. I trapped into one pitfall, because I started
to build the wxWidgets package in Visual Studio. Doing this some files
where not generated, which are search for by the find module of cmake.
I updated this module in my cmake installation.
After switching the build process of wxWidgets to the command line, I
expected that the old cmake module will work too. Maybe this is not the
case.

I have to test it and to note about it in my build diary.

Guido

[allard]

I'm also using CMake 2.6.2. I got the latest revision of hugin after
your previous post, but I just updated and got version 3635. In fact,
the build yesterday finished, but the program does not work, I think
it has to do with the wxrc executable that cannot be found in
wxwidgets. I can't find it either, not even in the downloaded and
installed version I have (2.8.9). It tried building the wxrc project
in wxwidgets using VS2008 but that only gave me a .obj file, not an
executable. I'm messing around here and I don't really know what I'm
doing half the time but it's fun.
Cmake also looks for a libpano12 directory and library, which is not
included in the SDK. Is that correct? I'll try again see what happens

allard

On Feb 10, 1:06 pm, "Guido Kohlmeyer" <d...@gekko-design.de> wrote:
> Dear Allard,
>
> I used cmake 2.6.2 to build hugin and tested the build process with this
> version.
> It is mandatory to get the latest revision of hugin from SVN, because I
> changed some cmake files to find wxWidgets, boost and exiv2.
> I even read about problems. I trapped into one pitfall, because I started
> to build the wxWidgets package in Visual Studio. Doing this some files
> where not generated, which are search for by the find module of cmake.
> I updated this module in my cmake installation.
> After switching the build process of wxWidgets to the command line, I
> expected that the old cmake module will work too. Maybe this is not the
> case.
>
> I have to test it and to note about it in my build diary.
>
> Guido
>
>
>
> > Hi Guido,
>
> > Thanks for this! I'm trying it right now. In fact, VC is building as
> > I'm typing. Never done this before. Well not entirely true. Tried once
> > before to build hugin from an older SDK. It did not work for me at
> > that time. This time i got similar errors from Cmake about not being
> > able to find a tiff package. I found a patch to Cmake's finding thingy
> > here:

> >http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindwxWidgets.c...

[Guido Kohlmeyer]

The libpano12 is not needed if libpano13 is found, which should be the
case. libpano12 is the old version of the panotools library and libpano13
is the current version.
I will check the problem with wxrc later.

[Yuval Levy]

Hi Guido and everybody else,

Guido Kohlmeyer wrote:
> I used cmake 2.6.2

try a 2.7 nightly build.

> I even read about problems. I trapped into one pitfall, because I started
> to build the wxWidgets package in Visual Studio. Doing this some files
> where not generated, which are search for by the find module of cmake.

IIRC 2.6.2 has a bug in FindwxWidgets.cmake. It did not work for me with
2.6.2. The nightly build 2.7.20081001 worked. I had similar changes to
Hugin's CMake build as Guido, but my local builds have started to show
problems when opening files over the network and I am stuck trying to
understand if I inadvertendly caused the regression.

Yuv

[allard]

It builds! I needed to add a bunch of empty files named README, TODO
etc because building INSTALL won't work if you don't, but I got it. I
can even run hugin and use some of the new features and projections
after opening an older PTO. But when I press 'stitch now' I get this
error:

make: *** No rule to make target `FILENAME REMOVED BY ME, EXISTING
FILE', needed by `pano8v0000.tif'. Stop.

[Yuval Levy]

allard wrote:
> It builds! I needed to add a bunch of empty files named README, TODO
> etc because building INSTALL won't work

Guido's SDK is short of what it needs to build the install target.
You'll need at least enblend-enfuse, and also autopano-sift-c IIRC.

Your best bet is to take a previous version of the SDK and overwrite it
with Guido's newer components.

> make: *** No rule to make target `FILENAME REMOVED BY ME, EXISTING
> FILE', needed by `pano8v0000.tif'. Stop.

May be related to the above.

Yuv

[Guido Kohlmeyer]

I appologize about the missing information about the SDK and the other
tools that are needed to work with hugin.
The SDK has (should have) currently all components to build, but there are
some additional tools needed to run. These tools are e.g. autopanao-sift-c
and enblend/enfuse. I decided not to include them in the SDK, but to store
them in an additional package. Maybe the wrong decision.
Therefore the discussion here to get rid of the teething troubles and to
find a good solution what should be in and out.

So far, thank you for your comments. I'm looking forward for other's
feedback, too

Guido

[allard]

Hi Guido, I have Enblend and Autopano-sift-(c) from the 0.7 release. I
had to manually point C-make to their locations but what I did when
building was point to an install of autopano-sift (not c), version 2.3
(not 2.5). Could that be a problem? I got the source for both enblend
and autopano-sift-c 2.5 but they won't build. Does the SDK need the
executables only or the source as well? I have installed enblend 3.2
with the downloadable installer but I see no difference.
Yuv thanks for the tip on CMake, that may be causing some of the
troubles.

On Feb 10, 4:19 pm, "Guido Kohlmeyer" <d...@gekko-design.de> wrote:
> I appologize about the missing information about the SDK and the other
> tools that are needed to work with hugin.
> The SDK has (should have) currently all components to build, but there are

> some additional tools needed to run. These tools are e.g. autopana-sift-c

[allard]

I skipped over the autopano issue. The lib may not be needed but iirc
I did get an error when building. At least I got a red line in Cmake.
I just pointed to the pano13 directory and lib, that worked.

[Bruno Postle]

This could be a problem with file name escaping as this code chnaged
recently, do you have spaces or other characters such as #, $, ' in
your paths?

It would be really useful to see the actual error message without
any alteration.

--
Bruno

[allard]

Yes there are spaces and it is a long path.
"C:\Documents and Settings\allard katan\My Documents\personal\fotos
\2008\2008_11_23-CostaBlanca met pap\panosingle\IMG_5473.jpg" was the
path. Note that for windows users, spaces in paths are very common. I
have almost everything on my harddisk either under 'Documents and
Settings" or "Program files". BTW I installed cmake 2.7 most recent
build, cleaned out the build directory and did a fresh build. No
problems building now BUT hugin crashes consistently on startup. I get
splash screen, parts of the window (with 'fast panorama preview' in
the title bar!) and then the famous 'hugin.exe has encountered a
problem and needs to close. We are sorry for the inconvenience.'

[Yuval Levy]

allard wrote:
> hugin crashes consistently on startup.

try deleting the hugin registry key. I've noticed this too. It happens
consistently when I move forth and back between different versions of hugin.

Yuv

[allard]

Yep, deleting registry worked. But when I started same version a
second time (normal close, no crash) I had to remove registry again.
Did a quick check on the filename thing. If I move the images to C:
\Data and rename to take underscores out I get the same error. But
hey, what do I see:
make: *** No rule to make target `C\:\DATA\test1.JPG', needed by
`test0000.tif'. Stop.

There is a \ too much in the filename after the C. Had not noticed
that before. Looks a lot like an escape character problem, Bruno?

[allard]

Oh, and before I forget: Fast preview absolutely rocks!
To me, it makes hugin a different experience. And a much better one at
that.

[Yuval Levy]

allard wrote:
> Yep, deleting registry worked. But when I started same version a
> second time (normal close, no crash) I had to remove registry again.

what status are the preview windows when you close hugin? try with the
fast preview opened and maximized; then with fast preview closed. I
suspect a small bug there.

Yuv

[T. Modes]

When I trying to compile with VCEE, I get the error

LINK : fatal error LNK1104: File "LIBC.lib" can not be opened

when compiling the sub-project "Hugin". All other projects compile
fine.

I added libc.lib to the exclude libs in linker options and it works.
I've to repeat the step after every cmake run. Is there a better
solution for this problem or have I only missed a option to set?

Thomas

[allard]

It does not reproduce, independent of preview window status...

[Lukáš Jirkovský]

2009/2/11 allard <ka...@physics.leidenuniv.nl>:

>
> Yep, deleting registry worked. But when I started same version a
> second time (normal close, no crash) I had to remove registry again.
> Did a quick check on the filename thing. If I move the images to C:
> \Data and rename to take underscores out I get the same error. But
> hey, what do I see:
> make: *** No rule to make target `C\:\DATA\test1.JPG', needed by
> `test0000.tif'. Stop.
>
> There is a \ too much in the filename after the C. Had not noticed
> that before. Looks a lot like an escape character problem, Bruno?
>

Oh, it may be my fault. How does it look like exactly? Or just post
the makefile.

[allard]

OK, I don't know how to attach a file and I'm too lazy to upload it to
my website, so here's the makefile. All the paths have a slash too
many:

# makefile for panorama stitching, created by hugin



# Tool configuration
NONA=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES\bin
\nona
PTSTITCHER=PTStitcher
PTMENDER=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\PTmender
PTBLENDER=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\PTblender
PTMASKER=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\PTmasker
PTROLLER=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\PTroller
ENBLEND=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\enblend
ENFUSE=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES\bin
\enfuse
SMARTBLEND=smartblend.exe
HDRMERGE=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\hugin_hdrmerge
RM=rm
EXIFTOOL=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES
\bin\exiftool

# options for the programs

NONA_LDR_REMAPPED_COMP=-z PACKBITS
ENBLEND_OPTS= -f4605x3889
ENBLEND_LDR_COMP=--compression NONE
ENBLEND_HDR_COMP=
ENFUSE_OPTS=
EXIFTOOL_COPY_ARGS=-ImageDescription -Make -Model -Artist -WhitePoint -
Copyright -GPS:all -DateTimeOriginal -CreateDate -UserComment -
ColorSpace -OwnerName -SerialNumber

# the output panorama
LDR_REMAPPED_PREFIX=test1-test2
LDR_REMAPPED_PREFIX_SHELL=test1-test2
HDR_STACK_REMAPPED_PREFIX=test1-test2_hdr_
HDR_STACK_REMAPPED_PREFIX_SHELL=test1-test2_hdr_
LDR_EXPOSURE_REMAPPED_PREFIX=test1-test2_exposure_layers_
LDR_EXPOSURE_REMAPPED_PREFIX_SHELL=test1-test2_exposure_layers_
PROJECT_FILE=C\:\DATA\test1-test2.pto
PROJECT_FILE_SHELL=C\:\DATA\test1-test2.pto
LDR_BLENDED=test1-test2.tif
LDR_BLENDED_SHELL=test1-test2.tif
LDR_STACKED_BLENDED=test1-test2_fused.tif
LDR_STACKED_BLENDED_SHELL=test1-test2_fused.tif
HDR_BLENDED=test1-test2_hdr.exr
HDR_BLENDED_SHELL=test1-test2_hdr.exr

# first input image
INPUT_IMAGE_1=C\:\DATA\test1.JPG
INPUT_IMAGE_1_SHELL=C\:\DATA\test1.JPG
# all input images
INPUT_IMAGES=C\:\DATA\test1.JPG\
C\:\DATA\test2.JPG

INPUT_IMAGES_SHELL=C\:\DATA\test1.JPG\
C\:\DATA\test2.JPG

# remapped images
LDR_LAYERS=test1-test20000.tif\
test1-test20001.tif

LDR_LAYERS_SHELL=test1-test20000.tif\
test1-test20001.tif

# remapped images (hdr)
HDR_LAYERS=test1-test2_hdr_0000.exr\
test1-test2_hdr_0001.exr

HDR_LAYERS_SHELL=test1-test2_hdr_0000.exr\
test1-test2_hdr_0001.exr

# remapped maxval images
HDR_LAYERS_WEIGHTS=test1-test2_hdr_0000_gray.pgm \
test1-test2_hdr_0001_gray.pgm

HDR_LAYERS_WEIGHTS_SHELL=test1-test2_hdr_0000_gray.pgm\
test1-test2_hdr_0001_gray.pgm

# stacked images
HDR_STACKS_NUMBERS = 0 1
HDR_STACK_0 = test1-test2_stack_hdr_0000.exr
HDR_STACK_0_SHELL = test1-test2_stack_hdr_0000.exr
HDR_STACK_0_INPUT = test1-test2_hdr_0000.exr

HDR_STACK_0_INPUT_SHELL = test1-test2_hdr_0000.exr

HDR_STACK_1 = test1-test2_stack_hdr_0001.exr
HDR_STACK_1_SHELL = test1-test2_stack_hdr_0001.exr
HDR_STACK_1_INPUT = test1-test2_hdr_0001.exr

HDR_STACK_1_INPUT_SHELL = test1-test2_hdr_0001.exr


HDR_STACKS = $(HDR_STACK_0) $(HDR_STACK_1)
HDR_STACKS_SHELL = $(HDR_STACK_0_SHELL) $(HDR_STACK_1_SHELL)


# number of image sets with similar exposure
LDR_EXPOSURE_EXPOSURE_LAYERS_NUMBERS = 0
LDR_EXPOSURE_LAYER_0 = test1-test2_exposure_00.tif
LDR_EXPOSURE_LAYER_0_SHELL = test1-test2_exposure_00.tif
LDR_EXPOSURE_LAYER_0_INPUT = test1-test2_exposure_layers_0000.tif\
test1-test2_exposure_layers_0001.tif

LDR_EXPOSURE_LAYER_0_INPUT_SHELL = test1-test2_exposure_layers_0000.tif
\
test1-test2_exposure_layers_0001.tif

LDR_EXPOSURE_LAYER_0_INPUT_PTMENDER = test1-test20000.tif\
test1-test20001.tif

LDR_EXPOSURE_LAYER_0_INPUT_PTMENDER_SHELL = test1-test20000.tif\
test1-test20001.tif
LDR_EXPOSURE_LAYER_0_EXPOSURE = 29.2018

LDR_EXPOSURE_LAYERS = $(LDR_EXPOSURE_LAYER_0)
LDR_EXPOSURE_LAYERS_SHELL = $(LDR_EXPOSURE_LAYER_0_SHELL)
LDR_EXPOSURE_LAYERS_REMAPPED = test1-test2_exposure_layers_0000.tif\
test1-test2_exposure_layers_0001.tif

LDR_EXPOSURE_LAYERS_REMAPPED_SHELL = test1-
test2_exposure_layers_0000.tif\
test1-test2_exposure_layers_0001.tif


# stacked images for enfuse or other automatic exposure blending tools
LDR_STACKS_NUMBERS = 0 1
LDR_STACK_0 = test1-test2_stack_ldr_0000.tif
LDR_STACK_0_SHELL = test1-test2_stack_ldr_0000.tif
LDR_STACK_0_INPUT = test1-test2_exposure_layers_0000.tif

LDR_STACK_0_INPUT_SHELL = test1-test2_exposure_layers_0000.tif

LDR_STACK_1 = test1-test2_stack_ldr_0001.tif
LDR_STACK_1_SHELL = test1-test2_stack_ldr_0001.tif
LDR_STACK_1_INPUT = test1-test2_exposure_layers_0001.tif

LDR_STACK_1_INPUT_SHELL = test1-test2_exposure_layers_0001.tif


LDR_STACKS = $(LDR_STACK_0) $(LDR_STACK_1)
LDR_STACKS_SHELL = $(LDR_STACK_0_SHELL) $(LDR_STACK_1_SHELL)
TEMP_FILES_SHELL = $(LDR_LAYERS_SHELL)

all: $(LDR_BLENDED)

clean:
-$(RM) $(TEMP_FILES_SHELL)

# Rules for ordinary TIFF_m output
test1-test20000.tif: C\:\DATA\test1.JPG $(PROJECT_FILE)
$(NONA) $(NONA_LDR_REMAPPED_COMP) -r ldr -m TIFF_m -o $
(LDR_REMAPPED_PREFIX_SHELL) -i 0 $(PROJECT_FILE_SHELL)

test1-test20001.tif: C\:\DATA\test2.JPG $(PROJECT_FILE)
$(NONA) $(NONA_LDR_REMAPPED_COMP) -r ldr -m TIFF_m -o $
(LDR_REMAPPED_PREFIX_SHELL) -i 1 $(PROJECT_FILE_SHELL)

# Rules for merge to hdr output
test1-test2_hdr_0000.exr: C\:\DATA\test1.JPG $(PROJECT_FILE)
$(NONA) -r hdr -m EXR_m -o $(HDR_STACK_REMAPPED_PREFIX_SHELL) -i 0 $
(PROJECT_FILE_SHELL)

test1-test2_hdr_0001.exr: C\:\DATA\test2.JPG $(PROJECT_FILE)
$(NONA) -r hdr -m EXR_m -o $(HDR_STACK_REMAPPED_PREFIX_SHELL) -i 1 $
(PROJECT_FILE_SHELL)

# Rules for exposure layer output
test1-test2_exposure_layers_0000.tif: C\:\DATA\test1.JPG $
(PROJECT_FILE)
$(NONA) $(NONA_LDR_REMAPPED_COMP) -r ldr -e 14.6147 -m TIFF_m -o $
(LDR_EXPOSURE_REMAPPED_PREFIX_SHELL) -i 0 $(PROJECT_FILE_SHELL)

test1-test2_exposure_layers_0001.tif: C\:\DATA\test2.JPG $
(PROJECT_FILE)
$(NONA) $(NONA_LDR_REMAPPED_COMP) -r ldr -e 14.5871 -m TIFF_m -o $
(LDR_EXPOSURE_REMAPPED_PREFIX_SHELL) -i 1 $(PROJECT_FILE_SHELL)

$(HDR_STACK_0) : $(HDR_STACK_0_INPUT)
$(HDRMERGE) -m avg -c -o $(HDR_STACK_0_SHELL) $
(HDR_STACK_0_INPUT_SHELL)

$(HDR_STACK_1) : $(HDR_STACK_1_INPUT)
$(HDRMERGE) -m avg -c -o $(HDR_STACK_1_SHELL) $
(HDR_STACK_1_INPUT_SHELL)

$(LDR_STACK_0) : $(LDR_STACK_0_INPUT)
$(ENFUSE) $(ENFUSE_OPTS) -o $(LDR_STACK_0_SHELL) $
(LDR_STACK_0_INPUT_SHELL)
- $(EXIFTOOL) -overwrite_original_in_place -TagsFromFile $
(INPUT_IMAGE_1_SHELL) $(EXIFTOOL_COPY_ARGS) $(LDR_STACK_0_SHELL)

$(LDR_STACK_1) : $(LDR_STACK_1_INPUT)
$(ENFUSE) $(ENFUSE_OPTS) -o $(LDR_STACK_1_SHELL) $
(LDR_STACK_1_INPUT_SHELL)
- $(EXIFTOOL) -overwrite_original_in_place -TagsFromFile $
(INPUT_IMAGE_1_SHELL) $(EXIFTOOL_COPY_ARGS) $(LDR_STACK_1_SHELL)

$(LDR_BLENDED) : $(LDR_LAYERS)
$(ENBLEND) $(ENBLEND_LDR_COMP) $(ENBLEND_OPTS) -o $
(LDR_BLENDED_SHELL) $(LDR_LAYERS_SHELL)
- $(EXIFTOOL) -overwrite_original_in_place -TagsFromFile $
(INPUT_IMAGE_1_SHELL) $(EXIFTOOL_COPY_ARGS) $(LDR_BLENDED_SHELL)

$(LDR_EXPOSURE_LAYER_0) : $(LDR_EXPOSURE_LAYER_0_INPUT)
$(ENBLEND) $(ENBLEND_LDR_COMP) $(ENBLEND_OPTS) -o $
(LDR_EXPOSURE_LAYER_0_SHELL) $(LDR_EXPOSURE_LAYER_0_INPUT_SHELL)
-$(EXIFTOOL) -overwrite_original_in_place -TagsFromFile $
(INPUT_IMAGE_1_SHELL) $(EXIFTOOL_COPY_ARGS) $
(LDR_EXPOSURE_LAYER_0_SHELL)

$(LDR_STACKED_BLENDED) : $(LDR_STACKS)
$(ENBLEND) $(ENBLEND_LDR_COMP) $(ENBLEND_OPTS) -o $
(LDR_STACKED_BLENDED_SHELL) $(LDR_STACKS_SHELL)
- $(EXIFTOOL) -overwrite_original_in_place -TagsFromFile $
(INPUT_IMAGE_1_SHELL) $(EXIFTOOL_COPY_ARGS) $
(LDR_STACKED_BLENDED_SHELL)

$(HDR_BLENDED) : $(HDR_STACKS)
$(ENBLEND) $(ENBLEND_HDR_COMP) $(ENBLEND_OPTS) -o $
(HDR_BLENDED_SHELL) $(HDR_STACKS_SHELL)



On Feb 11, 9:35 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> 2009/2/11 allard <ka...@physics.leidenuniv.nl>:

[Lukáš Jirkovský]

2009/2/11 allard <ka...@physics.leidenuniv.nl>:

So If I understand it correctly removing backslashe from C\: makes it work?

[allard]

I tried to manually change the makefile, but this did not work,
because hugin overrides that somehow. The makefile is only saved when
saving the project, but if you manually edit the makefile and press
'stitch now', you still get the same error. So i cannot check if the
whole stitching process works, but at least the paths are correct if
the backslashes between C and : , and before the space, are removed.
So

"NONA=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES\bin
\nona "

should be

"NONA=C:\Program Files\hugin\homebuild\hugin_build\INSTALL\FILES\bin
\nona "


>

[Guido Kohlmeyer]

Yes, this should work. On windows platform the syntax of an absolute path is:
<drive letter>:\path\to\file\<filename>
For example:
C:\My Photos\Ireland 2008\DSCN0012.jpg

As you see spaces are possible and were already supported in hugin 0.7.0.
I expect omitting the (back)slash between drive letter and colon will fix
the problem.

Guido

[Guido Kohlmeyer]

Dear allard,

The backslash before the space character is mandatory to escape the space
charater. Otherwise the space will be a separator and only the part until
the space is assigned to the variable on the left hand side of the
equation sign.
The backslash between the drive letter and the colon is the main problem.

By the way the makefile is generated automatically when you start a stich
process. If you want to play with makefiles you can even start the
makefile using the tool make: make -f <makefilename>

Guido

[Lukáš Jirkovský]

I tried to manually change the makefile, but this did not work,
because hugin overrides that somehow. The makefile is only saved when
saving the project, but if you manually edit the makefile and press
'stitch now', you still get the same error. So i cannot check if the
whole stitching process works, but at least the paths are correct if
the backslashes between C and : , and before the space, are removed.
So

"NONA=C\:\Program\ Files\hugin\homebuild\hugin_build\INSTALL\FILES\bin
\nona "
should be
"NONA=C:\Program Files\hugin\homebuild\hugin_build\INSTALL\FILES\bin
\nona "

Yeah, for that occasion is possible to use make -f command. I'll fix
it in hugin's trunk.

[Lukáš Jirkovský]

I've committed the fix to the hugin trunk. This should fix this
problem (on the other hand I'm not sure if files with : in name would
work then, but I think ':'s are disallowed in file name in windows).
Sorry for breaking this.

[allard]

Well, at least using make -f everything works after fixing the slashes
manually.

here's the proof (pannini projection):
<a href="http://www.allardkatan.net/misc/test1-test2.jpg">
http://www.allardkatan.net/misc/test1-test2.jpg </a>

I'll do a new build tonight to see if the fix has worked.

allard

[allard]

I succesfully built and ran SVN nr 3640. Cmake comes with a few errors/
missing directories but only the Enblend directory has to be set
manually to be able to built. The rest apparently does not matter.
These are the 'notfounds'

PANO12_INCLUDE_DIR-NOTFOUND
PANO12_LIBRARY-NOTFOUND
ENBLEND_EXE_DIR-NOTFOUND
AP_SIFT_DIR-NOTFOUND
wxWidgets_wxrc_EXECUTABLE-NOTFOUND

The only thing that I had to do that was not in the 'manual' (Guido's
post), was to set the Enblend directory in Cmake. Without that the
INSTALL will not build.
No bugs encountered in the program. I could stitch two images and save
the output, work with fast preview, etc. I tried to make an HDR, and
although there were no bugs the output looked all funny with colors
that should not be there. But I've never done HDR in hugin (and hardly
elsewhere) before and haven't consulted manuals so I suspect user
error.

So, as far as I can tell, we have a winner here.

I forgot to mention: I'm on Win XP SP3, 2Gb Ram, Intel T2300 1.66 GHz.

[Guido Kohlmeyer]

Some comments about the "NOTFOUNDS" in cmake.

PANO12_*
This is not a probelm and can be neglected, because pano13 is found and
pano13 is the newer one. PANO12_* is only used if PANO13 is not found.
Therefore no error comes up.

AP_SIFT_DIR
ENBLEND_EXE_DIR
Enblend as well as Autopano-SIFT are standalone tools that are not
included in the SDK so far. They are available on my machine and this is
obviously the reason why I got no error. I even though that hugin will
build and install without enblend. Well, seems not the case.

wxWidgets_wxrc_EXECUTABLE
This variable is set by the FindwxWidgets module of cmake, but hugin
doesn't need it. The missing variable can be neglected.

Except for the ENBLEND_EXE the SDK seems to work. Thank you for testing. I
will improve my environment and maybe release an updated one.

Guido

[allard]

> AP_SIFT_DIR
> ENBLEND_EXE_DIR
> Enblend as well as Autopano-SIFT are standalone tools that are not
> included in the SDK so far. They are available on my machine and this is
> obviously the reason why I got no error. I even though that hugin will
> build and install without enblend. Well, seems not the case.

Actually, the problem in building only appears at the 'install\ phase
and seems not really related to the enblend executable. It's the
AUTHORS, README, TODO etc files from the enblend directory that give
the error. Without those the INSTALL build exits with this error:
>CMake Error at cmake_install.cmake:70 (FILE):
1> file INSTALL cannot find file "C:/Program
1> Files/hugin/homebuild/hugin/ENBLEND_EXE_DIR-NOTFOUND/AUTHORS" to
install.
1>Project : error PRJ0019: A tool returned an error code from
"Performing Post-Build Event..."

Apparently it looks for these files before installing enblend since
from the buildlog (built again after the error above, and after
setting the right parameter in CMAKE) I get that the executable is
installed first:

-- Up-to-date: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/panotools/stitch.txt
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/bin/enblend.exe
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/bin/enfuse.exe
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/AUTHORS
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/ChangeLog
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/COPYING
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/NEWS
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/README
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/README_WINDOWS.txt
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/TODO
-- Installing: C:/Program Files/hugin/homebuild/hugin_build/INSTALL/
FILES/doc/enblend/VIGRA_LICENSE

Anyway, thanks for making this available, I'm glad I could help a bit.

[Steeve]

Guido

Some more feedback.

1>Build log was saved at "file://c:\HuginSDK\hugin_build\INSTALL.dir
\Release\BuildLog.htm"
1>INSTALL - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 29 up-to-date, 0 skipped
==========

It worked for me.. (Once I remembered to use VC2008, rather than
VS2005.

I took a snap-shot from SVN on saturday morning (14/2/09), I had the
same 'pitfalls' as the previous people on this list. For the record I
missed Yuval advice as delete the old SDK first, but was able to point
cmake to the bin directory of my 0.7.0 hugin install.

The Hugin.exe appears to run, and I have stitched one simple two image
pano without problems. I will try later this week some more
challenging panoramas.

Thank-you very much for taking the time to assemble this SDK, and to
the others on this list for finding and fixing the pitfalls and first.

Please let us know if there is any further testing you like

Regards
Stephen