[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[RueiKe]

Ryan,

Re OoM:  My test run with "-m 1000" did not get the out oe memory
error, but afterward I tested again with "-m 2000" and got the same
out of memory error - St9bad_alloc.  I have always used "-m 2000" or "-
m 3000" in the past with 32bit builds.  I use "-m 8000" for 64bit
builds.  One other error is after making the final image with "-m
1000", it gets an error when deleting the working files.

I will try 2009.2 later tonight for the GPU issue...

Regards,
Rick



On Nov 2, 11:11 pm, RueiKe  wrote:
> Hi Ryan,
>
> Re OoM:  I was not able to get enblend to work, even by setting "-m
> 2000".  I usually use "-m 3000" for 32bit windows version.  I am
> trying it again with "-m 1000"... I will report back in the morning.
> I don't know of a way to change disk cache settings.  I assumed hugin
> just used as much as it needed.
>
> Re GPU: SInce enblend did not run on most images, I asumed the problem
> was with Nona.  If this feature is available in Allard's 2009.2 build,
> I could give it a try tomorrow.
>
> Regards,
> Rick
>
> On Nov 2, 10:22 pm, Ryan  wrote:
>
>
>
> > Hi Rick,
>
> > Re: i18n: It sounds like wxWidgets+unicode support was the magic
> > combination -- I strongly suspect somebody just forgot to i18n-ize
> > those few spots in the GUI.
>
> > Re OoM: I couldn't tell from your previous emails: were you able to
> > work around the error by setting -m smaller and/or increasing the disk
> > cache size?
>
> > Re GPU: Yes, the question is whether something is broken about GPU
> > +enblend+win32. It seems that CPU+enblend+win32 works, and GPU+preview
> > +win32 works, and GPU+enblend+linux works, which makes me suspect
> > there's simply a problem with enblend's GPU code under windows. AFAIK
> > mine is the only enblend+GPU+win32 in the wild. Allard's MSCV 2009.2
> > build uses the version of enblend that shipped with 0.7, and the
> > official 3.2 build from Sourceforge doesn't seem to use GPU (links
> > only to user32.dll and kernel32.dll).
>
> > If somebody could tell me what it takes to integrate an enblend-4.0
> > snapshot with hugin I'm game. I just need to know:
> > 1. How to download an enblend-4.0 snapshot -- the sourceforge site
> > doesn't make it obvious
> > 2. What hugin code needs to change to handle the changes to command-
> > line args in enblend-4.0 vs older releases.
>
> > Meanwhile, just to be sure, perhaps you could download the official
> > win32 enblend/enfuse from Sourceforge and see what happens with a GPU
> > stitch.
>
> > Regards,
> > Ryan
>
> > On Nov 2, 2:37 pm, RueiKe  wrote:
>
> > > Hi Yuv,
>
> > > Yes, that is the option I used for the test case that gave the out of
> > > memory error.  I think Ryan's comment was concerning if the error I
> > > observed was specific to his build.
>
> > > Regards,
> > > Rick
>
> > > On Nov 2, 9:24 pm, Yuval Levy  wrote:
>
> > > > Hi Rick,
>
> > > > RueiKe wrote:
> > > > > Re GPU:  This is the first time I have tested the GPU option.  If
> > > > > there is another build to try for comparison, just send me a link and
> > > > > I will give it a try.
>
> > > > to compare the GPU option with the traditional CPU stitching, just
> > > > enable/disable GPU stitching in the preferences setting.
>
> > > > Yuv- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Yuval Levy]

Hi Ryan,

Ryan wrote:
> Re mingw support/cmake: I extended a couple of Find* modules to make
> fewer assumptions about locations of libraries (ie, they now respect
> CMAKE_PREFIX_PATH), but they should be compatible changes. Similarly,
> I moved the definition of EVT_CPEVENT to the .cpp file where it
> actually gets used to avoid some linker issues. Any hope of that sort
> of change making it into trunk?

Absolutely! The process is to let the patches undergo a little basic 
testing (just to ensure that they don't break anything existing 
unintentionally). Then they can go to trunk.

The best practice is to post the patches to the patches tracker [0], or 
to branch out a development codeline in SVN. Once we see your 
Sourceforge user ID in the patches tracker, one of the admins can give 
you write access to trunk. It is then left to your sense of 
responsibility to have your patches undergo the basic testing 
(basically: ask here on the list for people with other platforms to test 
them in their builds) and integrate them into trunk. When in doubt, ask.

The most important policy is [1] (the link may not work immediately)

welcome to the team.
Yuv


[0] http://sourceforge.net/tracker/?group_id=77506&atid=550443
[1] http://hugin.sourceforge.net/community/charter/
> 
> Regards,
> Ryan
> 
> On Nov 2, 5:19 pm, Yuval Levy  wrote:
>> T. Modes wrote:
>>> Hi Yuv
>>> some weeks again, you wrote (http://groups.google.com/group/hugin-ptx/
>>> msg/06ce8acea695ef21):
> Finally copy glut32.dll to hugin/bin-folder.
 the current policy for the windows binary is to avoid DLHell and link
 statically. This should not be too difficult to fix.
>>> But now it's:
 Using a prebuilt
 glut32.dll should be fine.
>>> Has the policy changed since August?
>> the policy has not changed. "Should be fine" only means that it does not
>> make sense to make life difficult at the moment.
>>
>> Should be fine to solve the problem at hand.
>>
>> Once the problem at hand is solved, look at the next steps. One of the
>> next steps may be to move to static builds.
>>
>> I can only recommend the static build policy, but if Ryan (or anyone
>> else) decides to go the dynamic linking way, they are free to do so.
>>
>> As long as it does not stand in the way of the officially supported way
>> of building Hugin (CMake / MSVC / static) I won't stand in their
>> effort's way.
>>
>> Currently mingw is not an officially supported way of building Hugin.
>> This does not mean that it is forbidden, it only means that if the mingw
>> build breaks, it's tough luck for those dependent on it (while if the
>> MSVC build breaks, it is a show stopper).
>>
>> The static linking policy has consequences on what is checked into trunk
>> with regard to the CMake build. If the changes for Windows dynamic
>> linking are conflicting with the choices in trunk, they can be
>> maintained as a separate set of patches, or even branched out as
>> separate SVN codeline.
>>
>> It also has consequences on support. I am less inclined to deal with
>> support requests ensuing from missing DLL problems and reserve myself
>> the right to mark such bug reports as invalid and close them.
>>
>> In short: policy is not about allowed and forbidden; it is about
>> supported and unsupported; and about priorities in case of trade offs.
>>
>> As you can see from this thread, even if mingw is not officially
>> supported, it gets attention.
>>
>> You may wonder about my personal priorities (giving support to Ryan's
>> unsupported effort while people are waiting for the RC3 release).
>>
>> In terms of my personal priorities, mingw has much less priority than
>> MSVC; but a person that is mostly self-sufficient and moves forward
>> proactively has higher priority than passive consumers. And when mixing
>> the two, people are more important than code.
>>
>> Policies are easier to change than attitudes. I welcome people with
>> Ryan's attitude, and in my choice of how to allocate my time I am more
>> inclined to help him than to fix and release RC3.
>>
>> 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: *IMPORTANT* Credits

[Erik Krause]

Carl von Einem wrote:

> This works:
> 

Thanks!

And thanks for listing me with my very minor droplets. However, my main 
intent where the enfuse droplets, the enblend ones where a mere byproduct...

best regards
-- 
Erik Krause
http://www.erik-krause.de

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: *IMPORTANT* Credits

[Yuval Levy]

Erik Krause wrote:
> Bruno Postle wrote:
> 
>>  http://hugin.sourceforge.net/community/authors/
> 
> This URL throws a 403 error. Is this intended? Or is it just me?

it's me, sorry.

more precisely my fixes who do not work yet.

I'll make it work sooner or later. I'm starting to *hate* how the 
current website is set up. I found no way to test it locally, so I have 
to go through the SVN update cycle and see what comes out on the other 
end before making further changes, which usually means that my time 
allocated for the task is already long over and I'm somewhere else. 
Frustrating...

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: *IMPORTANT* Credits

[Carl von Einem]

I also think that this would be a better address.

This works:


Another broken URL is "available" from the TOC on
http://hugin.sourceforge.net/ -> Community


Erik Krause schrieb am 02.11.2009 21:31 Uhr:
> Bruno Postle wrote:
> 
>>  http://hugin.sourceforge.net/community/authors/
> 
> This URL throws a 403 error. Is this intended? Or is it just me?

--~--~-~--~~~---~--~~
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: *IMPORTANT* Credits

[Erik Krause]

Bruno Postle wrote:

>  http://hugin.sourceforge.net/community/authors/

This URL throws a 403 error. Is this intended? Or is it just me?

best regards
-- 
Erik Krause
http://www.erik-krause.de

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Ryan]

Hi all,

Re enblend-4.0: Thanks for the pointer (and the reassurance that most
of the outstanding wrinkles have been ironed out). I'll try pulling it
down next time I have a chance. However, it sounds like nona, not
enblend is actually the culprit wrt GPU. It links against opengl,
glut, and glew, so there's definitely plenty of room for trouble. It
will be interesting to see how Allard's build behaves for Rick.

Re OoM: The hugin disk cache setting lives in the main preferences
pane. It defaults to 64MB and on my machine is set to 256MB, but I
assume you could set it larger; I don't know whether "OoM" errors
might actually be due to a too-small disk cache overflowing.

Re static builds: I actually missed the "no dynamic library" policy --
I just figured any dll needed to be in the bin/ folder to avoid
versioning problems. "This should not be too difficult to fix" (other
than maybe libglut.a, which I had issues building).

Re mingw support/cmake: I extended a couple of Find* modules to make
fewer assumptions about locations of libraries (ie, they now respect
CMAKE_PREFIX_PATH), but they should be compatible changes. Similarly,
I moved the definition of EVT_CPEVENT to the .cpp file where it
actually gets used to avoid some linker issues. Any hope of that sort
of change making it into trunk?

Regards,
Ryan

On Nov 2, 5:19 pm, Yuval Levy  wrote:
> T. Modes wrote:
> > Hi Yuv
>
> > some weeks again, you wrote (http://groups.google.com/group/hugin-ptx/
> > msg/06ce8acea695ef21):
>
> >>> Finally copy glut32.dll to hugin/bin-folder.
> >> the current policy for the windows binary is to avoid DLHell and link
> >> statically. This should not be too difficult to fix.
>
> > But now it's:
> >> Using a prebuilt
> >> glut32.dll should be fine.
>
> > Has the policy changed since August?
>
> the policy has not changed. "Should be fine" only means that it does not
> make sense to make life difficult at the moment.
>
> Should be fine to solve the problem at hand.
>
> Once the problem at hand is solved, look at the next steps. One of the
> next steps may be to move to static builds.
>
> I can only recommend the static build policy, but if Ryan (or anyone
> else) decides to go the dynamic linking way, they are free to do so.
>
> As long as it does not stand in the way of the officially supported way
> of building Hugin (CMake / MSVC / static) I won't stand in their
> effort's way.
>
> Currently mingw is not an officially supported way of building Hugin.
> This does not mean that it is forbidden, it only means that if the mingw
> build breaks, it's tough luck for those dependent on it (while if the
> MSVC build breaks, it is a show stopper).
>
> The static linking policy has consequences on what is checked into trunk
> with regard to the CMake build. If the changes for Windows dynamic
> linking are conflicting with the choices in trunk, they can be
> maintained as a separate set of patches, or even branched out as
> separate SVN codeline.
>
> It also has consequences on support. I am less inclined to deal with
> support requests ensuing from missing DLL problems and reserve myself
> the right to mark such bug reports as invalid and close them.
>
> In short: policy is not about allowed and forbidden; it is about
> supported and unsupported; and about priorities in case of trade offs.
>
> As you can see from this thread, even if mingw is not officially
> supported, it gets attention.
>
> You may wonder about my personal priorities (giving support to Ryan's
> unsupported effort while people are waiting for the RC3 release).
>
> In terms of my personal priorities, mingw has much less priority than
> MSVC; but a person that is mostly self-sufficient and moves forward
> proactively has higher priority than passive consumers. And when mixing
> the two, people are more important than code.
>
> Policies are easier to change than attitudes. I welcome people with
> Ryan's attitude, and in my choice of how to allocate my time I am more
> inclined to help him than to fix and release RC3.
>
> Yuv
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Yuval Levy]

T. Modes wrote:
> Hi Yuv
> 
> some weeks again, you wrote (http://groups.google.com/group/hugin-ptx/
> msg/06ce8acea695ef21):
> 
>>> Finally copy glut32.dll to hugin/bin-folder.
>> the current policy for the windows binary is to avoid DLHell and link
>> statically. This should not be too difficult to fix.
> 
> But now it's:
>> Using a prebuilt
>> glut32.dll should be fine.
> 
> Has the policy changed since August?

the policy has not changed. "Should be fine" only means that it does not 
make sense to make life difficult at the moment.

Should be fine to solve the problem at hand.

Once the problem at hand is solved, look at the next steps. One of the 
next steps may be to move to static builds.

I can only recommend the static build policy, but if Ryan (or anyone 
else) decides to go the dynamic linking way, they are free to do so.

As long as it does not stand in the way of the officially supported way 
of building Hugin (CMake / MSVC / static) I won't stand in their 
effort's way.

Currently mingw is not an officially supported way of building Hugin. 
This does not mean that it is forbidden, it only means that if the mingw 
build breaks, it's tough luck for those dependent on it (while if the 
MSVC build breaks, it is a show stopper).

The static linking policy has consequences on what is checked into trunk 
with regard to the CMake build. If the changes for Windows dynamic 
linking are conflicting with the choices in trunk, they can be 
maintained as a separate set of patches, or even branched out as 
separate SVN codeline.

It also has consequences on support. I am less inclined to deal with 
support requests ensuing from missing DLL problems and reserve myself 
the right to mark such bug reports as invalid and close them.

In short: policy is not about allowed and forbidden; it is about 
supported and unsupported; and about priorities in case of trade offs.

As you can see from this thread, even if mingw is not officially 
supported, it gets attention.

You may wonder about my personal priorities (giving support to Ryan's 
unsupported effort while people are waiting for the RC3 release).

In terms of my personal priorities, mingw has much less priority than 
MSVC; but a person that is mostly self-sufficient and moves forward 
proactively has higher priority than passive consumers. And when mixing 
the two, people are more important than code.

Policies are easier to change than attitudes. I welcome people with 
Ryan's attitude, and in my choice of how to allocate my time I am more 
inclined to help him than to fix and release RC3.

Yuv


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[T. Modes]

Hi Yuv

some weeks again, you wrote (http://groups.google.com/group/hugin-ptx/
msg/06ce8acea695ef21):

>> Finally copy glut32.dll to hugin/bin-folder.
>
>the current policy for the windows binary is to avoid DLHell and link
>statically. This should not be too difficult to fix.

But now it's:
> Using a prebuilt
> glut32.dll should be fine.

Has the policy changed since August?


>> 2. What hugin code needs to change to handle the changes to command-
>> line args in enblend-4.0 vs older releases.
>
>don't worry about this. in theory there should be no changes. in
>practice and IIRC there are a couple of bugs that have not been fixed
>yet that may affect 360°x180° panoramas - not critical for testing other
>test cases.

These points should be fixed the current enblend repository.

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

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[RueiKe]

Hi Ryan,

Re OoM:  I was not able to get enblend to work, even by setting "-m
2000".  I usually use "-m 3000" for 32bit windows version.  I am
trying it again with "-m 1000"... I will report back in the morning.
I don't know of a way to change disk cache settings.  I assumed hugin
just used as much as it needed.

Re GPU: SInce enblend did not run on most images, I asumed the problem
was with Nona.  If this feature is available in Allard's 2009.2 build,
I could give it a try tomorrow.

Regards,
Rick

On Nov 2, 10:22 pm, Ryan  wrote:
> Hi Rick,
>
> Re: i18n: It sounds like wxWidgets+unicode support was the magic
> combination -- I strongly suspect somebody just forgot to i18n-ize
> those few spots in the GUI.
>
> Re OoM: I couldn't tell from your previous emails: were you able to
> work around the error by setting -m smaller and/or increasing the disk
> cache size?
>
> Re GPU: Yes, the question is whether something is broken about GPU
> +enblend+win32. It seems that CPU+enblend+win32 works, and GPU+preview
> +win32 works, and GPU+enblend+linux works, which makes me suspect
> there's simply a problem with enblend's GPU code under windows. AFAIK
> mine is the only enblend+GPU+win32 in the wild. Allard's MSCV 2009.2
> build uses the version of enblend that shipped with 0.7, and the
> official 3.2 build from Sourceforge doesn't seem to use GPU (links
> only to user32.dll and kernel32.dll).
>
> If somebody could tell me what it takes to integrate an enblend-4.0
> snapshot with hugin I'm game. I just need to know:
> 1. How to download an enblend-4.0 snapshot -- the sourceforge site
> doesn't make it obvious
> 2. What hugin code needs to change to handle the changes to command-
> line args in enblend-4.0 vs older releases.
>
> Meanwhile, just to be sure, perhaps you could download the official
> win32 enblend/enfuse from Sourceforge and see what happens with a GPU
> stitch.
>
> Regards,
> Ryan
>
> On Nov 2, 2:37 pm, RueiKe  wrote:
>
>
>
> > Hi Yuv,
>
> > Yes, that is the option I used for the test case that gave the out of
> > memory error.  I think Ryan's comment was concerning if the error I
> > observed was specific to his build.
>
> > Regards,
> > Rick
>
> > On Nov 2, 9:24 pm, Yuval Levy  wrote:
>
> > > Hi Rick,
>
> > > RueiKe wrote:
> > > > Re GPU:  This is the first time I have tested the GPU option.  If
> > > > there is another build to try for comparison, just send me a link and
> > > > I will give it a try.
>
> > > to compare the GPU option with the traditional CPU stitching, just
> > > enable/disable GPU stitching in the preferences setting.
>
> > > Yuv- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Yuval Levy]

Hi Ryan,

Ryan wrote:
> If somebody could tell me what it takes to integrate an enblend-4.0
> snapshot with hugin I'm game. I just need to know:
> 1. How to download an enblend-4.0 snapshot -- the sourceforge site
> doesn't make it obvious

you need mercurial. get TortoiseHg and follow the instructions on [0]


> 2. What hugin code needs to change to handle the changes to command-
> line args in enblend-4.0 vs older releases.

don't worry about this. in theory there should be no changes. in 
practice and IIRC there are a couple of bugs that have not been fixed 
yet that may affect 360°x180° panoramas - not critical for testing other 
test cases.

Yuv

[0] http://wiki.panotools.org/Build_Hugin_for_Windows_with_SDK#Build_enblend

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Yuval Levy]

Hi Ryan,

Ryan wrote:
> Now it's time for my ignorance to show through a bit :)

I did not find any sign of ignorance in the message - just well 
formulated analysis and questions that bring the project further.


> I just figured out that wxWidgets was built without Unicode support

IIRC there were issues with Unicode / Windows which forced us e.g. to 
use ISO-8859-1 in the XRC files, which in turns is a pain in the neck 
because many XRC editors only support UTF-8. Any solution that helps 
make the Windows build more UTF-8 compliant is welcome.


> Re OoM: I built enblend-enfuse with image cache enabled (well, the
> configure script said so, at least... no way to query the binary
> afaik). On my machine the cache (in hugin's preferences) defaults to a
> piddling 256MB, though, which would probably cause problems

enblend-enfuse are independent from Hugin's cache preferences. Hugin 
only composes the command line that executes either enblend or enfuse.


> Re GPU: Unfortunately I don't have a access to a good enough GPU to
> even explore this issue, but how general is the problem? It doesn't
> seem to affect linux users, but what about the MSVC port of hugin? I
> ask because none of my porting effort touched GPU-related stuff; glew
> has explicit build-time support for cygming systems (in addition to
> cygwin and mingw32), and I used a prebuilt glut32.dll.

My hardware situation is similar to yours, Ryan. From observations 
reported by others the problem does not seem to be a platform (Windows / 
Linux) issue but rather a hardware or driver issue. I am not sure about 
the influence of the toolchain (MSVC vs. mingw). Using a prebuilt 
glut32.dll should be fine. A few weeks back I published an MSVC built 
nona-gpu for Windows. I don't recall the URL, should be somewhere in 
this list's archives.

Yuv

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Ryan]

Hmm... definitely try the official windows build of enblend-3.2. I
just checked my libtiff, which claims to have GPU support baked in,
and it doesn't depend on any graphics-related dlls either.

Ryan

On Nov 2, 3:22 pm, Ryan  wrote:
> Hi Rick,
>
> Re: i18n: It sounds like wxWidgets+unicode support was the magic
> combination -- I strongly suspect somebody just forgot to i18n-ize
> those few spots in the GUI.
>
> Re OoM: I couldn't tell from your previous emails: were you able to
> work around the error by setting -m smaller and/or increasing the disk
> cache size?
>
> Re GPU: Yes, the question is whether something is broken about GPU
> +enblend+win32. It seems that CPU+enblend+win32 works, and GPU+preview
> +win32 works, and GPU+enblend+linux works, which makes me suspect
> there's simply a problem with enblend's GPU code under windows. AFAIK
> mine is the only enblend+GPU+win32 in the wild. Allard's MSCV 2009.2
> build uses the version of enblend that shipped with 0.7, and the
> official 3.2 build from Sourceforge doesn't seem to use GPU (links
> only to user32.dll and kernel32.dll).
>
> If somebody could tell me what it takes to integrate an enblend-4.0
> snapshot with hugin I'm game. I just need to know:
> 1. How to download an enblend-4.0 snapshot -- the sourceforge site
> doesn't make it obvious
> 2. What hugin code needs to change to handle the changes to command-
> line args in enblend-4.0 vs older releases.
>
> Meanwhile, just to be sure, perhaps you could download the official
> win32 enblend/enfuse from Sourceforge and see what happens with a GPU
> stitch.
>
> Regards,
> Ryan
>
> On Nov 2, 2:37 pm, RueiKe  wrote:
>
> > Hi Yuv,
>
> > Yes, that is the option I used for the test case that gave the out of
> > memory error.  I think Ryan's comment was concerning if the error I
> > observed was specific to his build.
>
> > Regards,
> > Rick
>
> > On Nov 2, 9:24 pm, Yuval Levy  wrote:
>
> > > Hi Rick,
>
> > > RueiKe wrote:
> > > > Re GPU:  This is the first time I have tested the GPU option.  If
> > > > there is another build to try for comparison, just send me a link and
> > > > I will give it a try.
>
> > > to compare the GPU option with the traditional CPU stitching, just
> > > enable/disable GPU stitching in the preferences setting.
>
> > > Yuv
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Ryan]

Hi Rick,

Re: i18n: It sounds like wxWidgets+unicode support was the magic
combination -- I strongly suspect somebody just forgot to i18n-ize
those few spots in the GUI.

Re OoM: I couldn't tell from your previous emails: were you able to
work around the error by setting -m smaller and/or increasing the disk
cache size?

Re GPU: Yes, the question is whether something is broken about GPU
+enblend+win32. It seems that CPU+enblend+win32 works, and GPU+preview
+win32 works, and GPU+enblend+linux works, which makes me suspect
there's simply a problem with enblend's GPU code under windows. AFAIK
mine is the only enblend+GPU+win32 in the wild. Allard's MSCV 2009.2
build uses the version of enblend that shipped with 0.7, and the
official 3.2 build from Sourceforge doesn't seem to use GPU (links
only to user32.dll and kernel32.dll).

If somebody could tell me what it takes to integrate an enblend-4.0
snapshot with hugin I'm game. I just need to know:
1. How to download an enblend-4.0 snapshot -- the sourceforge site
doesn't make it obvious
2. What hugin code needs to change to handle the changes to command-
line args in enblend-4.0 vs older releases.

Meanwhile, just to be sure, perhaps you could download the official
win32 enblend/enfuse from Sourceforge and see what happens with a GPU
stitch.

Regards,
Ryan

On Nov 2, 2:37 pm, RueiKe  wrote:
> Hi Yuv,
>
> Yes, that is the option I used for the test case that gave the out of
> memory error.  I think Ryan's comment was concerning if the error I
> observed was specific to his build.
>
> Regards,
> Rick
>
> On Nov 2, 9:24 pm, Yuval Levy  wrote:
>
> > Hi Rick,
>
> > RueiKe wrote:
> > > Re GPU:  This is the first time I have tested the GPU option.  If
> > > there is another build to try for comparison, just send me a link and
> > > I will give it a try.
>
> > to compare the GPU option with the traditional CPU stitching, just
> > enable/disable GPU stitching in the preferences setting.
>
> > Yuv
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[RueiKe]

Hi Yuv,

Yes, that is the option I used for the test case that gave the out of
memory error.  I think Ryan's comment was concerning if the error I
observed was specific to his build.

Regards,
Rick

On Nov 2, 9:24 pm, Yuval Levy  wrote:
> Hi Rick,
>
> RueiKe wrote:
> > Re GPU:  This is the first time I have tested the GPU option.  If
> > there is another build to try for comparison, just send me a link and
> > I will give it a try.
>
> to compare the GPU option with the traditional CPU stitching, just
> enable/disable GPU stitching in the preferences setting.
>
> Yuv
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[RueiKe]

Hi Ryan,

I ran through my workflow with no unicode related errors.

Maybe not something your are working on, but just to thoroughly
document my observations, the following items are not translated:

"Loading images" - bottom of main window after opening project
"Cancel"  - button on fine tune all points status dialog box
"OK" - button on fine tune all points complete dialog box
"Strategy.." and other text of the optimizer status window
"YES" and "NO" buttons of optimizer dialog box
"Optimizing variables" of the optimizer status box
"YES" and "NO" buttons of exposure dialog box about linked parameters
"OK" and "Cancel" buttons of the exposure "number of pixels" dialog
box
"Cancel"  - button on expsosure status dialog box
"YES" and "NO" buttons of exposure dialog box about applying results
"Cancel"  - button on Align status dialog box
All text except dialog box name for filename selection after pressing
Stitch now.

Regards,
Rick

On Nov 2, 7:20 pm, RueiKe  wrote:
> Hi Ryan,
>
> I just tried the latest build and Chinese Traditional now works!  I
> probably need to run through a full test case to make sure there are
> no unicode issues (early builds of 0.8.0 had some that were cleaned up
> before release).  I will report back when complete.
>
> Regards,
> Rick
>
> On Nov 2, 6:47 pm, RueiKe  wrote:
>
>
>
> > Hi Ryan,
>
> > Re i18n: I am downloading the new version now.  I am using Vista in
> > English with the Traditional Chinese Language pack.  I don't any
> > errors; it just ignores the setting.  I have tried spanish and it
> > works fine.  I will post an update when I try your latest.
>
> > Re OoM:  The error I am getting is the same error I got in the past
> > when setting the memory cache size too large.  For this case, I set it
> > to 2GB (-m 2000).  I think a small setting should not cause a problem,
> > it should just go to disk cache.
>
> > Re GPU:  This is the first time I have tested the GPU option.  If
> > there is another build to try for comparison, just send me a link and
> > I will give it a try.
>
> > Regards,
> > Rick
>
> > On Nov 2, 5:45 pm, Ryan  wrote:
>
> > > Hi Rick,
>
> > > Can you try this version 
> > > out:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-uni...
>
> > > I think my machine must not have the Asian language packs installed
> > > because it still can't change the locale, but the binaries are now 3MB
> > > bigger compressed, so I'm pretty sure unicode is really there.
>
> > > Regards,
> > > Ryan
>
> > > On Nov 1, 5:34 am, RueiKe  wrote:
>
> > > > Hi Ryan,
>
> > > > I have finished running the first test case for hugin-2009.4.0_rc2-
> > > > win32-cygming-bin.zip.
>
> > > > Platform: Windows Vista 64bit on an i7 with 12GB memory and an ATI
> > > > Radeon HD 4800 series graphics card.
>
> > > > Project: 31 image 360x180 equirectangular projection aligned with
> > > > 7,129 control points.  No exposure bracketing in this project.
>
> > > > Observations:
> > > > GUI - Looks good.  Only concern found is it is in English even when
> > > > Chinese is selected.
> > > > Load images - No issues
> > > > Add Control Points - I used Autopano-sift-c with "--maxdim 4000 --
> > > > projection %f,%v --maxmatches %p %o %i" arguments.  It worked fine and
> > > > added as many control points as 2009.2 (Allard's build).  I found a
> > > > previous build of 2009.4 did not generate any control points when --
> > > > maxdim 4000 is specified, but this build doesn't have the issue/
> > > > Align - No problem
> > > > Fine Tune All control points - No issues
> > > > Control Point table - No problem, I removed bad control points with no
> > > > issues
> > > > Optimizer - No problems for position and everything
> > > > Exposure - No issues with Low Dynamic range 1000 points per image.
> > > > Stitching - Used Calculate Optimal Size -> 15,288 x 7,559.  Problems
> > > > in stitching a "Blended Panorama" for both with and without GPU:
> > > >    Without GPU - Out of memory error even with the arguments: -m 2000 -
> > > > b 4000
> > > >    With GPU - No errors, but during enblend most images were indicated
> > > > as redundant and not included in final image.  Final image was a large
> > > > file with the dimensions specified in "Calculate Optimal Size", but
> > > > was transparent except for an area the size and shape of the image
> > > > anchored for position.  The area was the same size as that component
> > > > image, but it had other images blended incorrectly into it.
>
> > > > Let me know if you need any other details,
>
> > > > Regards,
> > > > Rick
>
> > > > On Nov 1, 9:22 am, RueiKe  wrote:
>
> > > > > Hi Ryan,
>
> > > > > I am still working through my test case, but one observed issue so far
> > > > > is that the interface is in English even when I select Traditional
> > > > > Chinese.  I am running this out of the directory where I unzipped it
> > > > > to, so maybe this is part of the issue.
>
> > > > > Regards,
> > > > > Rick
>
> > > > > On Oct 31, 8:51 pm, Ryan  wrote:
>
>

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Yuval Levy]

Hi Rick,

RueiKe wrote:
> Re GPU:  This is the first time I have tested the GPU option.  If
> there is another build to try for comparison, just send me a link and
> I will give it a try.

to compare the GPU option with the traditional CPU stitching, just 
enable/disable GPU stitching in the preferences setting.

Yuv

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[RueiKe]

Hi Ryan,

I just tried the latest build and Chinese Traditional now works!  I
probably need to run through a full test case to make sure there are
no unicode issues (early builds of 0.8.0 had some that were cleaned up
before release).  I will report back when complete.

Regards,
Rick

On Nov 2, 6:47 pm, RueiKe  wrote:
> Hi Ryan,
>
> Re i18n: I am downloading the new version now.  I am using Vista in
> English with the Traditional Chinese Language pack.  I don't any
> errors; it just ignores the setting.  I have tried spanish and it
> works fine.  I will post an update when I try your latest.
>
> Re OoM:  The error I am getting is the same error I got in the past
> when setting the memory cache size too large.  For this case, I set it
> to 2GB (-m 2000).  I think a small setting should not cause a problem,
> it should just go to disk cache.
>
> Re GPU:  This is the first time I have tested the GPU option.  If
> there is another build to try for comparison, just send me a link and
> I will give it a try.
>
> Regards,
> Rick
>
> On Nov 2, 5:45 pm, Ryan  wrote:
>
>
>
> > Hi Rick,
>
> > Can you try this version 
> > out:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-uni...
>
> > I think my machine must not have the Asian language packs installed
> > because it still can't change the locale, but the binaries are now 3MB
> > bigger compressed, so I'm pretty sure unicode is really there.
>
> > Regards,
> > Ryan
>
> > On Nov 1, 5:34 am, RueiKe  wrote:
>
> > > Hi Ryan,
>
> > > I have finished running the first test case for hugin-2009.4.0_rc2-
> > > win32-cygming-bin.zip.
>
> > > Platform: Windows Vista 64bit on an i7 with 12GB memory and an ATI
> > > Radeon HD 4800 series graphics card.
>
> > > Project: 31 image 360x180 equirectangular projection aligned with
> > > 7,129 control points.  No exposure bracketing in this project.
>
> > > Observations:
> > > GUI - Looks good.  Only concern found is it is in English even when
> > > Chinese is selected.
> > > Load images - No issues
> > > Add Control Points - I used Autopano-sift-c with "--maxdim 4000 --
> > > projection %f,%v --maxmatches %p %o %i" arguments.  It worked fine and
> > > added as many control points as 2009.2 (Allard's build).  I found a
> > > previous build of 2009.4 did not generate any control points when --
> > > maxdim 4000 is specified, but this build doesn't have the issue/
> > > Align - No problem
> > > Fine Tune All control points - No issues
> > > Control Point table - No problem, I removed bad control points with no
> > > issues
> > > Optimizer - No problems for position and everything
> > > Exposure - No issues with Low Dynamic range 1000 points per image.
> > > Stitching - Used Calculate Optimal Size -> 15,288 x 7,559.  Problems
> > > in stitching a "Blended Panorama" for both with and without GPU:
> > >    Without GPU - Out of memory error even with the arguments: -m 2000 -
> > > b 4000
> > >    With GPU - No errors, but during enblend most images were indicated
> > > as redundant and not included in final image.  Final image was a large
> > > file with the dimensions specified in "Calculate Optimal Size", but
> > > was transparent except for an area the size and shape of the image
> > > anchored for position.  The area was the same size as that component
> > > image, but it had other images blended incorrectly into it.
>
> > > Let me know if you need any other details,
>
> > > Regards,
> > > Rick
>
> > > On Nov 1, 9:22 am, RueiKe  wrote:
>
> > > > Hi Ryan,
>
> > > > I am still working through my test case, but one observed issue so far
> > > > is that the interface is in English even when I select Traditional
> > > > Chinese.  I am running this out of the directory where I unzipped it
> > > > to, so maybe this is part of the issue.
>
> > > > Regards,
> > > > Rick
>
> > > > On Oct 31, 8:51 pm, Ryan  wrote:
>
> > > > > Correction to the 
> > > > > URLs:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cyg..
>
> > > > > Thanks,
> > > > > Ryan
>
> > > > > On Oct 31, 10:41 am, Ryan  wrote:
>
> > > > > > Hi all,
>
> > > > > > hugin-2009.4.0-rc2-win32-cygming-bin.zip is now available 
> > > > > > atftp://hugin.panotools.org/public_html/testing/hugin/. It works 
> > > > > > out of
> > > > > > the box -- just unzip and run hugin/bin/hugin.exe -- and there are 
> > > > > > no
> > > > > > dependencies on either cygwin or the location it unzips to.
>
> > > > > > In addition, autopano-sift-C-2.5.1_rc2-win32-cygming-bin.zip is
> > > > > > available for people who aren't troubled by patent issues. Just 
> > > > > > unzip
> > > > > > it to the same directory that the hugin-*.zip went to and hugin 
> > > > > > should
> > > > > > be able to use it (it's not a stand-alone executable and shares the
> > > > > > same directory hierarchy).
>
> > > > > > Finally, hugin-2009.4.0_rc2-win32-cygming-build.tar.gz contains the
> > > > > > master Makefile and patches which were used to build and package 
> > > > > > hugin/
> > > > >

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[RueiKe]

Hi Ryan,

Re i18n: I am downloading the new version now.  I am using Vista in
English with the Traditional Chinese Language pack.  I don't any
errors; it just ignores the setting.  I have tried spanish and it
works fine.  I will post an update when I try your latest.

Re OoM:  The error I am getting is the same error I got in the past
when setting the memory cache size too large.  For this case, I set it
to 2GB (-m 2000).  I think a small setting should not cause a problem,
it should just go to disk cache.

Re GPU:  This is the first time I have tested the GPU option.  If
there is another build to try for comparison, just send me a link and
I will give it a try.

Regards,
Rick

On Nov 2, 5:45 pm, Ryan  wrote:
> Hi Rick,
>
> Can you try this version 
> out:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-uni...
>
> I think my machine must not have the Asian language packs installed
> because it still can't change the locale, but the binaries are now 3MB
> bigger compressed, so I'm pretty sure unicode is really there.
>
> Regards,
> Ryan
>
> On Nov 1, 5:34 am, RueiKe  wrote:
>
>
>
> > Hi Ryan,
>
> > I have finished running the first test case for hugin-2009.4.0_rc2-
> > win32-cygming-bin.zip.
>
> > Platform: Windows Vista 64bit on an i7 with 12GB memory and an ATI
> > Radeon HD 4800 series graphics card.
>
> > Project: 31 image 360x180 equirectangular projection aligned with
> > 7,129 control points.  No exposure bracketing in this project.
>
> > Observations:
> > GUI - Looks good.  Only concern found is it is in English even when
> > Chinese is selected.
> > Load images - No issues
> > Add Control Points - I used Autopano-sift-c with "--maxdim 4000 --
> > projection %f,%v --maxmatches %p %o %i" arguments.  It worked fine and
> > added as many control points as 2009.2 (Allard's build).  I found a
> > previous build of 2009.4 did not generate any control points when --
> > maxdim 4000 is specified, but this build doesn't have the issue/
> > Align - No problem
> > Fine Tune All control points - No issues
> > Control Point table - No problem, I removed bad control points with no
> > issues
> > Optimizer - No problems for position and everything
> > Exposure - No issues with Low Dynamic range 1000 points per image.
> > Stitching - Used Calculate Optimal Size -> 15,288 x 7,559.  Problems
> > in stitching a "Blended Panorama" for both with and without GPU:
> >    Without GPU - Out of memory error even with the arguments: -m 2000 -
> > b 4000
> >    With GPU - No errors, but during enblend most images were indicated
> > as redundant and not included in final image.  Final image was a large
> > file with the dimensions specified in "Calculate Optimal Size", but
> > was transparent except for an area the size and shape of the image
> > anchored for position.  The area was the same size as that component
> > image, but it had other images blended incorrectly into it.
>
> > Let me know if you need any other details,
>
> > Regards,
> > Rick
>
> > On Nov 1, 9:22 am, RueiKe  wrote:
>
> > > Hi Ryan,
>
> > > I am still working through my test case, but one observed issue so far
> > > is that the interface is in English even when I select Traditional
> > > Chinese.  I am running this out of the directory where I unzipped it
> > > to, so maybe this is part of the issue.
>
> > > Regards,
> > > Rick
>
> > > On Oct 31, 8:51 pm, Ryan  wrote:
>
> > > > Correction to the 
> > > > URLs:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cyg..
>
> > > > Thanks,
> > > > Ryan
>
> > > > On Oct 31, 10:41 am, Ryan  wrote:
>
> > > > > Hi all,
>
> > > > > hugin-2009.4.0-rc2-win32-cygming-bin.zip is now available 
> > > > > atftp://hugin.panotools.org/public_html/testing/hugin/. It works out 
> > > > > of
> > > > > the box -- just unzip and run hugin/bin/hugin.exe -- and there are no
> > > > > dependencies on either cygwin or the location it unzips to.
>
> > > > > In addition, autopano-sift-C-2.5.1_rc2-win32-cygming-bin.zip is
> > > > > available for people who aren't troubled by patent issues. Just unzip
> > > > > it to the same directory that the hugin-*.zip went to and hugin should
> > > > > be able to use it (it's not a stand-alone executable and shares the
> > > > > same directory hierarchy).
>
> > > > > Finally, hugin-2009.4.0_rc2-win32-cygming-build.tar.gz contains the
> > > > > master Makefile and patches which were used to build and package 
> > > > > hugin/
> > > > > autopano.
>
> > > > > It would be interesting if people with "real" workflows could try it
> > > > > out and see (a) whether it really works and (b) how it compares to the
> > > > > MSVC version -- I my biggest panorama only has like seven photos in
> > > > > it, and I don't usually play with multiple lenses or stacks.
>
> > > > > The uploaded version uses
> > > > > - hugin-2009.4.0_rc2
> > > > > - enblend-enfuse-3.2
> > > > > - libpano13-2.9.15_beta3
> > > > > - autopano-sift-C-2.5.1_rc2
>
> > > > > I'm willing to try other versions

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Ryan]

Hi Rick,

Can you try this version out:
http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-unicode-cygming-bin.zip

I think my machine must not have the Asian language packs installed
because it still can't change the locale, but the binaries are now 3MB
bigger compressed, so I'm pretty sure unicode is really there.

Regards,
Ryan


On Nov 1, 5:34 am, RueiKe  wrote:
> Hi Ryan,
>
> I have finished running the first test case for hugin-2009.4.0_rc2-
> win32-cygming-bin.zip.
>
> Platform: Windows Vista 64bit on an i7 with 12GB memory and an ATI
> Radeon HD 4800 series graphics card.
>
> Project: 31 image 360x180 equirectangular projection aligned with
> 7,129 control points.  No exposure bracketing in this project.
>
> Observations:
> GUI - Looks good.  Only concern found is it is in English even when
> Chinese is selected.
> Load images - No issues
> Add Control Points - I used Autopano-sift-c with "--maxdim 4000 --
> projection %f,%v --maxmatches %p %o %i" arguments.  It worked fine and
> added as many control points as 2009.2 (Allard's build).  I found a
> previous build of 2009.4 did not generate any control points when --
> maxdim 4000 is specified, but this build doesn't have the issue/
> Align - No problem
> Fine Tune All control points - No issues
> Control Point table - No problem, I removed bad control points with no
> issues
> Optimizer - No problems for position and everything
> Exposure - No issues with Low Dynamic range 1000 points per image.
> Stitching - Used Calculate Optimal Size -> 15,288 x 7,559.  Problems
> in stitching a "Blended Panorama" for both with and without GPU:
>    Without GPU - Out of memory error even with the arguments: -m 2000 -
> b 4000
>    With GPU - No errors, but during enblend most images were indicated
> as redundant and not included in final image.  Final image was a large
> file with the dimensions specified in "Calculate Optimal Size", but
> was transparent except for an area the size and shape of the image
> anchored for position.  The area was the same size as that component
> image, but it had other images blended incorrectly into it.
>
> Let me know if you need any other details,
>
> Regards,
> Rick
>
> On Nov 1, 9:22 am, RueiKe  wrote:
>
> > Hi Ryan,
>
> > I am still working through my test case, but one observed issue so far
> > is that the interface is in English even when I select Traditional
> > Chinese.  I am running this out of the directory where I unzipped it
> > to, so maybe this is part of the issue.
>
> > Regards,
> > Rick
>
> > On Oct 31, 8:51 pm, Ryan  wrote:
>
> > > Correction to the 
> > > URLs:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cyg..
>
> > > Thanks,
> > > Ryan
>
> > > On Oct 31, 10:41 am, Ryan  wrote:
>
> > > > Hi all,
>
> > > > hugin-2009.4.0-rc2-win32-cygming-bin.zip is now available 
> > > > atftp://hugin.panotools.org/public_html/testing/hugin/. It works out of
> > > > the box -- just unzip and run hugin/bin/hugin.exe -- and there are no
> > > > dependencies on either cygwin or the location it unzips to.
>
> > > > In addition, autopano-sift-C-2.5.1_rc2-win32-cygming-bin.zip is
> > > > available for people who aren't troubled by patent issues. Just unzip
> > > > it to the same directory that the hugin-*.zip went to and hugin should
> > > > be able to use it (it's not a stand-alone executable and shares the
> > > > same directory hierarchy).
>
> > > > Finally, hugin-2009.4.0_rc2-win32-cygming-build.tar.gz contains the
> > > > master Makefile and patches which were used to build and package hugin/
> > > > autopano.
>
> > > > It would be interesting if people with "real" workflows could try it
> > > > out and see (a) whether it really works and (b) how it compares to the
> > > > MSVC version -- I my biggest panorama only has like seven photos in
> > > > it, and I don't usually play with multiple lenses or stacks.
>
> > > > The uploaded version uses
> > > > - hugin-2009.4.0_rc2
> > > > - enblend-enfuse-3.2
> > > > - libpano13-2.9.15_beta3
> > > > - autopano-sift-C-2.5.1_rc2
>
> > > > I'm willing to try other versions as appropriate, but wanted to close
> > > > the loop first (in particular, enblend-4.0 sounds like it needs some
> > > > integration work still).
>
> > > > Regards,
> > > > Ryan- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Re: hugin-2009.4 win32 (cygming) build available - please test

[Ryan]

Hi Rick,

Thanks for putting the build through its paces!

Now it's time for my ignorance to show through a bit :)

Re i18n: My system "Cannot set locale to language Chinese
(Traditional)" but Spanish and French work just fine (somebody did a
good job on those languages, BTW!). Did you get an error or did it
just silently ignore your language choice? Anyway, none of the Asian
languages I tried worked, and I just figured out that wxWidgets was
built without Unicode support, which would make life difficult for non-
latin charsets (I wonder why it defaults to unicode off?). I'll try
creating a new build with unicode support baked in.

Re OoM: I built enblend-enfuse with image cache enabled (well, the
configure script said so, at least... no way to query the binary
afaik). On my machine the cache (in hugin's preferences) defaults to a
piddling 256MB, though, which would probably cause problems for a
workflow as large as yours -- can you try bumping it up to something
more reasonable? (afaik -b only sets the block size of the image
cache, which is probably independent of its size) (How does that cache
size default get set, anyway?)

Re GPU: Unfortunately I don't have a access to a good enough GPU to
even explore this issue, but how general is the problem? It doesn't
seem to affect linux users, but what about the MSVC port of hugin? I
ask because none of my porting effort touched GPU-related stuff; glew
has explicit build-time support for cygming systems (in addition to
cygwin and mingw32), and I used a prebuilt glut32.dll.

Thanks!
Ryan

On Nov 1, 5:34 am, RueiKe  wrote:
> Hi Ryan,
>
> I have finished running the first test case for hugin-2009.4.0_rc2-
> win32-cygming-bin.zip.
>
> Platform: Windows Vista 64bit on an i7 with 12GB memory and an ATI
> Radeon HD 4800 series graphics card.
>
> Project: 31 image 360x180 equirectangular projection aligned with
> 7,129 control points.  No exposure bracketing in this project.
>
> Observations:
> GUI - Looks good.  Only concern found is it is in English even when
> Chinese is selected.
> Load images - No issues
> Add Control Points - I used Autopano-sift-c with "--maxdim 4000 --
> projection %f,%v --maxmatches %p %o %i" arguments.  It worked fine and
> added as many control points as 2009.2 (Allard's build).  I found a
> previous build of 2009.4 did not generate any control points when --
> maxdim 4000 is specified, but this build doesn't have the issue/
> Align - No problem
> Fine Tune All control points - No issues
> Control Point table - No problem, I removed bad control points with no
> issues
> Optimizer - No problems for position and everything
> Exposure - No issues with Low Dynamic range 1000 points per image.
> Stitching - Used Calculate Optimal Size -> 15,288 x 7,559.  Problems
> in stitching a "Blended Panorama" for both with and without GPU:
>    Without GPU - Out of memory error even with the arguments: -m 2000 -
> b 4000
>    With GPU - No errors, but during enblend most images were indicated
> as redundant and not included in final image.  Final image was a large
> file with the dimensions specified in "Calculate Optimal Size", but
> was transparent except for an area the size and shape of the image
> anchored for position.  The area was the same size as that component
> image, but it had other images blended incorrectly into it.
>
> Let me know if you need any other details,
>
> Regards,
> Rick
>
> On Nov 1, 9:22 am, RueiKe  wrote:
>
> > Hi Ryan,
>
> > I am still working through my test case, but one observed issue so far
> > is that the interface is in English even when I select Traditional
> > Chinese.  I am running this out of the directory where I unzipped it
> > to, so maybe this is part of the issue.
>
> > Regards,
> > Rick
>
> > On Oct 31, 8:51 pm, Ryan  wrote:
>
> > > Correction to the 
> > > URLs:http://hugin.panotools.org/testing/hugin/hugin-2009.4.0_rc2-win32-cyg..
>
> > > Thanks,
> > > Ryan
>
> > > On Oct 31, 10:41 am, Ryan  wrote:
>
> > > > Hi all,
>
> > > > hugin-2009.4.0-rc2-win32-cygming-bin.zip is now available 
> > > > atftp://hugin.panotools.org/public_html/testing/hugin/. It works out of
> > > > the box -- just unzip and run hugin/bin/hugin.exe -- and there are no
> > > > dependencies on either cygwin or the location it unzips to.
>
> > > > In addition, autopano-sift-C-2.5.1_rc2-win32-cygming-bin.zip is
> > > > available for people who aren't troubled by patent issues. Just unzip
> > > > it to the same directory that the hugin-*.zip went to and hugin should
> > > > be able to use it (it's not a stand-alone executable and shares the
> > > > same directory hierarchy).
>
> > > > Finally, hugin-2009.4.0_rc2-win32-cygming-build.tar.gz contains the
> > > > master Makefile and patches which were used to build and package hugin/
> > > > autopano.
>
> > > > It would be interesting if people with "real" workflows could try it
> > > > out and see (a) whether it really works and (b) how it compares to the
> > > > MSVC version -- I my biggest