From: Ricardo F. <rf...@gm...> - 2016-10-13 03:46:21
|
Hi, I am planing to release a considerable amount of research code on 3D stereo based on vxl, as a new repository. We all want to keep vxl lean, so I am planning to call the new project bigvxl. Do you agree? Is the name too close to vxl? The idea is to release large (and possibly klunky) computer vision systems in bigvxl, which can slowly mature to one day make it into vxl or even core. Some "big" code by nature don't even have to ever make it to vxl strict standards or granularity, but can still be very useful. The idea came up because most research and industry labs having internal code that use vxl do not have an intermediate, common and more laidback open source step prior to pushing code to lean vxl. So I am proposing to help maintain a common bigvxl repository that can be seen as closely coordinated with vxl and that can keep up (at least partially) with vxl changes and be built on official dashboards. I also plan to stratify bigvxl into core, development libraries, contrib, and so on. At least the bigvxl team (myself and a couple of students for now) should keep bigvxl's basic libraries conforming to the latest vxl at all times. Bigvxl woud be easier to change and less strict (thus messier) than vxl. Any thoughts? I plan to publish an initial bigvxl based on publishable Brown University code in the coming days. Best, |
From: Matt L. <mat...@ki...> - 2016-10-13 13:02:43
|
Ricardo, You are free to do what you like with your own code base that builds on VXL. I think it's great to be sharing more code based on VXL and I'm especially interested in seeing more 3D stereo code. Your curve reconstruction work is great, and it would be nice to have to more openly accessible. I'm a little confused about what you are proposing here. Maybe it's just the name that is throwing me off. Are you talking about a fork of VXL that contains all of VXL plus additional contributions? Or are you talking about a collection of code that builds against VXL but doesn't contain VXL? If it's the former I suggest you just make a fork on Github (either under your own account, or under a group for your lab) and just call it VXL. It would just be github.com/rfabbri/vxl. Actually, It looks like you've already done that. Then you can easily push and pull branches to and from the mainline VXL as needed. If you are talking about a repository that is just your research code that builds against VXL, that is fine too, but the name "Bigvxl" seems a little odd for that. --Matt On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> wrote: > Hi, > > I am planing to release a considerable amount of research code on 3D > stereo based on vxl, as a new repository. We all want to keep vxl lean, so > I am planning to call the new project bigvxl. Do you agree? Is the name too > close to vxl? > > The idea is to release large (and possibly klunky) computer vision systems > in bigvxl, which can slowly mature to one day make it into vxl or even > core. Some "big" code by nature don't even have to ever make it to vxl > strict standards or granularity, but can still be very useful. > > The idea came up because most research and industry labs having internal > code that use vxl do not have an intermediate, common and more laidback > open source step prior to pushing code to lean vxl. So I am proposing to > help maintain a common bigvxl repository that can be seen as closely > coordinated with vxl and that can keep up (at least partially) with vxl > changes and be built on official dashboards. I also plan to stratify bigvxl > into core, development libraries, contrib, and so on. At least the bigvxl > team (myself and a couple of students for now) should keep bigvxl's basic > libraries conforming to the latest vxl at all times. Bigvxl woud be easier > to change and less strict (thus messier) than vxl. > > Any thoughts? I plan to publish an initial bigvxl based on publishable > Brown University code in the coming days. > > Best, > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Ricardo F. <rf...@gm...> - 2016-10-21 18:49:22
|
Hi Matt, I was thinking about "a collection of code that builds against VXL but doesn't contain VXL". Another name would be dvxl or DVXL for Development VXL. Does that dound less odd? I am open for other names. I should be uploading the code very soon, in the coming days. Thanks, -- Dr Ricardo Fabbri Professor of Computer Engineering GNU/Linux registered user #175401 pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> wrote: > Ricardo, > > You are free to do what you like with your own code base that builds on > VXL. I think it's great to be sharing more code based on VXL and I'm > especially interested in seeing more 3D stereo code. Your curve > reconstruction work is great, and it would be nice to have to more openly > accessible. > > I'm a little confused about what you are proposing here. Maybe it's just > the name that is throwing me off. Are you talking about a fork of VXL that > contains all of VXL plus additional contributions? Or are you talking > about a collection of code that builds against VXL but doesn't contain > VXL? If it's the former I suggest you just make a fork on Github (either > under your own account, or under a group for your lab) and just call it > VXL. It would just be github.com/rfabbri/vxl. Actually, It looks like > you've already done that. Then you can easily push and pull branches to > and from the mainline VXL as needed. If you are talking about a repository > that is just your research code that builds against VXL, that is fine too, > but the name "Bigvxl" seems a little odd for that. > > --Matt > > On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> > wrote: > >> Hi, >> >> I am planing to release a considerable amount of research code on 3D >> stereo based on vxl, as a new repository. We all want to keep vxl lean, so >> I am planning to call the new project bigvxl. Do you agree? Is the name too >> close to vxl? >> >> The idea is to release large (and possibly klunky) computer vision >> systems in bigvxl, which can slowly mature to one day make it into vxl or >> even core. Some "big" code by nature don't even have to ever make it to vxl >> strict standards or granularity, but can still be very useful. >> >> The idea came up because most research and industry labs having internal >> code that use vxl do not have an intermediate, common and more laidback >> open source step prior to pushing code to lean vxl. So I am proposing to >> help maintain a common bigvxl repository that can be seen as closely >> coordinated with vxl and that can keep up (at least partially) with vxl >> changes and be built on official dashboards. I also plan to stratify bigvxl >> into core, development libraries, contrib, and so on. At least the bigvxl >> team (myself and a couple of students for now) should keep bigvxl's basic >> libraries conforming to the latest vxl at all times. Bigvxl woud be easier >> to change and less strict (thus messier) than vxl. >> >> Any thoughts? I plan to publish an initial bigvxl based on publishable >> Brown University code in the coming days. >> >> Best, >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> >> > |
From: Wheeler, F. W (GE G. R. US) <wh...@ge...> - 2016-10-21 20:29:40
|
Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD could mean Vision Something Development. Fred From: Ricardo Fabbri [mailto:rf...@gm...] Sent: Friday, October 21, 2016 2:49 PM To: Matt Leotta <mat...@ki...> Cc: Vxl-maintainers <vxl...@li...>; Anil Usumezbas <ani...@gm...> Subject: EXT: Re: [Vxl-maintainers] bigvxl : a new project Hi Matt, I was thinking about "a collection of code that builds against VXL but doesn't contain VXL". Another name would be dvxl or DVXL for Development VXL. Does that dound less odd? I am open for other names. I should be uploading the code very soon, in the coming days. Thanks, -- Dr Ricardo Fabbri Professor of Computer Engineering GNU/Linux registered user #175401 pt.wikipedia.org/wiki/IPRJ<https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=> labmacambira.sf.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=> rfabbri.github.io<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...<mailto:mat...@ki...>> wrote: Ricardo, You are free to do what you like with your own code base that builds on VXL. I think it's great to be sharing more code based on VXL and I'm especially interested in seeing more 3D stereo code. Your curve reconstruction work is great, and it would be nice to have to more openly accessible. I'm a little confused about what you are proposing here. Maybe it's just the name that is throwing me off. Are you talking about a fork of VXL that contains all of VXL plus additional contributions? Or are you talking about a collection of code that builds against VXL but doesn't contain VXL? If it's the former I suggest you just make a fork on Github (either under your own account, or under a group for your lab) and just call it VXL. It would just be github.com/rfabbri/vxl<https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>. Actually, It looks like you've already done that. Then you can easily push and pull branches to and from the mainline VXL as needed. If you are talking about a repository that is just your research code that builds against VXL, that is fine too, but the name "Bigvxl" seems a little odd for that. --Matt On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...<mailto:rf...@gm...>> wrote: Hi, I am planing to release a considerable amount of research code on 3D stereo based on vxl, as a new repository. We all want to keep vxl lean, so I am planning to call the new project bigvxl. Do you agree? Is the name too close to vxl? The idea is to release large (and possibly klunky) computer vision systems in bigvxl, which can slowly mature to one day make it into vxl or even core. Some "big" code by nature don't even have to ever make it to vxl strict standards or granularity, but can still be very useful. The idea came up because most research and industry labs having internal code that use vxl do not have an intermediate, common and more laidback open source step prior to pushing code to lean vxl. So I am proposing to help maintain a common bigvxl repository that can be seen as closely coordinated with vxl and that can keep up (at least partially) with vxl changes and be built on official dashboards. I also plan to stratify bigvxl into core, development libraries, contrib, and so on. At least the bigvxl team (myself and a couple of students for now) should keep bigvxl's basic libraries conforming to the latest vxl at all times. Bigvxl woud be easier to change and less strict (thus messier) than vxl. Any thoughts? I plan to publish an initial bigvxl based on publishable Brown University code in the coming days. Best, ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot<https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=> _______________________________________________ Vxl-maintainers mailing list Vxl...@li...<mailto:Vxl...@li...> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=> |
From: Ricardo F. <rf...@gm...> - 2016-10-22 22:29:23
|
I'm going with Fred's suggestion, vxd. dvxl is consistent with the name given to development libraries that will be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more direct reference to vxl. However, it is too similar to vxl, and is one letter longer than vxd. I'll be uploading code now. Please, please stop me if you prefer dvxl instead :) -- Dr Ricardo Fabbri Professor of Computer Engineering GNU/Linux registered user #175401 pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global Research, US) <wh...@ge...> wrote: > > > Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD > could mean Vision Something Development. > > > > Fred > > > > *From:* Ricardo Fabbri [mailto:rf...@gm...] > *Sent:* Friday, October 21, 2016 2:49 PM > *To:* Matt Leotta <mat...@ki...> > *Cc:* Vxl-maintainers <vxl...@li...>; Anil > Usumezbas <ani...@gm...> > *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project > > > > Hi Matt, > > > > I was thinking about "a collection of code that builds against VXL but > doesn't contain VXL". > > Another name would be dvxl or DVXL for Development VXL. Does that dound > less odd? > > I am open for other names. I should be uploading the code very soon, in > the coming days. > > > > Thanks, > > > > -- > Dr Ricardo Fabbri > Professor of Computer Engineering > GNU/Linux registered user #175401 > pt.wikipedia.org/wiki/IPRJ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=> > labmacambira.sf.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=> > > rfabbri.github.io > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=> > > > > On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> > wrote: > > Ricardo, > > > > You are free to do what you like with your own code base that builds on > VXL. I think it's great to be sharing more code based on VXL and I'm > especially interested in seeing more 3D stereo code. Your curve > reconstruction work is great, and it would be nice to have to more openly > accessible. > > > > I'm a little confused about what you are proposing here. Maybe it's just > the name that is throwing me off. Are you talking about a fork of VXL that > contains all of VXL plus additional contributions? Or are you talking > about a collection of code that builds against VXL but doesn't contain > VXL? If it's the former I suggest you just make a fork on Github (either > under your own account, or under a group for your lab) and just call it > VXL. It would just be github.com/rfabbri/vxl > <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>. > Actually, It looks like you've already done that. Then you can easily push > and pull branches to and from the mainline VXL as needed. If you are > talking about a repository that is just your research code that builds > against VXL, that is fine too, but the name "Bigvxl" seems a little odd for > that. > > > > --Matt > > > > On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> > wrote: > > Hi, > > I am planing to release a considerable amount of research code on 3D > stereo based on vxl, as a new repository. We all want to keep vxl lean, so > I am planning to call the new project bigvxl. Do you agree? Is the name too > close to vxl? > > The idea is to release large (and possibly klunky) computer vision systems > in bigvxl, which can slowly mature to one day make it into vxl or even > core. Some "big" code by nature don't even have to ever make it to vxl > strict standards or granularity, but can still be very useful. > > The idea came up because most research and industry labs having internal > code that use vxl do not have an intermediate, common and more laidback > open source step prior to pushing code to lean vxl. So I am proposing to > help maintain a common bigvxl repository that can be seen as closely > coordinated with vxl and that can keep up (at least partially) with vxl > changes and be built on official dashboards. I also plan to stratify bigvxl > into core, development libraries, contrib, and so on. At least the bigvxl > team (myself and a couple of students for now) should keep bigvxl's basic > libraries conforming to the latest vxl at all times. Bigvxl woud be easier > to change and less strict (thus messier) than vxl. > > Any thoughts? I plan to publish an initial bigvxl based on publishable > Brown University code in the coming days. > > Best, > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=> > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=> > > > > > |
From: Ricardo F. <rf...@gm...> - 2016-10-22 23:12:36
|
Here's what I'm doing for the individual library naming. A typical setup will have three VXL codebases: VXL, VXD and an internal version (eg, LEMSVXL at Brown). In VXL, we have things like vgl, vnl etc. in VXL/contrib/brl/bbas there are things such as bnl for contributions to vnl. The internal / closed-source version of bnl is called dbnl in LEMSVXL. In VXD we should have something in between for, say, vnl development changes that are open-sourced. Since the internal libs at Brown already prepend a 'd', as in 'dbnl', I was thinking that VXD should instead *append* a 'd', like 'bnld'. So the process of placing code would be threefold: 1) VXL: core/vnl and contrib/bbas/bnl for stable additions from Brown 2) VXD: basic/bnld for less stable additions from Brown, open sourced 3) Closed-sourced code improving bnl (as in LEMSVXL): basic/dbnl This naming convention is important as we want to keep many versions of the same library around, one in VXL, one in VXD and another one inside the lab. Is this too confusing? It will take some work to do this, so please let me know. Thanks, -- Dr Ricardo Fabbri Professor of Computer Engineering GNU/Linux registered user #175401 pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> On Sat, Oct 22, 2016 at 8:28 PM, Ricardo Fabbri <rf...@gm...> wrote: > I'm going with Fred's suggestion, vxd. > > dvxl is consistent with the name given to development libraries that will > be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more > direct reference to vxl. However, it is too similar to vxl, and is one > letter longer than vxd. > > I'll be uploading code now. Please, please stop me if you prefer dvxl > instead :) > > > > -- > Dr Ricardo Fabbri > Professor of Computer Engineering > GNU/Linux registered user #175401 > pt.wikipedia.org/wiki/IPRJ > labmacambira.sf.net > rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> > > On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global Research, > US) <wh...@ge...> wrote: > >> >> >> Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD >> could mean Vision Something Development. >> >> >> >> Fred >> >> >> >> *From:* Ricardo Fabbri [mailto:rf...@gm...] >> *Sent:* Friday, October 21, 2016 2:49 PM >> *To:* Matt Leotta <mat...@ki...> >> *Cc:* Vxl-maintainers <vxl...@li...>; Anil >> Usumezbas <ani...@gm...> >> *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project >> >> >> >> Hi Matt, >> >> >> >> I was thinking about "a collection of code that builds against VXL but >> doesn't contain VXL". >> >> Another name would be dvxl or DVXL for Development VXL. Does that dound >> less odd? >> >> I am open for other names. I should be uploading the code very soon, in >> the coming days. >> >> >> >> Thanks, >> >> >> >> -- >> Dr Ricardo Fabbri >> Professor of Computer Engineering >> GNU/Linux registered user #175401 >> pt.wikipedia.org/wiki/IPRJ >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=> >> labmacambira.sf.net >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=> >> >> rfabbri.github.io >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=> >> >> >> >> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> >> wrote: >> >> Ricardo, >> >> >> >> You are free to do what you like with your own code base that builds on >> VXL. I think it's great to be sharing more code based on VXL and I'm >> especially interested in seeing more 3D stereo code. Your curve >> reconstruction work is great, and it would be nice to have to more openly >> accessible. >> >> >> >> I'm a little confused about what you are proposing here. Maybe it's just >> the name that is throwing me off. Are you talking about a fork of VXL that >> contains all of VXL plus additional contributions? Or are you talking >> about a collection of code that builds against VXL but doesn't contain >> VXL? If it's the former I suggest you just make a fork on Github (either >> under your own account, or under a group for your lab) and just call it >> VXL. It would just be github.com/rfabbri/vxl >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>. >> Actually, It looks like you've already done that. Then you can easily push >> and pull branches to and from the mainline VXL as needed. If you are >> talking about a repository that is just your research code that builds >> against VXL, that is fine too, but the name "Bigvxl" seems a little odd for >> that. >> >> >> >> --Matt >> >> >> >> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> >> wrote: >> >> Hi, >> >> I am planing to release a considerable amount of research code on 3D >> stereo based on vxl, as a new repository. We all want to keep vxl lean, so >> I am planning to call the new project bigvxl. Do you agree? Is the name too >> close to vxl? >> >> The idea is to release large (and possibly klunky) computer vision >> systems in bigvxl, which can slowly mature to one day make it into vxl or >> even core. Some "big" code by nature don't even have to ever make it to vxl >> strict standards or granularity, but can still be very useful. >> >> The idea came up because most research and industry labs having internal >> code that use vxl do not have an intermediate, common and more laidback >> open source step prior to pushing code to lean vxl. So I am proposing to >> help maintain a common bigvxl repository that can be seen as closely >> coordinated with vxl and that can keep up (at least partially) with vxl >> changes and be built on official dashboards. I also plan to stratify bigvxl >> into core, development libraries, contrib, and so on. At least the bigvxl >> team (myself and a couple of students for now) should keep bigvxl's basic >> libraries conforming to the latest vxl at all times. Bigvxl woud be easier >> to change and less strict (thus messier) than vxl. >> >> Any thoughts? I plan to publish an initial bigvxl based on publishable >> Brown University code in the coming days. >> >> Best, >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=> >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=> >> >> >> >> >> > > |
From: Scott R. <sco...@vi...> - 2016-10-24 15:21:21
|
Would VXL be a compile-time dependency of VXD? Also, where would the other directories that are currently in vxl/contrib (besides contrib/bbas/bnl) go, VXD? Or would you decide on a case-by-case basis? thanks Scott On Sat, Oct 22, 2016 at 7:12 PM, Ricardo Fabbri <rf...@gm...> wrote: > Here's what I'm doing for the individual library naming. > > A typical setup will have three VXL codebases: VXL, VXD and an internal > version (eg, LEMSVXL at Brown). > > In VXL, we have things like vgl, vnl etc. in VXL/contrib/brl/bbas there > are things such as bnl for contributions to vnl. > The internal / closed-source version of bnl is called dbnl in LEMSVXL. > > In VXD we should have something in between for, say, vnl development > changes that are open-sourced. Since the internal libs at Brown already > prepend a 'd', as in 'dbnl', I was thinking that VXD should instead > *append* a 'd', like 'bnld'. > > So the process of placing code would be threefold: > > 1) VXL: core/vnl and contrib/bbas/bnl for stable additions from Brown > 2) VXD: basic/bnld for less stable additions from Brown, open sourced > 3) Closed-sourced code improving bnl (as in LEMSVXL): basic/dbnl > > This naming convention is important as we want to keep many versions of > the same library around, one in VXL, one in VXD and another one inside the > lab. Is this too confusing? It will take some work to do this, so please > let me know. > > Thanks, > > > -- > Dr Ricardo Fabbri > Professor of Computer Engineering > GNU/Linux registered user #175401 > pt.wikipedia.org/wiki/IPRJ > labmacambira.sf.net > rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> > > On Sat, Oct 22, 2016 at 8:28 PM, Ricardo Fabbri <rf...@gm...> wrote: > >> I'm going with Fred's suggestion, vxd. >> >> dvxl is consistent with the name given to development libraries that will >> be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more >> direct reference to vxl. However, it is too similar to vxl, and is one >> letter longer than vxd. >> >> I'll be uploading code now. Please, please stop me if you prefer dvxl >> instead :) >> >> >> >> -- >> Dr Ricardo Fabbri >> Professor of Computer Engineering >> GNU/Linux registered user #175401 >> pt.wikipedia.org/wiki/IPRJ >> labmacambira.sf.net >> rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> >> >> On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global >> Research, US) <wh...@ge...> wrote: >> >>> >>> >>> Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD >>> could mean Vision Something Development. >>> >>> >>> >>> Fred >>> >>> >>> >>> *From:* Ricardo Fabbri [mailto:rf...@gm...] >>> *Sent:* Friday, October 21, 2016 2:49 PM >>> *To:* Matt Leotta <mat...@ki...> >>> *Cc:* Vxl-maintainers <vxl...@li...>; Anil >>> Usumezbas <ani...@gm...> >>> *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project >>> >>> >>> >>> Hi Matt, >>> >>> >>> >>> I was thinking about "a collection of code that builds against VXL but >>> doesn't contain VXL". >>> >>> Another name would be dvxl or DVXL for Development VXL. Does that dound >>> less odd? >>> >>> I am open for other names. I should be uploading the code very soon, in >>> the coming days. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> -- >>> Dr Ricardo Fabbri >>> Professor of Computer Engineering >>> GNU/Linux registered user #175401 >>> pt.wikipedia.org/wiki/IPRJ >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=> >>> labmacambira.sf.net >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=> >>> >>> rfabbri.github.io >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=> >>> >>> >>> >>> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> >>> wrote: >>> >>> Ricardo, >>> >>> >>> >>> You are free to do what you like with your own code base that builds on >>> VXL. I think it's great to be sharing more code based on VXL and I'm >>> especially interested in seeing more 3D stereo code. Your curve >>> reconstruction work is great, and it would be nice to have to more openly >>> accessible. >>> >>> >>> >>> I'm a little confused about what you are proposing here. Maybe it's >>> just the name that is throwing me off. Are you talking about a fork of VXL >>> that contains all of VXL plus additional contributions? Or are you talking >>> about a collection of code that builds against VXL but doesn't contain >>> VXL? If it's the former I suggest you just make a fork on Github (either >>> under your own account, or under a group for your lab) and just call it >>> VXL. It would just be github.com/rfabbri/vxl >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>. >>> Actually, It looks like you've already done that. Then you can easily push >>> and pull branches to and from the mainline VXL as needed. If you are >>> talking about a repository that is just your research code that builds >>> against VXL, that is fine too, but the name "Bigvxl" seems a little odd for >>> that. >>> >>> >>> >>> --Matt >>> >>> >>> >>> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> >>> wrote: >>> >>> Hi, >>> >>> I am planing to release a considerable amount of research code on 3D >>> stereo based on vxl, as a new repository. We all want to keep vxl lean, so >>> I am planning to call the new project bigvxl. Do you agree? Is the name too >>> close to vxl? >>> >>> The idea is to release large (and possibly klunky) computer vision >>> systems in bigvxl, which can slowly mature to one day make it into vxl or >>> even core. Some "big" code by nature don't even have to ever make it to vxl >>> strict standards or granularity, but can still be very useful. >>> >>> The idea came up because most research and industry labs having internal >>> code that use vxl do not have an intermediate, common and more laidback >>> open source step prior to pushing code to lean vxl. So I am proposing to >>> help maintain a common bigvxl repository that can be seen as closely >>> coordinated with vxl and that can keep up (at least partially) with vxl >>> changes and be built on official dashboards. I also plan to stratify bigvxl >>> into core, development libraries, contrib, and so on. At least the bigvxl >>> team (myself and a couple of students for now) should keep bigvxl's basic >>> libraries conforming to the latest vxl at all times. Bigvxl woud be easier >>> to change and less strict (thus messier) than vxl. >>> >>> Any thoughts? I plan to publish an initial bigvxl based on publishable >>> Brown University code in the coming days. >>> >>> Best, >>> >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=> >>> _______________________________________________ >>> Vxl-maintainers mailing list >>> Vxl...@li... >>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=> >>> >>> >>> >>> >>> >> >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Ricardo F. <rf...@gm...> - 2016-10-24 15:15:29
|
On Mon, Oct 24, 2016 at 12:51 PM, Scott Richardson < sco...@vi...> wrote: > Would VXL be a compile-time dependency of VXD? Yes. At first, a CMake variable. But ideally it should detect installed VXL automatically as other libraries commonly do. > > Also, where would the other directories that are currently in vxl/contrib > (besides contrib/bbas/bnl) go, VXD? Or would you decide on a case-by-case > basis? The idea is that VXD can build at the same time as VXL and private VXL-dependent libraries from other companies/universities, without conflict, even if this means some code duplication (each library version having potentially similar code but a different maturity level). So it would be a parallel hierarchy as much as possible, with different naming. To begin with, VXD will only have libraries that actually have public code that is not ready or reviewed for VXL-quality yet. In other words, empty development libraries will not be mirrored in VXD. This will be decided on a case by case basis. If we have development code to be open sourced, we create the *d libraries as needed. I'm thinking about appending a *d to only the last path/library name. For instance: vxl/contrib/brl/bbas/libname would map to vxd/contrib/brl/bbas/libname*d* (same lib, ending with a *d) as possible. vxl/contrib/gel/vsol would map to vxd/contrib/gel/vsol*d* Includes for vxd/contrib/gel/vsold would look like #include <vsold/vsold_some_class.h> In CMake, we'd have include_directories( ${VXD_GEL_INCLUDE_DIR} ) We should strive to to make it always consistent with VXL while apending a 'd' to the lib names. This is a good idea since it is a tiny but good initial step towards making internal private code available in VXL: you first name it and place it properly, following the VXL hierarchy, then you mature the code and one day it may make it to the corresponding folder in VXL. As easy as it may sound, some developers will find it a lot of work to have to rename/properly place their internal library prior to open-sourcing it in VXD. Making a new library name and path correspond to a hypothetical place in VXL in a clear way would be the first requirement to place code in VXD. > > thanks > Scott > > On Sat, Oct 22, 2016 at 7:12 PM, Ricardo Fabbri <rf...@gm...> wrote: >> >> Here's what I'm doing for the individual library naming. >> >> A typical setup will have three VXL codebases: VXL, VXD and an internal >> version (eg, LEMSVXL at Brown). >> >> In VXL, we have things like vgl, vnl etc. in VXL/contrib/brl/bbas there >> are things such as bnl for contributions to vnl. >> The internal / closed-source version of bnl is called dbnl in LEMSVXL. >> >> In VXD we should have something in between for, say, vnl development >> changes that are open-sourced. Since the internal libs at Brown already >> prepend a 'd', as in 'dbnl', I was thinking that VXD should instead *append* >> a 'd', like 'bnld'. >> >> So the process of placing code would be threefold: >> >> 1) VXL: core/vnl and contrib/bbas/bnl for stable additions from Brown >> 2) VXD: basic/bnld for less stable additions from Brown, open sourced >> 3) Closed-sourced code improving bnl (as in LEMSVXL): basic/dbnl >> >> This naming convention is important as we want to keep many versions of >> the same library around, one in VXL, one in VXD and another one inside the >> lab. Is this too confusing? It will take some work to do this, so please let >> me know. >> >> Thanks, >> >> >> -- >> Dr Ricardo Fabbri >> Professor of Computer Engineering >> GNU/Linux registered user #175401 >> pt.wikipedia.org/wiki/IPRJ >> labmacambira.sf.net >> rfabbri.github.io >> >> On Sat, Oct 22, 2016 at 8:28 PM, Ricardo Fabbri <rf...@gm...> wrote: >>> >>> I'm going with Fred's suggestion, vxd. >>> >>> dvxl is consistent with the name given to development libraries that will >>> be uploaded, such as dvgl, dvnl, or dbgl, dbnl etc. It is also a more direct >>> reference to vxl. However, it is too similar to vxl, and is one letter >>> longer than vxd. >>> >>> I'll be uploading code now. Please, please stop me if you prefer dvxl >>> instead :) >>> >>> >>> >>> -- >>> Dr Ricardo Fabbri >>> Professor of Computer Engineering >>> GNU/Linux registered user #175401 >>> pt.wikipedia.org/wiki/IPRJ >>> labmacambira.sf.net >>> rfabbri.github.io >>> >>> On Fri, Oct 21, 2016 at 4:54 PM, Wheeler, Frederick W (GE Global >>> Research, US) <wh...@ge...> wrote: >>>> >>>> >>>> >>>> Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD >>>> could mean Vision Something Development. >>>> >>>> >>>> >>>> Fred >>>> >>>> >>>> >>>> From: Ricardo Fabbri [mailto:rf...@gm...] >>>> Sent: Friday, October 21, 2016 2:49 PM >>>> To: Matt Leotta <mat...@ki...> >>>> Cc: Vxl-maintainers <vxl...@li...>; Anil >>>> Usumezbas <ani...@gm...> >>>> Subject: EXT: Re: [Vxl-maintainers] bigvxl : a new project >>>> >>>> >>>> >>>> Hi Matt, >>>> >>>> >>>> >>>> I was thinking about "a collection of code that builds against VXL but >>>> doesn't contain VXL". >>>> >>>> Another name would be dvxl or DVXL for Development VXL. Does that dound >>>> less odd? >>>> >>>> I am open for other names. I should be uploading the code very soon, in >>>> the coming days. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> -- >>>> Dr Ricardo Fabbri >>>> Professor of Computer Engineering >>>> GNU/Linux registered user #175401 >>>> pt.wikipedia.org/wiki/IPRJ >>>> labmacambira.sf.net >>>> >>>> rfabbri.github.io >>>> >>>> >>>> >>>> On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> >>>> wrote: >>>> >>>> Ricardo, >>>> >>>> >>>> >>>> You are free to do what you like with your own code base that builds on >>>> VXL. I think it's great to be sharing more code based on VXL and I'm >>>> especially interested in seeing more 3D stereo code. Your curve >>>> reconstruction work is great, and it would be nice to have to more openly >>>> accessible. >>>> >>>> >>>> >>>> I'm a little confused about what you are proposing here. Maybe it's >>>> just the name that is throwing me off. Are you talking about a fork of VXL >>>> that contains all of VXL plus additional contributions? Or are you talking >>>> about a collection of code that builds against VXL but doesn't contain VXL? >>>> If it's the former I suggest you just make a fork on Github (either under >>>> your own account, or under a group for your lab) and just call it VXL. It >>>> would just be github.com/rfabbri/vxl. Actually, It looks like you've >>>> already done that. Then you can easily push and pull branches to and from >>>> the mainline VXL as needed. If you are talking about a repository that is >>>> just your research code that builds against VXL, that is fine too, but the >>>> name "Bigvxl" seems a little odd for that. >>>> >>>> >>>> >>>> --Matt >>>> >>>> >>>> >>>> On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I am planing to release a considerable amount of research code on 3D >>>> stereo based on vxl, as a new repository. We all want to keep vxl lean, so I >>>> am planning to call the new project bigvxl. Do you agree? Is the name too >>>> close to vxl? >>>> >>>> The idea is to release large (and possibly klunky) computer vision >>>> systems in bigvxl, which can slowly mature to one day make it into vxl or >>>> even core. Some "big" code by nature don't even have to ever make it to vxl >>>> strict standards or granularity, but can still be very useful. >>>> >>>> The idea came up because most research and industry labs having internal >>>> code that use vxl do not have an intermediate, common and more laidback open >>>> source step prior to pushing code to lean vxl. So I am proposing to help >>>> maintain a common bigvxl repository that can be seen as closely coordinated >>>> with vxl and that can keep up (at least partially) with vxl changes and be >>>> built on official dashboards. I also plan to stratify bigvxl into core, >>>> development libraries, contrib, and so on. At least the bigvxl team (myself >>>> and a couple of students for now) should keep bigvxl's basic libraries >>>> conforming to the latest vxl at all times. Bigvxl woud be easier to change >>>> and less strict (thus messier) than vxl. >>>> >>>> Any thoughts? I plan to publish an initial bigvxl based on publishable >>>> Brown University code in the coming days. >>>> >>>> Best, >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Vxl-maintainers mailing list >>>> Vxl...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> > |
From: Peter V. <pet...@ya...> - 2016-10-27 16:35:34
|
Shouldn't that be "VDL", then? "Vision Development Libraries"As opposed to / next to: VGL (geometry), VNL (numerics), VIL (imaging), etc.It's the "X" which is the wildcard ... -- Peter. -- Den fredag, 21 oktober 2016 22:29 skrev "Wheeler, Frederick W (GE Global Research, US)" <wh...@ge...>: #yiv3005058133 #yiv3005058133 -- _filtered #yiv3005058133 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv3005058133 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv3005058133 #yiv3005058133 p.yiv3005058133MsoNormal, #yiv3005058133 li.yiv3005058133MsoNormal, #yiv3005058133 div.yiv3005058133MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv3005058133 a:link, #yiv3005058133 span.yiv3005058133MsoHyperlink {color:blue;text-decoration:underline;}#yiv3005058133 a:visited, #yiv3005058133 span.yiv3005058133MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3005058133 p {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv3005058133 p.yiv3005058133msonormal0, #yiv3005058133 li.yiv3005058133msonormal0, #yiv3005058133 div.yiv3005058133msonormal0 {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv3005058133 span.yiv3005058133EmailStyle19 {color:windowtext;}#yiv3005058133 .yiv3005058133MsoChpDefault {} _filtered #yiv3005058133 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3005058133 div.yiv3005058133WordSection1 {}#yiv3005058133 Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD could mean Vision Something Development. Fred From: Ricardo Fabbri [mailto:rf...@gm...] Sent: Friday, October 21, 2016 2:49 PM To: Matt Leotta <mat...@ki...> Cc: Vxl-maintainers <vxl...@li...>; Anil Usumezbas <ani...@gm...> Subject: EXT: Re: [Vxl-maintainers] bigvxl : a new project Hi Matt, I was thinking about "a collection of code that builds against VXL but doesn't contain VXL". Another name would be dvxl or DVXL for Development VXL. Does that dound less odd? I am open for other names. I should be uploading the code very soon, in the coming days. Thanks, -- Dr Ricardo Fabbri Professor of Computer Engineering GNU/Linux registered user #175401 pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net rfabbri.github.io On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> wrote: Ricardo, You are free to do what you like with your own code base that builds on VXL. I think it's great to be sharing more code based on VXL and I'm especially interested in seeing more 3D stereo code. Your curve reconstruction work is great, and it would be nice to have to more openly accessible. I'm a little confused about what you are proposing here. Maybe it's just the name that is throwing me off. Are you talking about a fork of VXL that contains all of VXL plus additional contributions? Or are you talking about a collection of code that builds against VXL but doesn't contain VXL? If it's the former I suggest you just make a fork on Github (either under your own account, or under a group for your lab) and just call it VXL. It would just be github.com/rfabbri/vxl. Actually, It looks like you've already done that. Then you can easily push and pull branches to and from the mainline VXL as needed. If you are talking about a repository that is just your research code that builds against VXL, that is fine too, but the name "Bigvxl" seems a little odd for that. --Matt On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> wrote: Hi, I am planing to release a considerable amount of research code on 3D stereo based on vxl, as a new repository. We all want to keep vxl lean, so I am planning to call the new project bigvxl. Do you agree? Is the name too close to vxl? The idea is to release large (and possibly klunky) computer vision systems in bigvxl, which can slowly mature to one day make it into vxl or even core. Some "big" code by nature don't even have to ever make it to vxl strict standards or granularity, but can still be very useful. The idea came up because most research and industry labs having internal code that use vxl do not have an intermediate, common and more laidback open source step prior to pushing code to lean vxl. So I am proposing to help maintain a common bigvxl repository that can be seen as closely coordinated with vxl and that can keep up (at least partially) with vxl changes and be built on official dashboards. I also plan to stratify bigvxl into core, development libraries, contrib, and so on. At least the bigvxl team (myself and a couple of students for now) should keep bigvxl's basic libraries conforming to the latest vxl at all times. Bigvxl woud be easier to change and less strict (thus messier) than vxl. Any thoughts? I plan to publish an initial bigvxl based on publishable Brown University code in the coming days. Best, ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ricardo F. <rf...@gm...> - 2016-10-28 15:00:44
|
Hi Peter, VDL is indeed more consistent with VXL naming. In fact, VDL could be thought as a folder under VXL, ie, vxl/contrib/vdl, but managed in a separate repository and recursively having similar structure as VXL. Under vxl/contrib, we have BRL, GEL, etc. So 'VDL' would fit right in. One rationale for VXD is that we would be appending a '*d' to every library under development, like bnld, vgld, vsold, etc. In that sense, then, it is v*d. If we switch to VDL, technically every development library should be like vgl -> vgdl or vdgl. But that gets confusing. I'm thinking about just appending a d anyways, even if we use VDL. I'm not sure yet if we should switch to VDL, but it is a good name. What do you think? -- Dr Ricardo Fabbri Professor of Computer Engineering GNU/Linux registered user #175401 pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net rfabbri.github.io <http://www.lems.brown.edu/~rfabbri> On Thu, Oct 27, 2016 at 2:35 PM, Peter Vanroose <pet...@ya...> wrote: > Shouldn't that be "VDL", then? > "Vision Development Libraries" > As opposed to / next to: VGL (geometry), VNL (numerics), VIL (imaging), > etc. > It's the "X" which is the wildcard ... > > -- Peter. -- > > > Den fredag, 21 oktober 2016 22:29 skrev "Wheeler, Frederick W (GE Global > Research, US)" <wh...@ge...>: > > > > Perhaps “VXD”? VXL is meant to mean Vision Something Libraries. VXD > could mean Vision Something Development. > > Fred > > *From:* Ricardo Fabbri [mailto:rf...@gm...] > *Sent:* Friday, October 21, 2016 2:49 PM > *To:* Matt Leotta <mat...@ki...> > *Cc:* Vxl-maintainers <vxl...@li...>; Anil > Usumezbas <ani...@gm...> > *Subject:* EXT: Re: [Vxl-maintainers] bigvxl : a new project > > Hi Matt, > > I was thinking about "a collection of code that builds against VXL but > doesn't contain VXL". > Another name would be dvxl or DVXL for Development VXL. Does that dound > less odd? > I am open for other names. I should be uploading the code very soon, in > the coming days. > > Thanks, > > > -- > Dr Ricardo Fabbri > Professor of Computer Engineering > GNU/Linux registered user #175401 > pt.wikipedia.org/wiki/IPRJ > <https://urldefense.proofpoint.com/v2/url?u=http-3A__pt.wikipedia.org_wiki_IPRJ&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yzzbZzTFgDxZoY6JSs1k1jWEJJ-2v1JRzXC7p2qWqOU&e=> > labmacambira.sf.net > <https://urldefense.proofpoint.com/v2/url?u=http-3A__labmacambira.sf.net&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=tcaGTP5hAhJB1uxUmvz5j1RWPZNAzGrJOKgAqOJhEds&e=> > rfabbri.github.io > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lems.brown.edu_-7Erfabbri&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=_Ml9ogYimLN19Z6v-am_QhjMFWG5N9k-_m0ra_sgmlg&e=> > > On Thu, Oct 13, 2016 at 9:38 AM, Matt Leotta <mat...@ki...> > wrote: > > Ricardo, > > You are free to do what you like with your own code base that builds on > VXL. I think it's great to be sharing more code based on VXL and I'm > especially interested in seeing more 3D stereo code. Your curve > reconstruction work is great, and it would be nice to have to more openly > accessible. > > I'm a little confused about what you are proposing here. Maybe it's just > the name that is throwing me off. Are you talking about a fork of VXL that > contains all of VXL plus additional contributions? Or are you talking > about a collection of code that builds against VXL but doesn't contain > VXL? If it's the former I suggest you just make a fork on Github (either > under your own account, or under a group for your lab) and just call it > VXL. It would just be github.com/rfabbri/vxl > <https://urldefense.proofpoint.com/v2/url?u=http-3A__github.com_rfabbri_vxl&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=BPsKJlVCLswjx7lS2pkc5Vwwn4oYMSU3-kSU1XG4XBY&e=>. > Actually, It looks like you've already done that. Then you can easily push > and pull branches to and from the mainline VXL as needed. If you are > talking about a repository that is just your research code that builds > against VXL, that is fine too, but the name "Bigvxl" seems a little odd for > that. > > --Matt > > On Wed, Oct 12, 2016 at 11:46 PM, Ricardo Fabbri <rf...@gm...> > wrote: > > Hi, > I am planing to release a considerable amount of research code on 3D > stereo based on vxl, as a new repository. We all want to keep vxl lean, so > I am planning to call the new project bigvxl. Do you agree? Is the name too > close to vxl? > The idea is to release large (and possibly klunky) computer vision systems > in bigvxl, which can slowly mature to one day make it into vxl or even > core. Some "big" code by nature don't even have to ever make it to vxl > strict standards or granularity, but can still be very useful. > The idea came up because most research and industry labs having internal > code that use vxl do not have an intermediate, common and more laidback > open source step prior to pushing code to lean vxl. So I am proposing to > help maintain a common bigvxl repository that can be seen as closely > coordinated with vxl and that can keep up (at least partially) with vxl > changes and be built on official dashboards. I also plan to stratify bigvxl > into core, development libraries, contrib, and so on. At least the bigvxl > team (myself and a couple of students for now) should keep bigvxl's basic > libraries conforming to the latest vxl at all times. Bigvxl woud be easier > to change and less strict (thus messier) than vxl. > Any thoughts? I plan to publish an initial bigvxl based on publishable > Brown University code in the coming days. > Best, > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > <https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=VctCdhhgpCI3tzHCI4EQy9y4XxoD7Cm2-Dw_A2ErfMg&e=> > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_vxl-2Dmaintainers&d=DQMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=69wMrkpAraB1nFiFsNlRzg&m=Bq3Cic209mC8Njc7MBYrclroDZ3sx_1NjjYIs0WYo9E&s=yWCgc9LA7o5LeaxklJ0VAkvPKgnllBdvABJPOyQ_uZw&e=> > > > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > |