[vtkusers] A general advice for design stage of a new project

Cory Quammen cquammen at cs.unc.edu
Tue Jun 11 23:25:08 EDT 2013


I am currently working on a "from scratch" project with ITK/VTK and
one based on ParaView, so I have some views on the pros and cons of
going each route.

Benefits of using an existing ITK/VTK framework such as 3D Slicer or ParaView:

- You get a lot of things for free. Various types of data loading,
pre-existing visualization methods, ways to query the data, etc., are
already done for you, potentially saving you a lot of time. If you
start from scratch, you have to do everything yourself.

- A lot of things you might want to do to extend the framework are
easy. Adding a custom filter or one not exposed by the existing
framework can be quite simple in ParaView, 3D Slicer, and probably the
other systems Julien mentioned. The steps to add a custom filter in
these two frameworks are well documented and you can probably add your
first filter in a day or less of developer time. If you can implement
your application as a set of plugins for, say, 3D Slicer, you might be
very happy going that route. To get the same level of functionality
when starting from scratch might take weeks depending on how much
infrastructure code you have to write.

- There is an existing community of people often willing to help you
with the framework and with reaching your goals. While there is a
community for ITK and VTK, there is no community for your "from
scratch" project, other than your colleagues working on the same
project.

Drawbacks of using existing ITK/VTK frameworks:

- In addition to the learning curve for ITK/VTK, there is a learning
curve for these frameworks. In some cases, things are easy. But if you
want to do something that deviates from the standard use cases
envisioned by the framework, you can be in for some real difficulty.
You may even find that you need to modify the internal workings of the
framework to make it handle your particular use case; this can be very
difficult. You can always request the needed functionality from the
primary developers of the toolkit, but unless you can pay them, it may
be a long time if ever that this functionality gets into the framework
unless you do it yourself. Even then, the primary developers need to
accept your changes. If you do modify the framework to this extent,
you will likely have become a primary developer of the framework,
which you might not have ever intended to be. With a "from scratch"
project, you are totally free to implement whatever you need without
figuring out how to work within the constraints of the framework
(though you will eventually have constraints within your project as it
matures).

- Vulnerability to backwards incompatibility in future versions of the
framework. This is a biggie, and some frameworks are better than
others when it comes to worrying about backwards compatibility and how
breaking it affects their customers. When your applications makes use
of a framework, you are vulnerable to changes that will break your
application. Hopefully, the framework won't change it's public API
much and you will be okay. But if you need to do some advanced stuff
that uses framework internals, you could be in for a world of hurt
when the framework developers decide to refactor the internal code. If
you are lucky, the changes you need to make to your application code
are minimal. If you are unlucky, you may need to completely redo a
feature you had working in a previous version of the framework. You
can mitigate this somewhat by sticking with one version of the
framework, but then you give up bug fixes and new features in future
versions of the framework. A "from scratch" project largely insulates
you from this problem.

- You might not like the framework's user interface, or your customers
may specify a user interface that turns out to be incredibly difficult
to achieve within the framework you chose. In a "from scratch"
project, you are free to do whatever you want with the interface.

I hope that helps,
Cory

On Tue, Jun 11, 2013 at 11:28 AM, Julien Finet <julien.finet at kitware.com> wrote:
> Hi,
>
> An advice would be:
>   do not start your project from scratch (except if you intend to use a new
> (revolutionary) technology).
>
> There are many opensource (BSD like ) ITK and VTK based frameworks you can
> start from. The most popular/advanced allow you to extend them and sometimes
> to customize and redesign the entire front end GUI while reusing the
> internals.
>
> Here are some of those ITK/VTK frameworks: 3D Slicer, ParaView, VolView,
> MITK, GIMIAS, MAF...
>
> Each framework has pros and cons, you probably need to review each of them
> (and/or contact their mailing lists) to find the one that is closest to you
> needs. You can also use http://www.ohloh.net to see how advanced, popular
> and active each project is.
>
> Note also the resourceful webinar:  Building Qt-enabled VTK applications
>
> Hth,
> Julien.
>
>
>
> On Tue, Jun 11, 2013 at 10:55 AM, chasank <chasank at gmail.com> wrote:
>>
>> Hi,
>>
>> This question is a bit abstract (actually completely), so please bear with
>> us. We have been using VTK/ITK for 3 months. We will begin to implement a
>> big medical project, and now we are at the design stage (writing use
>> cases,
>> designing UML diagrams, etc). However, because of lack of experience in
>> VTK/ITK project, we cannot foresee what classes we will need to use in our
>> project. Which precautions do we need to take so that we will not have to
>> change initial design dramatically?
>>
>> For example, in one of our former projects we coded a small medical
>> application which allows users to display dicom/nifti image data for
>> 3-planes (sagittal, coronal, axial) and to select a dynamic roi with seed
>> region grow filter. But after that, we needed to add oblique slicing
>> feature
>> to this project and we had to code from scratch. We do not want to have
>> this
>> struggle in the future again. Do you have any advice for us based on your
>> precious experiences?
>>
>>
>>
>> --
>> View this message in context:
>> http://vtk.1045678.n5.nabble.com/A-general-advice-for-design-stage-of-a-new-project-tp5721320.html
>> Sent from the VTK - Users mailing list archive at Nabble.com.
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>



-- 
Cory Quammen
Research Associate
Department of Computer Science
The University of North Carolina at Chapel Hill



More information about the vtkusers mailing list