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
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> 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
>> 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
>> Ippei UKAI twisted the bytes to say:
Ippei> I've just remembered someone has said something like we
Ippei> do not have any good representation of PanoTools data other
Ippei> PTstitcher/PToptimiser script even for passing data between
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
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
Ippei> good project for the SoC students.
Ippei> 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.
>>>> I would be happy to mentor one student for one of the following
>>>> 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
>>>> 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.
>>>> 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
>>>> PanoTools-devel mailing list
-> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
>> MSN & AIM: ippei_ukai@... Skype: ippei_ukai
>> Homepage: http://homepage.mac.com/ippei_ukai/
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> PanoTools-devel mailing list
>> Daniel M. German "If your photographs are not good
>> Robert Capa -> you are not close enough."
>> dmg (at) uvic (dot) ca
>> replace (at) with @ and (dot) with .
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei_ukai@... Skype: ippei_ukai
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
Daniel M. German "You can't trust code that
you did not totally create
(Especially code from companies
Ken Thompson -> that employ people like me.)"
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .