From p.quadrani at scsolutions.it Thu Sep 10 11:11:04 2009 From: p.quadrani at scsolutions.it (Quadrani Paolo) Date: Thu, 10 Sep 2009 13:11:04 +0200 Subject: [Ctk-developers] more on CTK Scene Message-ID: Dear Stephen: sorry for the late reply, but Marco email and your reply started a discussion inside MAF developers group that took some time to come to a consensus. Here is our reply as a group. Traditionally, data objects contain only data, but not space- hierarchical information; this is defined in the scene. However, complex environments like ITK or MAF implement a different approach where all data objects are posed in an absolute space. ITK SpatialObjects and MAF VmeTree are surprisingly similar in this respect, with the parent-child and absolute poses. There is also consensus on the fact that the data objects should be separated by the graphic primitives we use to visualise them, in respect to the MVC pattern. the point Marco was trying to make is different. We can imagine the future CTK architecture as organised around components that can be plugged and replaced as transparently as possible. So we can imagine to have a module where the data objects are defined, and also their spatial containers (SpatialObjects / VmeTree). We should be able to take one spatial container from this module and give it to another module that is in charge of its visualisation. There are two problems that we are trying to solve: a) the data object module should be independent from the visualisation library in use. b) in general the Data Object Model required by a complex library such as CTK is much broader than that is typically supported by some visualisation libraries. This means that before I can pass my data object to the visualisation library I have to transform it in order to be presented to the rendering library and to be used. We see two options possible: 1) Create for each CTK Data Object type a series of adapters that "present" that data object as expected by a certain visualisation library without duplicating it in memory. So our ctkVolume object would have an adapter for VTK, one for OpenInventor, etc. an object like ctkMeshHermite, which has not reasonable counterpart in any visualisation library, would require a downcasting adapter, that convert the Hermitian cells into lower order cells for the shake of visualisation. If these adapters can be done, we could have a CTK data objects module, which can be connected to any visualisation component done with any of the libraries for which adapters are available. 2) Create a CTK Scene module that takes in input whatever CTK data object (or spatial container of data objects), convert it to a suitable graphic primitive, let you add camera, lights, and any other scene element, and output a representation of the rendering scene made of primitives that every visualization library can render. In this case the downcasting would be done in this ctkScene module, and the scene format could then be visualised with any library. To use vtk examples many of us understand, a ctkVolume object in the first case would have a vtk adapter that "present" it as vtkVolume. This is passed for example to a standard VTK pipeline for isosurface visualisation. In the second case the ctk Volume would be passed to the ctkScene module where we would define an isosurface visualisation, extract the isosurface, set suface rendering elements, create the scene, and pass it to a visualisation library via a neutral scene description. To us, if the adapter approach (solution 1) is viable, it looks much more elegant. cheers the MAF gang _________________________________ BioComputing Competence Centre SCS s.r.l. Via Magnanelli 6/3, 40033 Casalecchio di Reno Italy From stephen.aylward at kitware.com Thu Sep 10 16:42:28 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 10 Sep 2009 12:42:28 -0400 Subject: [Ctk-developers] more on CTK Scene In-Reply-To: References: Message-ID: <68a07c2d0909100942g230a65eaj48ca40ff68ae847c@mail.gmail.com> Hi Paolo, You (the MAF gang) summarized the issues and options very well! Thank you. I agree that if option 1 is feasible, it would be more elegant, and I think it is feasible. Really looking forward to the meeting in Oxford to discuss this face-to-face. I think a few more drawings, similar to what Marco started, will be very helpful and set a clear path for us. Thanks! Stephen On Thu, Sep 10, 2009 at 7:11 AM, Quadrani Paolo wrote: > Dear Stephen: > ?sorry for the late reply, but Marco email and your reply started a > discussion inside MAF developers group that took some time to come to > a consensus. Here is our reply as a group. > > Traditionally, data objects contain only data, but not space-hierarchical > information; > this is defined in the scene. However, complex environments like ITK or MAF > implement a different approach where all data objects are posed in an > absolute space. ITK SpatialObjects and ?MAF VmeTree are surprisingly > similar in this respect, with the parent-child and absolute poses. > > There is also consensus on the fact that the data objects should be > separated by the graphic primitives we use to visualise them, in > respect to the MVC pattern. > > the point Marco was trying to make is different. We can imagine the > future CTK architecture as organised around components that can be > plugged and replaced as transparently as possible. So we can imagine > to have a module where the data objects are defined, and also their > spatial containers (SpatialObjects / VmeTree). ?We should be able to > take one spatial container from this module and give it to another > module that is in charge of its visualisation. ?There are two problems > that we are trying to solve: > > a) the data object module should be independent from the visualisation > library in use. > > b) in general the Data Object Model required by a complex library such > as CTK is much broader than that is typically supported by > some visualisation libraries. ?This means that before I can pass my data > object to the visualisation library I have to transform it in order to be > presented > to the rendering library and to be used. > > We see two options possible: > > 1) Create for each CTK Data Object type a series of adapters that > "present" that data object as expected by a certain visualisation > library without duplicating it in memory. ?So our ctkVolume object > would have an adapter for VTK, one for OpenInventor, etc. ?an object > like ctkMeshHermite, which has ?not reasonable counterpart in any > visualisation library, would require a downcasting adapter, that > convert the Hermitian cells into lower order cells for the shake of > visualisation. ?If these adapters can be done, we could have a CTK > data objects module, which can be connected to any visualisation > component done with any of the libraries for which adapters are > available. > > 2) Create a CTK Scene module that takes in input whatever CTK data > object (or spatial container of data objects), convert it to a > suitable graphic primitive, let you add camera, lights, and any other > scene element, and output a representation of the rendering > scene made of primitives that every visualization library can render. > In this case the downcasting would be done in this ctkScene module, > and the scene format could then be visualised with any library. > > To use vtk examples many of us understand, a ctkVolume object in > the first case would have a vtk adapter that "present" it as vtkVolume. > This is passed for example to a standard VTK pipeline for isosurface > visualisation. > > In the second case the ctk Volume would be passed to the ctkScene > module where we would define an isosurface visualisation, extract the > isosurface, set suface rendering elements, create the scene, and pass > it to a visualisation library via a neutral scene description. > > To us, if the adapter approach (solution 1) is viable, it looks much more > elegant. > > cheers > > the MAF gang > > _________________________________ > 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 > -- 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 Mon Sep 14 21:02:42 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Mon, 14 Sep 2009 14:02:42 -0700 Subject: [Ctk-developers] CTK meeting in Oxford - any vegetarians? In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC709DCE078@USNWK100MSX.ww017.siemens.net> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A0AF21C@USNWK100MSX.ww017.siemens.net> Hello all, Please let me know if there are any vegetarians in the group, Charlotte is putting together a menu for the first dinner in Oxford on the 24th and the hotel can provide only two choices of each appetizer, main course and dessert. Thanks, Gianluca From kikinis at bwh.harvard.edu Tue Sep 15 11:45:11 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Tue, 15 Sep 2009 07:45:11 -0400 Subject: [Ctk-developers] CTK meeting in Oxford - status update In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC709DCE078@USNWK100MSX.ww017.siemens.net> References: <38E3A921A2B9FC46B02E566BDED7CF4E01F90CF9@oxfw0e1a.ww001.siemens.net> <849860E57EBCC34C9E28B6E59A046CC709DCE078@USNWK100MSX.ww017.siemens.net> Message-ID: <4AAF7E47.8070309@bwh.harvard.edu> http://wiki.na-mic.org/Wiki/index.php/Events:CTK-Workshop-September-2009 Hi, I have started a wiki page for our upcoming meeting. I cloned part of the page of the Heidelberg meeting as a startpoint. Please review and edit as appropriate. Gianluca, would you mind inserting the correct names, URL's and pictures? Also, logistics? Anybody wants to take a stab at the agenda Ron Paladini, Gianluca (SCR US) wrote: > 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 -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From gianluca.paladini at siemens.com Wed Sep 16 23:37:30 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Wed, 16 Sep 2009 16:37:30 -0700 Subject: [Ctk-developers] FW: United Kingdom: Train drivers' union cancels six-day strike after pay deal agreed Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A0F7D5C@USNWK100MSX.ww017.siemens.net> Turns out the train strike between 9/21-9/26 has been canceled. That's a relief! ________________________________ From: International SOS Security Advisories [mailto:secalerts at internationalsos.com] Sent: Wednesday, September 16, 2009 3:15 PM To: Paladini, Gianluca (SCR US) Subject: United Kingdom: Train drivers' union cancels six-day strike after pay deal agreed Security Contact Americas (1) (215) 942 8226 Asia/Pacific (65) 6338 7800 Europe/Africa (44) (20) 8762 8008 Paris, France (33) (0) 155 633 155 Security Situation Updates United Kingdom Train drivers' union cancels six-day strike after pay deal agreed Created: September 16, 2009 17:15 GMT Updated: September 16, 2009 19:13 GMT A proposed six-day strike by National Express East Anglia (NEEA) train drivers belonging to the Associated Society of Locomotive Engineers and Firemen (ASLEF) on 16 September was called off. The move came after the union reached an agreement on its members' salaries with the NEEA management. Comment and Analysis The industrial action would have significantly affected NEEA services between the capital London, various destinations in the Greater London area and the counties of Essex, Cambridgeshire, Hertfordshire, Suffolk and Norfolk. Another planned work stoppage threatening rail services was recently averted when a 24-hour strike by employees of First Capital Connect (FCC) affiliated to the National Union of Rail, Maritime and Transport Workers (RMT) was cancelled; the decision followed successful negotiations between the union and the FCC management. Several strikes by RMT and ASLEF members over similar issues have taken place in recent months. A work stoppage on 6-7 August by NEEA drivers caused severe disruption to services on all the operator's routes. Previously, RMT-affiliated employees of the London Underground (LU, subway) on 30-31 July staged a 48-hour strike in connection with a pay dispute; around 100 services ran during the industrial action compared to the usual 1,800. A similar strike by LU workers on 10-11 June caused widespread disruption. Travel Advice * Personnel are advised to monitor the local media and our website for the latest updates on planned industrial action affecting business travel. United Kingdom 1b This is a follow-up alert based upon the pre-travel advisory email you received for your destination. Please note that the follow-up alerts are sent to you just for the duration of your trip in order to notify you about the health and safety risks in your destination. If you have any questions, please contact onlinehelp at internationalsos.com . Important Notice: This communication (including any attachments) is for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.aylward at kitware.com Thu Sep 17 00:18:58 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Wed, 16 Sep 2009 20:18:58 -0400 Subject: [Ctk-developers] Scenes Message-ID: <68a07c2d0909161718w313a4035t871e89c00c589a84@mail.gmail.com> Hi, ctkScene: Love it? Hate it? Know you can make it better? Regardless of your current attitude, please send me your ideas and presentations!!! I'd like to help organize the discussion on ctkScene that is scheduled for next Friday. 1) If you are interested in making a brief presentation (less than 10 minutes), then please send me an email with the title. I will add it into our agenda. 2) If you have revisions to the Wiki page on ctkScene - please make those revisions by 5pm EST (22:00 GMT) on Friday. I am going to summarize those wiki pages as a set of slides at the start of the meeting. http://my-trac.assembla.com/protoctk/wiki/ctkScene 3) If you have questions, concerns, needs, wants, or rants regarding the ctkScene, please send them to me and I will create a set of slides that list "open-issues" to help focus our discussions. We only have one-hour, so I'd like to focus on high-level issues that remain, prior to getting into implementation details. For example, should a ctkScene be only a file format or should it also be implemented as a set of C++ classes? Should a ctkScene be specific to or independent of the visualization library? Should a ctkScene be our primary data structure, or should our primary data structure simply be an image? ...please add to this list of questions... 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 gianluca.paladini at siemens.com Thu Sep 17 01:05:13 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Wed, 16 Sep 2009 18:05:13 -0700 Subject: [Ctk-developers] Scenes In-Reply-To: <68a07c2d0909161718w313a4035t871e89c00c589a84@mail.gmail.com> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A0F7D87@USNWK100MSX.ww017.siemens.net> Here is a condensed list based on emails I wrote before (included below) - I think Stephen summarized a lot of it already in the Wiki page, but I would like this to be included at the end of the Wiki page as my suggestions: 1) We need a common, generalized scene graph file format that we can use to exchange information across toolkits 2) It is not useful to implement a new scene graph library - there are so many off-the-shelf scene graph-based toolkits already, some very good 3) XML is a good choice for an easy to parse scene graph file. Ideally this XML file could be parsed and translated to object instances from any scene graph library. The XML format should be organized in different sections to facilitate parsing in a fault-tolerant way. This is because a C++ scene graph object that has been modified by a software developer may get out of sync from the corresponding description found in the scene graph file. 4) The structure of such XML scene graph file format must not change drastically if a user loads a scene graph file, makes a simple change to the scene graph and saves it again. It should be possible to use a diff-and-merge tool like the ones used for source code in order to see where specific changes occurred. This is a must-have in order to be able to work on large projects with multiple developers. 5) The file must allow for the inclusion of information stored in separate files, in the form of nodes that load "sub-graphs". This is the equivalent of #include files in C++ code, and it is another must-have in large projects with multiple developers. 6) The format should include, at least optionally, additional presentation information about each scene graph object so that a Visual Programming environment can save and restore the way a developer has arranged scene graph objects within the workspace (position, grouping, etc.) Needless to say, this is what we have implemented for the new XML-based XIP scene graph file format - except for (1): so far we looked primarily into Open Inventor, and there are still open questions about whether this format is general-purpose enough. We'll give it a try for a while ;-) Cordially, Gianluca -----Original Message----- From: Paladini, Gianluca (SCR US) Sent: Friday, August 21, 2009 12:22 PM To: Marco Viceconti Cc: Stephen Aylward; ctk-developers at commontk.org Subject: RE: [Ctk-developers] CTK Scene 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: Paladini, Gianluca (SCR US) Sent: Thursday, August 20, 2009 10:32 PM To: Stephen Aylward Cc: ctk-developers at commontk.org Subject: RE: [Ctk-developers] CTK Scene 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: Paladini, Gianluca (SCR US) Sent: Thursday, August 20, 2009 9:38 PM To: Stephen Aylward; ctk-developers at commontk.org Subject: RE: [Ctk-developers] CTK Scene 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: Wednesday, September 16, 2009 8:19 PM To: ctk-developers at commontk.org Subject: [Ctk-developers] Scenes Hi, ctkScene: Love it? Hate it? Know you can make it better? Regardless of your current attitude, please send me your ideas and presentations!!! I'd like to help organize the discussion on ctkScene that is scheduled for next Friday. 1) If you are interested in making a brief presentation (less than 10 minutes), then please send me an email with the title. I will add it into our agenda. 2) If you have revisions to the Wiki page on ctkScene - please make those revisions by 5pm EST (22:00 GMT) on Friday. I am going to summarize those wiki pages as a set of slides at the start of the meeting. http://my-trac.assembla.com/protoctk/wiki/ctkScene 3) If you have questions, concerns, needs, wants, or rants regarding the ctkScene, please send them to me and I will create a set of slides that list "open-issues" to help focus our discussions. We only have one-hour, so I'd like to focus on high-level issues that remain, prior to getting into implementation details. For example, should a ctkScene be only a file format or should it also be implemented as a set of C++ classes? Should a ctkScene be specific to or independent of the visualization library? Should a ctkScene be our primary data structure, or should our primary data structure simply be an image? ...please add to this list of questions... 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 _______________________________________________ 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 Wed Sep 16 22:16:12 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Wed, 16 Sep 2009 15:16:12 -0700 Subject: [Ctk-developers] CTK meeting in Oxford - status update In-Reply-To: <4AAF7E47.8070309@bwh.harvard.edu> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A0F7CF2@USNWK100MSX.ww017.siemens.net> Hi Ron, I made a few changes to the agenda and added a list of participants and a couple of URL's. The agenda reflects what Charlotte Fenton has setup for us there, I hope everything works out. It looks like we won't have a chance to go back to the hotel before dinner because it's a couple of miles away from the Siemens office. Instead Charlotte and Jerome would like to walk us around Oxford and show us a few landmarks on the way to a Pub, and then go to a restaurant at a walking distance. Has everyone made plans to get to the Barcel? hotel from London/MICCAI yet? Beware of a rail strike planned on Sept. 21-26, I am not sure which trains will be affected and I am thinking about going by bus instead. Cheers, Gianluca -----Original Message----- From: Ron Kikinis [mailto:kikinis at bwh.harvard.edu] Sent: Tuesday, September 15, 2009 7:45 AM To: Paladini, Gianluca (SCR US) Cc: Meinzer Hans-Peter; Stephen Aylward; Kevin Cleary; Marco Viceconti; ctk-developers at commontk.org; dclunie at dclunie.com; Nicholas Ayache; Andreas Engelke; Nolden Marco; Wolf Ivo; Hauser Stefanie; Steve Pieper; Olivier Clatz; Dunning Janina; WINTZ Julien; Christian Renner; Quadrani Paolo; Lawrence Tarbox; Engelmann Uwe; Michael Onken (OFFIS); FENTON, CHARLOTTE Subject: Re: CTK meeting in Oxford - status update http://wiki.na-mic.org/Wiki/index.php/Events:CTK-Workshop-September-2009 Hi, I have started a wiki page for our upcoming meeting. I cloned part of the page of the Heidelberg meeting as a startpoint. Please review and edit as appropriate. Gianluca, would you mind inserting the correct names, URL's and pictures? Also, logistics? Anybody wants to take a stab at the agenda Ron Paladini, Gianluca (SCR US) wrote: > 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 -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From stephen.aylward at kitware.com Thu Sep 17 18:38:50 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 17 Sep 2009 14:38:50 -0400 Subject: [Ctk-developers] Scenes In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC70A0F80D3@USNWK100MSX.ww017.siemens.net> References: <68a07c2d0909161718w313a4035t871e89c00c589a84@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC70A0F80D3@USNWK100MSX.ww017.siemens.net> Message-ID: <68a07c2d0909171138y62835e9cv156e1c66e2c1660b@mail.gmail.com> Hi, If you would like to edit the CTK wiki pages, create a login and then send me or Steve Pieper an email letting us know the login you created. We can then give you authorization to edit the pages, submit code, etc. Also - the wiki page on ctkScene have been updated to include comments from Gianluca and Pat. Please review / edit to make sure I got them right. Stephen On Thu, Sep 17, 2009 at 12:34 PM, Paladini, Gianluca (SCR US) wrote: > Hi Stephen, > How do you edit these Wiki pages under Trac? Do I have to request a > login somewhere? > Cheers, > ? ?Gianluca > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen > Aylward > Sent: Wednesday, September 16, 2009 8:19 PM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] Scenes > > Hi, > > ctkScene: ?Love it? ?Hate it? ?Know you can make it better? > > Regardless of your current attitude, please send me your ideas and > presentations!!! > > I'd like to help organize the discussion on ctkScene that is scheduled > for next Friday. > > 1) If you are interested in making a brief presentation (less than 10 > minutes), then please send me an email with the title. ? I will add it > into our agenda. > > 2) If you have revisions to the Wiki page on ctkScene - please make > those revisions by 5pm EST (22:00 GMT) on Friday. ? I am going to > summarize those wiki pages as a set of slides at the start of the > meeting. > ? ? ?http://my-trac.assembla.com/protoctk/wiki/ctkScene > > 3) If you have questions, concerns, needs, wants, or rants regarding the > ctkScene, please send them to me and I will create a set of slides > that list "open-issues" to help focus our discussions. ? We only have > one-hour, so I'd like to focus on high-level issues that remain, prior > to getting into implementation details. ? For example, should a > ctkScene be only a file format or should it also be implemented as a > set of C++ classes? ? Should a ctkScene be specific to or independent > of the visualization library? ? Should a ctkScene be our primary data > structure, or should our primary data structure simply be an image? > ...please add to this list of questions... > > 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 > _______________________________________________ > 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 i.wolf at dkfz-heidelberg.de Fri Sep 18 21:02:15 2009 From: i.wolf at dkfz-heidelberg.de (Wolf Ivo) Date: Fri, 18 Sep 2009 23:02:15 +0200 Subject: [Ctk-developers] Scenes References: <68a07c2d0909161718w313a4035t871e89c00c589a84@mail.gmail.com> Message-ID: <9D19B08C681FF6439739C9AE77CE1953011B5782@dkfzex1.ad.dkfz-heidelberg.de> Hi Stephen, As for the MITK team, we traditionally like the type of definition of a scene that you gave and the mode-view-controller pattern. Both is pretty close to what is used within MITK (except for some extensions, which would be great to have) and therefore could nicely be integrated from CTK. Nevertheless, my feeling is that starting with a scene implementation is not the easiest way to go. And caution (correct me, if I am wrong): The Open Inventor definition of a scene is different from yours (and ours)! Nodes in an Open Inventor scene graph are not necessarily 'objects' (called shape nodes there), but can also be lights, materials (e.g. color), transforms (matrices), switches etc. Thus, the definition "a scene is composed of objects that fill a portion of space and time" is not compatible with Open Inventor (a material node does not fill a portion of space). Maybe it is possible (and desirable) to combine both ideas of defining a scene graph: the more data-centered approach defined above and the visualization-centered approach of Open Inventor. But we should be careful that we are talking about the same things (a topic for the list of questions). Regarding a brief presentation, we recently added some semantic information to our scene description, which might be useful for ctk, too. Best regards, Ivo ________________________________ Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen Aylward Gesendet: Do 17.09.2009 02:18 An: ctk-developers at commontk.org Betreff: [Ctk-developers] Scenes Hi, ctkScene: Love it? Hate it? Know you can make it better? Regardless of your current attitude, please send me your ideas and presentations!!! I'd like to help organize the discussion on ctkScene that is scheduled for next Friday. 1) If you are interested in making a brief presentation (less than 10 minutes), then please send me an email with the title. I will add it into our agenda. 2) If you have revisions to the Wiki page on ctkScene - please make those revisions by 5pm EST (22:00 GMT) on Friday. I am going to summarize those wiki pages as a set of slides at the start of the meeting. http://my-trac.assembla.com/protoctk/wiki/ctkScene 3) If you have questions, concerns, needs, wants, or rants regarding the ctkScene, please send them to me and I will create a set of slides that list "open-issues" to help focus our discussions. We only have one-hour, so I'd like to focus on high-level issues that remain, prior to getting into implementation details. For example, should a ctkScene be only a file format or should it also be implemented as a set of C++ classes? Should a ctkScene be specific to or independent of the visualization library? Should a ctkScene be our primary data structure, or should our primary data structure simply be an image? ...please add to this list of questions... 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 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From i.wolf at dkfz-heidelberg.de Fri Sep 18 21:10:25 2009 From: i.wolf at dkfz-heidelberg.de (Wolf Ivo) Date: Fri, 18 Sep 2009 23:10:25 +0200 Subject: [Ctk-developers] Draft of a CTK white paper Message-ID: <9D19B08C681FF6439739C9AE77CE1953011B5783@dkfzex1.ad.dkfz-heidelberg.de> Hi again, We have added a draft of a white paper with a summary of high level ideas on CTK to the Wiki, which we suggest to discuss and extend: http://my-trac.assembla.com/protoctk/wiki/Whitepaper Please feel free to add comments and things that are missing. Regards, Marco and Ivo From gianluca.paladini at siemens.com Fri Sep 18 21:56:16 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Fri, 18 Sep 2009 14:56:16 -0700 Subject: [Ctk-developers] Scenes In-Reply-To: <9D19B08C681FF6439739C9AE77CE1953011B5782@dkfzex1.ad.dkfz-heidelberg.de> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A14A804@USNWK100MSX.ww017.siemens.net> The advantage of a scene graph comes primarily from those nodes which define attributes rather than drawn objects, because those attributes can be inherited in lower branches of the scene and represent the state of the system at any point during scene graph traversal - that is a key feature, especially when it comes to transform matrices. "Separator" objects prevent those state changes from propagating, while "Group" objects don't. It is this mechanism that makes scene graphs ideal for setting up coordinate systems and controlling parts that move with respect to each other. Without that it's not a scene graph, it's a pipeline. Pipelines are supported in Open Inventor too, but via objects called engines rather than nodes. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Wolf Ivo Sent: Friday, September 18, 2009 5:02 PM To: Stephen Aylward; ctk-developers at commontk.org Subject: Re: [Ctk-developers] Scenes Hi Stephen, As for the MITK team, we traditionally like the type of definition of a scene that you gave and the mode-view-controller pattern. Both is pretty close to what is used within MITK (except for some extensions, which would be great to have) and therefore could nicely be integrated from CTK. Nevertheless, my feeling is that starting with a scene implementation is not the easiest way to go. And caution (correct me, if I am wrong): The Open Inventor definition of a scene is different from yours (and ours)! Nodes in an Open Inventor scene graph are not necessarily 'objects' (called shape nodes there), but can also be lights, materials (e.g. color), transforms (matrices), switches etc. Thus, the definition "a scene is composed of objects that fill a portion of space and time" is not compatible with Open Inventor (a material node does not fill a portion of space). Maybe it is possible (and desirable) to combine both ideas of defining a scene graph: the more data-centered approach defined above and the visualization-centered approach of Open Inventor. But we should be careful that we are talking about the same things (a topic for the list of questions). Regarding a brief presentation, we recently added some semantic information to our scene description, which might be useful for ctk, too. Best regards, Ivo ________________________________ Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen Aylward Gesendet: Do 17.09.2009 02:18 An: ctk-developers at commontk.org Betreff: [Ctk-developers] Scenes Hi, ctkScene: Love it? Hate it? Know you can make it better? Regardless of your current attitude, please send me your ideas and presentations!!! I'd like to help organize the discussion on ctkScene that is scheduled for next Friday. 1) If you are interested in making a brief presentation (less than 10 minutes), then please send me an email with the title. I will add it into our agenda. 2) If you have revisions to the Wiki page on ctkScene - please make those revisions by 5pm EST (22:00 GMT) on Friday. I am going to summarize those wiki pages as a set of slides at the start of the meeting. http://my-trac.assembla.com/protoctk/wiki/ctkScene 3) If you have questions, concerns, needs, wants, or rants regarding the ctkScene, please send them to me and I will create a set of slides that list "open-issues" to help focus our discussions. We only have one-hour, so I'd like to focus on high-level issues that remain, prior to getting into implementation details. For example, should a ctkScene be only a file format or should it also be implemented as a set of C++ classes? Should a ctkScene be specific to or independent of the visualization library? Should a ctkScene be our primary data structure, or should our primary data structure simply be an image? ...please add to this list of questions... 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 _______________________________________________ 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 From stephen.aylward at kitware.com Fri Sep 18 23:01:14 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Fri, 18 Sep 2009 19:01:14 -0400 Subject: [Ctk-developers] Scenes In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC70A14A804@USNWK100MSX.ww017.siemens.net> References: <9D19B08C681FF6439739C9AE77CE1953011B5782@dkfzex1.ad.dkfz-heidelberg.de> <849860E57EBCC34C9E28B6E59A046CC70A14A804@USNWK100MSX.ww017.siemens.net> Message-ID: <68a07c2d0909181601r2c8b53a9kdb84f7983ba80b33@mail.gmail.com> Hi, Gianluca and Ivo bring up a good point..."what is a scene?". The wiki begins with that discussion and a list of requirements, and it seems as though we might need to hash it out a bit more. To being, perhaps we need to distinguish computer graphics scene graphs ("CGScenes") from image processing scene graphs ("IPScenes"). The two serve different purposes. CGScenes are used in two of the largest, community imaging environments: XIP (OpenInventor) and Slicer (MRML). CGScenes use traversal-based semantics to define the context at a node, this is motivated by openGL's use of contexts during rendering. CGScenes are highly developed and have wonderful utility in computer graphics, and clearly they are a solid basis for imaging applications. IPScenes have also been developed independently by several groups (MITK, IGSTK, itkSpatialObjects, and OpenMAF). An IPScene is a tree of transforms, where the transform at a node only influences its children. That is, you don't traverse the scene graph to understand the context of the image stored at a node. IGScenes have demonstrated themselves to be useful for representing the relative location of patients and instruments for surgical guidance systems, the interactions of physiological systems for gate/motion analysis and prosthesis design, the multiscale representation of biological processes for multi-system disease modeling, and numerous other application areas. Sorry if my bias is showing here. As Gianluca mentioned, we need to save the state of an application as it processes its data. CGScenes make this easy. The centralization of GUI and model information simplifies saving state and simplifies the implementation of undo/redo capabilities. However, it could be argued that such mingling does confound the exchange of data across different applications and does create massive scenes that mix physical and GUI constructs. Defining a common API for such disparate types of data does perhaps necessitate the over simplification of the API. For example, the scene requirements listed on our wiki suggest that we need to be able to ask for the physical location of an object...how can you ask a GUI button for its physical location? How can you apply a 3D transform to a slider? The notion of saving the state of an application is critical, but perhaps it is better suited for a data structure other than the scene graph; one that has its own, specific API. So, we need both: a scene of objects and a record of the GUI state. On some implementations, it may be useful to combine them as facilitated by CGScenes. However, we should also allow other implementations to keep them separate. In particular, perhaps the XIP can be used as a reference implementation demonstrating their combined storage. Additionally, it would be interesting to see if MITK, IGSTK, or others can be adopted as a companion implementation that demonstrates the utility of keeping GUI and physical objects in separate data structures. Let's begin the talk on Friday with "What is a scene" - I fear we won't get beyond this question unless we have already had a few beers, and it will be a bit early in the day. So perhaps we should try to limit the time for each topic so that we can hit some potentially fertile topics for discussion as well as the more cantankerous topics. Thanks, Stephen On Fri, Sep 18, 2009 at 5:56 PM, Paladini, Gianluca (SCR US) wrote: > The advantage of a scene graph comes primarily from those nodes which > define attributes rather than drawn objects, because those attributes > can be inherited in lower branches of the scene and represent the state > of the system at any point during scene graph traversal - that is a key > feature, especially when it comes to transform matrices. "Separator" > objects prevent those state changes from propagating, while "Group" > objects don't. It is this mechanism that makes scene graphs ideal for > setting up coordinate systems and controlling parts that move with > respect to each other. > Without that it's not a scene graph, it's a pipeline. Pipelines are > supported in Open Inventor too, but via objects called engines rather > than nodes. > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Wolf Ivo > Sent: Friday, September 18, 2009 5:02 PM > To: Stephen Aylward; ctk-developers at commontk.org > Subject: Re: [Ctk-developers] Scenes > > Hi Stephen, > As for the MITK team, we traditionally like the type of definition of a > scene that you gave and the mode-view-controller pattern. Both is pretty > close to what is used within MITK (except for some extensions, which > would be great to have) and therefore could nicely be integrated from > CTK. Nevertheless, my feeling is that starting with a scene > implementation is not the easiest way to go. > > And caution (correct me, if I am wrong): The Open Inventor definition of > a scene is different from yours (and ours)! Nodes in an Open Inventor > scene graph are not necessarily 'objects' (called shape nodes there), > but can also be lights, materials (e.g. color), transforms (matrices), > switches etc. Thus, the definition "a scene is composed of objects that > fill a portion of space and time" is not compatible with Open Inventor > (a material node does not fill a portion of space). Maybe it is possible > (and desirable) to combine both ideas of defining a scene graph: the > more data-centered approach defined above and the visualization-centered > approach of Open Inventor. But we should be careful that we are talking > about the same things (a topic for the list of questions). > > Regarding a brief presentation, we recently added some semantic > information to our scene description, which might be useful for ctk, > too. > > Best regards, > > Ivo > > > > ________________________________ > > Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen Aylward > Gesendet: Do 17.09.2009 02:18 > An: ctk-developers at commontk.org > Betreff: [Ctk-developers] Scenes > > > > Hi, > > ctkScene: ?Love it? ?Hate it? ?Know you can make it better? > > Regardless of your current attitude, please send me your ideas and > presentations!!! > > I'd like to help organize the discussion on ctkScene that is scheduled > for next Friday. > > 1) If you are interested in making a brief presentation (less than 10 > minutes), then please send me an email with the title. ? I will add it > into our agenda. > > 2) If you have revisions to the Wiki page on ctkScene - please make > those revisions by 5pm EST (22:00 GMT) on Friday. ? I am going to > summarize those wiki pages as a set of slides at the start of the > meeting. > ? ? ?http://my-trac.assembla.com/protoctk/wiki/ctkScene > > 3) If you have questions, concerns, needs, wants, or rants regarding the > ctkScene, please send them to me and I will create a set of slides > that list "open-issues" to help focus our discussions. ? We only have > one-hour, so I'd like to focus on high-level issues that remain, prior > to getting into implementation details. ? For example, should a > ctkScene be only a file format or should it also be implemented as a > set of C++ classes? ? Should a ctkScene be specific to or independent > of the visualization library? ? Should a ctkScene be our primary data > structure, or should our primary data structure simply be an image? > ...please add to this list of questions... > > 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 > _______________________________________________ > 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 > -- 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 Sat Sep 19 00:00:57 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Fri, 18 Sep 2009 17:00:57 -0700 Subject: [Ctk-developers] Scenes In-Reply-To: <68a07c2d0909181601r2c8b53a9kdb84f7983ba80b33@mail.gmail.com> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A14A868@USNWK100MSX.ww017.siemens.net> As I mentioned, Open Inventor supports both types, CGScenes and IPScenes - it is not limited to just the first kind. This is why it was relatively simple to wrap ITK and VTK in Open Inventor, even though those libraries have nothing to do with CGScenes. In XIP Builder CGScenes are built top-down using connections in the top/bottom part of the box representing a node, while IPScenes are usually arranged freely on the visual workspace and their connections emanate laterally from the left and right edges of the box. IPScene connections are type-specific and are created by popping up a "field panel" for the object and connecting input-output parameters. Open Inventor supports user-defined field converters so that some connections between fields of different type (eg. text vs. numeric) are converted automatically. When you start digging in, there is a mountain of details that need to be supported and defining a toolkit-agnostic scene graph may be impossible to attain. That's why I'm an advocate of not re-inventing what others have spent decades refining, and I prefer just creating an XML file definition for toolkits that exist. I am beginning to wonder if we are better off defining a common XML file format that contains toolkit-specific declarations. This would save us a lot of time, because we would not have to figure out how to create generic scene descriptions. The file could declare that, in order to parse a particular scene you will need to have, for example, VTK, MITK and IGSTK. The application would make sure those DLLs are loaded, then parse the file and instantiate those objects. We already have to do this in XIP Builder because various objects are organized in separate libraries, and those libraries need to be present at runtime otherwise certain scene graphs cannot be fully loaded (objects from missing libraries are shown as red boxes). If we go with this approach then the focus in CTK would shift towards implementing "bridge" scene objects that allow connections between different toolkits - objects that would accept an input from an XIP object and provide a VTK output, and so on. As long as CTK provides a library of such objects and a file format to define how to create scenes that intermix the use of all out toolkits, our goal for interoperability would be met. -----Original Message----- From: Stephen Aylward [mailto:stephen.aylward at kitware.com] Sent: Friday, September 18, 2009 7:01 PM To: Paladini, Gianluca (SCR US) Cc: Wolf Ivo; ctk-developers at commontk.org Subject: Re: [Ctk-developers] Scenes Hi, Gianluca and Ivo bring up a good point..."what is a scene?". The wiki begins with that discussion and a list of requirements, and it seems as though we might need to hash it out a bit more. To being, perhaps we need to distinguish computer graphics scene graphs ("CGScenes") from image processing scene graphs ("IPScenes"). The two serve different purposes. CGScenes are used in two of the largest, community imaging environments: XIP (OpenInventor) and Slicer (MRML). CGScenes use traversal-based semantics to define the context at a node, this is motivated by openGL's use of contexts during rendering. CGScenes are highly developed and have wonderful utility in computer graphics, and clearly they are a solid basis for imaging applications. IPScenes have also been developed independently by several groups (MITK, IGSTK, itkSpatialObjects, and OpenMAF). An IPScene is a tree of transforms, where the transform at a node only influences its children. That is, you don't traverse the scene graph to understand the context of the image stored at a node. IGScenes have demonstrated themselves to be useful for representing the relative location of patients and instruments for surgical guidance systems, the interactions of physiological systems for gate/motion analysis and prosthesis design, the multiscale representation of biological processes for multi-system disease modeling, and numerous other application areas. Sorry if my bias is showing here. As Gianluca mentioned, we need to save the state of an application as it processes its data. CGScenes make this easy. The centralization of GUI and model information simplifies saving state and simplifies the implementation of undo/redo capabilities. However, it could be argued that such mingling does confound the exchange of data across different applications and does create massive scenes that mix physical and GUI constructs. Defining a common API for such disparate types of data does perhaps necessitate the over simplification of the API. For example, the scene requirements listed on our wiki suggest that we need to be able to ask for the physical location of an object...how can you ask a GUI button for its physical location? How can you apply a 3D transform to a slider? The notion of saving the state of an application is critical, but perhaps it is better suited for a data structure other than the scene graph; one that has its own, specific API. So, we need both: a scene of objects and a record of the GUI state. On some implementations, it may be useful to combine them as facilitated by CGScenes. However, we should also allow other implementations to keep them separate. In particular, perhaps the XIP can be used as a reference implementation demonstrating their combined storage. Additionally, it would be interesting to see if MITK, IGSTK, or others can be adopted as a companion implementation that demonstrates the utility of keeping GUI and physical objects in separate data structures. Let's begin the talk on Friday with "What is a scene" - I fear we won't get beyond this question unless we have already had a few beers, and it will be a bit early in the day. So perhaps we should try to limit the time for each topic so that we can hit some potentially fertile topics for discussion as well as the more cantankerous topics. Thanks, Stephen On Fri, Sep 18, 2009 at 5:56 PM, Paladini, Gianluca (SCR US) wrote: > The advantage of a scene graph comes primarily from those nodes which > define attributes rather than drawn objects, because those attributes > can be inherited in lower branches of the scene and represent the > state of the system at any point during scene graph traversal - that > is a key feature, especially when it comes to transform matrices. "Separator" > objects prevent those state changes from propagating, while "Group" > objects don't. It is this mechanism that makes scene graphs ideal for > setting up coordinate systems and controlling parts that move with > respect to each other. > Without that it's not a scene graph, it's a pipeline. Pipelines are > supported in Open Inventor too, but via objects called engines rather > than nodes. > > -----Original Message----- > From: ctk-developers-bounces at commontk.org > [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Wolf Ivo > Sent: Friday, September 18, 2009 5:02 PM > To: Stephen Aylward; ctk-developers at commontk.org > Subject: Re: [Ctk-developers] Scenes > > Hi Stephen, > As for the MITK team, we traditionally like the type of definition of > a scene that you gave and the mode-view-controller pattern. Both is > pretty close to what is used within MITK (except for some extensions, > which would be great to have) and therefore could nicely be integrated > from CTK. Nevertheless, my feeling is that starting with a scene > implementation is not the easiest way to go. > > And caution (correct me, if I am wrong): The Open Inventor definition > of a scene is different from yours (and ours)! Nodes in an Open > Inventor scene graph are not necessarily 'objects' (called shape nodes > there), but can also be lights, materials (e.g. color), transforms > (matrices), switches etc. Thus, the definition "a scene is composed of > objects that fill a portion of space and time" is not compatible with > Open Inventor (a material node does not fill a portion of space). > Maybe it is possible (and desirable) to combine both ideas of defining > a scene graph: the more data-centered approach defined above and the > visualization-centered approach of Open Inventor. But we should be > careful that we are talking about the same things (a topic for the list of questions). > > Regarding a brief presentation, we recently added some semantic > information to our scene description, which might be useful for ctk, > too. > > Best regards, > > Ivo > > > > ________________________________ > > Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen > Aylward > Gesendet: Do 17.09.2009 02:18 > An: ctk-developers at commontk.org > Betreff: [Ctk-developers] Scenes > > > > Hi, > > ctkScene: ?Love it? ?Hate it? ?Know you can make it better? > > Regardless of your current attitude, please send me your ideas and > presentations!!! > > I'd like to help organize the discussion on ctkScene that is scheduled > for next Friday. > > 1) If you are interested in making a brief presentation (less than 10 > minutes), then please send me an email with the title. ? I will add it > into our agenda. > > 2) If you have revisions to the Wiki page on ctkScene - please make > those revisions by 5pm EST (22:00 GMT) on Friday. ? I am going to > summarize those wiki pages as a set of slides at the start of the > meeting. > ? ? ?http://my-trac.assembla.com/protoctk/wiki/ctkScene > > 3) If you have questions, concerns, needs, wants, or rants regarding > the ctkScene, please send them to me and I will create a set of slides > that list "open-issues" to help focus our discussions. ? We only have > one-hour, so I'd like to focus on high-level issues that remain, prior > to getting into implementation details. ? For example, should a > ctkScene be only a file format or should it also be implemented as a > set of C++ classes? ? Should a ctkScene be specific to or independent > of the visualization library? ? Should a ctkScene be our primary data > structure, or should our primary data structure simply be an image? > ...please add to this list of questions... > > 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 > _______________________________________________ > 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 > -- 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 stephen.aylward at kitware.com Sat Sep 19 00:25:28 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Fri, 18 Sep 2009 20:25:28 -0400 Subject: [Ctk-developers] Scenes In-Reply-To: <849860E57EBCC34C9E28B6E59A046CC70A14A868@USNWK100MSX.ww017.siemens.net> References: <68a07c2d0909181601r2c8b53a9kdb84f7983ba80b33@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC70A14A868@USNWK100MSX.ww017.siemens.net> Message-ID: <68a07c2d0909181725uecccd88h92f9f45c73506fab@mail.gmail.com> Hi, I am sorry - I am doing a very poor job of explaining IPScene versus CGScene. I've caused you to confuse IPScene with ITK and VTK processing pipelines. The IPScene represents objects in physical space, not processing pipelines. Each node in the IPScene represents an object (e.g., a chair) that has a location and occupies a volume in some physical coordinate system (such as an ultrasound probe in an operating room or the liver in the abdomen of an individual). You can ask if a physical point is inside of an object, you can move an object (node) in physical space by applying a transform to the matrix associated with that node (i.e., the matrix the positions the node with respect to its parent note). A palm of a hand may the root of one IPScene with the fingers as branches off of the root. If you move the palm by changing its transforms, the fingers (as children) move with it in space. Below you seem to be describing IPScenes as processing pipelines between modules/vilters. That is something quite different - both VTK and ITK call them pipelines. Such pipelines implement algorithms. If we want to represent pipelines generically, I fully agree that a much different conversation would be needed. My intent was to distinguish GUI elements from physical objects. For example, in a CGScene, you would represent a GUI element, such as the visual representation of a pipeline. While an IPScene is the data you would pass between filters/modules in a pipeline. Sorry - not certain if I am helping. I look forward to our face-to-face discussions. Stephen On Fri, Sep 18, 2009 at 8:00 PM, Paladini, Gianluca (SCR US) wrote: > As I mentioned, Open Inventor supports both types, CGScenes and IPScenes - it is not limited to just the first kind. > This is why it was relatively simple to wrap ITK and VTK in Open Inventor, even though those libraries have nothing to do with CGScenes. > > In XIP Builder CGScenes are built top-down using connections in the top/bottom part of the box representing a node, while IPScenes are usually arranged freely on the visual workspace and their connections emanate laterally from the left and right edges of the box. IPScene connections are type-specific and are created by popping up a "field panel" for the object and connecting input-output parameters. Open Inventor supports user-defined field converters so that some connections between fields of different type (eg. text vs. numeric) are converted automatically. > > When you start digging in, there is a mountain of details that need to be supported and defining a toolkit-agnostic scene graph may be impossible to attain. That's why I'm an advocate of not re-inventing what others have spent decades refining, and I prefer just creating an XML file definition for toolkits that exist. > > I am beginning to wonder if we are better off defining a common XML file format that contains toolkit-specific declarations. This would save us a lot of time, because we would not have to figure out how to create generic scene descriptions. The file could declare that, in order to parse a particular scene you will need to have, for example, VTK, MITK and IGSTK. The application would make sure those DLLs are loaded, then parse the file and instantiate those objects. We already have to do this in XIP Builder because various objects are organized in separate libraries, and those libraries need to be present at runtime otherwise certain scene graphs cannot be fully loaded (objects from missing libraries are shown as red boxes). > > If we go with this approach then the focus in CTK would shift towards implementing "bridge" scene objects that allow connections between different toolkits - objects that would accept an input from an XIP object and provide a VTK output, and so on. As long as CTK provides a library of such objects and a file format to define how to create scenes that intermix the use of all out toolkits, our goal for interoperability would be met. > > -----Original Message----- > From: Stephen Aylward [mailto:stephen.aylward at kitware.com] > Sent: Friday, September 18, 2009 7:01 PM > To: Paladini, Gianluca (SCR US) > Cc: Wolf Ivo; ctk-developers at commontk.org > Subject: Re: [Ctk-developers] Scenes > > Hi, > > Gianluca and Ivo bring up a good point..."what is a scene?". ? The > wiki begins with that discussion and a list of requirements, and it seems as though we might need to hash it out a bit more. > > To being, perhaps we need to distinguish computer graphics scene graphs ("CGScenes") from image processing scene graphs ("IPScenes"). > The two serve different purposes. > > CGScenes are used in two of the largest, community imaging > environments: XIP (OpenInventor) and Slicer (MRML). ? CGScenes use > traversal-based semantics to define the context at a node, this is > motivated by openGL's use of contexts during rendering. ? CGScenes are > highly developed and have wonderful utility in computer graphics, and clearly they are a solid basis for imaging applications. > > IPScenes have also been developed independently by several groups (MITK, IGSTK, itkSpatialObjects, and OpenMAF). ?An IPScene is a tree of transforms, where the transform at a node only influences its children. ?That is, you don't traverse the scene graph to understand > the context of the image stored at a node. ? IGScenes have > demonstrated themselves to be useful for representing the relative location of patients and instruments for surgical guidance systems, the interactions of physiological systems for gate/motion analysis and prosthesis design, the multiscale representation of biological processes for multi-system disease modeling, and numerous other > application areas. ? Sorry if my bias is showing here. > > As Gianluca mentioned, we need to save the state of an application as > it processes its data. ? CGScenes make this easy. ?The centralization > of GUI and model information simplifies saving state and simplifies > the implementation of undo/redo capabilities. ? However, it could be > argued that such mingling does confound the exchange of data across different applications and does create massive scenes that mix physical and GUI constructs. ?Defining a common API for such disparate types of data does perhaps necessitate the over simplification of the > API. ? For example, the scene requirements listed on our wiki suggest > that we need to be able to ask for the physical location of an > object...how can you ask a GUI button for its physical location? ? How > can you apply a 3D transform to a slider? ? The notion of saving the > state of an application is critical, but perhaps it is better suited for a data structure other than the scene graph; one that has its own, specific API. > > So, we need both: a scene of objects and a record of the GUI state. > On some implementations, it may be useful to combine them as > facilitated by CGScenes. ? However, we should also allow other > implementations to keep them separate. > > In particular, perhaps the XIP can be used as a reference > implementation demonstrating their combined storage. ? ?Additionally, > it would be interesting to see if MITK, IGSTK, or others can be adopted as a companion implementation that demonstrates the utility of keeping GUI and physical objects in separate data structures. > > Let's begin the talk on Friday with "What is a scene" ? - I fear we > won't get beyond this question unless we have already had a few beers, > and it will be a bit early in the day. ? So perhaps we should try to > limit the time for each topic so that we can hit some potentially fertile topics for discussion as well as the more cantankerous topics. > > Thanks, > Stephen > > On Fri, Sep 18, 2009 at 5:56 PM, Paladini, Gianluca (SCR US) wrote: >> The advantage of a scene graph comes primarily from those nodes which >> define attributes rather than drawn objects, because those attributes >> can be inherited in lower branches of the scene and represent the >> state of the system at any point during scene graph traversal - that >> is a key feature, especially when it comes to transform matrices. "Separator" >> objects prevent those state changes from propagating, while "Group" >> objects don't. It is this mechanism that makes scene graphs ideal for >> setting up coordinate systems and controlling parts that move with >> respect to each other. >> Without that it's not a scene graph, it's a pipeline. Pipelines are >> supported in Open Inventor too, but via objects called engines rather >> than nodes. >> >> -----Original Message----- >> From: ctk-developers-bounces at commontk.org >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Wolf Ivo >> Sent: Friday, September 18, 2009 5:02 PM >> To: Stephen Aylward; ctk-developers at commontk.org >> Subject: Re: [Ctk-developers] Scenes >> >> Hi Stephen, >> As for the MITK team, we traditionally like the type of definition of >> a scene that you gave and the mode-view-controller pattern. Both is >> pretty close to what is used within MITK (except for some extensions, >> which would be great to have) and therefore could nicely be integrated >> from CTK. Nevertheless, my feeling is that starting with a scene >> implementation is not the easiest way to go. >> >> And caution (correct me, if I am wrong): The Open Inventor definition >> of a scene is different from yours (and ours)! Nodes in an Open >> Inventor scene graph are not necessarily 'objects' (called shape nodes >> there), but can also be lights, materials (e.g. color), transforms >> (matrices), switches etc. Thus, the definition "a scene is composed of >> objects that fill a portion of space and time" is not compatible with >> Open Inventor (a material node does not fill a portion of space). >> Maybe it is possible (and desirable) to combine both ideas of defining >> a scene graph: the more data-centered approach defined above and the >> visualization-centered approach of Open Inventor. But we should be >> careful that we are talking about the same things (a topic for the list of questions). >> >> Regarding a brief presentation, we recently added some semantic >> information to our scene description, which might be useful for ctk, >> too. >> >> Best regards, >> >> Ivo >> >> >> >> ________________________________ >> >> Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen >> Aylward >> Gesendet: Do 17.09.2009 02:18 >> An: ctk-developers at commontk.org >> Betreff: [Ctk-developers] Scenes >> >> >> >> Hi, >> >> ctkScene: ?Love it? ?Hate it? ?Know you can make it better? >> >> Regardless of your current attitude, please send me your ideas and >> presentations!!! >> >> I'd like to help organize the discussion on ctkScene that is scheduled >> for next Friday. >> >> 1) If you are interested in making a brief presentation (less than 10 >> minutes), then please send me an email with the title. ? I will add it >> into our agenda. >> >> 2) If you have revisions to the Wiki page on ctkScene - please make >> those revisions by 5pm EST (22:00 GMT) on Friday. ? I am going to >> summarize those wiki pages as a set of slides at the start of the >> meeting. >> ? ? ?http://my-trac.assembla.com/protoctk/wiki/ctkScene >> >> 3) If you have questions, concerns, needs, wants, or rants regarding >> the ctkScene, please send them to me and I will create a set of slides >> that list "open-issues" to help focus our discussions. ? We only have >> one-hour, so I'd like to focus on high-level issues that remain, prior >> to getting into implementation details. ? For example, should a >> ctkScene be only a file format or should it also be implemented as a >> set of C++ classes? ? Should a ctkScene be specific to or independent >> of the visualization library? ? Should a ctkScene be our primary data >> structure, or should our primary data structure simply be an image? >> ...please add to this list of questions... >> >> 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 >> _______________________________________________ >> 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 >> > > > > -- > 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 > -- 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 Sun Sep 20 15:54:54 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Sun, 20 Sep 2009 11:54:54 -0400 Subject: [Ctk-developers] Scenes In-Reply-To: <68a07c2d0909181725uecccd88h92f9f45c73506fab@mail.gmail.com> References: <68a07c2d0909181601r2c8b53a9kdb84f7983ba80b33@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC70A14A868@USNWK100MSX.ww017.siemens.net> <68a07c2d0909181725uecccd88h92f9f45c73506fab@mail.gmail.com> Message-ID: <4AB6504E.50202@bwh.harvard.edu> Hi Guys - Sorry to be late to the conversation, but I did want to add a few points from our experience when redesigning MRML a few years ago. * Object model and data structures for the scene: A core issue for MRML was the on-disk and in-memory representation of complex data types that are part of the scene. Since we use both VTK and ITK extensively, we considered creating a toolkit-independent object layer with adaptors to both toolkits... but we quickly realized that this meant building not only a new object layer but two complete adaptors. Instead, we standardized on VTK for our MRML Scene layer and have an interface to ITK (a pretty slick one - it uses the ITK I/O factory to give pointer access to the image data). By sticking, in particular, with vtkPolyData we have been able to represent things like diffusion tractography fiber bundles with tensors-per-vertex and annotated brain surface models. These are hard data structures to write and debug, and also by using VTK as the object model it plugs easily into the rest of the application. Note that MRML *does not* describe the GUI and it *does not* even link to OpenGL. It merely uses VTK for the data structures and the rich set of I/O and data manipulation utilities. Since CTK will have VTK available, the same considerations apply. One way of interpreting this approach is that it is essentially Pat's suggestion (Implementation 4), but using VTK (mostly vtkCommon) as the basis for the internal data structures. From there you can have an ITK adaptor and/or a Qt signals/slots interface as Stephen has shown in mavScene. Using QtCore's tree data structures and other tools to organize the vtkObject instances may be an ideal combination. * Descriptions of Image Acqusition We should distinguish between "objects that fill space" and "physical observations of objects using particular imaging devices and protocols" -- we typically have the latter and are trying to calculate the former. The ctkScene described on the wiki doesn't (yet) talk about the importance of having the scene be able to describe the image acquisition, clinical information, or other real-time info. Image acquisition info is basically what comes from the DICOM header like the imaging device and protocol. In general we should also be able to represent data on things like fMRI stimulus presentation and physiological response if ctkScene apsires to have complete information necessary for a wide range of image analysis tasks. * The "physical scene" vs. the "semantic scene" The current ctkScene description focuses on objects in space, but there is also a lot of non-physical information that we typically embed in the scene - things like anatomical labels and annotations. In MRML we allow /model hierarchies/ independent of /transform hierarchies/ (e.g. the "skeletal system" as opposed to the "hand"). The former might be used for visualization, while the latter can be used for positioning child objects relative to parent objects. In general I agree with the sentiment that these are complex issues that are best discussed over a beer (or two...). See you in Oxford! -Steve p.s. I added these to the wiki even if they are too late to be included in Stephen's summary. Stephen Aylward wrote: > Hi, > > I am sorry - I am doing a very poor job of explaining IPScene versus > CGScene. I've caused you to confuse IPScene with ITK and VTK > processing pipelines. > > The IPScene represents objects in physical space, not processing > pipelines. Each node in the IPScene represents an object (e.g., a > chair) that has a location and occupies a volume in some physical > coordinate system (such as an ultrasound probe in an operating room or > the liver in the abdomen of an individual). You can ask if a > physical point is inside of an object, you can move an object (node) > in physical space by applying a transform to the matrix associated > with that node (i.e., the matrix the positions the node with respect > to its parent note). A palm of a hand may the root of one IPScene > with the fingers as branches off of the root. If you move the palm by > changing its transforms, the fingers (as children) move with it in > space. > > Below you seem to be describing IPScenes as processing pipelines > between modules/vilters. That is something quite different - both VTK > and ITK call them pipelines. Such pipelines implement algorithms. > If we want to represent pipelines generically, I fully agree that a > much different conversation would be needed. > > My intent was to distinguish GUI elements from physical objects. For > example, in a CGScene, you would represent a GUI element, such as the > visual representation of a pipeline. While an IPScene is the data you > would pass between filters/modules in a pipeline. > > Sorry - not certain if I am helping. I look forward to our > face-to-face discussions. > > Stephen > > > On Fri, Sep 18, 2009 at 8:00 PM, Paladini, Gianluca (SCR US) > wrote: >> As I mentioned, Open Inventor supports both types, CGScenes and IPScenes - it is not limited to just the first kind. >> This is why it was relatively simple to wrap ITK and VTK in Open Inventor, even though those libraries have nothing to do with CGScenes. >> >> In XIP Builder CGScenes are built top-down using connections in the top/bottom part of the box representing a node, while IPScenes are usually arranged freely on the visual workspace and their connections emanate laterally from the left and right edges of the box. IPScene connections are type-specific and are created by popping up a "field panel" for the object and connecting input-output parameters. Open Inventor supports user-defined field converters so that some connections between fields of different type (eg. text vs. numeric) are converted automatically. >> >> When you start digging in, there is a mountain of details that need to be supported and defining a toolkit-agnostic scene graph may be impossible to attain. That's why I'm an advocate of not re-inventing what others have spent decades refining, and I prefer just creating an XML file definition for toolkits that exist. >> >> I am beginning to wonder if we are better off defining a common XML file format that contains toolkit-specific declarations. This would save us a lot of time, because we would not have to figure out how to create generic scene descriptions. The file could declare that, in order to parse a particular scene you will need to have, for example, VTK, MITK and IGSTK. The application would make sure those DLLs are loaded, then parse the file and instantiate those objects. We already have to do this in XIP Builder because various objects are organized in separate libraries, and those libraries need to be present at runtime otherwise certain scene graphs cannot be fully loaded (objects from missing libraries are shown as red boxes). >> >> If we go with this approach then the focus in CTK would shift towards implementing "bridge" scene objects that allow connections between different toolkits - objects that would accept an input from an XIP object and provide a VTK output, and so on. As long as CTK provides a library of such objects and a file format to define how to create scenes that intermix the use of all out toolkits, our goal for interoperability would be met. >> >> -----Original Message----- >> From: Stephen Aylward [mailto:stephen.aylward at kitware.com] >> Sent: Friday, September 18, 2009 7:01 PM >> To: Paladini, Gianluca (SCR US) >> Cc: Wolf Ivo; ctk-developers at commontk.org >> Subject: Re: [Ctk-developers] Scenes >> >> Hi, >> >> Gianluca and Ivo bring up a good point..."what is a scene?". The >> wiki begins with that discussion and a list of requirements, and it seems as though we might need to hash it out a bit more. >> >> To being, perhaps we need to distinguish computer graphics scene graphs ("CGScenes") from image processing scene graphs ("IPScenes"). >> The two serve different purposes. >> >> CGScenes are used in two of the largest, community imaging >> environments: XIP (OpenInventor) and Slicer (MRML). CGScenes use >> traversal-based semantics to define the context at a node, this is >> motivated by openGL's use of contexts during rendering. CGScenes are >> highly developed and have wonderful utility in computer graphics, and clearly they are a solid basis for imaging applications. >> >> IPScenes have also been developed independently by several groups (MITK, IGSTK, itkSpatialObjects, and OpenMAF). An IPScene is a tree of transforms, where the transform at a node only influences its children. That is, you don't traverse the scene graph to understand >> the context of the image stored at a node. IGScenes have >> demonstrated themselves to be useful for representing the relative location of patients and instruments for surgical guidance systems, the interactions of physiological systems for gate/motion analysis and prosthesis design, the multiscale representation of biological processes for multi-system disease modeling, and numerous other >> application areas. Sorry if my bias is showing here. >> >> As Gianluca mentioned, we need to save the state of an application as >> it processes its data. CGScenes make this easy. The centralization >> of GUI and model information simplifies saving state and simplifies >> the implementation of undo/redo capabilities. However, it could be >> argued that such mingling does confound the exchange of data across different applications and does create massive scenes that mix physical and GUI constructs. Defining a common API for such disparate types of data does perhaps necessitate the over simplification of the >> API. For example, the scene requirements listed on our wiki suggest >> that we need to be able to ask for the physical location of an >> object...how can you ask a GUI button for its physical location? How >> can you apply a 3D transform to a slider? The notion of saving the >> state of an application is critical, but perhaps it is better suited for a data structure other than the scene graph; one that has its own, specific API. >> >> So, we need both: a scene of objects and a record of the GUI state. >> On some implementations, it may be useful to combine them as >> facilitated by CGScenes. However, we should also allow other >> implementations to keep them separate. >> >> In particular, perhaps the XIP can be used as a reference >> implementation demonstrating their combined storage. Additionally, >> it would be interesting to see if MITK, IGSTK, or others can be adopted as a companion implementation that demonstrates the utility of keeping GUI and physical objects in separate data structures. >> >> Let's begin the talk on Friday with "What is a scene" - I fear we >> won't get beyond this question unless we have already had a few beers, >> and it will be a bit early in the day. So perhaps we should try to >> limit the time for each topic so that we can hit some potentially fertile topics for discussion as well as the more cantankerous topics. >> >> Thanks, >> Stephen >> >> On Fri, Sep 18, 2009 at 5:56 PM, Paladini, Gianluca (SCR US) wrote: >>> The advantage of a scene graph comes primarily from those nodes which >>> define attributes rather than drawn objects, because those attributes >>> can be inherited in lower branches of the scene and represent the >>> state of the system at any point during scene graph traversal - that >>> is a key feature, especially when it comes to transform matrices. "Separator" >>> objects prevent those state changes from propagating, while "Group" >>> objects don't. It is this mechanism that makes scene graphs ideal for >>> setting up coordinate systems and controlling parts that move with >>> respect to each other. >>> Without that it's not a scene graph, it's a pipeline. Pipelines are >>> supported in Open Inventor too, but via objects called engines rather >>> than nodes. >>> >>> -----Original Message----- >>> From: ctk-developers-bounces at commontk.org >>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Wolf Ivo >>> Sent: Friday, September 18, 2009 5:02 PM >>> To: Stephen Aylward; ctk-developers at commontk.org >>> Subject: Re: [Ctk-developers] Scenes >>> >>> Hi Stephen, >>> As for the MITK team, we traditionally like the type of definition of >>> a scene that you gave and the mode-view-controller pattern. Both is >>> pretty close to what is used within MITK (except for some extensions, >>> which would be great to have) and therefore could nicely be integrated >>> from CTK. Nevertheless, my feeling is that starting with a scene >>> implementation is not the easiest way to go. >>> >>> And caution (correct me, if I am wrong): The Open Inventor definition >>> of a scene is different from yours (and ours)! Nodes in an Open >>> Inventor scene graph are not necessarily 'objects' (called shape nodes >>> there), but can also be lights, materials (e.g. color), transforms >>> (matrices), switches etc. Thus, the definition "a scene is composed of >>> objects that fill a portion of space and time" is not compatible with >>> Open Inventor (a material node does not fill a portion of space). >>> Maybe it is possible (and desirable) to combine both ideas of defining >>> a scene graph: the more data-centered approach defined above and the >>> visualization-centered approach of Open Inventor. But we should be >>> careful that we are talking about the same things (a topic for the list of questions). >>> >>> Regarding a brief presentation, we recently added some semantic >>> information to our scene description, which might be useful for ctk, >>> too. >>> >>> Best regards, >>> >>> Ivo >>> >>> >>> >>> ________________________________ >>> >>> Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen >>> Aylward >>> Gesendet: Do 17.09.2009 02:18 >>> An: ctk-developers at commontk.org >>> Betreff: [Ctk-developers] Scenes >>> >>> >>> >>> Hi, >>> >>> ctkScene: Love it? Hate it? Know you can make it better? >>> >>> Regardless of your current attitude, please send me your ideas and >>> presentations!!! >>> >>> I'd like to help organize the discussion on ctkScene that is scheduled >>> for next Friday. >>> >>> 1) If you are interested in making a brief presentation (less than 10 >>> minutes), then please send me an email with the title. I will add it >>> into our agenda. >>> >>> 2) If you have revisions to the Wiki page on ctkScene - please make >>> those revisions by 5pm EST (22:00 GMT) on Friday. I am going to >>> summarize those wiki pages as a set of slides at the start of the >>> meeting. >>> http://my-trac.assembla.com/protoctk/wiki/ctkScene >>> >>> 3) If you have questions, concerns, needs, wants, or rants regarding >>> the ctkScene, please send them to me and I will create a set of slides >>> that list "open-issues" to help focus our discussions. We only have >>> one-hour, so I'd like to focus on high-level issues that remain, prior >>> to getting into implementation details. For example, should a >>> ctkScene be only a file format or should it also be implemented as a >>> set of C++ classes? Should a ctkScene be specific to or independent >>> of the visualization library? Should a ctkScene be our primary data >>> structure, or should our primary data structure simply be an image? >>> ...please add to this list of questions... >>> >>> 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 >>> _______________________________________________ >>> 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 >>> >> >> >> -- >> 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 stephen.aylward at kitware.com Mon Sep 21 22:27:31 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 21 Sep 2009 18:27:31 -0400 Subject: [Ctk-developers] Scenes In-Reply-To: <4AB6504E.50202@bwh.harvard.edu> References: <68a07c2d0909181601r2c8b53a9kdb84f7983ba80b33@mail.gmail.com> <849860E57EBCC34C9E28B6E59A046CC70A14A868@USNWK100MSX.ww017.siemens.net> <68a07c2d0909181725uecccd88h92f9f45c73506fab@mail.gmail.com> <4AB6504E.50202@bwh.harvard.edu> Message-ID: <68a07c2d0909211527v3d2b650y321b060b9c0dc61d@mail.gmail.com> Hi Steve, Very interesting ideas! Really good point: why bother creating a scene that depends on Qt if an ITK/VTK implementation is possible. I used "ITK/VTK" as the placeholder since I'm still working out the pros and cons of using each - I just read your email and I need to think about it more. One question that quickly jumps out at me...given that the algorithms are in ITK, perhaps it would be better to have the scene in ITK? That way algorithm developers don't need any other libraries. If data and logic are in ITK, then the chance of others following our lead might be greater since the cost to learn/use our methods/algorithms is then minimized. We can use ITK's IO library which supports more medical image types than VTK's IO library. Also consider that although CTK is committed to VTK, perhaps if we can keep our methods and data independent of it, then the XIP/OpenInventor folks might benefit more directly and with less refactoring. Stephen On Sun, Sep 20, 2009 at 11:54 AM, Steve Pieper wrote: > Hi Guys - > > Sorry to be late to the conversation, but I did want to add a few points > from our experience when redesigning MRML a few years ago. > > > * Object model and data structures for the scene: > > A core issue for MRML was the on-disk and in-memory representation of > complex data types that are part of the scene. ?Since we use both VTK and > ITK extensively, we considered creating a toolkit-independent object layer > with adaptors to both toolkits... but we quickly realized that this meant > building not only a new object layer but two complete adaptors. ?Instead, we > standardized on VTK for our MRML Scene layer and have an interface to ITK (a > pretty slick one - it uses the ITK I/O factory to give pointer access to the > image data). > > By sticking, in particular, with vtkPolyData we have been able to represent > things like diffusion tractography fiber bundles with tensors-per-vertex and > annotated brain surface models. ?These are hard data structures to write and > debug, and also by using VTK as the object model it plugs easily into the > rest of the application. ?Note that MRML *does not* describe the GUI and it > *does not* even link to OpenGL. ?It merely uses VTK for the data structures > and the rich set of I/O and data manipulation utilities. ?Since CTK will > have VTK available, the same considerations apply. > > One way of interpreting this approach is that it is essentially Pat's > suggestion (Implementation 4), but using VTK (mostly vtkCommon) as the basis > for the internal data structures. ?From there you can have an ITK adaptor > and/or a Qt signals/slots interface as Stephen has shown in mavScene. ?Using > QtCore's tree data structures and other tools to organize the vtkObject > instances may be an ideal combination. > > > * Descriptions of Image Acqusition > > We should distinguish between "objects that fill space" and "physical > observations of objects using particular imaging devices and protocols" -- > we typically have the latter and are trying to calculate the former. ?The > ctkScene described on the wiki doesn't (yet) talk about the importance of > having the scene be able to describe the image acquisition, clinical > information, or other real-time info. ?Image acquisition info is basically > what comes from the DICOM header like the imaging device and protocol. ?In > general we should also be able to represent data on things like fMRI > stimulus presentation and physiological response if ctkScene apsires to have > complete information necessary for a wide range of image analysis tasks. > > > * The "physical scene" vs. the "semantic scene" > > The current ctkScene description focuses on objects in space, but there is > also a lot of non-physical information that we typically embed in the scene > - things like anatomical labels and annotations. ?In MRML we allow /model > hierarchies/ independent of /transform hierarchies/ (e.g. the "skeletal > system" as opposed to the "hand"). ?The former might be used for > visualization, while the latter can be used for positioning child objects > relative to parent objects. > > > In general I agree with the sentiment that these are complex issues that are > best discussed over a beer (or two...). ?See you in Oxford! > > -Steve > > p.s. I added these to the wiki even if they are too late to be included in > Stephen's summary. > > Stephen Aylward wrote: >> >> Hi, >> >> I am sorry - I am doing a very poor job of explaining IPScene versus >> CGScene. ? ?I've caused you to confuse IPScene with ITK and VTK >> processing pipelines. >> >> The IPScene represents objects in physical space, not processing >> pipelines. ?Each node in the IPScene represents an object (e.g., a >> chair) that has a location and occupies a volume in some physical >> coordinate system (such as an ultrasound probe in an operating room or >> the liver in the abdomen of an individual). ? You can ask if a >> physical point is inside of an object, you can move an object (node) >> in physical space by applying a transform to the matrix associated >> with that node (i.e., the matrix the positions the node with respect >> to its parent note). ? ?A palm of a hand may the root of one IPScene >> with the fingers as branches off of the root. ?If you move the palm by >> changing its transforms, the fingers (as children) move with it in >> space. >> >> Below you seem to be describing IPScenes as processing pipelines >> between modules/vilters. ?That is something quite different - both VTK >> and ITK call them pipelines. ? Such pipelines implement algorithms. >> If we want to represent pipelines generically, I fully agree that a >> much different conversation would be needed. >> >> My intent was to distinguish GUI elements from physical objects. ? For >> example, in a CGScene, you would represent a GUI element, such as the >> visual representation of a pipeline. ?While an IPScene is the data you >> would pass between filters/modules in a pipeline. >> >> Sorry - not certain if I am helping. ? I look forward to our >> face-to-face discussions. >> >> Stephen >> >> >> On Fri, Sep 18, 2009 at 8:00 PM, Paladini, Gianluca (SCR US) >> wrote: >>> >>> As I mentioned, Open Inventor supports both types, CGScenes and IPScenes >>> - it is not limited to just the first kind. >>> This is why it was relatively simple to wrap ITK and VTK in Open >>> Inventor, even though those libraries have nothing to do with CGScenes. >>> >>> In XIP Builder CGScenes are built top-down using connections in the >>> top/bottom part of the box representing a node, while IPScenes are usually >>> arranged freely on the visual workspace and their connections emanate >>> laterally from the left and right edges of the box. IPScene connections are >>> type-specific and are created by popping up a "field panel" for the object >>> and connecting input-output parameters. Open Inventor supports user-defined >>> field converters so that some connections between fields of different type >>> (eg. text vs. numeric) are converted automatically. >>> >>> When you start digging in, there is a mountain of details that need to be >>> supported and defining a toolkit-agnostic scene graph may be impossible to >>> attain. That's why I'm an advocate of not re-inventing what others have >>> spent decades refining, and I prefer just creating an XML file definition >>> for toolkits that exist. >>> >>> I am beginning to wonder if we are better off defining a common XML file >>> format that contains toolkit-specific declarations. This would save us a lot >>> of time, because we would not have to figure out how to create generic scene >>> descriptions. The file could declare that, in order to parse a particular >>> scene you will need to have, for example, VTK, MITK and IGSTK. The >>> application would make sure those DLLs are loaded, then parse the file and >>> instantiate those objects. We already have to do this in XIP Builder because >>> various objects are organized in separate libraries, and those libraries >>> need to be present at runtime otherwise certain scene graphs cannot be fully >>> loaded (objects from missing libraries are shown as red boxes). >>> >>> If we go with this approach then the focus in CTK would shift towards >>> implementing "bridge" scene objects that allow connections between different >>> toolkits - objects that would accept an input from an XIP object and provide >>> a VTK output, and so on. As long as CTK provides a library of such objects >>> and a file format to define how to create scenes that intermix the use of >>> all out toolkits, our goal for interoperability would be met. >>> >>> -----Original Message----- >>> From: Stephen Aylward [mailto:stephen.aylward at kitware.com] >>> Sent: Friday, September 18, 2009 7:01 PM >>> To: Paladini, Gianluca (SCR US) >>> Cc: Wolf Ivo; ctk-developers at commontk.org >>> Subject: Re: [Ctk-developers] Scenes >>> >>> Hi, >>> >>> Gianluca and Ivo bring up a good point..."what is a scene?". ? The >>> wiki begins with that discussion and a list of requirements, and it seems >>> as though we might need to hash it out a bit more. >>> >>> To being, perhaps we need to distinguish computer graphics scene graphs >>> ("CGScenes") from image processing scene graphs ("IPScenes"). >>> The two serve different purposes. >>> >>> CGScenes are used in two of the largest, community imaging >>> environments: XIP (OpenInventor) and Slicer (MRML). ? CGScenes use >>> traversal-based semantics to define the context at a node, this is >>> motivated by openGL's use of contexts during rendering. ? CGScenes are >>> highly developed and have wonderful utility in computer graphics, and >>> clearly they are a solid basis for imaging applications. >>> >>> IPScenes have also been developed independently by several groups (MITK, >>> IGSTK, itkSpatialObjects, and OpenMAF). ?An IPScene is a tree of transforms, >>> where the transform at a node only influences its children. ?That is, you >>> don't traverse the scene graph to understand >>> the context of the image stored at a node. ? IGScenes have >>> demonstrated themselves to be useful for representing the relative >>> location of patients and instruments for surgical guidance systems, the >>> interactions of physiological systems for gate/motion analysis and >>> prosthesis design, the multiscale representation of biological processes for >>> multi-system disease modeling, and numerous other >>> application areas. ? Sorry if my bias is showing here. >>> >>> As Gianluca mentioned, we need to save the state of an application as >>> it processes its data. ? CGScenes make this easy. ?The centralization >>> of GUI and model information simplifies saving state and simplifies >>> the implementation of undo/redo capabilities. ? However, it could be >>> argued that such mingling does confound the exchange of data across >>> different applications and does create massive scenes that mix physical and >>> GUI constructs. ?Defining a common API for such disparate types of data does >>> perhaps necessitate the over simplification of the >>> API. ? For example, the scene requirements listed on our wiki suggest >>> that we need to be able to ask for the physical location of an >>> object...how can you ask a GUI button for its physical location? ? How >>> can you apply a 3D transform to a slider? ? The notion of saving the >>> state of an application is critical, but perhaps it is better suited for >>> a data structure other than the scene graph; one that has its own, specific >>> API. >>> >>> So, we need both: a scene of objects and a record of the GUI state. >>> On some implementations, it may be useful to combine them as >>> facilitated by CGScenes. ? However, we should also allow other >>> implementations to keep them separate. >>> >>> In particular, perhaps the XIP can be used as a reference >>> implementation demonstrating their combined storage. ? ?Additionally, >>> it would be interesting to see if MITK, IGSTK, or others can be adopted >>> as a companion implementation that demonstrates the utility of keeping GUI >>> and physical objects in separate data structures. >>> >>> Let's begin the talk on Friday with "What is a scene" ? - I fear we >>> won't get beyond this question unless we have already had a few beers, >>> and it will be a bit early in the day. ? So perhaps we should try to >>> limit the time for each topic so that we can hit some potentially fertile >>> topics for discussion as well as the more cantankerous topics. >>> >>> Thanks, >>> Stephen >>> >>> On Fri, Sep 18, 2009 at 5:56 PM, Paladini, Gianluca (SCR US) >>> wrote: >>>> >>>> The advantage of a scene graph comes primarily from those nodes which >>>> define attributes rather than drawn objects, because those attributes >>>> can be inherited in lower branches of the scene and represent the >>>> state of the system at any point during scene graph traversal - that >>>> is a key feature, especially when it comes to transform matrices. >>>> "Separator" >>>> objects prevent those state changes from propagating, while "Group" >>>> objects don't. It is this mechanism that makes scene graphs ideal for >>>> setting up coordinate systems and controlling parts that move with >>>> respect to each other. >>>> Without that it's not a scene graph, it's a pipeline. Pipelines are >>>> supported in Open Inventor too, but via objects called engines rather >>>> than nodes. >>>> >>>> -----Original Message----- >>>> From: ctk-developers-bounces at commontk.org >>>> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Wolf Ivo >>>> Sent: Friday, September 18, 2009 5:02 PM >>>> To: Stephen Aylward; ctk-developers at commontk.org >>>> Subject: Re: [Ctk-developers] Scenes >>>> >>>> Hi Stephen, >>>> As for the MITK team, we traditionally like the type of definition of >>>> a scene that you gave and the mode-view-controller pattern. Both is >>>> pretty close to what is used within MITK (except for some extensions, >>>> which would be great to have) and therefore could nicely be integrated >>>> from CTK. Nevertheless, my feeling is that starting with a scene >>>> implementation is not the easiest way to go. >>>> >>>> And caution (correct me, if I am wrong): The Open Inventor definition >>>> of a scene is different from yours (and ours)! Nodes in an Open >>>> Inventor scene graph are not necessarily 'objects' (called shape nodes >>>> there), but can also be lights, materials (e.g. color), transforms >>>> (matrices), switches etc. Thus, the definition "a scene is composed of >>>> objects that fill a portion of space and time" is not compatible with >>>> Open Inventor (a material node does not fill a portion of space). >>>> Maybe it is possible (and desirable) to combine both ideas of defining >>>> a scene graph: the more data-centered approach defined above and the >>>> visualization-centered approach of Open Inventor. But we should be >>>> careful that we are talking about the same things (a topic for the list >>>> of questions). >>>> >>>> Regarding a brief presentation, we recently added some semantic >>>> information to our scene description, which might be useful for ctk, >>>> too. >>>> >>>> Best regards, >>>> >>>> Ivo >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> Von: ctk-developers-bounces at commontk.org im Auftrag von Stephen >>>> Aylward >>>> Gesendet: Do 17.09.2009 02:18 >>>> An: ctk-developers at commontk.org >>>> Betreff: [Ctk-developers] Scenes >>>> >>>> >>>> >>>> Hi, >>>> >>>> ctkScene: ?Love it? ?Hate it? ?Know you can make it better? >>>> >>>> Regardless of your current attitude, please send me your ideas and >>>> presentations!!! >>>> >>>> I'd like to help organize the discussion on ctkScene that is scheduled >>>> for next Friday. >>>> >>>> 1) If you are interested in making a brief presentation (less than 10 >>>> minutes), then please send me an email with the title. ? I will add it >>>> into our agenda. >>>> >>>> 2) If you have revisions to the Wiki page on ctkScene - please make >>>> those revisions by 5pm EST (22:00 GMT) on Friday. ? I am going to >>>> summarize those wiki pages as a set of slides at the start of the >>>> meeting. >>>> ? ? http://my-trac.assembla.com/protoctk/wiki/ctkScene >>>> >>>> 3) If you have questions, concerns, needs, wants, or rants regarding >>>> the ctkScene, please send them to me and I will create a set of slides >>>> that list "open-issues" to help focus our discussions. ? We only have >>>> one-hour, so I'd like to focus on high-level issues that remain, prior >>>> to getting into implementation details. ? For example, should a >>>> ctkScene be only a file format or should it also be implemented as a >>>> set of C++ classes? ? Should a ctkScene be specific to or independent >>>> of the visualization library? ? Should a ctkScene be our primary data >>>> structure, or should our primary data structure simply be an image? >>>> ...please add to this list of questions... >>>> >>>> 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 >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> -- >>> 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 >>> >> >> >> > -- 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 Tue Sep 22 15:28:18 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Tue, 22 Sep 2009 17:28:18 +0200 Subject: [Ctk-developers] CTK Oxford meeting: some slides from B3C Message-ID: <7F5F6EA6-821E-4A47-A191-120C3FE33D33@tecno.ior.it> Dear All: I am not sure how we shall run the meeting in Oxford but just in case a put together some slide with a few ideas I collected during these months. This is just a first draft, but I thought it might be nice to share it with you. Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: pres_b3c_ctk_Oxford2009_v1.ppt Type: application/vnd.ms-powerpoint Size: 953856 bytes Desc: not available URL: -------------- next part -------------- -------------------------------------------------- MARCO VICECONTI, PhD - BioComputing Competence Centre (B3C) - SCS s.r.l. - http://www.b3c.it Via Magnanelli 2, 40033 Casalecchio di Reno, Italy - Tel: +39-051-6366865 Visit our Biomedical Research on-line community: http://www.biomedtown.org --------------------------------------------------