[hugin-ptx] Cmake files upgrading to ubuntu 11.4

[Kornel Benko]

Finaly I upgraded. I changed the cmake-build accordingly, hopefully
other platforms are not affected.

Kornel

-- 
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

Re: [hugin-ptx] Re: Finding control points for many images

[Yuval Levy]

On May 23, 2011 02:43:44 AM kfj wrote:
> On 23 Mai, 00:50, Yuval Levy  wrote:
> > If there was a button to trigger cpfind on the cp tab, this
> > would be an easy way to waste some time clicking away...
> > ... but I can also try to script this in python, can I?
> 
> I very much hope that you can not only try but even succeed in doing
> so ;-)

not tonight, but i will want to write a small iterator that runs cpfind and 
adds point to the project for a pair of images.


> > we need a list of functionalities already available; a todo-list of
> > functionality to expose next; a how-to for doing it.
> 
> The easiest route is the one I took in hsi/hpi, which is basically
> wrapping the C++ headers. This takes little effort - if you look at
> hsi.i, the interface definition, it isn't large at all, and not very
> complicated either. The problem with this approach is that the
> resulting python module is precisely as difficult to grasp as the C++
> header itself. The objects are the same, the methods are, and if you
> dont know what they do in C++, being able to access them from Python
> doesn't help. If the wrapped C++ code is well-evolved and high-level,
> with teling names - and what I found in hugin usually was like that -
> your Python module is valuable, otherwise you have to put in more
> work.

understand.  so which headers would be next on the list of desirable but not 
yet added to hsi.i ?

Yuv


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

Re: [hugin-ptx] 4 GoPro camera street view need help

[Yuval Levy]

On May 23, 2011 11:35:43 PM Gnome Nomad wrote:
> GPS for location.

with a resolution of a few mm to determine the exact place of the NPP? on a 
moving vehicle?  I am no GPS expert but I doubt it is feasible.

Yuv


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

Re: [hugin-ptx] Re: hugin plugin interface - developers please liaise

[Yuval Levy]

On May 23, 2011 04:08:04 AM kfj wrote:
> This probably does the trick:

thank you.  getting nearer.  let's iterate once more.

 
> hsi/hpi for hugin is optional. It has to be compiled into hugin. This
> is done by defining BUILD_HSI=ON in the cmake command that sets up the
> code generation. Inside hugin's C++ code, there are some #defines that
> are relevant only for hsi/hpi:

this is already taken care of in the building instruction.

think of me as somebody who wants to expose more functionality to HSI.

The first thing is to include the header in /src/hugin_script_interface/hsi.i

right?

 
> HUGIN_HSI - this is defined globally if hsi/hpi capability has been
> switched on. It is used to introduce code which is hsi/hpi-specific
> into files which are also part of 'plain' hugin

so if I have to add extra code, I will put it inside an #ifdef HUGIN_HSI?  
what are the situations you encountered when you had to add extra code?

  find . -exec grep -l HUGIN_HSI {} \;

found it only in five files (three of them headers files)

in MainFrame.cpp/.h this is "just" the extra menu entry and in 
wxPanoCommand.cpp/.h it is "just" to run the Python command.

the really relevant changes are in panodata/PanoramaVariable.h and from your 
well commented code I understand (correct me if I am wrong) that the reason 
for the slightly different class declaration is that SWIG requires an explicit 
default constructor?



> SWIG - this is only defined when code is processed by SWIG. It's used
> to hide code from SWIG which it can't handle.

  find . -exec grep -l SWIG {} \;

found it inside hugin_script_interface (obvious?) and inside seven header 
files in /src/hugin_base/panodata, although most of them are false positive 
(SWIG is in a comment).  Again, your comment make it clear.

so if after adding a header to hsi.i some parts of it are not digested by 
SWIG, or if there is no point in exposing them, I can use this to hide them? 


> _HSI_IGNORE_SECTION - this is only defined during the separate C-
> preprocessing of certain hugin header files which use a technique
> dubbed 'lazy metaprogramming' which SWIG can't handle. Preprocessing
> 'flattens' the files - it pulls in all code that is #included by them.
> Most of the code pulled in this way mustn't be wrapped by SWIG, so it
> is switched off via #ifndef _HSI_IGNORE_SECTION.

by now my brain is frying.  it does not help that it is close to midnight.

I see three instances of this and maybe I am generalizing, but isn't this 
simply:  all headers included in a headers are wrapped in HSI_IGNORE_SECTION 
because SWIG can't handle them?  and they are anyway fed into SWIG by being 
listed in hsi.i ?


and now the jackpot question:  what would be the next header file (or set of 
header files) that given enough resources and time  you would like to see 
added to hsi.i?

I better go to sleep now.

Yuv


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

Re: [hugin-ptx] 4 GoPro camera street view need help

[Gnome Nomad]

Yuval Levy wrote:

On May 23, 2011 04:30:27 PM Bruno Postle wrote:

I've often thought that the way to do a camera-on-a-car panorama rig
is to space the cameras out in a line instead of trying (and
failing) to put them all in the same place.  Then when you are
driving around you shoot a panorama by firing the shutters in
sequence such that each photo is taken from exactly the same
location.


if you have not done it yet, you should patent this idea ;-)

although in practical term it is a challenge to measure speed and synchronize 
time to trigger each camera's shutter precisely at the right moment.


GPS for location. And timing?

--
Gnome Nomad
gnomeno...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/

--
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

Re: [hugin-ptx] 4 GoPro camera street view need help

[Yuval Levy]

On May 23, 2011 04:30:27 PM Bruno Postle wrote:
> I've often thought that the way to do a camera-on-a-car panorama rig
> is to space the cameras out in a line instead of trying (and
> failing) to put them all in the same place.  Then when you are
> driving around you shoot a panorama by firing the shutters in
> sequence such that each photo is taken from exactly the same
> location.

if you have not done it yet, you should patent this idea ;-)

although in practical term it is a challenge to measure speed and synchronize 
time to trigger each camera's shutter precisely at the right moment.


> The result would be zero parallax errors, but there would
> be new errors with peoples and moving objects.

There is enough space to fit six cameras (rather than four) on the roof of a 
car, which should give enough leeway to generate sufficient overlap to cover 
for most moving objects.  Then the problem is determining the optimal seam 
lines...

> You would need some
> way to synchronise the shutters and the speed of the car, but there
> are no doubt plenty of ways of doing this.

maybe not a timer / spedomeeter then.  if a helper vehicle could stand still 
for the time that the 4-6 cameras pass through the NPP, it could beam a 
synchronizing laser that would trigger each camera when it is on the right 
spot.  So this helper vehicle would move forward to beam the laser for the 
next shooting position, stop, wait for all cameras on the camera vehicle to 
cross the beam, then move on to the next position and repeat.

Yuv


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

Re: [hugin-ptx] Smartblend wrapper doesn't work in Hugin 2011.0 RC1

[Yuval Levy]

On May 23, 2011 01:51:33 PM Henk Tijdink wrote:
> Stitching goes on, but no output file created.
> No Hugin crash with a logfile.

can you post the output of Hugin to your bug report [0] please?


> When comparing *pto.mk between version 2010.4 and 2011.0 I find that
> extra info is added by EXIF tools in version 2011..0.
> For example software: Hugin2011.0 build by Matthew Petrov, projection,
> etc.
> Could that be the cause or is it something else?

unlikely.  i've pointed to some likely causes and how to diagnose them on your 
bug tracker ticket.

Yuv

[0] https://bugs.launchpad.net/hugin/+bug/787075


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

Re: [hugin-ptx] Re: Hugin-2011.0.0_rc1 released

[Yuval Levy]

On May 23, 2011 01:19:08 PM kfj wrote:
> On 23 Mai, 14:40, Yuval Levy  wrote:
> > Scripts now run with limited feedback/interaction on Linux and Windows
> > (thanks to Thomas)
> 
> Would you be so kind as to elaborate on this?

I read in your notes that Thomas made it work on Windows?

Of course you are the initiator and original author and "only" mentioning you 
as our "resident Python wizard" in the next paragraph is not enough.  Should 
have mentioned your name next to Linux above.  Apology for the omission.

Yuv


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

Re: [hugin-ptx] Re: Hugin-2011.0.0_rc1 released

[David Haberthür]

On 23.05.2011, at 14:40, Yuval Levy wrote:

> What are Apple's policies and schedules regarding EOL of their systems?

As far as I know, Apple "officially" supports two versions back, this would 
currently mean down to 10.4. But there's no real EOL for their systems, or more 
precisely, there's an EOL only for hardware.

If I remember correctly, for 10.7 (Lion), support for non-Intel processors will 
be dropped, but that's another story.

Habi

-- 
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

Re: [hugin-ptx] Re: Hugin-2011.0.0_rc1 released

[David Haberthür]

Ciao Harry.

[snip]

>> I've loaded six images and pressed "Align". Then I've seen the Message in 
>> the attached screenshot (Screenshot at 17.21.24) and the assistant didn't 
>> work and refused to find any control points in the same six images shown 
>> above.

[snip]

> I'm really surprised and ashamed. This is definitely not the RC1 but an older 
> test build. I have absolutely no idea how this happened: wrong build folder 
> to copy from, wrong target folder to copy to, wrong dmg created.

Don't be ashamed! This is the reason we have testers, I hope. Your updated 
build behaves like intended, the Assistant (and everything else) works fine. 
Thanks for being so quick!

Habi

-- 
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

Re: [hugin-ptx] hugin under auto exposure?

[Bruno Postle]

On Mon 23-May-2011 at 13:20 +0100, paul womack wrote:


I would like to try the following variation; each photograph is 
exposure corrected to HDR, and the resulting HDR images seam 
blended into a single HDR image.


I'm assuming seam blending works correctly in HDR :-)

I would then (probably) like to use enfuse as a tonemapper, by 
creating synthetic LDR exposures at various light levels from the 
HDR, but this would be post processing of the HDR panaorama, 
outside Hugin.


This is the tricky bit, you need a good way to extract 'photos' with 
a credible response curve from HDR images.


However you don't need to do this.  Create a normal project, making 
sure you optimise Exposure and Camera Response, stitch it using the 
default global EV.  Then stitch two more versions, one with the 
global EV raised by one stop and the other lowered by one stop.


(You can change the global EV with the spinner in the Preview tab of 
the Preview window)


Then fuse these three images with enfuse on the command-line.

--
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

Re: [hugin-ptx] Re: creating stacks from exposure brackets

[Bruno Postle]

On Mon 23-May-2011 at 02:47 -0700, kfj wrote:

On 22 Mai, 23:26, Bruno Postle  wrote:

On Sun 22-May-2011 at 04:09 -0700, kfj wrote:

> I have a problem with panoramas with stacks. When I load a bunch
> of images, each image is in a separate stack. Is there a way to
> tell hugin to put groups of N images into stacks instead of
> assigning the stacks manually, or is someone working on such a
> feature? If not, I might write a plugin.

Assuming you want to use the Hugin feature that 'links' the
positions of photos within the stack - i.e. you have a good tripod
and don't need to optimise the photos within the stack separately.


Actually my stacks aren't done with a tripod, so they need alignment
within the stacks.


Then you don't need to tell Hugin about your stacks, the 'Cpfind 
(multirow/stacked)' control point generator can detect stacks by 
looking at the EXIF, and will split the job into cpfind bits and 
align_image_stack bits automatically.


..at least I think so, this feature was migrated from match-n-shift 
where the stacks are identified automatically.


--
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

Re: [hugin-ptx] 4 GoPro camera street view need help

[Bruno Postle]

On Sun 22-May-2011 at 20:36 -0300, Jim Watters wrote:

On 2011-05-20 2:35 PM, Felix wrote:

Hi, I DIY my street view system like http://www.diy-streetview.org/.
It's use 4 GoPro camera shot image.

I find it is hard to stitch panoramic image perfectly with these way.
Maybe with 4 camera, so 4 different nodal point.


With four of these cameras around there is only a small amount of 
overlap to join the cameras.


I've often thought that the way to do a camera-on-a-car panorama rig 
is to space the cameras out in a line instead of trying (and 
failing) to put them all in the same place.  Then when you are 
driving around you shoot a panorama by firing the shutters in 
sequence such that each photo is taken from exactly the same 
location.  The result would be zero parallax errors, but there would 
be new errors with people and moving objects.  You would need some 
way to synchronise the shutters and the speed of the car, but there 
are no doubt plenty of ways of doing this.


--
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] Smartblend wrapper doesn't work in Hugin 2011.0 RC1

[Henk Tijdink]

Till version 2010.4 of Hugin smartblend worked with the wrapper with
some glitches.(output upside down).
Tested it in Hugin 2011,0 RC1. (downloaded it from sourceforge M.
Petrov build).
Now during stitching smartblend gives an error, DEVIL.dll can't read
file. Stitching goes on, but no output file created.
No Hugin crash with a logfile.
When comparing *pto.mk between version 2010.4 and 2011.0 I find that
extra info is added by EXIF tools in version 2011..0.
For example software: Hugin2011.0 build by Matthew Petrov, projection,
etc.
Could that be the cause or is it something else?
Filed a bug in Launchpad.
System windows XP SP3 32 bits.

Kind regards,
Henk Tijdink

-- 
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-2011.0.0_rc1 released

[kfj]

On 23 Mai, 14:40, Yuval Levy  wrote:

> Scripts now run with limited feedback/interaction on Linux and Windows (thanks
> to Thomas)

Would you be so kind as to elaborate on this?

Kay

-- 
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

Re: [hugin-ptx] Re: Hugin-2011.0.0_rc1 released

[Yuval Levy]

Hoi Harry,

On May 23, 2011 01:42:48 AM Harry van der Wolf wrote:
> Yes, please wait a few days.

OK.  Since there is no negative feedback from any other platform, may I leave 
you the task (or honour?) to declare 2011.0.0 final?

The instructions are at [0], the release notes on the website [1] and in the 
repository [2] are ready (translators are welcome) and if you need help you 
can ask me.


> I assume it will be OK apart from the
> stitching error on 10.5 Leopard (18-19% of the users) which still requires
> the work around to push the project to PTBatcherGui. It does work on 10.4
> and 10.6. We've tried so much options and nothing works. I'm afraid it
> will remain a "known bug"  for this release.

Thanks for your efforts.  It is sad to leave users behind, even if it is a 
small group and only temporary, but as a great rock star once sung, the show 
must go on and many more users are looking forward for the improvement and new 
features that are waiting to be released.

We will be leaving more users behind:  Ubuntu Karmic (9.10) has reached EOL.  
Other Linux distros have similar support policies and with every new release 
we try to add support to the newest distributions and leave behind obsolete 
ones.

The elephant in the room in this respect is Windows XP.  April 2014 [3].

What are Apple's policies and schedules regarding EOL of their systems?

 
> > I would like to close 2011.0.0 and move on to 2011.2.0 - pythong
> > scripting.
> 
> Yes. That will be the next challenge: to get it working on OSX.

Sorry for the "challenges overload".  There are so many trade offs trying to 
balance the different constituencies that make our community and OSX users 
tend to be on the short end of the trade offs too many times.  It is not 
always easy to strike a reasonable balance, but we must do with the 
circumstances and available resources.  The python scripting feature will rock 
the boat for the foreseable future.

Scripts now run with limited feedback/interaction on Linux and Windows (thanks 
to Thomas), but the really cool, interactive features are for now successfully 
tested only on Ubuntu Linux (thanks to our resident Python wizard Kay).

The challenge will be to enable bleeding edge creativity and empower 
developers, like this project has done consistently for the past five years, 
without leaving too many users behind because of the technical challenges that 
come with living on the bleeding edge.

It is possible that the 2011.2.0 release cycle will be an extended one like 
2011.0.0 in an attempt to fix show stoppers on plattforms that are late to the 
game / don't have many developers available; or that it will ship with an even 
longer list of known issues and exceptions.


> Thanks for your ongoing support to get a new release out.

It's a team effort and you deserve credits for your ongoing support in getting 
the new release out to Mac users as well.

Yuv


[0] 
http://wiki.panotools.org/Development_of_Open_Source_tools#Declare_a_Release_Final
[1] http://hugin.sourceforge.net/releases/2011.0.0/en.shtml
[2] /doc/releases/hugin-2011.0.0_rc1.txt
[3] http://windows.microsoft.com/en-us/windows/products/lifecycle?T1=winxp


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

Re: [hugin-ptx] Re: Hugin-2011.0.0_rc1 released

[Allan Seidel]

Perhaps these have been mentioned before. I am seeing problems in the
Control Points tab. For example when starting to pick a point on the left
side image a duplicate version of that image appears at the bottom of the
frame and the right image enlarges a bit, overflowing the original space
allocated for that image. Also, the operation to move a control point is not
usable. The point does not appear to move.

Allan

On Mon, May 23, 2011 at 12:42 AM, Harry van der Wolf wrote:

> Hi, Yuv,
>
> 2011/5/22 Yuval Levy 
>
>> On May 22, 2011 12:32:43 PM Harry van der Wolf wrote:
>> > As always: Information and binaries via my website
>> > <
>> http://panorama.dyndns.org/index.php?lang=en&subject=Hugin&texttag=Hugin
>> >.
>> > (The binaries themselves are served from hugin.panotools.org who kindly
>> > provide the disk space and bandwidth).
>>
>> should we wait a few days for test reports about this binary before
>> declaring
>> 2011.0.0 final?
>>
>>
> Yes, please wait a few days. I assume it will be OK apart from the
> stitching error on 10.5 Leopard (18-19% of the users) which still requires
> the work around to push the project to PTBatcherGui. It does work on 10.4
> and 10.6. We've tried so much options and nothing works. I'm afraid it will
> remain a "known bug"  for this release.
>
>
>> so far there have been no negative reports from other platforms.
>>
>> I would like to close 2011.0.0 and move on to 2011.2.0 - python scripting.
>>
>>
> Yes. That will be the next challenge: to get it working on OSX.
>
>
>> Thanks
>> Yuv
>>
>
> Thanks for your ongoing support to get a new release out.
>
> best,
>
> 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
>

-- 
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

Re: [hugin-ptx] hugin under auto exposure?

[paul womack]

paul womack wrote:


So - can anyone advise me how to proceed, what options
(of the increasing range...) I need to set?


I guess system/hugin information might be helpful:

Operating System: Linux 2.6.34.8-68.fc13.x86_64 x86_64
Architecture: 64 bit
Free memory: 2186568 kiB

Hugin
Version: 2011.0.0.6e53c8840ae5
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/

 BugBear

--
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] hugin under auto exposure?

[paul womack]

I've read this page:

http://hugin.sourceforge.net/tutorials/auto-exposure/en.shtml
(last Updated April 2010)

The tutorial says:

"Exposure fusion - > Blended and fused panorama output option. This uses
a two step process, first images with a similar exposure (within a 0.5EV range)
are seam blended together with no exposure correction, then these blended
layers are exposure fused into the final panorama result:"

I would like to try the following variation;
each photograph is exposure corrected to HDR,
and the resulting HDR images seam blended into a single HDR image.

I'm assuming seam blending works correctly
in HDR :-)

I would then (probably) like to use enfuse
as a tonemapper, by creating synthetic LDR exposures
at various light levels from the HDR, but this would
be post processing of the HDR panaorama, outside Hugin.

(Alexander Rabtchevich's proposal of
an optimisation for this would be helpful
to me, but is not strictly neccessary).

So - can anyone advise me how to proceed, what options
(of the increasing range...) I need to set?

  BugBear

--
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: creating stacks from exposure brackets

[kfj]

On 22 Mai, 23:26, Bruno Postle  wrote:
> On Sun 22-May-2011 at 04:09 -0700, kfj wrote:
>
> > I have a problem with panoramas with stacks. When I load a bunch
> > of images, each image is in a separate stack. Is there a way to
> > tell hugin to put groups of N images into stacks instead of
> > assigning the stacks manually, or is someone working on such a
> > feature? If not, I might write a plugin.
>
> Assuming you want to use the Hugin feature that 'links' the
> positions of photos within the stack - i.e. you have a good tripod
> and don't need to optimise the photos within the stack separately.

Actually my stacks aren't done with a tripod, so they need alignment
within the stacks.

> This will happen automatically if you use match-n-shift --linkstacks
> to create the .pto project, it identifies the stacks from EXIF data.  
> Note that match-n-shift used to be a control point generator, but
> the default mode now is simply to create a .pto project from a list
> of photos using as much information as is possible from the EXIF.

Thanks for pointing me there - I had quite forgotten about match-n-
shift, as it didn't work for me at the time. It's a pity that it can
only be used to create the CPGs when called from hugin, but of course
making the project with it before loading it into hugin is an option.
I verified that it recognizes my stacks properly. I could take it from
there.

Kay

-- 
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: python scripting documentation

[kfj]

On 23 Mai, 02:08, Yuval Levy  wrote:
> Hi all, especially Kay,
>
> At the URL below is the information that I found from Kay's descriptions.  
> It's an initial stub for the manual entry.  You are welcome to add / improve /
> fix.

> http://wiki.panotools.org/Hugin_Scripting_Interface

Well done. I've finally created an account with the Panotools wiki,
prompted by your stub, and admittedly long overdue. I'll try and be
concise and not waffle ;-)

Kay

-- 
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 plugin interface - developers please liaise

[kfj]

On 22 Mai, 23:58, Yuval Levy  wrote:
> > Before I continue, let me point out the minor changes
> > ...
>
> would you help me rephrase the above with the purpose of explaining to those
> who get the tarball what has been done and what is still left to do, and how
> to do it?

This probably does the trick:

hsi/hpi for hugin is optional. It has to be compiled into hugin. This
is done by defining BUILD_HSI=ON in the cmake command that sets up the
code generation. Inside hugin's C++ code, there are some #defines that
are relevant only for hsi/hpi:

HUGIN_HSI - this is defined globally if hsi/hpi capability has been
switched on. It is used to introduce code which is hsi/hpi-specific
into files which are also part of 'plain' hugin

SWIG - this is only defined when code is processed by SWIG. It's used
to hide code from SWIG which it can't handle.

_HSI_IGNORE_SECTION - this is only defined during the separate C-
preprocessing of certain hugin header files which use a technique
dubbed 'lazy metaprogramming' which SWIG can't handle. Preprocessing
'flattens' the files - it pulls in all code that is #included by them.
Most of the code pulled in this way mustn't be wrapped by SWIG, so it
is switched off via #ifndef _HSI_IGNORE_SECTION.

Kay

-- 
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