headers
Yuval Levy | 1 Aug 2009 01:47
Picon
Favicon

Re: nona -t


Bruno Postle wrote:
> This is a bug and should go in the tracker.
> 
> I suspect that Enblend -> use alternative Enblend/Enfuse program is 
> similarly broken.
> 

actually it is more than a bug. It's a mess.

I've been working on Andrew's nona-gpu branch as this is the next 
feature we want to release. I studied all of his commit and understood 
pretty quickly that he neatly self-contained everything in nona and that 
we need a way to make it accessible from the Hugin GUI, i.e. pass the -g 
switch (which is similar to passing the -t switch). I figured out that 
by looking at how Hugin handles similar switches I can drill through the 
different stages and implement the missing code.

First I decided where to put the choice. The GPU is a system-wide 
choice, so it makes sense to put it in the preferences (as opposed to 
put it in the nona options on the stitcher tab, which I also considered 
because I thought I could use example code from there). On the stitcher 
tab I found that some option go into the project file (and are 
saved/implemented). others *should* go into the makefile.

To debug my work, I mutilated Andrew's nona (sorry Andrew). Where he 
inserted his code with

             case 'g':
                 useGPU = 1;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bruno Postle | 1 Aug 2009 02:01
X-Face

Re: nona -t


On Fri 31-Jul-2009 at 19:47 -0400, Yuval Levy wrote:
>
>Next I looked at where the Makefile is created. I was able to create a
>Makefile with the -g nona switch when hitting "Save", but not when
>hitting "Stitch Now".

The 'Stitch Now' code was made different from 'Save' after 
complaints about temporary files appearing in the output directory.

The difference with Stitch Now is that copies of the .pto and 
.pto.mk file are created in a temporary folder were the intermediate 
files are also created.  Personally I think this is an unnecessary 
complication and all files could be created and destroyed where 
users can see them.

There is a third way to stitch: pto2mk doesn't use the Hugin 
preferences at all - The Preferences are managed by wxwidgets but 
pto2mk is a command-line tool that shouldn't link to a GUI library.

--

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

Permalink | Reply | 1 comment |
headers
Michael Galloway | 1 Aug 2009 02:38
Picon
Favicon

Re: [mgx <at> ornl.gov: Re: requesting hugin 0.8.0 mac review]


On Fri, Jul 31, 2009 at 10:15:48PM +0100, Bruno Postle wrote:
> 
> On Sun 26-Jul-2009 at 09:53 -0400, Michael Galloway wrote:
> 
> >i'm forwarding this on to the general maillist per request by ippei.
> >on this os x build of hugin, i get dramatically different previews
> >between the opengl and the normal preview, attached are a couple of
> >images of the previews. this is using ippei's current os x build, on
> >os x 10.5.6 intel.
> 
> On Linux I see artefacts like this in the Fast preview, but mostly 
> with the more obscure output projections, and only rarely when the 
> output projection is set to 'rectilinear' or 'equirectangular'.  Do 
> you see this all the time?  Is this the same on all OS X machines?
> 
> -- 
> Bruno
>

no, i did two tests with this build from ippei, a 'simple' single row 
panorama that was about 180deg in which the opengl preview was normal,
and the multirow panorama that is 360deg which displayed the problems.

-- michael

--~--~---------~--~----~------------~-------~--~----~
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yuv | 1 Aug 2009 04:02
Picon
Favicon

Re: nona -t


Bruno Postle wrote:
> On Fri 31-Jul-2009 at 19:47 -0400, Yuval Levy wrote:
> There is a third way to stitch: pto2mk doesn't use the Hugin
> preferences at all - The Preferences are managed by wxwidgets but
> pto2mk is a command-line tool that shouldn't link to a GUI library.

oh, nice, another skeleton.

this means that we have to pass the preferences either through the
project file or through the makefile. Probably both since some of the
prefs are project-related (project file) and others are system-related
(makefile).

and definitely not wxWidgets dependent.

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 <at> googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Yuval Levy | 1 Aug 2009 05:31
Picon
Favicon

Re: What's in a Version Number?

Bruno Postle wrote:
> On Thu 23-Jul-2009 at 09:09 -0400, Yuval Levy wrote:
>> Can we agree on:
>> V_MAJOR: YYYY
>> V_MINOR: sequential, odd for development. and even for stable.
>> V_PATCH: for bugfixes on releases
> 
>> * right now we'd be 2009.1 in trunk
>> * the next release, with nona-gpu, will hopefully be 2009.2; or it will
>> be 2010.0
>> * after the next release trunk will be bumped to 2009.3 or 2010.1
>> respectively
> 
> Ok, this suits a system of branching for a stable release. So:
> 
> Current trunk becomes 2009.1.0 immediately.

means no freezes on trunk, ever?
> 
> Next stable branch is 2009.2.0 as soon as it branches, trunk becomes 
> 2009.3.0 at the same time.

Just to make sure we're on the same page: the branch becomes 2009.2.0 
*before* it is actually stabilized? (see the attached image that depicts 
how I envision the interface between the development and release cycles)?

If the next release branch is 2009.2.0 when it is branched, how are 
snapshots (alphas), betas, candidates distinguished from final?

I want trunk to keep on living without any freeze.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Yuval Levy | 1 Aug 2009 05:57
Picon
Favicon

Re: test version of official installers for Hugin 0.8 on Windows


hi Allard,

allard wrote:
> Just to help you stay away from the dark side, here's what I made of
> the text fileinstaller_licence.txt:

it's not so much the dark side, as it is the hot side. no airco in the 
office, my boss is cheap (did I tell you I'm my own boss?) so I work on 
the Ubuntu notebook in the airconditioned zone.

thanks for providing the text, my feedback between the lines.

> UPGRADES
> This version of Hugin is backwards compatible, and there should not be
> good reasons to keep using the previous stable version. If you wish to
> do so however, it is possible to install them side-by-side. If not,
> please uninstall the previous version before running this installer.

not really. 0.7 and 0.8 will conflict in the registry. IIRC using the 
more recent autopano expandos in 0.8 will result in hugin 0.7 passing a 
wrong input to autopano in 0.7.

> SHELF-LIFE
> 
> Hugin is under constant development, and the code evolves rapidly.
> Nevertheless, stable releases like this are not very frequent. If you
> are looking for newer features or the latest cutting edge development
> snapshots, and are willing to accept all the risks involved, look for
> them at Yuval Levy's page: <http://panospace.wordpress.com/downloads/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias | 1 Aug 2009 09:02
Picon

Re: Error during stiching


Bruno

Thank a lot - ill give it a try!

best regards

Tobias

Den 31/07/2009 kl. 23.14 skrev Bruno Postle <bruno <at> postle.net>:

>
> On Fri 31-Jul-2009 at 06:29 -0700, Tobias wrote:
>>
>> /var/folders/9E/9Ezie6nhGJSQ3UJQe3N7Vk+++TI/-Tmp-/huginmk_3i6Rri:179:
>> *** target pattern contains no `%'.  Stop.
>
> This is a bug triggered by a : (colon) in a file path.  You need to
> rename some files or folders.
>
> There is also an OS X bug with the same symptoms, apparently related
> to the path separator in OS X sometimes being : instead of /
>
> --  
> Bruno
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic
(Continue reading)

Permalink | Reply | 0 comments |
headers
T. Modes | 1 Aug 2009 10:32
Picon
Picon

Re: Libpano locale fix


Hi Daniel,

> I have looked at the patch and this is the improper way to deal with
> this problem. It modifies a bunch of functions to reset the locale. It
> is too cross-cutting. Have you looked at the patch?
>
> It is basically ~40 insertions of this code:
>
> +        setlocale(LC_ALL,old_locale);
> +        free(old_locale);
>

I don't agree. Libpano changes the locale in some function (call of
setlocale(LC_ALL,"C") mainly in parser.c), but does not restore the
old value at the end. This is no clean coding. When you change a
global setting in a function you should also restore the old value at
the end (this is the main function of the inserted lines).

> I suspect it would be easier to reset the locale in hugin after the
> panotools functions are called. that is just once place, compared to the
> 40 places that this patch would modify in libpano.

This would go, but it should only be a workaround.

Thomas
--~--~---------~--~----~------------~-------~--~----~
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
(Continue reading)

Permalink | Reply | 3 comments |
headers
dmg | 1 Aug 2009 10:41
Picon
Picon
Favicon

Re: Libpano locale fix


On Sat, Aug 1, 2009 at 1:32 AM, T. Modes<Thomas.Modes <at> gmx.de> wrote:
>
> I don't agree. Libpano changes the locale in some function (call of
> setlocale(LC_ALL,"C") mainly in parser.c), but does not restore the
> old value at the end. This is no clean coding. When you change a
> global setting in a function you should also restore the old value at
> the end (this is the main function of the inserted lines).
>

I agree that libpano is wrong in doing this. But I rather remove the setlocale
than adding 40 setlocales in _every return_.

--

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

Permalink | Reply | 2 comments |
headers
T. Modes | 1 Aug 2009 10:56
Picon
Picon

Re: Libpano locale fix


> I agree that libpano is wrong in doing this. But I rather remove the setlocale
> than adding 40 setlocales in _every return_.

I don't know if this will always work. I think, the setlocale is added
for correct reading and write of floats (always with point as decimal
separator). When you remove the call of setlocale you will probably
end up with some files with points and other with comma as decimal
separator.
Or do you use a own function to handle to conversion of float to
string and vice versa with correct interpreation of decimal separator?

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

Gmane