[hugin-ptx] Re: Enblend: CMake (Windows) broken

[Kornel Benko]

Am Tuesday 22 September 2009 schrieb Harry van der Wolf:
> The exact same thing happens also on OSX. I just removed the line from the
> CMakeLists.txt file. I will try tonight.
> I had not reported it yet as I was working on 2 Hugin things and 2 other
> things.
> 
> Harry

Harry, I already commited. Clearly my error.

Kornel

-- 
Kornel Benko
kornel.be...@berlin.de


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Enblend: CMake (Windows) broken

[Harry van der Wolf]

The exact same thing happens also on OSX. I just removed the line from the
CMakeLists.txt file. I will try tonight.
I had not reported it yet as I was working on 2 Hugin things and 2 other
things.

Harry

2009/9/22 Kornel Benko 

> Am Tuesday 22 September 2009 schrieb Yuval Levy:
> >
> > The CMake error, at line 33 of src/CMakeLists.txt says:
> > "set_target_properties called with incorrect number of arguments"
>
> I only see this line in enblend's cmake.
>
> It looks like OpenMP_CXX_FLAGS were not defined. Could you please check
> CMakeCache.txt for a similar variable (mybe only difference in case)
>
> Anyway it sholud read like:
>  if(OpenMP_CXX_FLAGS)
>set_target_properties(${_cmd} PROPERTIES LINK_FLAGS ${OpenMP_CXX_FLAGS})
>message(STATUS "Adding PROPERTIES LINK_FLAGS to ${_cmd}")
>  endif(Boost_FOUND)
>
> The output of running cmake should give you an indication of the value of
> OpenMP_CXX_FLAGS
>
> And it seems to be _my_ doing.
>
> > this is unrelated to Christoph's recent changes (rev. 524+) - it happens
> > already in rev. 523.
>
> > Yuv
>
> Could you please try?
>
>Kornel
> --
> Kornel Benko
> kornel.be...@berlin.de
>

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Enblend: CMake (Windows) broken

[Kornel Benko]

Am Tuesday 22 September 2009 schrieb Yuval Levy:
> 
> The CMake error, at line 33 of src/CMakeLists.txt says:
> "set_target_properties called with incorrect number of arguments"

I only see this line in enblend's cmake.

It looks like OpenMP_CXX_FLAGS were not defined. Could you please check
CMakeCache.txt for a similar variable (mybe only difference in case)

Anyway it sholud read like:
  if(OpenMP_CXX_FLAGS)
set_target_properties(${_cmd} PROPERTIES LINK_FLAGS ${OpenMP_CXX_FLAGS})
message(STATUS "Adding PROPERTIES LINK_FLAGS to ${_cmd}")
  endif(Boost_FOUND)

The output of running cmake should give you an indication of the value of 
OpenMP_CXX_FLAGS

And it seems to be _my_ doing.

> this is unrelated to Christoph's recent changes (rev. 524+) - it happens 
> already in rev. 523.

> Yuv

Could you please try?

Kornel
-- 
Kornel Benko
kornel.be...@berlin.de


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Aerial Photography Stitching

[Pablo d'Angelo]

Pablo d'Angelo wrote:
> Hi Matt,
> 
> The general workflow for "proper" orthorectification (as used by the 
> professionals) is:
> 
> 1. Measure some ground control points (GCPs) in the images. These 
> associate an image point with a 3D world position (lat, lon, height). If 
> a full bundle adjustment is used, this is not needed for every images as 
> tie points (called control points in hugin) can also be used. These are 
> usually measured against maps, orthoimages, gps traces. The height is 
> often derived from the SRTM dataset, or from high precision GPS 
> measurements with post processing at specific corner (centre of 
> roundabouts etc.).

Sorry, this was confusing. This is a better explanation: Tie point are 
measured between the images, Ground Control points are measured between 
the image and some reference data (maps, gps traces, digital elevation 
models, geodetic gps measurements etc.).

ciao
   Pablo

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Enblend: CMake (Windows) broken

[Yuval Levy]

The CMake error, at line 33 of src/CMakeLists.txt says:
"set_target_properties called with incorrect number of arguments"

this is unrelated to Christoph's recent changes (rev. 524+) - it happens 
already in rev. 523.

Yuv

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Hugin-2009.2.0_RC1 source code distribution released

[Yuval Levy]

Hi Terry,

Tduell wrote:
> I have successfully built RC1 and done some limited testing on Fedora
> 11 x86_64, and thus far all seems OK.

thanks for the good news!

Yuv

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Hugin-2009.2.0_RC1 source code distribution released

[Tduell]

Hullo Yuv,

On Sep 21, 12:10 pm, Yuval Levy  wrote:
> Panorama stitching and more. A powerful software package for creation
> and processing of panoramic images.
>
> hugin-2009.2.0_RC1 (release candidate 1) tarball is available here:
>
> 
>
> This is a release candidate and may be declared final in the coming days.

I have successfully built RC1 and done some limited testing on Fedora
11 x86_64, and thus far all seems OK.
Hugin 'about' reports svn 4461.
I have also successfully built (using mock) a fedora 11 i586 version.
I will pass these binary packages to Bruno so he can put them on his
server for all to access. The packages are...
hugin-2009.2.0-0.1.20090921svn.fc11.x86_64.rpm
hugin-base-2009.2.0-0.1.20090921svn.fc11.x86_64.rpm
hugin-2009.2.0-0.1.20090921svn.fc11.i586.rpm
hugin-base-2009.2.0-0.1.20090921svn.fc11.i586.rpm

Cheers,
Terry


--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Any free/open source tools to create QTVR/Cubic/Spherical Panorama

[Bruno Postle]

On Mon 21-Sep-2009 at 10:50 -0700, Leo wrote:
>
>I stitched the panorama images by Hugin. But I need to convert it to
>QTVR/Cubic/Spherical Panorama format. Any free/open source tools to
>create QTVR/Cubic/Spherical Panorama to recommend?

erect2qtvr creates a basic cubic QTVR panorama from a single 
equirectangular panorama.  It is part of the Panotools::Script perl 
module:

http://search.cpan.org/dist/Panotools-Script/bin/erect2qtvr

-- 
Bruno

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Aerial Photography Stitching

[Pablo d'Angelo]

Hi Matt,

The general workflow for "proper" orthorectification (as used by the 
professionals) is:

1. Measure some ground control points (GCPs) in the images. These 
associate an image point with a 3D world position (lat, lon, height). If 
a full bundle adjustment is used, this is not needed for every images as 
tie points (called control points in hugin) can also be used. These are 
usually measured against maps, orthoimages, gps traces. The height is 
often derived from the SRTM dataset, or from high precision GPS 
measurements with post processing at specific corner (centre of 
roundabouts etc.).

2. With the GCPs and tie points, the position and orientation of each 
photo is estimated using bundle adjustment. This works a bit similar to 
what hugin/panotools does, but it solves for full 3D geometry.

3. Orthorectification is preformed using the estimated positions and 
orientations and a digital terrain model. If there is a lot of overlap 
in the photos, the terrain model can also be computed from the photos 
itself (This is actually what I currently do in my day job).

All data that is required for this is freely available. You can use well 
traces streets in OSM for establishing the ground control points in step 
1). The SRTM model required for orthorectification is available in the 
public domain (at least for areas south of 60° northern latitude).

The main problem is that there is no complete open source software 
package for this job. All the components are available in various 
software packages, but they are not integrated:

- Tie points can be created in hugin or with other matching software. 
With a bit of scripting, GCPs can be derived from tie points measured 
against OSM maps (its just coordinate transformation and lookup in the 
elevation model).

- A complete package that takes care of most steps required for 1) and 
2) is bundler, http://phototour.cs.washington.edu/bundler/ however, this 
is not designed to handle ground control points, so it won't give you 
absolute coordinates. It uses a customized version of SBA 
http://www.ics.forth.gr/~lourakis/sba/ for the bundle adjustment. SBA 
recently been extended so that it supports both tie points and ground 
control points.

- Orthorectification can be done using open source remote sensing 
software packages such as http://www.ossim.org or 
http://www.orfeo-toolbox.org. However, these packages are mostly 
designed for handling commercial satellite and aerial imagery, and I'm 
not sure if the support a simple camera model.

Then there is e-foto, which I have just downloaded as tried, but I 
didn't manage to do something useful with it.

So the correct way to produce nice orthophotos as shown by the map 
providers is not that simple using open source software, and needs quite 
some gluing together of several packages.

Hugin is currently not really suited for aligning all your images. 
However, the latest work in panotools (as mentioned in the reply by 
Lukas) might help if your area is reasonably flat.

The new parameters Tx, Ty and Ts parameters in panotools should allow 
you to "orthorectify" your images to a plane. As these are are very new, 
they are not supported in hugin yet. This means that you need to use the 
  panotools script interface from the command line directly. Maybe the 
following procedure might work (disclamer: I haven't tried anything of 
that myself!):

0. Get and compile the current trunk of libpano13

1. Load a few overlapping images captured from different viewpoints 
(maybe start with 3 or so) into hugin, and create a few good control 
points between them (make sure that they are good, to avoid confusion 
due to mismatched control points later on). Try to load a very well 
downwards looking image as first image. This image will define the plane 
to which the other images are warped later on.

Do not optimize yet. Make sure that the field of view of the images is 
reasonably correct. (Computation from EXIF data is probably good for the 
first try).

2. Set the projection to rectilinear, and choose a wide HFOV and VFOV, 
such as 90 degrees or so. Press the "compute optimum size" button.

3. Export everything as panotools compatible project. The 100% 
bulletproof way is to go to the optimisation tab, tick the "edit script 
before optimisation" (or similar) checkbox, press Optimize and select 
the text of the checkbox and save it into a textfile named optimize.txt

4. Now you need to select which variables to optimize, using by adding 
them to the v line in optimize.txt. I would try optimizing roll, pitch, 
yaw and Tx, Ty, Ts for all but the first image. Run
$ PToptimizer optimize.txt
to perform the optimisation. Check the file to see some information 
about the errors. Here some trial and error with different parameter 
sets is probably needed.

5. Test remapping the images with PTmender:
$ PTmendler optimize.txt

6. Combine the without any blending using PTroller
$ PTroller -o output.tif remapped1.tif remapped2.tif

[hugin-ptx] Re: Aerial Photography Stitching

[Matt Williams]

2009/9/21 Lukáš Jirkovský :
> First, there are some new tilt options to the panorama tools (Tx, Ty,
> Tz and Ts) but doesn't use them yet.

I've had a look through the archives and I see that the options you
mention could indeed be very useful. What version of Hugin are these
likely to turn up in? I don't mind building from source but I'd like
to know which branch to get. Or should I just grab trunk?

> I'd try to load map into hugin and manually add control points to
> photos and corresponding parts of map. Then optimize with map set as
> anchor image. This would hopefully transform images to fit map
> directly in hugin. And for stitching I'de disable the map so it
> doesn't blend with photos by coincidence.

Yes, that's what I've been doing so far but I'm unable to stitch
together more than about 3 images before it significantly deviates (as
in ~20 ground distance) from the map. The tilt options should help
with this, even if they don't allow me to stitch any more together at
once but only allow the images to be more accurate. Really for our
purposes, accurately conforming to the ground truth is more important
than seamless blending or colour balance (though they would help).

-- 
Matt Williams
http://milliams.com

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] [OSX] hugin-mac-2009.2-RC1 for download

[Harry van der Wolf]

Hi Mac users,

I just published the new 32bit Hugin 2009.2-RC1 bundle. This is a release
candidate and may be declared final in the coming days.
See the Changelog: <
http://groups.google.com/group/hugin-ptx/browse_thread/thread/4f03311ffe435314
>

*Note: This build features the new Autopano generator options as built by
Thomas Modes and now ported to MacOSX to provide greater flexibility in
AutoCP generator options.*
It will make things a little more complicated, but gives you great
flexibility.

You need to copy the Hugin.app the way you always do: no changes there.
Download either or both the new "Hugin 2009 ControlPoint Generators". They
are just the old reliable panomatic and autopano-sift-c but not any longer
as plugins but as "naked" binaries. The Controlpoint.dmg's contain an
installer that copies the binary to the same directory where the plugins
resided.

When you start Hugin, go to preferences and to the "Control Point Detectors"
pane.
Here you can add panomatic and/or Autopano-SIFT-C. It is now possible to
create different configurations based on the same generator.

panomatic default parameters: -o %o %i
autopano-sift-c default parameters: --maxmatches %p %o %i
autopano-sift-c 120+ images: --maxmatches %p %o %s
For autopano-sift-c you might want to experiment with ransac: for fisheye
lenses don't use it. For normal lenses you might experiment by adding
"--ransac 1" to the parameters.

Note: Don't forget to set a "default" generator otherwise your assist panel
will no longer work.

Please test and give some feedback.

Information and binaries via my website
.
(The binaries itself are, as always, served from hugin.panotools.org who
kindly provide the disk space and bandwidth).

Hoi,
Harry

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Any free/open source tools to create QTVR/Cubic/Spherical Panorama

[Leo]

I stitched the panorama images by Hugin. But I need to convert it to
QTVR/Cubic/Spherical Panorama format. Any free/open source tools to
create QTVR/Cubic/Spherical Panorama to recommend?

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: svn 4450 hugin installer for Windows Vista

[Yuval Levy]

Thanks, Ad.

Ad Huikeshoven wrote:
> Last night I did build from scratch and got 4 fatal compile errors. This
> morning I build from scratch and got a new installer for hugin for Windows
> Vista, you can find at http://hugin.huikeshoven.org/

for all practical purposes, this is Hugin 2009.2.0_RC1. although the 
results differ from the results on OSX and on Linux depending on the 
dependencies (pun intended).

I admit that the spurious errors are worrying me. they may indicate 
problems in the build chain and thus in the quality of the result.


> As attachment I do include two files:

thanks, will look at them and integrate them in the SVN repository, with 
your notes.

> this one differs from the previous one
> I posted tweaked to compile a 2009.2 version

so if I understand correctly, this bat file is for 2009.2 and the 
previous one is for trunk? or are there also other changes?

Yuv

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: GSoC2008_masking

[Yuval Levy]

Carl von Einem wrote:
> I always prefer (if possible) to save masks as paths

me too.


>>  Original Message 
>> In any case, below is how I would integrate masking into my workflow. 
>> Please understand this is one case, and an example only.
>>
>> 1. capture images
>> 2. convert raw to tiff (or some other lossless format)
>> 3. load images into hugin
>> 4. load stored lens data, (crop circle and distortion params)
>> 5. create control points
>> 6. pairwise optimize to get rough position
>> 7. mask out problem/undesired areas.
>> 8. cleanup/tweak control points (reoptimizing as necessary)
>> 9. generate final output

I rather have 7 before 5, although it is an iterative process 
(especially if you want to consider positive masking as well).


>> Below is what I do now:
>>
>> 1. capture images
>> 2. convert raw to tiff (or some other lossless format)
>> 3. load images into gimp, mask out areas I don't want. (tripod, pano
>> head)
>> 4. load images into hugin
>> 5. load stored lens data, (crop circle and distortion params)
>> 6. create control points
>> 7. pairwise optimize to get rough position
>> 8. realize there are other places I want/need to mask out.
>> 9. Determine which images I need to edit mask by using the preview
>> window.
>> 10. save and exit hugin
>> 11. reload images into gimp and update the mask again
>> 12. load the previously saved project in hugin
>> 13. cleanup/tweak control points (reoptimizing as necessary)
>> 14. generate final output
>>

sounds very similar to what I do, although I don't doo pairwise 
optimization - I lay the images out roughly based on the shooting 
pattern. Probably pairwise CP detection and optimization would increase 
the speed and accuracy of my process if scripted/automated but I have 
not taken the time to do so - results are sufficient when detecting and 
optimizing the whole thing.


>> In this case, I thought adding the masking interface to the crop tab 
>> would be the best place, as one is attempting to acomplish basically the 
> 
> I'd prefer an interface for masking that can display two different
> images side by side, e.g. the CP editor tab. That way I can quickly
> decide which parts in one image are better that parts in another.

indeed, I think this is the reason why Fahim implemented it in preview 
mode - makes it easier to decide which parts in one image are better 
than parts in another; enable to deal with distortions at zenith and 
nadir (change the perspective / view to something convenient, do the 
masking; change it back) and enables positive masking (apply the mask's 
shape to all underlying images - in positive and negative as necessary).


>> Positive masking would be some what tricky since, as far as I know, the 
>> only way to guarantee an area of one image will definately appear is to 
>> apply a negative mask to all of the overlapping images of the area.  Is 
>> that correct?
> 
> You could also order the images in a different way (move up or down in
> images tab) which somehow makes a difference for enblend. I'd love to be
> able to control that behaviour better, e.g. by using positive masking.

image ordering is not as effective as proper positive masking - for 
which I also see "apply negative mask to all of the overlapping images 
of the area" as the only way to guarantee it, as Gerry stated.


>> Would a few people please give me some examples of how they would like 
>> to use masking within Hugin?
> 
> Today I often enough have to edit masks of images that are already
> loaded in a hugin project. To see the difference I need to newly load
> the whole project. I'd prefer a button in the preview window that allows
> to just reload all images (or maybe also just one).

keep them coming
Yuv

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Hugin&PT application & examples: Underwater photo-mosaic

[Oskar Sander]

> took some time to load, but here it was. What is the original resolution
> of the mosaic? in the PDF viewer I zoomed at 400%...
>

I belive this one was taken with a Nikon D300, but there has also been
experiments with framegrabbs from a HD video camera. The swim-by can be
easier with a videocam at times instead of DSLR if not an insane resolution
is required.  Myself I use only a stillcam setup, video is not for true
artist ;-)

Digital really is the way to go UW, the instant feedback on your photography
techique is what makes the whole difference and simplified post processing
as a bonus. Visibility like this [1] from 4 weeks ago in Narvik is rare if
not impossible in the Baltic unfortunately.

Part from the mosaic-application, I find taking "classic" mini panoramas on
freehand can be quite successful too when trying to capture a very wide
view, like [2] which was just three shots fired off without any special
thought on technique.


I have only used Hugin GUI so far, but I'd like to play around with the new
panotools implementation on tilt, so let's discuss how to test that (maybe
separate thread)



>
>
>
[1] http://www.dykarna.nu/fotoalbum/21774/259510.html
[2] http://www.dykarna.nu/fotoalbum/19221/259511.html

Cheers
/O

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: GSoC2008_masking

[Carl von Einem]

I always prefer (if possible) to save masks as paths, ideally in an
external file. Saving masks in 16 bit tiffs results in huge files...

Yuval Levy wrote:
> I think this excellent analysis and request for *user scenarios* belongs 
> in the public mailing list. This is an opportunity for users to help 
> shape up a feature.
> 
> Thank you, Gerry, Fahim and Daniel for this.
> 
> Yuv
> 
>  Original Message 
> From: Gerry Patterson
> 
> Hello All,
> 
> I have the maskeditor up and running.  It is a little unstable right 
> now, but I most of the segfaults are repeatable, meaning they should be 
> able to be worked out fairly quickly.  I have not had much luck with the 
> masking editor in the legacy preview window.  In the stand alone app I 
> have been able to load a stack of images and save off masks in tiff 
> format for each image. I created them with the PolyEd_Basic mode.  When 
> I tried loading remapped images from nona, the transparent areas are 
> filled with black. Fahim had mentioned this would happen.
> 
> So.
> 
> I am looking at this to scratch an itch.  I don't like having to load my 
> images into another program to edit the alpha channel.  My needs are 
> pretty basic as I had only considered negative masking and really just a 
> way to paint out certain areas before the remapping and blending.  So 
> one could consider that a use case.  I know there are others.
> 
> After watching the video linked to the gsoc2008_masking page [1][2].  I 
> remembered what this whole lazy snapping thing was.  It is very 
> impressive.  I haven't been able to get that working though in the stand 
> alone app.  Perhaps I am doing it wrong.
> 
> In any case, below is how I would integrate masking into my workflow. 
> Please understand this is one case, and an example only.
> 
> 1. capture images
> 2. convert raw to tiff (or some other lossless format)
> 3. load images into hugin
> 4. load stored lens data, (crop circle and distortion params)
> 5. create control points
> 6. pairwise optimize to get rough position
> 7. mask out problem/undesired areas.
> 8. cleanup/tweak control points (reoptimizing as necessary)
> 9. generate final output
> 
> Below is what I do now:
> 
> 1. capture images
> 2. convert raw to tiff (or some other lossless format)
> 3. load images into gimp, mask out areas I don't want. (tripod, pano
> head)
> 4. load images into hugin
> 5. load stored lens data, (crop circle and distortion params)
> 6. create control points
> 7. pairwise optimize to get rough position
> 8. realize there are other places I want/need to mask out.
> 9. Determine which images I need to edit mask by using the preview
> window.
> 10. save and exit hugin
> 11. reload images into gimp and update the mask again
> 12. load the previously saved project in hugin
> 13. cleanup/tweak control points (reoptimizing as necessary)
> 14. generate final output
> 
> In this case, I thought adding the masking interface to the crop tab 
> would be the best place, as one is attempting to acomplish basically the 

I'd prefer an interface for masking that can display two different
images side by side, e.g. the CP editor tab. That way I can quickly
decide which parts in one image are better that parts in another.

> same thing: remove undesired parts from the source image. Typically, I 
> would just want to paint in the mask with varying sizes of soft brushes. 
>   The segmentation lazy snapping would be cool but the hard edges 
> wouldn't be required as the blending should take care of things.
> 
> Positive masking would be some what tricky since, as far as I know, the 
> only way to guarantee an area of one image will definately appear is to 
> apply a negative mask to all of the overlapping images of the area.  Is 
> that correct?

You could also order the images in a different way (move up or down in
images tab) which somehow makes a difference for enblend. I'd love to be
able to control that behaviour better, e.g. by using positive masking.

> Would a few people please give me some examples of how they would like 
> to use masking within Hugin?

Today I often enough have to edit masks of images that are already
loaded in a hugin project. To see the difference I need to newly load
the whole project. I'd prefer a button in the preview window that allows
to just reload all images (or maybe also just one).

Carl

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~-

[hugin-ptx] Re: gsoc2009_deghosting call for testing

[Lukáš Jirkovský]

Hi Harry

2009/9/20 Harry van der Wolf :
> Hi,
>
> I've never worked with deghosting from Hugin and neither with HDR output. I
> really need some explanation. I have been googling already for some
> background information also but that's really scarce. Can someone point me
> to some info?

All the pto's in tarball should be prepared. First you need to check
in stitcher tab if both Remapped images is checked for both Exposure
fusion and HDR merging. Then you just run stitch. This should give a
bunch of images. Images with *.exr extensions are used for
hugin_hdrmerge and tiff images are used within deghosting_mask (but
you can also use .exr images here too).

For deghosting_mask run:
deghosting_masks input_images -i 5
where -i specify number of iterations, I suggest using about 5
iterations. It should give results good enough. Since it's quite slow
using more iterations is clueless.

for other options:
* if the masks doesn't mask part big enough to remove ghosting you can
try lower threshold (-t parameter)
* -a f should turn on computation similar to the old deghosting code
from hugin_hdrmerge
* if you try exr input here you can try using -a g, it seems to give
better results (maybe I'll make it default)
* if you want to see weights you can use -w w This will save weights
in you current directory. The darker area is the higher possibility
that it's "ghost" is.

For hugin_hdrmerge run:
hugin_hdrmerge -o foo.exr -m khan -i 5 input_images.exr
where -m khan enables deghosting code

The options are the same, only -w options doesn't work here.

How to interpret (and use) results:
hugin_hdrmerge:
just look at the output image. Ghosting artifacts shouldn't be present
or they should be at least reduced (compared to running hugin_hdrmerge
without -m khan).

deghosting_mask:
result shoud be bunch of b/w images. Then make sure they are in the
same directory as the input images to the deghosting_mask and use use
enfuse-mask (from Panotools::scripts):
enfuse-mask input_files // note: do not specify the masks

Resulting image should have ghosting removed or at least reduced.

> Can I somewhere specify options for hugin_hdrmerge? If I need to do that on
> the command line it's not much use for MacOSX users using the bundle, and
> probably the same for Windows users (but that's a wild guess).
> (I have a bundle ready for distribution but that's not useful if you can't
> set options from the Gui).

Yep, it's command line. It seems that I need to add some switch to GUI
to easily enable it. I guess that it will take some time, because GUI
toolkits are not my friends.

>
> I do get "mask like" images instead of nicely merged images when running
> hugin_hdrmerge from the command line, but actually I'm really clueless.
>
> If the Tux images set functions best, a simple "hugin_hdrmerge for dummies"
> based on this set would be useful and highly appreciated (unless I'm the
> only dummy off course).
>
> Harry
>
>
> 2009/9/20 Lukáš Jirkovský 
>>
>> Hi all,
>> I've created small compilation. All should contain some artifacts.
>> With the files from folders Kyjov and Tanum the algorithm fails quite
>> badly :-| because the ghosting is in smaller details.
>>
>> All folders contain input images and hdr.pto for remapping images to
>> both HDR and LDR (to save bandwidth). The archive (22MB) can be
>> downloaded from:
>> http://blender6xx.ic.cz/pub/HDR.tar.bz2
>>
>> I've also tried images from:
>> http://hugindeghosting.blogspot.com/
>> http://graphics.cs.ucf.edu/ekhan/project_ghost.htm
>>
>> regards,
>> Lukáš
>>
>>
>
>
> >
>
I hope I've not missed something. If you have any other questions feel
free to ask them.

Lukas

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Aerial Photography Stitching

[Lukáš Jirkovský]

Hi Matt

2009/9/21 Matt Williams :
>
> Hi guys, I've only recently discovered Hugin so I'm still getting used
> to it so bear in mind that there's probably still plenty I'm missing.
>
> I'm a mapper for OpenStreetMap (http://openstreetmap.org), a project
> to create a free map of the world. Recently someone sponsored a round
> of amateur aerial photography of the area around the town of Stratford-
> upon-Avon in the UK. We now have the full set of aerial imagery
> (around 900 photos) of the whole town from various directions and at
> various angles to the vertical. You can see a summary of the data at
> http://milliams.com/verticalitymetre/stats.php and
> http://milliams.com/verticalitymetre/map.html (where a low number
> score is more vertical).
>
> Now, we've got to the stage where we would like to be able to rectify
> this imagery to the map and stitch all this imagery together in a
> mostly seamless way. Perhaps Hugin/Panorama Tools isn't really what I
> should be using for this but it's so close to doing what we need, I'd
> be surprised if it couldn't be coerced into shape.
>
> The method I've been using so far (and I've only done a few small
> tests with it, nothing large scale) is based on 
> http://www.dojoe.net/tutorials/linear-pano/
> and is to select a few (that's only 2 or 3 so far) overlapping images
> which are very nearly vertical, add them to Hugin and deselect the
> 'Image Center Shift' link for the lens. I've autopano-sift'd them to
> add control points. Then, I've added a png of a map image (from
> openstreetmap) as the first image, set a different lens number for it
> (made up a DoV of about 10 degrees) and set it as the position anchor.
> Then I've manually added control points (by hand) between each of the
> images and the map in order to try to coerce Hugin to align the images
> to the map.
>
> I then enblend the remapped images together (excluding the map png)
> and upload it to http://warper.geothings.net/ which is our map warper
> for aligning it to the map. This allows me to slightly tweak the
> rectification to make it match the map more closely. This mostly works
> for small image clusters but I am ofter getting divergence from the
> map at the edge of the image.
>
> What I would like to ask is whether anyone has any experience with
> this sort of work and has some suggestions about the best way to do it
> or if Hugin/Panorama Tools really isn't suitable for the job. I've
> looked through a paper published on this topic at
> http://www.cc.gatech.edu/~pesti/pubs/mapstitcher.pdf and it seems to
> suggest the best results are achieved when doing the stitching and
> ortho-rectification (and map alignment) at the same time to avoid
> cumulative errors (as seen at 
> http://warper.geothings.net/uploads/1315/original/test3.jpg,
> that main road should be almost straight).
>
> Thoughts/suggestions/revelations?
>
> Regards,
> Matt Williams
> http://milliams.com
>
> >
>

First, there are some new tilt options to the panorama tools (Tx, Ty,
Tz and Ts) but doesn't use them yet.

I'd try to load map into hugin and manually add control points to
photos and corresponding parts of map. Then optimize with map set as
anchor image. This would hopefully transform images to fit map
directly in hugin. And for stitching I'de disable the map so it
doesn't blend with photos by coincidence.

Anyway, interesting project.

regards,
Lukas

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Tilt transformation...

[Oskar Sander]

Dmg,

If I am running an optimization using Autooptimize using the new Tilt
parameters in the new panotools version, what is the parameter syntax in the
pto-file?

Cheers
/O

2009/9/11 Oskar Sander 

>
>
> 2009/9/10 dmg 
>
>>
>> to be honest, I am not sure how much they will help for a mosaic. The
>> model for panos in libpano
>> is still spherical. But it is a matter of trying.
>>
>> scale scales the tilt operations only. It actually scales the view
>> point from which the photo was originally taken.
>>
>> --dmg
>>
>>
>>
>
> Well, one major problem when "fudging" mosaics currently in Hugin without
> Dev's addition. Is that yaw, pitch and x,y are not independent of the lens
> distortion model and the panoramic node(what do you call it?).  Which means
> that the mosaic quickly gets FU  because:
>1 Slightest camera tilt causes distortion that cannot be handled by
> yaw or pitch, as these are applied in the sphere center, not the translated
> camera position (x,y) and
>2. any x, y translation will move the image from the center within
> the distortion model and may give horrific results as obviously distortion
> center in the case of the mosaic application is in the center of each camera
> viewpoint
>
> In my mind, your addition solves both of these issues, by optimizing your
> new parameters instead of y,p,x,y.
>
>
> Then the panosphere issue would be interesting to discuss. It could maybe
> overcome if you see each camera position as being closer to the sphere's
> surface and the final panoramic viewpoint further back...
>
>
> Cheers
> /O
>
>
>
>
>
>
>


-- 
/O

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Integration Queue - current status

[Yuval Levy]

Bruno Postle wrote:
> On Sun 20-Sep-2009 at 21:34 -0400, Yuval Levy wrote:
>> Bruno Postle wrote:
>>> I think in general if there is nothing major broken in the trunk,
>>> and a stable release branch is still going through the beta/rc
>>> steps, then this is an indication that something new should go into
>>> the trunk.
>> this is so obvious I have not even thought of it. Shouldn't it be an
>> impossible situation?
> 
> It's how I would describe the current situation, acceptable amounts 
> of not-brokenness are different for a stable branch.
> 
> e.g. the stable branch doesn't have complete translations, 
> release-notes or online manual, but these are irrelevant for the 
> trunk.

to go with the (SVN) tree metaphor: developers are like water - they are 
free to flow wherever they want. I can't control them.

the intended course of life for a stable branch is that it is spawned 
from trunk, grows more polished and solid and eventually blooms into a 
final release.

however if a stable branch does not attract enough water, it dries out 
without blooming. abandoned at some stage of the beta/rc process - 
simply because there was not enough interest for a release.

in that sense, you're right: add something new to trunk if there is 
nothing major broken in it. I got caught by my sense of duty / ownership 
toward 2009.2

if trunk attracts more water than the stable branch, the stable branch 
can dry out without achieving final release status.

Yuv

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Integration Queue - current status

[Bruno Postle]

On Sun 20-Sep-2009 at 21:34 -0400, Yuval Levy wrote:
>Bruno Postle wrote:
>> I think in general if there is nothing major broken in the trunk,
>> and a stable release branch is still going through the beta/rc
>> steps, then this is an indication that something new should go into
>> the trunk.
>
>this is so obvious I have not even thought of it. Shouldn't it be an
>impossible situation?

It's how I would describe the current situation, acceptable amounts 
of not-brokenness are different for a stable branch.

e.g. the stable branch doesn't have complete translations, 
release-notes or online manual, but these are irrelevant for the 
trunk.

-- 
Bruno

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Aerial Photography Stitching

[Matt Williams]

Hi guys, I've only recently discovered Hugin so I'm still getting used
to it so bear in mind that there's probably still plenty I'm missing.

I'm a mapper for OpenStreetMap (http://openstreetmap.org), a project
to create a free map of the world. Recently someone sponsored a round
of amateur aerial photography of the area around the town of Stratford-
upon-Avon in the UK. We now have the full set of aerial imagery
(around 900 photos) of the whole town from various directions and at
various angles to the vertical. You can see a summary of the data at
http://milliams.com/verticalitymetre/stats.php and
http://milliams.com/verticalitymetre/map.html (where a low number
score is more vertical).

Now, we've got to the stage where we would like to be able to rectify
this imagery to the map and stitch all this imagery together in a
mostly seamless way. Perhaps Hugin/Panorama Tools isn't really what I
should be using for this but it's so close to doing what we need, I'd
be surprised if it couldn't be coerced into shape.

The method I've been using so far (and I've only done a few small
tests with it, nothing large scale) is based on 
http://www.dojoe.net/tutorials/linear-pano/
and is to select a few (that's only 2 or 3 so far) overlapping images
which are very nearly vertical, add them to Hugin and deselect the
'Image Center Shift' link for the lens. I've autopano-sift'd them to
add control points. Then, I've added a png of a map image (from
openstreetmap) as the first image, set a different lens number for it
(made up a DoV of about 10 degrees) and set it as the position anchor.
Then I've manually added control points (by hand) between each of the
images and the map in order to try to coerce Hugin to align the images
to the map.

I then enblend the remapped images together (excluding the map png)
and upload it to http://warper.geothings.net/ which is our map warper
for aligning it to the map. This allows me to slightly tweak the
rectification to make it match the map more closely. This mostly works
for small image clusters but I am ofter getting divergence from the
map at the edge of the image.

What I would like to ask is whether anyone has any experience with
this sort of work and has some suggestions about the best way to do it
or if Hugin/Panorama Tools really isn't suitable for the job. I've
looked through a paper published on this topic at
http://www.cc.gatech.edu/~pesti/pubs/mapstitcher.pdf and it seems to
suggest the best results are achieved when doing the stitching and
ortho-rectification (and map alignment) at the same time to avoid
cumulative errors (as seen at 
http://warper.geothings.net/uploads/1315/original/test3.jpg,
that main road should be almost straight).

Thoughts/suggestions/revelations?

Regards,
Matt Williams
http://milliams.com

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Picasa button for Hugin on Mac

[rafm]

Hi,

I tried to make a Picasa Hugin button for Mac by modifying Jacob's
button for Windows:

http://jacob.hoffman-andrews.com/hacks/hugin-picasa-button.html

The button gets installed, properly starts Hugin, but Hugin crashes
soon after starting. The most probable reason is that Hugin tries to
load the first image as a project file rather than adding them to the
current (or better new) project. The status line shows "Opening
project: ...jpg" Is it possible to change this behaviour on Mac so it
is possible to make a Picasa button? That would be a really great
thing!

Crash report attached below.

Thanks,

Rafal


Process: Hugin [2024]
Path:/Applications/Hugin.app/Contents/MacOS/Hugin
Identifier:  net.sourceforge.hugin.Hugin
Version: 0.8.0 ()
Code Type:   X86 (Native)
Parent Process:  launchd [94]

Date/Time:   2009-09-20 16:13:51.223 -0700
OS Version:  Mac OS X 10.6.1 (10B504)
Report Version:  6

Interval Since Last Report:  284803 sec
Crashes Since Last Report:   109
Per-App Interval Since Last Report:  8658 sec
Per-App Crashes Since Last Report:   4
Anonymous UUID:  E2D87819-E944-4D15-
A1A6-04A42740890A

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib   0x92d85912 __kill + 10
1   libSystem.B.dylib   0x92d85904 kill$UNIX2003 + 32
2   libSystem.B.dylib   0x92e18b99 raise + 26
3   libSystem.B.dylib   0x92e2ec50 abort + 93
4   net.sourceforge.hugin.base_wx   0x0139c77d 0xdf2000 + 5941117
5   net.sourceforge.hugin.base_wx   0x012c204e
HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&,
std::string const&) + 8974
6   net.sourceforge.hugin.Hugin 0x000f7837
PT::wxLoadPTProjectCmd::execute() + 151
7   net.sourceforge.hugin.Hugin 0x00029968
CommandHistory::addCommand(AppBase::Command*, bool) + 472
8   net.sourceforge.hugin.Hugin 0x000aba23
MainFrame::LoadProjectFile(wxString const&) + 1587
9   net.sourceforge.hugin.Hugin 0x00086b5f huginApp::OnInit() +
9535
10  net.sourceforge.hugin.Hugin 0x000891e1 wxAppConsole::CallOnInit
() + 17
11  libwx_macu-2.8.0.5.0.dylib  0x004ee76a wxEntry(int&, wchar_t**)
+ 58
12  net.sourceforge.hugin.Hugin 0x00082f58 main + 24
13  net.sourceforge.hugin.Hugin 0x2362 start + 258
14  net.sourceforge.hugin.Hugin 0x2289 start + 41

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib   0x92d4b03a kevent + 10
1   libSystem.B.dylib   0x92d4b768 _dispatch_mgr_invoke +
215
2   libSystem.B.dylib   0x92d4abf9 _dispatch_queue_invoke +
183
3   libSystem.B.dylib   0x92d4a98a _dispatch_worker_thread2
+ 234
4   libSystem.B.dylib   0x92d4a401 _pthread_wqthread + 390
5   libSystem.B.dylib   0x92d4a246 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib   0x92d4a092 __workq_kernreturn + 10
1   libSystem.B.dylib   0x92d4a628 _pthread_wqthread + 941
2   libSystem.B.dylib   0x92d4a246 start_wqthread + 30

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x  ebx: 0x92e2ebff  ecx: 0xbfffdb1c  edx: 0x92d85912
  edi: 0x0009  esi: 0xa0492b10  ebp: 0xbfffdb38  esp: 0xbfffdb1c
   ss: 0x001f  efl: 0x0282  eip: 0x92d85912   cs: 0x0007
   ds: 0x001f   es: 0x001f   fs: 0x   gs: 0x0037
  cr2: 0xa0783000

Binary Images:
0x1000 -   0x2c3ffb +net.sourceforge.hugin.Hugin 0.8.0 ()
<93AD2905-5671-5A08-4D8E-7BA422FDF0D2> /Applications/Hugin.app/
Contents/MacOS/Hugin
  0x3ab000 -   0x3abff7  libmx.A.dylib ??? (???) <01401BF8-3FC7-19CF-
ACCE-0F292BFD2F25> /usr/lib/libmx.A.dylib
  0x3ae000 -   0x406ff4 +libpano13.dylib ??? (???) <2C6830D4-F2AB-
F8C0-2EF7-D0AA4E6C7208> /Applications/Hugin.app/Contents/Libraries/
libpano13.dylib
  0x41 -   0x42fffb +libpng.3.1.2.38.dylib ??? (???)  /Applications/Hugin.app/Contents/
Libraries/libpng.3.1.2.38.dylib
  0x437000 -   0x483fef +libtiff.3.dylib ??? (???)  /Applications/Hugin.app/Contents/
Libraries/libtiff.3.dylib
  0x48b000 -   0x4a7ff3 +libjpeg.62.0.0.dylib ??? (???) /Applications/
Hugin.app/Contents/Libraries/libjpeg.62.0.0.dylib
  0x4ac000 -   0x996ff7 +libwx_macu-2.8.0.5.0.dylib ??? (???)
<4829F5C7-D09B-23EF-871C-46AAF032CFD4> /Applications/Hugin.app/
Contents/Libraries/libwx_macu-2.8.0.5.0.dylib
  0xc2a000 -   0xc32ff3 +libIex.6.0.0.dylib ??? (???) /Applications/
Hugin.app/Contents/Libraries/libIex.6.0.0.dylib
  0xc3d000 -   0xccffef +libIlmImf.6.0.0.dylib ??? (???)
<8039728F-05DC-A40D-6AE7-993633D0E650> /Applications/Hugin.app/
Contents/Libraries/libIlmImf.6.

[hugin-ptx] Re: Missing files in creatin doc's in enblend

[cspiel]

Kornel -

I sent you an email with the info
concerning my latest changes.  Breakage
is expected.


On Sep 21, 8:49 am, Kornel Benko  wrote:
> the first one is maybe a typo
> versenblend.texi <-> varsenblend.texi

SIC.  See rev6b57666aa217.

> the second is really missing:
> config-h.texi

See rev256fc64fe72b.


> texi2dvi: Creating /usr/BUILD/BuildEnblend/doc/enblend.pdf from 
> /usr/src/enblend/enblend/doc/enblend.texi
> [ 57%] cd /usr/BUILD/BuildEnblend/doc && 
> /usr/local/texlive/2008/bin/x86_64-linux/makeinfo 
> --css-include=/usr/src/enblend/enblend/doc/default.css -I 
> /usr/src/enblend/enblend/doc -o /usr/BUILD/BuildEnblend/doc/enblend.info 
> /usr/src/enblend/enblend/doc/enblend.texi
>
> /usr/src/enblend/enblend/doc/enblend.texi:14: @include `varsenblend.texi': No 
> such file or directory.
> /usr/src/enblend/enblend/doc/enblend.texi:14: @include `config-h.texi': No 
> such file or directory.

You build with CMake, which must fail
after the changes stated above.  Autotool's
configure(1) works ok.


/Chris

--~--~-~--~~~---~--~~
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---