Mon, 6 Oct 2003 18:17:17 -0300
MJVR> I admit the options are intriguing, particularly given the number of
MJVR> linux clusters and computation grids being assembled (we have several
Exactly, i was talking about those technologies.
MJVR> will certainly address this issue. But if only a small community wants
MJVR> these types of capabilities, I fear the complexity involved will outweigh
MJVR> the benefit. This is not to say that is not going to happen. Just that
MJVR> we need to scope the cost/benefit.
I think that the cost isn't too high. We can reuse the experiencie
with VTK design. Both frameworks share the same architecture in a
global view, so some concepts can be reused.
MJVR> The developer community for ITK is larger (by construction) than the
MJVR> developer community for VTK. Also, the types of algorithms in ITK
MJVR> (for instance, segmentation algorithms) are more complicated than the
MJVR> algorithms in VTK. These issues drive us to keep things as simple as
MJVR> possible under the hood.
I'll give a try to sketch the changes to the pipeline to address these
issues. I'll share with you, and maybe some good can be done.
I think that MPI is good, and the basic principles of VTK can be
applied. Obviously without disturbing the way that ITK is used today.
MJVR> Note, however, that since one can mix VTK and ITK, it would be possible
MJVR> to used VTK's capability to bridge across a network to other cpus and still
MJVR> use ITK in the pipeline housed on each cpu.
Yeah, but the problem with this solution is the performance loss. I
think that this can be an excelente transient solution.
--
Best regards,
Sebastián mailto:sebasf@lncc.br
---
Visit SkullyDoo OpenSource project (3D image segmentation and visualization software) http://www.skullydoo.com.ar