From tarboxl at mir.wustl.edu Mon Nov 2 18:01:01 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Mon, 2 Nov 2009 12:01:01 -0600 Subject: [Ctk-developers] Meeting at RSNA Message-ID: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> As we discussed in Oxford, we have arranged for a meeting room at RSNA 2009. Here are the particulars: Event: The Common Tool Kit Planning Meeting Time: 9:00 AM - 6:00 PM Venue: McCormick Place, Lakeside Building Date: Sunday, November 29, 2009 Room: E262 See you in Chicago! ________________________________ The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kikinis at bwh.harvard.edu Tue Nov 3 12:50:23 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Tue, 03 Nov 2009 07:50:23 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <4AF0270F.6090108@bwh.harvard.edu> Hello everybody, Many thanks to Larry for making the room arrangements. I have started a page for this event on the NA-MIC wiki. Please add your names if you are planning to come. Please feel free to edit and or add to the page. I have invited Terry Yoo from NLM to join us. Terry is responsible for conceiving ITK. I think that he would be interested in our discussions and might provide some valuable input. Ron Tarbox, Lawrence wrote: > As we discussed in Oxford, we have arranged for a meeting room at RSNA > 2009. Here are the particulars: > > > > Event: The Common Tool Kit Planning Meeting > > Time: 9:00 AM ? 6:00 PM > > Venue: McCormick Place, Lakeside Building > > Date: Sunday, November 29, 2009 > > Room: E262 > > > > See you in Chicago! > > > > > ------------------------------------------------------------------------ > The material in this message is private and may contain Protected > Healthcare Information (PHI). If you are not the intended recipient, be > advised that any unauthorized use, disclosure, copying or the taking of > any action in reliance on the contents of this information is strictly > prohibited. If you have received this email in error, please immediately > notify the sender via telephone or return mail. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From kikinis at bwh.harvard.edu Tue Nov 3 12:59:04 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Tue, 03 Nov 2009 07:59:04 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <4AF0270F.6090108@bwh.harvard.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <4AF0270F.6090108@bwh.harvard.edu> Message-ID: <4AF02918.2040406@bwh.harvard.edu> http://wiki.na-mic.org/Wiki/index.php/Events:CTK-Workshop-Chicago-2009 Forgot the link. Here it is. Ron Kikinis wrote: > Hello everybody, > > Many thanks to Larry for making the room arrangements. > I have started a page for this event on the NA-MIC wiki. Please add your > names if you are planning to come. Please feel free to edit and or add > to the page. > I have invited Terry Yoo from NLM to join us. Terry is responsible for > conceiving ITK. I think that he would be interested in our discussions > and might provide some valuable input. > > Ron > > > Tarbox, Lawrence wrote: >> As we discussed in Oxford, we have arranged for a meeting room at RSNA >> 2009. Here are the particulars: >> >> >> >> Event: The Common Tool Kit Planning Meeting >> >> Time: 9:00 AM ? 6:00 PM >> >> Venue: McCormick Place, Lakeside Building >> >> Date: Sunday, November 29, 2009 >> >> Room: E262 >> >> >> >> See you in Chicago! >> >> >> >> >> ------------------------------------------------------------------------ >> The material in this message is private and may contain Protected >> Healthcare Information (PHI). If you are not the intended recipient, >> be advised that any unauthorized use, disclosure, copying or the >> taking of any action in reliance on the contents of this information >> is strictly prohibited. If you have received this email in error, >> please immediately notify the sender via telephone or return mail. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From tarboxl at mir.wustl.edu Tue Nov 3 17:02:34 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Tue, 3 Nov 2009 11:02:34 -0600 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <4AF0270F.6090108@bwh.harvard.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <4AF0270F.6090108@bwh.harvard.edu> Message-ID: <67B4B5166383D848A0565AA7491841F92EC5A36A8E@RAD-VMSRVEXV2.rad.wustl.edu> I heard yesterday from the Kitware folks that NLM(?) may be issuing an RFP to creating the next major version of ITK. Since we all leverage ITK in some way, and I expect a new version of ITK would be a core piece of CTK, would it be appropriate for the CTK consortium to collectively respond to the anticipated RFP? If CTK were to submit a proposal, I would suspect that a lion's share of the work would be done by a core group (e.g. Kitware and/or NA-MIC), with perhaps small contributions by others. -----Original Message----- From: Ron Kikinis [mailto:kikinis at bwh.harvard.edu] Sent: Tuesday, November 03, 2009 06:50 AM To: Tarbox, Lawrence Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] Meeting at RSNA Hello everybody, Many thanks to Larry for making the room arrangements. I have started a page for this event on the NA-MIC wiki. Please add your names if you are planning to come. Please feel free to edit and or add to the page. I have invited Terry Yoo from NLM to join us. Terry is responsible for conceiving ITK. I think that he would be interested in our discussions and might provide some valuable input. Ron Tarbox, Lawrence wrote: > As we discussed in Oxford, we have arranged for a meeting room at RSNA > 2009. Here are the particulars: > > > > Event: The Common Tool Kit Planning Meeting > > Time: 9:00 AM - 6:00 PM > > Venue: McCormick Place, Lakeside Building > > Date: Sunday, November 29, 2009 > > Room: E262 > > > > See you in Chicago! > > > > > ------------------------------------------------------------------------ > The material in this message is private and may contain Protected > Healthcare Information (PHI). If you are not the intended recipient, be > advised that any unauthorized use, disclosure, copying or the taking of > any action in reliance on the contents of this information is strictly > prohibited. If you have received this email in error, please immediately > notify the sender via telephone or return mail. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From viceconti at tecno.ior.it Sun Nov 8 06:14:55 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Sun, 8 Nov 2009 07:14:55 +0100 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: References: Message-ID: Dear Paul: I hope you do not mind if I put in CC the CTK list, as this conversation might be of their interest. I was not familiar with this pattern, and I found it very interesting. but I disagree on the use in the XDOM story. If I got it right, this is a pattern where you can change at run time un particular method in one particular instance of a class, as far as it is designed according to this pattern. So if you have a volume class that support the method spin voxels, which makes all voxels to revolve clockwise, you can load runtime a decorator in a specific view so that all instances of the volume class loaded in that view actually spin counterclockwise. In creating an extensible data object model (XDOM) however, the problem is not to override methods, but to allow the plugin programmer to add new methods that extend a template data type. In this sense I believe the bridge pattern is more adequate: http://en.wikipedia.org/wiki/Bridge_pattern Still, I think we should give this pattern a closer look, because there are a number of cases where it might come handy. I suspect that the mechanism our colleagues in INRIA described at the CTK meeting in Oxford is strongly based on the ability of QTObjects and derivative to exchange messages, making simple and efficient the use of message-passing mechanisms. This however creates a strong dependency onto QT, which we might want to discourage in CTK (we should remember QT already changed license model 2 times :-) ). Thus, I hope they agree that some lateral thinking on this matter is helpful. Cheers Marco Il giorno 4 Nov 2009, alle ore 09:41, Paul Desmedt ha scritto: > Hi Marco,When you were explaining the XDOM principle it made me > think a lot of the decorator pattern,Which is a method to easily > extend functionality in which basically the inheritence is bypassed.I > ?m not an expert in this so I could be wrong, find below the > introduction from wikipedia (http://en.wikipedia.org/wiki/Decorator_pattern > ). > Introduction > The decorator pattern can be used to make it possible to extend > (decorate) the functionality of a certain object at runtime, > independently of other instances of the same class, provided some > groundwork is done at design time. This is achieved by designing a > new decorator class that wraps the original class. This wrapping > could be achieved by the following sequence of steps: > > ? Subclass the original "Component" class into a "Decorator" class > (see UML diagram); > ? In the Decorator class, add a Component pointer as a field; > ? Pass a Component to the Decorator constructor to initialize the > Component pointer; > ? In the Decorator class, redirect all "Component" methods to the > "Component" pointer; and > ? In the Decorator class, override any Component method(s) whose > behaviour needs to be modified. > This pattern is designed so that multiple decorators can be stacked > on top of each other, each time adding a new functionality to the > overridden method(s). > > -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From m.nolden at dkfz-heidelberg.de Sun Nov 8 11:07:24 2009 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Sun, 08 Nov 2009 12:07:24 +0100 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: References: Message-ID: <4AF6A66C.2010108@dkfz-heidelberg.de> Marco Viceconti wrote: > I suspect that the mechanism our colleagues in INRIA described at the > CTK meeting in Oxford is strongly based on the ability of QTObjects > and derivative to exchange messages, making simple and efficient the > use of message-passing mechanisms. This however creates a strong > dependency onto QT, which we might want to discourage in CTK (we > should remember QT already changed license model 2 times :-) ). > > Dear Marco, at the first CTK meeting in Heidelberg we agreed on using Qt in CTK, since everyone is already using it. This does not necessarily include the Qt GUI classes, but the Qt Core module which offers the message-passing mechanisms. Of course such a strong dependency should always be discussed, but I'm not afraid of any licensing changes anymore. Regards Marco (the other one) -- ---------------------------------------------------------------------- Dipl.-Inform. Med. Marco Nolden Deutsches Krebsforschungszentrum (German Cancer Research Center) Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325 Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 D-69120 Heidelberg eMail: M.Nolden at dkfz.de From stephen.aylward at kitware.com Sun Nov 8 15:38:29 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 8 Nov 2009 10:38:29 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> Hi, Can we arrange for a phone line or internet connection in the room? I am not going to be able to attend on Sunday, and I'd like to participate via a conference line or Skype. I'd also like to encourage people to add to the agenda: list presentations you'd like to make, demonstrations you'd like to give, funding you are pursing, etc. Steve - would you be willing to present the details of the SlicerQt effort if J2 and JC provide slides to you? Thanks, Stephen PS> Kitware has a conference line we can use. On Mon, Nov 2, 2009 at 1:01 PM, Tarbox, Lawrence wrote: > As we discussed in Oxford, we have arranged for a meeting room at RSNA > 2009.? Here are the particulars: > > > > Event:? The Common Tool Kit Planning Meeting > > Time:? 9:00 AM ? 6:00 PM > > Venue:? McCormick Place, Lakeside Building > > Date:? Sunday, November 29, 2009 > > Room:? E262 > > > > See you in Chicago! > > > > ________________________________ > The material in this message is private and may contain Protected Healthcare > Information (PHI). If you are not the intended recipient, be advised that > any unauthorized use, disclosure, copying or the taking of any action in > reliance on the contents of this information is strictly prohibited. If you > have received this email in error, please immediately notify the sender via > telephone or return mail. > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From kikinis at bwh.harvard.edu Sun Nov 8 15:56:32 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Sun, 08 Nov 2009 10:56:32 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> Message-ID: <4AF6EA30.6010604@bwh.harvard.edu> Hi, I have offered to sponsor the room. I will not sponsor connectivity. The format of our get-togethers is not well suited for remote attendance. Ron Stephen Aylward wrote: > Hi, > > Can we arrange for a phone line or internet connection in the room? > I am not going to be able to attend on Sunday, and I'd like to > participate via a conference line or Skype. > > I'd also like to encourage people to add to the agenda: list > presentations you'd like to make, demonstrations you'd like to give, > funding you are pursing, etc. > > Steve - would you be willing to present the details of the SlicerQt > effort if J2 and JC provide slides to you? > > Thanks, > Stephen > > PS> Kitware has a conference line we can use. > > On Mon, Nov 2, 2009 at 1:01 PM, Tarbox, Lawrence wrote: >> As we discussed in Oxford, we have arranged for a meeting room at RSNA >> 2009. Here are the particulars: >> >> >> >> Event: The Common Tool Kit Planning Meeting >> >> Time: 9:00 AM ? 6:00 PM >> >> Venue: McCormick Place, Lakeside Building >> >> Date: Sunday, November 29, 2009 >> >> Room: E262 >> >> >> >> See you in Chicago! >> >> >> >> ________________________________ >> The material in this message is private and may contain Protected Healthcare >> Information (PHI). If you are not the intended recipient, be advised that >> any unauthorized use, disclosure, copying or the taking of any action in >> reliance on the contents of this information is strictly prohibited. If you >> have received this email in error, please immediately notify the sender via >> telephone or return mail. >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- 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 Sun Nov 8 16:07:58 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 8 Nov 2009 11:07:58 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <67B4B5166383D848A0565AA7491841F92EC5A36A8E@RAD-VMSRVEXV2.rad.wustl.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <4AF0270F.6090108@bwh.harvard.edu> <67B4B5166383D848A0565AA7491841F92EC5A36A8E@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <68a07c2d0911080807r43fe66d9g7b426a21933c4b5f@mail.gmail.com> Hi, Regarding the ITKv4 effort, I will present what I know and what I recommend. =========== What I know (some is second-hand rumors and some is from an ITK review meeting held at the NLM in June 2009): Background: The June NLM meeting recommended that the new ITK consist of a compact, stable, well-tested core and external modules that provide domain-specific features. For example, there could be a module for microscopy methods, another for video processing, another for DTI processing, etc. With this in mind, there will be two types of funding: * NLM is going to fund multiple (6? 8?) contracts to develop the next generation of ITK. Each contract will be about $500K total. It is unclear if the timeline is one or two years. This awards cannot involve GUI or visualizations - just as ITK does not currently involve GUI or visualizations. These awards should not be used to develop algorithms. These awards are intended for ITK infrastructure (wrapping for other languages, multi-threading and distributed computing support, etc). These are lengthy (25 page?) proposals. * NLM is ALSO going to fund ~10 awards to "users" who represent different application areas, algorithms, and data. Each of these "A2D2" awards is going to be for ~150K total for one or two years. These awards can propose the development of application, auxiliary (GUI) toolkits, algorithm distribution, data distribution, DICOM support, etc. Each group can submit multiple proposals. The proposals will probably 5 pages or so. BOTH call for proposals are expected "any day" - but the NLM has been making that claim for several months. I believe the money has been set-aside, but the NIH is quite swamped with processing applications/awards associated with the President's economic stimulus package. Historically the NLM has made awards to groups in the USA AND in Europe! ======== What I recommend: * The CTK folks should submit multiple A2D2 proposals. They can propose to add algorithms, data, GUI support, DICOM support, etc to the external modules that will be associated with ITK. Each proposal should be independent, but should point towards a common goal. We can perhaps prepare some boilerplate text for inclusion in the proposals. * If you've done basic ITK development you should also submit proposals for the ITKv4 core development (Ivo, INRIA, etc.). Again, these proposals are meant to stand on their own, but we should identify a common theme. The NLM likes to make individual awards and then create the team themselves. They did this for the original ITK development - each of the 5 initial groups had written their own proposals, as if each would do all development themselves. Then the NLM made us work together as a team. There is some concern that the NLM won't receive enough of these "core" proposals, so if you have ITK infrastructure development expertise, please consider applying. Again, these cannot mention GUI, visualization, etc - such things will never be in the core of ITK. I hope this helps, Stephen On Tue, Nov 3, 2009 at 12:02 PM, Tarbox, Lawrence wrote: > I heard yesterday from the Kitware folks that NLM(?) may be issuing an RFP to creating the next major version of ITK. ?Since we all leverage ITK in some way, and I expect a new version of ITK would be a core piece of CTK, would it be appropriate for the CTK consortium to collectively respond to the anticipated RFP? ?If CTK were to submit a proposal, I would suspect that a lion's share of the work would be done by a core group (e.g. Kitware and/or NA-MIC), with perhaps small contributions by others. > > -----Original Message----- > From: Ron Kikinis [mailto:kikinis at bwh.harvard.edu] > Sent: Tuesday, November 03, 2009 06:50 AM > To: Tarbox, Lawrence > Cc: ctk-developers at commontk.org > Subject: Re: [Ctk-developers] Meeting at RSNA > > Hello everybody, > > Many thanks to Larry for making the room arrangements. > I have started a page for this event on the NA-MIC wiki. Please add your > names if you are planning to come. Please feel free to edit and or add > to the page. > I have invited Terry Yoo from NLM to join us. Terry is responsible for > conceiving ITK. I think that he would be interested in our discussions > and might provide some valuable input. > > Ron > > > Tarbox, Lawrence wrote: >> As we discussed in Oxford, we have arranged for a meeting room at RSNA >> 2009. ?Here are the particulars: >> >> >> >> Event: ?The Common Tool Kit Planning Meeting >> >> Time: ?9:00 AM - 6:00 PM >> >> Venue: ?McCormick Place, Lakeside Building >> >> Date: ?Sunday, November 29, 2009 >> >> Room: ?E262 >> >> >> >> See you in Chicago! >> >> >> >> >> ------------------------------------------------------------------------ >> The material in this message is private and may contain Protected >> Healthcare Information (PHI). If you are not the intended recipient, be >> advised that any unauthorized use, disclosure, copying or the taking of >> any action in reliance on the contents of this information is strictly >> prohibited. If you have received this email in error, please immediately >> notify the sender via telephone or return mail. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- > Ron Kikinis, M.D., > Professor of Radiology, Harvard Medical School > Director, Surgical Planning Laboratory > http://www.spl.harvard.edu/~kikinis > > The material in this message is private and may contain Protected Healthcare Information (PHI). ?If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. ?If you have received this email in error, please immediately notify the sender via telephone or return mail. > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From stephen.aylward at kitware.com Sun Nov 8 16:11:48 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 8 Nov 2009 11:11:48 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <4AF6EA30.6010604@bwh.harvard.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> <4AF6EA30.6010604@bwh.harvard.edu> Message-ID: <68a07c2d0911080811p32611fadl1b34c6702cdc576d@mail.gmail.com> Understood. Thanks for sponsoring the room! I look forward to meeting with everyone at SPIE Medical Imaging in February, 2010 in California. Best regards, Stephen On Sun, Nov 8, 2009 at 10:56 AM, Ron Kikinis wrote: > Hi, > I have offered to sponsor the room. I will not sponsor connectivity. The > format of our get-togethers is not well suited for remote attendance. > Ron > > Stephen Aylward wrote: >> >> Hi, >> >> Can we arrange for a phone line or internet connection in the room? >> I am not going to be able to attend on Sunday, and I'd like to >> participate via a conference line or Skype. >> >> I'd also like to encourage people to add to the agenda: list >> presentations you'd like to make, demonstrations you'd like to give, >> funding you are pursing, etc. >> >> Steve - would you be willing to present the details of the SlicerQt >> effort if J2 and JC provide slides to you? >> >> Thanks, >> Stephen >> >> PS> Kitware has a conference line we can use. >> >> On Mon, Nov 2, 2009 at 1:01 PM, Tarbox, Lawrence >> wrote: >>> >>> As we discussed in Oxford, we have arranged for a meeting room at RSNA >>> 2009. ?Here are the particulars: >>> >>> >>> >>> Event: ?The Common Tool Kit Planning Meeting >>> >>> Time: ?9:00 AM ? 6:00 PM >>> >>> Venue: ?McCormick Place, Lakeside Building >>> >>> Date: ?Sunday, November 29, 2009 >>> >>> Room: ?E262 >>> >>> >>> >>> See you in Chicago! >>> >>> >>> >>> ________________________________ >>> The material in this message is private and may contain Protected >>> Healthcare >>> Information (PHI). If you are not the intended recipient, be advised that >>> any unauthorized use, disclosure, copying or the taking of any action in >>> reliance on the contents of this information is strictly prohibited. If >>> you >>> have received this email in error, please immediately notify the sender >>> via >>> telephone or return mail. >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> >> >> > > -- > Ron Kikinis, M.D., > Professor of Radiology, Harvard Medical School > Director, Surgical Planning Laboratory > http://www.spl.harvard.edu/~kikinis > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From pieper at bwh.harvard.edu Sun Nov 8 17:01:25 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Sun, 08 Nov 2009 12:01:25 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> Message-ID: <4AF6F965.1070405@bwh.harvard.edu> Hi Stephen - Yes, definitely, I'd love to present the Qt and Slicer effort and will coordinate with J2 and JC. This can be a sort of status update and design review. (As a preview, there are links to the project info and work-in-process code below). Also, I've been in contact with the Qt group at Nokia. They are very interested in participating but may have trouble making the meeting in person. An alternative might be to schedule a teleconference/webinar of sorts on another day where they can present their technical and community involvement plans for Q&A. Any feedback on the best strategy for this would be welcome. -Steve http://www.na-mic.org/Wiki/index.php/Projects:ARRA:SlicerUI http://viewvc.slicer.org/viewcvs.cgi/trunk/Libs/qCTKWidgets/ http://viewvc.slicer.org/viewcvs.cgi/trunk/Libs/qMRMLWidgets/ Stephen Aylward wrote: > Hi, > > Can we arrange for a phone line or internet connection in the room? > I am not going to be able to attend on Sunday, and I'd like to > participate via a conference line or Skype. > > I'd also like to encourage people to add to the agenda: list > presentations you'd like to make, demonstrations you'd like to give, > funding you are pursing, etc. > > Steve - would you be willing to present the details of the SlicerQt > effort if J2 and JC provide slides to you? > > Thanks, > Stephen > > PS> Kitware has a conference line we can use. > > On Mon, Nov 2, 2009 at 1:01 PM, Tarbox, Lawrence wrote: >> As we discussed in Oxford, we have arranged for a meeting room at RSNA >> 2009. Here are the particulars: >> >> >> >> Event: The Common Tool Kit Planning Meeting >> >> Time: 9:00 AM ? 6:00 PM >> >> Venue: McCormick Place, Lakeside Building >> >> Date: Sunday, November 29, 2009 >> >> Room: E262 >> >> >> >> See you in Chicago! >> >> >> >> ________________________________ >> The material in this message is private and may contain Protected Healthcare >> Information (PHI). If you are not the intended recipient, be advised that >> any unauthorized use, disclosure, copying or the taking of any action in >> reliance on the contents of this information is strictly prohibited. If you >> have received this email in error, please immediately notify the sender via >> telephone or return mail. >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > From stephen.aylward at kitware.com Sun Nov 8 17:40:59 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 8 Nov 2009 12:40:59 -0500 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <4AF6F965.1070405@bwh.harvard.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> <4AF6F965.1070405@bwh.harvard.edu> Message-ID: <68a07c2d0911080940v20592cfaw80092cd3eacb0ba7@mail.gmail.com> Having webinars might be a great way for the technical aspects of the project to continue to move forward in sync - great idea! I volunteer you, J2, and JC for the first one :) Perhaps something in early December and with a strong technical focus? That way you can keep the RSNA presentation focused on bigger issues such as how to move the code into the CTK repository, documentation and testing standards, and other such policies. Stephen On Sun, Nov 8, 2009 at 12:01 PM, Steve Pieper wrote: > Hi Stephen - > > Yes, definitely, I'd love to present the Qt and Slicer effort and will > coordinate with J2 and JC. ?This can be a sort of status update and design > review. ?(As a preview, there are links to the project info and > work-in-process code below). > > Also, I've been in contact with the Qt group at Nokia. ?They are very > interested in participating but may have trouble making the meeting in > person. ?An alternative might be to schedule a teleconference/webinar of > sorts on another day where they can present their technical and community > involvement plans for Q&A. ?Any feedback on the best strategy for this would > be welcome. > > -Steve > > > http://www.na-mic.org/Wiki/index.php/Projects:ARRA:SlicerUI > > http://viewvc.slicer.org/viewcvs.cgi/trunk/Libs/qCTKWidgets/ > > http://viewvc.slicer.org/viewcvs.cgi/trunk/Libs/qMRMLWidgets/ > > > > Stephen Aylward wrote: >> >> Hi, >> >> Can we arrange for a phone line or internet connection in the room? >> I am not going to be able to attend on Sunday, and I'd like to >> participate via a conference line or Skype. >> >> I'd also like to encourage people to add to the agenda: list >> presentations you'd like to make, demonstrations you'd like to give, >> funding you are pursing, etc. >> >> Steve - would you be willing to present the details of the SlicerQt >> effort if J2 and JC provide slides to you? >> >> Thanks, >> Stephen >> >> PS> Kitware has a conference line we can use. >> >> On Mon, Nov 2, 2009 at 1:01 PM, Tarbox, Lawrence >> wrote: >>> >>> As we discussed in Oxford, we have arranged for a meeting room at RSNA >>> 2009. ?Here are the particulars: >>> >>> >>> >>> Event: ?The Common Tool Kit Planning Meeting >>> >>> Time: ?9:00 AM ? 6:00 PM >>> >>> Venue: ?McCormick Place, Lakeside Building >>> >>> Date: ?Sunday, November 29, 2009 >>> >>> Room: ?E262 >>> >>> >>> >>> See you in Chicago! >>> >>> >>> >>> ________________________________ >>> The material in this message is private and may contain Protected >>> Healthcare >>> Information (PHI). If you are not the intended recipient, be advised that >>> any unauthorized use, disclosure, copying or the taking of any action in >>> reliance on the contents of this information is strictly prohibited. If >>> you >>> have received this email in error, please immediately notify the sender >>> via >>> telephone or return mail. >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> >> >> > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From stephen.aylward at kitware.com Sun Nov 8 22:51:57 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 8 Nov 2009 17:51:57 -0500 Subject: [Ctk-developers] Logo idea Message-ID: <68a07c2d0911081451g60335406l882b7ddf9300018b@mail.gmail.com> Hi, Working on the commontk.org website... What about the attached as a logo for CTK? Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 -------------- next part -------------- A non-text attachment was scrubbed... Name: CTK.jpg Type: image/jpeg Size: 49925 bytes Desc: not available URL: From stephen.aylward at kitware.com Sun Nov 8 23:50:51 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 8 Nov 2009 18:50:51 -0500 Subject: [Ctk-developers] Wiki pages and logos Message-ID: <68a07c2d0911081550v3f327e50pb3888a895d5c99f@mail.gmail.com> Hi, We've begun working on the CTK wiki pages: http://www.commontk.org/cgi-bin/trac.cgi/wiki 1) To gain request write-access to those pages, please fill-out the form at: https://www.kitware.com/Admin/SendPassword.cgi For the "requested resource" field, please enter "CTK TRAC write access" 2) I've created a candidate logo, you can see it at the bottom of the main wiki page, and at the following links: http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK.jpg http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK_with_Text.jpg I look forward to your comments and questions...and to you adding more content to these pages... Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From tarboxl at mir.wustl.edu Mon Nov 9 06:58:52 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Mon, 9 Nov 2009 00:58:52 -0600 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> <68a07c2d0911080738k671e2fe3i67b8c954704aa6cb@mail.gmail.com> Message-ID: <67B4B5166383D848A0565AA7491841F92EC595840A@RAD-VMSRVEXV2.rad.wustl.edu> Chicago - a union city - that translates into 'it is very expensive to add communications lines' because one has to hire a Union member to do the installation. RSNA does provide free wireless, but experience at the last few RSNA meetings tells me that the wireless does not always reach into the meeting rooms, and speeds are somewhat sporadic. However, it has been getting better. In other words, we wouldn't know if the free RSNA wireless will work for us until we get there. Best not to depend on it. -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward Sent: Sunday, November 08, 2009 9:38 AM To: ctk-developers at commontk.org Subject: Re: [Ctk-developers] Meeting at RSNA Hi, Can we arrange for a phone line or internet connection in the room? I am not going to be able to attend on Sunday, and I'd like to participate via a conference line or Skype. I'd also like to encourage people to add to the agenda: list presentations you'd like to make, demonstrations you'd like to give, funding you are pursing, etc. Steve - would you be willing to present the details of the SlicerQt effort if J2 and JC provide slides to you? Thanks, Stephen PS> Kitware has a conference line we can use. On Mon, Nov 2, 2009 at 1:01 PM, Tarbox, Lawrence wrote: > As we discussed in Oxford, we have arranged for a meeting room at RSNA > 2009. Here are the particulars: > > > > Event: The Common Tool Kit Planning Meeting > > Time: 9:00 AM - 6:00 PM > > Venue: McCormick Place, Lakeside Building > > Date: Sunday, November 29, 2009 > > Room: E262 > > > > See you in Chicago! > > > > ________________________________ > The material in this message is private and may contain Protected Healthcare > Information (PHI). If you are not the intended recipient, be advised that > any unauthorized use, disclosure, copying or the taking of any action in > reliance on the contents of this information is strictly prohibited. If you > have received this email in error, please immediately notify the sender via > telephone or return mail. > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From viceconti at tecno.ior.it Mon Nov 9 07:02:41 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Mon, 9 Nov 2009 08:02:41 +0100 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <4AF6A66C.2010108@dkfz-heidelberg.de> References: <4AF6A66C.2010108@dkfz-heidelberg.de> Message-ID: Worth to be said because when we agreed to use Qt, I am sure most of us were thinking of the GUI, and not of a class from which every other class in the framework would inherit. So before we carry on, at the cost of being pedantic, let me pose this question to the whole CTK group: Qt provide a portable GUI framework, that we agreed to adopt in CTK. But it also provides some interesting low-level mechanisms, in particular a extensive multi-threading library and inter-object communication mechanism. Do we all agree that also this part of Qt can be used to build CTK? Even if we agree, would not be better to ensure that CTK is not ridden of Qt code, and find solutions such as the wrapping of the QtObject class into a CTK Class? Cheers Marco Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: > Marco Viceconti wrote: >> I suspect that the mechanism our colleagues in INRIA described at >> the CTK meeting in Oxford is strongly based on the ability of >> QTObjects and derivative to exchange messages, making simple and >> efficient the use of message-passing mechanisms. This however >> creates a strong dependency onto QT, which we might want to >> discourage in CTK (we should remember QT already changed license >> model 2 times :-) ). >> >> > Dear Marco, > > at the first CTK meeting in Heidelberg we agreed on using Qt in CTK, > since everyone is already using it. This does not necessarily > include the Qt GUI classes, but the Qt Core module which offers the > message-passing mechanisms. Of course such a strong dependency > should always be discussed, but I'm not afraid of any licensing > changes anymore. > > Regards > > Marco (the other one) > > -- > ---------------------------------------------------------------------- > Dipl.-Inform. Med. Marco Nolden > Deutsches Krebsforschungszentrum (German Cancer Research Center) > Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325 > Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 > D-69120 Heidelberg eMail: M.Nolden at dkfz.de > > > > > > -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From viceconti at tecno.ior.it Mon Nov 9 08:46:54 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Mon, 9 Nov 2009 09:46:54 +0100 Subject: [Ctk-developers] Meeting at RSNA In-Reply-To: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> References: <67B4B5166383D848A0565AA7491841F92EC59583A6@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <9800AAB4-AA9F-4FFF-8EA1-34291BDBC87F@tecno.ior.it> Dear colleagues: I am sorry to inform you that neither Paolo nor I will be able to attend this CTK meeting in Chicago. I hoped I could combine it with another obligation I have in USA (IMAG Meeting) but this is much later in December. I might see you some of you there, however. Cheers Marco Il giorno 2 Nov 2009, alle ore 19:01, Tarbox, Lawrence ha scritto: > As we discussed in Oxford, we have arranged for a meeting room at > RSNA 2009. Here are the particulars: > > Event: The Common Tool Kit Planning Meeting > Time: 9:00 AM ? 6:00 PM > Venue: McCormick Place, Lakeside Building > Date: Sunday, November 29, 2009 > Room: E262 > > See you in Chicago! > > > The material in this message is private and may contain Protected > Healthcare Information (PHI). If you are not the intended recipient, > be advised that any unauthorized use, disclosure, copying or the > taking of any action in reliance on the contents of this information > is strictly prohibited. If you have received this email in error, > please immediately notify the sender via telephone or return mail. > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From pieper at bwh.harvard.edu Mon Nov 9 13:01:23 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 09 Nov 2009 08:01:23 -0500 Subject: [Ctk-developers] Wiki pages and logos In-Reply-To: <68a07c2d0911081550v3f327e50pb3888a895d5c99f@mail.gmail.com> References: <68a07c2d0911081550v3f327e50pb3888a895d5c99f@mail.gmail.com> Message-ID: <4AF812A3.4000405@bwh.harvard.edu> Hi Stephen - Thanks for digging into this! For the logo, I really like the big C - that really gets the idea across nicely. But I'm not a fan of the little red tk. Mainly because it would encourage people to write Ctk which I think is not what we want. Perhaps a non-script, smaller TK but still red? Also, I prefer the text-free variation of the logo. Another point - will you have vector versions of whatever final logo? -Steve Stephen Aylward wrote: > Hi, > > We've begun working on the CTK wiki pages: > http://www.commontk.org/cgi-bin/trac.cgi/wiki > > 1) To gain request write-access to those pages, please fill-out the form at: > https://www.kitware.com/Admin/SendPassword.cgi > For the "requested resource" field, please enter "CTK TRAC write access" > > 2) I've created a candidate logo, you can see it at the bottom of the > main wiki page, and at the following links: > http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK.jpg > http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK_with_Text.jpg > > I look forward to your comments and questions...and to you adding more > content to these pages... > > Stephen > > From stephen.aylward at kitware.com Mon Nov 9 13:25:46 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 9 Nov 2009 08:25:46 -0500 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: References: <4AF6A66C.2010108@dkfz-heidelberg.de> Message-ID: <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> 1) QtCore will supply system-level functions. "If a function we need exists in Qt, then we should use it" 2) QtGUI is optional It was more clearly stated in out meeting notes: http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 See the section called "Technical Aspects." s On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti wrote: > Worth to be said because when we agreed to use Qt, I am sure most of us were > thinking of the GUI, and not of a class from which every other class in the > framework would inherit. > > So before we carry on, at the cost of being pedantic, let me pose this > question to the whole CTK group: > > Qt provide a portable GUI framework, that we agreed to adopt in CTK. > > But it also provides some interesting low-level mechanisms, in particular a > extensive multi-threading library and inter-object communication mechanism. > ?Do we all agree that also this part of Qt can be used to build CTK? > > Even if we agree, would not be better to ensure that CTK is not ridden of Qt > code, and find solutions such as the wrapping of the QtObject class into a > CTK Class? > > Cheers > > Marco > > > > Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: > >> Marco Viceconti wrote: >>> >>> I suspect that the mechanism our colleagues in INRIA described at the >>> ?CTK meeting in Oxford is strongly based on the ability of QTObjects ?and >>> derivative to exchange messages, making simple and efficient the ?use of >>> message-passing mechanisms. ?This however creates a strong ?dependency onto >>> QT, which we might want to discourage in CTK (we ?should remember QT already >>> changed license model 2 times :-) ). >>> >>> >> Dear Marco, >> >> at the first CTK meeting in Heidelberg we agreed on using Qt in CTK, since >> everyone is already using it. This does not necessarily include the Qt GUI >> classes, but the Qt Core module which offers the message-passing mechanisms. >> Of course such a strong dependency should always be discussed, but I'm not >> afraid of any licensing changes anymore. >> >> Regards >> >> Marco (the other one) >> >> -- >> ---------------------------------------------------------------------- >> Dipl.-Inform. Med. Marco Nolden >> Deutsches Krebsforschungszentrum ? ? ? (German Cancer Research Center) >> Div. Medical & Biological Informatics ? ? ? ? ?Tel: (+49) 6221-42 2325 >> Im Neuenheimer Feld 280 ? ? ? ? ? ? ? ? ? ? ? ?Fax: (+49) 6221-42 2345 >> D-69120 Heidelberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de >> >> >> >> >> >> > > -------------------------------------------------- > MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. ? 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From stephen.aylward at kitware.com Mon Nov 9 13:31:16 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 9 Nov 2009 08:31:16 -0500 Subject: [Ctk-developers] Wiki pages and logos In-Reply-To: <4AF812A3.4000405@bwh.harvard.edu> References: <68a07c2d0911081550v3f327e50pb3888a895d5c99f@mail.gmail.com> <4AF812A3.4000405@bwh.harvard.edu> Message-ID: <68a07c2d0911090531r4fc41a1boa2ce2c35badf3743@mail.gmail.com> Hi, Good point about the tk...and a relatively easy fix. About vector versions - perhaps we can have one of the artist-types at Kitware produce one...I'm a hack... s On Mon, Nov 9, 2009 at 8:01 AM, Steve Pieper wrote: > Hi Stephen - > > Thanks for digging into this! > > For the logo, I really like the big C - that really gets the idea across > nicely. ?But I'm not a fan of the little red tk. ?Mainly because it would > encourage people to write Ctk which I think is not what we want. Perhaps a > non-script, smaller TK but still red? ?Also, I prefer the text-free > variation of the logo. > > Another point - will you have vector versions of whatever final logo? > > -Steve > > Stephen Aylward wrote: >> >> Hi, >> >> We've begun working on the CTK wiki pages: >> ? http://www.commontk.org/cgi-bin/trac.cgi/wiki >> >> 1) To gain request write-access to those pages, please fill-out the form >> at: >> ? ? ?https://www.kitware.com/Admin/SendPassword.cgi >> ?For the "requested resource" field, please enter "CTK TRAC write access" >> >> 2) I've created a candidate logo, you can see it at the bottom of the >> main wiki page, and at the following links: >> >> http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK.jpg >> >> http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK_with_Text.jpg >> >> I look forward to your comments and questions...and to you adding more >> content to these pages... >> >> Stephen >> >> > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From pieper at bwh.harvard.edu Mon Nov 9 14:22:13 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 09 Nov 2009 09:22:13 -0500 Subject: [Ctk-developers] Wiki pages and logos In-Reply-To: <68a07c2d0911090531r4fc41a1boa2ce2c35badf3743@mail.gmail.com> References: <68a07c2d0911081550v3f327e50pb3888a895d5c99f@mail.gmail.com> <4AF812A3.4000405@bwh.harvard.edu> <68a07c2d0911090531r4fc41a1boa2ce2c35badf3743@mail.gmail.com> Message-ID: <4AF82595.6080905@bwh.harvard.edu> I've had good luck in the past with converting to vector formats with http://autotrace.sourceforge.net/. But I think it's better to start with a vector drawing program from the start. -Steve Stephen Aylward wrote: > Hi, > > Good point about the tk...and a relatively easy fix. > > About vector versions - perhaps we can have one of the artist-types at > Kitware produce one...I'm a hack... > > s > > On Mon, Nov 9, 2009 at 8:01 AM, Steve Pieper wrote: >> Hi Stephen - >> >> Thanks for digging into this! >> >> For the logo, I really like the big C - that really gets the idea across >> nicely. But I'm not a fan of the little red tk. Mainly because it would >> encourage people to write Ctk which I think is not what we want. Perhaps a >> non-script, smaller TK but still red? Also, I prefer the text-free >> variation of the logo. >> >> Another point - will you have vector versions of whatever final logo? >> >> -Steve >> >> Stephen Aylward wrote: >>> Hi, >>> >>> We've begun working on the CTK wiki pages: >>> http://www.commontk.org/cgi-bin/trac.cgi/wiki >>> >>> 1) To gain request write-access to those pages, please fill-out the form >>> at: >>> https://www.kitware.com/Admin/SendPassword.cgi >>> For the "requested resource" field, please enter "CTK TRAC write access" >>> >>> 2) I've created a candidate logo, you can see it at the bottom of the >>> main wiki page, and at the following links: >>> >>> http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK.jpg >>> >>> http://www.commontk.org/cgi-bin/trac.cgi/attachment/wiki/WikiStart/CTK_with_Text.jpg >>> >>> I look forward to your comments and questions...and to you adding more >>> content to these pages... >>> >>> Stephen >>> >>> > > > From viceconti at tecno.ior.it Wed Nov 11 12:56:41 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Wed, 11 Nov 2009 13:56:41 +0100 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> References: <4AF6A66C.2010108@dkfz-heidelberg.de> <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> Message-ID: <035B7139-0CBE-44AF-8282-755C8F1015D4@tecno.ior.it> Sorry I missed this point. Ok, I trust the group on this decision. By the way this also clear a similar decision we are now taking inside MAF3 on whether to use QtObject. I presume that no one disagree with the second statement in my email: "Even if we agree [to use Qt core], would not be better to ensure that CTK is not ridden of Qt code, and find solutions such as the wrapping of the QtObject class into a CTK Class? thanks Stephen. Marco Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto: > 1) QtCore will supply system-level functions. "If a function we need > exists in Qt, then we should use it" > > 2) QtGUI is optional > > It was more clearly stated in out meeting notes: > http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 > See the section called "Technical Aspects." > > s > > On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti > wrote: >> Worth to be said because when we agreed to use Qt, I am sure most >> of us were >> thinking of the GUI, and not of a class from which every other >> class in the >> framework would inherit. >> >> So before we carry on, at the cost of being pedantic, let me pose >> this >> question to the whole CTK group: >> >> Qt provide a portable GUI framework, that we agreed to adopt in CTK. >> >> But it also provides some interesting low-level mechanisms, in >> particular a >> extensive multi-threading library and inter-object communication >> mechanism. >> Do we all agree that also this part of Qt can be used to build CTK? >> >> Even if we agree, would not be better to ensure that CTK is not >> ridden of Qt >> code, and find solutions such as the wrapping of the QtObject class >> into a >> CTK Class? >> >> Cheers >> >> Marco >> >> >> >> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: >> >>> Marco Viceconti wrote: >>>> >>>> I suspect that the mechanism our colleagues in INRIA described at >>>> the >>>> CTK meeting in Oxford is strongly based on the ability of >>>> QTObjects and >>>> derivative to exchange messages, making simple and efficient the >>>> use of >>>> message-passing mechanisms. This however creates a strong >>>> dependency onto >>>> QT, which we might want to discourage in CTK (we should remember >>>> QT already >>>> changed license model 2 times :-) ). >>>> >>>> >>> Dear Marco, >>> >>> at the first CTK meeting in Heidelberg we agreed on using Qt in >>> CTK, since >>> everyone is already using it. This does not necessarily include >>> the Qt GUI >>> classes, but the Qt Core module which offers the message-passing >>> mechanisms. >>> Of course such a strong dependency should always be discussed, but >>> I'm not >>> afraid of any licensing changes anymore. >>> >>> Regards >>> >>> Marco (the other one) >>> >>> -- >>> ---------------------------------------------------------------------- >>> Dipl.-Inform. Med. Marco Nolden >>> Deutsches Krebsforschungszentrum (German Cancer Research >>> Center) >>> Div. Medical & Biological Informatics Tel: (+49) 6221-42 >>> 2325 >>> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 >>> 2345 >>> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >>> >>> >>> >>> >>> >>> >> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it >> ) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. >> 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my >> employer >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> > > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging Research > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From stephen.aylward at kitware.com Wed Nov 11 15:49:04 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Wed, 11 Nov 2009 10:49:04 -0500 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <035B7139-0CBE-44AF-8282-755C8F1015D4@tecno.ior.it> References: <4AF6A66C.2010108@dkfz-heidelberg.de> <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> <035B7139-0CBE-44AF-8282-755C8F1015D4@tecno.ior.it> Message-ID: <68a07c2d0911110749l64718ae7ja54dad53551d05c2@mail.gmail.com> Hi Marco, I was a bit short on time and details with my last email. Sorry. You raise an interesting point. Should (or could?) some of our primary data structures derive from Qt data structures. I don't think this is a good idea. Given that we have (a) images and objects, (b) image/object processing algorithms, (c) visualization algorithms, and (d) optional GUI components in CTK, I suggest we add the following rule: NEW RULE: When images, objects, and data structures (e.g., vectors) are exposed on an API that MAY be called by image/object algorithms or by visualization algorithms, those exposed images, objects, and data structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector). What this means: a) Image/Object processing algorithms' inputs and outputs should be ITK data objects. b) Inputs to visualization algorithms should be ITK data objects. Outputs of visualization algorithms can be non-ITK (e.g., VTK, OpenInventor, ...) - assuming that they are passed directly to a GUI (i.e., not used by image/object processing algorithms and not used by other visualization algorithms). You cannot chain visualization algorithms together, unless they are passing only ITK objects. c) Qt should never be exposed by Image/Object processing algorithms or visualization algorithms. d) Use itk::Vector and NOT std::vector to represent mathematical vectors. e) Use itk::Array instead of std::list or std::vector. I know this is open to debate...so let's hear it.... :) s On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti wrote: > Sorry I missed this point. > > Ok, I trust the group on this decision. ?By the way this also clear a > similar decision we are now taking inside MAF3 on whether to use QtObject. > > I presume that no one disagree with the second statement in my email: "Even > if we agree [to use Qt core], would not be better to ensure that CTK is not > ridden of Qt > code, and find solutions such as the wrapping of the QtObject class into a > CTK Class? > > thanks Stephen. > > Marco > > > > Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto: > >> 1) QtCore will supply system-level functions. ? "If a function we need >> exists in Qt, then we should use it" >> >> 2) QtGUI is optional >> >> It was more clearly stated in out meeting notes: >> ?http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 >> See the section called "Technical Aspects." >> >> s >> >> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti >> wrote: >>> >>> Worth to be said because when we agreed to use Qt, I am sure most of us >>> were >>> thinking of the GUI, and not of a class from which every other class in >>> the >>> framework would inherit. >>> >>> So before we carry on, at the cost of being pedantic, let me pose this >>> question to the whole CTK group: >>> >>> Qt provide a portable GUI framework, that we agreed to adopt in CTK. >>> >>> But it also provides some interesting low-level mechanisms, in particular >>> a >>> extensive multi-threading library and inter-object communication >>> mechanism. >>> ?Do we all agree that also this part of Qt can be used to build CTK? >>> >>> Even if we agree, would not be better to ensure that CTK is not ridden of >>> Qt >>> code, and find solutions such as the wrapping of the QtObject class into >>> a >>> CTK Class? >>> >>> Cheers >>> >>> Marco >>> >>> >>> >>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: >>> >>>> Marco Viceconti wrote: >>>>> >>>>> I suspect that the mechanism our colleagues in INRIA described at the >>>>> ?CTK meeting in Oxford is strongly based on the ability of QTObjects >>>>> ?and >>>>> derivative to exchange messages, making simple and efficient the ?use >>>>> of >>>>> message-passing mechanisms. ?This however creates a strong ?dependency >>>>> onto >>>>> QT, which we might want to discourage in CTK (we ?should remember QT >>>>> already >>>>> changed license model 2 times :-) ). >>>>> >>>>> >>>> Dear Marco, >>>> >>>> at the first CTK meeting in Heidelberg we agreed on using Qt in CTK, >>>> since >>>> everyone is already using it. This does not necessarily include the Qt >>>> GUI >>>> classes, but the Qt Core module which offers the message-passing >>>> mechanisms. >>>> Of course such a strong dependency should always be discussed, but I'm >>>> not >>>> afraid of any licensing changes anymore. >>>> >>>> Regards >>>> >>>> Marco (the other one) >>>> >>>> -- >>>> ---------------------------------------------------------------------- >>>> Dipl.-Inform. Med. Marco Nolden >>>> Deutsches Krebsforschungszentrum ? ? ? (German Cancer Research Center) >>>> Div. Medical & Biological Informatics ? ? ? ? ?Tel: (+49) 6221-42 2325 >>>> Im Neuenheimer Feld 280 ? ? ? ? ? ? ? ? ? ? ? ?Fax: (+49) 6221-42 2345 >>>> D-69120 Heidelberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -------------------------------------------------- >>> MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) >>> Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 >>> Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. >>> 39-051-6366863 >>> via di Barbiano 1/10, 40136 - Bologna, Italy >>> >>> Tiger! Tiger! Burning bright in the forest of the night, >>> what immortal hand or eye could frame thy fearful symmetry? >>> -------------------------------------------------- >>> Opinions expressed here do not necessarily reflect those of my employer >>> >>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >> >> >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging Research >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> > > -------------------------------------------------- > MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. ? 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From pieper at bwh.harvard.edu Wed Nov 11 21:03:18 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Wed, 11 Nov 2009 16:03:18 -0500 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <68a07c2d0911110749l64718ae7ja54dad53551d05c2@mail.gmail.com> References: <4AF6A66C.2010108@dkfz-heidelberg.de> <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> <035B7139-0CBE-44AF-8282-755C8F1015D4@tecno.ior.it> <68a07c2d0911110749l64718ae7ja54dad53551d05c2@mail.gmail.com> Message-ID: <4AFB2696.1000802@bwh.harvard.edu> Whew... that's a pretty broad new rule and not one I'm willing to buy into without more discussion. In particular, to throw some more red meat on the table: * I would love to see a base set of object classes that are truly shared among vtk, itk, and all other toolkits. The fact that vtk and itk are so similar but different is a problem IMO. * I vastly prefer the runtime polymorphic behavior of vtk data structures (vtkPolyData, vtkImageData, etc) over their templated itk analogs. * Whatever programming system we adopt should be as widely used as possible through CTK and it should support things like wrapping really well. Traditionally I've liked vtk's wrapping over itk's, but Qt + PySide has the potential to be even better. Also I think Qt's signals and slots or much better than the vtk or itk events. At various time we have said we don't want to reinvent the wheel with 'yet another object system' so in spirit I agree with Stephen - in practice I'm not convinced that itk's object system is the logical choice. -Steve Stephen Aylward wrote: > Hi Marco, > > I was a bit short on time and details with my last email. Sorry. > > You raise an interesting point. Should (or could?) some of our > primary data structures derive from Qt data structures. I don't think > this is a good idea. > > Given that we have (a) images and objects, (b) image/object processing > algorithms, (c) visualization algorithms, and (d) optional GUI > components in CTK, I suggest we add the following rule: > > NEW RULE: When images, objects, and data structures (e.g., vectors) > are exposed on an API that MAY be called by image/object algorithms or > by visualization algorithms, those exposed images, objects, and data > structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector). > > What this means: > > a) Image/Object processing algorithms' inputs and outputs should be > ITK data objects. > > b) Inputs to visualization algorithms should be ITK data objects. > Outputs of visualization algorithms can be non-ITK (e.g., VTK, > OpenInventor, ...) - assuming that they are passed directly to a GUI > (i.e., not used by image/object processing algorithms and not used by > other visualization algorithms). You cannot chain visualization > algorithms together, unless they are passing only ITK objects. > > c) Qt should never be exposed by Image/Object processing algorithms or > visualization algorithms. > > d) Use itk::Vector and NOT std::vector to represent mathematical vectors. > > e) Use itk::Array instead of std::list or std::vector. > > I know this is open to debate...so let's hear it.... > > :) > > s > > On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti wrote: >> Sorry I missed this point. >> >> Ok, I trust the group on this decision. By the way this also clear a >> similar decision we are now taking inside MAF3 on whether to use QtObject. >> >> I presume that no one disagree with the second statement in my email: "Even >> if we agree [to use Qt core], would not be better to ensure that CTK is not >> ridden of Qt >> code, and find solutions such as the wrapping of the QtObject class into a >> CTK Class? >> >> thanks Stephen. >> >> Marco >> >> >> >> Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto: >> >>> 1) QtCore will supply system-level functions. "If a function we need >>> exists in Qt, then we should use it" >>> >>> 2) QtGUI is optional >>> >>> It was more clearly stated in out meeting notes: >>> http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 >>> See the section called "Technical Aspects." >>> >>> s >>> >>> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti >>> wrote: >>>> Worth to be said because when we agreed to use Qt, I am sure most of us >>>> were >>>> thinking of the GUI, and not of a class from which every other class in >>>> the >>>> framework would inherit. >>>> >>>> So before we carry on, at the cost of being pedantic, let me pose this >>>> question to the whole CTK group: >>>> >>>> Qt provide a portable GUI framework, that we agreed to adopt in CTK. >>>> >>>> But it also provides some interesting low-level mechanisms, in particular >>>> a >>>> extensive multi-threading library and inter-object communication >>>> mechanism. >>>> Do we all agree that also this part of Qt can be used to build CTK? >>>> >>>> Even if we agree, would not be better to ensure that CTK is not ridden of >>>> Qt >>>> code, and find solutions such as the wrapping of the QtObject class into >>>> a >>>> CTK Class? >>>> >>>> Cheers >>>> >>>> Marco >>>> >>>> >>>> >>>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: >>>> >>>>> Marco Viceconti wrote: >>>>>> I suspect that the mechanism our colleagues in INRIA described at the >>>>>> CTK meeting in Oxford is strongly based on the ability of QTObjects >>>>>> and >>>>>> derivative to exchange messages, making simple and efficient the use >>>>>> of >>>>>> message-passing mechanisms. This however creates a strong dependency >>>>>> onto >>>>>> QT, which we might want to discourage in CTK (we should remember QT >>>>>> already >>>>>> changed license model 2 times :-) ). >>>>>> >>>>>> >>>>> Dear Marco, >>>>> >>>>> at the first CTK meeting in Heidelberg we agreed on using Qt in CTK, >>>>> since >>>>> everyone is already using it. This does not necessarily include the Qt >>>>> GUI >>>>> classes, but the Qt Core module which offers the message-passing >>>>> mechanisms. >>>>> Of course such a strong dependency should always be discussed, but I'm >>>>> not >>>>> afraid of any licensing changes anymore. >>>>> >>>>> Regards >>>>> >>>>> Marco (the other one) >>>>> >>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> Dipl.-Inform. Med. Marco Nolden >>>>> Deutsches Krebsforschungszentrum (German Cancer Research Center) >>>>> Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325 >>>>> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 >>>>> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -------------------------------------------------- >>>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >>>> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >>>> Istituto Ortopedico Rizzoli fax. >>>> 39-051-6366863 >>>> via di Barbiano 1/10, 40136 - Bologna, Italy >>>> >>>> Tiger! Tiger! Burning bright in the forest of the night, >>>> what immortal hand or eye could frame thy fearful symmetry? >>>> -------------------------------------------------- >>>> Opinions expressed here do not necessarily reflect those of my employer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>> >>> >>> -- >>> Stephen R. Aylward, Ph.D. >>> Director of Medical Imaging Research >>> Kitware, Inc. - North Carolina Office >>> http://www.kitware.com >>> stephen.aylward (Skype) >>> (919) 969-6990 x300 >>> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my employer >> >> >> >> > > > From gianluca.paladini at siemens.com Wed Nov 11 21:24:25 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Wed, 11 Nov 2009 13:24:25 -0800 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <4AFB2696.1000802@bwh.harvard.edu> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A6FF609@USNWK100MSX.ww017.siemens.net> A problem with ITK is the fact that its memory management is limited to memory allocated on the heap. It does not accept the creation of images and volumes based on pointers to existing data allocated elsewhere, therefore it forces applications to copy data back and forth between different libraries - an interoperability issue for CTK. It also assumes memory to be contiguous, it doesn't support 3D datasets where each slice has been allocated as separate buffers. In Siemens products, where depending on the clinical application we may require to load a very large number of datasets each with a very large number of slices, we use a proprietary memory manager which allocates memory-mapped buffers and can page in such buffers in/out of physical memory efficiently under low memory conditions. We cannot use ITK in many use cases because the system could potentially run out of physical memory and start thrashing endlessly. No matter how much DRAM you put in a system, users will always find a way to use all of it. As long as we make CTK capable of accepting externally allocated data buffer pointers in order to process images/volumes (we can use smart pointers to avoid accessing null ones), and if we also introduce this feature in our respective toolkits, then we will be able to pass around image and volume data buffers between toolkits and 'wrap' them within any class from any toolkit we choose to use, as well as use any external memory management system we want. - Gianluca -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: Wednesday, November 11, 2009 4:03 PM To: Stephen Aylward Cc: Paul Desmedt; ctk-developers at commontk.org Subject: Re: [Ctk-developers] XDOM - decorator pattern Whew... that's a pretty broad new rule and not one I'm willing to buy into without more discussion. In particular, to throw some more red meat on the table: * I would love to see a base set of object classes that are truly shared among vtk, itk, and all other toolkits. The fact that vtk and itk are so similar but different is a problem IMO. * I vastly prefer the runtime polymorphic behavior of vtk data structures (vtkPolyData, vtkImageData, etc) over their templated itk analogs. * Whatever programming system we adopt should be as widely used as possible through CTK and it should support things like wrapping really well. Traditionally I've liked vtk's wrapping over itk's, but Qt + PySide has the potential to be even better. Also I think Qt's signals and slots or much better than the vtk or itk events. At various time we have said we don't want to reinvent the wheel with 'yet another object system' so in spirit I agree with Stephen - in practice I'm not convinced that itk's object system is the logical choice. -Steve Stephen Aylward wrote: > Hi Marco, > > I was a bit short on time and details with my last email. Sorry. > > You raise an interesting point. Should (or could?) some of our > primary data structures derive from Qt data structures. I don't think > this is a good idea. > > Given that we have (a) images and objects, (b) image/object processing > algorithms, (c) visualization algorithms, and (d) optional GUI > components in CTK, I suggest we add the following rule: > > NEW RULE: When images, objects, and data structures (e.g., vectors) > are exposed on an API that MAY be called by image/object algorithms or > by visualization algorithms, those exposed images, objects, and data > structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector). > > What this means: > > a) Image/Object processing algorithms' inputs and outputs should be > ITK data objects. > > b) Inputs to visualization algorithms should be ITK data objects. > Outputs of visualization algorithms can be non-ITK (e.g., VTK, > OpenInventor, ...) - assuming that they are passed directly to a GUI > (i.e., not used by image/object processing algorithms and not used by > other visualization algorithms). You cannot chain visualization > algorithms together, unless they are passing only ITK objects. > > c) Qt should never be exposed by Image/Object processing algorithms or > visualization algorithms. > > d) Use itk::Vector and NOT std::vector to represent mathematical vectors. > > e) Use itk::Array instead of std::list or std::vector. > > I know this is open to debate...so let's hear it.... > > :) > > s > > On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti wrote: >> Sorry I missed this point. >> >> Ok, I trust the group on this decision. By the way this also clear a >> similar decision we are now taking inside MAF3 on whether to use QtObject. >> >> I presume that no one disagree with the second statement in my email: >> "Even if we agree [to use Qt core], would not be better to ensure >> that CTK is not ridden of Qt code, and find solutions such as the >> wrapping of the QtObject class into a CTK Class? >> >> thanks Stephen. >> >> Marco >> >> >> >> Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto: >> >>> 1) QtCore will supply system-level functions. "If a function we need >>> exists in Qt, then we should use it" >>> >>> 2) QtGUI is optional >>> >>> It was more clearly stated in out meeting notes: >>> http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 >>> See the section called "Technical Aspects." >>> >>> s >>> >>> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti >>> >>> wrote: >>>> Worth to be said because when we agreed to use Qt, I am sure most >>>> of us were thinking of the GUI, and not of a class from which every >>>> other class in the framework would inherit. >>>> >>>> So before we carry on, at the cost of being pedantic, let me pose >>>> this question to the whole CTK group: >>>> >>>> Qt provide a portable GUI framework, that we agreed to adopt in CTK. >>>> >>>> But it also provides some interesting low-level mechanisms, in >>>> particular a extensive multi-threading library and inter-object >>>> communication mechanism. >>>> Do we all agree that also this part of Qt can be used to build CTK? >>>> >>>> Even if we agree, would not be better to ensure that CTK is not >>>> ridden of Qt code, and find solutions such as the wrapping of the >>>> QtObject class into a CTK Class? >>>> >>>> Cheers >>>> >>>> Marco >>>> >>>> >>>> >>>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: >>>> >>>>> Marco Viceconti wrote: >>>>>> I suspect that the mechanism our colleagues in INRIA described at >>>>>> the CTK meeting in Oxford is strongly based on the ability of >>>>>> QTObjects and derivative to exchange messages, making simple and >>>>>> efficient the use of message-passing mechanisms. This however >>>>>> creates a strong dependency onto QT, which we might want to >>>>>> discourage in CTK (we should remember QT already changed license >>>>>> model 2 times :-) ). >>>>>> >>>>>> >>>>> Dear Marco, >>>>> >>>>> at the first CTK meeting in Heidelberg we agreed on using Qt in >>>>> CTK, since everyone is already using it. This does not necessarily >>>>> include the Qt GUI classes, but the Qt Core module which offers >>>>> the message-passing mechanisms. >>>>> Of course such a strong dependency should always be discussed, but >>>>> I'm not afraid of any licensing changes anymore. >>>>> >>>>> Regards >>>>> >>>>> Marco (the other one) >>>>> >>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> Dipl.-Inform. Med. Marco Nolden >>>>> Deutsches Krebsforschungszentrum (German Cancer Research Center) >>>>> Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325 >>>>> Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345 >>>>> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -------------------------------------------------- >>>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >>>> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >>>> Istituto Ortopedico Rizzoli fax. >>>> 39-051-6366863 >>>> via di Barbiano 1/10, 40136 - Bologna, Italy >>>> >>>> Tiger! Tiger! Burning bright in the forest of the night, >>>> what immortal hand or eye could frame thy fearful symmetry? >>>> -------------------------------------------------- >>>> Opinions expressed here do not necessarily reflect those of my employer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>> >>> >>> -- >>> Stephen R. Aylward, Ph.D. >>> Director of Medical Imaging Research >>> Kitware, Inc. - North Carolina Office >>> http://www.kitware.com >>> stephen.aylward (Skype) >>> (919) 969-6990 x300 >>> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my employer >> >> >> >> > > > _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From viceconti at tecno.ior.it Thu Nov 12 09:43:56 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Thu, 12 Nov 2009 10:43:56 +0100 Subject: [Ctk-developers] Qt licenses model Message-ID: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> I would like to open another discussion thread, parallel to the one we started on Qt core. Currently Qt is available under two possible open source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. http://qt.nokia.com/products/licensing If I understand correctly the code is the same, the access rules are the same, so I am not sure why one would choose GPL which is more restrictive than LGPL. Can someone clarify this to me? Secondly, having agreed that CTK will be BSD-like, can anyone confirm me that by using a LGPL library to develop CTK we shall not break the BSD-like license we plan to adopt? Thanks Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From viceconti at tecno.ior.it Thu Nov 12 10:07:14 2009 From: viceconti at tecno.ior.it (Marco Viceconti) Date: Thu, 12 Nov 2009 11:07:14 +0100 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <68a07c2d0911110749l64718ae7ja54dad53551d05c2@mail.gmail.com> References: <4AF6A66C.2010108@dkfz-heidelberg.de> <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> <035B7139-0CBE-44AF-8282-755C8F1015D4@tecno.ior.it> <68a07c2d0911110749l64718ae7ja54dad53551d05c2@mail.gmail.com> Message-ID: <4CC1F7B1-6200-4A99-92AB-5822DFD75717@tecno.ior.it> Dear Stephen: there is nothing better that an a provocative statement to spark discussion, which then let emerge very interesting points such as those made by Piper and Paladini. Bravo. But .... a) if we agree to design CTK using the memory management and the inter- object communication provided by Qt, if I am not wrong this means that ALL CTK objects will have to be derived by QtObject of by a CtkObject that wraps it, not only the data objects. So the decision is much broader than this. For example one aspect that in my opinion would be worth another discussion thread where the more tech people (Paolo and Daniele on my side) start to say something is: given Gianluca point on memory management (with which I agree 100%) is the memory management mechanism (MMM) provided by QtObject sufficient for CTK? If not, does it prevents of make more difficult the development of more sophisticated MMM such as those described by Gianluca to dynamically manage objects out-of-core? another aspect: how do we ensure that if every object can send a message to any other object after a while CTK code does not become a jungle which no one can really debug? In MAF3 we plan to use a very strong encapsulation between modules, and explicitly prevent that two objects residing inside to separate modules can start to exchange messages directly. Is this a good architectural decision, we could consider also for CTK? b) the discussion in Oxford made very clear that the biggest problem we share is the lack of extensibility, completeness, and efficacy in the ALL the data object models we use in ALL our codes. All we have done with respect to data models fall short to some extend, all except maybe something in MedInria in not design to be extensible at run time, which prevents programmers to add data types as plugins. Around the idea of developing an extensible data object model (XDOM) revolves the proposal we are putting together on the EU side, under the coordination of the INRIA team. So a more realistic scenario is that we: i) discuss in depth what is wrong with each of the currently available data object models (which is already happening in this thread) ii) develop an XDOM component for CTK iii) adopt it in the next version of our respective products, including ITK and VTK (well this may take a while, but you got the idea). Cheers Marco Il giorno 11 Nov 2009, alle ore 16:49, Stephen Aylward ha scritto: > Hi Marco, > > I was a bit short on time and details with my last email. Sorry. > > You raise an interesting point. Should (or could?) some of our > primary data structures derive from Qt data structures. I don't think > this is a good idea. > > Given that we have (a) images and objects, (b) image/object processing > algorithms, (c) visualization algorithms, and (d) optional GUI > components in CTK, I suggest we add the following rule: > > NEW RULE: When images, objects, and data structures (e.g., vectors) > are exposed on an API that MAY be called by image/object algorithms or > by visualization algorithms, those exposed images, objects, and data > structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector). > > What this means: > > a) Image/Object processing algorithms' inputs and outputs should be > ITK data objects. > > b) Inputs to visualization algorithms should be ITK data objects. > Outputs of visualization algorithms can be non-ITK (e.g., VTK, > OpenInventor, ...) - assuming that they are passed directly to a GUI > (i.e., not used by image/object processing algorithms and not used by > other visualization algorithms). You cannot chain visualization > algorithms together, unless they are passing only ITK objects. > > c) Qt should never be exposed by Image/Object processing algorithms or > visualization algorithms. > > d) Use itk::Vector and NOT std::vector to represent mathematical > vectors. > > e) Use itk::Array instead of std::list or std::vector. > > I know this is open to debate...so let's hear it.... > > :) > > s > > On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti > wrote: >> Sorry I missed this point. >> >> Ok, I trust the group on this decision. By the way this also clear a >> similar decision we are now taking inside MAF3 on whether to use >> QtObject. >> >> I presume that no one disagree with the second statement in my >> email: "Even >> if we agree [to use Qt core], would not be better to ensure that >> CTK is not >> ridden of Qt >> code, and find solutions such as the wrapping of the QtObject class >> into a >> CTK Class? >> >> thanks Stephen. >> >> Marco >> >> >> >> Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto: >> >>> 1) QtCore will supply system-level functions. "If a function we >>> need >>> exists in Qt, then we should use it" >>> >>> 2) QtGUI is optional >>> >>> It was more clearly stated in out meeting notes: >>> http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 >>> See the section called "Technical Aspects." >>> >>> s >>> >>> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti >> > >>> wrote: >>>> >>>> Worth to be said because when we agreed to use Qt, I am sure most >>>> of us >>>> were >>>> thinking of the GUI, and not of a class from which every other >>>> class in >>>> the >>>> framework would inherit. >>>> >>>> So before we carry on, at the cost of being pedantic, let me pose >>>> this >>>> question to the whole CTK group: >>>> >>>> Qt provide a portable GUI framework, that we agreed to adopt in >>>> CTK. >>>> >>>> But it also provides some interesting low-level mechanisms, in >>>> particular >>>> a >>>> extensive multi-threading library and inter-object communication >>>> mechanism. >>>> Do we all agree that also this part of Qt can be used to build >>>> CTK? >>>> >>>> Even if we agree, would not be better to ensure that CTK is not >>>> ridden of >>>> Qt >>>> code, and find solutions such as the wrapping of the QtObject >>>> class into >>>> a >>>> CTK Class? >>>> >>>> Cheers >>>> >>>> Marco >>>> >>>> >>>> >>>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: >>>> >>>>> Marco Viceconti wrote: >>>>>> >>>>>> I suspect that the mechanism our colleagues in INRIA described >>>>>> at the >>>>>> CTK meeting in Oxford is strongly based on the ability of >>>>>> QTObjects >>>>>> and >>>>>> derivative to exchange messages, making simple and efficient >>>>>> the use >>>>>> of >>>>>> message-passing mechanisms. This however creates a strong >>>>>> dependency >>>>>> onto >>>>>> QT, which we might want to discourage in CTK (we should >>>>>> remember QT >>>>>> already >>>>>> changed license model 2 times :-) ). >>>>>> >>>>>> >>>>> Dear Marco, >>>>> >>>>> at the first CTK meeting in Heidelberg we agreed on using Qt in >>>>> CTK, >>>>> since >>>>> everyone is already using it. This does not necessarily include >>>>> the Qt >>>>> GUI >>>>> classes, but the Qt Core module which offers the message-passing >>>>> mechanisms. >>>>> Of course such a strong dependency should always be discussed, >>>>> but I'm >>>>> not >>>>> afraid of any licensing changes anymore. >>>>> >>>>> Regards >>>>> >>>>> Marco (the other one) >>>>> >>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> Dipl.-Inform. Med. Marco Nolden >>>>> Deutsches Krebsforschungszentrum (German Cancer Research >>>>> Center) >>>>> Div. Medical & Biological Informatics Tel: (+49) >>>>> 6221-42 2325 >>>>> Im Neuenheimer Feld 280 Fax: (+49) >>>>> 6221-42 2345 >>>>> D-69120 Heidelberg eMail: M.Nolden at dkfz.de >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -------------------------------------------------- >>>> MARCO VICECONTI, PhD (viceconti at tecno.ior.it >>>> ) >>>> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >>>> Istituto Ortopedico Rizzoli fax. >>>> 39-051-6366863 >>>> via di Barbiano 1/10, 40136 - Bologna, Italy >>>> >>>> Tiger! Tiger! Burning bright in the forest of the night, >>>> what immortal hand or eye could frame thy fearful symmetry? >>>> -------------------------------------------------- >>>> Opinions expressed here do not necessarily reflect those of my >>>> employer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>> >>> >>> >>> -- >>> Stephen R. Aylward, Ph.D. >>> Director of Medical Imaging Research >>> Kitware, Inc. - North Carolina Office >>> http://www.kitware.com >>> stephen.aylward (Skype) >>> (919) 969-6990 x300 >>> >> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it >> ) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. >> 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my >> employer >> >> >> >> > > > > -- > Stephen R. Aylward, Ph.D. > Director of Medical Imaging Research > Kitware, Inc. - North Carolina Office > http://www.kitware.com > stephen.aylward (Skype) > (919) 969-6990 x300 > -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer From will.schroeder at kitware.com Thu Nov 12 13:07:03 2009 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 12 Nov 2009 08:07:03 -0500 Subject: [Ctk-developers] Qt licenses model In-Reply-To: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> References: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> Message-ID: <3ae73beb0911120507t497baff4tfc5386995ed551b5@mail.gmail.com> We will not touch GPL. We use the LGPLd Qt in most applications we create, it should not be a problem mixing it into our BSD-licensed components. Will On Thu, Nov 12, 2009 at 4:43 AM, Marco Viceconti wrote: > I would like to open another discussion thread, parallel to the one we > started on Qt core. Currently Qt is available under two possible open > source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. > http://qt.nokia.com/products/licensing > > If I understand correctly the code is the same, the access rules are the > same, so I am not sure why one would choose GPL which is more restrictive > than LGPL. Can someone clarify this to me? > > Secondly, having agreed that CTK will be BSD-like, can anyone confirm me > that by using a LGPL library to develop CTK we shall not break the BSD-like > license we plan to adopt? > > Thanks > > Marco > > > > -------------------------------------------------- > MARCO VICECONTI, PhD (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica tel. 39-051-6366865 > Istituto Ortopedico Rizzoli fax. > 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.aylward at kitware.com Thu Nov 12 14:34:58 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 12 Nov 2009 09:34:58 -0500 Subject: [Ctk-developers] Qt licenses model In-Reply-To: <3ae73beb0911120507t497baff4tfc5386995ed551b5@mail.gmail.com> References: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> <3ae73beb0911120507t497baff4tfc5386995ed551b5@mail.gmail.com> Message-ID: <68a07c2d0911120634m4509483ax89e215d47b508f97@mail.gmail.com> I second Will's comments. We can link with LGPL libraries without corrupting our BSD-like license. The same is not true for GPL libraries - they consume any code they touch. We cannot redistribute LGPL Qt, but we can derive from and link with it. s On Thu, Nov 12, 2009 at 8:07 AM, Will Schroeder wrote: > We will not touch GPL. We use the LGPLd Qt in most applications we create, > it should not be a problem mixing it into our BSD-licensed components. > Will > > On Thu, Nov 12, 2009 at 4:43 AM, Marco Viceconti > wrote: >> >> I would like to open another discussion thread, parallel to the one we >> started on Qt core. ?Currently Qt is available under two possible open >> source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. >> http://qt.nokia.com/products/licensing >> >> If I understand correctly the code is the same, the access rules are the >> same, so I am not sure why one would choose GPL which is more restrictive >> than LGPL. ?Can someone clarify this to me? >> >> Secondly, having agreed that CTK will be BSD-like, can anyone confirm me >> that by using a LGPL library to develop CTK we shall not break the BSD-like >> license we plan to adopt? >> >> Thanks >> >> Marco >> >> >> >> -------------------------------------------------- >> MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) >> Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 >> Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. >> 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my employer >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From tarboxl at mir.wustl.edu Thu Nov 12 15:00:13 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Thu, 12 Nov 2009 09:00:13 -0600 Subject: [Ctk-developers] Qt licenses model In-Reply-To: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> References: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> Message-ID: <67B4B5166383D848A0565AA7491841F92EC647F3E7@RAD-VMSRVEXV2.rad.wustl.edu> I think the reason that the Qt Software folks (now owned by Nokia) left the GPL option in is for the benefit of some of their partners who were writing GPL code (or dual-licensed GPL/Commercial code) back in the days when Qt Software was TrollTech. Some of those partners have made additions/modifications to Qt, released them under GPL, and do not want to ever release them under LGPL. While technically they could still release their additions/modifications under GPL even though Qt is LGPL (i.e., LGPL allows it), these partners prefer to keep their licensing straight forward, and just say the whole combined mess is GPL. Qt Software is merely saying formally that Qt Software is OK with that model, basically reaffirming their partners' right to continue releasing modified versions of Qt under GPL. At least that is the impression that I get. I don't think that there is a problem with release our software under a modified BSD license, as long as we are only linking to Qt, and not modifying Qt code directly (i.e., one could switch to a Qt clone, if it existed, or to a modified version of Qt by simply rebuilding against a different link library). If we do modify the Qt code itself, then those modifications would have to be released as LGPL. Of course, if we modify Qt itself, I would vote for feeding those modifications back to the Qt community for potential incorporation into a future release of Qt. Lawrence -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Marco Viceconti Sent: Thursday, November 12, 2009 3:44 AM To: ctk-developers at commontk.org Subject: [Ctk-developers] Qt licenses model I would like to open another discussion thread, parallel to the one we started on Qt core. Currently Qt is available under two possible open source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. http://qt.nokia.com/products/licensing If I understand correctly the code is the same, the access rules are the same, so I am not sure why one would choose GPL which is more restrictive than LGPL. Can someone clarify this to me? Secondly, having agreed that CTK will be BSD-like, can anyone confirm me that by using a LGPL library to develop CTK we shall not break the BSD-like license we plan to adopt? Thanks Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From stephen.aylward at kitware.com Thu Nov 12 15:46:37 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Thu, 12 Nov 2009 10:46:37 -0500 Subject: [Ctk-developers] XDOM - decorator pattern In-Reply-To: <4CC1F7B1-6200-4A99-92AB-5822DFD75717@tecno.ior.it> References: <4AF6A66C.2010108@dkfz-heidelberg.de> <68a07c2d0911090525h18e9b38et69592530f5b8f09f@mail.gmail.com> <035B7139-0CBE-44AF-8282-755C8F1015D4@tecno.ior.it> <68a07c2d0911110749l64718ae7ja54dad53551d05c2@mail.gmail.com> <4CC1F7B1-6200-4A99-92AB-5822DFD75717@tecno.ior.it> Message-ID: <68a07c2d0911120746j759f31a2ub45f4b1a3e9c8499@mail.gmail.com> Steve, Gianluca, and Marco all raise excellent points. The three issues appear to be communication (mentioned by Steve and Marco), wrapping (Steve) and memory management (Gianluca and Marco). 1) Regarding Memory Management, ITK has an extensible Memory Management Model (MMM). While the itkImage implements a particular MMM (contiguous, etc), all of the methods access its data via iterators and calls to GetPixel. We specifically check for this. As a result, it is possible to use different MMM in ITK. We have streaming readers and writers. Our filters access data through an abstraction. The region request mechanism can be extended. I've CC'd Luis Ibanez. He can provide more insight. I am pushing this with ITK because if we can use ITK's MMM or fix it, then we benefit a much broader community and we can still make full use of ITK compared to if we try to develop something independently. 2) Regarding wrapping. this is a problem. ITKv4 should fix this, BUT I never believe such promises until they happen (particularly when I am making those promises to myself :) ). We could build our own typeless layer on top of ITK for wrapping. This layer could be the QtImage class, for example. Or use the XDOM Marco is proposing. 3) Regarding communications - this is constantly a battle. ITK, VTK, and Qt have different levels of incompatibility. Perhaps we create a typeless layer for our data and algorithms using Qt's comm mechanism. I like Marco's emphasis on modularization of the design pattern. Much work is needed here. s On Thu, Nov 12, 2009 at 5:07 AM, Marco Viceconti wrote: > Dear Stephen: > ?there is nothing better that an a provocative statement to spark > discussion, which then let emerge very interesting points such as those made > by Piper and Paladini. ?Bravo. > > But .... > > a) if we agree to design CTK using the memory management and the > inter-object communication provided by Qt, if I am not wrong this means that > ALL CTK objects will have to be derived by QtObject of by a CtkObject that > wraps it, not only the data objects. ?So the decision is much broader than > this. ? For example one aspect that in my opinion would be worth another > discussion thread where the more tech people (Paolo and Daniele on my side) > start to say something is: given Gianluca point on memory management (with > which I agree 100%) is the memory management mechanism (MMM) provided by > QtObject sufficient for CTK? ?If not, does it prevents of make more > difficult the development of more sophisticated MMM such as those described > by Gianluca to dynamically manage objects out-of-core? ?another aspect: how > do we ensure that if every object can send a message to any other object > after a while CTK code does not become a jungle which no one can really > debug? ?In MAF3 we plan to use a very strong encapsulation between modules, > and explicitly prevent that two objects residing inside to separate modules > can start to exchange messages directly. ?Is this a good architectural > decision, we could consider also for CTK? > > b) the discussion in Oxford made very clear that the biggest problem we > share is the lack of extensibility, completeness, and efficacy in the ALL > the data object models we use in ALL our codes. ?All we have done with > respect to data models fall short to some extend, all except maybe something > in MedInria in not design to be extensible at run time, which prevents > programmers to add data types as plugins. ?Around the idea of developing an > extensible data object model (XDOM) revolves the proposal we are putting > together on the EU side, under the coordination of the INRIA team. ?So a > more realistic scenario is that we: > ?i) discuss in depth what is wrong with each of the currently available data > object models (which is already happening in this thread) > ?ii) develop an XDOM component for CTK > ?iii) adopt it in the next version of our respective products, including ITK > and VTK (well this may take a while, but you got the idea). > > Cheers > > Marco > > > > > > Il giorno 11 Nov 2009, alle ore 16:49, Stephen Aylward ha scritto: > >> Hi Marco, >> >> I was a bit short on time and details with my last email. ?Sorry. >> >> You raise an interesting point. ?Should (or could?) some of our >> primary data structures derive from Qt data structures. ?I don't think >> this is a good idea. >> >> Given that we have (a) images and objects, (b) image/object processing >> algorithms, (c) visualization algorithms, and (d) optional GUI >> components in CTK, I suggest we add the following rule: >> >> NEW RULE: When images, objects, and data structures (e.g., vectors) >> are exposed on an API that MAY be called by image/object algorithms or >> by visualization algorithms, those exposed images, objects, and data >> structs should be based on ITK (itk::Image, itk::Mesh, itk::Vector). >> >> What this means: >> >> a) Image/Object processing algorithms' inputs and outputs should be >> ITK data objects. >> >> b) Inputs to visualization algorithms should be ITK data objects. >> Outputs of visualization algorithms can be non-ITK (e.g., VTK, >> OpenInventor, ...) - assuming that they are passed directly to a GUI >> (i.e., not used by image/object processing algorithms and not used by >> other visualization algorithms). ?You cannot chain visualization >> algorithms together, unless they are passing only ITK objects. >> >> c) Qt should never be exposed by Image/Object processing algorithms or >> visualization algorithms. >> >> d) Use itk::Vector and NOT std::vector to represent mathematical vectors. >> >> e) Use itk::Array instead of std::list or std::vector. >> >> I know this is open to debate...so let's hear it.... >> >> :) >> >> s >> >> On Wed, Nov 11, 2009 at 7:56 AM, Marco Viceconti >> wrote: >>> >>> Sorry I missed this point. >>> >>> Ok, I trust the group on this decision. ?By the way this also clear a >>> similar decision we are now taking inside MAF3 on whether to use >>> QtObject. >>> >>> I presume that no one disagree with the second statement in my email: >>> "Even >>> if we agree [to use Qt core], would not be better to ensure that CTK is >>> not >>> ridden of Qt >>> code, and find solutions such as the wrapping of the QtObject class into >>> a >>> CTK Class? >>> >>> thanks Stephen. >>> >>> Marco >>> >>> >>> >>> Il giorno 9 Nov 2009, alle ore 14:25, Stephen Aylward ha scritto: >>> >>>> 1) QtCore will supply system-level functions. ? "If a function we need >>>> exists in Qt, then we should use it" >>>> >>>> 2) QtGUI is optional >>>> >>>> It was more clearly stated in out meeting notes: >>>> ?http://www.na-mic.org/Wiki/index.php/Events:CTK-Workshop-June-2009 >>>> See the section called "Technical Aspects." >>>> >>>> s >>>> >>>> On Mon, Nov 9, 2009 at 2:02 AM, Marco Viceconti >>>> wrote: >>>>> >>>>> Worth to be said because when we agreed to use Qt, I am sure most of us >>>>> were >>>>> thinking of the GUI, and not of a class from which every other class in >>>>> the >>>>> framework would inherit. >>>>> >>>>> So before we carry on, at the cost of being pedantic, let me pose this >>>>> question to the whole CTK group: >>>>> >>>>> Qt provide a portable GUI framework, that we agreed to adopt in CTK. >>>>> >>>>> But it also provides some interesting low-level mechanisms, in >>>>> particular >>>>> a >>>>> extensive multi-threading library and inter-object communication >>>>> mechanism. >>>>> ?Do we all agree that also this part of Qt can be used to build CTK? >>>>> >>>>> Even if we agree, would not be better to ensure that CTK is not ridden >>>>> of >>>>> Qt >>>>> code, and find solutions such as the wrapping of the QtObject class >>>>> into >>>>> a >>>>> CTK Class? >>>>> >>>>> Cheers >>>>> >>>>> Marco >>>>> >>>>> >>>>> >>>>> Il giorno 8 Nov 2009, alle ore 12:07, Marco Nolden ha scritto: >>>>> >>>>>> Marco Viceconti wrote: >>>>>>> >>>>>>> I suspect that the mechanism our colleagues in INRIA described at the >>>>>>> ?CTK meeting in Oxford is strongly based on the ability of QTObjects >>>>>>> ?and >>>>>>> derivative to exchange messages, making simple and efficient the ?use >>>>>>> of >>>>>>> message-passing mechanisms. ?This however creates a strong >>>>>>> ?dependency >>>>>>> onto >>>>>>> QT, which we might want to discourage in CTK (we ?should remember QT >>>>>>> already >>>>>>> changed license model 2 times :-) ). >>>>>>> >>>>>>> >>>>>> Dear Marco, >>>>>> >>>>>> at the first CTK meeting in Heidelberg we agreed on using Qt in CTK, >>>>>> since >>>>>> everyone is already using it. This does not necessarily include the Qt >>>>>> GUI >>>>>> classes, but the Qt Core module which offers the message-passing >>>>>> mechanisms. >>>>>> Of course such a strong dependency should always be discussed, but I'm >>>>>> not >>>>>> afraid of any licensing changes anymore. >>>>>> >>>>>> Regards >>>>>> >>>>>> Marco (the other one) >>>>>> >>>>>> -- >>>>>> ---------------------------------------------------------------------- >>>>>> Dipl.-Inform. Med. Marco Nolden >>>>>> Deutsches Krebsforschungszentrum ? ? ? (German Cancer Research Center) >>>>>> Div. Medical & Biological Informatics ? ? ? ? ?Tel: (+49) 6221-42 2325 >>>>>> Im Neuenheimer Feld 280 ? ? ? ? ? ? ? ? ? ? ? ?Fax: (+49) 6221-42 2345 >>>>>> D-69120 Heidelberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? eMail: M.Nolden at dkfz.de >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -------------------------------------------------- >>>>> MARCO VICECONTI, PhD >>>>> (viceconti at tecno.ior.it) >>>>> Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 >>>>> Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. >>>>> 39-051-6366863 >>>>> via di Barbiano 1/10, 40136 - Bologna, Italy >>>>> >>>>> Tiger! Tiger! Burning bright in the forest of the night, >>>>> what immortal hand or eye could frame thy fearful symmetry? >>>>> -------------------------------------------------- >>>>> Opinions expressed here do not necessarily reflect those of my employer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ctk-developers mailing list >>>>> Ctk-developers at commontk.org >>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>>> >>>> >>>> >>>> >>>> -- >>>> Stephen R. Aylward, Ph.D. >>>> Director of Medical Imaging Research >>>> Kitware, Inc. - North Carolina Office >>>> http://www.kitware.com >>>> stephen.aylward (Skype) >>>> (919) 969-6990 x300 >>>> >>> >>> -------------------------------------------------- >>> MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) >>> Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 >>> Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. >>> 39-051-6366863 >>> via di Barbiano 1/10, 40136 - Bologna, Italy >>> >>> Tiger! Tiger! Burning bright in the forest of the night, >>> what immortal hand or eye could frame thy fearful symmetry? >>> -------------------------------------------------- >>> Opinions expressed here do not necessarily reflect those of my employer >>> >>> >>> >>> >> >> >> >> -- >> Stephen R. Aylward, Ph.D. >> Director of Medical Imaging Research >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> stephen.aylward (Skype) >> (919) 969-6990 x300 >> > > -------------------------------------------------- > MARCO VICECONTI, PhD ? ? ? ? ? ? ? ? ? ? ? ? ? ? (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica ? ? ? ? ? ? ?tel. ? 39-051-6366865 > Istituto Ortopedico Rizzoli ? ? ? ? ? ? ? ? ? ? ? ? ? ?fax. ? 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From will.schroeder at kitware.com Thu Nov 12 16:26:57 2009 From: will.schroeder at kitware.com (Will Schroeder) Date: Thu, 12 Nov 2009 11:26:57 -0500 Subject: [Ctk-developers] Qt licenses model In-Reply-To: <67B4B5166383D848A0565AA7491841F92EC647F3E7@RAD-VMSRVEXV2.rad.wustl.edu> References: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> <67B4B5166383D848A0565AA7491841F92EC647F3E7@RAD-VMSRVEXV2.rad.wustl.edu> Message-ID: <3ae73beb0911120826r24f6ee9dl1e3710e3f58013fc@mail.gmail.com> Maybe this wasn't clear, but if possible use a OSI-compliant license, not a modified BSD. This makes it possible to seek funding or respond to technology requests (since I believe an OSI-compliant license can be a pre-condition to engagement, it also gives a sense of authoratative approval which warms some people's hearts). We thought about gaining OSI approval for VTK's original license but eventually just adopted a standard BSD. Will On Thu, Nov 12, 2009 at 10:00 AM, Tarbox, Lawrence wrote: > I think the reason that the Qt Software folks (now owned by Nokia) left the > GPL option in is for the benefit of some of their partners who were writing > GPL code (or dual-licensed GPL/Commercial code) back in the days when Qt > Software was TrollTech. Some of those partners have made > additions/modifications to Qt, released them under GPL, and do not want to > ever release them under LGPL. While technically they could still release > their additions/modifications under GPL even though Qt is LGPL (i.e., LGPL > allows it), these partners prefer to keep their licensing straight forward, > and just say the whole combined mess is GPL. Qt Software is merely saying > formally that Qt Software is OK with that model, basically reaffirming their > partners' right to continue releasing modified versions of Qt under GPL. > > At least that is the impression that I get. > > I don't think that there is a problem with release our software under a > modified BSD license, as long as we are only linking to Qt, and not > modifying Qt code directly (i.e., one could switch to a Qt clone, if it > existed, or to a modified version of Qt by simply rebuilding against a > different link library). > > If we do modify the Qt code itself, then those modifications would have to > be released as LGPL. Of course, if we modify Qt itself, I would vote for > feeding those modifications back to the Qt community for potential > incorporation into a future release of Qt. > > Lawrence > > -----Original Message----- > From: ctk-developers-bounces at commontk.org [mailto: > ctk-developers-bounces at commontk.org] On Behalf Of Marco Viceconti > Sent: Thursday, November 12, 2009 3:44 AM > To: ctk-developers at commontk.org > Subject: [Ctk-developers] Qt licenses model > > I would like to open another discussion thread, parallel to the one we > started on Qt core. Currently Qt is available under two possible open > source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. > http://qt.nokia.com/products/licensing > > If I understand correctly the code is the same, the access rules are > the same, so I am not sure why one would choose GPL which is more > restrictive than LGPL. Can someone clarify this to me? > > Secondly, having agreed that CTK will be BSD-like, can anyone confirm > me that by using a LGPL library to develop CTK we shall not break the > BSD-like license we plan to adopt? > > Thanks > > Marco > > > > -------------------------------------------------- > MARCO VICECONTI, PhD > (viceconti at tecno.ior.it) > Laboratorio di Tecnologia Medica tel. 39-051-6366865 > Istituto Ortopedico Rizzoli fax. > 39-051-6366863 > via di Barbiano 1/10, 40136 - Bologna, Italy > > Tiger! Tiger! Burning bright in the forest of the night, > what immortal hand or eye could frame thy fearful symmetry? > -------------------------------------------------- > Opinions expressed here do not necessarily reflect those of my employer > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > The material in this message is private and may contain Protected > Healthcare Information (PHI). If you are not the intended recipient, be > advised that any unauthorized use, disclosure, copying or the taking of any > action in reliance on the contents of this information is strictly > prohibited. If you have received this email in error, please immediately > notify the sender via telephone or return mail. > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarboxl at mir.wustl.edu Thu Nov 12 18:51:02 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Thu, 12 Nov 2009 12:51:02 -0600 Subject: [Ctk-developers] Qt licenses model In-Reply-To: <3ae73beb0911120826r24f6ee9dl1e3710e3f58013fc@mail.gmail.com> References: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> <67B4B5166383D848A0565AA7491841F92EC647F3E7@RAD-VMSRVEXV2.rad.wustl.edu> <3ae73beb0911120826r24f6ee9dl1e3710e3f58013fc@mail.gmail.com> Message-ID: <67B4B5166383D848A0565AA7491841F92EC6550E4B@RAD-VMSRVEXV2.rad.wustl.edu> An OSI approved license is fine with me. Historical note - the original Berkeley license had a fourth clause in it that required acknowledging UCB in any advertising. This was a sore point within the open source community. So Berkeley modified the license to remove the advertising clause. This modified license is known as the "Modified Berkeley" or "Modified BSD" license, or in some circles the "New BSD License", and is the one that OSI approved. In 2008, the OSI board approved a variant which they call the "Simplified BSD License", which is essentially the same as what historically has been called the "Modified BSD" license. So we are talking about the same thing. Some people remove the third cause (the "no endorsement" clause), which is allowed by OSI. I would prefer if we leave it in. In fact some people (e.g. the caBIG(r) community) do not feel that the third clause goes far enough. They feel that one should mention trademarks, and not just the name of the copyright holder (i.e., that the software license is not a license to use the copyright owner's trademarks). Some of the other OSI licenses have such trademark clauses (e.g. the Apache V2.0 license). Also some people (e.g. the caBIG(r) community) feel that a patent clause is needed. Some of the other OSI licenses have such patent clauses (e.g. the Apache V2.0 license, the Mozilla 1.1 license, CDDL, the Eclipse Public License 1.0). Although I am relatively neutral, in some ways I would prefer the Apache license over the Berkeley license. The Apache license is closer to the caBIG(r) Model License Agreement that we were required to use for the initial XIP development. I definitely do not want to use a GPL license, or any license that has a viral (sometimes called "copyleft") provision, though I have no problem with utilizing LGPL code if accessed solely as a library. Lawrence From: Will Schroeder [mailto:will.schroeder at kitware.com] Sent: Thursday, November 12, 2009 10:27 AM To: Tarbox, Lawrence Cc: Marco Viceconti; ctk-developers at commontk.org Subject: Re: [Ctk-developers] Qt licenses model Maybe this wasn't clear, but if possible use a OSI-compliant license, not a modified BSD. This makes it possible to seek funding or respond to technology requests (since I believe an OSI-compliant license can be a pre-condition to engagement, it also gives a sense of authoratative approval which warms some people's hearts). We thought about gaining OSI approval for VTK's original license but eventually just adopted a standard BSD. Will On Thu, Nov 12, 2009 at 10:00 AM, Tarbox, Lawrence > wrote: I think the reason that the Qt Software folks (now owned by Nokia) left the GPL option in is for the benefit of some of their partners who were writing GPL code (or dual-licensed GPL/Commercial code) back in the days when Qt Software was TrollTech. Some of those partners have made additions/modifications to Qt, released them under GPL, and do not want to ever release them under LGPL. While technically they could still release their additions/modifications under GPL even though Qt is LGPL (i.e., LGPL allows it), these partners prefer to keep their licensing straight forward, and just say the whole combined mess is GPL. Qt Software is merely saying formally that Qt Software is OK with that model, basically reaffirming their partners' right to continue releasing modified versions of Qt under GPL. At least that is the impression that I get. I don't think that there is a problem with release our software under a modified BSD license, as long as we are only linking to Qt, and not modifying Qt code directly (i.e., one could switch to a Qt clone, if it existed, or to a modified version of Qt by simply rebuilding against a different link library). If we do modify the Qt code itself, then those modifications would have to be released as LGPL. Of course, if we modify Qt itself, I would vote for feeding those modifications back to the Qt community for potential incorporation into a future release of Qt. Lawrence -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Marco Viceconti Sent: Thursday, November 12, 2009 3:44 AM To: ctk-developers at commontk.org Subject: [Ctk-developers] Qt licenses model I would like to open another discussion thread, parallel to the one we started on Qt core. Currently Qt is available under two possible open source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. http://qt.nokia.com/products/licensing If I understand correctly the code is the same, the access rules are the same, so I am not sure why one would choose GPL which is more restrictive than LGPL. Can someone clarify this to me? Secondly, having agreed that CTK will be BSD-like, can anyone confirm me that by using a LGPL library to develop CTK we shall not break the BSD-like license we plan to adopt? Thanks Marco -------------------------------------------------- MARCO VICECONTI, PhD (viceconti at tecno.ior.it) Laboratorio di Tecnologia Medica tel. 39-051-6366865 Istituto Ortopedico Rizzoli fax. 39-051-6366863 via di Barbiano 1/10, 40136 - Bologna, Italy Tiger! Tiger! Burning bright in the forest of the night, what immortal hand or eye could frame thy fearful symmetry? -------------------------------------------------- Opinions expressed here do not necessarily reflect those of my employer _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 ________________________________ The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarboxl at mir.wustl.edu Thu Nov 12 18:57:03 2009 From: tarboxl at mir.wustl.edu (Tarbox, Lawrence) Date: Thu, 12 Nov 2009 12:57:03 -0600 Subject: [Ctk-developers] Qt licenses model In-Reply-To: <68a07c2d0911120634m4509483ax89e215d47b508f97@mail.gmail.com> References: <0DE30106-9F40-4B00-87D9-FF09457041FB@tecno.ior.it> <3ae73beb0911120507t497baff4tfc5386995ed551b5@mail.gmail.com> <68a07c2d0911120634m4509483ax89e215d47b508f97@mail.gmail.com> Message-ID: <67B4B5166383D848A0565AA7491841F92EC6550E4C@RAD-VMSRVEXV2.rad.wustl.edu> I don't think that there is any problem with redistribution of the binary Qt runtime environment with BSD-licensed code. Qt Software, I believe, expressly allows such redistribution. In fact, there is no problem with redistributing the rest of the LGPL Qt code, as long as we keep it logically separate from the BSD-licensed code (i.e., strictly a 'linked to' relationship in keeping with the LGPL provisions), and as long as we provide a means for people to get the source for the LGPL Qt code. Lawrence -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Stephen Aylward Sent: Thursday, November 12, 2009 08:35 AM To: Will Schroeder Cc: ctk-developers at commontk.org Subject: Re: [Ctk-developers] Qt licenses model I second Will's comments. We can link with LGPL libraries without corrupting our BSD-like license. The same is not true for GPL libraries - they consume any code they touch. We cannot redistribute LGPL Qt, but we can derive from and link with it. s On Thu, Nov 12, 2009 at 8:07 AM, Will Schroeder wrote: > We will not touch GPL. We use the LGPLd Qt in most applications we create, > it should not be a problem mixing it into our BSD-licensed components. > Will > > On Thu, Nov 12, 2009 at 4:43 AM, Marco Viceconti > wrote: >> >> I would like to open another discussion thread, parallel to the one we >> started on Qt core. Currently Qt is available under two possible open >> source licenses: Qt GNU LGPL v. 2.1 and Qt GNU GPL v. 3.0. >> http://qt.nokia.com/products/licensing >> >> If I understand correctly the code is the same, the access rules are the >> same, so I am not sure why one would choose GPL which is more restrictive >> than LGPL. Can someone clarify this to me? >> >> Secondly, having agreed that CTK will be BSD-like, can anyone confirm me >> that by using a LGPL library to develop CTK we shall not break the BSD-like >> license we plan to adopt? >> >> Thanks >> >> Marco >> >> >> >> -------------------------------------------------- >> MARCO VICECONTI, PhD (viceconti at tecno.ior.it) >> Laboratorio di Tecnologia Medica tel. 39-051-6366865 >> Istituto Ortopedico Rizzoli fax. >> 39-051-6366863 >> via di Barbiano 1/10, 40136 - Bologna, Italy >> >> Tiger! Tiger! Burning bright in the forest of the night, >> what immortal hand or eye could frame thy fearful symmetry? >> -------------------------------------------------- >> Opinions expressed here do not necessarily reflect those of my employer >> >> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > -- > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From stephen.aylward at kitware.com Mon Nov 16 21:28:52 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Mon, 16 Nov 2009 16:28:52 -0500 Subject: [Ctk-developers] CTK - reminders... Message-ID: <68a07c2d0911161328g7b10e1b9ycc2ff5537b9cf114@mail.gmail.com> Hi, 1) If you haven't already created an account for editing the CTK wiki pages, you should do so using the online form at: https://www.kitware.com/Admin/SendPassword.cgi 2) We have a variety of suggested logos, and we welcome additional suggestions. **** Please post your comments regarding our candidate logos to the mail list. **** The final decision will be made during the RSNA meeting. http://www.commontk.org/cgi-bin/trac.cgi 3) Details on the RSNA event are on the wiki: http://www.commontk.org/cgi-bin/trac.cgi/wiki/Events Thanks, Stephen -- Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 From pieper at bwh.harvard.edu Mon Nov 16 22:42:50 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 16 Nov 2009 17:42:50 -0500 Subject: [Ctk-developers] Nokia to participate in Chicago meeting - questions? Message-ID: <4B01D56A.5030607@bwh.harvard.edu> Hi CTKers - Representatives of Nokia/Qt have agreed to attend the upcoming Chicago meeting of the CTK effort. In preparation, Clay (cc'd) has requested that we send questions and/or discussion topics. So far we are considering the following draft agenda for the afternoon: Qt progress * 1:00 - 3:00 Nokia will present: o Evolving features of Qt o Community involvement processes o Q&A * 3:00 - 3:15 Update on qCTKWidgets being developed in Slicer's Qt Port * TBD: other Qt progress updates (Olivier? Julien? Marco? Ivo? Others?) Anything specific to add? Perhaps there are follow up questions from our recent discussions about non-widget Qt code and how widely CTK might depend on it. It will be a great opportunity to jointly understand these issues so please help us to prepare so we can make the best use of our face to face time. Thanks, Steve From pieper at bwh.harvard.edu Tue Nov 17 01:05:12 2009 From: pieper at bwh.harvard.edu (Steve Pieper) Date: Mon, 16 Nov 2009 20:05:12 -0500 Subject: [Ctk-developers] chicago meeting headcount Message-ID: <4B01F6C8.4070405@bwh.harvard.edu> We're finalizing plans for the Chicago meeting and we'd like to get a headcount by tomorrow. If you are planning to attend please email me or add your name to the wiki page participant list. http://wiki.na-mic.org/Wiki/index.php/Events:CTK-Workshop-Chicago-2009 Thanks, Steve From i.wolf at dkfz-heidelberg.de Mon Nov 23 10:35:03 2009 From: i.wolf at dkfz-heidelberg.de (Ivo Wolf) Date: Mon, 23 Nov 2009 11:35:03 +0100 Subject: [Ctk-developers] suggestions for chicago meeting Message-ID: <4B0A6557.5090908@dkfz-heidelberg.de> Dear CTKlers: we'd like to suggest to start the "Modules / Applications" session with a meta-topic: "The CTK Layer Structure". The idea is to lay a foundation for the discussions of the other topics. I will prepare a 5-8 min presentation on this. Regarding the Qt/Nokia session, we think it could be interesting to here them talk about: - Qt-Scripting support - Qt-Plugin concepts (current and future plans) - separation of the Qt-non-GUI classes from the GUI part. - are there plans for inter-process communication (IPC) support in Qt? Additionially, I think it might be a good opportunity to discuss the role of Qt in the core after the Qt/Nokia session. Best regards, Ivo From kikinis at bwh.harvard.edu Mon Nov 23 12:21:06 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Mon, 23 Nov 2009 07:21:06 -0500 Subject: [Ctk-developers] suggestions for chicago meeting In-Reply-To: <4B0A6557.5090908@dkfz-heidelberg.de> References: <4B0A6557.5090908@dkfz-heidelberg.de> Message-ID: <4B0A7E32.3030808@bwh.harvard.edu> can you insert into the wiki? Ivo Wolf wrote: > Dear CTKlers: > > we'd like to suggest to start the "Modules / Applications" session with > a meta-topic: "The CTK Layer Structure". The idea is to lay a > foundation for the discussions of the other topics. I will prepare a 5-8 > min presentation on this. > > Regarding the Qt/Nokia session, we think it could be interesting to here > them talk about: > - Qt-Scripting support > - Qt-Plugin concepts (current and future plans) > - separation of the Qt-non-GUI classes from the GUI part. > - are there plans for inter-process communication (IPC) support in Qt? > > Additionially, I think it might be a good opportunity to discuss the > role of Qt in the core after the Qt/Nokia session. > > Best regards, > > Ivo > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- Ron Kikinis, M.D., Professor of Radiology, Harvard Medical School Director, Surgical Planning Laboratory http://www.spl.harvard.edu/~kikinis From olivier.clatz at sophia.inria.fr Mon Nov 23 12:14:59 2009 From: olivier.clatz at sophia.inria.fr (Olivier Clatz) Date: Mon, 23 Nov 2009 13:14:59 +0100 Subject: [Ctk-developers] Towards a proposal for next European call Message-ID: <4B0A7CC3.9030505@sophia.inria.fr> Dear CTK partners, as you already know, we are preparing a proposal for the next (April) European call in order to fund the European part of the CTK development. We just received confirmation of participation of all the partners yesterday, and we are now launching officially the initiative. We drafted a pre-proposal together, that I attached to this email. We will have the opportunity to present this project at the next CTK meeting during RSNA. See you in Chicago, Olivier -------------- next part -------------- A non-text attachment was scrubbed... Name: preprop_CTK_Europe.pdf Type: application/pdf Size: 84049 bytes Desc: not available URL: From gianluca.paladini at siemens.com Sun Nov 29 04:27:03 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Sat, 28 Nov 2009 20:27:03 -0800 Subject: [Ctk-developers] Towards a proposal for next European call In-Reply-To: <4B0A7CC3.9030505@sophia.inria.fr> References: <4B0A7CC3.9030505@sophia.inria.fr> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A97CDE9@USNWK100MSX.ww017.siemens.net> Hi Olivier, This looks very interesting. One thing to keep in mind is that Siemens is a German company and therefore can be part of a EU grant proposal as well. The fact that our office is in Princeton is not a limiting factor, we can use any of our locations in Europe for these kind of proposals. For some grants that require it, we can also raise some matching funding. So please keep us in the loop beyond the advisory board, we can actually make a strong contribution in data management, visualization, processing and compliance. Cordially, Gianluca -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Olivier Clatz Sent: Monday, November 23, 2009 7:15 AM To: ctk-developers at commontk.org Subject: [Ctk-developers] Towards a proposal for next European call Dear CTK partners, as you already know, we are preparing a proposal for the next (April) European call in order to fund the European part of the CTK development. We just received confirmation of participation of all the partners yesterday, and we are now launching officially the initiative. We drafted a pre-proposal together, that I attached to this email. We will have the opportunity to present this project at the next CTK meeting during RSNA. See you in Chicago, Olivier From gianluca.paladini at siemens.com Sun Nov 29 05:17:39 2009 From: gianluca.paladini at siemens.com (Paladini, Gianluca (SCR US)) Date: Sat, 28 Nov 2009 21:17:39 -0800 Subject: [Ctk-developers] chicago meeting headcount In-Reply-To: <4B01F6C8.4070405@bwh.harvard.edu> References: <4B01F6C8.4070405@bwh.harvard.edu> Message-ID: <849860E57EBCC34C9E28B6E59A046CC70A97CDEE@USNWK100MSX.ww017.siemens.net> Dear all, I won't be able to make it, unfortunately I have a couple of kidney stones (7 and 10 mm) and I have to get lithotripsy on Monday. I am sending to the CTK meeting Patric Ljung, a research scientist from my program who is very knowledgeable about XIP and 3D visualization (he'll be also teaching an XIP course with Larry Tarbox on Wednesday). I hope you have a productive meeting, and I look forward to seeing you all again at the next one (SPIE, I suppose). Cordially, Gianluca -----Original Message----- From: ctk-developers-bounces at commontk.org [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper Sent: Monday, November 16, 2009 8:05 PM To: ctk-developers at commontk.org Subject: [Ctk-developers] chicago meeting headcount We're finalizing plans for the Chicago meeting and we'd like to get a headcount by tomorrow. If you are planning to attend please email me or add your name to the wiki page participant list. http://wiki.na-mic.org/Wiki/index.php/Events:CTK-Workshop-Chicago-2009 Thanks, Steve _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers From kikinis at bwh.harvard.edu Sun Nov 29 17:25:35 2009 From: kikinis at bwh.harvard.edu (Ron Kikinis) Date: Sun, 29 Nov 2009 12:25:35 -0500 Subject: [Ctk-developers] [Fwd: Doodle: Link for poll "CTK Hackfest"] Message-ID: <4B12AE8F.8080408@bwh.harvard.edu> -------- Original Message -------- Subject: Doodle: Link for poll "CTK Hackfest" Date: Sun, 29 Nov 2009 18:25:01 +0100 (CET) From: Doodle - DO NOT REPLY To: You have initiated a poll "CTK Hackfest" at Doodle. The link to your poll is: http://www.doodle.com/my29igegcd49ka2n Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) Get Premium Doodle: more features, no ads http://doodle.com/r/enPremiumDoodle -- 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 Sun Nov 29 17:57:38 2009 From: stephen.aylward at kitware.com (Stephen Aylward) Date: Sun, 29 Nov 2009 12:57:38 -0500 Subject: [Ctk-developers] first email update from CTK meeting in Chicago: hacker week around end of February proposed In-Reply-To: <4CE8C97C-8DE9-4660-802C-39A4295EA4FF@isis.georgetown.edu> References: <4CE8C97C-8DE9-4660-802C-39A4295EA4FF@isis.georgetown.edu> Message-ID: <68a07c2d0911290957o8297878r545cd3ba92239061@mail.gmail.com> Hi, I am closing on my house on Monday (must close by Dec 1 - it has been schedule for a very long time) - and have to teach at RSNA on Tuesday. Flying to and from RSNA twice in 3 days would have been too much. I do wish I could be there! The one-week event sounds interesting. It would be great if we could get some code in the repository prior to that week so that we can do "homework". We can contribute some Qt widgets (that Steve presented). They are extremely useful in app building. Can we also get some more base classes? Is ITK or VTK the base image class we should be using? Can Slicer's execution model be abstracted from MRML? Should it be? Can MITK's data structs that drive its visualizations be shared? Stephen On Sun, Nov 29, 2009 at 12:11 PM, Kevin Cleary wrote: > Here is the first news: Peter Meinzer proposed a one week "hacker meeting" > the last week in February or the first week in March to develop a small, > initial prototype of a core, and have detailed technical discussions - > either in Heidelberg or Boston > > I will have more news at the end of the day but if this meeting occurs we > will want to send someone and I will probably send Patrick if he is willing > to go > > Stephen R. Aylward, Ph.D. Director of Medical Imaging Research Kitware, Inc. - North Carolina Office http://www.kitware.com stephen.aylward (Skype) (919) 969-6990 x300 -------------- next part -------------- An HTML attachment was scrubbed... URL: