[Ctk-developers] XDOM - decorator pattern
Stephen Aylward
stephen.aylward at kitware.com
Thu Nov 12 10:46:37 EST 2009
Steve, Gianluca, and Marco all raise excellent points.
The three issues appear to be communication (mentioned by Steve and
Marco), wrapping (Steve) and memory management (Gianluca and Marco).
1) Regarding Memory Management, ITK has an extensible Memory
Management Model (MMM). While the itkImage implements a particular
MMM (contiguous, etc), all of the methods access its data via
iterators and calls to GetPixel. We specifically check for this.
As a result, it is possible to use different MMM in ITK. We have
streaming readers and writers. Our filters access data through an
abstraction. The region request mechanism can be extended.
I've CC'd Luis Ibanez. He can provide more insight.
I am pushing this with ITK because if we can use ITK's MMM or fix it,
then we benefit a much broader community and we can still make full
use of ITK compared to if we try to develop something independently.
2) Regarding wrapping. this is a problem. ITKv4 should fix this,
BUT I never believe such promises until they happen (particularly when
I am making those promises to myself :) ). We could build our own
typeless layer on top of ITK for wrapping. This layer could be the
QtImage class, for example. Or use the XDOM Marco is proposing.
3) Regarding communications - this is constantly a battle. ITK, VTK,
and Qt have different levels of incompatibility. Perhaps we create a
typeless layer for our data and algorithms using Qt's comm mechanism.
I like Marco's emphasis on modularization of the design pattern.
Much work is needed here.
s
On Thu, Nov 12, 2009 at 5:07 AM, Marco Viceconti <viceconti at tecno.ior.it> wrote:
> Dear Stephen:
> there is nothing better that an a provocative statement to spark
> discussion, which then let emerge very interesting points such as those made
> by Piper and Paladini. Bravo.
>
> But ....
>
> a) if we agree to design CTK using the memory management and the
> inter-object communication provided by Qt, if I am not wrong this means that
> ALL CTK objects will have to be derived by QtObject of by a CtkObject that
> wraps it, not only the data objects. So the decision is much broader than
> this. For example one aspect that in my opinion would be worth another
> discussion thread where the more tech people (Paolo and Daniele on my side)
> start to say something is: given Gianluca point on memory management (with
> which I agree 100%) is the memory management mechanism (MMM) provided by
> QtObject sufficient for CTK? If not, does it prevents of make more
> difficult the development of more sophisticated MMM such as those described
> by Gianluca to dynamically manage objects out-of-core? another aspect: how
> do we ensure that if every object can send a message to any other object
> after a while CTK code does not become a jungle which no one can really
> debug? In MAF3 we plan to use a very strong encapsulation between modules,
> and explicitly prevent that two objects residing inside to separate modules
> can start to exchange messages directly. Is this a good architectural
> decision, we could consider also for CTK?
>
> b) the discussion in Oxford made very clear that the biggest problem we
> share is the lack of extensibility, completeness, and efficacy in the ALL
> the data object models we use in ALL our codes. All we have done with
> respect to data models fall short to some extend, all except maybe something
> in MedInria in not design to be extensible at run time, which prevents
> programmers to add data types as plugins. Around the idea of developing an
> extensible data object model (XDOM) revolves the proposal we are putting
> together on the EU side, under the coordination of the INRIA team. So a
> more realistic scenario is that we:
> i) discuss in depth what is wrong with each of the currently available data
> object models (which is already happening in this thread)
> ii) develop an XDOM component for CTK
> iii) adopt it in the next version of our respective products, including ITK
> and VTK (well this may take a while, but you got the idea).
>
> Cheers
>
> Marco
>
>
>
>
>
> Il giorno 11 Nov 2009, alle ore 16:49, Stephen Aylward ha scritto:
>
>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
>
>
>
>
--
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
More information about the Ctk-developers
mailing list