From: Joseph M. <mu...@le...> - 2004-05-20 12:21:34
|
Dear VXL community, I have been thinking that it would be useful to have a third category of libraries which are jointly supported but not with the same goals as the core libraries, which are foundational. For the moment let's call them "public" libraries. These libraries would implement broadly useful and universally accepted applications such as the Canny edge detector and the Kanade-Lucas-Tommasi feature tracker. Such base applications form the building blocks for larger applications such as video object recognition being developed in the contrib and private VXL libraries. Some example topics for the public libraries: Computational geometry Image processing Image segmentation Point detection Edge detection Region detection Photogrammetry Camera calibration Projective reconstruction Factorization .. I think you get the idea. These are of shared interest across most vxl communities and by putting them in a public space, we can collaborate on bug-fixing and improving the algorithms. Useful for teaching as well.. Joe o----o----o----o----o----o----o Professor of Engineering (Research) Barus and Holley Bldg., Room 351 Brown University Providence, RI 401-863-2655 |
From: Amitha P. <pe...@cs...> - 2004-05-20 19:19:33
|
It's not clear to me why such "public libraries" can't be in vxl/core. In what way would libraries in this public space be different from a library that goes in core? Currently, the criterion for core is (a) well-documented, (b) relatively stable [maybe], and (c) used by more that one group. Given that both the public and core libraries are jointly maintained, which one of the above would the public libraries not satisfy? Perhaps your desire is to separate actively developed libraries (changing APIs and functionality) and more stable libraries that aren't yet documented? When would such a public library be documented and moved into core? I think that edge detection, etc, are also fundamental. I think that they should be well-documented so more of us can use them. I'm somewhat concerned that the public libraries will become a dumping ground, and then the core will stagnate (as it is beginning to do now). I would much rather see a little more documentation effort put into these public libraries, and then have them moved into the core. (rrel is a good example of this. It's been stable for a long time. It's used by at least two groups. But I nor anyone at RPI has taken the time to write a small overview documentation. As soon as that's done, I would nominate it to be moved to the core.) Amitha. |
From: Gehua Y. <ya...@rp...> - 2004-05-20 21:29:41
|
I think this is more like a philosophy question: should "public" and core libraries be separated? My answer is YES. The reasons are: 1. "Public" can use and depend on core, but not the other way around. 2. Though algorithms in public are "fundamental" in terms of applications in computer vision area, but the core is more basic and primitive. I agree on most of the criterion Amitha mentioned, i.e., well-documented, relatively stable, and used by more than one group. But that doesn't mean public libraries should go into core, since we can still apply the same requirements to public library. To me, the major advantage of introducing public library is clear and easy to understand hierarchies. Gehua ----- Original Message ----- From: "Amitha Perera" <pe...@cs...> To: "Joseph Mundy" <mu...@le...> Cc: "Vxl" <vxl...@li...> Sent: Thursday, May 20, 2004 3:19 PM Subject: Re: [Vxl-maintainers] Not core, Not contrib > It's not clear to me why such "public libraries" can't be in vxl/core. > > In what way would libraries in this public space be different from a > library that goes in core? Currently, the criterion for core is (a) > well-documented, (b) relatively stable [maybe], and (c) used by more > that one group. Given that both the public and core libraries are > jointly maintained, which one of the above would the public libraries > not satisfy? > |
From: Amitha P. <pe...@cs...> - 2004-05-20 21:44:04
|
On Thu 20 May 2004, Gehua Yang wrote: > My answer is YES. The reasons are: > 1. "Public" can use and depend on core, but not the other way around. > 2. Though algorithms in public are "fundamental" in terms of applications in > computer vision area, but the core is more basic and primitive. You seem to be distinguishing between level 1 and level 2 libraries. I see no reason why more good level 2 libraries should not be added to the core. In fact, I think that's the ideal route: the core grows as we add more and more good libraries to it. I don't think the VXL definition of "core" is "smallest subset". I think the VXL core is a set of widely used, robust libraries. Some, like vnl, vil, and vgl support essentially non-overlapping functional areas, and are hence implemented as level 1 libraries. Others, like vgl_algo, are not so easily categorized, and hence are level 2 libraries. Presumably, these "public" libraries will not depend on "contrib" libraries. Then, they are close to meeting the criteria for being "core" libraries. I would suggest that any library that would belong in this public space would be better served in core. > I agree on most of the criterion Amitha mentioned, i.e., well-documented, > relatively stable, and used by more than one group. But that doesn't mean > public libraries should go into core, since we can still apply the same > requirements to public library. Again: what would be the value of adding yet another category? How would these public libraries be different from my (broader) definition of "core"? > To me, the major advantage of introducing public library is clear and easy > to understand hierarchies. Heirarchies of what? Do you mean dependencies? Amitha. |
From: Gehua Y. <ya...@rp...> - 2004-05-20 22:04:46
|
Sorry for the confusion. I agree that, by using a broader definition, public is essentially part of core. I am just a little worried about the future crowdedness and possible confusion of dependencies in core directory. If vnl, vil, and vgl stuff is level 1 and vnl_algo is level 2, then the so-called public libraries will level 3? How could we separate these three levels in terms of current directory organization? Gehua ----- Original Message ----- From: "Amitha Perera" <pe...@cs...> To: "Gehua Yang" <ya...@rp...> Cc: "Vxl" <vxl...@li...> Sent: Thursday, May 20, 2004 5:43 PM Subject: Re: [Vxl-maintainers] Not core, Not contrib > On Thu 20 May 2004, Gehua Yang wrote: > > My answer is YES. The reasons are: > > 1. "Public" can use and depend on core, but not the other way around. > > 2. Though algorithms in public are "fundamental" in terms of applications in > > computer vision area, but the core is more basic and primitive. > > You seem to be distinguishing between level 1 and level 2 libraries. I > see no reason why more good level 2 libraries should not be added to > the core. In fact, I think that's the ideal route: the core grows as > we add more and more good libraries to it. I don't think the VXL > definition of "core" is "smallest subset". I think the VXL core is a > set of widely used, robust libraries. Some, like vnl, vil, and vgl > support essentially non-overlapping functional areas, and are hence > implemented as level 1 libraries. Others, like vgl_algo, are not so > easily categorized, and hence are level 2 libraries. > > Presumably, these "public" libraries will not depend on "contrib" > libraries. Then, they are close to meeting the criteria for being > "core" libraries. I would suggest that any library that would belong > in this public space would be better served in core. > > > I agree on most of the criterion Amitha mentioned, i.e., well-documented, > > relatively stable, and used by more than one group. But that doesn't mean > > public libraries should go into core, since we can still apply the same > > requirements to public library. > > Again: what would be the value of adding yet another category? How > would these public libraries be different from my (broader) > definition of "core"? > > > To me, the major advantage of introducing public library is clear and easy > > to understand hierarchies. > > Heirarchies of what? Do you mean dependencies? > > Amitha. > |
From: <kar...@ya...> - 2004-05-21 08:54:01
|
The structure at the moment is: level 1: vnl, vgl, and anything else with 3 letters. level 2: vgui, vnl_algo and anything else with more than 3 letters. In each library you can depend only on stuff in libraries in the level above. I think the new libraries you are talking about adding would be just level 2 libraries, wouldn't they? Therefore I agree with Amitha that separating them off would be confusing. Karen ky...@ro... --- Gehua Yang <ya...@rp...> wrote: > Sorry for the confusion. > > I agree that, by using a broader definition, public is essentially part > of > core. I am just a little worried about the future crowdedness and > possible > confusion of dependencies in core directory. If vnl, vil, and vgl stuff > is > level 1 and vnl_algo is level 2, then the so-called public libraries > will > level 3? How could we separate these three levels in terms of current > directory organization? > > Gehua > ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
From: Matt L. <ml...@le...> - 2004-05-21 14:07:52
|
I think one issue here is whether or not there should be a more explicit separation of level 1 and level 2 libraries in the core. That is, should the directory structure change so that level 1 and level 2 libraries each have a subdirectory in core. The other issue seems to be whether or not there should be a more explicit separation of core libraries based of function. I think the core libraries have been mostly limited to code that can be used as building blocks for more complicated algorithms. Is it logical to also include more specific and complete vision algorithms into the core or should they be separated? I'm also concerned about crowdedness and confusion of dependencies if many more libraries are added to core. I agree with Amitha that these "public" libraries should not be separated from the core. Most are probably level 2 libraries, though I would imagine that we need a third level for some. However, I'm wondering if there is someway that we can subdivide the core that would make the levels and dependencies more clear. -Matt Leotta On Fri, 2004-05-21 at 04:53, Karen McGaul wrote: > The structure at the moment is: > level 1: vnl, vgl, and anything else with 3 letters. > level 2: vgui, vnl_algo and anything else with more than 3 letters. > > In each library you can depend only on stuff in libraries in the level > above. I think the new libraries you are talking about adding would be > just level 2 libraries, wouldn't they? Therefore I agree with Amitha that > separating them off would be confusing. > > Karen > ky...@ro... > > --- Gehua Yang <ya...@rp...> wrote: > Sorry for the confusion. > > > > I agree that, by using a broader definition, public is essentially part > > of > > core. I am just a little worried about the future crowdedness and > > possible > > confusion of dependencies in core directory. If vnl, vil, and vgl stuff > > is > > level 1 and vnl_algo is level 2, then the so-called public libraries > > will > > level 3? How could we separate these three levels in terms of current > > directory organization? > > > > Gehua > > > > > > > > ____________________________________________________________ > Yahoo! Messenger - Communicate instantly..."Ping" > your friends today! Download Messenger Now > http://uk.messenger.yahoo.com/download/index.html > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |