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

Bill Lorensen bill.lorensen at gmail.com
Mon Jan 25 23:09:05 EST 2010


If we adopt a math library for internal use, we can hide the adopted
library's api's inside the vtk classes. People writing applications
can choose to use the math library outside of vtk if they wish.

For example, in ITK, we use the vnl numerics library from vxl. Many of
our optimizers use vnl optimization techniques, but the vnl api's are
not exposed to the itk user. This is similar to VTK's use of OpenGL,
libtiff, libpng, etc. We use the utility library inside VTK and do not
expose the utility API's.

Unfortunately, we did not hide vnl every place we use it in ITK.
Hopefully, VTK will not make the same mistake.

Bill

On Mon, Jan 25, 2010 at 9:33 PM, pat marion <pat.marion at kitware.com> wrote:
> Adopting a math library, one thing to consider is vtk's wrapped api.  If new
> data classes are used as public method arguments or return values they may
> or may not translate easily to vtk's wrapped languages, java, python, tcl.
>
> Devil's advocate- If something like Eigen is so easy to incorporate into a
> project, then why does vtk need to include it, why not leave it up to the
> application developer to choose their own math library?
>
> Pat
>
> On Mon, Jan 25, 2010 at 8:01 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> 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
>> >
>> _______________________________________________
>> 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
>
>
>



More information about the vtk-developers mailing list