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
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 <chuck.atkins@kitware.com>
Till: Vxl-maintainers <vxl-maintainers@lists.sourceforge.net>
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

-- "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!
Vxl-maintainers mailing list