[hugin-ptx] Landscape and portrait images can't share a lens

[Nicolas Pelletier]

As I was stitching, I got this.

HuginBase::PanoramaMemento::loadPTScript(): Landscape and portrait images
can't share a lens
error on script line 2792:
ERROR:  (..\..\..\hugin\src\hugin_base\panodata\Panorama.cpp:2373)
HuginBase::PanoramaMemento::loadPTScript(): Landscape and portrait images
can't share a lens
error on script line 2792:
ERROR:  (..\..\..\hugin\src\hugin_base\panodata\Panorama.cpp:2373)
HuginBase::PanoramaMemento::loadPTScript(): Landscape and portrait images
can't share a lens
error on script line 2792:

Reading the error, my fault! I did mix both type of images (didn't know I
couldn't)

Can I in the GUI know which image is which? so I can separate them back into
2 lenses?

Should this not matter? as in if it's a landscape, just flip it and the
behavior will be the same?

Thank you!

More info,
Vista running the install kit of RC4

--~--~-~--~~~---~--~~
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: Autopano-sift-c memory leaks

[Nicolas Pelletier]

Hi Seb,
Thanks for the info.

Just to confirm, you are running a 64 bit build of APSC. Correct?

Do you know what was the memory level at which it peaked?

Thanks,

nick


On Wed, Jul 15, 2009 at 4:50 PM, Seb Perez-D  wrote:

>
> On Wed, Jul 15, 2009 at 14:35, Nicolas
> Pelletier wrote:
> > 36 * 15mpx images will blow up after 30-32 images, regardless of the
> value
> > of maxdim. I've used the default of 1600, and tried many values, even
> down
> > to 100. Still an out of memory.
>
> I've just tried with 64 jpeg images, each 10,000x5000 (i.e., 50 Mpix
> each), with the default maxdim, and autopano-sift-c worked without
> problems (in Linux, 64 bits). So the issue is either a) Windows
> related; b) 32 bits related; c) your particular configuration; d) all
> of the preceding; e) other (there must be an error somewhere).
>
> Best,
>
> 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: fulla and Panasonic LX3

[Charles Flèche]

Good idea, thanks.


- "Martin Proetzsch"  a écrit :

> Hello Charles,
> 
> On Jul 15, 2009, at 4:44 PM, Charles Flèche wrote:
> 
> > Is there any known fulla settings to apply barrel distortion  
> > correction to the LX3 RAW files ? If not, could someone point me  
> > some documentation explaining how-to measure the barrel distortion
> ?
> 
> Maybe you can also try the current version of ufraw with lensfun  
> option activated:
> http://ufraw.sourceforge.net/
> 
> If the camera is included in the database, it corrects distortions  
> when developing your raw file.
> 
> Martin
> 

--~--~-~--~~~---~--~~
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: Autopano-sift-c memory leaks

[Seb Perez-D]

On Wed, Jul 15, 2009 at 14:35, Nicolas
Pelletier wrote:
> 36 * 15mpx images will blow up after 30-32 images, regardless of the value
> of maxdim. I've used the default of 1600, and tried many values, even down
> to 100. Still an out of memory.

I've just tried with 64 jpeg images, each 10,000x5000 (i.e., 50 Mpix
each), with the default maxdim, and autopano-sift-c worked without
problems (in Linux, 64 bits). So the issue is either a) Windows
related; b) 32 bits related; c) your particular configuration; d) all
of the preceding; e) other (there must be an error somewhere).

Best,

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: fulla and Panasonic LX3

[Martin Proetzsch]

Hello Charles,

On Jul 15, 2009, at 4:44 PM, Charles Flèche wrote:

> Is there any known fulla settings to apply barrel distortion  
> correction to the LX3 RAW files ? If not, could someone point me  
> some documentation explaining how-to measure the barrel distortion ?

Maybe you can also try the current version of ufraw with lensfun  
option activated:
http://ufraw.sourceforge.net/

If the camera is included in the database, it corrects distortions  
when developing your raw file.

Martin
--~--~-~--~~~---~--~~
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: What is optimized FOV really?

[Aron H]

I'm happy to report that I am able to duplicate the Hugin transform
and camera distortion model in my software, using the basic outline I
described earlier.

I also wanted to report that I compared the results of camera
calibration in Hugin and Bouguet, and they agree very well, in a
limited case.
Allow Hugin to optimize FOV, only the 'b' distortion parameter, and
the 'd' and 'e' center shift.
Allow Bouguet to optimize FOV and center shift, and only the k0
distortion parameter.
k0 and b are the coefficient on the r^2 distortion in both camera
models.

I found that the center shift and r^2 distortion (after scaling)
agreed almost exactly. Here are the numbers:
Center shift:
Bouguet 17.32  27.47
Hugin 17.327.5
r^2 distortion
Bouguet -0.01138
Hugin -0.01138
Amazing, considering the input to Bouguet is 21 pictures of a
calibration grid, and the input to Hugin is an 18 picture 360 deg
panorama! I haven't figured out the formula to compare FOV/focal
length directly yet, although
if I follow Klaus' suggestion that
> focal_length_panotools * d = true_focal_length

then I get this for focal length, in pixels:
Bouguet 1950.0
Hugin 1954.91

I will get that promised comparison up on the wiki shortly, explaining
the scaling I did between the two systems.

Regards,
Aron
--~--~-~--~~~---~--~~
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: 64 bits versions

[Nicolas Pelletier]

Yes it does. Thanks for the info.
When I get a moment, I'll setup a dev system and get the patches.

nick

On Wed, Jul 15, 2009 at 2:25 PM, Ryan Sleevi

> wrote:

>
> > Thanks for the info.
> > Out of curiosity, is there a reason why it is not a single branch with 2
> > build targets, but one branch 32, and patches for 64?
> >
> > Thanks,
> >
> > nick
>
> That's definitely my goal and on my todo in the coming weeks. The big
> reason for it not being yet resolved is that the initial goal was to get
> it working, and get it out there, so that other people can reproduce it.
>
> There are a lot of hardcoded interdependencies in the project files on
> various libraries, and the projects come from several different
> distributions - some source, some binary, some from svn repos, etc.
>
> Being familiar with the process as I am now, it isn't a hard thing, in
> terms of technical difficulty, it's just a matter of going through
> everything and checking. My priority at present has been more in the
> experimenting with the low-hanging fruit of optimizations, as that seems
> to be able to benefit a larger crowd than the build process smoothing.
>
> The patches aren't just for 64-bit though, I should mention. The patches
> at present are meant to simplify a much longer process that even 32-bit
> users had to go through in resolving the various conflicts/issues (eg:
> updating solution files to VS2008, changing paths/dependencies, etc). It's
> just that the patches at present, in addition to resolving everything for
> 32-bit, introduce the new 64-bit configurations as options. You end up
> with 4 projects - Debug, RelMinSize, Release, RelWithDebInfo - and two
> configurations - 32-bit and 64-bit. You just can't change the
> configuration of Hugin without also going back through and updating a
> number of things (from enblend/enfuse to recompiling wxWidgets + OpenEXR
> etc)
>
> Does that help any?
>
>
> >
>

--~--~-~--~~~---~--~~
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: 64 bits versions

[Ryan Sleevi]

> Thanks for the info.
> Out of curiosity, is there a reason why it is not a single branch with 2
> build targets, but one branch 32, and patches for 64?
>
> Thanks,
>
> nick

That's definitely my goal and on my todo in the coming weeks. The big
reason for it not being yet resolved is that the initial goal was to get
it working, and get it out there, so that other people can reproduce it.

There are a lot of hardcoded interdependencies in the project files on
various libraries, and the projects come from several different
distributions - some source, some binary, some from svn repos, etc.

Being familiar with the process as I am now, it isn't a hard thing, in
terms of technical difficulty, it's just a matter of going through
everything and checking. My priority at present has been more in the
experimenting with the low-hanging fruit of optimizations, as that seems
to be able to benefit a larger crowd than the build process smoothing.

The patches aren't just for 64-bit though, I should mention. The patches
at present are meant to simplify a much longer process that even 32-bit
users had to go through in resolving the various conflicts/issues (eg:
updating solution files to VS2008, changing paths/dependencies, etc). It's
just that the patches at present, in addition to resolving everything for
32-bit, introduce the new 64-bit configurations as options. You end up
with 4 projects - Debug, RelMinSize, Release, RelWithDebInfo - and two
configurations - 32-bit and 64-bit. You just can't change the
configuration of Hugin without also going back through and updating a
number of things (from enblend/enfuse to recompiling wxWidgets + OpenEXR
etc)

Does that help any?


--~--~-~--~~~---~--~~
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: 64 bits versions

[Bruno Postle]

On Wed 15-Jul-2009 at 13:25 -0400, Nicolas Pelletier wrote:
>Out of curiosity, is there a reason why it is not a single branch with 2
>build targets, but one branch 32, and patches for 64?

Just because we are near release and this is a 'feature' not a 
'bugfix'.  This won't stop anyone building a binary installer, it is 
just an extra step until the patch gets applied to the trunk.

-- 
Bruno

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

[hugin-ptx] Re: 64 bits versions

[Nicolas Pelletier]

Thanks for the info.
Out of curiosity, is there a reason why it is not a single branch with 2
build targets, but one branch 32, and patches for 64?

Thanks,

nick


On Wed, Jul 15, 2009 at 12:59 PM, Ryan Sleevi

> wrote:

>
> > So hugin works in 64.
> > What about APSC, enblend and enfuse?
> >
> > Thanks,
> >
> > nick
> >
>
> With the patches, they all work. Getting enblend/enfuse on 64-bit was the
> most onerous part, because a number of GNU dependencies are only
> distributed in 32-bit form. However, the wiki page details the steps
> necessary to compile them in 64-bit (and the appropriate patches as
> necessary), so they'll compile fine.
>
> I don't think APSCpp required any
>
>
> >
>

--~--~-~--~~~---~--~~
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-mac-0.8.0-RC5 32/64bit version released

[Klaus Foehl]

On 14 July, 13:07, Klaus Foehl  wrote:
> On 13 July, 22:11, Bruno Postle  wrote:
>
> > On Mon 13-Jul-2009 at 01:49 -0700, Klaus Foehl wrote:
> > >2) Blending section of stitching: had "--visualize visu.jpeg" as
> > >default option from a previous 0.7.0 option but stops stitching
> > >progress as file somehow cannot be written. Same for suffix .jpg.
>
> > Have you tried --visualize=visu.tif or some other TIFF name?
>
> No. But it says something like "cannot open XXX as input image"...
>
> What I tried is to give an absolute file name. No change there.

Because the error message is about "input file", precondition
violation,
I just copied a JPG file onto that name. Different error message now,
it now complains about file not having an alpha layer

Cheers
Klaus
--~--~-~--~~~---~--~~
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: 64 bits versions

[Ryan Sleevi]

> So hugin works in 64.
> What about APSC, enblend and enfuse?
>
> Thanks,
>
> nick
>

With the patches, they all work. Getting enblend/enfuse on 64-bit was the
most onerous part, because a number of GNU dependencies are only
distributed in 32-bit form. However, the wiki page details the steps
necessary to compile them in 64-bit (and the appropriate patches as
necessary), so they'll compile fine.

I don't think APSCpp required any


--~--~-~--~~~---~--~~
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: fulla and Panasonic LX3

[Charles Flèche]

> LX3 looks like a nice camera...



It is, and I highly recommend it. But this barrel distortion problem is kinda 
annoying.

--~--~-~--~~~---~--~~
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: fulla and Panasonic LX3

[Charles Flèche]

> there's tutorial about it:
> http://hugin.sourceforge.net/tutorials/calibration/en.shtml



Brilliant, thank you very much Lukáš, I've overlooked that 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: fulla and Panasonic LX3

[Bruno Postle]

On Wed 15-Jul-2009 at 16:44 +0200, Charles Flèche wrote:

> Is there any known fulla settings to apply barrel distortion 
> correction to the LX3 RAW files ? If not, could someone point me 
> some documentation explaining how-to measure the barrel 
> distortion?

There are various ways of doing it, the simplest is just to stitch 
two photos together and use the resulting lens parameters:

http://hugin.sourceforge.net/tutorials/two-photos/

LX3 looks like a nice camera...

-- 
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: fulla and Panasonic LX3

[Lukáš Jirkovský]

2009/7/15 Charles Flèche :
>
> Hello everyone,
> The Panasonic LX3 has a flaw : the lens is subject to an pretty bad barrel 
> distortion. This distortion is corrected in-camera before the export to JPEG. 
> In case of RAW shooting, it's corrected in the provided software SilkyPix.
>
> More details in the following link : 
> http://www.imaging-resource.com/PRODS/LX3/LX3A4.HTM
>
> Is there any known fulla settings to apply barrel distortion correction to 
> the LX3 RAW files ? If not, could someone point me some documentation 
> explaining how-to measure the barrel distortion ?
>
> Thank you very much !
>
> >
>

Hi Charles,
there's tutorial about it:
http://hugin.sourceforge.net/tutorials/calibration/en.shtml

In short – take a picture of something with straight lines (some
building should be enough). Then switch to the control points tab and
add control points to the line. For a first pair in every line use
mode "Add new Line" and for all other CP's on that line select the
corresponding line from the drop down menu. Then optimize for a,b,c
(maybe only b).

Lukáš

--~--~-~--~~~---~--~~
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: 64 bits versions

[Nicolas Pelletier]

So hugin works in 64.
What about APSC, enblend and enfuse?

Thanks,

nick

Milton Berle 
- "If opportunity doesn't knock, build a door."

On Wed, Jul 15, 2009 at 9:59 AM, Ryan Sleevi

> wrote:

>
> Nick,
>
>   No one's stepped up to the role of being the binary builder. I haven't
> volunteered myself just because I wouldn't be able to compile
> "everything" - needing to leave off those tools affected by
> SIFT/SURF/other patents and the like (which should just be the CP
> generators, but still, an important part and part of the current
> distributions)
>
>   I did, however, update the wiki at
> http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 with the steps to
> building Hugin on x64, which should fully work with Visual Studio 2008,
> including Express Edition. If you are using Express Edition, you'll
> also need the Windows SDK 6.1/6.1a (or whatever is shipping), as that
> contains the x64 native compilers / x86-64 cross compilers. If using
> EE, you'll also need to enable the x64 compilers in EE, which requires
> a little trickery with the registry, but is documented in numerous
> places
>
>   You'll also need to run several patches on the various parts of the SDK
> and Hugin. They are linked in that wiki page, but also found on the
> SourceForge Patches tracker (there are two patches - one for Hugin, one
> for the SDK).
>
>   If you have any trouble, feel free to ask, as I've been running it fine
> on Vista x64 for over a month now. If there is anything in the wiki you
> find confusing or need clarification, feel free to ask and/or edit away
> to resolve that.
>
> > I'm running on vista.
> > Binaries would be nice, but if it works, but no binaries, then I'll build
> > it
> > myself.
> >
> > nick
>
>
>
> >
>

--~--~-~--~~~---~--~~
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] fulla and Panasonic LX3

[Charles Flèche]

Hello everyone,
The Panasonic LX3 has a flaw : the lens is subject to an pretty bad barrel 
distortion. This distortion is corrected in-camera before the export to JPEG. 
In case of RAW shooting, it's corrected in the provided software SilkyPix.

More details in the following link : 
http://www.imaging-resource.com/PRODS/LX3/LX3A4.HTM

Is there any known fulla settings to apply barrel distortion correction to the 
LX3 RAW files ? If not, could someone point me some documentation explaining 
how-to measure the barrel distortion ?

Thank you very 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: 64 bits versions

[luca vascon]

YE
Please!!
I'm running XP64...

2009/7/15 Ryan Sleevi >

>
> Nick,
>
>   No one's stepped up to the role of being the binary builder. I haven't
> volunteered myself just because I wouldn't be able to compile
> "everything" - needing to leave off those tools affected by
> SIFT/SURF/other patents and the like (which should just be the CP
> generators, but still, an important part and part of the current
> distributions)
>
>   I did, however, update the wiki at
> http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 with the steps to
> building Hugin on x64, which should fully work with Visual Studio 2008,
> including Express Edition. If you are using Express Edition, you'll
> also need the Windows SDK 6.1/6.1a (or whatever is shipping), as that
> contains the x64 native compilers / x86-64 cross compilers. If using
> EE, you'll also need to enable the x64 compilers in EE, which requires
> a little trickery with the registry, but is documented in numerous
> places
>
>   You'll also need to run several patches on the various parts of the SDK
> and Hugin. They are linked in that wiki page, but also found on the
> SourceForge Patches tracker (there are two patches - one for Hugin, one
> for the SDK).
>
>   If you have any trouble, feel free to ask, as I've been running it fine
> on Vista x64 for over a month now. If there is anything in the wiki you
> find confusing or need clarification, feel free to ask and/or edit away
> to resolve that.
>
> > I'm running on vista.
> > Binaries would be nice, but if it works, but no binaries, then I'll build
> > it
> > myself.
> >
> > nick
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: 64 bits versions

[Ryan Sleevi]

Nick,

   No one's stepped up to the role of being the binary builder. I haven't
volunteered myself just because I wouldn't be able to compile
"everything" - needing to leave off those tools affected by
SIFT/SURF/other patents and the like (which should just be the CP
generators, but still, an important part and part of the current
distributions)

   I did, however, update the wiki at
http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 with the steps to
building Hugin on x64, which should fully work with Visual Studio 2008,
including Express Edition. If you are using Express Edition, you'll
also need the Windows SDK 6.1/6.1a (or whatever is shipping), as that
contains the x64 native compilers / x86-64 cross compilers. If using
EE, you'll also need to enable the x64 compilers in EE, which requires
a little trickery with the registry, but is documented in numerous
places

   You'll also need to run several patches on the various parts of the SDK
and Hugin. They are linked in that wiki page, but also found on the
SourceForge Patches tracker (there are two patches - one for Hugin, one
for the SDK).

   If you have any trouble, feel free to ask, as I've been running it fine
on Vista x64 for over a month now. If there is anything in the wiki you
find confusing or need clarification, feel free to ask and/or edit away
to resolve that.

> I'm running on vista.
> Binaries would be nice, but if it works, but no binaries, then I'll build
> it
> myself.
>
> nick



--~--~-~--~~~---~--~~
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: 64 bits versions

[Nicolas Pelletier]

I'm running on vista.
Binaries would be nice, but if it works, but no binaries, then I'll build it
myself.

nick


On Wed, Jul 15, 2009 at 9:00 AM, Alexandre Prokoudine <
alexandre.prokoud...@gmail.com> wrote:

>
> On 15 июл, 16:37, Nicolas Pelletier 
> wrote:
> > Hi,
> > Are there 64bit versions for some\all of the "hugin package"? Looking for
> > APSC, Enblend, Enfuse and hugin.
>
> Do you mean binary builds for Linux?
>
> Alexandre
> >
>

--~--~-~--~~~---~--~~
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: 64 bits versions

[Alexandre Prokoudine]

On 15 июл, 16:37, Nicolas Pelletier 
wrote:
> Hi,
> Are there 64bit versions for some\all of the "hugin package"? Looking for
> APSC, Enblend, Enfuse and hugin.

Do you mean binary builds for Linux?

Alexandre
--~--~-~--~~~---~--~~
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] 64 bits versions

[Nicolas Pelletier]

Hi,
Are there 64bit versions for some\all of the "hugin package"? Looking for
APSC, Enblend, Enfuse and hugin.

Thanks,

nick

--~--~-~--~~~---~--~~
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: Autopano-sift-c memory leaks

[Nicolas Pelletier]

Already did.
This is one of the other details I found weird.

36 * 15mpx images will blow up after 30-32 images, regardless of the value
of maxdim. I've used the default of 1600, and tried many values, even down
to 100. Still an out of memory.

nick

Timothy Leary
- "Women who seek to be equal with men lack ambition."

On Wed, Jul 15, 2009 at 8:14 AM, Andrew Chanler  wrote:

> By default all the images are down-sized so that the largest dimension is
> 1600 pixels.  There is a command line option called -maxdim which you can
> set this setting with.  Try setting this to something like 1200 or 800.
>
>
> On Wed, Jul 15, 2009 at 7:54 AM, Nicolas Pelletier <
> nicolas.pellet...@gmail.com> wrote:
>
>> Thanks Andrew, I appreciate.
>> In my case, the out of memory happens in the first phase, i.e. when
>> searching for keypoints for each individual images.
>>
>> I did not write down the exact numbers, but it did "keep" much memory
>> between images. (For example, before processing image X, process at 200
>> megs. While processing, peak at 800. As it's starting the next image, down
>> to 315. 200 and 315 seems far apart, even if we consider that the task
>> manager might not update fast enough).
>>
>> I'll also add that the more I use it, the more I think that much memory
>> is\will be used by the software and it will reach a pix limit quickly.
>>
>> But what is boggling me a little is that, if that was the end of this
>> (i.e. I'm just hitting the software\memory limit), then there would be more
>> reports of this. At least I'd think there would. Specially since I saw
>> people mentioning making giga pans with this.
>>
>> I appreciate the work Andrew. When I have a moment, I'll try to setup the
>> computer for dev.
>>
>> nick
>>
>>
>>
>> On Wed, Jul 15, 2009 at 7:05 AM, Andrew Chanler wrote:
>>
>>> I found the largest leak.  And now my build only leaks a few KB, however
>>> I think the main problem is the amount of memory the application uses Let me
>>> summarize the memory usage with 2 images.
>>>
>>> 1) During GenerateKeyspp an enormousness amount of memory is allocated
>>> for image processing.  For a single 1536x1024 image I saw 217MB get
>>> allocated and freed during this function.  Then at the end of the function
>>> 7.4MB was allocated for the keypoints that were found in that image
>>> (1092Bytes per keypoint and it found 7000+ keypoints).
>>>
>>> 2) This repeated for each image.  So another large chunk was allocated to
>>> find keypoints in it. But it was also freed.  And another roughly 7.5MB were
>>> allocated for keypoints.  So roughly 15.5MB are now allocated for keypoints.
>>>
>>> 3) Next MultiMatch_ANN will run to find keypoints that match in different
>>> images.  This is where the largest abuse of memory was.  It for each
>>> Keypoint it allocates a KeypointN.  This doubles the memory used by
>>> keypoints to 31MB.  Then when it finds a match it creates a Match which
>>> points to two KeypointN's.  In my case it found 40 matches between the two
>>> images.Then at the end of the function it frees all the Keypoint's.  However
>>> out of the 13755 KeypointN's that were allocated we only need 80 that are
>>> used in each Match. These extra KeypointN's represent the largest leak in
>>> the program.
>>>
>>> Now taking a look at your case, if you have 36 images that each found
>>> 7000 points. that would be 263MB for keypoints.  Then when you call
>>> MultiMatch_ANN that would double when you allocate KeypointN's to 526MB.
>>>
>>> When you go to the larger image sets does it fail before it finishes
>>> processing all the images?  Or does it fail while it searches for matches?
>>>
>>> I'll have to clean up my workspace and submit my patch that only
>>> allocates KeypointN's when they are needed.  I have some other ideas to
>>> reduce the memory usage by during the image processing but I need to
>>> investigate it more.
>>>
>>> Andrew
>>>
>>>
>>> On Tue, Jul 14, 2009 at 11:38 PM, Nicolas Pelletier <
>>> nicolas.pellet...@gmail.com> wrote:
>>>
 Tried some more cases to try and find something weird.
 Unfortunately, nothing.

 I consistently run out of memory, whenever I take big images (threeshold
 seems to be 36 images of 10 mpix).

 Bigger pictures and out of memory.

 I have not tried more smaller pictures.

 Of the people who stitch many pictures anybody has a 15+ mpix camera?

 nick


 On Mon, Jul 13, 2009 at 5:34 PM, Andrew Chanler wrote:

> I have only found 1 small memory leak so far... 16bytes * number of
> images I believe.  Here is the fix.
>
> Index: APSCpp/APSCpp.c
> ===
> --- APSCpp/APSCpp.c (revision 4038)
> +++ APSCpp/APSCpp.c (working copy)
> @@ -415,6 +415,8 @@
> kpp->imageFile = strdup(imgname);
> kpp->xDim = pW;
> kpp->y

[hugin-ptx] Re: Autopano-sift-c memory leaks

[Andrew Chanler]

By default all the images are down-sized so that the largest dimension is
1600 pixels.  There is a command line option called -maxdim which you can
set this setting with.  Try setting this to something like 1200 or 800.

On Wed, Jul 15, 2009 at 7:54 AM, Nicolas Pelletier <
nicolas.pellet...@gmail.com> wrote:

> Thanks Andrew, I appreciate.
> In my case, the out of memory happens in the first phase, i.e. when
> searching for keypoints for each individual images.
>
> I did not write down the exact numbers, but it did "keep" much memory
> between images. (For example, before processing image X, process at 200
> megs. While processing, peak at 800. As it's starting the next image, down
> to 315. 200 and 315 seems far apart, even if we consider that the task
> manager might not update fast enough).
>
> I'll also add that the more I use it, the more I think that much memory
> is\will be used by the software and it will reach a pix limit quickly.
>
> But what is boggling me a little is that, if that was the end of this (i.e.
> I'm just hitting the software\memory limit), then there would be more
> reports of this. At least I'd think there would. Specially since I saw
> people mentioning making giga pans with this.
>
> I appreciate the work Andrew. When I have a moment, I'll try to setup the
> computer for dev.
>
> nick
>
>
>
> On Wed, Jul 15, 2009 at 7:05 AM, Andrew Chanler wrote:
>
>> I found the largest leak.  And now my build only leaks a few KB, however I
>> think the main problem is the amount of memory the application uses Let me
>> summarize the memory usage with 2 images.
>>
>> 1) During GenerateKeyspp an enormousness amount of memory is allocated for
>> image processing.  For a single 1536x1024 image I saw 217MB get allocated
>> and freed during this function.  Then at the end of the function 7.4MB was
>> allocated for the keypoints that were found in that image (1092Bytes per
>> keypoint and it found 7000+ keypoints).
>>
>> 2) This repeated for each image.  So another large chunk was allocated to
>> find keypoints in it. But it was also freed.  And another roughly 7.5MB were
>> allocated for keypoints.  So roughly 15.5MB are now allocated for keypoints.
>>
>> 3) Next MultiMatch_ANN will run to find keypoints that match in different
>> images.  This is where the largest abuse of memory was.  It for each
>> Keypoint it allocates a KeypointN.  This doubles the memory used by
>> keypoints to 31MB.  Then when it finds a match it creates a Match which
>> points to two KeypointN's.  In my case it found 40 matches between the two
>> images.Then at the end of the function it frees all the Keypoint's.  However
>> out of the 13755 KeypointN's that were allocated we only need 80 that are
>> used in each Match. These extra KeypointN's represent the largest leak in
>> the program.
>>
>> Now taking a look at your case, if you have 36 images that each found 7000
>> points. that would be 263MB for keypoints.  Then when you call
>> MultiMatch_ANN that would double when you allocate KeypointN's to 526MB.
>>
>> When you go to the larger image sets does it fail before it finishes
>> processing all the images?  Or does it fail while it searches for matches?
>>
>> I'll have to clean up my workspace and submit my patch that only allocates
>> KeypointN's when they are needed.  I have some other ideas to reduce the
>> memory usage by during the image processing but I need to investigate it
>> more.
>>
>> Andrew
>>
>>
>> On Tue, Jul 14, 2009 at 11:38 PM, Nicolas Pelletier <
>> nicolas.pellet...@gmail.com> wrote:
>>
>>> Tried some more cases to try and find something weird.
>>> Unfortunately, nothing.
>>>
>>> I consistently run out of memory, whenever I take big images (threeshold
>>> seems to be 36 images of 10 mpix).
>>>
>>> Bigger pictures and out of memory.
>>>
>>> I have not tried more smaller pictures.
>>>
>>> Of the people who stitch many pictures anybody has a 15+ mpix camera?
>>>
>>> nick
>>>
>>>
>>> On Mon, Jul 13, 2009 at 5:34 PM, Andrew Chanler wrote:
>>>
 I have only found 1 small memory leak so far... 16bytes * number of
 images I believe.  Here is the fix.

 Index: APSCpp/APSCpp.c
 ===
 --- APSCpp/APSCpp.c (revision 4038)
 +++ APSCpp/APSCpp.c (working copy)
 @@ -415,6 +415,8 @@
 kpp->imageFile = strdup(imgname);
 kpp->xDim = pW;
 kpp->yDim = pH;
 +   // free preallocated array before over-writing pointer...
 +   ArrayList_delete(kpp->array);
 if( mode == 0 ){
 // return the KeypointN list
 kpp->array = globalNaturalKeypoints;

 Hopefully I'll find something more fruitful than this...

 Andrew


 On Sun, Jul 12, 2009 at 2:13 PM, Tom Sharpless 
 wrote:

>
> Hi, I'm starting a new thread on this as the old one has gotten too
> long.
>
> First some background.  Hugin's

[hugin-ptx] Re: Autopano-sift-c memory leaks

[Nicolas Pelletier]

Thanks Andrew, I appreciate.
In my case, the out of memory happens in the first phase, i.e. when
searching for keypoints for each individual images.

I did not write down the exact numbers, but it did "keep" much memory
between images. (For example, before processing image X, process at 200
megs. While processing, peak at 800. As it's starting the next image, down
to 315. 200 and 315 seems far apart, even if we consider that the task
manager might not update fast enough).

I'll also add that the more I use it, the more I think that much memory
is\will be used by the software and it will reach a pix limit quickly.

But what is boggling me a little is that, if that was the end of this (i.e.
I'm just hitting the software\memory limit), then there would be more
reports of this. At least I'd think there would. Specially since I saw
people mentioning making giga pans with this.

I appreciate the work Andrew. When I have a moment, I'll try to setup the
computer for dev.

nick


On Wed, Jul 15, 2009 at 7:05 AM, Andrew Chanler  wrote:

> I found the largest leak.  And now my build only leaks a few KB, however I
> think the main problem is the amount of memory the application uses Let me
> summarize the memory usage with 2 images.
>
> 1) During GenerateKeyspp an enormousness amount of memory is allocated for
> image processing.  For a single 1536x1024 image I saw 217MB get allocated
> and freed during this function.  Then at the end of the function 7.4MB was
> allocated for the keypoints that were found in that image (1092Bytes per
> keypoint and it found 7000+ keypoints).
>
> 2) This repeated for each image.  So another large chunk was allocated to
> find keypoints in it. But it was also freed.  And another roughly 7.5MB were
> allocated for keypoints.  So roughly 15.5MB are now allocated for keypoints.
>
> 3) Next MultiMatch_ANN will run to find keypoints that match in different
> images.  This is where the largest abuse of memory was.  It for each
> Keypoint it allocates a KeypointN.  This doubles the memory used by
> keypoints to 31MB.  Then when it finds a match it creates a Match which
> points to two KeypointN's.  In my case it found 40 matches between the two
> images.Then at the end of the function it frees all the Keypoint's.  However
> out of the 13755 KeypointN's that were allocated we only need 80 that are
> used in each Match. These extra KeypointN's represent the largest leak in
> the program.
>
> Now taking a look at your case, if you have 36 images that each found 7000
> points. that would be 263MB for keypoints.  Then when you call
> MultiMatch_ANN that would double when you allocate KeypointN's to 526MB.
>
> When you go to the larger image sets does it fail before it finishes
> processing all the images?  Or does it fail while it searches for matches?
>
> I'll have to clean up my workspace and submit my patch that only allocates
> KeypointN's when they are needed.  I have some other ideas to reduce the
> memory usage by during the image processing but I need to investigate it
> more.
>
> Andrew
>
>
> On Tue, Jul 14, 2009 at 11:38 PM, Nicolas Pelletier <
> nicolas.pellet...@gmail.com> wrote:
>
>> Tried some more cases to try and find something weird.
>> Unfortunately, nothing.
>>
>> I consistently run out of memory, whenever I take big images (threeshold
>> seems to be 36 images of 10 mpix).
>>
>> Bigger pictures and out of memory.
>>
>> I have not tried more smaller pictures.
>>
>> Of the people who stitch many pictures anybody has a 15+ mpix camera?
>>
>> nick
>>
>>
>> On Mon, Jul 13, 2009 at 5:34 PM, Andrew Chanler wrote:
>>
>>> I have only found 1 small memory leak so far... 16bytes * number of
>>> images I believe.  Here is the fix.
>>>
>>> Index: APSCpp/APSCpp.c
>>> ===
>>> --- APSCpp/APSCpp.c (revision 4038)
>>> +++ APSCpp/APSCpp.c (working copy)
>>> @@ -415,6 +415,8 @@
>>> kpp->imageFile = strdup(imgname);
>>> kpp->xDim = pW;
>>> kpp->yDim = pH;
>>> +   // free preallocated array before over-writing pointer...
>>> +   ArrayList_delete(kpp->array);
>>> if( mode == 0 ){
>>> // return the KeypointN list
>>> kpp->array = globalNaturalKeypoints;
>>>
>>> Hopefully I'll find something more fruitful than this...
>>>
>>> Andrew
>>>
>>>
>>> On Sun, Jul 12, 2009 at 2:13 PM, Tom Sharpless wrote:
>>>

 Hi, I'm starting a new thread on this as the old one has gotten too
 long.

 First some background.  Hugin's autopano-sift-C project builds 3
 programs:
  generatekeys finds SIFT keypoints in one image and puts them in an
 XML file;
  autopano reads those files and constructs control points linking
 pairs of images;
  autopano-sift-c combines both function, plus several enhancements,
 in one program.
 The combined program shares a great deal of code with the separate
 ones.  The main differences are that it processes

[hugin-ptx] Re: Autopano-sift-c memory leaks

[Andrew Chanler]

I found the largest leak.  And now my build only leaks a few KB, however I
think the main problem is the amount of memory the application uses Let me
summarize the memory usage with 2 images.

1) During GenerateKeyspp an enormousness amount of memory is allocated for
image processing.  For a single 1536x1024 image I saw 217MB get allocated
and freed during this function.  Then at the end of the function 7.4MB was
allocated for the keypoints that were found in that image (1092Bytes per
keypoint and it found 7000+ keypoints).

2) This repeated for each image.  So another large chunk was allocated to
find keypoints in it. But it was also freed.  And another roughly 7.5MB were
allocated for keypoints.  So roughly 15.5MB are now allocated for keypoints.

3) Next MultiMatch_ANN will run to find keypoints that match in different
images.  This is where the largest abuse of memory was.  It for each
Keypoint it allocates a KeypointN.  This doubles the memory used by
keypoints to 31MB.  Then when it finds a match it creates a Match which
points to two KeypointN's.  In my case it found 40 matches between the two
images.Then at the end of the function it frees all the Keypoint's.  However
out of the 13755 KeypointN's that were allocated we only need 80 that are
used in each Match. These extra KeypointN's represent the largest leak in
the program.

Now taking a look at your case, if you have 36 images that each found 7000
points. that would be 263MB for keypoints.  Then when you call
MultiMatch_ANN that would double when you allocate KeypointN's to 526MB.

When you go to the larger image sets does it fail before it finishes
processing all the images?  Or does it fail while it searches for matches?

I'll have to clean up my workspace and submit my patch that only allocates
KeypointN's when they are needed.  I have some other ideas to reduce the
memory usage by during the image processing but I need to investigate it
more.

Andrew

On Tue, Jul 14, 2009 at 11:38 PM, Nicolas Pelletier <
nicolas.pellet...@gmail.com> wrote:

> Tried some more cases to try and find something weird.
> Unfortunately, nothing.
>
> I consistently run out of memory, whenever I take big images (threeshold
> seems to be 36 images of 10 mpix).
>
> Bigger pictures and out of memory.
>
> I have not tried more smaller pictures.
>
> Of the people who stitch many pictures anybody has a 15+ mpix camera?
>
> nick
>
>
> On Mon, Jul 13, 2009 at 5:34 PM, Andrew Chanler wrote:
>
>> I have only found 1 small memory leak so far... 16bytes * number of images
>> I believe.  Here is the fix.
>>
>> Index: APSCpp/APSCpp.c
>> ===
>> --- APSCpp/APSCpp.c (revision 4038)
>> +++ APSCpp/APSCpp.c (working copy)
>> @@ -415,6 +415,8 @@
>> kpp->imageFile = strdup(imgname);
>> kpp->xDim = pW;
>> kpp->yDim = pH;
>> +   // free preallocated array before over-writing pointer...
>> +   ArrayList_delete(kpp->array);
>> if( mode == 0 ){
>> // return the KeypointN list
>> kpp->array = globalNaturalKeypoints;
>>
>> Hopefully I'll find something more fruitful than this...
>>
>> Andrew
>>
>>
>> On Sun, Jul 12, 2009 at 2:13 PM, Tom Sharpless wrote:
>>
>>>
>>> Hi, I'm starting a new thread on this as the old one has gotten too
>>> long.
>>>
>>> First some background.  Hugin's autopano-sift-C project builds 3
>>> programs:
>>>  generatekeys finds SIFT keypoints in one image and puts them in an
>>> XML file;
>>>  autopano reads those files and constructs control points linking
>>> pairs of images;
>>>  autopano-sift-c combines both function, plus several enhancements,
>>> in one program.
>>> The combined program shares a great deal of code with the separate
>>> ones.  The main differences are that it processes all the images; does
>>> not write keypoint data to, or read them from, XML files;  can convert
>>> images to stereographic projection before finding keypoints; and can
>>> read source image information  from a Hugin project file.  Although it
>>> ships as "autopano-sift-c", that name has always designated the two-
>>> program package as well, so to avoid confusion let us call the
>>> combined program by its name in the source code tree, "APSCpp".
>>>
>>> There have been several reports of out-of-memory errors while running
>>> "autopano-sift-c". It is possible that some might refer to
>>> generatekeys/autopano, however nowadays people mostly run APSCpp, as a
>>> Hugin plugin.  Moreover, the combined program would be more likely to
>>> fail due to problems in the image processing stages, because it
>>> processes a series of images while generatekeys handles only one.
>>> However it is not clear whether these failures happened at the image
>>> processing or the control point processing stage.  I am guessing it
>>> was the first stage, because that normally has a far higher peak
>>> memory demand than the second.
>>>
>>> I know of no case in which such a f