From: Chuck A. <chu...@ki...> - 2011-12-07 22:41:55
|
In the spirit of forward progress, I'd like to raise the possibility of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 became vidl, thus deprecating vidl1. That was over 2 1/2 years ago now. Current development is in vidl and vidl1 is no longer maintained sans the occasional compiler bug fix for missing include files. There's also a dependency on the mpeg2 library which is GPL licensed. Are there any objections or even affirmations for the removal of the long since deprecated vidl1 and GPL licensed libmpeg2? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos |
From: Amitha P. <ami...@us...> - 2011-12-07 23:02:04
|
i support this. On 12/7/2011 5:41 PM, Chuck Atkins wrote: > In the spirit of forward progress, I'd like to raise the possibility > of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 > became vidl, thus deprecating vidl1. That was over 2 1/2 years ago > now. Current development is in vidl and vidl1 is no longer maintained > sans the occasional compiler bug fix for missing include files. > There's also a dependency on the mpeg2 library which is GPL licensed. > > Are there any objections or even affirmations for the removal of the > long since deprecated vidl1 and GPL licensed libmpeg2? > > Chuck Atkins > R&D Engineer, Kitware, Inc. > (518) 371-3971 x603 > chu...@ki... <mailto:chu...@ki...> > > -- "Mathematicians are tools for turning coffee grounds into > formulas.", Paul Erdos > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Joseph M. <mu...@le...> - 2011-12-07 23:19:47
|
Chuck, I am fine with the change. I have some ancient code that uses vidl1 but will get rid of it. Joe From: Chuck Atkins [mailto:chu...@ki...] Sent: Wednesday, December 07, 2011 5:41 PM To: Vxl-maintainers Subject: [Vxl-maintainers] Status of VIDL1 In the spirit of forward progress, I'd like to raise the possibility of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 became vidl, thus deprecating vidl1. That was over 2 1/2 years ago now. Current development is in vidl and vidl1 is no longer maintained sans the occasional compiler bug fix for missing include files. There's also a dependency on the mpeg2 library which is GPL licensed. Are there any objections or even affirmations for the removal of the long since deprecated vidl1 and GPL licensed libmpeg2? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos |
From: Peter V. <pet...@ya...> - 2011-12-08 16:28:06
|
I observe that in the current public vxl source code, there are direct dependencies on vidl1 in the following three libraries: contrib/gel/vgel (vgel_kl: interface to Kanade-Lucas-Tomasi point tracker) contrib/brl/vvid (in vvid_file_manager & vvid_command_line_player) contrib/brl/bseg/vpro (vpro_roi_process, and possibly vpro_capture_process, vpro_basis_generator_process, vpro_half_res_process) and the three executables in contrib/brl/bexe/vded Could these be easily rewritten to use vidl instead? (Some, but *not all* of the code using vidl1 is conditionally compiled with #ifdef HAS_MPEG2; so I'm mainly worried about the parts outside such condition.) I've not checked indirect dependencies... -- Peter. -- ________________________________ Från: Chuck Atkins <chu...@ki...> Till: Vxl-maintainers <vxl...@li...> Skickat: onsdag, 7 december 2011 23:41 Ämne: [Vxl-maintainers] Status of VIDL1 In the spirit of forward progress, I'd like to raise the possibility of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 became vidl, thus deprecating vidl1. That was over 2 1/2 years ago now. Current development is in vidl and vidl1 is no longer maintained sans the occasional compiler bug fix for missing include files. There's also a dependency on the mpeg2 library which is GPL licensed. Are there any objections or even affirmations for the removal of the long since deprecated vidl1 and GPL licensed libmpeg2? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Chuck A. <chu...@ki...> - 2011-12-08 16:51:11
|
> > contrib/brl/vvid > contrib/brl/bseg/vpro > contrib/brl/bexe/vded > I assume since Joe is ok with the change then he's okay with how this will impact the BRL contrib folder. Joe, is that a safe assumption? I observe that in the current public vxl source code, there are direct > dependencies on vidl1 in the following three libraries: > contrib/gel/vgel (vgel_kl: interface to Kanade-Lucas-Tomasi point tracker) > This one I am less sure of. However, if it is being used the it would certainly benefit from being ported to vidl as it will then reap the benefits of any new file formats or video interfaces that get developed. > (Some, but *not all* of the code using vidl1 is conditionally compiled > with #ifdef HAS_MPEG2; so I'm mainly worried about the parts outside such > condition.) > I've not checked indirect dependencies... > From a code maintenance standpoint, removing the deprecated vidl1 is the focus. However, from a licensing standpoint, removing the dependency on the GPL'd libmpeg2 is in my opinion far more important. -- ------------------------------ *Från:* Chuck Atkins <chu...@ki...> *Till:* Vxl-maintainers <vxl...@li...> *Skickat:* onsdag, 7 december 2011 23:41 *Ämne:* [Vxl-maintainers] Status of VIDL1 In the spirit of forward progress, I'd like to raise the possibility of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 became vidl, thus deprecating vidl1. That was over 2 1/2 years ago now. Current development is in vidl and vidl1 is no longer maintained sans the occasional compiler bug fix for missing include files. There's also a dependency on the mpeg2 library which is GPL licensed. Are there any objections or even affirmations for the removal of the long since deprecated vidl1 and GPL licensed libmpeg2? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@ki...> - 2011-12-08 17:08:15
|
I'm also in favor of removing vidl1, as you might expect. In addition to Chucks comments on vidl1 lacking capability to handle modern video formats and interfaces, I'll also add that vidl1 is not a practical design for modern video processing. vidl1 requires an entire video sequence to be decoded and stored in memory before accessing the frames. This makes live/streaming video processing impossible, and makes processing anything but short or low resolution video clips impractical. This was the main reason for creating the new vidl. --Matt On Thu, 2011-12-08 at 11:50 -0500, Chuck Atkins wrote: > contrib/brl/vvid > > contrib/brl/bseg/vpro > > contrib/brl/bexe/vded > > > I assume since Joe is ok with the change then he's okay with how this > will impact the BRL contrib folder. Joe, is that a safe assumption? > > > I observe that in the current public vxl source code, there > are direct dependencies on vidl1 in the following three > libraries: > contrib/gel/vgel (vgel_kl: interface to Kanade-Lucas-Tomasi > point tracker) > > > > This one I am less sure of. However, if it is being used the it would > certainly benefit from being ported to vidl as it will then reap the > benefits of any new file formats or video interfaces that get > developed. > > > (Some, but *not all* of the code using vidl1 is conditionally > compiled with #ifdef HAS_MPEG2; so I'm mainly worried about > the parts outside such condition.) > > I've not checked indirect dependencies... > > > From a code maintenance standpoint, removing the deprecated vidl1 is > the focus. However, from a licensing standpoint, removing the > dependency on the GPL'd libmpeg2 is in my opinion far more important. > > > > -- > > ______________________________________________________________________ > Från: Chuck Atkins <chu...@ki...> > Till: Vxl-maintainers <vxl...@li...> > Skickat: onsdag, 7 december 2011 23:41 > Ämne: [Vxl-maintainers] Status of VIDL1 > > In the spirit of forward progress, I'd like to raise the possibility > of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 > became vidl, thus deprecating vidl1. That was over 2 1/2 years ago > now. Current development is in vidl and vidl1 is no longer maintained > sans the occasional compiler bug fix for missing include files. > There's also a dependency on the mpeg2 library which is GPL licensed. > > Are there any objections or even affirmations for the removal of the > long since deprecated vidl1 and GPL licensed libmpeg2? > > Chuck Atkins > R&D Engineer, Kitware, Inc. > (518) 371-3971 x603 > chu...@ki... > > -- "Mathematicians are tools for turning coffee grounds into > formulas.", Paul Erdos > > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and > point of > discussion for anyone considering optimizing the pricing and packaging > model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Joseph M. <mu...@le...> - 2011-12-08 17:57:43
|
Correct. From: Chuck Atkins [mailto:chu...@ki...] Sent: Thursday, December 08, 2011 11:50 AM To: Peter Vanroose Cc: Vxl-maintainers Subject: Re: [Vxl-maintainers] Status of VIDL1 contrib/brl/vvid contrib/brl/bseg/vpro contrib/brl/bexe/vded I assume since Joe is ok with the change then he's okay with how this will impact the BRL contrib folder. Joe, is that a safe assumption? I observe that in the current public vxl source code, there are direct dependencies on vidl1 in the following three libraries: contrib/gel/vgel (vgel_kl: interface to Kanade-Lucas-Tomasi point tracker) This one I am less sure of. However, if it is being used the it would certainly benefit from being ported to vidl as it will then reap the benefits of any new file formats or video interfaces that get developed. (Some, but *not all* of the code using vidl1 is conditionally compiled with #ifdef HAS_MPEG2; so I'm mainly worried about the parts outside such condition.) I've not checked indirect dependencies... From a code maintenance standpoint, removing the deprecated vidl1 is the focus. However, from a licensing standpoint, removing the dependency on the GPL'd libmpeg2 is in my opinion far more important. -- _____ Från: Chuck Atkins <chu...@ki...> Till: Vxl-maintainers <vxl...@li...> Skickat: onsdag, 7 december 2011 23:41 Ämne: [Vxl-maintainers] Status of VIDL1 In the spirit of forward progress, I'd like to raise the possibility of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 became vidl, thus deprecating vidl1. That was over 2 1/2 years ago now. Current development is in vidl and vidl1 is no longer maintained sans the occasional compiler bug fix for missing include files. There's also a dependency on the mpeg2 library which is GPL licensed. Are there any objections or even affirmations for the removal of the long since deprecated vidl1 and GPL licensed libmpeg2? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 <tel:%28518%29%20371-3971%20x603> chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos ---------------------------------------------------------------------------- -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Joseph M. <mu...@le...> - 2011-12-09 14:04:11
|
Chuck, I believe I have removed all dependencies on VIDL1 from brl. Joe From: Chuck Atkins [mailto:chu...@ki...] Sent: Wednesday, December 07, 2011 5:41 PM To: Vxl-maintainers Subject: [Vxl-maintainers] Status of VIDL1 In the spirit of forward progress, I'd like to raise the possibility of excising vidl1. On Mar. 22 2009, vidl became vidl1 and vidl2 became vidl, thus deprecating vidl1. That was over 2 1/2 years ago now. Current development is in vidl and vidl1 is no longer maintained sans the occasional compiler bug fix for missing include files. There's also a dependency on the mpeg2 library which is GPL licensed. Are there any objections or even affirmations for the removal of the long since deprecated vidl1 and GPL licensed libmpeg2? Chuck Atkins R&D Engineer, Kitware, Inc. (518) 371-3971 x603 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos |
From: Chuck A. <chu...@ki...> - 2011-12-09 15:20:30
|
On Fri, Dec 9, 2011 at 9:03 AM, Joseph Mundy <mu...@le...> wrote: > Chuck,**** > > I believe I have removed all dependencies on VIDL1 from brl.**** > > Joe**** > > ** > Great!. Feedback seems generally positive with few objects so I'll go ahead with this. The only outstanding piece is the vgel_kt code in gel, which can just be taken out of the CMakeList.txt for the time being until it's decided to either port or delete. However, following the general advice of "don't make commits that break things and then leave for the weekend", I'll wait until Monday to make the commit. |