[Ctk-developers] XDOM - decorator pattern
Paladini, Gianluca (SCR US)
gianluca.paladini at siemens.com
Wed Nov 11 16:24:25 EST 2009
A problem with ITK is the fact that its memory management is limited to
memory allocated on the heap. It does not accept the creation of images
and volumes based on pointers to existing data allocated elsewhere,
therefore it forces applications to copy data back and forth between
different libraries - an interoperability issue for CTK. It also assumes
memory to be contiguous, it doesn't support 3D datasets where each slice
has been allocated as separate buffers. In Siemens products, where
depending on the clinical application we may require to load a very
large number of datasets each with a very large number of slices, we use
a proprietary memory manager which allocates memory-mapped buffers and
can page in such buffers in/out of physical memory efficiently under low
memory conditions. We cannot use ITK in many use cases because the
system could potentially run out of physical memory and start thrashing
endlessly. No matter how much DRAM you put in a system, users will
always find a way to use all of it.
As long as we make CTK capable of accepting externally allocated data
buffer pointers in order to process images/volumes (we can use smart
pointers to avoid accessing null ones), and if we also introduce this
feature in our respective toolkits, then we will be able to pass around
image and volume data buffers between toolkits and 'wrap' them within
any class from any toolkit we choose to use, as well as use any external
memory management system we want.
- Gianluca
-----Original Message-----
From: ctk-developers-bounces at commontk.org
[mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper
Sent: Wednesday, November 11, 2009 4:03 PM
To: Stephen Aylward
Cc: Paul Desmedt; ctk-developers at commontk.org
Subject: Re: [Ctk-developers] XDOM - decorator pattern
Whew... that's a pretty broad new rule and not one I'm willing to buy
into without more discussion.
In particular, to throw some more red meat on the table:
* I would love to see a base set of object classes that are truly shared
among vtk, itk, and all other toolkits. The fact that vtk and itk are
so similar but different is a problem IMO.
* I vastly prefer the runtime polymorphic behavior of vtk data
structures (vtkPolyData, vtkImageData, etc) over their templated itk
analogs.
* Whatever programming system we adopt should be as widely used as
possible through CTK and it should support things like wrapping really
well. Traditionally I've liked vtk's wrapping over itk's, but Qt +
PySide has the potential to be even better. Also I think Qt's signals
and slots or much better than the vtk or itk events.
At various time we have said we don't want to reinvent the wheel with
'yet another object system' so in spirit I agree with Stephen - in
practice I'm not convinced that itk's object system is the logical
choice.
-Steve
Stephen Aylward wrote:
> Hi Marco,
>
> I was a bit short on time and details with my last email. Sorry.
>
> You raise an interesting point. Should (or could?) some of our
> primary data structures derive from Qt data structures. I don't think
> this is a good idea.
>
> Given that we have (a) images and objects, (b) image/object processing
> algorithms, (c) visualization algorithms, and (d) optional GUI
> components in CTK, I suggest we add the following rule:
>
> NEW RULE: When images, objects, and data structures (e.g., vectors)
> are exposed on an API that MAY be called by image/object algorithms or
> by visualization algorithms, those exposed images, objects, and data
> structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector).
>
> What this means:
>
> a) Image/Object processing algorithms' inputs and outputs should be
> ITK data objects.
>
> b) Inputs to visualization algorithms should be ITK data objects.
> Outputs of visualization algorithms can be non-ITK (e.g., VTK,
> OpenInventor, ...) - assuming that they are passed directly to a GUI
> (i.e., not used by image/object processing algorithms and not used by
> other visualization algorithms). You cannot chain visualization
> algorithms together, unless they are passing only ITK objects.
>
> c) Qt should never be exposed by Image/Object processing algorithms or
> visualization algorithms.
>
> d) Use itk::Vector and NOT std::vector to represent mathematical
vectors.
>
> e) Use itk::Array instead of std::list or std::vector.
>
> I know this is open to debate...so let's hear it....
>
> :)
>
> s
>
> On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti
<viceconti at tecno.ior.it> wrote:
>> Sorry I missed this point.
>>
>> Ok, I trust the group on this decision. By the way this also clear a
>> similar decision we are now taking inside MAF3 on whether to use
QtObject.
>>
>> I presume that no one disagree with the second statement in my email:
>> "Even if we agree [to use Qt core], would not be better to ensure
>> that CTK is not ridden of Qt code, and find solutions such as the
>> wrapping of the QtObject class into a CTK Class?
>>
>> thanks Stephen.
>>
>> Marco
>>
>>
>>
>> Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto:
>>
>>> 1) QtCore will supply system-level functions. "If a function we
need
>>> exists in Qt, then we should use it"
>>>
>>> 2) QtGUI is optional
>>>
>>> It was more clearly stated in out meeting notes:
>>> http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009
>>> See the section called "Technical Aspects."
>>>
>>> s
>>>
>>> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti
>>> <viceconti at tecno.ior.it>
>>> wrote:
>>>> Worth to be said because when we agreed to use Qt, I am sure most
>>>> of us were thinking of the GUI, and not of a class from which every
>>>> other class in the framework would inherit.
>>>>
>>>> So before we carry on, at the cost of being pedantic, let me pose
>>>> this question to the whole CTK group:
>>>>
>>>> Qt provide a portable GUI framework, that we agreed to adopt in
CTK.
>>>>
>>>> But it also provides some interesting low-level mechanisms, in
>>>> particular a extensive multi-threading library and inter-object
>>>> communication mechanism.
>>>> Do we all agree that also this part of Qt can be used to build
CTK?
>>>>
>>>> Even if we agree, would not be better to ensure that CTK is not
>>>> ridden of Qt code, and find solutions such as the wrapping of the
>>>> QtObject class into a CTK Class?
>>>>
>>>> Cheers
>>>>
>>>> Marco
>>>>
>>>>
>>>>
>>>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto:
>>>>
>>>>> Marco Viceconti wrote:
>>>>>> I suspect that the mechanism our colleagues in INRIA described at
>>>>>> the CTK meeting in Oxford is strongly based on the ability of
>>>>>> QTObjects and derivative to exchange messages, making simple and
>>>>>> efficient the use of message-passing mechanisms. This however
>>>>>> creates a strong dependency onto QT, which we might want to
>>>>>> discourage in CTK (we should remember QT already changed license
>>>>>> model 2 times :-) ).
>>>>>>
>>>>>>
>>>>> Dear Marco,
>>>>>
>>>>> at the first CTK meeting in Heidelberg we agreed on using Qt in
>>>>> CTK, since everyone is already using it. This does not necessarily
>>>>> include the Qt GUI classes, but the Qt Core module which offers
>>>>> the message-passing mechanisms.
>>>>> Of course such a strong dependency should always be discussed, but
>>>>> I'm not afraid of any licensing changes anymore.
>>>>>
>>>>> Regards
>>>>>
>>>>> Marco (the other one)
>>>>>
>>>>> --
>>>>>
----------------------------------------------------------------------
>>>>> Dipl.-Inform. Med. Marco Nolden
>>>>> Deutsches Krebsforschungszentrum (German Cancer Research
Center)
>>>>> Div. Medical & Biological Informatics Tel: (+49) 6221-42
2325
>>>>> Im Neuenheimer Feld 280 Fax: (+49) 6221-42
2345
>>>>> D-69120 Heidelberg eMail:
M.Nolden at dkfz.de
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --------------------------------------------------
>>>> MARCO VICECONTI, PhD
(viceconti at tecno.ior.it)
>>>> Laboratorio di Tecnologia Medica tel. 39-051-6366865
>>>> Istituto Ortopedico Rizzoli fax.
>>>> 39-051-6366863
>>>> via di Barbiano 1/10, 40136 - Bologna, Italy
>>>>
>>>> Tiger! Tiger! Burning bright in the forest of the night,
>>>> what immortal hand or eye could frame thy fearful symmetry?
>>>> --------------------------------------------------
>>>> Opinions expressed here do not necessarily reflect those of my
employer
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ctk-developers mailing list
>>>> Ctk-developers at commontk.org
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>>>
>>>
>>>
>>> --
>>> Stephen R. Aylward, Ph.D.
>>> Director of Medical Imaging Research
>>> Kitware, Inc. - North Carolina Office
>>> http://www.kitware.com
>>> stephen.aylward (Skype)
>>> (919) 969-6990 x300
>>>
>> --------------------------------------------------
>> MARCO VICECONTI, PhD
(viceconti at tecno.ior.it)
>> Laboratorio di Tecnologia Medica tel. 39-051-6366865
>> Istituto Ortopedico Rizzoli fax.
39-051-6366863
>> via di Barbiano 1/10, 40136 - Bologna, Italy
>>
>> Tiger! Tiger! Burning bright in the forest of the night,
>> what immortal hand or eye could frame thy fearful symmetry?
>> --------------------------------------------------
>> Opinions expressed here do not necessarily reflect those of my
employer
>>
>>
>>
>>
>
>
>
_______________________________________________
Ctk-developers mailing list
Ctk-developers at commontk.org
http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
More information about the Ctk-developers
mailing list