From: Pablo d. <pab...@we...> - 2007-02-17 19:20:09
|
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 |
From: Pablo d. <pab...@we...> - 2007-02-18 00:30:07
|
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 >Pan...@li... >https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: yuval l. <yuv...@ya...> - 2007-02-18 04:44:07
|
Hi Pablo, excellent idea! I read through the FAQ and Wiki of the SoC, find my thoughts below. --- Pablo dAngelo <pab...@we...> 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 |
From: Pablo d'A. <pab...@we...> - 2007-02-18 20:37:04
|
Hi Yuval, > Hi Pablo, > --- Pablo dAngelo <pab...@we...> 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 |
From: Daniel M. G. <dm...@uv...> - 2007-02-22 00:16:58
|
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 . |
From: Florent B. <fl...@sa...> - 2007-02-20 01:06:34
|
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 |
From: Pablo d'A. <pab...@we...> - 2007-02-20 20:50:33
|
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 |
From: Daniel M. G. <dm...@uv...> - 2007-02-22 00:17:01
|
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 . |
From: Ippei U. <ipp...@ma...> - 2007-03-12 22:43:39
|
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 > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel -- ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3 (UKAI Ippei) = ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ |
From: Daniel M. G. <dm...@uv...> - 2007-03-13 03:30:39
|
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 >> Pan...@li... >> https://lists.sourceforge.net/lists/listinfo/panotools-devel Ippei> -- ->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... 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> Pan...@li... 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 . |
From: Ippei U. <ipp...@ma...> - 2007-03-13 19:54:24
|
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 >>> Pan...@li... >>> https://lists.sourceforge.net/lists/listinfo/panotools-devel > > > > Ippei> -- > ->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> > MSN & AIM: ipp...@ma... 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> Pan...@li... > 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 hug...@go... > To unsubscribe from this group, send email to hugin-ptx- > uns...@go... > For more options, visit this group at http://groups.google.com/ > group/hugin-ptx > -~----------~----~----~----~------~----~------~--~--- > -- ->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ |
From: Daniel M. G. <dm...@uv...> - 2007-03-13 20:37:35
|
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 >>>> Pan...@li... >>>> https://lists.sourceforge.net/lists/listinfo/panotools-devel >> >> >> Ippei> -- -> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> >> MSN & AIM: ipp...@ma... 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> Pan...@li... 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: ipp...@ma... 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 hug...@go... Ippei> To unsubscribe from this group, send email to hug...@go... 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 . |
From: Pablo d'A. <pab...@we...> - 2007-03-13 23:17:42
|
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 |
From: Ippei U. <ipp...@ma...> - 2007-03-15 17:10:55
Attachments:
QC_screen.jpg
|
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 |
From: Daniel M. G. <dm...@uv...> - 2007-03-15 19:32:40
|
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 hug...@go... Ippei> To unsubscribe from this group, send email to hug...@go... Ippei> For more options, visit this group at http://groups.google.com/group/hugin-ptx Ippei> -~----------~----~----~----~------~----~------~--~--- Ippei> -- ->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... 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 . |
From: Carl v. E. <ei...@gm...> - 2007-03-15 20:21:50
|
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 |
From: Daniel M. G. <dm...@uv...> - 2007-03-15 22:45:49
|
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 . |
From: Carl v. E. <ei...@gm...> - 2007-03-15 23:23:23
|
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. > |
From: Daniel M. G. <dm...@uv...> - 2007-03-15 23:43:02
|
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 hug...@go... Carl> To unsubscribe from this group, send email to hug...@go... 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 . |
From: Carl v. E. <ei...@gm...> - 2007-03-16 12:49:10
|
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 |
From: Daniel M. G. <dm...@uv...> - 2007-03-17 21:28:08
|
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 . |
From: Carl v. E. <ei...@gm...> - 2007-03-19 15:29:31
|
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 |
From: Daniel M. G. <dm...@uv...> - 2007-03-20 09:09:23
|
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 . |
From: Carl v. E. <ei...@gm...> - 2007-03-20 11:29:05
|
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 |
From: Ippei U. <ipp...@ma...> - 2007-03-16 03:35:00
|
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: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ |