Panorama Tools

Hi again,

seems like I forgot the third topic:

3. improvements in the GUI of hugin such as, control point editor, batch 
processor, scripting language
and a simpler interface for newbies.

ciao
  Pablo

Pablo dAngelo schrieb:

>Hi all,
>
>I just noticed (on the openicc mailing list) that the google summer of 
>code starts soon.
>http://code.google.com/soc
>
>I would be happy to mentor one student for one of the following projects:
>
>1. Implementation of the SURF feature detector and matcher, and 
>improving its
>    performance on heavily distorted images (fisheye + wideangle). I 
>believe this
>    is also quite interesting for the students future, since this is 
>based on state of
>    the art research. This would be great, since a good detector for 
>these image
>    types is currently missing in the opensource world.
>
>2. Improved blending and anti-ghosting program, especially with respect to
>    the creation of HDR panoramas from multiple exposures.
>  
>
>I have supervised or co supervised some diploma (~masters) thesis in the 
>last 3
>years, so I feel qualified to mentor a student.
>
>I have never participated in the summer of code, and I'm not sure if 
>hugin is big
>enough for google to be considered, although hugin, panotools (tlalli) 
>and enblend
>is the most advanced opensource panorama creation software.
>Maybe with some backing from the panotools-list verein, there would be a
>chance to get accepted?
>
> From what I read, we need a fallback mentor and some organizer that 
>stays in
>contact with google and mediates if something goes wrong.
>
>ciao
>  Pablo
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>PanoTools-devel mailing list
>PanoTools-devel@...
>https://lists.sourceforge.net/lists/listinfo/panotools-devel
>  
>

Hi Pablo,

excellent idea!

I read through the FAQ and Wiki of the SoC, find my
thoughts below.


--- Pablo dAngelo <pablo.dangelo@...> wrote:
> I'm not sure if hugin is big enough for google to be
> considered

Size does not seem to be a criteria. 
<http://code.google.com/support/bin/answer.py?answer=60281&topic=10730>
hugin/panotools/tlalli seems to me to be "active" and
"viable", though ultimatively it is Google's Open
Source Program Office that will decide on
applications. They expect 100 mentoring orgs. I don't
know how many applications they will have nor how they
will select, but I think it is worth giving it a try.

As a mentoring organization, the hugin project (or
whatever we choose to be the mentoring org) has a
window of opportunity to apply from march 5 to march
12.

<http://code.google.com/support/bin/answer.py?answer=60303&topic=10727>

is what we'd have to work on.

I've started
<http://wiki.panotools.org/Google_SoC_2007> and
everybody is welcome to add there.

I've also already written some blah blah in there - I
was in BS mode as I am currently contributing to a
government funding application (they all ask the same
questions).

Pablo, could you rewrite your project ideas in the
document that was open for them at the link above,
please?

then we need to get organized and last but not least
recruit the student(s). I would start with recruiting
both the steering committee (organization) and the
students simultaneously, even before we have Google
funds. Just inform the community at large of our
intention and tell potential students to pencil in the
dates in their calendar.

I guess that there are qualifying students on
panotools-devel and hugin-ptx. Maybe a call on the
user lists such as NG would help too. We should ask
people even if they are no students. Maybe there is a
student in the family or they know somebody
interested.


> Maybe with some backing from the panotools-list
> verein, there would be a chance to get accepted?

we should get as much backing as possible. the user
community is very important. I think that if we show
the practical applications we have a better chance to
be selected by Google.

If we show user commitment (e.g. start another
donation drive for pano equipment to give to the
student) we are more likely to get passionate and
successful students and the backing of Google.


>  From what I read, we need a fallback mentor and

In terms of mentorship, I'd love to see academics. I
am thinking of Daniel and JD, and of course you,
Pablo. Sorry if I forgot to mention anybody.
Volunteers?


> some organizer that stays in contact with google
> and mediates if something goes wrong.

I think best is a user here. Backed by a strong
steering committee. I've started drafting the stuff,
though we might find a more appropriate candidate for
the job. We have time to define who that will be until
march 5-12. Until then, let's get invitations out to
the steering committee and see how many people we can
get there.

Yuv


 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

Hi Yuval,

> Hi Pablo,
> --- Pablo dAngelo <pablo.dangelo@...> wrote:
>> I'm not sure if hugin is big enough for google to be
>> considered
> 
> Size does not seem to be a criteria. 
> <http://code.google.com/support/bin/answer.py?answer=60281&topic=10730>
> hugin/panotools/tlalli seems to me to be "active" and
> "viable", though ultimatively it is Google's Open
> Source Program Office that will decide on
> applications. They expect 100 mentoring orgs. I don't
> know how many applications they will have nor how they
> will select, but I think it is worth giving it a try.

I have read some discussions on the openicc lists about failed attempts 2006:
http://lists.freedesktop.org/archives/openicc/2007q1/000810.html

> Pablo, could you rewrite your project ideas in the
> document that was open for them at the link above,
> please?

http://wiki.panotools.org/SoC2007_projects

I would be very happy about feedback about my project
ideas.

ciao
  Pablo

Le samedi 17 f=E9vrier 2007, Pablo dAngelo a =E9crit=A0:
> Hi all,
>=20
> I just noticed (on the openicc mailing list) that the google summer of=20
> code starts soon.
> http://code.google.com/soc
>=20
> I would be happy to mentor one student for one of the following projects:
>=20
> 1. Implementation of the SURF feature detector and matcher, and=20
> improving its
>     performance on heavily distorted images (fisheye + wideangle). I=20
> believe this
>     is also quite interesting for the students future, since this is=20
> based on state of
>     the art research. This would be great, since a good detector for=20
> these image
>     types is currently missing in the opensource world.
[...]

Hi,

I'm interested in implementing the SURF algorithm. I was already thinking t=
o=20
implement it as a school work, and I would be happy to be part of the SoC.

=2D-=20
=46lorent

Florent Bayle schrieb:

> Hi,
> 
> I'm interested in implementing the SURF algorithm. I was already thinking to 
> implement it as a school work, and I would be happy to be part of the SoC.

Good.

Actually, for the panorama use, I think we should build a
detector/descriptor that is more tailored our needs than SURF. We still got
Herbert Bay (SURF) as the second mentor :-)

ciao
  Pablo

yuval> I guess that there are qualifying students on
 yuval> panotools-devel and hugin-ptx. Maybe a call on the
 yuval> user lists such as NG would help too. We should ask
 yuval> people even if they are no students. Maybe there is a
 yuval> student in the family or they know somebody
 yuval> interested.

I can also advertise locally. We have good students. I wonder if
master's students qualify for this. They would be great in the
algorithms part.


 yuval> In terms of mentorship, I'd love to see academics. I
 yuval> am thinking of Daniel and JD, and of course you,
 yuval> Pablo. Sorry if I forgot to mention anybody.
 yuval> Volunteers?

That is my day job :) I mentioned in my previous message that I'll be
happy to mentor.


 yuval> I think best is a user here. Backed by a strong
 yuval> steering committee. I've started drafting the stuff,
 yuval> though we might find a more appropriate candidate for
 yuval> the job. We have time to define who that will be until
 yuval> march 5-12. Until then, let's get invitations out to
 yuval> the steering committee and see how many people we can
 yuval> get there.

 yuval> https://lists.sourceforge.net/lists/listinfo/panotools-devel

--
Daniel M. German                  "The energy of the world is constant.
   Rudolf Clausius ->              Its entropy tends to a maximum."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Pablo> Hi all,
 Pablo> I just noticed (on the openicc mailing list) that the google summer of 
 Pablo> code starts soon.
 Pablo> http://code.google.com/soc

 Pablo> I would be happy to mentor one student for one of the following projects:

Hi Pablo,

I am not sure this message will make it to the panotools list (we just
had a renumbering of IPs and i have been having firewalling problems).

Anyways, here is my idea:

* I think  "Hugin" qualifies as an organization. It has a good
  reputation and lots of users.

* I can be the "secundary" mentor. As you know, I do supervision of
  students for a living :)


I think you can target two different goals.

1. The implemention of the algorithms. This will require that they are
   well defined and tractable by a student. If you have the matlab
   that would be great. You should  mention that.

2. The GUI. I really think this is where we can get the most out of a
   student. We can even make it clear that hugin can be improved
   dramatically (like the message sent few days ago with small
   ideas). 

#2 is more tangible and has more specific goals. And this is an area
 where many of us are not very interested :)

 Pablo> I have never participated in the summer of code, and I'm not
 Pablo> sure if hugin is big enough for google to be considered,
 Pablo> although hugin, panotools (tlalli) and enblend

we do not lose anything by trying... except the time invested in the
proposal..

--
Daniel M. German                  "If builders built buildings
                                   the way computer programmers
                                   write programs, the first woodpecker
                                   that came along
                                   would have destroyed
    Weinberg's law  ->             all civilization. "
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi,

I've just remembered someone has said something like we unfortunately =20=

do not have any good representation of PanoTools data other than =20
PTstitcher/PToptimiser script even for passing data between functions =20=

of different libraries.

Wouldn't it be a good idea to have a set of XML, C struct, or C++ =20
class as a portable data structure for passing PanoTools data between =20=

functions, libraries, processes, and computers? I've kind of found it =20=

sad and legacy way to parse and construct the script every time data =20
has to be passed on from one to the other.

I don't really know the internals of PanoTools much and I'm not =20
entirely sure about the situation, but it might be a good idea to =20
have a vision, because if an improvement is possible that's another =20
good project for the SoC students.

Any ideas?

Ippei

On 2007-02-17, at 19:21, Pablo dAngelo wrote:

> Hi all,
>
> I just noticed (on the openicc mailing list) that the google summer of
> code starts soon.
> http://code.google.com/soc
>
> I would be happy to mentor one student for one of the following =20
> projects:
>
> 1. Implementation of the SURF feature detector and matcher, and
> improving its
>     performance on heavily distorted images (fisheye + wideangle). I
> believe this
>     is also quite interesting for the students future, since this is
> based on state of
>     the art research. This would be great, since a good detector for
> these image
>     types is currently missing in the opensource world.
>
> 2. Improved blending and anti-ghosting program, especially with =20
> respect to
>     the creation of HDR panoramas from multiple exposures.
>
> I have supervised or co supervised some diploma (~masters) thesis =20
> in the
> last 3
> years, so I feel qualified to mentor a student.
>
> I have never participated in the summer of code, and I'm not sure if
> hugin is big
> enough for google to be considered, although hugin, panotools (tlalli)
> and enblend
> is the most advanced opensource panorama creation software.
> Maybe with some backing from the panotools-list verein, there would =20=

> be a
> chance to get accepted?
>
>  =46rom what I read, we need a fallback mentor and some organizer that
> stays in
> contact with google and mediates if something goes wrong.
>
> ciao
>   Pablo
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> PanoTools-devel mailing list
> PanoTools-devel@...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel



--
  ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3  (UKAI Ippei) =
->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/

Hi Ippei,

 What is needed is to break apart the two main functionalities if
panotools:

1. Registration

Registration can return a complex data structure or an object that
corresponds to the current "script".


2. Mapping.

Map one picture at a time by expanding CreatePanorama with the
parameters for that image, and an array of points to morph.  The
mapping procedure does not even need to know about the rest of the
images.

dmg


 Ippei UKAI twisted the bytes to say:

 Ippei> Hi,
 Ippei> I've just remembered someone has said something like we unfortunately  
 Ippei> do not have any good representation of PanoTools data other than  
 Ippei> PTstitcher/PToptimiser script even for passing data between functions  
 Ippei> of different libraries.

 Ippei> Wouldn't it be a good idea to have a set of XML, C struct, or C++  
 Ippei> class as a portable data structure for passing PanoTools data between  
 Ippei> functions, libraries, processes, and computers? I've kind of found it  
 Ippei> sad and legacy way to parse and construct the script every time data  
 Ippei> has to be passed on from one to the other.

 Ippei> I don't really know the internals of PanoTools much and I'm not  
 Ippei> entirely sure about the situation, but it might be a good idea to  
 Ippei> have a vision, because if an improvement is possible that's another  
 Ippei> good project for the SoC students.

 Ippei> Any ideas?

 Ippei> Ippei

 Ippei> On 2007-02-17, at 19:21, Pablo dAngelo wrote:

 >> Hi all,
 >> 
 >> I just noticed (on the openicc mailing list) that the google summer of
 >> code starts soon.
 >> http://code.google.com/soc
 >> 
 >> I would be happy to mentor one student for one of the following  
 >> projects:
 >> 
 >> 1. Implementation of the SURF feature detector and matcher, and
 >> improving its
 >> performance on heavily distorted images (fisheye + wideangle). I
 >> believe this
 >> is also quite interesting for the students future, since this is
 >> based on state of
 >> the art research. This would be great, since a good detector for
 >> these image
 >> types is currently missing in the opensource world.
 >> 
 >> 2. Improved blending and anti-ghosting program, especially with  
 >> respect to
 >> the creation of HDR panoramas from multiple exposures.
 >> 
 >> I have supervised or co supervised some diploma (~masters) thesis  
 >> in the
 >> last 3
 >> years, so I feel qualified to mentor a student.
 >> 
 >> I have never participated in the summer of code, and I'm not sure if
 >> hugin is big
 >> enough for google to be considered, although hugin, panotools (tlalli)
 >> and enblend
 >> is the most advanced opensource panorama creation software.
 >> Maybe with some backing from the panotools-list verein, there would  
 >> be a
 >> chance to get accepted?
 >> 
 >> From what I read, we need a fallback mentor and some organizer that
 >> stays in
 >> contact with google and mediates if something goes wrong.
 >> 
 >> ciao
 >> Pablo
 >> 
 >> ---------------------------------------------------------------------- 
 >> ---
 >> Take Surveys. Earn Cash. Influence the Future of IT
 >> Join SourceForge.net's Techsay panel and you'll get the chance to  
 >> share your
 >> opinions on IT & business topics through brief surveys-and earn cash
 >> http://www.techsay.com/default.php? 
 >> page=join.php&p=sourceforge&CID=DEVDEV
 >> _______________________________________________
 >> PanoTools-devel mailing list
 >> PanoTools-devel@...
 >> https://lists.sourceforge.net/lists/listinfo/panotools-devel



 Ippei> --
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/




 Ippei> -------------------------------------------------------------------------
 Ippei> Take Surveys. Earn Cash. Influence the Future of IT
 Ippei> Join SourceForge.net's Techsay panel and you'll get the chance to share your
 Ippei> opinions on IT & business topics through brief surveys-and earn cash
 Ippei> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
 Ippei> _______________________________________________
 Ippei> PanoTools-devel mailing list
 Ippei> PanoTools-devel@...
 Ippei> https://lists.sourceforge.net/lists/listinfo/panotools-devel

--
Daniel M. German                  "If your photographs are not good enough,
   Robert Capa ->                  you are not close enough."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi Daniel,

My idea was to restructure the panotools into:

1. Good data structure
- File format (currently script, but we could define a new better  
schemes with XML)
- IO functionality that converts between the file format and the data  
representations used in the programs.
- Panorama data representations that can be used by many applications  
(C++ class / C structure + functions)

2. Basic Toolkit that does something with the data in the above format
- Optimiser: reads the control points, modifies the parameters and  
positions
- Stitcher: reads the parameters and positions, and the configuration  
for the output perspective/projection/image etc., and outputs the  
images accordingly

I'm not sure what you mean by Registration and Mapping, but if you  
mean the separation of general mapping engine + projection definition  
(like a shading language?), I was looking at a larger picture.

Apologies if I've misunderstood the nature of problems, but I thought  
the problem was that the data representation is sort of in a higher  
level and a lower level representation that all applications can  
happily use directly would be desirable. I just thought something  
like XML can be defined modular so that one project can have one  
representation of where the photos are mapped on the sphere, three of  
camera/lens parameters, and two of how those should be output etc. It  
even allows us to separate files for each of those.

Anyway, my point is that one can work on this kind of foundational  
improvements during the summer too if we put as the SoC project. That  
way, we would probably get a better framework to write panorama  
imaging algorithms in after the summer. I'm not one of those who  
understand inside the black-box of the individual panotools  
processes, but I feel the current framework makes the panotools more  
like a black-suck that is even hard for programmers to use it from  
outside, not to mention how it should be extended.

Ippei


On 2007-03-13, at 03:28, Daniel M. German wrote:

> Hi Ippei,
>
>  What is needed is to break apart the two main functionalities if
> panotools:
>
> 1. Registration
>
> Registration can return a complex data structure or an object that
> corresponds to the current "script".
>
>
> 2. Mapping.
>
> Map one picture at a time by expanding CreatePanorama with the
> parameters for that image, and an array of points to morph.  The
> mapping procedure does not even need to know about the rest of the
> images.
>
> dmg
>
>
>  Ippei UKAI twisted the bytes to say:
>
>  Ippei> Hi,
>  Ippei> I've just remembered someone has said something like we  
> unfortunately
>  Ippei> do not have any good representation of PanoTools data other  
> than
>  Ippei> PTstitcher/PToptimiser script even for passing data between  
> functions
>  Ippei> of different libraries.
>
>  Ippei> Wouldn't it be a good idea to have a set of XML, C struct,  
> or C++
>  Ippei> class as a portable data structure for passing PanoTools  
> data between
>  Ippei> functions, libraries, processes, and computers? I've kind  
> of found it
>  Ippei> sad and legacy way to parse and construct the script every  
> time data
>  Ippei> has to be passed on from one to the other.
>
>  Ippei> I don't really know the internals of PanoTools much and I'm  
> not
>  Ippei> entirely sure about the situation, but it might be a good  
> idea to
>  Ippei> have a vision, because if an improvement is possible that's  
> another
>  Ippei> good project for the SoC students.
>
>  Ippei> Any ideas?
>
>  Ippei> Ippei
>
>  Ippei> On 2007-02-17, at 19:21, Pablo dAngelo wrote:
>
>>> Hi all,
>>>
>>> I just noticed (on the openicc mailing list) that the google  
>>> summer of
>>> code starts soon.
>>> http://code.google.com/soc
>>>
>>> I would be happy to mentor one student for one of the following
>>> projects:
>>>
>>> 1. Implementation of the SURF feature detector and matcher, and
>>> improving its
>>> performance on heavily distorted images (fisheye + wideangle). I
>>> believe this
>>> is also quite interesting for the students future, since this is
>>> based on state of
>>> the art research. This would be great, since a good detector for
>>> these image
>>> types is currently missing in the opensource world.
>>>
>>> 2. Improved blending and anti-ghosting program, especially with
>>> respect to
>>> the creation of HDR panoramas from multiple exposures.
>>>
>>> I have supervised or co supervised some diploma (~masters) thesis
>>> in the
>>> last 3
>>> years, so I feel qualified to mentor a student.
>>>
>>> I have never participated in the summer of code, and I'm not sure if
>>> hugin is big
>>> enough for google to be considered, although hugin, panotools  
>>> (tlalli)
>>> and enblend
>>> is the most advanced opensource panorama creation software.
>>> Maybe with some backing from the panotools-list verein, there would
>>> be a
>>> chance to get accepted?
>>>
>>> From what I read, we need a fallback mentor and some organizer that
>>> stays in
>>> contact with google and mediates if something goes wrong.
>>>
>>> ciao
>>> Pablo
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> share your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>> http://www.techsay.com/default.php?
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> PanoTools-devel mailing list
>>> PanoTools-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
>
>
>  Ippei> --
>   ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
>    MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
>    Homepage:  http://homepage.mac.com/ippei_ukai/
>
>
>
>
>  Ippei>  
> ---------------------------------------------------------------------- 
> ---
>  Ippei> Take Surveys. Earn Cash. Influence the Future of IT
>  Ippei> Join SourceForge.net's Techsay panel and you'll get the  
> chance to share your
>  Ippei> opinions on IT & business topics through brief surveys-and  
> earn cash
>  Ippei> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
>  Ippei> _______________________________________________
>  Ippei> PanoTools-devel mailing list
>  Ippei> PanoTools-devel@...
>  Ippei> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
> --
> Daniel M. German                  "If your photographs are not good  
> enough,
>    Robert Capa ->                  you are not close enough."
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google  
> Groups "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http:// 
> wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugin-ptx@...
> To unsubscribe from this group, send email to hugin-ptx- 
> unsubscribe@...
> For more options, visit this group at http://groups.google.com/ 
> group/hugin-ptx
> -~----------~----~----~----~------~----~------~--~---
>



--
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/

Hi Ippei,

 Ippei> My idea was to restructure the panotools into:

 Ippei> 1. Good data structure
 Ippei> - File format (currently script, but we could define a new better  
 Ippei> schemes with XML)
 Ippei> - IO functionality that converts between the file format and the data  
 Ippei> representations used in the programs.
 Ippei> - Panorama data representations that can be used by many applications  
 Ippei> (C++ class / C structure + functions)

Panotools needs a total rehaul from the internal point of view, IMO.

But the reality is that you don't need a complex data structure to
call panotools.

Panotools does two things, mainly:

1. OPtimization step (what I call registration). It receives as an
   input a bunch of control points and does its best to "match"
   them. In its current implementation it does not require access to
   the images. It outputs a set of <yaw,roll,pitch> for each image, +
   lens parameters for each different lens.

2. Mapping. Takes an image, yaw, roll and pitch, and lens parameters,
   + optional morph-to control points. Output is an image.

I lean towards the idea of encapsulation. you don't want the caller to
know more than it needs. What we need are functions that take all the
information as input and return the corresponding result. Doing that
will oviate the need to use scripts, and it will make the rewriting
the panotools easier.

So what is neeeded are data structures that replace the parameters
(there are too many). The data structure should be marshall-able as an
XML file (or even a PTstitcher script).

In fact, once this data structure is defined and implemented, it will
be easy to split panotools into 2 different systems: optimization and
mapping. Having both in one library makes things more complex than
they need to be.


 Ippei> Apologies if I've misunderstood the nature of problems, but I thought  
 Ippei> the problem was that the data representation is sort of in a higher  
 Ippei> level and a lower level representation that all applications can  
 Ippei> happily use directly would be desirable. I just thought something  
 Ippei> like XML can be defined modular so that one project can have one  
 Ippei> representation of where the photos are mapped on the sphere, three of  
 Ippei> camera/lens parameters, and two of how those should be output etc. It  
 Ippei> even allows us to separate files for each of those.

The problem, in my opinoin, is that there are no functions to call in
panotools to do either job only.

 Ippei> Anyway, my point is that one can work on this kind of foundational  
 Ippei> improvements during the summer too if we put as the SoC project. That  
 Ippei> way, we would probably get a better framework to write panorama  
 Ippei> imaging algorithms in after the summer. I'm not one of those who  
 Ippei> understand inside the black-box of the individual panotools  
 Ippei> processes, but I feel the current framework makes the panotools more  
 Ippei> like a black-suck that is even hard for programmers to use it from  
 Ippei> outside, not to mention how it should be extended.

 Ippei> Ippei


 Ippei> On 2007-03-13, at 03:28, Daniel M. German wrote:

 >> Hi Ippei,
 >> 
 >> What is needed is to break apart the two main functionalities if
 >> panotools:
 >> 
 >> 1. Registration
 >> 
 >> Registration can return a complex data structure or an object that
 >> corresponds to the current "script".
 >> 
 >> 
 >> 2. Mapping.
 >> 
 >> Map one picture at a time by expanding CreatePanorama with the
 >> parameters for that image, and an array of points to morph.  The
 >> mapping procedure does not even need to know about the rest of the
 >> images.
 >> 
 >> dmg
 >> 
 >> 
 >> Ippei UKAI twisted the bytes to say:
 >> 
 Ippei> Hi,
 Ippei> I've just remembered someone has said something like we  
 >> unfortunately
 Ippei> do not have any good representation of PanoTools data other  
 >> than
 Ippei> PTstitcher/PToptimiser script even for passing data between  
 >> functions
 Ippei> of different libraries.
 >> 
 Ippei> Wouldn't it be a good idea to have a set of XML, C struct,  
 >> or C++
 Ippei> class as a portable data structure for passing PanoTools  
 >> data between
 Ippei> functions, libraries, processes, and computers? I've kind  
 >> of found it
 Ippei> sad and legacy way to parse and construct the script every  
 >> time data
 Ippei> has to be passed on from one to the other.
 >> 
 Ippei> I don't really know the internals of PanoTools much and I'm  
 >> not
 Ippei> entirely sure about the situation, but it might be a good  
 >> idea to
 Ippei> have a vision, because if an improvement is possible that's  
 >> another
 Ippei> good project for the SoC students.
 >> 
 Ippei> Any ideas?
 >> 
 Ippei> Ippei
 >> 
 Ippei> On 2007-02-17, at 19:21, Pablo dAngelo wrote:
 >> 
 >>>> Hi all,
 >>>> 
 >>>> I just noticed (on the openicc mailing list) that the google  
 >>>> summer of
 >>>> code starts soon.
 >>>> http://code.google.com/soc
 >>>> 
 >>>> I would be happy to mentor one student for one of the following
 >>>> projects:
 >>>> 
 >>>> 1. Implementation of the SURF feature detector and matcher, and
 >>>> improving its
 >>>> performance on heavily distorted images (fisheye + wideangle). I
 >>>> believe this
 >>>> is also quite interesting for the students future, since this is
 >>>> based on state of
 >>>> the art research. This would be great, since a good detector for
 >>>> these image
 >>>> types is currently missing in the opensource world.
 >>>> 
 >>>> 2. Improved blending and anti-ghosting program, especially with
 >>>> respect to
 >>>> the creation of HDR panoramas from multiple exposures.
 >>>> 
 >>>> I have supervised or co supervised some diploma (~masters) thesis
 >>>> in the
 >>>> last 3
 >>>> years, so I feel qualified to mentor a student.
 >>>> 
 >>>> I have never participated in the summer of code, and I'm not sure if
 >>>> hugin is big
 >>>> enough for google to be considered, although hugin, panotools  
 >>>> (tlalli)
 >>>> and enblend
 >>>> is the most advanced opensource panorama creation software.
 >>>> Maybe with some backing from the panotools-list verein, there would
 >>>> be a
 >>>> chance to get accepted?
 >>>> 
 >>>> From what I read, we need a fallback mentor and some organizer that
 >>>> stays in
 >>>> contact with google and mediates if something goes wrong.
 >>>> 
 >>>> ciao
 >>>> Pablo
 >>>> 
 >>>> -------------------------------------------------------------------- 
 >>>> --
 >>>> ---
 >>>> Take Surveys. Earn Cash. Influence the Future of IT
 >>>> Join SourceForge.net's Techsay panel and you'll get the chance to
 >>>> share your
 >>>> opinions on IT & business topics through brief surveys-and earn cash
 >>>> http://www.techsay.com/default.php?
 >>>> page=join.php&p=sourceforge&CID=DEVDEV
 >>>> _______________________________________________
 >>>> PanoTools-devel mailing list
 >>>> PanoTools-devel@...
 >>>> https://lists.sourceforge.net/lists/listinfo/panotools-devel
 >> 
 >> 
 >> 
 Ippei> --
 -> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
 >> MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
 >> Homepage:  http://homepage.mac.com/ippei_ukai/
 >> 
 >> 
 >> 
 >> 
 Ippei> 
 >> ---------------------------------------------------------------------- 
 >> ---
 Ippei> Take Surveys. Earn Cash. Influence the Future of IT
 Ippei> Join SourceForge.net's Techsay panel and you'll get the  
 >> chance to share your
 Ippei> opinions on IT & business topics through brief surveys-and  
 >> earn cash
 Ippei> http://www.techsay.com/default.php? 
 >> page=join.php&p=sourceforge&CID=DEVDEV
 Ippei> _______________________________________________
 Ippei> PanoTools-devel mailing list
 Ippei> PanoTools-devel@...
 Ippei> https://lists.sourceforge.net/lists/listinfo/panotools-devel
 >> 
 >> --
 >> Daniel M. German                  "If your photographs are not good  
 >> enough,
 >> Robert Capa ->                  you are not close enough."
 >> http://turingmachine.org/
 >> http://silvernegative.com/
 >> dmg (at) uvic (dot) ca
 >> replace (at) with @ and (dot) with .
 >> 
 >> 
 >> 
 >> >



 Ippei> --
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/




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

--
Daniel M. German                  "You can't trust code that
                                   you did not totally create
                                   yourself
                                   (Especially code from companies
   Ken Thompson ->                 that employ people like me.)"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

On 2007-03-13, at 20:36, Daniel M. German wrote:

> Hi Ippei,
>
>  Ippei> My idea was to restructure the panotools into:
>
>  Ippei> 1. Good data structure
>  Ippei> - File format (currently script, but we could define a new  
> better
>  Ippei> schemes with XML)
>  Ippei> - IO functionality that converts between the file format  
> and the data
>  Ippei> representations used in the programs.
>  Ippei> - Panorama data representations that can be used by many  
> applications
>  Ippei> (C++ class / C structure + functions)
>
> Panotools needs a total rehaul from the internal point of view, IMO.
>
> But the reality is that you don't need a complex data structure to
> call panotools.

I think we are getting the same place anyway. I was rather thinking  
in OOP stylistics, and probably the flat C way of implementing it is  
what you are suggesting here.

> Panotools does two things, mainly:
>
> 1. OPtimization step (what I call registration). It receives as an
>    input a bunch of control points and does its best to "match"
>    them. In its current implementation it does not require access to
>    the images. It outputs a set of <yaw,roll,pitch> for each image, +
>    lens parameters for each different lens.
>
> 2. Mapping. Takes an image, yaw, roll and pitch, and lens parameters,
>    + optional morph-to control points. Output is an image.

I see. I was looking at it rather as data + operations rather than  
pipe-lined operations.

> I lean towards the idea of encapsulation. you don't want the caller to
> know more than it needs. What we need are functions that take all the
> information as input and return the corresponding result. Doing that
> will oviate the need to use scripts, and it will make the rewriting
> the panotools easier.
>
> So what is neeeded are data structures that replace the parameters
> (there are too many). The data structure should be marshall-able as an
> XML file (or even a PTstitcher script).
>
> In fact, once this data structure is defined and implemented, it will
> be easy to split panotools into 2 different systems: optimization and
> mapping. Having both in one library makes things more complex than
> they need to be.

That's exactly what I was suggesting:) And with a few design  
consideration, that XML can hold any combination of image  
information, lens information, mapping information etc. which makes  
perfect for hugin as well as single task that only requires one or  
two of those.

>  Ippei> Apologies if I've misunderstood the nature of problems, but  
> I thought
>  Ippei> the problem was that the data representation is sort of in  
> a higher
>  Ippei> level and a lower level representation that all  
> applications can
>  Ippei> happily use directly would be desirable. I just thought  
> something
>  Ippei> like XML can be defined modular so that one project can  
> have one
>  Ippei> representation of where the photos are mapped on the  
> sphere, three of
>  Ippei> camera/lens parameters, and two of how those should be  
> output etc. It
>  Ippei> even allows us to separate files for each of those.
>
> The problem, in my opinoin, is that there are no functions to call in
> panotools to do either job only.

True. And that's the problem I'm looking at, just wasn't thinking in  
terms of the library structure.

Anyway, with your clarification, it now looks much simpler than I  
thought. Sounds like another possibility for the SoC project that I  
might be able to choose from:)

Ippei


--
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/

Hi Ippei,

 Ippei> I think we are getting the same place anyway. I was rather thinking  
 Ippei> in OOP stylistics, and probably the flat C way of implementing it is  
 Ippei> what you are suggesting here.

Wrapping panotools with C++ would be a great idea.

In summary, what this job requires is to replace the parser of
panootools. This is not easy, because they are too many things done
during parsing, and the parser is very messy in its current state.

dmg



--
Daniel M. German                  "The WWW might get the glory,
                                   but e-mail is the quiet
   Beppi Crosanol ->               workhorse of the digital age."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi all,

I have just written a small command line tool to automatically align a stack
of images, similar to the manual method described in the wiki page at
http://wiki.panotools.org/Align_a_stack_of_photos

During this I remembered that we need a nice interface to the panorama data
model. The C++ classes I have written for managing the panorama data in the
hugin project have turned into a bloated API over the years. So some simple,
clean interface would be definitely useful.

Daniel M. German wrote:
> Hi Ippei,
> 
> Panotools needs a total rehaul from the internal point of view, IMO.
> 
> But the reality is that you don't need a complex data structure to
> call panotools.
> 
> Panotools does two things, mainly:
> 
> 1. OPtimization step (what I call registration). It receives as an
>    input a bunch of control points and does its best to "match"
>    them. In its current implementation it does not require access to
>    the images. It outputs a set of <yaw,roll,pitch> for each image, +
>    lens parameters for each different lens.
> 
> 2. Mapping. Takes an image, yaw, roll and pitch, and lens parameters,
>    + optional morph-to control points. Output is an image.
> 
> I lean towards the idea of encapsulation. you don't want the caller to
> know more than it needs. What we need are functions that take all the
> information as input and return the corresponding result. Doing that
> will oviate the need to use scripts, and it will make the rewriting
> the panotools easier.
>
> So what is neeeded are data structures that replace the parameters
> (there are too many).

I don't understand what you mean with too many parameters?

> In fact, once this data structure is defined and implemented, it will
> be easy to split panotools into 2 different systems: optimization and
> mapping. Having both in one library makes things more complex than
> they need to be.

And both will depend on the projection library :-)

Actually, for the mapping part, I would suggest instead of doing all the
lowlevel stuff ourself and limit everything to tiff files (which is an
enormous waste of disk space for real HDR panoramas, especially when all the
intermediate files get stored on the hard disk), we should use a library
that has been build with large images and flexible processing in mind, such as
VIPS. VIPS has been designed from the ground up to work with images bigger
than the available memory, has been tested on a 64 CPU machine with a good
speedup, and can be easily scripted with python. Additionally it has a
very nice, high level C++ interface. We can tap all this by porting the
panotools mapping function to a VIPS operation, which shouldn't be terribly
hard (although this is the "dirty" part of VIPS), given that the main author
will help us :-)

http://wiki.panotools.org/SoC2007_projects#Processing_of_very_large_images

>  Ippei> Anyway, my point is that one can work on this kind of foundational  
>  Ippei> improvements during the summer too if we put as the SoC project. That  
>  Ippei> way, we would probably get a better framework to write panorama  
>  Ippei> imaging algorithms in after the summer. I'm not one of those who  
>  Ippei> understand inside the black-box of the individual panotools  
>  Ippei> processes, but I feel the current framework makes the panotools more  
>  Ippei> like a black-suck that is even hard for programmers to use it from  
>  Ippei> outside, not to mention how it should be extended.

I understand most of the inside, and you are definitely right about the
interface. Seems like we have many candidates for projects :-)

Daniel, maybe this is a project you could mentor?


ciao
  Pablo

On 2007-03-13, at 23:17, Pablo d'Angelo wrote:

>> In fact, once this data structure is defined and implemented, it will
>> be easy to split panotools into 2 different systems: optimization and
>> mapping. Having both in one library makes things more complex than
>> they need to be.
>
> And both will depend on the projection library :-)

I'm confused. I thought mapping/optimisation is done to put the  
images on the sphere surface (or whatever way in a 3D space), and  
projection/stitcher engine produces the images by sort of taking  
picture from the centre of that world with different projections (or  
an interactive VR snap, or even a movie which could be really cool).  
I don't understand why would the optimisation process ever need to  
know about the projection.

> Actually, for the mapping part, I would suggest instead of doing  
> all the
> lowlevel stuff ourself and limit everything to tiff files (which is an
> enormous waste of disk space for real HDR panoramas, especially  
> when all the
> intermediate files get stored on the hard disk), we should use a  
> library
> that has been build with large images and flexible processing in  
> mind, such as
> VIPS. VIPS has been designed from the ground up to work with images  
> bigger
> than the available memory, has been tested on a 64 CPU machine with  
> a good
> speedup, and can be easily scripted with python. Additionally it has a
> very nice, high level C++ interface. We can tap all this by porting  
> the
> panotools mapping function to a VIPS operation, which shouldn't be  
> terribly
> hard (although this is the "dirty" part of VIPS), given that the  
> main author
> will help us :-)
>
> http://wiki.panotools.org/ 
> SoC2007_projects#Processing_of_very_large_images

I wonder any cross-platform CPU-only compatible GPU-aware tool is up  
there. On Mac, Apple's Quartz Composer does something really  
interesting; please look at the screenshot (I tried it out two years  
ago when Tiger came out). It's based on GLSL, and runs with the best  
available processor unit on the machine (GPU/AltiVec/SSE).

Anyway, I think the best is to make sure we will have a fixed API for  
any small components of the library (that's what I learnt in CS1;  
break up tasks and give each component as generic interface as  
possible). That way, we can easily extend/replace/modify only the  
required part later whatever implementation we choose now. Moreover,  
I think we should prefer LGPL for newly written parts so that some  
developers could write closed source versions of specific part of the  
library for their purposes. The already written part can be modified  
to follow the same new APIs still remaining under GPL.

I'm saying this because panotools can provide a set of general  
framework, and for example PTMac could write its own projection  
engine with Mac OS X's API, and still use the same optimiser etc. At  
least I think that's how opensource libraries should be. Of course  
the panotools/hugin would aim for the best cross-platform opensource  
implementation around because that's our goal, but there are  
different needs in the field and we can seek the way to keep us both  
happily alive.

>>  Ippei> Anyway, my point is that one can work on this kind of  
>> foundational
>>  Ippei> improvements during the summer too if we put as the SoC  
>> project. That
>>  Ippei> way, we would probably get a better framework to write  
>> panorama
>>  Ippei> imaging algorithms in after the summer. I'm not one of  
>> those who
>>  Ippei> understand inside the black-box of the individual panotools
>>  Ippei> processes, but I feel the current framework makes the  
>> panotools more
>>  Ippei> like a black-suck that is even hard for programmers to use  
>> it from
>>  Ippei> outside, not to mention how it should be extended.
>
> I understand most of the inside, and you are definitely right about  
> the
> interface. Seems like we have many candidates for projects :-)

I think I'm going to apply for this one as well as the hugin  
renovation. If someone who is better at Qt4 or whatever GUI library  
wanted the hugin work, I'd be more useful working on this one.

Ippei

Ippei UKAI wrote:
> On 2007-03-13, at 23:17, Pablo d'Angelo wrote:
>   
>>> In fact, once this data structure is defined and implemented, it will
>>> be easy to split panotools into 2 different systems: optimization and
>>> mapping. Having both in one library makes things more complex than
>>> they need to be.
>>>       
>> And both will depend on the projection library :-)
>>     
>
> I'm confused. I thought mapping/optimisation is done to put the  
> images on the sphere surface (or whatever way in a 3D space), and  
> projection/stitcher engine produces the images by sort of taking  
> picture from the centre of that world with different projections (or  
> an interactive VR snap, or even a movie which could be really cool).  
> I don't understand why would the optimisation process ever need to  
> know about the projection.
>   
Going by memory.
The error reported back from the optimizer is the distance the on the 
projection selected.
The error used internally to find closest fit, is the distance on a 
sphere for normal control points but for lines (horizontal, vertical, 
and straight) control points it uses the projection selected.

It may be worth investigating if all line control points should be 
optimized for rectilinear projection regardless of projection selected. 

The problem: no longer able to use line control points to optimize a pan 
taken from a the center of a circle to spherical projection.

-- 
Jim Watters

jwatters @ photocreations . ca
http://photocreations.ca

Hi Ippei

 Ippei> On 2007-03-13, at 23:17, Pablo d'Angelo wrote:
 >>> In fact, once this data structure is defined and implemented, it will
 >>> be easy to split panotools into 2 different systems: optimization and
 >>> mapping. Having both in one library makes things more complex than
 >>> they need to be.
 >> 
 >> And both will depend on the projection library :-)

I'll try to answer both messages in one.

1. The registration maps an image to a sphere. It is in this sphere that
optimization happens. In other words, panotools trie to find where in
this sphere this image corresponds to.

2. The mapping takes this sphere and projects it.

Both 1 and 2 require a projection library, but not to the same extend.

1 takes as input only rectilinear, equirectangular, fisheye equisolid
(correct me if I am wrong, but this sounds like azimuth equal area)
and cylindrical (I don't really know why cylindrical, but that is a
different story).

2 takes the sphere and projects into whatever we want. Panotools
supports 10 (I think) projection (tlalli has 14).


1 only requires very simple projections. 


This is the conundrum. Should we support more input projections? I
would say no, but not to close the door and hardcode it.

So what Pablo is saying is right, panotools remapping is 3 systems:

1. Registration optimization

2. Remapping of sphere to output projection

3. Projections library

and I would add:

4. Parsing of input


 Ippei> I'm confused. I thought mapping/optimisation is done to put the  
 Ippei> images on the sphere surface (or whatever way in a 3D space), and  
 Ippei> projection/stitcher engine produces the images by sort of taking  
 Ippei> picture from the centre of that world with different projections (or  
 Ippei> an interactive VR snap, or even a movie which could be really cool).  
 Ippei> I don't understand why would the optimisation process ever need to  
 Ippei> know about the projection.


The reason that the optimization needs to know the input projection is
that it needs to know where an x,y point in the photo corresponds to
the sphere.

Why thing that panotools does not do is to assume a flat field,
instead of a sphere to stitching. That limits the use of panotools,
and makes it difficult to stitch "murals" and similar objects when you
know the photos were "perfectly" parallel to each other

I hope this clarifies your doubts.

I think rehauling panotools is a summer project. And it will be fun,
but it requires a lot of reengenering to get it "right". 

dmg

 >> Actually, for the mapping part, I would suggest instead of doing  
 >> all the
 >> lowlevel stuff ourself and limit everything to tiff files (which is an
 >> enormous waste of disk space for real HDR panoramas, especially  
 >> when all the
 >> intermediate files get stored on the hard disk), we should use a  
 >> library
 >> that has been build with large images and flexible processing in  
 >> mind, such as
 >> VIPS. VIPS has been designed from the ground up to work with images  
 >> bigger
 >> than the available memory, has been tested on a 64 CPU machine with  
 >> a good
 >> speedup, and can be easily scripted with python. Additionally it has a
 >> very nice, high level C++ interface. We can tap all this by porting  
 >> the
 >> panotools mapping function to a VIPS operation, which shouldn't be  
 >> terribly
 >> hard (although this is the "dirty" part of VIPS), given that the  
 >> main author
 >> will help us :-)
 >> 
 >> http://wiki.panotools.org/ 
 >> SoC2007_projects#Processing_of_very_large_images

 Ippei> I wonder any cross-platform CPU-only compatible GPU-aware tool is up  
 Ippei> there. On Mac, Apple's Quartz Composer does something really  
 Ippei> interesting; please look at the screenshot (I tried it out two years  
 Ippei> ago when Tiger came out). It's based on GLSL, and runs with the best  
 Ippei> available processor unit on the machine (GPU/AltiVec/SSE).

 Ippei> Anyway, I think the best is to make sure we will have a fixed API for  
 Ippei> any small components of the library (that's what I learnt in CS1;  
 Ippei> break up tasks and give each component as generic interface as  
 Ippei> possible). That way, we can easily extend/replace/modify only the  
 Ippei> required part later whatever implementation we choose now. Moreover,  
 Ippei> I think we should prefer LGPL for newly written parts so that some  
 Ippei> developers could write closed source versions of specific part of the  
 Ippei> library for their purposes. The already written part can be modified  
 Ippei> to follow the same new APIs still remaining under GPL.

 Ippei> I'm saying this because panotools can provide a set of general  
 Ippei> framework, and for example PTMac could write its own projection  
 Ippei> engine with Mac OS X's API, and still use the same optimiser etc. At  
 Ippei> least I think that's how opensource libraries should be. Of course  
 Ippei> the panotools/hugin would aim for the best cross-platform opensource  
 Ippei> implementation around because that's our goal, but there are  
 Ippei> different needs in the field and we can seek the way to keep us both  
 Ippei> happily alive.

 Ippei> Anyway, my point is that one can work on this kind of  
 >>> foundational
 Ippei> improvements during the summer too if we put as the SoC  
 >>> project. That
 Ippei> way, we would probably get a better framework to write  
 >>> panorama
 Ippei> imaging algorithms in after the summer. I'm not one of  
 >>> those who
 Ippei> understand inside the black-box of the individual panotools
 Ippei> processes, but I feel the current framework makes the  
 >>> panotools more
 Ippei> like a black-suck that is even hard for programmers to use  
 >>> it from
 Ippei> outside, not to mention how it should be extended.
 >> 
 >> I understand most of the inside, and you are definitely right about  
 >> the
 >> interface. Seems like we have many candidates for projects :-)

 Ippei> I think I'm going to apply for this one as well as the hugin  
 Ippei> renovation. If someone who is better at Qt4 or whatever GUI library  
 Ippei> wanted the hugin work, I'd be more useful working on this one.

 Ippei> Ippei



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


 Ippei> --
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/



--
Daniel M. German                  "A machine --computer-- can only do
   Lady Lovelance ->               what we tell it to do"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Daniel M. German wrote:
> 
> 1 takes as input only rectilinear, equirectangular, fisheye equisolid
> (correct me if I am wrong, but this sounds like azimuth equal area)
> and cylindrical (I don't really know why cylindrical, but that is a
> different story).

Certain types of panoramic cameras output images in cylindrical 
projection, see e.g.
http://www.funsci.com/fun3_en/panoram2/pan2_en.htm

Carl

Carl> Daniel M. German wrote:
 >> 
 >> 1 takes as input only rectilinear, equirectangular, fisheye equisolid
 >> (correct me if I am wrong, but this sounds like azimuth equal area)
 >> and cylindrical (I don't really know why cylindrical, but that is a
 >> different story).

 Carl> Certain types of panoramic cameras output images in cylindrical 
 Carl> projection, see e.g.
 Carl> http://www.funsci.com/fun3_en/panoram2/pan2_en.htm

Thanks Carl.

It is also interesting to mention that there are several types of
fisheye lenses (I don't know much about optics, but I would not be
surprised if fisheye lenses are more of a combination of different
projection than strictly one).

Some fisheyes are equidistant, and some (very, very few)
stereographic.


dmg



--
Daniel M. German                  "Sooner or later all the peoples of the world,
                                   without regard to the political system
                                   under which they live,
                                   will have to discover a way
   Martin Luther King, jr. ->      to live together in peace."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi Jim,

 >> images on the sphere surface (or whatever way in a 3D space), and  
 >> projection/stitcher engine produces the images by sort of taking  
 >> picture from the centre of that world with different projections (or  
 >> an interactive VR snap, or even a movie which could be really cool).  
 >> I don't understand why would the optimisation process ever need to  
 >> know about the projection.
 >> 
 Jim> Going by memory.
 Jim> The error reported back from the optimizer is the distance the on the 
 Jim> projection selected.

I agree, we have to check several of the statements we make here :) 

 Jim> The error used internally to find closest fit, is the distance on a 
 Jim> sphere for normal control points but for lines (horizontal, vertical, 
 Jim> and straight) control points it uses the projection selected.

You are totally right, I forgot about straight lines in my previous
posting.

But straight lines only make sense for rectilinear (I don't think
people use them for the other azimuthal --fisheye-- and it is
certainly meaningless in any other type of projection).

 Jim> It may be worth investigating if all line control points should be 
 Jim> optimized for rectilinear projection regardless of projection selected. 

 Jim> The problem: no longer able to use line control points to optimize a pan 
 Jim> taken from a the center of a circle to spherical projection.

 Jim> -- 
 Jim> Jim Watters

 Jim> jwatters @ photocreations . ca
 Jim> http://photocreations.ca


 Jim> -------------------------------------------------------------------------
 Jim> Take Surveys. Earn Cash. Influence the Future of IT
 Jim> Join SourceForge.net's Techsay panel and you'll get the chance to share your
 Jim> opinions on IT & business topics through brief surveys-and earn cash
 Jim> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
 Jim> _______________________________________________
 Jim> PanoTools-devel mailing list
 Jim> PanoTools-devel@...
 Jim> https://lists.sourceforge.net/lists/listinfo/panotools-devel

--
Daniel M. German                  "One thing I have learned in a long life:
                                   that all our science, measured against
                                   reality, is primivite and childlike
                                   --and yet it is the most precious thing
   Albert Einstein ->              we have. "
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi Daniel,

> Hi Ippei
> 
> 1. The registration maps an image to a sphere. It is in this sphere that
> optimization happens. In other words, panotools trie to find where in
> this sphere this image corresponds to.
> 
> 2. The mapping takes this sphere and projects it.
> 
> Both 1 and 2 require a projection library, but not to the same extend.
> 
> 1 takes as input only rectilinear, equirectangular, fisheye equisolid
> (correct me if I am wrong, but this sounds like azimuth equal area)
> and cylindrical (I don't really know why cylindrical, but that is a
> different story).

Well, thats a very simple cylinder projection, as produced by swing
lens cameras.

> 2 takes the sphere and projects into whatever we want. Panotools
> supports 10 (I think) projection (tlalli has 14).
> 
> 
> 1 only requires very simple projections. 
> 
> 
> This is the conundrum. Should we support more input projections? I
> would say no, but not to close the door and hardcode it.

Why not? Who knows, maybe sometime you want to reproject that panorama in
Mercator projection into something else, but you have lost the source
images? Then this will be very useful. I don't like to artificially restrict
functionality if there is no good reason to do so. Keep it flexible.

> The reason that the optimization needs to know the input projection is
> that it needs to know where an x,y point in the photo corresponds to
> the sphere.
> 
> Why thing that panotools does not do is to assume a flat field,
> instead of a sphere to stitching. That limits the use of panotools,
> and makes it difficult to stitch "murals" and similar objects when you
> know the photos were "perfectly" parallel to each other

This is something that should be changed as well during an overhaul.
Internally, the panotools projections are all 2D <-> 2D. Within that model,
the plane to plane projection could be also handled. It would just require
some additional parameters, namely the 3D position of the camera with
respect to the output plane.

So this would require an additional set of x y z parameters (probably this
is still there from the PTStereo and PTInterpolate programs :-) for each
image, and a new output projection which is just a flat plane, without a
HFOV.

This would be very useful. For example, in the past I had several requests
form people, mostly scientists, who wanted to stitch the images they have
captured with cameras onboard a unstable unmanned aerial vehicle into a large,
planar ground map.

> I think rehauling panotools is a summer project. And it will be fun,
> but it requires a lot of reengenering to get it "right". 

Maybe you can add it to the list of projects on
http://wiki.panotools.org/SoC2007_projects

ciao
  Pablo

On Thu 15-Mar-2007 at 12:44 -0700, Daniel M. German wrote:
>
> But straight lines only make sense for rectilinear (I don't think
> people use them for the other azimuthal --fisheye-- and it is
> certainly meaningless in any other type of projection).

The vertical control points are useful for levelling equirectangular 
and cylindrical panoramas.

Horizontal control points are useful for leveling the horizon in 
equirectangular and cylindrical panoramas, good for seaside scenes.

Straight-line control points are useful in any projection as they 
don't really have to be used strictly with straight lines.  The 
classic case is with overhead wires, these curve in all projections 
but you can align them nonetheless with straight-line control 
points.

-- 
Bruno

Pablo d'Angelo twisted the bytes to say:

 >> I think rehauling panotools is a summer project. And it will be fun,
 >> but it requires a lot of reengenering to get it "right". 

 Pablo> Maybe you can add it to the list of projects on
 Pablo> http://wiki.panotools.org/SoC2007_projects

I'll do.


 Pablo> ciao
  Pablo

 Pablo> -------------------------------------------------------------------------
 Pablo> Take Surveys. Earn Cash. Influence the Future of IT
 Pablo> Join SourceForge.net's Techsay panel and you'll get the chance to share your
 Pablo> opinions on IT & business topics through brief surveys-and earn cash
 Pablo> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
 Pablo> _______________________________________________
 Pablo> PanoTools-devel mailing list
 Pablo> PanoTools-devel@...
 Pablo> https://lists.sourceforge.net/lists/listinfo/panotools-devel

--
Daniel M. German                  "If debugging is the
                                   art of removing bugs,
                                   then programming must
   Anonymous ->                    be the art of inserting them."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Bruno Postle twisted the bytes to say:

 Bruno> On Thu 15-Mar-2007 at 12:44 -0700, Daniel M. German wrote:
 >> 
 >> But straight lines only make sense for rectilinear (I don't think
 >> people use them for the other azimuthal --fisheye-- and it is
 >> certainly meaningless in any other type of projection).

 Bruno> The vertical control points are useful for levelling equirectangular 
 Bruno> and cylindrical panoramas.

yes, by straight lines I mean straight that are not vertical or
horizontal. Those two are very important.

 Bruno> Horizontal control points are useful for leveling the horizon in 
 Bruno> equirectangular and cylindrical panoramas, good for seaside scenes.

 Bruno> Straight-line control points are useful in any projection as they 
 Bruno> don't really have to be used strictly with straight lines.  The 
 Bruno> classic case is with overhead wires, these curve in all projections 
 Bruno> but you can align them nonetheless with straight-line control 
 Bruno> points.

Ok, I am with you. This means that even if they are meaningless, they
are still useful :) Call it art :)



 Bruno> -- 
 Bruno> Bruno

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

--
Daniel M. German                  "Cyberspace. A consensual hallucination
                                   experienced daily by billions
   William Gibson ->               of legitimate operators in every nation"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Daniel, have a look at the 10 mm OP lens described on
http://www.naturfotograf.com/lens_fish.html
That was a lens with orthographic projection.

And CinemaScope uses anamorphic lenses:
http://en.wikipedia.org/wiki/Anamorphic
Not really a fisheye though :-)

Carl

Daniel M. German wrote:
> 
> It is also interesting to mention that there are several types of
> fisheye lenses (I don't know much about optics, but I would not be
> surprised if fisheye lenses are more of a combination of different
> projection than strictly one).
> 
> Some fisheyes are equidistant, and some (very, very few)
> stereographic.
>

Hi Carl,

 Carl> Daniel, have a look at the 10 mm OP lens described on
 Carl> http://www.naturfotograf.com/lens_fish.html
 Carl> That was a lens with orthographic projection.

Orthographic! No wonder it is a collector item! :) Also, if you have
to lift the mirror in your SLR before you mount the lens.. then it is
not exactly the most practical one :) 

I actually believe that stereographic is better than any other
azimithal (except, of course, rectilinear). I would love to see a >
180 degrees FOV Peirce Quincuncial lens, though :)

 Carl> And CinemaScope uses anamorphic lenses:
 Carl> http://en.wikipedia.org/wiki/Anamorphic
 Carl> Not really a fisheye though :-)

I was looking the other day for an anamorphic lens for my EOS. I could
not find one. They are widely used cinema, but rarely in photography
(except by people who rig their own lenses), but it is something I'd
like to see. 


 Carl> Daniel M. German wrote:
 >> 
 >> It is also interesting to mention that there are several types of
 >> fisheye lenses (I don't know much about optics, but I would not be
 >> surprised if fisheye lenses are more of a combination of different
 >> projection than strictly one).
 >> 
 >> Some fisheyes are equidistant, and some (very, very few)
 >> stereographic.
 >> 

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

--
Daniel M. German                  "A mind of moderate capacity
                                   which closely pursues one study
                                   must infallibly arrive
   Mary Shilley ->                 at great proficiency in that study."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Ippei> I wonder any cross-platform CPU-only compatible GPU-aware tool is up  
 Ippei> there. On Mac, Apple's Quartz Composer does something really  
 Ippei> interesting; please look at the screenshot (I tried it out two years  
 Ippei> ago when Tiger came out). It's based on GLSL, and runs with the best  
 Ippei> available processor unit on the machine (GPU/AltiVec/SSE).

 Ippei> Anyway, I think the best is to make sure we will have a fixed API for  
 Ippei> any small components of the library (that's what I learnt in CS1;  
 Ippei> break up tasks and give each component as generic interface as  
 Ippei> possible). That way, we can easily extend/replace/modify only the  
 Ippei> required part later whatever implementation we choose now. Moreover,  
 Ippei> I think we should prefer LGPL for newly written parts so that some  
 Ippei> developers could write closed source versions of specific part of the  
 Ippei> library for their purposes. The already written part can be modified  
 Ippei> to follow the same new APIs still remaining under GPL.

We already had a long discussion on this. The quick answer is no, we
can't change the license of derivations of panotools. A new library
could be LGPL, but I am not interested in creating LGPL software.

There is also the fact that an LGPL license will restrict us to only
use LGPL and BSD-type licensed software. The GNU Scientific Library is
GPL, and it should be used.

 Ippei> I think I'm going to apply for this one as well as the hugin  
 Ippei> renovation. If someone who is better at Qt4 or whatever GUI library  
 Ippei> wanted the hugin work, I'd be more useful working on this one.

 Ippei> Ippei

It sounds good. Panotools is quite good at what it does, but it is
written in a very monolithic way. I don't think that anybody really
knows it 100%.

In a way PTblender, PTroller, PTcrop, PTuncrop, and PTtiff2psd have
been attempts to create some modularity and encapsulation.

The first step towards this goal is to improve the testing
framework. We cannot really proceed to rehaul until we have some
reference tests.

dmg

--
Daniel M. German                  "Any sufficiently advanced
                                   technology is indistinguishable
   Arthur C. Clarke ->             from magic."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

On 2007-03-15, at 22:55, Pablo d'Angelo wrote:

>
> Hi Daniel,
>
>> Hi Ippei
>>
>> 1. The registration maps an image to a sphere. It is in this =20
>> sphere that
>> optimization happens. In other words, panotools trie to find where in
>> this sphere this image corresponds to.
>>
>> 2. The mapping takes this sphere and projects it.
>>
>> Both 1 and 2 require a projection library, but not to the same =20
>> extend.
>>
>> 1 takes as input only rectilinear, equirectangular, fisheye equisolid
>> (correct me if I am wrong, but this sounds like azimuth equal area)
>> and cylindrical (I don't really know why cylindrical, but that is a
>> different story).
>
> Well, thats a very simple cylinder projection, as produced by swing
> lens cameras.
>
>> 2 takes the sphere and projects into whatever we want. Panotools
>> supports 10 (I think) projection (tlalli has 14).
>>
>>
>> 1 only requires very simple projections.
>>
>>
>> This is the conundrum. Should we support more input projections? I
>> would say no, but not to close the door and hardcode it.
>
> Why not? Who knows, maybe sometime you want to reproject that =20
> panorama in
> Mercator projection into something else, but you have lost the source
> images? Then this will be very useful. I don't like to artificially =20=

> restrict
> functionality if there is no good reason to do so. Keep it flexible.

So, we have projections to and from the sphere because we have to =20
reverse the projection of the original lens/camera from the real =20
world to the photo, not only the projection from the sphere to the =20
resulting panorama. That means we have two types of projections: 2D =20
to sphere and sphere to 2D, and their interface are similar but =20
opposite in domains and co-domains, and some of them may be the =20
complete inverse of another. That makes sense to me now.

Is this something to do with the hugin's limitation to optimise =20
parameters while the output projection of the panorama is not one of =20
three basic ones? What I understood from above is that the =20
optimisation and output projection are independent of each other.

>> The reason that the optimization needs to know the input =20
>> projection is
>> that it needs to know where an x,y point in the photo corresponds to
>> the sphere.
>>
>> Why thing that panotools does not do is to assume a flat field,
>> instead of a sphere to stitching. That limits the use of panotools,
>> and makes it difficult to stitch "murals" and similar objects when =20=

>> you
>> know the photos were "perfectly" parallel to each other
>
> This is something that should be changed as well during an overhaul.
> Internally, the panotools projections are all 2D <-> 2D. Within =20
> that model,
> the plane to plane projection could be also handled. It would just =20
> require
> some additional parameters, namely the 3D position of the camera with
> respect to the output plane.
>
> So this would require an additional set of x y z parameters =20
> (probably this
> is still there from the PTStereo and PTInterpolate programs :-) for =20=

> each
> image, and a new output projection which is just a flat plane, =20
> without a
> HFOV.
>
> This would be very useful. For example, in the past I had several =20
> requests
> form people, mostly scientists, who wanted to stitch the images =20
> they have
> captured with cameras onboard a unstable unmanned aerial vehicle =20
> into a large,
> planar ground map.

So because of this spherical nature of the world, it is surely not =20
trivial to stitch photos that cannot be assumed to be taken from one =20
point in the 3D world... but do you mean we'll have multiple spheres =20
and need to optimise their relative positions to an intermediate =20
output plane, from which we'll get another sphere for the usual =20
output projection??? That certainly sounds really really powerful... =20
but sounds like so big the difference is that this should happen =20
separately from the interface reorganisation.

>> I think rehauling panotools is a summer project. And it will be fun,
>> but it requires a lot of reengenering to get it "right".
>
> Maybe you can add it to the list of projects on
> http://wiki.panotools.org/SoC2007_projects

If that is to reorganise the panotools into:

1. Registration optimization
2. Remapping of sphere to output projection
3. Projections library
4. Parsing of input/output

then that would be my second choice of the project. That would be =20
nice if you could add it with a brief description, but I'll be =20
writing my version of the detailed project description anyway.

(Actually it interests me more then the GUI, but I feel the GUI =20
should have a higher priority in the todo list from the user point of =20=

view. I would so loved to do both, but a summer would be too short...)

Ippei

--
  ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3  (UKAI Ippei) =
->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/

Hi Ippei,

 Ippei> On 2007-03-15, at 22:55, Pablo d'Angelo wrote:


 Ippei> So, we have projections to and from the sphere because we have to  
 Ippei> reverse the projection of the original lens/camera from the real  
 Ippei> world to the photo, not only the projection from the sphere to the  
 Ippei> resulting panorama. That means we have two types of projections: 2D  
 Ippei> to sphere and sphere to 2D, and their interface are similar but  
 Ippei> opposite in domains and co-domains, and some of them may be the  
 Ippei> complete inverse of another. That makes sense to me now.

Exactly. 

But panotools is very smart on this: it does not really create a
sphere. Instead it creates a "stack of operations": map from lens ->
equirectangular (the "raw" sphere, because a normalized x, y in the
equirectangular corresponds to a yaw, tilt in the sphere ) ->
projection.

In other words, it creates a pipeline of operations that needs to be
computed.

The process to create the image is:

for every pixel in the output image:

  * Using the computation stack determine the pixels in the source
  image that it needs (it usually requires a neiborhood, in order to
  apply the correct appropriate interpolation --this is why sync1024
  is significantly slower than bilinear).

I like the computation stack model. It is powerful. But it is also
very difficult to improve and maintain.

I am not suggesting it to be rehauled. The rehauling would be in
making sure it has a cleaner interface between projections and
remapping.

To give you an idea of how clutter things are. Addinga projection
involves modifing 6 or 7 files.


 Ippei> Is this something to do with the hugin's limitation to optimise  
 Ippei> parameters while the output projection of the panorama is not one of  
 Ippei> three basic ones? What I understood from above is that the  
 Ippei> optimisation and output projection are independent of each other.

No, it is just that when we added new projections we did not bother to
add them as input projections, only as oputput ones.


--
Daniel M. German                  "Computer Science is no more
                                   about computers than astronomy
   Edsger Dijkstra  ->             is about telescopes"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

On 2007-03-16, at 02:10, Daniel M. German wrote:
>  Ippei> Anyway, I think the best is to make sure we will have a =20
> fixed API for
>  Ippei> any small components of the library (that's what I learnt =20
> in CS1;
>  Ippei> break up tasks and give each component as generic interface as
>  Ippei> possible). That way, we can easily extend/replace/modify =20
> only the
>  Ippei> required part later whatever implementation we choose now. =20
> Moreover,
>  Ippei> I think we should prefer LGPL for newly written parts so =20
> that some
>  Ippei> developers could write closed source versions of specific =20
> part of the
>  Ippei> library for their purposes. The already written part can be =20=

> modified
>  Ippei> to follow the same new APIs still remaining under GPL.
>
> We already had a long discussion on this. The quick answer is no, we
> can't change the license of derivations of panotools. A new library
> could be LGPL, but I am not interested in creating LGPL software.
>
> There is also the fact that an LGPL license will restrict us to only
> use LGPL and BSD-type licensed software. The GNU Scientific Library is
> GPL, and it should be used.

I have roughly followed the discussion about the license. I'm only =20
saying that the newly written 'interface' and 'I/O file format =20
parsers' could stay out of GPL, so that it can have non GPL =20
implementation out of scope of our projects. It's not the derivatives.

The current implementation stays GPL because there are no way back. I =20=

know that. I have used a library which is in GPL only because it's =20
derived from a GPL'ed application; inherently I had no choice other =20
than releasing my software with GPL not BSD.

I think nothing can stop renewing the current implementations to use =20
LGPL'ed interface and file parsers, and at least I feel it's =20
desirable to allow commercial implementations that reads the same =20
file formats.

>  Ippei> I think I'm going to apply for this one as well as the hugin
>  Ippei> renovation. If someone who is better at Qt4 or whatever GUI =20=

> library
>  Ippei> wanted the hugin work, I'd be more useful working on this one.
>
>  Ippei> Ippei
>
> It sounds good. Panotools is quite good at what it does, but it is
> written in a very monolithic way. I don't think that anybody really
> knows it 100%.
>
> In a way PTblender, PTroller, PTcrop, PTuncrop, and PTtiff2psd have
> been attempts to create some modularity and encapsulation.
>
> The first step towards this goal is to improve the testing
> framework. We cannot really proceed to rehaul until we have some
> reference tests.


--
  ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3  (UKAI Ippei) =
->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/

On 2007-03-16, at 03:11, Daniel M. German wrote:

>
> Hi Ippei,
>
>  Ippei> On 2007-03-15, at 22:55, Pablo d'Angelo wrote:
>
>
>  Ippei> So, we have projections to and from the sphere because we =20
> have to
>  Ippei> reverse the projection of the original lens/camera from the =20=

> real
>  Ippei> world to the photo, not only the projection from the sphere =20=

> to the
>  Ippei> resulting panorama. That means we have two types of =20
> projections: 2D
>  Ippei> to sphere and sphere to 2D, and their interface are similar =20=

> but
>  Ippei> opposite in domains and co-domains, and some of them may be =20=

> the
>  Ippei> complete inverse of another. That makes sense to me now.
>
> Exactly.
>
> But panotools is very smart on this: it does not really create a
> sphere. Instead it creates a "stack of operations": map from lens ->
> equirectangular (the "raw" sphere, because a normalized x, y in the
> equirectangular corresponds to a yaw, tilt in the sphere ) ->
> projection.
>
> In other words, it creates a pipeline of operations that needs to be
> computed.
>
> The process to create the image is:
>
> for every pixel in the output image:
>
>   * Using the computation stack determine the pixels in the source
>   image that it needs (it usually requires a neiborhood, in order to
>   apply the correct appropriate interpolation --this is why sync1024
>   is significantly slower than bilinear).
>
> I like the computation stack model. It is powerful. But it is also
> very difficult to improve and maintain.

So it computes the composition of all the operations on the images =20
and apply it over the bitmap matrix. That's clever way to handle non-=20
discrete intermediate coordinates. Sounds like we need something like =20=

OpenGL Shading Language that can be manipulated on runtime and =20
executed very fast according to the output resolution. I have no idea =20=

how it could be done in C to be honest though. I'm too used to OOP.

> I am not suggesting it to be rehauled. The rehauling would be in
> making sure it has a cleaner interface between projections and
> remapping.
>
> To give you an idea of how clutter things are. Addinga projection
> involves modifing 6 or 7 files.

Right... so the situation is worse than I thought.

>  Ippei> Is this something to do with the hugin's limitation to =20
> optimise
>  Ippei> parameters while the output projection of the panorama is =20
> not one of
>  Ippei> three basic ones? What I understood from above is that the
>  Ippei> optimisation and output projection are independent of each =20
> other.
>
> No, it is just that when we added new projections we did not bother to
> add them as input projections, only as oputput ones.

Okay, I think I'm still lost here. Why do we need the input versions =20
of the output projections for optimisation if the optimisation is =20
independent from the output projection process? I thought input =20
projections are chosen in the Camera and Lens tab, and they are =20
certainly independent of the output projection.

Ippei

--
  ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3  (UKAI Ippei) =
->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai@...   Skype: ippei_ukai
   Homepage:  http://homepage.mac.com/ippei_ukai/

Hi Daniel,

Daniel M. German wrote:
> Hi Carl,
> 
>  Carl> Daniel, have a look at the 10 mm OP lens described on
>  Carl> http://www.naturfotograf.com/lens_fish.html
>  Carl> That was a lens with orthographic projection.
> 
> Orthographic! No wonder it is a collector item! :) Also, if you have
> to lift the mirror in your SLR before you mount the lens.. then it is
> not exactly the most practical one :) 

Why in the world do you need a mirror? To check if your feet are still 
in the picture? ;-)

I mostly use a "viewfinder camera without a viewfinder" together with a 
12 mm rectilinear lens. The lens comes with its own external viewfinder 
but I don't carry that around because it's so easy to tell what will be 
in the picture: in portrait orientation it covers 90 deg. horizontally, 
and 110 deg. vertically.

> I actually believe that stereographic is better than any other
> azimithal (except, of course, rectilinear). I would love to see a >
> 180 degrees FOV Peirce Quincuncial lens, though :)

Maybe some day we have in-camera capabilities to imitate such a lens. 
I'd go digital for something like that!

>  Carl> And CinemaScope uses anamorphic lenses:
>  Carl> http://en.wikipedia.org/wiki/Anamorphic
>  Carl> Not really a fisheye though :-)
> 
> I was looking the other day for an anamorphic lens for my EOS. I could
> not find one. They are widely used cinema, but rarely in photography
> (except by people who rig their own lenses), but it is something I'd
> like to see. 

We should ask someone at ARRI.
http://www.arri.com/sub/de/rental/mucrental/cam/index.htm
There must be a way to make them keep their price list in the locker... :-)

Carl

Ippei UKAI schrieb:
> On 2007-03-16, at 03:11, Daniel M. German wrote:
> 
>> Hi Ippei,
>>
>> I like the computation stack model. It is powerful. But it is also
>> very difficult to improve and maintain.
> 
> So it computes the composition of all the operations on the images  
> and apply it over the bitmap matrix. That's clever way to handle non- 
> discrete intermediate coordinates.

And this is one of the big strengths of panotools. We need to keep that.
The transform stack can be treated as a black box, and can represent a
all different kinds of 2D<->2D transformations. Currently panotools builds
the stack so that everything goes through a spherical model internally, but
this is not a fundamental requirement!

Interesting features are possible if we allow other transformations as well.
Just think how complicated this conceptually very elegant procedure is:
http://wiki.panotools.org/Fixing_nadir_parallax_errors

I believe the maintainance difficulties are more due to technical reasons
and not due to the flexibility of the transform stack approach.

> Sounds like we need something like
> OpenGL Shading Language that can be manipulated on runtime and  
> executed very fast according to the output resolution. I have no idea  
> how it could be done in C to be honest though. I'm too used to OOP.

Using hardware acceleration is an attractive idea, however generality should
not be sacrified. I think it might be useful to build dedictated
transformations for the most common use cases.

>>  Ippei> What I understood from above is that the
>>  Ippei> optimisation and output projection are independent of each  
>> other.
>>
>> No, it is just that when we added new projections we did not bother to
>> add them as input projections, only as oputput ones.
> 
> Okay, I think I'm still lost here. Why do we need the input versions  
> of the output projections for optimisation if the optimisation is  
> independent from the output projection process?

Actually an output projection has to be specified for the optimisation,
however, currently only rectilinear, cylindrical and spherical are
available, with spherical being the logical solution for 360x180 deg panos.

But lets step back. I will try to summarize how the stuff related to
projections works in panotools.

1. remapping is quite simple:
(pano image coordinate P_j)  -> [transform_stack_i(x_i)] -> (image i
coordinates I_ij)

transform_stack_i(x_i) is the transformation function parametrized with
different parameters x_i (yaw, roll, pitch, hfov) for each input image i.
You can use different projections for each input image, thus different
transform stacks are required.

The pixel found in the image is then placed in the panorama image.
Actually, in the literature this is usually called inverse mapping, since
the forward mapping, which transforms the input image coordinates I into the
panorama coordinates P has some drawbacks when actual images should be
remapped: http://blogs.mathworks.com/steve/?p=53


2. In order to calculate the function above, the parameters x_i need to be
determined. This is done using the optimizer. Here stuff gets tricky.
There are two ways to attack the problem, and the second one I describe is
used in panotools, so feel free to skip to II) if you head aches while
reading I):

I) using the same transformation as for the remapping:

Assume that we roughly know the coordinate P_j in the panorama image
and have measured the associated image coordinates I_ij (corresponding
points in the images).
Then we can transform P_j into each image, resulting in image coordinates
I*_ij. In order to make the images match, we require
I_ij = I*_ij
With this equation, we can then estimate the coordinate of P_j, and the
transformation parameters x_i.
The advantage of this method is that it allows "multi image" control points,
and the main drawbacks are that the coordinates P_j also need to be
determined, making the problem harder to solve. Additionally approximate
initial values for P_j need to be available (but could be computed using
other methods).
The idea behind this method is also used in Bundle Adjustment, as used
extensively in Photogrammetry for 3D reconstruction and map building.

II) using the inverse transformation.

Contrary to 3D reconstruction from images, where the transformation is
actually a projection from 3D->2D, and thus cannot be uniquely invertable,
we have the advantage that our transformation is invertible

Thus we can use another approach based on the inverse transformation:
Use the control point I_1j and I_2j to calculate P_1j and
P_2j. To make the images match, we require
P_1j = P_2j
The parameters x_j can then be recovered by minimising the distance
between P_1j - P_2j, which is the distance of control points in the
final panorama.

As implemented in panotools, this distance is always measured on the
sphere, except for the special horizontal, vertical and line
control points.

The big advantege is that we do not need to estimate values for P_j, and
thus have fewer parameters to estimate, and fewer control points are
required. There are also other differences with respect to stability etc.

This is why the inverse transformations are required for the optimisation.
I hope this was not to confusing.

ciao
  Pablo

Hi Carl,

 Carl> Why in the world do you need a mirror? To check if your feet are still 
 Carl> in the picture? ;-)

I have been taking photos with a 10x ND filter (and sometimes also a
polarizer (2x) and I find my old range finder far more useful!

The other day and old-timer saw me taking long exposures and we
started talking. He said that long time ago, in a visit of the Queen
to the city he took some very good photos, ... until he came back
home. He then realized he never removed the lens cap.

Sometimes a mirror is useful :)

 Carl> I mostly use a "viewfinder camera without a viewfinder" together with a 
 Carl> 12 mm rectilinear lens. The lens comes with its own external viewfinder 

Do you mean the Voigtlander 12mm?  It is, from what I know, the widest
rectilinear lens in the market.

 >> I actually believe that stereographic is better than any other
 >> azimithal (except, of course, rectilinear). I would love to see a >
 >> 180 degrees FOV Peirce Quincuncial lens, though :)

 Carl> Maybe some day we have in-camera capabilities to imitate such a lens. 
 Carl> I'd go digital for something like that!

We are finishing a paper in which I propose such a system. Here is the
"teaser" (as Pablo). I'll post the submitted version of the paper on
Monday.

Original image:

http://turingmachine.org/~dmg/temp/libraryDefishIntoLambertEqualAreaOriginal.jpg

Automatically remapped with no control points:

http://turingmachine.org/~dmg/temp/libraryDefishedLambertEqArea.jpg

The remapping is happening in the computer, based on data from 3
accelerometers attached to the camera, relayed via bluetooth. But we
argue that (for some projections) the CPUs the cameras can provide a
preview in their LCD in real time.

 >> I was looking the other day for an anamorphic lens for my EOS. I could
 >> not find one. They are widely used cinema, but rarely in photography
 >> (except by people who rig their own lenses), but it is something I'd
 >> like to see. 

 Carl> We should ask someone at ARRI.
 Carl> http://www.arri.com/sub/de/rental/mucrental/cam/index.htm
 Carl> There must be a way to make them keep their price list in the locker... :-)

Ouch! The cost of the lens case is more expensive than to the cost of
a Nikkor 10.5mm!

15k euros! I could by an entire EOS arsenal for that amount :) life
isn't fair :)


 Carl> Carl

--
Daniel M. German                  "When asked whether or not we are
                                   Marxists, our position is the same as
                                   that of a physicist or a biologist who
                                   is asked if he is a `Newtonian', or if
   Che Guevara ->                  he is a `Pasteurian'"
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Pablo> I believe the maintainance difficulties are more due to technical reasons
 Pablo> and not due to the flexibility of the transform stack approach.

I totally agree. the conceptual model is great. It is just difficult
to understand how it works. Perhaps one of the tasks is to document it
well. I think its main problem is that it is rather obscure how the
stack is built and used.

dmg


--
Daniel M. German                  "Work. Finish. Publish. "
                                   Michael Faraday
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi!

Daniel M. German wrote:
> [...] He then realized he never removed the lens cap.
> Sometimes a mirror is useful :)

indeed... :-)

>  Carl> I mostly use a "viewfinder camera without a viewfinder" together=
 with a=20
>  Carl> 12 mm rectilinear lens. The lens comes with its own external vie=
wfinder=20
>=20
> Do you mean the Voigtlander 12mm?  It is, from what I know, the widest
> rectilinear lens in the market.

Yes, it's the Voigtl=E4nder. I also have the 15 mm for a little bit more =

resolution. Both are really fun to work with and I especially like the=20
small setup. The body is a little bit simple though: I already had to=20
fix the pressure plate and I think about something like the  =09
Zeiss Ikon SW Camera body as a replacement.

But I just discovered that:
http://www.arri.com/prod/cam/ultra_prime_r8/ultra_prime_r8.htm
Is that true? A 8mm rectilinear lens?

There is also a ZEISS 10 mm mentioned.

>  Carl> Maybe some day we have in-camera capabilities to imitate such a =
lens.=20
>  Carl> I'd go digital for something like that!
>=20
> We are finishing a paper in which I propose such a system. Here is the
> "teaser" (as Pablo). I'll post the submitted version of the paper on
> Monday.
>=20
> Original image:
> http://turingmachine.org/~dmg/temp/libraryDefishIntoLambertEqualAreaOri=
ginal.jpg
>=20
> Automatically remapped with no control points:
> http://turingmachine.org/~dmg/temp/libraryDefishedLambertEqArea.jpg
>=20
> The remapping is happening in the computer, based on data from 3
> accelerometers attached to the camera, relayed via bluetooth. But we
> argue that (for some projections) the CPUs the cameras can provide a
> preview in their LCD in real time.

Very fascinating. I always thought about using those camera attached=20
y/p/r sensors to just add their values to the EXIF data of the image.

Another benefit of such sensors that feed the camera (or an attached=20
pda) could be a warning (for me and Luca) if a shot is still missing for =

a full sphere. That would be great for shots without a tripod!

>  >> I was looking the other day for an anamorphic lens for my EOS. I co=
uld
>  >> not find one. They are widely used cinema, but rarely in photograph=
y
>  >> (except by people who rig their own lenses), but it is something I'=
d
>  >> like to see.=20
>=20
>  Carl> We should ask someone at ARRI.
>  Carl> http://www.arri.com/sub/de/rental/mucrental/cam/index.htm
>  Carl> There must be a way to make them keep their price list in the lo=
cker... :-)
>=20
> Ouch! The cost of the lens case is more expensive than to the cost of
> a Nikkor 10.5mm!
> 15k euros! I could by an entire EOS arsenal for that amount :) life
> isn't fair :)

Their rental price list says 125,- EUR per day, that's a start :-)

Carl

Carl von Einem twisted the bytes to say:

 Carl> Hi!
 Carl> Daniel M. German wrote:
 >> [...] He then realized he never removed the lens cap.
 >> Sometimes a mirror is useful :)

 Carl> indeed... :-)

 Carl> I mostly use a "viewfinder camera without a viewfinder" together with a 
 Carl> 12 mm rectilinear lens. The lens comes with its own external viewfinder 
 >> 
 >> Do you mean the Voigtlander 12mm?  It is, from what I know, the widest
 >> rectilinear lens in the market.

 Carl> Yes, it's the Voigtländer. I also have the 15 mm for a little bit more 
 Carl> resolution. Both are really fun to work with and I especially like the 
 Carl> small setup. The body is a little bit simple though: I already had to 
 Carl> fix the pressure plate and I think about something like the  	
 Carl> Zeiss Ikon SW Camera body as a replacement.

According to the specs it renders an image in a 25 strip of film
(http://www.arri.com/prod/cam/ultra_prime_r8/tech_spec.htm). So it is a
"cropped" lens, similar to the Canon EF-S 10. In a 35mm camera it
would be more like a 12mm.

http://www.arri.com/prod/cam/ultra_prime_r8/tech_spec.htm

 Carl> Very fascinating. I always thought about using those camera attached 
 Carl> y/p/r sensors to just add their values to the EXIF data of the image.

The problem with yaw is that it requires a magnetic compass, not an
inclinometer. And good inclinometers are expensive. Cheap
accelerometers can measure roll and pitch but with low
resolution. good enough for remapping, but not for automatic
registration.

 Carl> Another benefit of such sensors that feed the camera (or an attached 
 Carl> pda) could be a warning (for me and Luca) if a shot is still missing for 
 Carl> a full sphere. That would be great for shots without a tripod!

This is a good point! :)

 Carl> Their rental price list says 125,- EUR per day, that's a start :-)

If I was somewhere around... :)



--
Daniel M. German                  "Eat food. Not too much. Mostly Plants"
                                   M. Polland from NY Times
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Daniel M. German wrote:
> 
> According to the specs it renders an image in a 25 strip of film
> (http://www.arri.com/prod/cam/ultra_prime_r8/tech_spec.htm). So it is a
> "cropped" lens, similar to the Canon EF-S 10. In a 35mm camera it
> would be more like a 12mm.

Right, that looks more like the fov of my 12 mm. Only that  ARRI/Zeiss 
lens is 2 kg! My 12 mm is 1.23 kg (including mounted body and L-bracket)

>  Carl> Very fascinating. I always thought about using those camera attached 
>  Carl> y/p/r sensors to just add their values to the EXIF data of the image.
> 
> The problem with yaw is that it requires a magnetic compass, not an
> inclinometer. And good inclinometers are expensive. Cheap
> accelerometers can measure roll and pitch but with low
> resolution. good enough for remapping, but not for automatic
> registration.

So how much resolution does it need?

>  Carl> Another benefit of such sensors that feed the camera (or an attached 
>  Carl> pda) could be a warning (for me and Luca) if a shot is still missing for 
>  Carl> a full sphere. That would be great for shots without a tripod!
> 
> This is a good point! :)

Oh, and we need a sensor to detect the lens cap! ;-)

>  Carl> Their rental price list says 125,- EUR per day, that's a start :-)
> 
> If I was somewhere around... :)

It's right in your direction if you want to come to the Panotools 
meeting this year in Switzerland.

And how about http://www.arrican.com/
I bet they are very interested in what you do with this kind of lenses!

Carl