Bruno Postle | 1 Feb 22:27 2010
X-Face
Picon

A libpano13 beta release?

I'm planning on uploading a libpano13-2.0.17_beta1 tarball, mainly 
to help people who want to build the Hugin trunk (which needs the 
latest snapshot).  Is there any reason why I shouldn't?

--

-- 
Bruno

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
dmg | 1 Feb 22:30 2010
Picon
Picon

Re: A libpano13 beta release?

Hi Bruno,

Yes, that will be a great idea.

--dmg

On Mon, Feb 1, 2010 at 1:27 PM, Bruno Postle <bruno@...> wrote:
> I'm planning on uploading a libpano13-2.0.17_beta1 tarball, mainly
> to help people who want to build the Hugin trunk (which needs the
> latest snapshot).  Is there any reason why I shouldn't?
>
> --
> Bruno
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> PanoTools-devel mailing list
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
>

--

-- 
--dmg

(Continue reading)

Bruno Postle | 1 Feb 23:14 2010
Picon

libpano13-2.9.17_beta1 released


A libpano13-2.9.17_beta1 (first beta snapshot) tarball has been
uploaded to sourceforge:

https://sourceforge.net/projects/panotools/files/libpano13/

This is an interim 'beta' primarily useful for users wishing to try
Hugin development snapshots, the final release is likely to have
further bugfixes and maybe API changes.

You might wonder what happened to 2.9.15 and 2.9.16, these have been
skipped, the next stable release will now be 2.9.17 (until then the
current stable release is still 2.9.14).

There have been a number of changes since 2.9.15_beta3:

* cmake build system improvements. The 'default' build system is
still autotools (./configure; make etc...), but a cmake system is
also supplied which should be broadly equivalent.

* Fixes for possible memory leaks.

* Te0 and Te1 'test parameters' are in use as plane_yaw and
plane_pitch parameters. This allows specification of the plane that
is used in the translation mosaic (TrX, TrY, TrZ) mode. Various
improvements to the mosaic mode.

* Improvements for building on windows both cmake and visual studio.

* Helmut Dersch's mpremap tool has been imported (requires java).
(Continue reading)

Pablo d'Angelo | 9 Feb 06:19 2010
Picon

[Fwd: Re: question on panotools geometry]

I'm just forwarding a discussion between me, Daniel, Chris and Dev to 
the panotools-devel list, as it might be interesting for other parties, too.

Pablo
Picon
From: Pablo d'Angelo <pablo.dangelo@...>
Subject: Re: question on panotools geometry
Date: 2010-02-04 06:06:25 GMT
Hi all,

Chris Gat wrote:
> Just as Daniel mentioned, I effectively divided SetInvMake and SetMake
> functions into 2 modes, a planar and spherical. The planar mode will
> scale, translate, and tilt (based on Dev's code) the images to align.
> Spherical mode operates as it did before I started working on the
> code. The FOV of the input images isn't a factor when building the
> size of the panorama, but the tilt functions are reliant on these FOVs
> for proper tilting.  In general, I don't think FOV should be a factor
> in mosaic type panoramas, since the concept becomes lost once you
> start taking photos of the same plane at varying angles and distances.
> It makes calculating the resultant panorama size very difficult.  My
> implementation forces the user to specify a size of the output
> panorama that will contain the resultant panorama.  If is not
(Continue reading)

Pablo d'Angelo | 9 Feb 06:20 2010
Picon

[Fwd: Re: question on panotools geometry]

gmane.comp.graphics.panotools.devel
Picon
From: Pablo d'Angelo <pablo.dangelo@...>
Subject: Re: question on panotools geometry
Date: 2010-02-06 15:49:05 GMT
Hi all,

I believe that this needs to be moved to panotools-devel or hugin-ptx.
Is everybody ok with this? I will then repost on these lists.

D M German wrote:
> Hi Pablo,
> 
> One of problems I encountered when trying to do very long mosaics of a
> wall, is that I had to "fake" the FOV of each photo to be very small.
> 
> Also, another problem of libpano is that horizontal/vertical shift is
> done before the image is mapped to the panosphere (and before the lens
> correction is done). But for plannar mosaics you want to do the
> translation after the image has been mapped to the infinite plane.

Actually, this shift is a part of the lens correction and not designed 
for a planar mode. This is why an additional shift at the right place 
would be much better.

(Continue reading)

Thomas Sharpless | 9 Feb 14:33 2010
Picon

Re: [Fwd: Re: question on panotools geometry]

My 2 cents

Why don't we start using focal length rather than FOV as the basic angular scale parameter?  It is a pure scale factor, independent of image size and the shape of the projection function, both of which are conflated in FOV.  In my experience, 3/4 of the confusion about image scaling and angle-of-view calculations comes from the difficulty of disentangling those 3 basic parameters from FOV.

Regards, Tom


2010/2/9 Pablo d'Angelo <pablo.dangelo-S0/GAf8tV78@public.gmane.org>

Hi all,

I believe that this needs to be moved to panotools-devel or hugin-ptx.
Is everybody ok with this? I will then repost on these lists.

D M German wrote:
Hi Pablo,

One of problems I encountered when trying to do very long mosaics of a
wall, is that I had to "fake" the FOV of each photo to be very small.

Also, another problem of libpano is that horizontal/vertical shift is
done before the image is mapped to the panosphere (and before the lens
correction is done). But for plannar mosaics you want to do the
translation after the image has been mapped to the infinite plane.

Actually, this shift is a part of the lens correction and not designed for a planar mode. This is why an additional shift at the right place would be much better.

 Pablo> They are the normal FOV of the camera that was used for capturing the
 Pablo> image. This also means that all the distortion correction mechanisms
 Pablo> etc. still work properly, and one can reuse the lens calibration for
 Pablo> all images that were captured with the same camera (and optimize them
 Pablo> jointly).

This was the main motivation of the plannar mode.

Then I don't see why it is necessary to make such intrusive changes.

If the panorama projection is set to rectilinear, the panorama will be identical to the image on the plane, and one basically gets a planar mode for free. It is not very useful with the default r,p,y parameters, though. This is why I added the Tr ones.

I just saw that the optimizer always minimizes distances on the sphere and not in the output image. While this might makes sense for the panoramic usecase, it is probably not desirable for creating a planar mosaic.

> One does not have to
fake extremely narrow FOV for the lens to fit the mosaic in a sphere
(although, from what you say Pablo, the image will just keep wrapping
around the sphere several times).

No, that is not possible with a rectilinear panorama anyway.

>  By having a plannar mode we can use
the proper FOV of the lens.

Actually, this is also possible with the Tr parameters.

However, I found that with the additional parameters, optimisation generally tends to become more unstable, and I'm not sure if the Tr or a modified Ti (as used by PTGui and PTStitcherNG) is better in that respect.

ciao
 Pablo


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
PanoTools-devel mailing list
PanoTools-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/panotools-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
PanoTools-devel mailing list
PanoTools-devel@...
https://lists.sourceforge.net/lists/listinfo/panotools-devel
walter harms | 17 Feb 11:21 2010
Picon

autopano and filenames

Hi list,
this is is a bit off-topic but i have a minor problem with autopano (Version 2.5.0).
I made a script to produce my panoramas automaticly, and it runs into problems because of the file names.

Is there a proper way to have full the path in the resulting pto file ?
see:

PTO:
# image lines
#-hugin  cropFactor=1
i w512 h384 f0 Eb1 Eev0 Er1 Ra0 Rb0 Rc0 Rd0 Re0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 a0 b0.0140625985265577 c0 d0 e0 g0
p-0.301561129829693 r-0.32
4581100061696 t0 v54.9998672424966 y0.000854177496194097  Vm5 u10 n"bilder/081110001p1.jpg"

                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
KEYFILE:
<?xml version="1.0" encoding="UTF-8"?>
<KeypointXMLList>
  <XDim>512</XDim>
  <YDim>384</YDim>
  <ImageFile>/home/walter/src/source/bilder/081110001p1.jpg</ImageFile>
  <Arr>

re,
 wh

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
walter harms | 17 Feb 14:28 2010
Picon

solved: Re: autopano and filenames


--absolute-pathnames on

i was looking to hard to find, after i found that in the source .... strange.

re,
 wh

walter harms schrieb:
> Hi list,
> this is is a bit off-topic but i have a minor problem with autopano (Version 2.5.0).
> I made a script to produce my panoramas automaticly, and it runs into problems because of the file names.
> 
> Is there a proper way to have full the path in the resulting pto file ?
> see:
> 
> PTO:
> # image lines
> #-hugin  cropFactor=1
> i w512 h384 f0 Eb1 Eev0 Er1 Ra0 Rb0 Rc0 Rd0 Re0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 a0 b0.0140625985265577 c0 d0 e0 g0
p-0.301561129829693 r-0.32
> 4581100061696 t0 v54.9998672424966 y0.000854177496194097  Vm5 u10 n"bilder/081110001p1.jpg"
> 
>                                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> KEYFILE:
> <?xml version="1.0" encoding="UTF-8"?>
> <KeypointXMLList>
>   <XDim>512</XDim>
>   <YDim>384</YDim>
>   <ImageFile>/home/walter/src/source/bilder/081110001p1.jpg</ImageFile>
>   <Arr>
> 
> re,
>  wh
> 
> 
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> PanoTools-devel mailing list
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
> 

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
dev g | 18 Feb 06:51 2010
Picon

installing debian package from Cmake

Hello everyone,

I am trying to get my IDE (Eclipse) to allow me to debug Panotools and have followed an approach I found here:
http://www.vtk.org/Wiki/Eclipse_CDT4_Generator
to create Eclipse .project files from Cmake by adding some flags to the cmake commands given here:
http://wiki.panotools.org/Hugin_Compiling_Ubuntu#Building_Libpano13

From the command line, there are 3 steps:
1. Cmake ...
2. make package
3. sudo dpkg -i libpano13-*-Linux.deb

My approach does steps 1 and 2 from within Eclipse (creates the makefile and package) but does not do step 3.  Of course, the executables (such as PTmender, etc.) aren't created until the package is installed (with the command sudo dpkg -i libpano13-*-Linux.deb).  Is there any way to install the package by altering CMakeLists.txt?

Has anyone had success in setting up Eclipse or another IDE to debug Panotools or a similar project?  Any advice would be appreciated.

Thanks,
Dev

------------------------------------------------------------------------------
Download Intel&reg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs 
proactively, and fine-tune applications for parallel performance. 
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
PanoTools-devel mailing list
PanoTools-devel@...
https://lists.sourceforge.net/lists/listinfo/panotools-devel
Kornel Benko | 18 Feb 08:01 2010
Picon

Re: installing debian package from Cmake

Am Thursday 18 February 2010 schrieb dev g:
> Hello everyone,
> 
> I am trying to get my IDE (Eclipse) to allow me to debug Panotools and have
> followed an approach I found here:
> http://www.vtk.org/Wiki/Eclipse_CDT4_Generator
> to create Eclipse .project files from Cmake by adding some flags to the
> cmake commands given here:
> http://wiki.panotools.org/Hugin_Compiling_Ubuntu#Building_Libpano13
> 
> >From the command line, there are 3 steps:
> 1. Cmake ...
> 2. make package
> 3. sudo dpkg -i libpano13-*-Linux.deb

Making it in source-tree? Not recomended.

> My approach does steps 1 and 2 from within Eclipse (creates the makefile and
> package) but does not do step 3.  Of course, the executables (such as
> PTmender, etc.) aren't created until the package is installed (with the
> command sudo dpkg -i libpano13-*-Linux.deb).  Is there any way to install
> the package by altering CMakeLists.txt?

I would not like it. It would be very platform dependant. But why is it not possible from eclipse?

> Has anyone had success in setting up Eclipse or another IDE to debug
> Panotools or a similar project?  Any advice would be appreciated.
>
> Thanks,
> Dev
> 

	Kornel

--

-- 
Kornel Benko
Kornel.Benko@...
------------------------------------------------------------------------------
Download Intel&reg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs 
proactively, and fine-tune applications for parallel performance. 
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
PanoTools-devel mailing list
PanoTools-devel@...
https://lists.sourceforge.net/lists/listinfo/panotools-devel

Gmane