From viceconti at tecno.ior.it Thu Aug 6 10:34:56 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Thu, 6 Aug 2009 19:34:56 +0900 Subject: [Ctk-developers] CTK and MAF3 In-Reply-To: <004f01ca12f4$8808aab0$981a0010$@georgetown.edu> References: <9D19B08C681FF6439739C9AE77CE1953E55A30@dkfzex1.ad.dkfz-heidelberg.de> <9D19B08C681FF6439739C9AE77CE195301248608@dkfzex1.ad.dkfz-heidelberg.de> <049CF705-ECCB-4A7B-B9B8-1DF5EB52DD2F@tecno.ior.it> <9D19B08C681FF6439739C9AE77CE195301248671@dkfzex1.ad.dkfz-heidelberg.de> <4A635D1F.8080403@dclunie.com> <9D19B08C681FF6439739C9AE77CE1953012486F8@dkfzex1.ad.dkfz-heidelberg.de> <004f01ca12f4$8808aab0$981a0010$@georgetown.edu> Message-ID: <688DEDBF-279A-4887-9753-254D43A0CE51@tecno.ior.it> Dear all: seems we are not yet sing the ctk-developers mailing list. Since I am not sure who is on it, I post to both the list and the direct addresses. If you are on both, sorry for cross-posting. If we are all on it, we should start to use it exclusively, so we also have an archive of our messages. ***** The general idea of CTK is very exciting. However, its timing is somehow odd for us. while CTK is starting its first steps now, we are well deep into the architectural design of the next major revision of MAF, and we are starting its development. From the past, we do these big changes every four years of so, so the timing is a bit off-beat. But if we see the problem from another side, maybe this is not so bad. MAF3 will be highly modular; this means that some MAF3 modules could be simply re-used into CTK, at least in principle. This could boost CTK, because we are starting to work right now, so some solid things could be already available Q1 2010. Of course if one or more MAF modules are candidate as concrete implementation for into CTK, we should need to revise our internal designs plans with the whole CTK panel, and agree on who does what (we are ready to take 100% load for these modules, but there might be a strategic opportunity to distribute the effort). So for us it would be important to know soon if any part of MAF is considered interesting for potential inclusion into the first version of CTK. To the purpose I wrote with Paolo a short document that describes MAF3 architecture, at least as we imagine today (implementation might change a few things here and there :-) ). I am not sure how we should proceed, but for now I would ask you to take a look to this document when you have a minute, and if you see something that fancy you, write it on the list. Please understand we are not trying to push our agenda. In our vision CTK is a strategic element of MAF4; however, if there is an opportunity to leverage on the big development effort we plan to undertake in the next few months, it is worth consider this, I guess. Best regards -------------- next part -------------- A non-text attachment was scrubbed... Name: maf3_architecture_v1.pdf Type: application/pdf Size: 434245 bytes Desc: not available URL: -------------- next part -------------- -------------------------------------------------- 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 From stephen.aylward at kitware.com Wed Aug 12 18:56:24 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Wed, 12 Aug 2009 14:56:24 -0400 Subject: [Ctk-developers] CTK and MAF3: hotels in London In-Reply-To: References: <9D19B08C681FF6439739C9AE77CE19530124873C@dkfzex1.ad.dkfz-heidelberg.de> Message-ID: <68a07c2d0908121156r536f3b66n50db6a9d7bf3dcb1@mail.gmail.com> On Mon, Aug 10, 2009 at 7:20 AM, Kevin Cleary wrote: > As for the meeting location, I am not against going to Oxford since I have > never been there, so perhaps the best thing to do is take a vote > > Kevin I follow Kevin's logic...I've never been to Oxford, and I'd enjoy seeing it. My vote is for Oxford, but I am willing to me at either location. Thanks, Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From pieper at bwh.harvard.edu Fri Aug 14 12:46:20 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Fri, 14 Aug 2009 08:46:20 -0400 Subject: [Ctk-developers] CTK and MAF3: hotels in London In-Reply-To: <9D19B08C681FF6439739C9AE77CE195301248766@dkfzex1.ad.dkfz-heidelberg.de> References: <9D19B08C681FF6439739C9AE77CE19530124873C@dkfzex1.ad.dkfz-heidelberg.de> <68a07c2d0908121156r536f3b66n50db6a9d7bf3dcb1@mail.gmail.com> <9D19B08C681FF6439739C9AE77CE195301248766@dkfzex1.ad.dkfz-heidelberg.de> Message-ID: <4A855C9C.9080309@bwh.harvard.edu> I agree with Peter - I need to start making travel plans soon... Thanks, Steve p.s. Peter - if all else fails you and I will pick a pub! Meinzer Hans-Peter wrote: > Dear Friends of CTK, > > I dislike what I see coming up. There are two options: > 1- Oxford, no details available from Gianluca. > 2- London, no details available from Kevin. > I suggest we accept the first offer with a precise location and time. > > Also, for those NOT attending MICCAI, which is the majority, we need a suggestion of a hotel CLOSE BY, preferably with some local travel advise. As London is big a place, things might be easier in a small village. > > best wishes > Peter Meinzer > > > > > Hans-Peter Meinzer > Prof. Dr. sc.hum.habil. > Head of Department 'Medical and Biological Informatics' > German Cancer Research Center > Im Neuenheimer Feld 280 > 69120 Heidelberg > > +49-6221-422366 office > +49-6221-422345 fax > +49-171-2655356 mobile > > H.P.Meinzer at dkfz.de > > ________________________________ > > Von: Stephen Aylward [mailto:stephen.aylward at kitware.com] > Gesendet: Mi 12.8.2009 20:56 > An: Kevin Cleary > Cc: Meinzer Hans-Peter; Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; Kevin Cleary; Nicholas Ayache; Ron Kikinis; Andreas Engelke; Nolden Marco; Wolf Ivo; Sauer, Frank (SCR US); Gianluca US) Paladini (SCR; Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Lawrence Tarbox; Engelmann Uwe > Betreff: Re: AW: CTK and MAF3: hotels in London > > > > On Mon, Aug 10, 2009 at 7:20 AM, Kevin Cleary wrote: >> As for the meeting location, I am not against going to Oxford since I have >> never been there, so perhaps the best thing to do is take a vote >> >> Kevin > > I follow Kevin's logic...I've never been to Oxford, and I'd enjoy seeing it. > > My vote is for Oxford, but I am willing to me at either location. > > Thanks, > Stephen > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > > From tarboxl at mir.wustl.edu Fri Aug 14 13:25:13 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Fri, 14 Aug 2009 08:25:13 -0500 Subject: [Ctk-developers] CTK and MAF3: hotels in London In-Reply-To: <68a07c2d0908121156r536f3b66n50db6a9d7bf3dcb1@mail.gmail.com> References: <9D19B08C681FF6439739C9AE77CE19530124873C@dkfzex1.ad.dkfz-heidelberg.de> <68a07c2d0908121156r536f3b66n50db6a9d7bf3dcb1@mail.gmail.com> Message-ID: <67B4B5166383D848A0565AA7491841F9150DF941@RAD-VMSRVEXV2.rad.wustl.edu> Ditto. Oxford would be new to me, so I have a slight preference for Oxford. But I do not object to either location. Lawrence -----Original Message----- From: Stephen Aylward [mailto:stephen.aylward at kitware.com] Sent: Wednesday, August 12, 2009 1:56 PM To: Kevin Cleary Cc: Meinzer Hans-Peter; Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; Kevin Cleary; Nicholas Ayache; Ron Kikinis; Andreas Engelke; Nolden Marco; Wolf Ivo; Sauer, Frank (SCR US); Gianluca US) Paladini (SCR; Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Tarbox, Lawrence; Engelmann Uwe Subject: Re: AW: CTK and MAF3: hotels in London On Mon, Aug 10, 2009 at 7:20 AM, Kevin Cleary wrote: > As for the meeting location, I am not against going to Oxford since I have > never been there, so perhaps the best thing to do is take a vote > > Kevin I follow Kevin's logic...I've never been to Oxford, and I'd enjoy seeing it. My vote is for Oxford, but I am willing to me at either location. Thanks, Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From pieper at bwh.harvard.edu Fri Aug 14 14:42:41 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Fri, 14 Aug 2009 10:42:41 -0400 Subject: [Ctk-developers] updated mailing list Message-ID: <4A8577E1.9010401@bwh.harvard.edu> Hi - I took the liberty of subscribing everyone who has been cc'd on the recent emails to the ctk-developers at commontk.org mailing list if they weren't already subscribed (current member list below). You can always check the subscriber list, subscribe new people, opt out, etc at this site: http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers (Also - don't forget that the archives are publicly readable - so no patient info, trade secrets, or embarrassing admissions on the list!) -Steve http://public.kitware.com/cgi-bin/mailman/roster/ctk-developers * andreas.engelke at dfg.de * christian.renner at dfg.de * cleary at georgetown.edu * dclunie at dclunie.com * eichelberg at offis.de * gianluca.paladini at siemens.com * h.p.meinzer at dkfz.de * i.wolf at dkfz-heidelberg.de * j.dunning at dkfz-heidelberg.de * julien.finet at kitware.com * jwintz at sophia.inria.fr * kikinis at bwh.harvard.edu * m.nolden at dkfz-heidelberg.de * nicholas.ayache at inria.fr * olivier.clatz at sophia.inria.fr * p.quadrani at scsolutions.it * pieper at bwh.harvard.edu * sauer.frank at siemens.com * sebastien.barre.ml at gmail.com * stefanie.hauser at dkfz-heidelberg.de * stephen.aylward at kitware.com * tarboxl at mir.wustl.edu * u.engelmann at dkfz-heidelberg.de * viceconti at tecno.ior.it From gianluca.paladini at siemens.com Fri Aug 14 18:36:02 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Fri, 14 Aug 2009 11:36:02 -0700 Subject: [Ctk-developers] CTK and MAF3: hotels in London In-Reply-To: <9D19B08C681FF6439739C9AE77CE195301248766@dkfzex1.ad.dkfz-heidelberg.de> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709D17DAD@USNWK100MSX.ww017.siemens.net> Hello all, We do have a meeting room in Oxford reserved for the 25th, and in fact we could have the room for the 26th as well if necessary - see email below from Jerome, he is director of R&D at Siemens Molecular Imaging. I am in touch with his secretary, Charlotte, who can assist with travel arrangements. It is nice to have a point of contact in the UK that can help. As I indicated in an email on 7/22, Siemens Molecular Imaging is at this location: 23-38 Hythe Bridge St, Oxford, Oxfordshire, OX1 2EP, United Kingdom 01865 28502. http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Siemens+Mole cular+Imaging,+23-38+Hythe+Bridge+St.,+Oxfordshire,+OX1+2EP,+Oxford,+Uni ted+Kingdom&sll=37.0625,-95.677068&sspn=78.056642,54.580078&ie=UTF8&ll=5 1.753244,-1.266561&spn=0.007731,0.009023&z=17&iwloc=A I think the debate about choosing between London and Oxford has stalled our travel plans, and now we are running out of time. If you could kindly let me know who plans on attending I can at least have Charlotte look into hotel availability in Oxford and make lunch/dinner arrangements. How many people plan to attend? Cordially, Gianluca ------------------------------------------------------------------------ -------- From: DECLERCK, JEROME Sent: Thursday, July 23, 2009 1:38 PM To: Paladini, Gianluca (SCR US) Cc: FENTON, CHARLOTTE RE: CTK meeting in Oxford Hi Gianluca, I managed to organize for you to be able to use the room for 2 days if you need to, thanks to Charlotte, who has kindly accepted to come on a Saturday. She would also be the point of contact should you need to organize hotels, etc. Best regards, Jerome -----Original Message----- From: Meinzer Hans-Peter [mailto:h.p.meinzer at dkfz-heidelberg.de] Sent: Friday, August 14, 2009 7:23 AM To: Stephen Aylward; Kevin Cleary Cc: Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; Kevin Cleary; Nicholas Ayache; Ron Kikinis; Andreas Engelke; Nolden Marco; Wolf Ivo; Sauer, Frank (SCR US); Paladini, Gianluca (SCR US); Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Lawrence Tarbox; Engelmann Uwe Subject: AW: AW: CTK and MAF3: hotels in London Dear Friends of CTK, I dislike what I see coming up. There are two options: 1- Oxford, no details available from Gianluca. 2- London, no details available from Kevin. I suggest we accept the first offer with a precise location and time. Also, for those NOT attending MICCAI, which is the majority, we need a suggestion of a hotel CLOSE BY, preferably with some local travel advise. As London is big a place, things might be easier in a small village. best wishes Peter Meinzer Hans-Peter Meinzer Prof. Dr. sc.hum.habil. Head of Department 'Medical and Biological Informatics' German Cancer Research Center Im Neuenheimer Feld 280 69120 Heidelberg +49-6221-422366 office +49-6221-422345 fax +49-171-2655356 mobile H.P.Meinzer at dkfz.de ________________________________ Von: Stephen Aylward [mailto:stephen.aylward at kitware.com] Gesendet: Mi 12.8.2009 20:56 An: Kevin Cleary Cc: Meinzer Hans-Peter; Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; Kevin Cleary; Nicholas Ayache; Ron Kikinis; Andreas Engelke; Nolden Marco; Wolf Ivo; Sauer, Frank (SCR US); Gianluca US) Paladini (SCR; Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Lawrence Tarbox; Engelmann Uwe Betreff: Re: AW: CTK and MAF3: hotels in London On Mon, Aug 10, 2009 at 7:20 AM, Kevin Cleary wrote: > As for the meeting location, I am not against going to Oxford since I > have never been there, so perhaps the best thing to do is take a vote > > Kevin I follow Kevin's logic...I've never been to Oxford, and I'd enjoy seeing it. My vote is for Oxford, but I am willing to me at either location. Thanks, Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From kikinis at bwh.harvard.edu Sat Aug 15 13:41:08 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Sat, 15 Aug 2009 09:41:08 -0400 Subject: [Ctk-developers] meeting in Oxford In-Reply-To: <9D19B08C681FF6439739C9AE77CE19530124876A@dkfzex1.ad.dkfz-heidelberg.de> References: <9D19B08C681FF6439739C9AE77CE19530124873C@dkfzex1.ad.dkfz-heidelberg.de> <68a07c2d0908121156r536f3b66n50db6a9d7bf3dcb1@mail.gmail.com> <9D19B08C681FF6439739C9AE77CE195301248766@dkfzex1.ad.dkfz-heidelberg.de> <4A855C9C.9080309@bwh.harvard.edu> <9D19B08C681FF6439739C9AE77CE19530124876A@dkfzex1.ad.dkfz-heidelberg.de> Message-ID: <4A86BAF4.7080207@bwh.harvard.edu> Misunderstanding. London or Oxford, gehupft wie gesprungen... Meinzer Hans-Peter wrote: > Dear Friends of CTK, dear Gianluca, > > summarizing all comments on meeting location preferences: the winner is Oxford. Only one vote for London (Ron). MANY votes for Oxford. > Therefore let us please meet in Oxford. > > Everybody is asked to tell Gianluca and Charlotte (hello Charlotte, please help us) to find the number of attendees and care for food etc. > Gianluca, please get us 3 beds for Ivo, Marco and myself. > > Having done this I will return to paint my garden shed in swedish red color (Falun rod) with white window frames. > Steve, do you have OFFIS in your list dicom at offis.de > The list above is complete????? > > Best wishes from sunny Odenwald. > > Peter Meinzer > > > > > > Hans-Peter Meinzer > Prof. Dr. sc.hum.habil. > Head of Department 'Medical and Biological Informatics' > German Cancer Research Center > Im Neuenheimer Feld 280 > 69120 Heidelberg > > +49-6221-422366 office > +49-6221-422345 fax > +49-171-2655356 mobile > > H.P.Meinzer at dkfz.de > > ________________________________ > > Von: Paladini, Gianluca (SCR US) [mailto:gianluca.paladini at siemens.com] > Gesendet: Fr 14.8.2009 20:36 > An: Meinzer Hans-Peter; Stephen Aylward; Kevin Cleary > Cc: Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; Kevin Cleary; Nicholas Ayache; Ron Kikinis; Andreas Engelke; Nolden Marco; Wolf Ivo; Sauer, Frank (SCR US); Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Lawrence Tarbox; Engelmann Uwe > Betreff: RE: AW: CTK and MAF3: hotels in London > > > > Hello all, > > We do have a meeting room in Oxford reserved for the 25th, and in fact > we could have the room for the 26th as well if necessary - see email > below from Jerome, he is director of R&D at Siemens Molecular Imaging. I > am in touch with his secretary, Charlotte, who can assist with travel > arrangements. It is nice to have a point of contact in the UK that can > help. > > As I indicated in an email on 7/22, Siemens Molecular Imaging is at this > location: > 23-38 Hythe Bridge St, Oxford, Oxfordshire, OX1 2EP, United Kingdom > 01865 28502. > > http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Siemens+Mole > cular+Imaging,+23-38+Hythe+Bridge+St.,+Oxfordshire,+OX1+2EP,+Oxford,+Uni > ted+Kingdom&sll=37.0625,-95.677068&sspn=78.056642,54.580078&ie=UTF8&ll=5 > 1.753244,-1.266561&spn=0.007731,0.009023&z=17&iwloc=A > > I think the debate about choosing between London and Oxford has stalled > our travel plans, and now we are running out of time. If you could > kindly let me know who plans on attending I can at least have Charlotte > look into hotel availability in Oxford and make lunch/dinner > arrangements. > > How many people plan to attend? > Cordially, > Gianluca > > > -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From viceconti at tecno.ior.it Mon Aug 17 05:37:34 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Mon, 17 Aug 2009 07:37:34 +0200 Subject: [Ctk-developers] CTK and MAF3: hotels in London In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC709D17DAD@USNWK100MSX.ww017.siemens.net> References: <849860E57EBCC34C9E28B6E59A046CC709D17DAD@USNWK100MSX.ww017.siemens.net> Message-ID: <8CFDA215-3F1D-4536-A0A0-CF28B5CBDED0@tecno.ior.it> Dear Gianluca, please count me in. I am still waiting for the confirmation of a MICCAI tutorial the day before, so I still cannot make firm travel plans, but please count me for sure for the 25th lunch. Cheers Marco Il giorno 14/ago/09, alle ore 20:36, Paladini, Gianluca (SCR US) ha scritto: > Hello all, > > We do have a meeting room in Oxford reserved for the 25th, and in fact > we could have the room for the 26th as well if necessary - see email > below from Jerome, he is director of R&D at Siemens Molecular > Imaging. I > am in touch with his secretary, Charlotte, who can assist with travel > arrangements. It is nice to have a point of contact in the UK that can > help. > > As I indicated in an email on 7/22, Siemens Molecular Imaging is at > this > location: > 23-38 Hythe Bridge St, Oxford, Oxfordshire, OX1 2EP, United Kingdom > 01865 28502. > > http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Siemens+Mole > cular+Imaging,+23-38+Hythe+Bridge+St.,+Oxfordshire,+OX1+2EP,+Oxford, > +Uni > ted > +Kingdom&sll=37.0625,-95.677068&sspn=78.056642,54.580078&ie=UTF8&ll=5 > 1.753244,-1.266561&spn=0.007731,0.009023&z=17&iwloc=A > > I think the debate about choosing between London and Oxford has > stalled > our travel plans, and now we are running out of time. If you could > kindly let me know who plans on attending I can at least have > Charlotte > look into hotel availability in Oxford and make lunch/dinner > arrangements. > > How many people plan to attend? > Cordially, > Gianluca > > ------------------------------------------------------------------------ > -------- > From: DECLERCK, JEROME > Sent: Thursday, July 23, 2009 1:38 PM > To: Paladini, Gianluca (SCR US) > Cc: FENTON, CHARLOTTE > RE: CTK meeting in Oxford > > Hi Gianluca, > I managed to organize for you to be able to use the room for 2 days if > you need to, thanks to Charlotte, who has kindly accepted to come on a > Saturday. She would also be the point of contact should you need to > organize hotels, etc. > > Best regards, > > Jerome > > -----Original Message----- > From: Meinzer Hans-Peter [mailto:h.p.meinzer at dkfz-heidelberg.de] > Sent: Friday, August 14, 2009 7:23 AM > To: Stephen Aylward; Kevin Cleary > Cc: Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; > Kevin Cleary; Nicholas Ayache; Ron Kikinis; Andreas Engelke; Nolden > Marco; Wolf Ivo; Sauer, Frank (SCR US); Paladini, Gianluca (SCR US); > Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ > Julien; Christian Renner; Quadrani Paolo; Lawrence Tarbox; Engelmann > Uwe > Subject: AW: AW: CTK and MAF3: hotels in London > > Dear Friends of CTK, > > I dislike what I see coming up. There are two options: > 1- Oxford, no details available from Gianluca. > 2- London, no details available from Kevin. > I suggest we accept the first offer with a precise location and time. > > Also, for those NOT attending MICCAI, which is the majority, we need a > suggestion of a hotel CLOSE BY, preferably with some local travel > advise. As London is big a place, things might be easier in a small > village. > > best wishes > Peter Meinzer > > > > > Hans-Peter Meinzer > Prof. Dr. sc.hum.habil. > Head of Department 'Medical and Biological Informatics' > German Cancer Research Center > Im Neuenheimer Feld 280 > 69120 Heidelberg > > +49-6221-422366 office > +49-6221-422345 fax > +49-171-2655356 mobile > > H.P.Meinzer at dkfz.de > > ________________________________ > > Von: Stephen Aylward [mailto:stephen.aylward at kitware.com] > Gesendet: Mi 12.8.2009 20:56 > An: Kevin Cleary > Cc: Meinzer Hans-Peter; Marco Viceconti; ctk-developers at commontk.org; > dclunie at dclunie.com; Kevin Cleary; Nicholas Ayache; Ron Kikinis; > Andreas > Engelke; Nolden Marco; Wolf Ivo; Sauer, Frank (SCR US); Gianluca US) > Paladini (SCR; Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning > Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Lawrence > Tarbox; > Engelmann Uwe > Betreff: Re: AW: CTK and MAF3: hotels in London > > > > On Mon, Aug 10, 2009 at 7:20 AM, Kevin > Cleary wrote: >> As for the meeting location, I am not against going to Oxford since I >> have never been there, so perhaps the best thing to do is take a vote >> >> Kevin > > I follow Kevin's logic...I've never been to Oxford, and I'd enjoy > seeing > it. > > My vote is for Oxford, but I am willing to me at either location. > > Thanks, > Stephen > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging > 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 From gianluca.paladini at siemens.com Mon Aug 17 17:04:01 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Mon, 17 Aug 2009 10:04:01 -0700 Subject: [Ctk-developers] CTK meeting in Oxford In-Reply-To: <38E3A921A2B9FC46B02E566BDED7CF4E01F90CF9@oxfw0e1a.ww001.siemens.net> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709D67E9C@USNWK100MSX.ww017.siemens.net> Hello CTK members, I am putting together a list of attendees for the upcoming second CTK meeting in Oxford, UK on Sept. 25th. Based on the emails I have received so far I have the following confirmations: Confirmed: 1. Hans-Peter Meinzer, German Cancer Research Center, Heidelberg 2. Gianluca Paladini, Siemens Corporate Research, Princeton 3. Frank Sauer, Siemens Corporate Research, Princeton 4. Steve Pieper, Harvard Medical School, Boston 5. Ron Kikinis, Harvard Medical School, Boston 6. Kevin Cleary, Georgetown University, ISIS, Washington DC 7. Lawrence Tarbox, Mallinckrodt Institute of Radiology, St.Louis 8. Stephen Aylward, Kitware Inc., Clifton Park 9. Marco Viceconti, Laboratorio di Tecnologia Medica, Bologna 10. Michael Onken, OFFIS DICOM Team, Oldenburg Not Yet Confirmed: - Ivo Wolf, Hochschule Mannheim, Institut f?r Medizinische Informatik, Mannheim - Marco Nolden, German Cancer Research Center, Heidelberg - Christian Renner, German Research Foundation, DFG, Bonn - David Clunie, Chief Technology Officer, RadPharm Inc., Princeton - Nicolas Ayache, Sophia Antipolis, INRIA, Nice - Olivier Clatz, Sofia Antipolis, INRIA, Nice - Julien Wintz, Sofia Antipolis, INRIA, Nice - Quadrani Paolo, BioComputing Competence Centre, Bologna If you plan on attending, please let me know ASAP so that Charlotte Fenton at Siemens Molecular Imaging can make sure we have a place to stay. So far she provisionally booked 10 rooms for the 24th and 7 rooms for the 25th (see message below), I assume we will need more and therefore we may need to go to a different hotel. If you contact Charlotte directly please CC' me to it so I can keep track of the list of attendees. Looking forward to seeing you in Oxford! Cordially, Gianluca ________________________________ From: FENTON, CHARLOTTE Sent: Monday, August 17, 2009 10:19 AM To: Paladini, Gianluca (SCR US) Cc: DECLERCK, JEROME; Royal Oxford Hotel Subject: RE: CTK meeting in Oxford Dear Gianluca Thanks for your email. For your meeting for up to 15 people on 25th September I have managed to make a provisional booking for 10 rooms at the Royal Oxford Hotel at ?94 each including breakfast for the night of 24th September. There are 7 rooms available for the night of 25th September. (How late will your meeting run?) The Royal Oxford is infront of our office which avoids any transport issues. The phone number is 01865 248432, please mention Siemens when booking. www.royaloxfordhotel.co.uk Let me know what you will require for lunch and dinner and I shall come up with a costing for you. Directions for finding this office are available on google map: http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=ox1+2ep&sll=53.800651,-4.064941&sspn=11.510541,26.894531&ie=UTF8&ll=51.752885,-1.267505&spn=0.011769,0.026264&z=15&layer=c&cbll=51.753027,-1.267437&panoid=m5V6wZQRhxg7L4kNPz93uQ&cbp=12,43.61,,0,5 Thanks Charlotte Charlotte Fenton Office Manager Siemens Molecular Imaging Siemens Magnet Technology Ltd Healthcare Sector Beaver House 23/38 Hythe Bridge Street OXFORD OX1 2EP United Kingdom Direct Line +44 (0)1865 265514 Fax +44 (0)1865 265501 E-Mail charlotte.fenton at siemens.com; Siemens Magnet Technology Ltd. Registered office: Faraday House, Sir William Siemens Square, Frimley, Camberley, GU16 8QD. Registered no: 2342055, England. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.quadrani at scsolutions.it Thu Aug 20 12:02:24 2009 From: p.quadrani at scsolutions.it (Quadrani Paolo) Date: Thu, 20 Aug 2009 14:02:24 +0200 Subject: [Ctk-developers] Widgets list Message-ID: <2E0D70A9-6A59-4076-9670-C7AEA300A84F@scsolutions.it> Dear all, following I report collected comments from B3C on the widgets list: " Instead thinking at all possible widgets combinations, should be more convenient to start thinking at a common base of widgets (coming for example from the General Purpose Widgets) and giving an easy way to combine/extend them through the API. We think that are missing some widgets: - Rotation widget - Translation widget - Isotropic-scaling widget - ROI widget - Probing widget - Distance meter widget - Selection widget " At this link you can find some snapshots coming from a MAF application: http://www.openmaf.org/maf/Members/Quadrani/CTK_Widgets_snaps.zip Cheers Paolo Quadrani _________________________________ BioComputing Competence Centre SCS s.r.l. Via Magnanelli 6/3, 40033 Casalecchio di Reno Italy From gianluca.paladini at siemens.com Thu Aug 20 02:44:02 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Wed, 19 Aug 2009 19:44:02 -0700 Subject: [Ctk-developers] CTK meeting in Oxford - status update In-Reply-To: References: <38E3A921A2B9FC46B02E566BDED7CF4E01F90CF9@oxfw0e1a.ww001.siemens.net> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709DCE078@USNWK100MSX.ww017.siemens.net> Hello CTK members, Here is an update about the meeting in Oxford. Hotels are very full on the date of our meeting as it is the welcome weekend for Oxford Brookes University so parents are dropping their children off. The good news is that Charlotte Fenton managed to book a block of 14 rooms at the Barcelo Hotel: http://www.barcelo-hotels.co.uk/hotels/central-england/barcelo-oxford-hotel It looks quite nice on their website, it is a four star hotel and we have a group rate of ?88.00 per night including breakfast. It is however 4 miles away from Siemens and therefore we will have to find some vans/taxis to take us there. Charlotte also arranged a dinner for everyone at the Barcelo on the 24th with a private dining menu, lunch at Siemens on the 25th, and another dinner at the Living Room restaurant. Meals & drinks are courtesy of Siemens (although we are getting our Compliance Office involved to make sure we have their blessing). This is the list of attendees I have so far: 1. Hans-Peter Meinzer, German Cancer Research Center, Heidelberg 2. Gianluca Paladini, Siemens Corporate Research, Princeton 3. Steve Pieper, Harvard Medical School, Boston 4. Ron Kikinis, Harvard Medical School, Boston 5. Kevin Cleary, Georgetown University, ISIS, Washington DC (ONE HOTEL NIGHT ONLY) 6. Lawrence Tarbox, Mallinckrodt Institute of Radiology, St.Louis 7. Stephen Aylward, Kitware Inc., Clifton Park 8. Marco Viceconti, Laboratorio di Tecnologia Medica, Bologna 9. Michael Onken, OFFIS DICOM Team, Oldenburg (ONE HOTEL NIGHT ONLY) 10. Olivier Clatz, Sofia Antipolis, INRIA, Nice 11. Julien Wintz, Sofia Antipolis, INRIA, Nice 12. Ivo Wolf, Hochschule Mannheim, Institut f?r Medizinische Informatik, Mannheim 13. Marco Nolden, German Cancer Research Center, Heidelberg 14. David Clunie, RadPharm Inc., Princeton (80% probable) If anyone else not in the list plans on being there, it's time to send a confirmation. Also, Charlotte would like to know if there are any vegetarians in the group, or if there are any allergies or dietary requirements that we should be aware of - please let her know. Looking forward to seeing you in Oxford! Cordially, Gianluca From pieper at bwh.harvard.edu Thu Aug 20 17:38:30 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Thu, 20 Aug 2009 13:38:30 -0400 Subject: [Ctk-developers] Widgets list In-Reply-To: <2E0D70A9-6A59-4076-9670-C7AEA300A84F@scsolutions.it> References: <2E0D70A9-6A59-4076-9670-C7AEA300A84F@scsolutions.it> Message-ID: <4A8D8A16.5050808@bwh.harvard.edu> Thanks, Paolo - Those are good points. I added them to the wiki pages under 2D/3D widgets with some links to other info: http://my-trac.assembla.com/protoctk/wiki/WidgetPlans -Steve Quadrani Paolo wrote: > Dear all, > following I report collected comments from B3C on the widgets list: > > " > Instead thinking at all possible widgets combinations, should be more > convenient to start thinking at a common base of widgets (coming for > example from the General Purpose Widgets) and giving an easy way to > combine/extend them through the API. > > We think that are missing some widgets: > - Rotation widget > - Translation widget > - Isotropic-scaling widget > - ROI widget > - Probing widget > - Distance meter widget > - Selection widget > " > > At this link you can find some snapshots coming from a MAF application: > http://www.openmaf.org/maf/Members/Quadrani/CTK_Widgets_snaps.zip > > Cheers > > Paolo Quadrani > _________________________________ > BioComputing Competence Centre > SCS s.r.l. > > Via Magnanelli 6/3, 40033 > Casalecchio di Reno > Italy > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From stephen.aylward at kitware.com Thu Aug 20 22:39:07 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 20 Aug 2009 18:39:07 -0400 Subject: [Ctk-developers] CTK Scene Message-ID: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> Continuing the discussion of CTK data types... I propose that we have a ctkScene as a driving datatype. First, perhaps, we need to agree on the definition of a scene. I propose that a ctkScene should have two main traits: 1) Generically, a scene is composed of objects that fill a portion of space and time * Objects have a position in space * Objects have an orientation in space * Objects have a range in time * Given a point in physical space and time, it should be possible to determine if an object contains it or not. * An object should contain at least one point in space and time * The concept of units is paramount in a scene. ** Units describe the spatial and chronological scale of an object 2) A scene represents a hierarchy of object in space and time. * Objects have a single parent (except a root object) and may have one or more children objects ** That is, a scene is a tree * Moving a parent object in space or time should (by default) cause its children to experience the same movement in space and time * The coordinate system for root objects is defined as "real-world" space. It is an absolute space. * A scene may have multiple roots ** It is not necessary to represent everything in space from a single root. ** One or more roots are used to contain the physical/temporal objects relevant to a particular task. * Objects implicitly include their child objects ** When querying the time/space extent of an object (e.g., to determine if a point is inside of it or to determine its bounding box) that query typically also includes its child objects in its computations. * Most queries to and responses from objects should be with respect to real-world space (i.e., the coordinate system of the root object). ** For example, querying an object if it contains a physical point is done using real-world coordinates (i.e., a coordinate system common to all objects in its tree). I'm adding this to the wiki at: http://my-trac.assembla.com/protoctk/wiki/ctkScene Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From gianluca.paladini at siemens.com Thu Aug 20 23:27:02 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Thu, 20 Aug 2009 16:27:02 -0700 Subject: [Ctk-developers] Widgets list In-Reply-To: <2E0D70A9-6A59-4076-9670-C7AEA300A84F@scsolutions.it> References: <2E0D70A9-6A59-4076-9670-C7AEA300A84F@scsolutions.it> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709DCE7C0@USNWK100MSX.ww017.siemens.net> I would caution not to throw into the mix widgets that interact within the display area. It is useful to populate a GUI's control area with advanced widgets that go beyond simple buttons and sliders - but when it comes to the display area you enter the realm of 2D and 3D computer graphics - some of us use straight OpenGL, some use VTK interactors, some use Open Inventor manipulators, etc.. Those are not self-contained user interface widgets - they are tied to coordinate systems and state management, therefore the moment you introduce something like that you immediately open up a big can of worms. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Quadrani Paolo Sent: Thursday, August 20, 2009 8:02 AM To: ctk-developers at commontk.org Subject: [Ctk-developers] Widgets list Dear all, following I report collected comments from B3C on the widgets list: " Instead thinking at all possible widgets combinations, should be more convenient to start thinking at a common base of widgets (coming for example from the General Purpose Widgets) and giving an easy way to combine/extend them through the API. We think that are missing some widgets: - Rotation widget - Translation widget - Isotropic-scaling widget - ROI widget - Probing widget - Distance meter widget - Selection widget " At this link you can find some snapshots coming from a MAF application: http://www.openmaf.org/maf/Members/Quadrani/CTK_Widgets_snaps.zip Cheers Paolo Quadrani _________________________________ BioComputing Competence Centre SCS s.r.l. Via Magnanelli 6/3, 40033 Casalecchio di Reno Italy _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From gianluca.paladini at siemens.com Fri Aug 21 01:37:51 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Thu, 20 Aug 2009 18:37:51 -0700 Subject: [Ctk-developers] CTK Scene In-Reply-To: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709DCE801@USNWK100MSX.ww017.siemens.net> Hi Stephen, I would like to add another requirement - we should pick a "platform neutral" representation of a scene graph that can be parsed into any proprietary scene graph technology. In XIP we have already moved in that direction - we are about to release a new scene graph file format to store/retrieve scene graphs using an XML representation. This is being done in the spirit of having XIP Builder becoming a "CTK friendly" scene graph editor tool. Ideally this XML file could be parsed and translated to object instances from any scene graph library, including Open Inventor, OpenSG, OSG, OpenRM, NVSG and so on (yes, there are a lot of scene graph libraries out there already...). This new XML format solves two major drawbacks of Open Inventor scene graph files: 1) If two developers are working independently on the same scene graph, there is no way of using a diff-and-merge tool to synchronize their changes (the same way it is done with C++ files). The structure of Open Inventor files is rearranged considerably even after the smallest change. Our XIP file format is designed in such a way that any changes from version to version can be easily identified. This is a must-have in order to be able to work on large projects with multiple developers! 2) If a scene graph object changes (for example a field name or method is renamed or removed) Open Inventor is unable to load a file containing an obsolete object being used in the scene graph. Our new XML-based format is more fault-tolerant and will simply avoid forming connections between objects with mismatched functionality, and will flag those objects so that they can be seen and corrected by the user. I will notify everyone when the file format is posted in the public domain. Right now we are testing it with the largest scene graphs ever created at SCR (thousands of nodes). It is really not XIP-specific, therefore it could be used as a starting point for CTK. In addition, it has extra information (in a separate section) that goes beyond just the scene graph description: it contains a description about how to visualize the scene graph hierarchy itself within a visual programming tool (how nodes are positioned on the screen, how they are grouped together, their shape and color etc.). Note that there is an existing consortium for defining a standard XML representation of a scene graph, it is called X3D. They have been at it for YEARS and YEARS, it was supposed to be a replacement for VRML but is it still lagging behind Open Inventor. And X3D's Medical working group is progressing at even a slower pace. In my opinion we are better off staying away from X3D - it is my hope that our CTK group will be a productive one ;) Cheers, Gianluca -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward Sent: Thursday, August 20, 2009 6:39 PM To: ctk-developers at commontk.org Subject: [Ctk-developers] CTK Scene Continuing the discussion of CTK data types... I propose that we have a ctkScene as a driving datatype. First, perhaps, we need to agree on the definition of a scene. I propose that a ctkScene should have two main traits: 1) Generically, a scene is composed of objects that fill a portion of space and time * Objects have a position in space * Objects have an orientation in space * Objects have a range in time * Given a point in physical space and time, it should be possible to determine if an object contains it or not. * An object should contain at least one point in space and time * The concept of units is paramount in a scene. ** Units describe the spatial and chronological scale of an object 2) A scene represents a hierarchy of object in space and time. * Objects have a single parent (except a root object) and may have one or more children objects ** That is, a scene is a tree * Moving a parent object in space or time should (by default) cause its children to experience the same movement in space and time * The coordinate system for root objects is defined as "real-world" space. It is an absolute space. * A scene may have multiple roots ** It is not necessary to represent everything in space from a single root. ** One or more roots are used to contain the physical/temporal objects relevant to a particular task. * Objects implicitly include their child objects ** When querying the time/space extent of an object (e.g., to determine if a point is inside of it or to determine its bounding box) that query typically also includes its child objects in its computations. * Most queries to and responses from objects should be with respect to real-world space (i.e., the coordinate system of the root object). ** For example, querying an object if it contains a physical point is done using real-world coordinates (i.e., a coordinate system common to all objects in its tree). I'm adding this to the wiki at: http://my-trac.assembla.com/protoctk/wiki/ctkScene Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From stephen.aylward at kitware.com Fri Aug 21 02:21:54 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 20 Aug 2009 22:21:54 -0400 Subject: [Ctk-developers] CTK Scene In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC709DCE801@USNWK100MSX.ww017.siemens.net> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC709DCE801@USNWK100MSX.ww017.siemens.net> Message-ID: <68a07c2d0908201921v5c9dc3fcg2004ec976462d890@mail.gmail.com> Hi Gianluca, That sounds like extremely useful work. I think the medical image analysis field could greatly benefit from standardizing scene representations as well as standardizing the recording of data providence (what is the data source, and what processing has been applied). These should be base technologies (ITK / CTK level) and, like you said, platform independent. I like the idea of starting from a file format / database structure for the scene. Having extensions to define visualization properties is also an interesting idea. My only concern is to keep a scene from become application or visualization specific. There should be no storage of gl contexts, gl triangle strips, vtkActors, or properties specific to those platforms within the scene. Is there going to be a group / committee that will manage the extensions to that format? A reference implementation in C++? Thanks, Stephen On Thu, Aug 20, 2009 at 9:37 PM, Paladini, Gianluca (SCR US) wrote: > Hi Stephen, > I would like to add another requirement - we should pick a "platform > neutral" representation of a scene graph that can be parsed into any > proprietary scene graph technology. In XIP we have already moved in that > direction - we are about to release a new scene graph file format to > store/retrieve scene graphs using an XML representation. This is being > done in the spirit of having XIP Builder becoming a "CTK friendly" scene > graph editor tool. Ideally this XML file could be parsed and translated > to object instances from any scene graph library, including Open > Inventor, OpenSG, OSG, OpenRM, NVSG and so on (yes, there are a lot of > scene graph libraries out there already...). > > This new XML format solves two major drawbacks of Open Inventor scene > graph files: > 1) If two developers are working independently on the same scene graph, > there is no way of using a diff-and-merge tool to synchronize their > changes (the same way it is done with C++ files). The structure of Open > Inventor files is rearranged considerably even after the smallest > change. Our XIP file format is designed in such a way that any changes > from version to version can be easily identified. This is a must-have in > order to be able to work on large projects with multiple developers! > 2) If a scene graph object changes (for example a field name or method > is renamed or removed) Open Inventor is unable to load a file containing > an obsolete object being used in the scene graph. Our new XML-based > format is more fault-tolerant and will simply avoid forming connections > between objects with mismatched functionality, and will flag those > objects so that they can be seen and corrected by the user. > > I will notify everyone when the file format is posted in the public > domain. Right now we are testing it with the largest scene graphs ever > created at SCR (thousands of nodes). It is really not XIP-specific, > therefore it could be used as a starting point for CTK. In addition, it > has extra information (in a separate section) that goes beyond just the > scene graph description: it contains a description about how to > visualize the scene graph hierarchy itself within a visual programming > tool (how nodes are positioned on the screen, how they are grouped > together, their shape and color etc.). > > Note that there is an existing consortium for defining a standard XML > representation of a scene graph, it is called X3D. ?They have been at it > for YEARS and YEARS, it was supposed to be a replacement for VRML but is > it still lagging behind Open Inventor. And X3D's Medical working group > is progressing at even a slower pace. In my opinion we are better off > staying away from X3D - it is my hope that our CTK group will be a > productive one ;) > Cheers, > ? ?Gianluca > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen > Aylward > Sent: Thursday, August 20, 2009 6:39 PM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] CTK Scene > > Continuing the discussion of CTK data types... > > I propose that we have a ctkScene as a driving datatype. > > First, perhaps, we need to agree on the definition of a scene. ? I > propose that a ctkScene should have two main traits: > > 1) Generically, a scene is composed of objects that fill a portion of > space and time > * Objects have a position in space > * Objects have an orientation in space > * Objects have a range in time > * Given a point in physical space and time, it should be possible to > determine if an object contains it or not. > * An object should contain at least one point in space and time > * The concept of units is paramount in a scene. > ** Units describe the spatial and chronological scale of an object > > 2) A scene represents a hierarchy of object in space and time. > * Objects have a single parent (except a root object) and may have one > or more children objects > ** That is, a scene is a tree > * Moving a parent object in space or time should (by default) cause > its children to experience the same movement in space and time > * The coordinate system for root objects is defined as "real-world" > space. ? It is an absolute space. > * A scene may have multiple roots > ** It is not necessary to represent everything in space from a single > root. > ** One or more roots are used to contain the physical/temporal objects > relevant to a particular task. > * Objects implicitly include their child objects > ** When querying the time/space extent of an object (e.g., to > determine if a point is inside of it or to determine its bounding box) > that query typically also includes its child objects in its > computations. > * Most queries to and responses from objects should be with respect to > real-world space (i.e., the coordinate system of the root object). > ** For example, querying an object if it contains a physical point is > done using real-world coordinates (i.e., a coordinate system common to > all objects in its tree). > > I'm adding this to the wiki at: > http://my-trac.assembla.com/protoctk/wiki/ctkScene > > Stephen > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > 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 Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From gianluca.paladini at siemens.com Fri Aug 21 02:32:29 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Thu, 20 Aug 2009 19:32:29 -0700 Subject: [Ctk-developers] CTK Scene In-Reply-To: <68a07c2d0908201921v5c9dc3fcg2004ec976462d890@mail.gmail.com> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC709DCE801@USNWK100MSX.ww017.siemens.net> <68a07c2d0908201921v5c9dc3fcg2004ec976462d890@mail.gmail.com> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709DCE816@USNWK100MSX.ww017.siemens.net> XIP is open source, therefore it will serve as a reference implementation on how to parse this XML file. The file refers to nodes by their class name (and optional instance name), the same goes for fields (i.e. public data members) and methods. Therefore in principle the file can refer to objects belonging to any class library. It is up to the application to create instances of such C++ objects while loading and parsing the XML file, connecting objects together and setting their values and properties. If unknown objects are found it means that the application does not have the right scene graph library to match what's described in the file. -----Original Message----- From: Stephen Aylward [mailto:stephen.aylward at kitware.com] Sent: Thursday, August 20, 2009 10:22 PM To: Paladini, Gianluca (SCR US) Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] CTK Scene Hi Gianluca, That sounds like extremely useful work. I think the medical image analysis field could greatly benefit from standardizing scene representations as well as standardizing the recording of data providence (what is the data source, and what processing has been applied). These should be base technologies (ITK / CTK level) and, like you said, platform independent. I like the idea of starting from a file format / database structure for the scene. Having extensions to define visualization properties is also an interesting idea. My only concern is to keep a scene from become application or visualization specific. There should be no storage of gl contexts, gl triangle strips, vtkActors, or properties specific to those platforms within the scene. Is there going to be a group / committee that will manage the extensions to that format? A reference implementation in C++? Thanks, Stephen On Thu, Aug 20, 2009 at 9:37 PM, Paladini, Gianluca (SCR US) wrote: > Hi Stephen, > I would like to add another requirement - we should pick a "platform > neutral" representation of a scene graph that can be parsed into any > proprietary scene graph technology. In XIP we have already moved in that > direction - we are about to release a new scene graph file format to > store/retrieve scene graphs using an XML representation. This is being > done in the spirit of having XIP Builder becoming a "CTK friendly" scene > graph editor tool. Ideally this XML file could be parsed and translated > to object instances from any scene graph library, including Open > Inventor, OpenSG, OSG, OpenRM, NVSG and so on (yes, there are a lot of > scene graph libraries out there already...). > > This new XML format solves two major drawbacks of Open Inventor scene > graph files: > 1) If two developers are working independently on the same scene graph, > there is no way of using a diff-and-merge tool to synchronize their > changes (the same way it is done with C++ files). The structure of Open > Inventor files is rearranged considerably even after the smallest > change. Our XIP file format is designed in such a way that any changes > from version to version can be easily identified. This is a must-have in > order to be able to work on large projects with multiple developers! > 2) If a scene graph object changes (for example a field name or method > is renamed or removed) Open Inventor is unable to load a file containing > an obsolete object being used in the scene graph. Our new XML-based > format is more fault-tolerant and will simply avoid forming connections > between objects with mismatched functionality, and will flag those > objects so that they can be seen and corrected by the user. > > I will notify everyone when the file format is posted in the public > domain. Right now we are testing it with the largest scene graphs ever > created at SCR (thousands of nodes). It is really not XIP-specific, > therefore it could be used as a starting point for CTK. In addition, it > has extra information (in a separate section) that goes beyond just the > scene graph description: it contains a description about how to > visualize the scene graph hierarchy itself within a visual programming > tool (how nodes are positioned on the screen, how they are grouped > together, their shape and color etc.). > > Note that there is an existing consortium for defining a standard XML > representation of a scene graph, it is called X3D. ?They have been at it > for YEARS and YEARS, it was supposed to be a replacement for VRML but is > it still lagging behind Open Inventor. And X3D's Medical working group > is progressing at even a slower pace. In my opinion we are better off > staying away from X3D - it is my hope that our CTK group will be a > productive one ;) > Cheers, > ? ?Gianluca > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen > Aylward > Sent: Thursday, August 20, 2009 6:39 PM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] CTK Scene > > Continuing the discussion of CTK data types... > > I propose that we have a ctkScene as a driving datatype. > > First, perhaps, we need to agree on the definition of a scene. ? I > propose that a ctkScene should have two main traits: > > 1) Generically, a scene is composed of objects that fill a portion of > space and time > * Objects have a position in space > * Objects have an orientation in space > * Objects have a range in time > * Given a point in physical space and time, it should be possible to > determine if an object contains it or not. > * An object should contain at least one point in space and time > * The concept of units is paramount in a scene. > ** Units describe the spatial and chronological scale of an object > > 2) A scene represents a hierarchy of object in space and time. > * Objects have a single parent (except a root object) and may have one > or more children objects > ** That is, a scene is a tree > * Moving a parent object in space or time should (by default) cause > its children to experience the same movement in space and time > * The coordinate system for root objects is defined as "real-world" > space. ? It is an absolute space. > * A scene may have multiple roots > ** It is not necessary to represent everything in space from a single > root. > ** One or more roots are used to contain the physical/temporal objects > relevant to a particular task. > * Objects implicitly include their child objects > ** When querying the time/space extent of an object (e.g., to > determine if a point is inside of it or to determine its bounding box) > that query typically also includes its child objects in its > computations. > * Most queries to and responses from objects should be with respect to > real-world space (i.e., the coordinate system of the root object). > ** For example, querying an object if it contains a physical point is > done using real-world coordinates (i.e., a coordinate system common to > all objects in its tree). > > I'm adding this to the wiki at: > http://my-trac.assembla.com/protoctk/wiki/ctkScene > > Stephen > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > 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 Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From viceconti at tecno.ior.it Fri Aug 21 06:06:30 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Fri, 21 Aug 2009 08:06:30 +0200 Subject: [Ctk-developers] X3D In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC709DCE801@USNWK100MSX.ww017.siemens.net> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC709DCE801@USNWK100MSX.ww017.siemens.net> Message-ID: I have some ideas on neutral scenes, which I shall write on separate reply to this thread. Here I would like to notice that while I agree with Gianluca, the fact is that ACR-NEMA have a working Item under WG06 on n-Dimensional Presentation States which explicitly refers to X3D: http://medical.nema.org/Dicom/minutes/WG-11/2009/2009-02-11/WG-11_2009-02-11_Min.doc So while I am not advocating we buy into X3D, we should keep an open root toward it somehow, in case this action of the Web3D consortium suddenly gets legs. Also notice that X3D is a draft ISO standard, although I do not think it has been ratified yet. cheers Marco Il giorno 21/ago/09, alle ore 03:37, Paladini, Gianluca (SCR US) ha scritto: > Hi Stephen, > I would like to add another requirement - we should pick a "platform > neutral" representation of a scene graph that can be parsed into any > proprietary scene graph technology. In XIP we have already moved in > that > direction - we are about to release a new scene graph file format to > store/retrieve scene graphs using an XML representation. This is being > done in the spirit of having XIP Builder becoming a "CTK friendly" > scene > graph editor tool. Ideally this XML file could be parsed and > translated > to object instances from any scene graph library, including Open > Inventor, OpenSG, OSG, OpenRM, NVSG and so on (yes, there are a lot of > scene graph libraries out there already...). > > This new XML format solves two major drawbacks of Open Inventor scene > graph files: > 1) If two developers are working independently on the same scene > graph, > there is no way of using a diff-and-merge tool to synchronize their > changes (the same way it is done with C++ files). The structure of > Open > Inventor files is rearranged considerably even after the smallest > change. Our XIP file format is designed in such a way that any changes > from version to version can be easily identified. This is a must- > have in > order to be able to work on large projects with multiple developers! > 2) If a scene graph object changes (for example a field name or method > is renamed or removed) Open Inventor is unable to load a file > containing > an obsolete object being used in the scene graph. Our new XML-based > format is more fault-tolerant and will simply avoid forming > connections > between objects with mismatched functionality, and will flag those > objects so that they can be seen and corrected by the user. > > I will notify everyone when the file format is posted in the public > domain. Right now we are testing it with the largest scene graphs ever > created at SCR (thousands of nodes). It is really not XIP-specific, > therefore it could be used as a starting point for CTK. In addition, > it > has extra information (in a separate section) that goes beyond just > the > scene graph description: it contains a description about how to > visualize the scene graph hierarchy itself within a visual programming > tool (how nodes are positioned on the screen, how they are grouped > together, their shape and color etc.). > > Note that there is an existing consortium for defining a standard XML > representation of a scene graph, it is called X3D. They have been > at it > for YEARS and YEARS, it was supposed to be a replacement for VRML > but is > it still lagging behind Open Inventor. And X3D's Medical working group > is progressing at even a slower pace. In my opinion we are better off > staying away from X3D - it is my hope that our CTK group will be a > productive one ;) > Cheers, > Gianluca > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen > Aylward > Sent: Thursday, August 20, 2009 6:39 PM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] CTK Scene > > Continuing the discussion of CTK data types... > > I propose that we have a ctkScene as a driving datatype. > > First, perhaps, we need to agree on the definition of a scene. I > propose that a ctkScene should have two main traits: > > 1) Generically, a scene is composed of objects that fill a portion of > space and time > * Objects have a position in space > * Objects have an orientation in space > * Objects have a range in time > * Given a point in physical space and time, it should be possible to > determine if an object contains it or not. > * An object should contain at least one point in space and time > * The concept of units is paramount in a scene. > ** Units describe the spatial and chronological scale of an object > > 2) A scene represents a hierarchy of object in space and time. > * Objects have a single parent (except a root object) and may have one > or more children objects > ** That is, a scene is a tree > * Moving a parent object in space or time should (by default) cause > its children to experience the same movement in space and time > * The coordinate system for root objects is defined as "real-world" > space. It is an absolute space. > * A scene may have multiple roots > ** It is not necessary to represent everything in space from a single > root. > ** One or more roots are used to contain the physical/temporal objects > relevant to a particular task. > * Objects implicitly include their child objects > ** When querying the time/space extent of an object (e.g., to > determine if a point is inside of it or to determine its bounding box) > that query typically also includes its child objects in its > computations. > * Most queries to and responses from objects should be with respect to > real-world space (i.e., the coordinate system of the root object). > ** For example, querying an object if it contains a physical point is > done using real-world coordinates (i.e., a coordinate system common to > all objects in its tree). > > I'm adding this to the wiki at: > http://my-trac.assembla.com/protoctk/wiki/ctkScene > > Stephen > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------------------------------------------- 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 From viceconti at tecno.ior.it Fri Aug 21 06:58:36 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Fri, 21 Aug 2009 08:58:36 +0200 Subject: [Ctk-developers] CTK Scene In-Reply-To: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> Message-ID: <6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> One of the goal of MAF3 is to fully separate VMEs (our data objects) from Views and from Operations, so as to maximise reusability, and to make possible that each of these MAF resources can be added at run time as a plugin. This of course raise the debate on how to provide a neutral representation of the visualisation components. Firstly, Stephen implies that the right point where to cut is the scene, as most of the visualisation libraries do. But I would like to bring some alternative ideas on the table: a) Actors. One could image to export single actors instead of whole scene. this would reduce the granularity, and would make conceptually easier to develop distributed applications where single actors are being generated/updated by separate processes, and the visualisation application has the responsibility to compose the scene with them and to render it. Actually this idea is not necessarily in conflict with the one Stephen and Gianluca advocate; we could image an extensibility mechanism to the scene format, so that I can also export a single actor using the same XML syntax. b) RenderWindows: to the other extreme, in MAF we are considering to expose out of the visualisation module not the scene, but the RenderWindow. The rationale behind this is that the true conceptualisation nowadays is in choosing for each type of actor a certain rendering style, so that multi-actors Views produce a coherent representation. So for example, in our MIP View volumes are rendered with a MIP visual pipe, but surfaces are rendered with a flat surface rendering, so that it appears consistent with a radiography-like image where geometric objects are usually man-made and thus of homogenous opacity. In this perspective the View becomes like a virtual imaging machine, which produces a visual representation for each digital object according to the type and properties of this object in a coherent way. The problem with approach b) is that I have difficulties to see how this could be made compatible with scene approach. One possibility could be to extend the XML syntax to include an optional section where one can also specify the rendering elements; does this make any sense? I do not have a strong opinion on this, but I thought it might be useful we try to thing a bit out of the box here. Cheers Marco Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto: > Continuing the discussion of CTK data types... > > I propose that we have a ctkScene as a driving datatype. > > First, perhaps, we need to agree on the definition of a scene. I > propose that a ctkScene should have two main traits: > > 1) Generically, a scene is composed of objects that fill a portion of > space and time > * Objects have a position in space > * Objects have an orientation in space > * Objects have a range in time > * Given a point in physical space and time, it should be possible to > determine if an object contains it or not. > * An object should contain at least one point in space and time > * The concept of units is paramount in a scene. > ** Units describe the spatial and chronological scale of an object > > 2) A scene represents a hierarchy of object in space and time. > * Objects have a single parent (except a root object) and may have one > or more children objects > ** That is, a scene is a tree > * Moving a parent object in space or time should (by default) cause > its children to experience the same movement in space and time > * The coordinate system for root objects is defined as "real-world" > space. It is an absolute space. > * A scene may have multiple roots > ** It is not necessary to represent everything in space from a > single root. > ** One or more roots are used to contain the physical/temporal objects > relevant to a particular task. > * Objects implicitly include their child objects > ** When querying the time/space extent of an object (e.g., to > determine if a point is inside of it or to determine its bounding box) > that query typically also includes its child objects in its > computations. > * Most queries to and responses from objects should be with respect to > real-world space (i.e., the coordinate system of the root object). > ** For example, querying an object if it contains a physical point is > done using real-world coordinates (i.e., a coordinate system common to > all objects in its tree). > > I'm adding this to the wiki at: > http://my-trac.assembla.com/protoctk/wiki/ctkScene > > Stephen > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -------------------------------------------------- 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 From stephen.aylward at kitware.com Fri Aug 21 12:20:19 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Fri, 21 Aug 2009 08:20:19 -0400 Subject: [Ctk-developers] CTK Scene In-Reply-To: <6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> Message-ID: <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> Both options have merit. I agree that exporting single objects should be supported. It allows the system to interact with other (legacy) systems and, as you said, provides IO flexibility. One question regarding terminology...when you say "Actors" you are not referring to vtkActors, right? I'm fairly certain you are not, but I mention it because this is a point of contention for me at times...I've found vtkActors to have too limited an API to be used as scene objects (e.g., no standard method exists for querying if a point is inside of them, limited concept of parent-child relationships... - they fulfill almost none of the requirements that I posted on the wiki: http://my-trac.assembla.com/protoctk/wiki/ctkScene). Perhaps RenderWindow-specific information can be broadcast via traits. Traits can be used to describe a RenderWindow (3D vs 2D, MIP transfer function, Grayscale vs Color, Interactive vs passive) and for these traits each object in the scene may optionally change its default appearance (For ObjectX, if renderWindow is 2D, grayscale, and interactive; then display ObjectX as a semi-transparent contour, and show its control points so that the contour can be edited). Any application can override these defaults with application-specific behaviour, but those settings should (perhaps?) not be stored in the scene if those settings are not inherent to the object. The reason the renderWindow is given traits instead of the object having traits is so that the application developer (who is defining the renderWindow within his/her application) can specify the general nature of how objects will appear within it so as to be most effective for the user / task. Really interesting idea about exposing the renderwindow. I need to learn/think more about that - not certain how it promotes the exchange of information between multiple views or between views and logic modules within a single application. This discussion reminds me of yet another approach...a scene rendering pipeline developed by Julien Jomier called SpatialObject Viewers. In it, each renderWindow had an objectFactory associated with it. This objectFactor would generate a different renderer for each object fed to it, based on the object's type. The application developer could choose different objectFactories (one that produced MIPs, one that was interactive, one that was 3D) for each renderWindow in the application and in that way achieve a desired behaviour/appearance. Julien presented this system to the NAMIC group years ago: http://www.na-mic.org/Wiki/images/f/.../Na-Mic-SLC05-SpatialObjects.ppt Wow, we even have a website for them (this is a surprise to me - google is amazing): http://public.kitware.com/SOViewer/ This design pattern could be extended so that the objects, by specifying how they should be viewed in renderWindows having particular traits, could influence which renderer the renderWindow's objectFactory produced for them. Furthermore, there is no need to extend a renderWindow or application as each new object type is defined. Only objectFactories need to be extended, and those are intended to be extended via shared libraries. My thoughts for the morning... Stephen On Fri, Aug 21, 2009 at 2:58 AM, Marco Viceconti wrote: > One of the goal of MAF3 is to fully separate VMEs (our data objects) from > Views and from Operations, so as to maximise reusability, and to make > possible that each of these MAF resources can be added at run time as a > plugin. > > This of course raise the debate on how to provide a neutral representation > of the visualisation components. Firstly, Stephen implies that the right > point where to cut is the scene, as most of the visualisation libraries do. > ?But I would like to bring some alternative ideas on the table: > > a) Actors. ?One could image to export single actors instead of whole scene. > ?this would reduce the granularity, and would make conceptually easier to > develop distributed applications where single actors are being > generated/updated by separate processes, and the visualisation application > has the responsibility to compose the scene with them and to render it. > Actually this idea is not necessarily in conflict with the one Stephen and > Gianluca advocate; we could image an extensibility mechanism to the scene > format, so that I can also export a single actor using the same XML syntax. > > b) ?RenderWindows: to the other extreme, in MAF we are considering to expose > out of the visualisation module not the scene, but the RenderWindow. ?The > rationale behind this is that the true conceptualisation nowadays is in > choosing for each type of actor a certain rendering style, so that > multi-actors Views produce a coherent representation. So for example, in our > MIP View volumes are rendered with a MIP visual pipe, but surfaces are > rendered with a flat surface rendering, so that it appears consistent with a > radiography-like image where geometric objects are usually man-made and thus > of homogenous opacity. ?In this perspective the View becomes like a virtual > imaging machine, which produces a visual representation for each digital > object according to the type and properties of this object in a coherent > way. > > The problem with approach b) is that I have difficulties to see how this > could be made compatible with scene approach. ?One possibility could be to > extend the XML syntax to include an optional section where one can also > specify the rendering elements; does this make any sense? > > I do not have a strong opinion on this, but I thought it might be useful we > try to thing a bit out of the box here. > > Cheers > > Marco > > > > Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto: > >> Continuing the discussion of CTK data types... >> >> I propose that we have a ctkScene as a driving datatype. >> >> First, perhaps, we need to agree on the definition of a scene. ? I >> propose that a ctkScene should have two main traits: >> >> 1) Generically, a scene is composed of objects that fill a portion of >> space and time >> * Objects have a position in space >> * Objects have an orientation in space >> * Objects have a range in time >> * Given a point in physical space and time, it should be possible to >> determine if an object contains it or not. >> * An object should contain at least one point in space and time >> * The concept of units is paramount in a scene. >> ** Units describe the spatial and chronological scale of an object >> >> 2) A scene represents a hierarchy of object in space and time. >> * Objects have a single parent (except a root object) and may have one >> or more children objects >> ** That is, a scene is a tree >> * Moving a parent object in space or time should (by default) cause >> its children to experience the same movement in space and time >> * The coordinate system for root objects is defined as "real-world" >> space. ? It is an absolute space. >> * A scene may have multiple roots >> ** It is not necessary to represent everything in space from a single >> root. >> ** One or more roots are used to contain the physical/temporal objects >> relevant to a particular task. >> * Objects implicitly include their child objects >> ** When querying the time/space extent of an object (e.g., to >> determine if a point is inside of it or to determine its bounding box) >> that query typically also includes its child objects in its >> computations. >> * Most queries to and responses from objects should be with respect to >> real-world space (i.e., the coordinate system of the root object). >> ** For example, querying an object if it contains a physical point is >> done using real-world coordinates (i.e., a coordinate system common to >> all objects in its tree). >> >> I'm adding this to the wiki at: >> http://my-trac.assembla.com/protoctk/wiki/ctkScene >> >> Stephen >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > -------------------------------------------------- > 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 Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From gianluca.paladini at siemens.com Fri Aug 21 16:21:38 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Fri, 21 Aug 2009 09:21:38 -0700 Subject: [Ctk-developers] CTK Scene In-Reply-To: <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com><6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> Message-ID: <849860E57EBCC34C9E28B6E59A046CC709E2B1D1@USNWK100MSX.ww017.siemens.net> Hi Marco, I can see this concept of Actors corresponding to Open Inventor Manipulators, and the concept of RenderWindows corresponding to Open Inventor Examiners. Just playing devil's advocate - are we trying to reinvent the wheel? The goal of CTK is to provide a common set of functionality that we can all use in our respective frameworks. The idea of having a common, generalized scene graph file format that we can use to exchange information across toolkits can be very useful, but is it useful to implement a new scene graph library, knowing that there are so many off-the-shelf libraries developers can already use? For example in the case of XIP there is one free, open source version of Open Inventor from Sgi which we use in OpenXIP and two commercial versions from Mercury (http://www.vsg3d.com) and SystemsInMotion (http://www.coin3d.org) which we use to implement XIP-based products. Alternatively there are free open source libraries like OpenSG (http://opensg.vrsource.org/trac), OpenSceneGraph (http://www.openscenegraph.org/projects/osg), OpenRM (http://www.openrm.org), NVSG (http://developer.nvidia.com/object/nvsg_home.html). Since existing open source scene graph initiatives have put several years of development into their libraries, an effective way to design CTK's scene graph interchangeable file format may be to look at what exists already - a 'competitive analysis' if you will. Do you think this could be a useful exercise? I admit we only look at Open Inventor for our XML file format, therefore we may be missing support for functionality existing in other scene graph libraries. - Gianluca -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward Sent: Friday, August 21, 2009 8:20 AM To: Marco Viceconti Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] CTK Scene Both options have merit. I agree that exporting single objects should be supported. It allows the system to interact with other (legacy) systems and, as you said, provides IO flexibility. One question regarding terminology...when you say "Actors" you are not referring to vtkActors, right? I'm fairly certain you are not, but I mention it because this is a point of contention for me at times...I've found vtkActors to have too limited an API to be used as scene objects (e.g., no standard method exists for querying if a point is inside of them, limited concept of parent-child relationships... - they fulfill almost none of the requirements that I posted on the wiki: http://my-trac.assembla.com/protoctk/wiki/ctkScene). Perhaps RenderWindow-specific information can be broadcast via traits. Traits can be used to describe a RenderWindow (3D vs 2D, MIP transfer function, Grayscale vs Color, Interactive vs passive) and for these traits each object in the scene may optionally change its default appearance (For ObjectX, if renderWindow is 2D, grayscale, and interactive; then display ObjectX as a semi-transparent contour, and show its control points so that the contour can be edited). Any application can override these defaults with application-specific behaviour, but those settings should (perhaps?) not be stored in the scene if those settings are not inherent to the object. The reason the renderWindow is given traits instead of the object having traits is so that the application developer (who is defining the renderWindow within his/her application) can specify the general nature of how objects will appear within it so as to be most effective for the user / task. Really interesting idea about exposing the renderwindow. I need to learn/think more about that - not certain how it promotes the exchange of information between multiple views or between views and logic modules within a single application. This discussion reminds me of yet another approach...a scene rendering pipeline developed by Julien Jomier called SpatialObject Viewers. In it, each renderWindow had an objectFactory associated with it. This objectFactor would generate a different renderer for each object fed to it, based on the object's type. The application developer could choose different objectFactories (one that produced MIPs, one that was interactive, one that was 3D) for each renderWindow in the application and in that way achieve a desired behaviour/appearance. Julien presented this system to the NAMIC group years ago: http://www.na-mic.org/Wiki/images/f/.../Na-Mic-SLC05-SpatialObjects.ppt Wow, we even have a website for them (this is a surprise to me - google is amazing): http://public.kitware.com/SOViewer/ This design pattern could be extended so that the objects, by specifying how they should be viewed in renderWindows having particular traits, could influence which renderer the renderWindow's objectFactory produced for them. Furthermore, there is no need to extend a renderWindow or application as each new object type is defined. Only objectFactories need to be extended, and those are intended to be extended via shared libraries. My thoughts for the morning... Stephen On Fri, Aug 21, 2009 at 2:58 AM, Marco Viceconti wrote: > One of the goal of MAF3 is to fully separate VMEs (our data objects) from > Views and from Operations, so as to maximise reusability, and to make > possible that each of these MAF resources can be added at run time as a > plugin. > > This of course raise the debate on how to provide a neutral representation > of the visualisation components. Firstly, Stephen implies that the right > point where to cut is the scene, as most of the visualisation libraries do. > ?But I would like to bring some alternative ideas on the table: > > a) Actors. ?One could image to export single actors instead of whole scene. > ?this would reduce the granularity, and would make conceptually easier to > develop distributed applications where single actors are being > generated/updated by separate processes, and the visualisation application > has the responsibility to compose the scene with them and to render it. > Actually this idea is not necessarily in conflict with the one Stephen and > Gianluca advocate; we could image an extensibility mechanism to the scene > format, so that I can also export a single actor using the same XML syntax. > > b) ?RenderWindows: to the other extreme, in MAF we are considering to expose > out of the visualisation module not the scene, but the RenderWindow. ?The > rationale behind this is that the true conceptualisation nowadays is in > choosing for each type of actor a certain rendering style, so that > multi-actors Views produce a coherent representation. So for example, in our > MIP View volumes are rendered with a MIP visual pipe, but surfaces are > rendered with a flat surface rendering, so that it appears consistent with a > radiography-like image where geometric objects are usually man-made and thus > of homogenous opacity. ?In this perspective the View becomes like a virtual > imaging machine, which produces a visual representation for each digital > object according to the type and properties of this object in a coherent > way. > > The problem with approach b) is that I have difficulties to see how this > could be made compatible with scene approach. ?One possibility could be to > extend the XML syntax to include an optional section where one can also > specify the rendering elements; does this make any sense? > > I do not have a strong opinion on this, but I thought it might be useful we > try to thing a bit out of the box here. > > Cheers > > Marco > > > > Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto: > >> Continuing the discussion of CTK data types... >> >> I propose that we have a ctkScene as a driving datatype. >> >> First, perhaps, we need to agree on the definition of a scene. ? I >> propose that a ctkScene should have two main traits: >> >> 1) Generically, a scene is composed of objects that fill a portion of >> space and time >> * Objects have a position in space >> * Objects have an orientation in space >> * Objects have a range in time >> * Given a point in physical space and time, it should be possible to >> determine if an object contains it or not. >> * An object should contain at least one point in space and time >> * The concept of units is paramount in a scene. >> ** Units describe the spatial and chronological scale of an object >> >> 2) A scene represents a hierarchy of object in space and time. >> * Objects have a single parent (except a root object) and may have one >> or more children objects >> ** That is, a scene is a tree >> * Moving a parent object in space or time should (by default) cause >> its children to experience the same movement in space and time >> * The coordinate system for root objects is defined as "real-world" >> space. ? It is an absolute space. >> * A scene may have multiple roots >> ** It is not necessary to represent everything in space from a single >> root. >> ** One or more roots are used to contain the physical/temporal objects >> relevant to a particular task. >> * Objects implicitly include their child objects >> ** When querying the time/space extent of an object (e.g., to >> determine if a point is inside of it or to determine its bounding box) >> that query typically also includes its child objects in its >> computations. >> * Most queries to and responses from objects should be with respect to >> real-world space (i.e., the coordinate system of the root object). >> ** For example, querying an object if it contains a physical point is >> done using real-world coordinates (i.e., a coordinate system common to >> all objects in its tree). >> >> I'm adding this to the wiki at: >> http://my-trac.assembla.com/protoctk/wiki/ctkScene >> >> Stephen >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > -------------------------------------------------- > 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 Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From stephen.aylward at kitware.com Sun Aug 23 22:10:25 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 23 Aug 2009 18:10:25 -0400 Subject: [Ctk-developers] CTK Scene In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC709E2B1D1@USNWK100MSX.ww017.siemens.net> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC709E2B1D1@USNWK100MSX.ww017.siemens.net> Message-ID: <68a07c2d0908231510l5e91e052t5ca51f9e4bf9ad68@mail.gmail.com> Hi Gianluca, Good point! I am all for re-using code, and so I think we need to decide on a library, but perhaps not build one ourselves. Here is why I think we should share code for a scene, and not just file formats: 1) Widgets and display (application building): The QtWidgets being discussed by Steve, for example, include display widgets. Those are going to require us to define how images are stored in memory. Typically display widgets must handle entire scenes - they must handle the transforms between objects, handle different display methods for different objects (some as surfaces and some as volume rendering), etc etc. Also, CTK can enable application building only if its components can interoperate. We should, in my opinion, avoid trying to duplicate QtWidgets for a multitude of different scene libraries. 2) Algorithms: I tend to design algorithms that operate on scenes: registration for image guided surgery, vessel network extraction and characterization, longitudinal studies, as well as statistical atlas formation methods. These algorithms typically require full knowledge of the pose of objects in space and time, with respect to parent objects, and with respect to one another, i.e., a scene. 3) Impact: it seems like if we stop at a file format, then we miss the opportunity to re-use code and to enable the community. Promoting code re-use was a driving force in my work at UNC and now at Kitware because I believe that by making algorithms and data containers open-source, then we can have a greater impact on the field than 99.9% of the journal articles published. Coding is often viewed as an evil necessity in medical image research - but what we need to realize that source code is actually the only language in which our methods and ideas can be truly communicated. Distributing algorithms as code exposes our methods' parameters, assumptions, limitations, and real-world utility and enables others to rapidly build upon our work - journal articles typically do not). But - I do see advantages to openAPI instead of openSource in certain situations. In particular, when we develop a community around CTK, we should encourage even the non-openSource folks to participate. For example, we should avoid all GPL code that would require all source to be open. It would also be nice if we allowed for some methods to be distributed as binary-only. Or perhaps methods having non-commercial licenses. However, the core should remain BSD. My 2 cents (~0.01 euro). Stephen On Fri, Aug 21, 2009 at 12:21 PM, Paladini, Gianluca (SCR US) wrote: > Hi Marco, > I can see this concept of Actors corresponding to Open Inventor Manipulators, and the concept of RenderWindows corresponding to Open Inventor Examiners. > > Just playing devil's advocate - are we trying to reinvent the wheel? > > The goal of CTK is to provide a common set of functionality that we can all use in our respective frameworks. The idea of having a common, generalized scene graph file format that we can use to exchange information across toolkits can be very useful, but is it useful to implement a new scene graph library, knowing that there are so many off-the-shelf libraries developers can already use? > > For example in the case of XIP there is one free, open source version of Open Inventor from Sgi which we use in OpenXIP and two commercial versions from Mercury (http://www.vsg3d.com) and SystemsInMotion (http://www.coin3d.org) which we use to implement XIP-based products. Alternatively there are free open source libraries like OpenSG (http://opensg.vrsource.org/trac), OpenSceneGraph (http://www.openscenegraph.org/projects/osg), OpenRM (http://www.openrm.org), NVSG (http://developer.nvidia.com/object/nvsg_home.html). > > Since existing open source scene graph initiatives have put several years of development into their libraries, an effective way to design CTK's scene graph interchangeable file format may be to look at what exists already - a 'competitive analysis' if you will. Do you think this could be a useful exercise? I admit we only look at Open Inventor for our XML file format, therefore we may be missing support for functionality existing in other scene graph libraries. > > ?- Gianluca > > -----Original Message----- > From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward > Sent: Friday, August 21, 2009 8:20 AM > To: Marco Viceconti > Cc: ctk-developers at commontk.org > Subject: Re: [Ctk-developers] CTK Scene > > Both options have merit. > > I agree that exporting single objects should be supported. ? It allows > the system to interact with other (legacy) systems and, as you said, > provides IO flexibility. ? ?One question regarding terminology...when > you say "Actors" you are not referring to vtkActors, right? ? I'm > fairly certain you are not, but I mention it because this is a point > of contention for me at times...I've found vtkActors to have too > limited an API to be used as scene objects (e.g., no standard method > exists for querying if a point is inside of them, limited concept of > parent-child relationships... - they fulfill almost none of the > requirements that I posted on the wiki: > http://my-trac.assembla.com/protoctk/wiki/ctkScene). > > Perhaps RenderWindow-specific information can be broadcast via traits. > ?Traits can be used to describe a RenderWindow (3D vs 2D, MIP > transfer function, Grayscale vs Color, Interactive vs passive) and for > these traits each object in the scene may optionally change its > default appearance (For ObjectX, if renderWindow is 2D, ?grayscale, > and interactive; then display ObjectX as a semi-transparent contour, > and show its control points so that the contour can be edited). ? Any > application can override these defaults with application-specific > behaviour, but those settings should (perhaps?) not be stored in the > scene if those settings are not inherent to the object. ?The reason > the renderWindow is given traits instead of the object having traits > is so that the application developer (who is defining the renderWindow > within his/her application) can specify the general nature of how > objects will appear within it so as to be most effective for the user > / task. > > Really interesting idea about exposing the renderwindow. ? I need to > learn/think more about that - not certain how it promotes the exchange > of information between multiple views or between views and logic > modules within a single application. > > This discussion reminds me of yet another approach...a scene rendering > pipeline developed by Julien Jomier called SpatialObject Viewers. ? In > it, each renderWindow had an objectFactory associated with it. ?This > objectFactor would generate a different renderer for each object fed > to it, based on the object's type. ?The application developer could > choose different objectFactories (one that produced MIPs, one that was > interactive, one that was 3D) for each renderWindow in the application > and in that way achieve a desired behaviour/appearance. ? Julien > presented this system to the NAMIC group years ago: > ? http://www.na-mic.org/Wiki/images/f/.../Na-Mic-SLC05-SpatialObjects.ppt > Wow, we even have a website for them (this is a surprise to me - > google is amazing): > ? http://public.kitware.com/SOViewer/ > This design pattern could be extended so that the objects, by > specifying how they should be viewed in renderWindows having > particular traits, could influence which renderer the renderWindow's > objectFactory produced for them. ?Furthermore, there is no need to > extend a renderWindow or application as each new object type is > defined. ?Only objectFactories need to be extended, and those are > intended to be extended via shared libraries. > > My thoughts for the morning... > > Stephen > > > > On Fri, Aug 21, 2009 at 2:58 AM, Marco Viceconti wrote: >> One of the goal of MAF3 is to fully separate VMEs (our data objects) from >> Views and from Operations, so as to maximise reusability, and to make >> possible that each of these MAF resources can be added at run time as a >> plugin. >> >> This of course raise the debate on how to provide a neutral representation >> of the visualisation components. Firstly, Stephen implies that the right >> point where to cut is the scene, as most of the visualisation libraries do. >> ?But I would like to bring some alternative ideas on the table: >> >> a) Actors. ?One could image to export single actors instead of whole scene. >> ?this would reduce the granularity, and would make conceptually easier to >> develop distributed applications where single actors are being >> generated/updated by separate processes, and the visualisation application >> has the responsibility to compose the scene with them and to render it. >> Actually this idea is not necessarily in conflict with the one Stephen and >> Gianluca advocate; we could image an extensibility mechanism to the scene >> format, so that I can also export a single actor using the same XML syntax. >> >> b) ?RenderWindows: to the other extreme, in MAF we are considering to expose >> out of the visualisation module not the scene, but the RenderWindow. ?The >> rationale behind this is that the true conceptualisation nowadays is in >> choosing for each type of actor a certain rendering style, so that >> multi-actors Views produce a coherent representation. So for example, in our >> MIP View volumes are rendered with a MIP visual pipe, but surfaces are >> rendered with a flat surface rendering, so that it appears consistent with a >> radiography-like image where geometric objects are usually man-made and thus >> of homogenous opacity. ?In this perspective the View becomes like a virtual >> imaging machine, which produces a visual representation for each digital >> object according to the type and properties of this object in a coherent >> way. >> >> The problem with approach b) is that I have difficulties to see how this >> could be made compatible with scene approach. ?One possibility could be to >> extend the XML syntax to include an optional section where one can also >> specify the rendering elements; does this make any sense? >> >> I do not have a strong opinion on this, but I thought it might be useful we >> try to thing a bit out of the box here. >> >> Cheers >> >> Marco >> >> >> >> Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto: >> >>> Continuing the discussion of CTK data types... >>> >>> I propose that we have a ctkScene as a driving datatype. >>> >>> First, perhaps, we need to agree on the definition of a scene. ? I >>> propose that a ctkScene should have two main traits: >>> >>> 1) Generically, a scene is composed of objects that fill a portion of >>> space and time >>> * Objects have a position in space >>> * Objects have an orientation in space >>> * Objects have a range in time >>> * Given a point in physical space and time, it should be possible to >>> determine if an object contains it or not. >>> * An object should contain at least one point in space and time >>> * The concept of units is paramount in a scene. >>> ** Units describe the spatial and chronological scale of an object >>> >>> 2) A scene represents a hierarchy of object in space and time. >>> * Objects have a single parent (except a root object) and may have one >>> or more children objects >>> ** That is, a scene is a tree >>> * Moving a parent object in space or time should (by default) cause >>> its children to experience the same movement in space and time >>> * The coordinate system for root objects is defined as "real-world" >>> space. ? It is an absolute space. >>> * A scene may have multiple roots >>> ** It is not necessary to represent everything in space from a single >>> root. >>> ** One or more roots are used to contain the physical/temporal objects >>> relevant to a particular task. >>> * Objects implicitly include their child objects >>> ** When querying the time/space extent of an object (e.g., to >>> determine if a point is inside of it or to determine its bounding box) >>> that query typically also includes its child objects in its >>> computations. >>> * Most queries to and responses from objects should be with respect to >>> real-world space (i.e., the coordinate system of the root object). >>> ** For example, querying an object if it contains a physical point is >>> done using real-world coordinates (i.e., a coordinate system common to >>> all objects in its tree). >>> >>> I'm adding this to the wiki at: >>> http://my-trac.assembla.com/protoctk/wiki/ctkScene >>> >>> Stephen >>> >>> -- >>> Stephen R. Aylward, Ph.D. >>> Director of Medical Imaging >>> Kitware, Inc. - North Carolina Office >>> http://www.kitware.com >>> stephen.aylward (Skype) >>> (919) 969-6990 x300 >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >> >> -------------------------------------------------- >> 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 > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > 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 Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From p.quadrani at scsolutions.it Mon Aug 24 08:09:57 2009 From: p.quadrani at scsolutions.it (Quadrani Paolo) Date: Mon, 24 Aug 2009 10:09:57 +0200 Subject: [Ctk-developers] CTK Scene In-Reply-To: <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> Message-ID: <6A94DA71-96CB-433E-B1CB-9275F5BD4215@scsolutions.it> Hi Stephen, SpatialObject Viewer technique is something similar to what happen now in MAF2. A VME (Data object) is rendered with a default Visual Pipeline through a mafView, but you can customize this association at vertical application level (at compile time), so the mafView will instantiate the custom Visual Pipeline through an object factory or you can customize the association dynamically at run time. What we intend to do in MAF3 is to go a step further; abstract also the connection with the graphic engine by using adapters toward the more suitable graphic engine for fulfilling the specific task. This is the reason of the "finding the cutting point" between data and graphic that Marco was rising. Cheers. Paolo On 21/ago/09, at 14:20, Stephen Aylward wrote: > Both options have merit. > > I agree that exporting single objects should be supported. It allows > the system to interact with other (legacy) systems and, as you said, > provides IO flexibility. One question regarding terminology...when > you say "Actors" you are not referring to vtkActors, right? I'm > fairly certain you are not, but I mention it because this is a point > of contention for me at times...I've found vtkActors to have too > limited an API to be used as scene objects (e.g., no standard method > exists for querying if a point is inside of them, limited concept of > parent-child relationships... - they fulfill almost none of the > requirements that I posted on the wiki: > http://my-trac.assembla.com/protoctk/wiki/ctkScene). > > Perhaps RenderWindow-specific information can be broadcast via traits. > Traits can be used to describe a RenderWindow (3D vs 2D, MIP > transfer function, Grayscale vs Color, Interactive vs passive) and for > these traits each object in the scene may optionally change its > default appearance (For ObjectX, if renderWindow is 2D, grayscale, > and interactive; then display ObjectX as a semi-transparent contour, > and show its control points so that the contour can be edited). Any > application can override these defaults with application-specific > behaviour, but those settings should (perhaps?) not be stored in the > scene if those settings are not inherent to the object. The reason > the renderWindow is given traits instead of the object having traits > is so that the application developer (who is defining the renderWindow > within his/her application) can specify the general nature of how > objects will appear within it so as to be most effective for the user > / task. > > Really interesting idea about exposing the renderwindow. I need to > learn/think more about that - not certain how it promotes the exchange > of information between multiple views or between views and logic > modules within a single application. > > This discussion reminds me of yet another approach...a scene rendering > pipeline developed by Julien Jomier called SpatialObject Viewers. In > it, each renderWindow had an objectFactory associated with it. This > objectFactor would generate a different renderer for each object fed > to it, based on the object's type. The application developer could > choose different objectFactories (one that produced MIPs, one that was > interactive, one that was 3D) for each renderWindow in the application > and in that way achieve a desired behaviour/appearance. Julien > presented this system to the NAMIC group years ago: > http://www.na-mic.org/Wiki/images/f/.../Na-Mic-SLC05-SpatialObjects.ppt > Wow, we even have a website for them (this is a surprise to me - > google is amazing): > http://public.kitware.com/SOViewer/ > This design pattern could be extended so that the objects, by > specifying how they should be viewed in renderWindows having > particular traits, could influence which renderer the renderWindow's > objectFactory produced for them. Furthermore, there is no need to > extend a renderWindow or application as each new object type is > defined. Only objectFactories need to be extended, and those are > intended to be extended via shared libraries. > > My thoughts for the morning... > > Stephen > > > > On Fri, Aug 21, 2009 at 2:58 AM, Marco Viceconti > wrote: >> One of the goal of MAF3 is to fully separate VMEs (our data >> objects) from >> Views and from Operations, so as to maximise reusability, and to make >> possible that each of these MAF resources can be added at run time >> as a >> plugin. >> >> This of course raise the debate on how to provide a neutral >> representation >> of the visualisation components. Firstly, Stephen implies that the >> right >> point where to cut is the scene, as most of the visualisation >> libraries do. >> But I would like to bring some alternative ideas on the table: >> >> a) Actors. One could image to export single actors instead of >> whole scene. >> this would reduce the granularity, and would make conceptually >> easier to >> develop distributed applications where single actors are being >> generated/updated by separate processes, and the visualisation >> application >> has the responsibility to compose the scene with them and to render >> it. >> Actually this idea is not necessarily in conflict with the one >> Stephen and >> Gianluca advocate; we could image an extensibility mechanism to the >> scene >> format, so that I can also export a single actor using the same XML >> syntax. >> >> b) RenderWindows: to the other extreme, in MAF we are considering >> to expose >> out of the visualisation module not the scene, but the >> RenderWindow. The >> rationale behind this is that the true conceptualisation nowadays >> is in >> choosing for each type of actor a certain rendering style, so that >> multi-actors Views produce a coherent representation. So for >> example, in our >> MIP View volumes are rendered with a MIP visual pipe, but surfaces >> are >> rendered with a flat surface rendering, so that it appears >> consistent with a >> radiography-like image where geometric objects are usually man-made >> and thus >> of homogenous opacity. In this perspective the View becomes like a >> virtual >> imaging machine, which produces a visual representation for each >> digital >> object according to the type and properties of this object in a >> coherent >> way. >> >> The problem with approach b) is that I have difficulties to see how >> this >> could be made compatible with scene approach. One possibility >> could be to >> extend the XML syntax to include an optional section where one can >> also >> specify the rendering elements; does this make any sense? >> >> I do not have a strong opinion on this, but I thought it might be >> useful we >> try to thing a bit out of the box here. >> >> Cheers >> >> Marco >> >> >> >> Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto: >> >>> Continuing the discussion of CTK data types... >>> >>> I propose that we have a ctkScene as a driving datatype. >>> >>> First, perhaps, we need to agree on the definition of a scene. I >>> propose that a ctkScene should have two main traits: >>> >>> 1) Generically, a scene is composed of objects that fill a portion >>> of >>> space and time >>> * Objects have a position in space >>> * Objects have an orientation in space >>> * Objects have a range in time >>> * Given a point in physical space and time, it should be possible to >>> determine if an object contains it or not. >>> * An object should contain at least one point in space and time >>> * The concept of units is paramount in a scene. >>> ** Units describe the spatial and chronological scale of an object >>> >>> 2) A scene represents a hierarchy of object in space and time. >>> * Objects have a single parent (except a root object) and may have >>> one >>> or more children objects >>> ** That is, a scene is a tree >>> * Moving a parent object in space or time should (by default) cause >>> its children to experience the same movement in space and time >>> * The coordinate system for root objects is defined as "real-world" >>> space. It is an absolute space. >>> * A scene may have multiple roots >>> ** It is not necessary to represent everything in space from a >>> single >>> root. >>> ** One or more roots are used to contain the physical/temporal >>> objects >>> relevant to a particular task. >>> * Objects implicitly include their child objects >>> ** When querying the time/space extent of an object (e.g., to >>> determine if a point is inside of it or to determine its bounding >>> box) >>> that query typically also includes its child objects in its >>> computations. >>> * Most queries to and responses from objects should be with >>> respect to >>> real-world space (i.e., the coordinate system of the root object). >>> ** For example, querying an object if it contains a physical point >>> is >>> done using real-world coordinates (i.e., a coordinate system >>> common to >>> all objects in its tree). >>> >>> I'm adding this to the wiki at: >>> http://my-trac.assembla.com/protoctk/wiki/ctkScene >>> >>> Stephen >>> >>> -- >>> Stephen R. Aylward, Ph.D. >>> Director of Medical Imaging >>> Kitware, Inc. - North Carolina Office >>> http://www.kitware.com >>> stephen.aylward (Skype) >>> (919) 969-6990 x300 >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >> >> -------------------------------------------------- >> 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 > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers Paolo Quadrani _________________________________ BioComputing Competence Centre SCS s.r.l. Via Magnanelli 6/3, 40033 Casalecchio di Reno Italy From stephen.aylward at kitware.com Mon Aug 24 14:53:40 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 24 Aug 2009 10:53:40 -0400 Subject: [Ctk-developers] CTK Scene In-Reply-To: <6A94DA71-96CB-433E-B1CB-9275F5BD4215@scsolutions.it> References: <68a07c2d0908201539n2a1dc14ek79c58427f09572c5@mail.gmail.com> <6632EC83-4CBD-4EE7-BBBC-C9F5E74933B8@tecno.ior.it> <68a07c2d0908210520k5549e6d1tab7978a97b1ddf9a@mail.gmail.com> <6A94DA71-96CB-433E-B1CB-9275F5BD4215@scsolutions.it> Message-ID: <68a07c2d0908240753o20572badxe02d2d747dc4bcef@mail.gmail.com> Following Gianluca's suggestion, I'm compiling a list of scene libraries on the wiki at: http://my-trac.assembla.com/protoctk/wiki/ctkScene I'd like to then evaluate each with respect to the requirements we've listed on that page. So, if you have any suggestions for changes / additions to the requirements, please add them to the page or send them to the list via email. Thanks, Stephen On Mon, Aug 24, 2009 at 4:09 AM, Quadrani Paolo wrote: > Hi Stephen, > SpatialObject Viewer technique is something similar to what happen now in > MAF2. > A VME (Data object) is rendered with a default Visual Pipeline through a > mafView, but you can customize this association at vertical application > level (at compile time), so the mafView will instantiate the custom Visual > Pipeline through an object factory or you can customize the association > dynamically at run time. > What we intend to do in MAF3 is to go a step further; abstract also the > connection with the graphic engine by using adapters toward the more > suitable graphic engine for fulfilling the specific task. This is the reason > of the "finding the cutting point" between data and graphic that Marco was > rising. > Cheers. > > Paolo > > On 21/ago/09, at 14:20, Stephen Aylward wrote: > >> Both options have merit. >> >> I agree that exporting single objects should be supported. ? It allows >> the system to interact with other (legacy) systems and, as you said, >> provides IO flexibility. ? ?One question regarding terminology...when >> you say "Actors" you are not referring to vtkActors, right? ? I'm >> fairly certain you are not, but I mention it because this is a point >> of contention for me at times...I've found vtkActors to have too >> limited an API to be used as scene objects (e.g., no standard method >> exists for querying if a point is inside of them, limited concept of >> parent-child relationships... - they fulfill almost none of the >> requirements that I posted on the wiki: >> http://my-trac.assembla.com/protoctk/wiki/ctkScene). >> >> Perhaps RenderWindow-specific information can be broadcast via traits. >> ?Traits can be used to describe a RenderWindow (3D vs 2D, MIP >> transfer function, Grayscale vs Color, Interactive vs passive) and for >> these traits each object in the scene may optionally change its >> default appearance (For ObjectX, if renderWindow is 2D, ?grayscale, >> and interactive; then display ObjectX as a semi-transparent contour, >> and show its control points so that the contour can be edited). ? Any >> application can override these defaults with application-specific >> behaviour, but those settings should (perhaps?) not be stored in the >> scene if those settings are not inherent to the object. ?The reason >> the renderWindow is given traits instead of the object having traits >> is so that the application developer (who is defining the renderWindow >> within his/her application) can specify the general nature of how >> objects will appear within it so as to be most effective for the user >> / task. >> >> Really interesting idea about exposing the renderwindow. ? I need to >> learn/think more about that - not certain how it promotes the exchange >> of information between multiple views or between views and logic >> modules within a single application. >> >> This discussion reminds me of yet another approach...a scene rendering >> pipeline developed by Julien Jomier called SpatialObject Viewers. ? In >> it, each renderWindow had an objectFactory associated with it. ?This >> objectFactor would generate a different renderer for each object fed >> to it, based on the object's type. ?The application developer could >> choose different objectFactories (one that produced MIPs, one that was >> interactive, one that was 3D) for each renderWindow in the application >> and in that way achieve a desired behaviour/appearance. ? Julien >> presented this system to the NAMIC group years ago: >> ?http://www.na-mic.org/Wiki/images/f/.../Na-Mic-SLC05-SpatialObjects.ppt >> Wow, we even have a website for them (this is a surprise to me - >> google is amazing): >> ?http://public.kitware.com/SOViewer/ >> This design pattern could be extended so that the objects, by >> specifying how they should be viewed in renderWindows having >> particular traits, could influence which renderer the renderWindow's >> objectFactory produced for them. ?Furthermore, there is no need to >> extend a renderWindow or application as each new object type is >> defined. ?Only objectFactories need to be extended, and those are >> intended to be extended via shared libraries. >> >> My thoughts for the morning... >> >> Stephen >> >> >> >> On Fri, Aug 21, 2009 at 2:58 AM, Marco Viceconti >> wrote: >>> >>> One of the goal of MAF3 is to fully separate VMEs (our data objects) from >>> Views and from Operations, so as to maximise reusability, and to make >>> possible that each of these MAF resources can be added at run time as a >>> plugin. >>> >>> This of course raise the debate on how to provide a neutral >>> representation >>> of the visualisation components. Firstly, Stephen implies that the right >>> point where to cut is the scene, as most of the visualisation libraries >>> do. >>> ?But I would like to bring some alternative ideas on the table: >>> >>> a) Actors. ?One could image to export single actors instead of whole >>> scene. >>> ?this would reduce the granularity, and would make conceptually easier to >>> develop distributed applications where single actors are being >>> generated/updated by separate processes, and the visualisation >>> application >>> has the responsibility to compose the scene with them and to render it. >>> Actually this idea is not necessarily in conflict with the one Stephen >>> and >>> Gianluca advocate; we could image an extensibility mechanism to the scene >>> format, so that I can also export a single actor using the same XML >>> syntax. >>> >>> b) ?RenderWindows: to the other extreme, in MAF we are considering to >>> expose >>> out of the visualisation module not the scene, but the RenderWindow. ?The >>> rationale behind this is that the true conceptualisation nowadays is in >>> choosing for each type of actor a certain rendering style, so that >>> multi-actors Views produce a coherent representation. So for example, in >>> our >>> MIP View volumes are rendered with a MIP visual pipe, but surfaces are >>> rendered with a flat surface rendering, so that it appears consistent >>> with a >>> radiography-like image where geometric objects are usually man-made and >>> thus >>> of homogenous opacity. ?In this perspective the View becomes like a >>> virtual >>> imaging machine, which produces a visual representation for each digital >>> object according to the type and properties of this object in a coherent >>> way. >>> >>> The problem with approach b) is that I have difficulties to see how this >>> could be made compatible with scene approach. ?One possibility could be >>> to >>> extend the XML syntax to include an optional section where one can also >>> specify the rendering elements; does this make any sense? >>> >>> I do not have a strong opinion on this, but I thought it might be useful >>> we >>> try to thing a bit out of the box here. >>> >>> Cheers >>> >>> Marco >>> >>> >>> >>> Il giorno 21/ago/09, alle ore 00:39, Stephen Aylward ha scritto: >>> >>>> Continuing the discussion of CTK data types... >>>> >>>> I propose that we have a ctkScene as a driving datatype. >>>> >>>> First, perhaps, we need to agree on the definition of a scene. ? I >>>> propose that a ctkScene should have two main traits: >>>> >>>> 1) Generically, a scene is composed of objects that fill a portion of >>>> space and time >>>> * Objects have a position in space >>>> * Objects have an orientation in space >>>> * Objects have a range in time >>>> * Given a point in physical space and time, it should be possible to >>>> determine if an object contains it or not. >>>> * An object should contain at least one point in space and time >>>> * The concept of units is paramount in a scene. >>>> ** Units describe the spatial and chronological scale of an object >>>> >>>> 2) A scene represents a hierarchy of object in space and time. >>>> * Objects have a single parent (except a root object) and may have one >>>> or more children objects >>>> ** That is, a scene is a tree >>>> * Moving a parent object in space or time should (by default) cause >>>> its children to experience the same movement in space and time >>>> * The coordinate system for root objects is defined as "real-world" >>>> space. ? It is an absolute space. >>>> * A scene may have multiple roots >>>> ** It is not necessary to represent everything in space from a single >>>> root. >>>> ** One or more roots are used to contain the physical/temporal objects >>>> relevant to a particular task. >>>> * Objects implicitly include their child objects >>>> ** When querying the time/space extent of an object (e.g., to >>>> determine if a point is inside of it or to determine its bounding box) >>>> that query typically also includes its child objects in its >>>> computations. >>>> * Most queries to and responses from objects should be with respect to >>>> real-world space (i.e., the coordinate system of the root object). >>>> ** For example, querying an object if it contains a physical point is >>>> done using real-world coordinates (i.e., a coordinate system common to >>>> all objects in its tree). >>>> >>>> I'm adding this to the wiki at: >>>> http://my-trac.assembla.com/protoctk/wiki/ctkScene >>>> >>>> Stephen >>>> >>>> -- >>>> Stephen R. Aylward, Ph.D. >>>> Director of Medical Imaging >>>> Kitware, Inc. - North Carolina Office >>>> http://www.kitware.com >>>> stephen.aylward (Skype) >>>> (919) 969-6990 x300 >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>> >>> -------------------------------------------------- >>> 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 >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > Paolo Quadrani > _________________________________ > BioComputing Competence Centre > SCS s.r.l. > > Via Magnanelli 6/3, 40033 > Casalecchio di Reno > Italy > > > > > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From viceconti at tecno.ior.it Sat Aug 29 10:00:06 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Sat, 29 Aug 2009 12:00:06 +0200 Subject: [Ctk-developers] more on CTK Scene Message-ID: <5C24AECB-0DB7-410D-BF95-656266070C8C@tecno.ior.it> Let me think aloud. CTK modules will create data objects that we want visualise. These objects are made into scene actors, a scene around them is defined, and (usually through a visualisation library) a render view is returned. If the the visualisation is interactive, in addition to this I need to define an interaction style, and I might need to add inside the scene additional service actors such as handlers that exist only to sustain a certain interaction. The I need to connect the interactions with my interaction hardware, and with the rest of the GUI. In many of our applications there is an additional level of complexity, when an interaction does not change only a parameter of the scene of its rendering, but it actually modify an actor. For CTK I can see two possible options: a) The quantum of encapsulation in the View. A CTK View is a module that can take as input standards CTK Data Objects ( I here postulate CTK will have a unique Data Object Model) and return a render window. In addition, the View exposes some interaction styles, that must be connected to actual interactions, and a number of View Settings, that the application must capture and pass to the View (typically via a GUI). Each view run a separate thread, and connects with the rest of the application through a limited set of public APIs. a Facade class prevents any access to internal methods, and makes easier the wrapping into scripting languages. So for a programmer writing a CTK-based application a View is something he can use as it is or not, but cannot be modified (except of course changing the code of the view itself). Which visualisation library is used inside each view is immaterial. The View programmer has the responsibility to transform the CTK Data Objects into Actors compatible with VTK, Open Inventor or whatever he plans to use for that view. Similarly, it is his responsibility to transform the rendering output of the visualisation library into a CTK Render Window. In the picture below the CTK View would be the blue box. b) The quantum of encapsulation is the scene. CTK provides classes that automatically compose data objects into actors and these into scenes, and expose such scene in a way that is neutral to the visualisation library. Each application programmer is responsible to decide what to do with this scene, but in principle CTK could also provide additional modules for interactive rendering. The scene composer module is the red box, and the interactive rendering module is the brown box. I personally believe that we would have an advantage with option b) only if the brown box could be entirely replaced by an existing visualisation library; unfortunately I suspect this is not the case: - Most scengraph libraries treat only vector data + textures; extensions are needed for example to render volumes - Most complex interaction styles cannot be encoded in the scenegraph, and need to be programmed with direct calls to the visualisation library. - No visualisation library could provide you out-of-the-box mechanism to modify CTK data objects from interaction. This means in most realistic cases the application programmer should anyway cross the brown box and code directly with the visualisation library calls. This is why we consider option a) the most interesting for CTK. If you are an application programmer you use pre-packged View modules, and you just have to pass your data object, attache your interaction devices to the pre-defined interaction styles, and expose in your GUI the View settings, and the render window: done. If you need a special View, then of course you need to dirt your hands with a visualisation library, but this would happen anyway. CTK community could provide template of View modules to be programmed with VTK, Open Inventor, OpenSG, etc. to make life easier. Added these notes and the figure to the wiki: http://my-trac.assembla.com/protoctk/wiki/ctkScene cheers Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: ctk_view_encapsualtion.gif Type: image/gif Size: 7792 bytes Desc: not available URL: -------------- next part -------------- -------------------------------------------------- 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 From stephen.aylward at kitware.com Sun Aug 30 03:23:28 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sat, 29 Aug 2009 23:23:28 -0400 Subject: [Ctk-developers] more on CTK Scene In-Reply-To: <5C24AECB-0DB7-410D-BF95-656266070C8C@tecno.ior.it> References: <5C24AECB-0DB7-410D-BF95-656266070C8C@tecno.ior.it> Message-ID: <68a07c2d0908292023q209dfce6wcf2a2000dfcb6149@mail.gmail.com> Hi Marco, I'm sorry, but I'm having trouble following your email because I am not certain of the definition of a few of the terms you are using (i.e., what is an actor and how is it different than an object? Also, what is an interactor? Do you mean VTKActors and VTKInteractors?), and I think you are suggesting that graphics primitives should be contained within our scene / objects and that breaks our model-view-controller design pattern. My preference is to follow the scene design in ITK. The ITK SpatialObjects scene are quite different that those used by scengraphs in visualization libraries. We can use those ITK scenes for algorithms to perform registration, store results of segmentations, manage longitudinal and multiscale data, etc etc, There is no reason to incorporate a visualization library into our data containers, i.e., our scenes. It would unnecessarily burden the algorithm developers, require inclusion of a visualization library when all that we want to do is process data, and, as I mentioned, break our model-view-controller design pattern. Thanks, Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300