date:20090907


James Legg wrote:
> I don't remember directly changing anything in the non libpano13
> sections, but it does remove chunks from files that are changed in the
> gsoc2009_layout branch.
> 
> I think svn merge should be able to find its way around the patch
> without to much hassle.

thanks, James. I'll wait another few days to give time to others to test 
the patch - particularly on OSX and Windows. If there are no reports 
that it breaks something, I'll commit it before issuing RC1

https://sourceforge.net/tracker/download.php?group_id=77506&atid=550441&file_id=342125&aid=2853853

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: Mailing List(s)

James Legg wrote:
> hugin-ptx is the only list linked to on hugin.sourceforge.net, and
> sourceforge makes the lists it hosts difficult to find. Could all the
> lists be listed there and at sourceforge.net/projects/hugin/?

I am not sure what can and can't be listed on sf.net/projects/hugin. We 
control hugin.sf.net and so we can list anything there. Yes the lists 
are difficult to find and part of this process will end in better 
documentation on where to find what - lists, RSS feeds, etc.

> To encourage public conversations I think the reply-to address on
> hugin-cvs (and other notification lists) should be hugin-ptx rather then
> the commiter's sourceforge address.

I'm not sure if (a) it makes sense for all notifications lists and (b) 
if it is possible with the current mailing list infrastructure (SF).

I do see an added value with the reply to committs notification going to 
hugin-ptx (or a dev-list). it defintely should not go to the committer.

What scares me a bit is replies to bug tracker notifications. This may 
defeat the purpose of keeping follow up information attached to the bug 
tracker ticket, rather than a discussion on a mailing list.

> A few emails quoting bits of a
> commit message posted to hugin-ptx will bring more attention to
> hugin-cvs and more public developer talk.

it's a matter of signal-to-noise ratio - for most users commit messages 
are noise. for me they are a wonderful way to learn as the project goes 
along, by reading what experts are doing and learning from their commit. 
Although I admit I don't always have the bandwidth to read and 
understand in full detail every single commit. I am still on the 
learning curve.

Also I don't think it is possible to limit this to "a few", unless the 
forward to hugin-ptx is manual and intentional. if we subscribe 
hugin-ptx to the commit notification we get every single commit in its 
full detail.

>> * A single developers mailing list that includes all the notifications, 
>> like [VLC devel] (used by the VideoLAN developers).
> 
> I don't like this approach. I subscribe to hugin-cvs and hugin-ptx, but
> only use the RSS feeds for the trackers. The volume of traffic is high,
> and forcing people who want some development talk to receive svn commits
> and tracker updates in their inbox as well can only make the volume
> greater.

I don't think this approach will happen. I rather think that we will 
have one separated list for notifications (tracker and commits), and one 
separated list for talk (which can very well be hugin-ptx if the users 
tolerate more dev talk).

Help me understand how you use RSS feeds to track notifications. RSS 
feeds have not worked for me so far. I found that most of them carry 
just the last ten or so messages, and I found no RSS reader that checks 
them automatically and regularly enough to guarantee that I don't miss 
an update (e.g. when I'm away for a few days). What's the point of 
incomplete information?

Furthermore: what's the difference between a feed and an in-box? to me 
they are conceptually exactly the same: a list of subject lines that I 
skim through, very often just with the delete key. Messages in mailboxes 
I can sort automatically into subfolders; or I can have (as I do) two or 
more different mailboxes with different priority. The only difference I 
see between RSS feeds and mailboxes is that once something is on my 
mailbox on the server, it waits for me and it can't be taken back or 
accidentally forgotten. Polling a mailbox or polling an RSS feed, I 
don't see much difference.

> Would the individual lists for automatic notifications still be
> available when there is a combined list?

I've tried to set up something like that - with a combined list that 
hooks up on the existing lists. It does not really work (yet), and it 
probably won't work with a GoogleGroup (my preferred mailing list tool). 
But it should work with mailman, i.e. it can problably be set up on SF 
(with all the disadvantages of SF).

> As a developer I would join a dev-talk list if it were created, but I'm
> happy to continue discussing developmental matters here. It's really up
> to people who would classify themselves as users or translators to
> decide if they consider development chatter as signal or noise.

exactly - this is why I want to read opinions from users.
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: Mailing List(s)

2009-09-07 Thread Nicolas Pelletier

My 2 cents...
I've been on the list as a user lately, but may transition to the dark side.

I think splitting the list so that all the hardcore details are in another
(public) list may be good... I'm just afraid that developers will not be on
the "user" list... I think this does make this list what it is.

Also, I'll agree with James... All the notifications seem more RSS relevant
(from past experience).

Thanks,

nick


On Mon, Sep 7, 2009 at 9:32 PM, James Legg  wrote:

>
> On Mon, 2009-09-07 at 20:21 -0400, Yuval Levy wrote:
> > Hi all,
> >
> > Hugin-PTX has this great feeling about it. It is a unique mix of
> > developers and users. In a single place we get creative artist's ideas
> > and discussion; user support requests; and developers communication down
> > to very technical details.
> >
> > It makes it easy to stay on top of things about Hugin, Libpano, Enblend,
> > Panini, and related tools; but at times the volume can become
> > overwhelming - and I take a big chunk of the blame for this ;-)
> 
> > I believe much of the developers communication is of public interest -
> > or at least of interest for those who want to contribute. And being
> > informed helps.
>
> Agreed, most developer conversions should be held in a publicly
> accessible list.
>
> > Another thing about mailing lists are notifications: we have
> > notification mailing lists for repository commits (at least SVN - I'm
> > still looking at how to implement this on Mercurial in Sourceforge); and
> > notifications from the bug/patch/feature trackers. Few people are aware
> > of them - and I realized a few weeks ago that this can be critical,
> > especially for developers. One of our GSoC students was not aware of a
> > change that was relevant for his project.
>
> hugin-ptx is the only list linked to on hugin.sourceforge.net, and
> sourceforge makes the lists it hosts difficult to find. Could all the
> lists be listed there and at sourceforge.net/projects/hugin/?
>
> To encourage public conversations I think the reply-to address on
> hugin-cvs (and other notification lists) should be hugin-ptx rather then
> the commiter's sourceforge address. A few emails quoting bits of a
> commit message posted to hugin-ptx will bring more attention to
> hugin-cvs and more public developer talk.
>
> > In an off-list discussion with Bruno we considered different options.
> >
> > * A single developers mailing list that includes all the notifications,
> > like [VLC devel] (used by the VideoLAN developers).
>
> I don't like this approach. I subscribe to hugin-cvs and hugin-ptx, but
> only use the RSS feeds for the trackers. The volume of traffic is high,
> and forcing people who want some development talk to receive svn commits
> and tracker updates in their inbox as well can only make the volume
> greater.
>
>
> > * Separation of developers talk from automatic notifications, but with
> > automatic notifications form all the related projects going to a single
> > mailing list. This means summarizing [hugin-cvs], [hugin-tracker],
> > [panotools-cvs] and the likes into a single mailing list, ideally one
> > with a better user interface than SourceForge that makes it very
> > difficult to find out where to subscribe and that insist to present
> > mailing list as (yuk!) forums
>
> Would the individual lists for automatic notifications still be
> available when there is a combined list?
>
> 
> > Since this would change the dynamics in the community, I would like to
> > know how people here feel about it. Would the developers be inclined to
> > join a dev-talk mailing list? and to subscribe to a single list with all
> > automatic notifications? How would the translators, users feel about
> this?
> >
> > What is *your* opinion about having three mailing lists, one for the
> > community at large; one for developers talk; and one for automated
> > notifications?
>
> As a developer I would join a dev-talk list if it were created, but I'm
> happy to continue discussing developmental matters here. It's really up
> to people who would classify themselves as users or translators to
> decide if they consider development chatter as signal or noise.
>
> -James
>
>
> >
>

--~--~-~--~~~---~--~~
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: bug: obscure compile failure if libpano12 is installed

2009-09-07 Thread Reid Priedhorsky


On Sep 7, 5:59 pm, Yuval Levy  wrote:
> Yuval Levy wrote:
> > yes, libpano12 is unmaintained legacy.
>
> I've cleaned up a lot of cruft. the patch is at 
> https://sourceforge.net/tracker/download.php?group_id=77506&atid=5504...

Thanks Yuv! :)

Reid
--~--~-~--~~~---~--~~
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: Mailing List(s)

2009-09-07 Thread James Legg

On Mon, 2009-09-07 at 20:21 -0400, Yuval Levy wrote:
> Hi all,
> 
> Hugin-PTX has this great feeling about it. It is a unique mix of 
> developers and users. In a single place we get creative artist's ideas 
> and discussion; user support requests; and developers communication down 
> to very technical details.
> 
> It makes it easy to stay on top of things about Hugin, Libpano, Enblend, 
> Panini, and related tools; but at times the volume can become 
> overwhelming - and I take a big chunk of the blame for this ;-)

> I believe much of the developers communication is of public interest - 
> or at least of interest for those who want to contribute. And being 
> informed helps.

Agreed, most developer conversions should be held in a publicly
accessible list.

> Another thing about mailing lists are notifications: we have 
> notification mailing lists for repository commits (at least SVN - I'm 
> still looking at how to implement this on Mercurial in Sourceforge); and 
> notifications from the bug/patch/feature trackers. Few people are aware 
> of them - and I realized a few weeks ago that this can be critical, 
> especially for developers. One of our GSoC students was not aware of a 
> change that was relevant for his project.

hugin-ptx is the only list linked to on hugin.sourceforge.net, and
sourceforge makes the lists it hosts difficult to find. Could all the
lists be listed there and at sourceforge.net/projects/hugin/?

To encourage public conversations I think the reply-to address on
hugin-cvs (and other notification lists) should be hugin-ptx rather then
the commiter's sourceforge address. A few emails quoting bits of a
commit message posted to hugin-ptx will bring more attention to
hugin-cvs and more public developer talk.

> In an off-list discussion with Bruno we considered different options.
> 
> * A single developers mailing list that includes all the notifications, 
> like [VLC devel] (used by the VideoLAN developers).

I don't like this approach. I subscribe to hugin-cvs and hugin-ptx, but
only use the RSS feeds for the trackers. The volume of traffic is high,
and forcing people who want some development talk to receive svn commits
and tracker updates in their inbox as well can only make the volume
greater.

> * Separation of developers talk from automatic notifications, but with 
> automatic notifications form all the related projects going to a single 
> mailing list. This means summarizing [hugin-cvs], [hugin-tracker], 
> [panotools-cvs] and the likes into a single mailing list, ideally one 
> with a better user interface than SourceForge that makes it very 
> difficult to find out where to subscribe and that insist to present 
> mailing list as (yuk!) forums

Would the individual lists for automatic notifications still be
available when there is a combined list?

> Since this would change the dynamics in the community, I would like to 
> know how people here feel about it. Would the developers be inclined to 
> join a dev-talk mailing list? and to subscribe to a single list with all 
> automatic notifications? How would the translators, users feel about this?
> 
> What is *your* opinion about having three mailing lists, one for the 
> community at large; one for developers talk; and one for automated 
> notifications?

As a developer I would join a dev-talk list if it were created, but I'm
happy to continue discussing developmental matters here. It's really up
to people who would classify themselves as users or translators to
decide if they consider development chatter as signal or noise.

-James

--~--~-~--~~~---~--~~
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: bug: obscure compile failure if libpano12 is installed

2009-09-07 Thread James Legg


On Mon, 2009-09-07 at 18:59 -0400, Yuval Levy wrote:
> Yuval Levy wrote:
> > yes, libpano12 is unmaintained legacy.
> 
> I've cleaned up a lot of cruft. the patch is at 
> https://sourceforge.net/tracker/download.php?group_id=77506&atid=550441&file_id=342125&aid=2853853
> 
> needs to be tested. also if it affects a GSoC project pending 
> integration (James?), it needs to be delayed.
> 
> More info in the bug tracker ticket.
> 
> Yuv

I don't remember directly changing anything in the non libpano13
sections, but it does remove chunks from files that are changed in the
gsoc2009_layout branch.

I think svn merge should be able to find its way around the patch
without to much hassle.

-James


--~--~-~--~~~---~--~~
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: how to add another parameter to the optimization?

2009-09-07 Thread dmg


Never mind, I got it working.

Apparently until parameters present in the i line are optimized. If
there are not there.
they aren't. Weird.


On Mon, Sep 7, 2009 at 4:52 PM, D M German wrote:
>
> hi Everybody,
>
> i am trying to finish and integrate the tilt function that Dev
> implemented during the summer.
>
> I have everything working except the optimization. I just can't understand
> the optimizer varies parameters, and how to instruct it to vary the
> values of the tilt.
>
> (yes, i have modified the parser, and Ptoptimizar correctly reports that
> the tilt variables are being optimized).
>
> Anybody has any clue?
>
>
> Thanks!
>
>
> --
> --
> Daniel M. German
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>
>



-- 
--dmg

---
Daniel M. German
http://turingmachine.org

--~--~-~--~~~---~--~~
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] Mailing List(s)


Hi all,

Hugin-PTX has this great feeling about it. It is a unique mix of 
developers and users. In a single place we get creative artist's ideas 
and discussion; user support requests; and developers communication down 
to very technical details.

It makes it easy to stay on top of things about Hugin, Libpano, Enblend, 
Panini, and related tools; but at times the volume can become 
overwhelming - and I take a big chunk of the blame for this ;-)

This has worked well so far, but we are growing and so is the level of 
activity and consequently the volume of messages, many of them very 
specifically targeted.

We already set up separate mailing lists, e.g. for Google Summer of Code 
mentors. It's a simple way to keep traffic relevant.

There have also been many off-list threads between many developers - 
most recently the restructuring of the enblend project that had about a 
dozen developers, builders, and testers, exchanging a high number of 
mails (I've counted over 50, and I don't even get everything that 
Christoph gets). So we got the 4.0 pre-release underway with little 
public awareness.

Other such "development talk" happened on the mentors list - which needs 
to be confidential because some of the matter discussed (e.g. evaluation 
of students) are not public.

I believe much of the developers communication is of public interest - 
or at least of interest for those who want to contribute. And being 
informed helps. As an example, this weekend Kornel and I exchanged about 
two dozen emails about a CMake build for enblend. Today we find out that 
Harry has been working on that from his end as well. If our 
communication would have been "in the clear", he would have known of our 
effort and we would have known of his.

There is currently one developers mailing list, panotools-devel, but it 
is practically dead (and it is run on Sourceforge's infrastructure which 
makes web accesses a pain).

Another thing about mailing lists are notifications: we have 
notification mailing lists for repository commits (at least SVN - I'm 
still looking at how to implement this on Mercurial in Sourceforge); and 
notifications from the bug/patch/feature trackers. Few people are aware 
of them - and I realized a few weeks ago that this can be critical, 
especially for developers. One of our GSoC students was not aware of a 
change that was relevant for his project.

In an off-list discussion with Bruno we considered different options.

* A single developers mailing list that includes all the notifications, 
like [VLC devel] (used by the VideoLAN developers).

* Separation of developers talk from automatic notifications, but with 
automatic notifications form all the related projects going to a single 
mailing list. This means summarizing [hugin-cvs], [hugin-tracker], 
[panotools-cvs] and the likes into a single mailing list, ideally one 
with a better user interface than SourceForge that makes it very 
difficult to find out where to subscribe and that insist to present 
mailing list as (yuk!) forums

The separation of developers talk should not make technical discourse 
disappear from Hugin-PTX. It should rather help keeping the balance, 
with the details that are currently discussed off-list being discussed 
on the new developers list. It will be left to the judgment of the 
individual developers what topics are better discussed there and what 
are better kept here; and the list would be publicly readable anyway, 
for easy cross-referencing.

Since this would change the dynamics in the community, I would like to 
know how people here feel about it. Would the developers be inclined to 
join a dev-talk mailing list? and to subscribe to a single list with all 
automatic notifications? How would the translators, users feel about this?

What is *your* opinion about having three mailing lists, one for the 
community at large; one for developers talk; and one for automated 
notifications?

Yuv


[VLC devel] http://mailman.videolan.org/pipermail/vlc-devel/
[hugin-cvs] https://lists.sourceforge.net/lists/listinfo/hugin-cvs
[hugin-tracker] https://lists.sourceforge.net/lists/listinfo/hugin-tracker
[panotools-cvs] https://lists.sourceforge.net/lists/listinfo/panotools-cvs

--~--~-~--~~~---~--~~
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] Chaos

2009-09-07 Thread Dale Beams

Recently I watched a show on Chaos theory. Prior to this theory being
implemented, the geometric shape was stuck in a simple solid world.

>From what I understand Hugin uses backend programs that also implement photo
>manipulation in a solid shape world, ie (spheres, etc.)

I imagine the ability to take any set of photos and use them in a not so set
simple solid world. For example, the current layout is cylindrical, sphere,
etc.

Let's take a set of photos from the general vantage point and "stretch" them to
fit an irregular solid. Essentially this can be done in gimp to some degree
know using skew, and etc.

If I have a flat plane of water, place a tissue on it, it will sit there flat.
I can stretch it upon that plane if needed. Drop a pebble in the water and the
tissue will conform to the waves created by the pebble, matching the water.
Pick the tissue up and drape it over a bush, and plane becomes irregular. None
of the points have changed, only their position in their plane. Take several
sheets and do the same, (photos) matching the points of each photo, and no
longer does it require perfect nodal points.

In addition, I think hugin as a community needs to consider looking at the math
and new algorythms for not only control points but also photo matching and
plane geometory. In the case of photo matching, I've not understood what is
holding back the idea of matching photos first based upon "areas" unique and
similar by color/shape. The algorytym needs to look at general shapes
(irregular) and color and then match them over the course of the photo. We do
this all the time. Take a set of 10 photos and print them out and lay them on
the floor. You'll find you can match them pretty quickly. We don't do this by
points, we do this by recognizing one shape looks like and is in the same or
similar color as one next to it. A puzzle organization. Which in fact is done
when putting togather large jigsaw puzzles.

Something like, look at color, caculate area, perimeter, match shape, etc.

And lastly the ability to break free from simple shapes allows photo matching
to go beyond simple panoramos into mega panoramas, such as long linear
panorama's or mapping. By not constricting the shape of the container for the
panorama, and basing it on edge to edge shape and color, linear and large map
panoramas become easy.

Enough of my rambling.

Dale

_
Get back to school stuff for them and cashback for you.
http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1
--~--~-~--~~~---~--~~
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] how to add another parameter to the optimization?

2009-09-07 Thread D M German



hi Everybody,

i am trying to finish and integrate the tilt function that Dev
implemented during the summer.

I have everything working except the optimization. I just can't understand
the optimizer varies parameters, and how to instruct it to vary the
values of the tilt.

(yes, i have modified the parser, and Ptoptimizar correctly reports that
the tilt variables are being optimized).

Anybody has any clue?


Thanks!


-- 
--
Daniel M. German  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

--~--~-~--~~~---~--~~
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/Enfuse 4.0 and Hugin


On Sep 7, 10:37 pm, "Ryan Sleevi"  wrote:
> > Is there a reason it wasn't compiled with image cache and OpenMP?
>
> If I recall correctly, the cached file representation used by enblend has
> not been made re-entrant/multi-threaded aware yet, so it causes some issues.
>
> I'm not sure if any work has been done towards supporting it, but I suspect
> it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image
> segments across multiple threads efficiently.

Tried using GPU, SSE2 and the regular release, they all die with :
enblend: out of memory
enblend: bad allocation

at some point. Is that expected or normal on win32?
They did accept -m parameter with no complaint.

OpenMP and GPU die after blending 5 photos, regular after 22 (of 44).
Is there a way to check why?

Well, back to 3.2 for the time being.

--~--~-~--~~~---~--~~
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] Changing [OSX] hugin-mac AutoCP parameters is possible.

2009-09-07 Thread AKS-Gmail-IMAP


>
> Harry van der Wolf wrote regarding the "plug-in" method for AutoCP  
> matchers used in the OS X implementation:
>>

>>  The disadvantage of Ippei's
>> implementation is that you can't change parameters which you can  
>> with Thomas
>> solution.


Ah but Harry you can change easily the parameters for the OS X  
AutoCPs.  In each of the OS X AutoCP packages is an XML property list  
plist file called Info.plist.  OS X will open that file using the  
Property List Editor. Using the editor you may change the  
"HginAutoCPArgs" key to be anything you want. You may even keep the  
plist open after saving the change so to quickly change the arguments  
for the next AutoCP run.

Allan
--~--~-~--~~~---~--~~
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: Control point generator incantations


Bruno Postle wrote:
> I don't think there is any need to ship with alternative 
> incantations for each tool,

it's not about "shipping with" alternatives. It is about making sure 
that the name given to a further incantation added by the user is unique 
(i.e. check that it is not an already existing name)


>> why match-n-shift not on windows? IIRC it was working?
> 
> Apparently the binaries I produced didn't have all the right perl 
> modules, it will work, but somebody else needs to do it.

The instructions are at 


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: bug: obscure compile failure if libpano12 is installed


Yuval Levy wrote:
> yes, libpano12 is unmaintained legacy.

I've cleaned up a lot of cruft. the patch is at 
https://sourceforge.net/tracker/download.php?group_id=77506&atid=550441&file_id=342125&aid=2853853

needs to be tested. also if it affects a GSoC project pending 
integration (James?), it needs to be delayed.

More info in the bug tracker ticket.

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] Enblend/Enfuse 4.0 dev snapshots

2009-09-07 Thread Benjamin Schnieders


Hi all,

just trying a selfcompiled v4.0 - stitching a pretty big project now.

Inspecting the enblend run with top I see that indeed enblend sometimes 
uses more than 100% cpu - but never more than like 200%, usually it is 
around 100% and from time to time there is a peak using somewhat more. 
As I have a quadcore and I see it is perfectly used up by nona I'm a 
little disappointed about enblend - was this a malconfiguration?

enblend verbose version info tells me:
enblend 4.0-b93c2aed500d

Extra feature: dmalloc support: no
Extra feature: image cache: no
Extra feature: GPU acceleration: yes
Extra feature: OpenMP: yes - version 2005-5
   - support for nested parallelism
   - support for dynamic adjustment of the 
number of threads
   - using 4 processors and up to 3 threads


Is this the up-to date version or id I compile something wrong?

Thanks :)
Benjamin

--~--~-~--~~~---~--~~
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: Control point generator incantations

On Mon 07-Sep-2009 at 17:48 -0400, Yuval Levy wrote:
>
>My point is that there can be multiple settings for the same tool and
>that currently the short description allows one to have the same short
>name more than once. This affects also the potential patent-free cp
>generator.

I don't think there is any need to ship with alternative 
incantations for each tool, I just included all variations in the 
email as this stuff needs to be documented somewhere.

There is really only one sensible set of parameters for each, I'll 
commit the autopano-sift-c --projection parameter anyway as this has 
been supported since 2.5.0 over a year ago.

>> For now I think we should just ship these presets:
>>
>> 1. autopano-sift-c (default)
>> 2. panomatic
>> 3. match-n-shift (not on windows)
>> 4. autopano.exe (only on windows)
>> 5. align_image_stack
>
>why match-n-shift not on windows? IIRC it was working?

Apparently the binaries I produced didn't have all the right perl 
modules, it will work, but somebody else needs to do it.

>> I'm tempted to switch autopano-sift-c with autopano-noop.sh on Linux
>> as they are functionally identical - Currently I patch this in when
>> packaging for fedora.
>
>I second this. Default should be autopano-noop.sh (or the Windows
>equivalent) so that also users of distributions that don't have a CP
>generator get a meaningful feedback (which can be a statement telling
>them to install a CP detector and change the preference).

Actually autopano-noop.sh in 2009.2.0 tests for autopano-sift-c and 
just passes through the command if it is present.  i.e. it _should_ 
be a painless default on Linux/unix.

-- 
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: Control point generator incantations

Bruno Postle wrote:
> On Mon 07-Sep-2009 at 13:00 -0400, Yuval Levy wrote:
>> What we absolutely need is a way to identify the different settings, and
>> this goes via *short* descriptive name.
> 
> Long descriptions need support for translation

The long descriptions are not my point.

My point is that there can be multiple settings for the same tool and 
that currently the short description allows one to have the same short 
name more than once. This affects also the potential patent-free cp 
generator.

> For now I think we should just ship these presets:
> 
> 1. autopano-sift-c (default)
> 2. panomatic
> 3. match-n-shift (not on windows)
> 4. autopano.exe (only on windows)
> 5. align_image_stack

why match-n-shift not on windows? IIRC it was working?

> I'm tempted to switch autopano-sift-c with autopano-noop.sh on Linux 
> as they are functionally identical - Currently I patch this in when 
> packaging for fedora.

I second this. Default should be autopano-noop.sh (or the Windows 
equivalent) so that also users of distributions that don't have a CP 
generator get a meaningful feedback (which can be a statement telling 
them to install a CP detector and change the preference).

Yuv (waiting for his trunk to build with the pano12 cruft removed before 
filing a patch)

> 

--~--~-~--~~~---~--~~
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: Control point generator incantations

On Mon 07-Sep-2009 at 13:00 -0400, Yuval Levy wrote:
>
>What we absolutely need is a way to identify the different settings, and
>this goes via *short* descriptive name.

Long descriptions need support for translation and this effort 
should go into creating a properly working patent-free control point 
generator rather than giving the user a choice between part-working 
alternatives.

For now I think we should just ship these presets:

1. autopano-sift-c (default)
2. panomatic
3. match-n-shift (not on windows)
4. autopano.exe (only on windows)
5. align_image_stack

I'm tempted to switch autopano-sift-c with autopano-noop.sh on Linux 
as they are functionally identical - Currently I patch this in when 
packaging for fedora.

-- 
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: Hugin system recommendation for the future?


On Sep 7, 10:50 pm, Bruno Postle  wrote:
>
> i.e. get a system with lots of memory and create a ramdisk for
> temporary files.  You don't need any expensive solid-state
> persistent storage.

And/or get a regular RAID0 or preferably RAID5. With 6 cheap drives it
should net you >500mb/s transfers and oodles of space for all the
por^H^H, erm, panos.
Just be sure to get a proper controller for the RAID.


--~--~-~--~~~---~--~~
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/Enfuse 4.0 and Hugin


On Sep 7, 10:37 pm, "Ryan Sleevi"  wrote:
>
> > Is there a reason it wasn't compiled with image cache and OpenMP?
>
> If I recall correctly, the cached file representation used by enblend has
> not been made re-entrant/multi-threaded aware yet, so it causes some issues.
>
> I'm not sure if any work has been done towards supporting it, but I suspect
> it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image
> segments across multiple threads efficiently.

So not anytime soon? :(
Any workarounds? BTW shouldn't the OS do the swapping for Enblend? Or
they do, but I have a 32-bit one?
--~--~-~--~~~---~--~~
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: celeste build problem, 2009.2.0-beta2


On Mon 07-Sep-2009 at 13:15 -0400, Yuval Levy wrote:
>Bruno Postle wrote:
>> Since nona-gpu was added, the libhuginbase library links to GLEW and
>> X libraries, as a result all hugin tools now link to them.
>>
>> It would be nice to fix this, but it hasn't been a priority.
>
>I think it does not affect only OpenBSD:
>

These are unlikely to be related.  libhuginbase linking to GLEW 
isn't a 'bug', it just drags in extra dependencies that shouldn't be 
required by command-line tools.

-- 
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: Hugin system recommendation for the future?


On Mon 07-Sep-2009 at 14:09 +0200, Seb Perez-D wrote:
>
>One thing that is slow is writing the TIF files produced by nona and
>reading them again by enblend. One way to speed the process would be
>to ensure that everything stays in RAM. With enough memory this could
>be done.

i.e. get a system with lots of memory and create a ramdisk for 
temporary files.  You don't need any expensive solid-state 
persistent storage.

-- 
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: Enblend/Enfuse 4.0 and Hugin

2009-09-07 Thread Ryan Sleevi


> -Original Message-
> From: hugin-ptx@googlegroups.com [mailto:hugin-...@googlegroups.com] On
> Behalf Of Zoran Zorkic
> Sent: Monday, September 07, 2009 4:25 PM
> To: hugin and other free panoramic software
> Subject: [hugin-ptx] Re: Enblend/Enfuse 4.0 and Hugin

> 
> Is there a reason it wasn't compiled with image cache and OpenMP?
> 

If I recall correctly, the cached file representation used by enblend has
not been made re-entrant/multi-threaded aware yet, so it causes some issues.

I'm not sure if any work has been done towards supporting it, but I suspect
it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image
segments across multiple threads efficiently.



--~--~-~--~~~---~--~~
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: bug: obscure compile failure if libpano12 is installed


Reid Priedhorsky wrote:
> Removing libpano12-dev and friends and replacing with libpano13-dev
> and friends resulted in a successful build and working software.
> 
> The docs indicate libpano13 is required, but the cmake step did not
> complain that I had the wrong libpano version.

yes, libpano12 is unmaintained legacy. Hugin has been long enough in 
transition. I think we should decomission it / remove any reference to 
it and work with libpano13 only.

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: Enblend/Enfuse 4.0 dev snapshots


J. Schneider wrote:
> Sorry, I was too fast posting; I recognized the cause was changed 
> options syntax for enblend. I have to review my enblend options in 
> hugin. But this probably means we need new droplets for enblend, too.

https://sourceforge.net/tracker/?func=detail&aid=2853823&group_id=77506&atid=550441

--~--~-~--~~~---~--~~
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] Panotools::Script 0.23 released


Panotools::Script is a perl module for reading/writing and 
manipulating hugin .pto project files, this 0.23 release fixes some 
minor bugs and adds two command-line tools:

- ptodummy is a utility for testing .pto projects.  Given a .pto 
file (e.g. from a bug report) without the original input images, 
ptodummy recreates any missing input files as required to allow 
the project to load in hugin.

- enfuse-mask is a wrapper around enfuse which allows you to use 
external masks instead of manipulating alpha channels of input 
images.

A Panotools::Script tarball is available on CPAN:

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

0.23 changes:
- Add new projections to pod documentation and ptoinfo output
- Add empty 'v' line to all output as panotools chokes without 'v' lines
- New enfuse-mask tool based on enblend-mask
- New ptodummy tool for creating missing input photos
- panostart: create default Makefile if no output specified
- support 'i' line 'j' parameter introduced in gsoc layout project

SHA1SUM: 831f6c4dcb389035d64461888e57b68f6fff34c9  Panotools-Script-0.23.tar.gz

-- 
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: Enblend/Enfuse 4.0 and Hugin




On Sep 7, 10:11 pm, Yuval Levy  wrote:
> Zoran Zorkic wrote:
> > Got this after trying to blend a 360x180 from Hugin 2009.1.0.4263:
>
> > enblend: unrecognized wrap-around mode "-f3000x1500"
>
> > Probably because enblend was called with "-w -f3000x1500".
>
> yes, there are some changes in how enblend / enfuse is called in 4.0
>
> we will need to adapt this in Hugin - ideally with an enblend --version
> to find out if we're using a "legacy" enblend-enfuse; and with the
> Makefile adapted to the enblend-enfuse "generation" found on the machine.

I think it could have been done more backward compatible way in
enblend.

Anyway, using OpenMP, SSE2 version (on a 2x1 pano) from
command line I quickly bails with just a:

enblend: out of memory
enblend: bad allocation

I guess this is cause it was compiled without image cache :/
Yay for 32-bit OSes!

And by the testing I've done, the next fastest is v3.2 :(

Is there a reason it wasn't compiled with image cache and OpenMP?

--~--~-~--~~~---~--~~
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/Enfuse 4.0 dev snapshots

2009-09-07 Thread J. Schneider


Sorry, I was too fast posting; I recognized the cause was changed 
options syntax for enblend. I have to review my enblend options in 
hugin. But this probably means we need new droplets for enblend, too.
regards
Joachim

J. Schneider schrieb:
> Fine! I tried the x86 OpenMP, SSE2 version (assuming that this is right 
> for a core2duo).
> I copied just enblend.exe into my hugin/bin directory (latest available 
> build).
> The error I get looks not like it's a problem of MP or the like, its 
> about an "unrecognized wrap-around mode". It won't let me copy the 
> output as the window disappears just after klicking OK (and before you 
> can't select text) but I felt this would happen and made a screenshot:
> http://www.joachimschneider.info/enblend-error/enblend-error.gif
> The first of the numbers mentioned is the width.
> 
> Any idea?
> 
> 
> Btw, there are droplets supplied only for enfuse but not enblend. Is it 
> because those for enblend didn't need any changes and I can continue to 
> use them?
> 
> regards
> Joachim

--~--~-~--~~~---~--~~
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] bug: obscure compile failure if libpano12 is installed

2009-09-07 Thread Reid Priedhorsky


I had libpano12 installed (Debian Lenny package libpano12-dev). The
build failed with:

/usr/local/src/hugin-0.8.0/src/hugin_base/panodata/
PanoramaOptions.cpp: In member function 'double
HuginBase::PanoramaOptions::getMaxVFOV() const':
/usr/local/src/hugin-0.8.0/src/hugin_base/panodata/PanoramaOptions.cpp:
527: error: expected primary-expression before '}' token
/usr/local/src/hugin-0.8.0/src/hugin_base/panodata/PanoramaOptions.cpp:
527: error: expected `;' before '}' token

Looking in PanoramaOptions.cpp at that line, there is an obvious
syntax error, but it's #ifdef'ed out - if libpano13 is installed.

Removing libpano12-dev and friends and replacing with libpano13-dev
and friends resulted in a successful build and working software.

The docs indicate libpano13 is required, but the cmake step did not
complain that I had the wrong libpano version.

Thanks,

Reid

--~--~-~--~~~---~--~~
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] " fork failed: no error on" Win-2003 64bit

2009-09-07 Thread Vasu


Hi Friends,

We used to run few shell scripts on Windows 2003 - 32 bit Editions
sucessfully, now same scripts are throughing a strange error " fork
failed: no error " on Windows 2003 - 64 bit Editions.

   can you please let us know what could be the root cause of this?
any change in runnig shell script on 64 bit edn.?

D:\Source\FLL\release>installinfra.bat
D:\Source\FLL\release>echo off
installinfra: fork failed: no error [3]
installinfra: fork failed: no error [27]
installinfra: fork failed: no error [41]
installinfra: fork failed: no error [42]


Appreciate your immediate help.
Thank in Advance.
Vasu.S

--~--~-~--~~~---~--~~
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/Enfuse 4.0 and Hugin


Zoran Zorkic wrote:
> Got this after trying to blend a 360x180 from Hugin 2009.1.0.4263:
> 
> enblend: unrecognized wrap-around mode "-f3000x1500"
> 
> Probably because enblend was called with "-w -f3000x1500".

yes, there are some changes in how enblend / enfuse is called in 4.0

we will need to adapt this in Hugin - ideally with an enblend --version 
to find out if we're using a "legacy" enblend-enfuse; and with the 
Makefile adapted to the enblend-enfuse "generation" found on the machine.

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: Enblend/Enfuse 4.0 dev snapshots

2009-09-07 Thread J. Schneider


Fine! I tried the x86 OpenMP, SSE2 version (assuming that this is right 
for a core2duo).
I copied just enblend.exe into my hugin/bin directory (latest available 
build).
The error I get looks not like it's a problem of MP or the like, its 
about an "unrecognized wrap-around mode". It won't let me copy the 
output as the window disappears just after klicking OK (and before you 
can't select text) but I felt this would happen and made a screenshot:
http://www.joachimschneider.info/enblend-error/enblend-error.gif
The first of the numbers mentioned is the width.

Any idea?


Btw, there are droplets supplied only for enfuse but not enblend. Is it 
because those for enblend didn't need any changes and I can continue to 
use them?

regards
Joachim

--~--~-~--~~~---~--~~
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/Enfuse 4.0 dev snapshots


Got this after trying to blend a 360x180 from Hugin 2009.1.0.4263:

enblend: unrecognized wrap-around mode "-f3000x1500"

Probably because enblend was called with "-w -f3000x1500".



--~--~-~--~~~---~--~~
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/Enfuse 4.0 dev snapshots

Zoran Zorkic wrote:
> Tested it on some 10 remapped photos:
> used enblend -v -o output.tif input*.tif
> unless stated otherwise
> 
> GPU, SSE2: 108 sec
> GPU, SSE2, -m 1900: 85 sec
> OPENMP: 63 sec
> OPENMP, SSE2: 63 sec
> RELEASE: 112 sec
> RELEASE, -m 1900: 89 sec
> 
> Test machine: Xp sp2 x86, e6...@3.35ghz 4gb ram, nVidia 9800GT 512mb

the next level would be to run this kind of tests in the installer and 
select the appropriate version to be installed on the system.

If a dual core is already so much faster than GPU stitching, I'd tend to 
install the OpenMP version on any x86 multi-core. Not sure about the old 
multi-threading pentium. Leave the GPU accelerated only for people with 
old boxes and poweful GPUs.

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 system recommendation for the future?


Seb Perez-D wrote:
> One thing that is slow is writing the TIF files produced by nona and
> reading them again by enblend. One way to speed the process would be
> to ensure that everything stays in RAM. With enough memory this could
> be done.

or with 

beware, this is a concerted attack by the high tech industry and the 
credit card companies on your retirement savings ;-)

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: celeste build problem, 2009.2.0-beta2


Bruno Postle wrote:
> Since nona-gpu was added, the libhuginbase library links to GLEW and 
> X libraries, as a result all hugin tools now link to them.
> 
> It would be nice to fix this, but it hasn't been a priority.

I think it does not affect only OpenBSD:


what would it take to fix this?

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: Control point generator incantations

Bart van Andel wrote:
> On 7 sep, 05:26, Yuv  wrote:
>> the more the merrier! I would suggest giving more meaningful names
>> (first column) indicating the purpose of the settings. Some works
>> better with fisheye lenses than others.
> 
> I haven't even checked out this new preset thing (which I deem a very
> good idea!), so I don't know if I'm saying something stupid, but
> wouldn't a comment or description field be a better solution to
> describe the purpose of each preset? I'd favour this over using very
> long names.

an *additional* comment / description may or may not be useful - the 
defaults can also be explained in the manual.

What we absolutely need is a way to identify the different settings, and 
this goes via *short* descriptive name.

The idea is that users give names that are meaningful to them; but we do 
need to name the defaults properly.

Right now I can define three different Autopano-SIFT-C settings and give 
all three of them the same "Autopano-SIFT-C" name. The preferences panel 
does not complain. This will generates confusion later on, e.g. in the 
Images tab where I have a drop down with three entries that look exactly 
the same. Even "Autopano-SIFT-C 1","Autopano-SIFT-C 2","Autopano-SIFT-C 
3" would be better than the present situation.

This is, of course, just for defaults. It is expected that the user will 
give those settings a meaningful name, e.g. I already see myself giving 
them names such as "8mm full spherical" or "rectilinear gigapano" to 
relate them with my own workflow.

It would also make sense to add the "Points per Overlap" (currently in 
the Images tab) to the settings. When I work with my calibrated fisheye 
lens, I often use only 4 CPs per overlap. On the other hand, there are 
situations when I like to generate more CPs.

Ultimately we need a short, descriptive, custom name for the user to 
recognize their own settings; and to identify the defaults that will be 
shipped with Hugin.

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] Hugin-2009.2.0_beta3 released


Panorama stitching and more. A powerful software package for creation 
and processing of panoramic images.

A hugin-2009.2.0_beta3 (beta release 3) tarball is available here:



This is a beta release, i.e. it may not work for you. The current Hugin 
2009.2 release codeline is reported to work on Linux, Windows and OS X, 
however some experimental functionalities may not work and the final 
release is likely to have further bugfixes and minor feature enhancements.


CALL FOR TRANSLATORS

In particular, most translations haven't been updated since 0.8.0, so 
this release isn't fully internationalised yet. There are less than 30 
new strings to translate so it isn't a big job this time. Start at



With the new release process it is possible for the final version to be 
released without updated translations. Updated translations that don't 
make the cut will be used in future releases.


MAJOR CHANGES SINCE 0.8.0:

 * GPU accelerated stitching. Highly experimental. Activate from 
Files -> Preferences -> Stitching. Depends on a combination of hardware, 
driver, input images and other factors. Details will be posted in the 
Hugin FAQ 

 * Improved Preferences panel (Control Point Detectors) - OSX 
version uses its own plugin control point detectors architecture.

 * Improved control of stitching process (Stitcher tab). Hugin now 
features an additional Exposure fusion -> Blended and fused panorama 
output option, useful when it is not possible to keep exposure and white 
balance constant between shots. Tutorial at 


 * Fast Preview shows control points connected with lines - the 
longest the line the worse the quality (except for vertical and 
horizontal control lines).

 * Lots of bugfixes, lots of new bugs.

See README, ChangeLog and INSTALL_cmake for more information.

This release is tagged in the subversion repository as 
/hugin/releases/tag/2009.2.0_beta3 at revision 4340.

SHA1SUM: 0b8d64282a35e241d87828be276dbeb4b2929ebe 
hugin-2009.2.0_beta3.tar.gz

Recent Hugin binary installers for testing are provided by the users 
communities and can be found here:



--~--~-~--~~~---~--~~
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: Control point generator incantations

2009-09-07 Thread Bart van Andel


On 7 sep, 05:26, Yuv  wrote:
> the more the merrier! I would suggest giving more meaningful names
> (first column) indicating the purpose of the settings. Some works
> better with fisheye lenses than others.

I haven't even checked out this new preset thing (which I deem a very
good idea!), so I don't know if I'm saying something stupid, but
wouldn't a comment or description field be a better solution to
describe the purpose of each preset? I'd favour this over using very
long names.

--
Bart
--~--~-~--~~~---~--~~
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: celeste build problem, 2009.2.0-beta2

2009-09-07 Thread Tim Nugent


celeste_train is very low priority, I've actually commented out 
add_subdirectory(training) from CMakeLists.txt for the moment, I don't 
think we need to worry about it.

Tim

Bruno Postle wrote:
> On Mon 07-Sep-2009 at 13:02 +0100, Tim Nugent wrote:
>> Strange, celeste stuff doesn't need libGLEW for anything..
> 
> Since nona-gpu was added, the libhuginbase library links to GLEW and 
> X libraries, as a result all hugin tools now link to them.
> 
> It would be nice to fix this, but it hasn't been a priority.
> 
>> Stuart Henderson wrote:
>>> Now that celeste and celeste/training pull in libGLEW they also need to
>>> find the X libs, which on OpenBSD are in /usr/X11R6/lib (not in ld's
>>> default search path).
> 

--~--~-~--~~~---~--~~
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: celeste build problem, 2009.2.0-beta2


On Mon 07-Sep-2009 at 13:02 +0100, Tim Nugent wrote:
>Strange, celeste stuff doesn't need libGLEW for anything..

Since nona-gpu was added, the libhuginbase library links to GLEW and 
X libraries, as a result all hugin tools now link to them.

It would be nice to fix this, but it hasn't been a priority.

>Stuart Henderson wrote:
>> Now that celeste and celeste/training pull in libGLEW they also need to
>> find the X libs, which on OpenBSD are in /usr/X11R6/lib (not in ld's
>> default search path).

-- 
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: Hugin system recommendation for the future?

2009-09-07 Thread Seb Perez-D


On Mon, Sep 7, 2009 at 13:15, Zoran Zorkic wrote:
> On Sep 7, 12:45 pm, Seb Perez-D  wrote:
>
>> I've read (and I believe it is true) that a very very hard drive is
>> needed - some setups that have been mentioned in PanotoolsNG have
>> several fast drives acting as one without redundancies.
>
> It helps when your system runs out of memory and has to swap to disk.
> Having a fast raid 0 field can speed things up considerably. Though if
> you have 16gb of ram it should not matter much.

One thing that is slow is writing the TIF files produced by nona and
reading them again by enblend. One way to speed the process would be
to ensure that everything stays in RAM. With enough memory this could
be done.

Cheers,

Seb

--~--~-~--~~~---~--~~
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: celeste build problem, 2009.2.0-beta2

2009-09-07 Thread Tim Nugent


Strange, celeste stuff doesn't need libGLEW for anything..

Tim

Stuart Henderson wrote:
> Now that celeste and celeste/training pull in libGLEW they also need to
> find the X libs, which on OpenBSD are in /usr/X11R6/lib (not in ld's
> default search path). So linking fails unless I add -L/usr/X11R6/lib.
> I haven't worked out how to get CMake to do this yet but noticed that
> ${wxWidgets_LIBRARIES} adds this so for now I can workaround by adding
> this to the relevant target_link_libraries. It works, but isn't
> "the right way", can anyone suggest something better?
> 
> thanks,
> Stuart.
> 
> 
> 
> > 
> 

--~--~-~--~~~---~--~~
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 system recommendation for the future?




On Sep 7, 12:45 pm, Seb Perez-D  wrote:

> I've read (and I believe it is true) that a very very hard drive is
> needed - some setups that have been mentioned in PanotoolsNG have
> several fast drives acting as one without redundancies.

It helps when your system runs out of memory and has to swap to disk.
Having a fast raid 0 field can speed things up considerably. Though if
you have 16gb of ram it should not matter much.


--~--~-~--~~~---~--~~
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 system recommendation for the future?

2009-09-07 Thread Seb Perez-D


On Mon, Sep 7, 2009 at 12:22, Oskar Sander wrote:
> How does an ideal Hugin system look like (for example Windows) going
> forward?   I suppose huge amounts of memory is still good, but how does
> other factors rank (i.e. multiple cores, GPU etc)?

I've read (and I believe it is true) that a very very hard drive is
needed - some setups that have been mentioned in PanotoolsNG have
several fast drives acting as one without redundancies.

A lot of RAM also helps. Multiple cores are difficult to use, but this
changes over time (see the recent enblend with OpenMP)

Cheers,

Seb

--~--~-~--~~~---~--~~
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 system recommendation for the future?

2009-09-07 Thread Oskar Sander

How does an ideal Hugin system look like (for example Windows) going
forward?   I suppose huge amounts of memory is still good, but how does
other factors rank (i.e. multiple cores, GPU etc)?

I'm about to upgrade my home computer anyway and don't want to miss the
mark.

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] celeste build problem, 2009.2.0-beta2

2009-09-07 Thread Stuart Henderson


Now that celeste and celeste/training pull in libGLEW they also need to
find the X libs, which on OpenBSD are in /usr/X11R6/lib (not in ld's
default search path). So linking fails unless I add -L/usr/X11R6/lib.
I haven't worked out how to get CMake to do this yet but noticed that
${wxWidgets_LIBRARIES} adds this so for now I can workaround by adding
this to the relevant target_link_libraries. It works, but isn't
"the right way", can anyone suggest something better?

thanks,
Stuart.



--~--~-~--~~~---~--~~
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/Enfuse 4.0 dev snapshots


Continued:

ENBLEND 3.2, -m 1900: 72 sec

Test machine: Xp sp2 x86, e6550 3.35GHz 4gb ram, nVidia 9800GT 512mb,
fairly new drivers
(I just saw that google censored my cpu in the last post :D )

Old, 3.2, was crashing for me a lot lately on bigger projects, I'll
try to test it against this one when I find some time.

Also when running GPU --gpu i get the following warnings:
---
: info: using graphics card: NVIDIA Corporation
: info:renderer: GeForce 9800 GT/PCI/SSE2
: info: GL info log
0(1) : warning C7531: global type sampler2DRect requires "#extension
GL_ARB_texture_rectangle : enable" before use
---
...
enblend: info:state (130, 580) weight = nan
enblend: info:state (117, 580) weight = nan
enblend: info:state (104, 580) weight = nan
enblend: info:new estimate = (-2147483648, -2147483648)
enblend: warning: new mean field estimate outside cost image
---

--~--~-~--~~~---~--~~
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/Enfuse 4.0 dev snapshots