[vtk-developers] Scope of VTK and it's potential as a common research language

Mon Jan 25 20:01:44 EST 2010

If we decide that Eigen is a good candidate for a vtk numerical
library, tehn perhaps we can convince them to convert to a truly open,
uncomplicated license like the vtk or apache license.

Bill

On Mon, Jan 25, 2010 at 5:49 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> http://eigen.tuxfamily.org/index.php?title=FAQ#Licensing - this should not be
> an issue. Benoit even asked the FSF about the position - the LGPL3 license
> makes provisions for templates etc. The only circumstance they felt it would
> be an issue is the normal one - where we changed the Eigen source code those
> changes must be contributed back/made available.
>
> I have worked with Benoit for many years, and am certain he would be open to
> answering any questions you might have. This license was chosen to ensure
> Eigen could be permissively used in both open and closed source applications.
>
> On Monday 25 January 2010 17:34:25 Bill Lorensen wrote:
>> I would be concerned about the lgpl license.
>>
>> On Mon, Jan 25, 2010 at 5:30 PM, Andrew Maclean
>>
>> <andrew.amaclean at gmail.com> wrote:
>> > Actually Eigen looks quite good. I wonder how much work would be
>> > needed to refactor VTK to use this?
>> >
>> >
>> > Andrew
>> >
>> > On Tue, Jan 26, 2010 at 1:55 AM, Biddiscombe, John A. <biddisco at cscs.ch>
> wrote:
>> >> To revisit this question :
>> >>
>> >> I'd like to see VTK adopt a decent vector+maths library under the hood,
>> >> a dependency on something like Eigen would not be a problem AFAIAC
>> >> (Especially if it was inside Utilities and compiled along with VTK). VTK
>> >> shouldn't reimplement these things, but should not introduce too many
>> >> hard to solve dependencies. Using Utilities/Mathlibrary-1,2,3 etc is not
>> >> a problem for me. There are many algorithms in VTK which mess round with
>> >> points and the code is not very readable. A decent vector/matric
>> >> template calss would make things much better.
>> >>
>> >> In an ideal world all things like boost would work out of the box with
>> >> cmake too and we could replace huge amounts of smartpointer stuff,
>> >> lists, and the rest with stl/boost objects.
>> >>
>> >> JB
>> >>
>> >>> -----Original Message-----
>> >>> From: vtk-developers-bounces at vtk.org
>> >>> [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Doria
>> >>> Sent: 11 January 2010 03:50
>> >>> To: VTK Developers
>> >>> Subject: [vtk-developers] Scope of VTK and it's potential as a common
>> >>> research language
>> >>>
>> >>> A recent discussion has raised, again, a point which has come up
>> >>> several times - that is, how much math should VTK include? I agree
>> >>> that it is very important to address. Here are my thoughts:
>> >>>
>> >>> Although VTK is a visualization toolkit, I believe it can and should
>> >>> act as much more than that. It serves as a common language for
>> >>> scientists and engineers to share code (clearly within reason -
>> >>> typically in the computer graphics/computer vision/image processing
>> >>> fields). This is critically important as technology continues to
>> >>> advance at an accelerating rate. While yes, we don't strive to provide
>> >>> a full mathematics toolbox, I believe we should not hesitate to
>> >>> provide things to make it easy for people to share code. If a few
>> >>> simple matrix multiples force someone to include yet another 3rd party
>> >>> library, it makes it significantly harder to give to a colleague. If
>> >>> one says "here is my code, you'll need VXL, VTK, ITK, LAPACK, Boost,
>> >>> etc. etc", that will discourage people from actually use the code, as
>> >>> they will likely have to spend a week getting it to compile and link.
>> >>> If one says "I have implemented all of my research as VTK filters",
>> >>> the next researcher can simply use it as a building block for the next
>> >>> year's research. I've never seen an actual survey, but I bet the
>> >>> *majority* of most students (and probably professional's, too) time is
>> >>> spent re-implementing things that have already been written at least
>> >>> once (probably hundreds of times) and should already be
>> >>> "plug-and-play". The problem is 100% that the code is not written in a
>> >>> form that is compatible with the next guy's code base. If we strive to
>> >>> setup an environment in which this problem is alleviated, it would be
>> >>> a massive step in the right direction for the success of all future
>> >>> scientists. The Insight/VTK journal's are already in place to then
>> >>> make this work in a common environment/language easy to share and
>> >>> find.
>> >>>
>> >>> That said, there is still clearly a line that needs to be drawn. We
>> >>> should probably not provide everything that is available in a
>> >>> mathematics package such as Maple. However, again, we shouldn't
>> >>> hesitate to provide things that are reasonably linked to the research
>> >>> fields that people who use VTK are involved with. If the logic is "VTK
>> >>> is only a visualization toolkit", then all of the readers and writers
>> >>> do not fit the description, which we all know to be critically useful.
>> >>> None of the mathematics functions should be exposed, which would make
>> >>> things much harder. My point is, we have already taken a giant step
>> >>> over the "only a visualization toolkit" line, so why restrain
>> >>> continued development in reasonable directions?
>> >>>
>> >>> I realize I'm the "new guy" to VTK, but I think this allows me to
>> >>> bring a nice perspective to the table. Being a current PhD student,
>> >>> I'm experiencing first hand the "state of the art" of code sharing
>> >>> and, frankly, it is failing miserably.
>> >>>
>> >>> I'd like to hear what some of you veteran VTK-ers and scientists think
>> >>> about this.
>> >>>
>> >>> David D.
>> >>> _______________________________________________
>> >>> Powered by www.kitware.com
>> >>>
>> >>> Visit other Kitware open-source projects at
>> >>> http://www.kitware.com/opensource/opensource.html
>> >>>
>> >>> Follow this link to subscribe/unsubscribe:
>> >>> http://www.vtk.org/mailman/listinfo/vtk-developers
>> >>
>> >> _______________________________________________
>> >> Powered by www.kitware.com
>> >>
>> >> Visit other Kitware open-source projects at
>> >> http://www.kitware.com/opensource/opensource.html
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://www.vtk.org/mailman/listinfo/vtk-developers
>> >
>> > --
>> > ___________________________________________
>> > Andrew J. P. Maclean
>> > Centre for Autonomous Systems
>> > The Rose Street Building J04
>> > The University of Sydney  2006  NSW
>> > AUSTRALIA
>> > Ph: +61 2 9351 3283
>> > Fax: +61 2 9351 7474
>> > URL: http://www.acfr.usyd.edu.au/
>> > ___________________________________________
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>>  http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>
> --
> Marcus D. Hanwell, Ph.D.
> R&D Engineer, Kitware Inc.
> (518) 881-4937
>