Google summer of code
Pablo dAngelo
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
Pablo dAngelo
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:
>-------------------------------------------------------------------------
>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
>PanoToo...@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
>
Ippei UKAI
I'm actually interested in this one. It looks very similar to my
brainstorm on hugin2.
However, I considered Control Point editor as one of the assets to
keep to be used as a component of the completely new GUI layout.
Anyway, I'm definitely interested in.
Ippei
--
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei...@mac.com Skype: ippei_ukai
Homepage: http://homepage.mac.com/ippei_ukai/
Pablo d'Angelo
> Hi Pablo,
> --- Pablo dAngelo <pablo....@web.de> 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
Daniel M. German
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 .
Daniel M. German
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."
Hal V. Engel
> 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 looked over last years list of projects that were part of SoC and many of
them were smaller and less well known than Hugin. In fact many of them I had
never heard of and I had a hard time finding even web links to some of them.
So I think you have a pretty good chance of getting a slot this year.
prokoudine
> From what I read, we need a fallback mentor and some organizer that
> stays in
> contact with google and mediates if something goes wrong.
I can do communication work if noone else volunteers.
Alexandre
Yuv
wrote:
> I can do communication work if noone else volunteers.
that's very appreciated, Alexandre.
please enter your information at <http://wiki.panotools.org/
Google_SoC_2007>
for a start we need a short bio for the application as mentoring
organization.
I am currently coordinating the drafting of the application as
mentoring organization. they accept applications between March 5 and
12. My goal is to have an application text ready to present to them /
apply on March 5.
Feel free to add to the draft <http://wiki.panotools.org/
SoC2007_application>
Yuv
Ippei UKAI
What do you exactly mean by 'batch processor' in hugin?
Is there any specific need or feature request for some kind of batch
process over the images, or it means hugin should have some kind of
scripting UI like many applications on Mac do for AppleScript?
Ippei
On 2007-02-18, at 00:31, Pablo dAngelo wrote:
--
Daniel M. German
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
>> ----------------------------------------------------------------------
>> ---
>> 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
>> PanoToo...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/panotools-devel
Ippei> --
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei...@mac.com 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> PanoToo...@lists.sourceforge.net
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."
Ippei UKAI
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
Daniel M. German
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>
--
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.)"
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.
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:)
Daniel M. German
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."
Pablo d'Angelo
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
Ippei UKAI
>> 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
Jim Watters
> 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.
>
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
Giuseppe Rota
I've been coding a "clone" of the hugin interface. It may turn useful for the SoC. I didn't have time to clean the code, (nor to finish the whole thing), so I apologize in advance for the quality of the code.
-------------------------------------------------------------------------
Daniel M. German
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> --
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei...@mac.com 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"
Carl von Einem
>
> 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
Daniel M. German
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."
Daniel M. German
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> PanoToo...@lists.sourceforge.net
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. "
Pablo d'Angelo
> 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
Bruno Postle
>
> 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
Daniel M. German
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> PanoToo...@lists.sourceforge.net
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."
Daniel M. German
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>
--
Daniel M. German "Cyberspace. A consensual hallucination
experienced daily by billions
William Gibson -> of legitimate operators in every nation"
Carl von Einem
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 :-)
Daniel M. German
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."
Ippei UKAI
So, we have projections to and from the sphere because we have to
reverse the projection of the original lens/camera from the real
world to the photo, not only the projection from the sphere to the
resulting panorama. That means we have two types of projections: 2D
to sphere and sphere to 2D, and their interface are similar but
opposite in domains and co-domains, and some of them may be the
complete inverse of another. That makes sense to me now.
Is this something to do with the hugin's limitation to optimise
parameters while the output projection of the panorama is not one of
three basic ones? What I understood from above is that the
optimisation and output projection are independent of each other.
So because of this spherical nature of the world, it is surely not
trivial to stitch photos that cannot be assumed to be taken from one
point in the 3D world... but do you mean we'll have multiple spheres
and need to optimise their relative positions to an intermediate
output plane, from which we'll get another sphere for the usual
output projection??? That certainly sounds really really powerful...
but sounds like so big the difference is that this should happen
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
nice if you could add it with a brief description, but I'll be
writing my version of the detailed project description anyway.
(Actually it interests me more then the GUI, but I feel the GUI
should have a higher priority in the todo list from the user point of
view. I would so loved to do both, but a summer would be too short...)
Daniel M. German
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"
Ippei UKAI
> 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.
I have roughly followed the discussion about the license. I'm only
saying that the newly written 'interface' and 'I/O file format
parsers' could stay out of GPL, so that it can have non GPL
implementation out of scope of our projects. It's not the derivatives.
The current implementation stays GPL because there are no way back. I
know that. I have used a library which is in GPL only because it's
derived from a GPL'ed application; inherently I had no choice other
than releasing my software with GPL not BSD.
I think nothing can stop renewing the current implementations to use
LGPL'ed interface and file parsers, and at least I feel it's
desirable to allow commercial implementations that reads the same
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
> 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.
Ippei UKAI
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. 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.
> 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
> 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.
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? I thought input
projections are chosen in the Camera and Lens tab, and they are
certainly independent of the output projection.
Pablo d'Angelo
> On 2007-03-16, at 03:11, Daniel M. German wrote:
>
>> Hi Ippei,
>>
>> 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
Daniel M. German
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
Rich
> Hi guys,
> I've been coding a "clone" of the hugin interface. It may turn useful
> for the SoC. I didn't have time to clean the code, (nor to finish the
> whole thing), so I apologize in advance for the quality of the code.
i haven't seen a response to this - maybe the code could be evaluated
and some decision made regarding it ? maybe it is worth mentioning in
the wiki ?
...
--
Rich