From s.mang at Dkfz-Heidelberg.de Mon Feb 3 09:11:24 2014 From: s.mang at Dkfz-Heidelberg.de (Mang, Sarah) Date: Mon, 3 Feb 2014 10:11:24 +0100 Subject: [Ctk-developers] How should status report be coded? Message-ID: Hi there, How does the result and output reporting mentioned in the documentation work? Is there an example how the reports should be formatted? Cheers, Sarah ___________________________________________________ Dr. Sarah Mang, Dipl.-Inform. Deutsches Krebsforschungszentrum Heidelberg Softwareentwicklung f?r Integrierte Diagnostik und Therapie (SIDT) , E071 Im Neuenheimer Feld 280 D-69120 Heidelberg Germany Telefon: +49 - 6221 - 42 2560 Fax: +49 - 6221 - 42 2572 ___________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Mon Feb 3 14:17:24 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Mon, 3 Feb 2014 09:17:24 -0500 Subject: [Ctk-developers] How should status report be coded? In-Reply-To: References: Message-ID: Hi Sarah, Could you provide us with more information ? What do you mean by " result and output reporting" ? If you are taking about issues/bugs, you should report them on the github tracker. See [1] Information allowing to systematically reproduce the problem should be provided: - Version of CTK - Version of OS, compiler - ... Let us know if you have any questions, Jc [1] https://github.com/commontk/CTK/issues/new 2014-02-03 Mang, Sarah : > Hi there, > > > > How does the result and output reporting mentioned in the documentation > work? > > Is there an example how the reports should be formatted? > > > > Cheers, > > Sarah > > > > ___________________________________________________ > > Dr. Sarah Mang, Dipl.-Inform. > > Deutsches Krebsforschungszentrum Heidelberg > > Softwareentwicklung f?r Integrierte Diagnostik und Therapie (SIDT) , E071 > > Im Neuenheimer Feld 280 > > D-69120 Heidelberg > > Germany > > Telefon: +49 - 6221 - 42 2560 > > Fax: +49 - 6221 - 42 2572 > > ___________________________________________________ > > > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.mang at Dkfz-Heidelberg.de Mon Feb 3 15:12:49 2014 From: s.mang at Dkfz-Heidelberg.de (Mang, Sarah) Date: Mon, 3 Feb 2014 16:12:49 +0100 Subject: [Ctk-developers] How should status report be coded? In-Reply-To: References: Message-ID: Dear JC, I was referring to the methods of asynchronous communication with running modules as mentioned in the main page of the documentation: http://www.commontk.org/docs/html/CommandLineModules_Page.html This is not an error, but I could not find a documentation on this feature, therefore I can currently not use it. My guess is that CTK reacts to certain output strings generated by the running module, but not to every output. I therefore assume that these output strings need to be formatted in a certain way. My question now is - How are they formatted? Anny help would be appreciated. Regards, Sarah Von: Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] Gesendet: Montag, 3. Februar 2014 15:17 An: Mang, Sarah Cc: ctk-developers at commontk.org Betreff: Re: [Ctk-developers] How should status report be coded? Hi Sarah, Could you provide us with more information ? What do you mean by " result and output reporting" ? If you are taking about issues/bugs, you should report them on the github tracker. See [1] Information allowing to systematically reproduce the problem should be provided: - Version of CTK - Version of OS, compiler - ... Let us know if you have any questions, Jc [1] https://github.com/commontk/CTK/issues/new 2014-02-03 Mang, Sarah >: Hi there, How does the result and output reporting mentioned in the documentation work? Is there an example how the reports should be formatted? Cheers, Sarah ___________________________________________________ Dr. Sarah Mang, Dipl.-Inform. Deutsches Krebsforschungszentrum Heidelberg Softwareentwicklung f?r Integrierte Diagnostik und Therapie (SIDT) , E071 Im Neuenheimer Feld 280 D-69120 Heidelberg Germany Telefon: +49 - 6221 - 42 2560 Fax: +49 - 6221 - 42 2572 ___________________________________________________ _______________________________________________ Ctk-developers mailing list Ctk-developers at commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.zelzer at dkfz-heidelberg.de Tue Feb 4 15:13:41 2014 From: s.zelzer at dkfz-heidelberg.de (Sascha Zelzer) Date: Tue, 04 Feb 2014 16:13:41 +0100 Subject: [Ctk-developers] How should status report be coded? In-Reply-To: References: Message-ID: <52F103A5.4010903@dkfz-heidelberg.de> Hi Sarah, just for clarifiation, CTK is made up of a couple of different libraries with different scopes. The command line module library (or "CLI" stuff) is just one part of CTK. On the page you linked, there is a section called "Progress and Result reporting". It shows an example XML snippet which - when printed by the executable to stdout, triggers the progress reporting in the ctkCmdLineModuleFuture [1] class. The format for the XML is snippet is also documented via an XSD file which is linked in that section as well [2]. Best, Sascha [1] http://www.commontk.org/docs/html/classctkCmdLineModuleFuture.html [2] http://www.commontk.org/docs/html/ctkCmdLineModuleProcess.xsd On 02/03/2014 04:12 PM, Mang, Sarah wrote: > > Dear JC, > > I was referring to the methods of asynchronous communication with > running modules as mentioned in the main page of the documentation: > > http://www.commontk.org/docs/html/CommandLineModules_Page.html > > This is not an error, but I could not find a documentation on this > feature, therefore I can currently not use it. > > My guess is that CTK reacts to certain output strings generated by the > running module, but not to every output. I therefore assume that these > output strings need to be formatted in a certain way. My question now > is ? How are they formatted? > > Anny help would be appreciated. > > Regards, > > Sarah > > *Von:*Jean-Christophe Fillion-Robin [mailto:jchris.fillionr at kitware.com] > *Gesendet:* Montag, 3. Februar 2014 15:17 > *An:* Mang, Sarah > *Cc:* ctk-developers at commontk.org > *Betreff:* Re: [Ctk-developers] How should status report be coded? > > Hi Sarah, > > Could you provide us with more information ? What do you mean by " > result and output reporting" ? > > If you are taking about issues/bugs, you should report them on the > github tracker. See [1] > > Information allowing to systematically reproduce the problem should be > provided: > > - Version of CTK > > - Version of OS, compiler > - ... > > Let us know if you have any questions, > > Jc > > > [1] https://github.com/commontk/CTK/issues/new > > 2014-02-03 Mang, Sarah >: > > Hi there, > > How does the result and output reporting mentioned in the > documentation work? > > Is there an example how the reports should be formatted? > > Cheers, > > Sarah > > ___________________________________________________ > > Dr. Sarah Mang, Dipl.-Inform. > > Deutsches Krebsforschungszentrum Heidelberg > > Softwareentwicklung f?r Integrierte Diagnostik und Therapie (SIDT) , E071 > > Im Neuenheimer Feld 280 > > D-69120 Heidelberg > > Germany > > Telefon: +49 - 6221 - 42 2560 > > Fax: +49 - 6221 - 42 2572 > > ___________________________________________________ > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.larkin at lickenbrocktech.com Mon Feb 10 19:17:46 2014 From: sean.larkin at lickenbrocktech.com (sean.larkin at lickenbrocktech.com) Date: Mon, 10 Feb 2014 12:17:46 -0700 Subject: [Ctk-developers] ctk install on Windows 7 64-bit Message-ID: <20140210121746.bcf41451ec78cfd27e91c9adae7d2273.fa6c8cd7b3.wbe@email09.secureserver.net> I'm trying to use ctk with VTK 6.0 and Qt 4.8.5. I've downloaded the ctk source and used cmake to build project files for VS2010. The cmake options I chose are Qt testing, build qt designer plug-in, build shared libs, enable widgets, CTK_LIB_CORE, all the VTK options, and CTK_SUPER_BUILD. I am able to compile ctk for release, which is what I want. When I run the INSTALL project, it creates the folder "C\:Program Files\CTK\" with only the "lib" subfolder. Inside this lib folder are a few more subfolders that lead to a bunch of ctk CMake files. There is nothing else. Why are the lib files that were built not being copied over? And where are the bin and include directories? I believe everything was built correctly, as I copied the plug-in dll files into the Qt designer folder and I can use those widgets in the Qt designer. Problem is I cannot provide include directories for my project or links to the lib files. Can anyone shed some light on what is going on here, or if I am missing a step? Thanks, Sean From pieper at isomics.com Sun Feb 16 15:51:45 2014 From: pieper at isomics.com (Steve Pieper) Date: Sun, 16 Feb 2014 10:51:45 -0500 Subject: [Ctk-developers] [slicer-devel] DICOM Module In-Reply-To: References: Message-ID: Hi Aaron - I suggest we move this discussion over to the ctk-developers mailing list (you might want to sign up [1] if you haven't already) since as you saw that level of the code is housed in CTK and there's active work going on among that group. I've cc'd ctk-developers here to get the ball rolling. Regarding the shared/static libraries issue with DCMTK it would be great to file that as an issue on the ctk issue tracker [2]. Probably the configuration of the ctkDICOM2 executable isn't getting the right flags. As for the user interface options you are right - there's a lot that can be done to simplify/streamline the interface. There's been quite some research and discussion on that [3] and your contributions would be most welcome. Alireza at BWH and Andreas at DKFZ have been taking the lead on this and we're aiming for an architecture that allows the flexibility to support various use cases as seen in Slicer and MITK. By the way, as a reminder to people with an interest in this topic, please sign up on the wiki page if you plan to attend the May CTK hackfest [4] either in person or electronically. Best, Steve [1] http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers [2] https://github.com/commontk/CTK/issues [3] http://www.na-mic.org/Wiki/index.php/2014_Project_Week:Slicer_DICOM_Module_Interface_Redesign [4] http://www.commontk.org/index.php/CTK-Hackfest-May-2014 On Thu, Feb 13, 2014 at 9:56 PM, Aaron Boxer wrote: > Thanks, Steve. I did manage to build CTK under VS 2010. > > It seems that the Cmake script caused DCMTK to build as static libaries, > but when I tried to run ctkDICOM2, it was looking > for ofstd.dll, for example. So, these dlls were not in the CTK build. Once > I put the Slicer DCMTK binary > folder on the path, ctkDICOM2 ran ok. But the CMake script may need to be > fixed. > > My ideas on changing the interface run along the lines of the ClearCanvas > workstation: > > See the first screenshot on the left here > > http://sourceforge.net/projects/clearcanvas/ > > for more details. > > Having all search controls and search results on one page makes the search > experience quite pleasant. > Also, since a PACS workflow is study based, you only need to have a single > table of studies, rather than > the three in the current implementation: patient, study, series. The user > can always search by patient id or name > if they want. > > Once I get familiar with the code, I will see if I can come up with a > prototype for this. > > Cheers, > Aaron > > > > > > > > > On Thu, Feb 13, 2014 at 7:44 PM, Steve Pieper wrote: > >> Hi Aaron - >> >> Thanks for your offer of help - much appreciated! >> >> In terms of development, you can build the CTK code stand-alone and use >> the ctkDICOM2 application as a stand alone to do query/retrieve and play >> with the database display. This is pretty quick since the testing app is >> small. >> >> On the slicer side, everything is just python code that uses the widgets >> from the ctk code. Since slicer takes a while to start up, I typically use >> a little helper code to rebuild a copy of the DICOM module for testing. >> Slicer allows you to have a .slicerrc.py in your home directory that loads >> a script with customizations. I have a .slicerrc.py file in github [1] >> that includes a reloader for the DICOM module [2]. So if you edit the >> python code and hit a keybinding [3] you get a new copy of the interface >> without exiting and re-starting slicer. This makes it pretty efficient to >> tweak & test the python code quickly. >> >> -Steve >> >> [1] https://github.com/pieper/SlicerRC >> >> [2] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L186-L212 >> >> [3] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L250 >> >> >> On Thu, Feb 13, 2014 at 10:57 AM, Aaron Boxer wrote: >> >>> Thanks, Steve. I'm happy to fix bugs. >>> >>> What is your dev environment like? Can you build the DICOM widget >>> standalone, or do you need to run it from the Slicer project? >>> >>> >>> >>> >>> On Thu, Feb 13, 2014 at 8:27 AM, Steve Pieper wrote: >>> >>>> Hi Aaron - >>>> >>>> The code is split between the core functionality in ctk [1] and the >>>> slicer module's use of that code [2]. You could review and contribute to >>>> the issues [3]. >>>> >>>> HTH, >>>> Steve >>>> >>>> >>>> [1] https://github.com/commontk/CTK/tree/master/Libs/DICOM >>>> >>>> [2] https://github.com/Slicer/Slicer/tree/master/Modules/Scripted/DICOM >>>> >>>> [3] >>>> http://na-mic.org/Bug/search.php?project_id=3&category=Module+DICOM&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 >>>> >>>> >>>> On Wed, Feb 12, 2014 at 9:44 PM, Aaron Boxer wrote: >>>> >>>>> I have some ideas about improving the user expericne for the DICOM >>>>> widget. What tools would I need to build and modify this ? >>>>> >>>>> Thanks very much, >>>>> Aaron >>>>> >>>>> _______________________________________________ >>>>> slicer-devel mailing list >>>>> slicer-devel at bwh.harvard.edu >>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>> To unsubscribe: send email to >>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the >>>>> subject >>>>> >>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>> >>>>> >>>>> The information in this e-mail is intended only for the person to whom >>>>> it is >>>>> addressed. If you believe this e-mail was sent to you in error and the >>>>> e-mail >>>>> contains patient information, please contact the Partners Compliance >>>>> HelpLine at >>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>> you in error >>>>> but does not contain patient information, please contact the sender >>>>> and properly >>>>> dispose of the e-mail. >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Mon Feb 17 13:40:08 2014 From: boxerab at gmail.com (Aaron Boxer) Date: Mon, 17 Feb 2014 08:40:08 -0500 Subject: [Ctk-developers] [slicer-devel] DICOM Module In-Reply-To: References: Message-ID: Thanks, Steve. I will pick up the discussion with the CTK folks. I really like the modularization/OSGI features of CTK, but I see a lot of room for improvement on the UX side. By day, I work on an in-house Clear Canvas based RIS/PACS system for a large hospital network, and I see all the time how little UI improvements make big differences for the users. Cheers, Aaron On Sun, Feb 16, 2014 at 10:51 AM, Steve Pieper wrote: > Hi Aaron - > > I suggest we move this discussion over to the ctk-developers mailing list > (you might want to sign up [1] if you haven't already) since as you saw > that level of the code is housed in CTK and there's active work going on > among that group. I've cc'd ctk-developers here to get the ball rolling. > > Regarding the shared/static libraries issue with DCMTK it would be great > to file that as an issue on the ctk issue tracker [2]. Probably the > configuration of the ctkDICOM2 executable isn't getting the right flags. > > As for the user interface options you are right - there's a lot that can > be done to simplify/streamline the interface. There's been quite some > research and discussion on that [3] and your contributions would be most > welcome. Alireza at BWH and Andreas at DKFZ have been taking the lead on > this and we're aiming for an architecture that allows the flexibility to > support various use cases as seen in Slicer and MITK. > > By the way, as a reminder to people with an interest in this topic, please > sign up on the wiki page if you plan to attend the May CTK hackfest [4] > either in person or electronically. > > Best, > Steve > > [1] http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > [2] https://github.com/commontk/CTK/issues > > [3] > http://www.na-mic.org/Wiki/index.php/2014_Project_Week:Slicer_DICOM_Module_Interface_Redesign > > [4] http://www.commontk.org/index.php/CTK-Hackfest-May-2014 > > > On Thu, Feb 13, 2014 at 9:56 PM, Aaron Boxer wrote: > >> Thanks, Steve. I did manage to build CTK under VS 2010. >> >> It seems that the Cmake script caused DCMTK to build as static libaries, >> but when I tried to run ctkDICOM2, it was looking >> for ofstd.dll, for example. So, these dlls were not in the CTK build. >> Once I put the Slicer DCMTK binary >> folder on the path, ctkDICOM2 ran ok. But the CMake script may need to be >> fixed. >> >> My ideas on changing the interface run along the lines of the ClearCanvas >> workstation: >> >> See the first screenshot on the left here >> >> http://sourceforge.net/projects/clearcanvas/ >> >> for more details. >> >> Having all search controls and search results on one page makes the >> search experience quite pleasant. >> Also, since a PACS workflow is study based, you only need to have a >> single table of studies, rather than >> the three in the current implementation: patient, study, series. The >> user can always search by patient id or name >> if they want. >> >> Once I get familiar with the code, I will see if I can come up with a >> prototype for this. >> >> Cheers, >> Aaron >> >> >> >> >> >> >> >> >> On Thu, Feb 13, 2014 at 7:44 PM, Steve Pieper wrote: >> >>> Hi Aaron - >>> >>> Thanks for your offer of help - much appreciated! >>> >>> In terms of development, you can build the CTK code stand-alone and use >>> the ctkDICOM2 application as a stand alone to do query/retrieve and play >>> with the database display. This is pretty quick since the testing app is >>> small. >>> >>> On the slicer side, everything is just python code that uses the widgets >>> from the ctk code. Since slicer takes a while to start up, I typically use >>> a little helper code to rebuild a copy of the DICOM module for testing. >>> Slicer allows you to have a .slicerrc.py in your home directory that loads >>> a script with customizations. I have a .slicerrc.py file in github [1] >>> that includes a reloader for the DICOM module [2]. So if you edit the >>> python code and hit a keybinding [3] you get a new copy of the interface >>> without exiting and re-starting slicer. This makes it pretty efficient to >>> tweak & test the python code quickly. >>> >>> -Steve >>> >>> [1] https://github.com/pieper/SlicerRC >>> >>> [2] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L186-L212 >>> >>> [3] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L250 >>> >>> >>> On Thu, Feb 13, 2014 at 10:57 AM, Aaron Boxer wrote: >>> >>>> Thanks, Steve. I'm happy to fix bugs. >>>> >>>> What is your dev environment like? Can you build the DICOM widget >>>> standalone, or do you need to run it from the Slicer project? >>>> >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 8:27 AM, Steve Pieper wrote: >>>> >>>>> Hi Aaron - >>>>> >>>>> The code is split between the core functionality in ctk [1] and the >>>>> slicer module's use of that code [2]. You could review and contribute to >>>>> the issues [3]. >>>>> >>>>> HTH, >>>>> Steve >>>>> >>>>> >>>>> [1] https://github.com/commontk/CTK/tree/master/Libs/DICOM >>>>> >>>>> [2] >>>>> https://github.com/Slicer/Slicer/tree/master/Modules/Scripted/DICOM >>>>> >>>>> [3] >>>>> http://na-mic.org/Bug/search.php?project_id=3&category=Module+DICOM&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 >>>>> >>>>> >>>>> On Wed, Feb 12, 2014 at 9:44 PM, Aaron Boxer wrote: >>>>> >>>>>> I have some ideas about improving the user expericne for the DICOM >>>>>> widget. What tools would I need to build and modify this ? >>>>>> >>>>>> Thanks very much, >>>>>> Aaron >>>>>> >>>>>> _______________________________________________ >>>>>> slicer-devel mailing list >>>>>> slicer-devel at bwh.harvard.edu >>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>> To unsubscribe: send email to >>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>> the subject >>>>>> >>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>> >>>>>> >>>>>> The information in this e-mail is intended only for the person to >>>>>> whom it is >>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>> the e-mail >>>>>> contains patient information, please contact the Partners Compliance >>>>>> HelpLine at >>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>> you in error >>>>>> but does not contain patient information, please contact the sender >>>>>> and properly >>>>>> dispose of the e-mail. >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Fri Feb 21 15:16:46 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 21 Feb 2014 10:16:46 -0500 Subject: [Ctk-developers] [slicer-devel] DICOM Module In-Reply-To: References: Message-ID: Hi Aaron, Your contribution are very welcome. Let's also note that version of DCMTK used in CTK is 2yrs old ( See [1][2] ) We could consider upgrading but we should also note that the version in debian stable is still 3.6.0 [3] @Marco: What do you think ? Jc [1] https://github.com/commontk/CTK/blob/4cfeaaf79e54dba8ed73fab1d15fad36bffd209d/CMakeExternals/DCMTK.cmake#L27 [2] https://github.com/commontk/DCMTK/commit/ae3b946f6e6231 [3] https://packages.debian.org/search?keywords=dcmtk On Mon, Feb 17, 2014 at 8:40 AM, Aaron Boxer wrote: > Thanks, Steve. I will pick up the discussion with the CTK folks. > I really like the modularization/OSGI features of CTK, but I see a lot of > room for improvement on the UX side. > By day, I work on an in-house Clear Canvas based RIS/PACS system for a > large hospital network, and I see all the > time how little UI improvements make big differences for the users. > > Cheers, > Aaron > > > On Sun, Feb 16, 2014 at 10:51 AM, Steve Pieper wrote: > >> Hi Aaron - >> >> I suggest we move this discussion over to the ctk-developers mailing list >> (you might want to sign up [1] if you haven't already) since as you saw >> that level of the code is housed in CTK and there's active work going on >> among that group. I've cc'd ctk-developers here to get the ball rolling. >> >> Regarding the shared/static libraries issue with DCMTK it would be great >> to file that as an issue on the ctk issue tracker [2]. Probably the >> configuration of the ctkDICOM2 executable isn't getting the right flags. >> >> As for the user interface options you are right - there's a lot that can >> be done to simplify/streamline the interface. There's been quite some >> research and discussion on that [3] and your contributions would be most >> welcome. Alireza at BWH and Andreas at DKFZ have been taking the lead on >> this and we're aiming for an architecture that allows the flexibility to >> support various use cases as seen in Slicer and MITK. >> >> By the way, as a reminder to people with an interest in this topic, >> please sign up on the wiki page if you plan to attend the May CTK hackfest >> [4] either in person or electronically. >> >> Best, >> Steve >> >> [1] http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> [2] https://github.com/commontk/CTK/issues >> >> [3] >> http://www.na-mic.org/Wiki/index.php/2014_Project_Week:Slicer_DICOM_Module_Interface_Redesign >> >> [4] http://www.commontk.org/index.php/CTK-Hackfest-May-2014 >> >> >> On Thu, Feb 13, 2014 at 9:56 PM, Aaron Boxer wrote: >> >>> Thanks, Steve. I did manage to build CTK under VS 2010. >>> >>> It seems that the Cmake script caused DCMTK to build as static libaries, >>> but when I tried to run ctkDICOM2, it was looking >>> for ofstd.dll, for example. So, these dlls were not in the CTK build. >>> Once I put the Slicer DCMTK binary >>> folder on the path, ctkDICOM2 ran ok. But the CMake script may need to >>> be fixed. >>> >>> My ideas on changing the interface run along the lines of the >>> ClearCanvas workstation: >>> >>> See the first screenshot on the left here >>> >>> http://sourceforge.net/projects/clearcanvas/ >>> >>> for more details. >>> >>> Having all search controls and search results on one page makes the >>> search experience quite pleasant. >>> Also, since a PACS workflow is study based, you only need to have a >>> single table of studies, rather than >>> the three in the current implementation: patient, study, series. The >>> user can always search by patient id or name >>> if they want. >>> >>> Once I get familiar with the code, I will see if I can come up with a >>> prototype for this. >>> >>> Cheers, >>> Aaron >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Feb 13, 2014 at 7:44 PM, Steve Pieper wrote: >>> >>>> Hi Aaron - >>>> >>>> Thanks for your offer of help - much appreciated! >>>> >>>> In terms of development, you can build the CTK code stand-alone and use >>>> the ctkDICOM2 application as a stand alone to do query/retrieve and play >>>> with the database display. This is pretty quick since the testing app is >>>> small. >>>> >>>> On the slicer side, everything is just python code that uses the >>>> widgets from the ctk code. Since slicer takes a while to start up, I >>>> typically use a little helper code to rebuild a copy of the DICOM module >>>> for testing. Slicer allows you to have a .slicerrc.py in your home >>>> directory that loads a script with customizations. I have a .slicerrc.py >>>> file in github [1] that includes a reloader for the DICOM module [2]. So >>>> if you edit the python code and hit a keybinding [3] you get a new copy of >>>> the interface without exiting and re-starting slicer. This makes it pretty >>>> efficient to tweak & test the python code quickly. >>>> >>>> -Steve >>>> >>>> [1] https://github.com/pieper/SlicerRC >>>> >>>> [2] >>>> https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L186-L212 >>>> >>>> [3] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L250 >>>> >>>> >>>> On Thu, Feb 13, 2014 at 10:57 AM, Aaron Boxer wrote: >>>> >>>>> Thanks, Steve. I'm happy to fix bugs. >>>>> >>>>> What is your dev environment like? Can you build the DICOM widget >>>>> standalone, or do you need to run it from the Slicer project? >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 8:27 AM, Steve Pieper wrote: >>>>> >>>>>> Hi Aaron - >>>>>> >>>>>> The code is split between the core functionality in ctk [1] and the >>>>>> slicer module's use of that code [2]. You could review and contribute to >>>>>> the issues [3]. >>>>>> >>>>>> HTH, >>>>>> Steve >>>>>> >>>>>> >>>>>> [1] https://github.com/commontk/CTK/tree/master/Libs/DICOM >>>>>> >>>>>> [2] >>>>>> https://github.com/Slicer/Slicer/tree/master/Modules/Scripted/DICOM >>>>>> >>>>>> [3] >>>>>> http://na-mic.org/Bug/search.php?project_id=3&category=Module+DICOM&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 >>>>>> >>>>>> >>>>>> On Wed, Feb 12, 2014 at 9:44 PM, Aaron Boxer wrote: >>>>>> >>>>>>> I have some ideas about improving the user expericne for the DICOM >>>>>>> widget. What tools would I need to build and modify this ? >>>>>>> >>>>>>> Thanks very much, >>>>>>> Aaron >>>>>>> >>>>>>> _______________________________________________ >>>>>>> slicer-devel mailing list >>>>>>> slicer-devel at bwh.harvard.edu >>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>>> To unsubscribe: send email to >>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>>> the subject >>>>>>> >>>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>>> >>>>>>> >>>>>>> The information in this e-mail is intended only for the person to >>>>>>> whom it is >>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>> the e-mail >>>>>>> contains patient information, please contact the Partners Compliance >>>>>>> HelpLine at >>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>>> you in error >>>>>>> but does not contain patient information, please contact the sender >>>>>>> and properly >>>>>>> dispose of the e-mail. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.nolden at dkfz-heidelberg.de Mon Feb 24 16:16:02 2014 From: m.nolden at dkfz-heidelberg.de (Marco Nolden) Date: Mon, 24 Feb 2014 17:16:02 +0100 Subject: [Ctk-developers] [slicer-devel] DICOM Module In-Reply-To: References: Message-ID: <530B7042.8030803@dkfz.de> On 02/21/2014 04:16 PM, Jean-Christophe Fillion-Robin wrote: > Hi Aaron, > > Your contribution are very welcome. > > Let's also note that version of DCMTK used in CTK is 2yrs old ( See [1][2] ) > > We could consider upgrading but we should also note that the version in > debian stable is still 3.6.0 [3] > > @Marco: What do you think ? The version that is linked in the superbuild is already newer than 3,6.0 so we could of course update this to a newer snapshot. IIRC we just agreed that it should be possible to build CTK using an official DCMTK release, possibly with some missing functionality in that case. However, there is currently no dartclient checking this configuration so I'm not sure if it still works ... Best, Marco > > Jc > > > [1] > https://github.com/commontk/CTK/blob/4cfeaaf79e54dba8ed73fab1d15fad36bffd209d/CMakeExternals/DCMTK.cmake#L27 > > [2] https://github.com/commontk/DCMTK/commit/ae3b946f6e6231 > > [3] https://packages.debian.org/search?keywords=dcmtk > > > On Mon, Feb 17, 2014 at 8:40 AM, Aaron Boxer > wrote: > > Thanks, Steve. I will pick up the discussion with the CTK folks. > I really like the modularization/OSGI features of CTK, but I see a > lot of room for improvement on the UX side. > By day, I work on an in-house Clear Canvas based RIS/PACS system for > a large hospital network, and I see all the > time how little UI improvements make big differences for the users. > > Cheers, > Aaron > > > On Sun, Feb 16, 2014 at 10:51 AM, Steve Pieper > wrote: > > Hi Aaron - > > I suggest we move this discussion over to the ctk-developers > mailing list (you might want to sign up [1] if you haven't > already) since as you saw that level of the code is housed in > CTK and there's active work going on among that group. I've > cc'd ctk-developers here to get the ball rolling. > > Regarding the shared/static libraries issue with DCMTK it would > be great to file that as an issue on the ctk issue tracker [2]. > Probably the configuration of the ctkDICOM2 executable isn't > getting the right flags. > > As for the user interface options you are right - there's a lot > that can be done to simplify/streamline the interface. There's > been quite some research and discussion on that [3] and your > contributions would be most welcome. Alireza at BWH and Andreas > at DKFZ have been taking the lead on this and we're aiming for > an architecture that allows the flexibility to support various > use cases as seen in Slicer and MITK. > > By the way, as a reminder to people with an interest in this > topic, please sign up on the wiki page if you plan to attend the > May CTK hackfest [4] either in person or electronically. > > Best, > Steve > > [1] > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > [2] https://github.com/commontk/CTK/issues > > [3] > http://www.na-mic.org/Wiki/index.php/2014_Project_Week:Slicer_DICOM_Module_Interface_Redesign > > [4] http://www.commontk.org/index.php/CTK-Hackfest-May-2014 > > > On Thu, Feb 13, 2014 at 9:56 PM, Aaron Boxer > wrote: > > Thanks, Steve. I did manage to build CTK under VS 2010. > > It seems that the Cmake script caused DCMTK to build as > static libaries, but when I tried to run ctkDICOM2, it was > looking > for ofstd.dll, for example. So, these dlls were not in the > CTK build. Once I put the Slicer DCMTK binary > folder on the path, ctkDICOM2 ran ok. But the CMake script > may need to be fixed. > > My ideas on changing the interface run along the lines of > the ClearCanvas workstation: > > See the first screenshot on the left here > > http://sourceforge.net/projects/clearcanvas/ > > for more details. > > Having all search controls and search results on one page > makes the search experience quite pleasant. > Also, since a PACS workflow is study based, you only need to > have a single table of studies, rather than > the three in the current implementation: patient, study, > series. The user can always search by patient id or name > if they want. > > Once I get familiar with the code, I will see if I can come > up with a prototype for this. > > Cheers, > Aaron > > > > > > > > > On Thu, Feb 13, 2014 at 7:44 PM, Steve Pieper > > wrote: > > Hi Aaron - > > Thanks for your offer of help - much appreciated! > > In terms of development, you can build the CTK code > stand-alone and use the ctkDICOM2 application as a stand > alone to do query/retrieve and play with the database > display. This is pretty quick since the testing app is > small. > > On the slicer side, everything is just python code that > uses the widgets from the ctk code. Since slicer takes > a while to start up, I typically use a little helper > code to rebuild a copy of the DICOM module for testing. > Slicer allows you to have a .slicerrc.py in your home > directory that loads a script with customizations. I > have a .slicerrc.py file in github [1] that includes a > reloader for the DICOM module [2]. So if you edit the > python code and hit a keybinding [3] you get a new copy > of the interface without exiting and re-starting slicer. > This makes it pretty efficient to tweak & test the > python code quickly. > > -Steve > > [1] https://github.com/pieper/SlicerRC > > [2] > https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L186-L212 > > [3] > https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L250 > > > On Thu, Feb 13, 2014 at 10:57 AM, Aaron Boxer > > wrote: > > Thanks, Steve. I'm happy to fix bugs. > > What is your dev environment like? Can you build > the DICOM widget standalone, or do you need to run > it from the Slicer project? > > > > > On Thu, Feb 13, 2014 at 8:27 AM, Steve Pieper > > wrote: > > Hi Aaron - > > The code is split between the core functionality > in ctk [1] and the slicer module's use of that > code [2]. You could review and contribute to > the issues [3]. > > HTH, > Steve > > > [1] > https://github.com/commontk/CTK/tree/master/Libs/DICOM > > > [2] > https://github.com/Slicer/Slicer/tree/master/Modules/Scripted/DICOM > > [3] > http://na-mic.org/Bug/search.php?project_id=3&category=Module+DICOM&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 > > > On Wed, Feb 12, 2014 at 9:44 PM, Aaron Boxer > > > wrote: > > I have some ideas about improving the user > expericne for the DICOM widget. What tools > would I need to build and modify this ? > > Thanks very much, > Aaron > > _______________________________________________ > slicer-devel mailing list > slicer-devel at bwh.harvard.edu > > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > To unsubscribe: send email to > slicer-devel-request at massmail.spl.harvard.edu > with unsubscribe as the subject > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ > > > The information in this e-mail is intended > only for the person to whom it is > addressed. If you believe this e-mail was > sent to you in error and the e-mail > contains patient information, please contact > the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If > the e-mail was sent to you in error > but does not contain patient information, > please contact the sender and properly > dispose of the e-mail. > > > > > > > > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > > > > -- > +1 919 869 8849 -- ---------------------------------------------------------------------- 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 sergio.vera at alma3d.com Tue Feb 25 08:59:41 2014 From: sergio.vera at alma3d.com (Sergio Vera) Date: Tue, 25 Feb 2014 09:59:41 +0100 Subject: [Ctk-developers] CTK compilation under Xcode 5.02 (clang5.0) Message-ID: Hello anyone has been able to compile CTK under Mac OS X Maverick / Xcode 5.02 (clang5.0)? VTK fails to compile. As far as I have read, VTK 5.10 refuses to compile against Maverick (10.9) SDK but compiles fine in mountain lion (10.8) OS X SDK. However, even after changing the target SDK inside Xcode, the VTK cloned by CTK does not compile. Best regards -- Sergio Vera Alma IT Systems C/ Vilana, 4B, 4? 1? 08022 Barcelona T. (+34) 932 380 592 www.alma3d.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Tue Feb 25 14:13:02 2014 From: pieper at isomics.com (Steve Pieper) Date: Tue, 25 Feb 2014 09:13:02 -0500 Subject: [Ctk-developers] CTK compilation under Xcode 5.02 (clang5.0) In-Reply-To: References: Message-ID: Hi Sergio - Slicer compiles against the latest clang/Xcode/Mavericks setup. It builds VTK and CTK so you could investigate what's different in your builds. -Steve On Tue, Feb 25, 2014 at 3:59 AM, Sergio Vera wrote: > Hello anyone has been able to compile CTK under Mac OS X Maverick / Xcode > 5.02 (clang5.0)? > > VTK fails to compile. As far as I have read, VTK 5.10 refuses to compile > against Maverick (10.9) SDK but compiles fine in mountain lion (10.8) OS X > SDK. However, even after changing the target SDK inside Xcode, the VTK > cloned by CTK does not compile. > > Best regards > > -- > Sergio Vera > > Alma IT Systems > C/ Vilana, 4B, 4? 1? > 08022 Barcelona > T. (+34) 932 380 592 > www.alma3d.com > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boxerab at gmail.com Tue Feb 25 14:19:30 2014 From: boxerab at gmail.com (Aaron Boxer) Date: Tue, 25 Feb 2014 09:19:30 -0500 Subject: [Ctk-developers] [slicer-devel] DICOM Module In-Reply-To: References: Message-ID: On Fri, Feb 21, 2014 at 10:16 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Aaron, > > Your contribution are very welcome. > Thanks. My patch will probably not be accepted by Offis, since they have their own commercial jpeg 2000 product. So, using this means that we will have to use an unofficial DCMTK build. My patch changes very little in the library, so it is quite safe. Aaron > > Let's also note that version of DCMTK used in CTK is 2yrs old ( See [1][2] > ) > > We could consider upgrading but we should also note that the version in > debian stable is still 3.6.0 [3] > > @Marco: What do you think ? > > Jc > > > [1] > https://github.com/commontk/CTK/blob/4cfeaaf79e54dba8ed73fab1d15fad36bffd209d/CMakeExternals/DCMTK.cmake#L27 > > [2] https://github.com/commontk/DCMTK/commit/ae3b946f6e6231 > > [3] https://packages.debian.org/search?keywords=dcmtk > > > On Mon, Feb 17, 2014 at 8:40 AM, Aaron Boxer wrote: > >> Thanks, Steve. I will pick up the discussion with the CTK folks. >> I really like the modularization/OSGI features of CTK, but I see a lot of >> room for improvement on the UX side. >> By day, I work on an in-house Clear Canvas based RIS/PACS system for a >> large hospital network, and I see all the >> time how little UI improvements make big differences for the users. >> >> Cheers, >> Aaron >> >> >> On Sun, Feb 16, 2014 at 10:51 AM, Steve Pieper wrote: >> >>> Hi Aaron - >>> >>> I suggest we move this discussion over to the ctk-developers mailing >>> list (you might want to sign up [1] if you haven't already) since as you >>> saw that level of the code is housed in CTK and there's active work going >>> on among that group. I've cc'd ctk-developers here to get the ball rolling. >>> >>> Regarding the shared/static libraries issue with DCMTK it would be great >>> to file that as an issue on the ctk issue tracker [2]. Probably the >>> configuration of the ctkDICOM2 executable isn't getting the right flags. >>> >>> As for the user interface options you are right - there's a lot that can >>> be done to simplify/streamline the interface. There's been quite some >>> research and discussion on that [3] and your contributions would be most >>> welcome. Alireza at BWH and Andreas at DKFZ have been taking the lead on >>> this and we're aiming for an architecture that allows the flexibility to >>> support various use cases as seen in Slicer and MITK. >>> >>> By the way, as a reminder to people with an interest in this topic, >>> please sign up on the wiki page if you plan to attend the May CTK hackfest >>> [4] either in person or electronically. >>> >>> Best, >>> Steve >>> >>> [1] http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> [2] https://github.com/commontk/CTK/issues >>> >>> [3] >>> http://www.na-mic.org/Wiki/index.php/2014_Project_Week:Slicer_DICOM_Module_Interface_Redesign >>> >>> [4] http://www.commontk.org/index.php/CTK-Hackfest-May-2014 >>> >>> >>> On Thu, Feb 13, 2014 at 9:56 PM, Aaron Boxer wrote: >>> >>>> Thanks, Steve. I did manage to build CTK under VS 2010. >>>> >>>> It seems that the Cmake script caused DCMTK to build as static >>>> libaries, but when I tried to run ctkDICOM2, it was looking >>>> for ofstd.dll, for example. So, these dlls were not in the CTK build. >>>> Once I put the Slicer DCMTK binary >>>> folder on the path, ctkDICOM2 ran ok. But the CMake script may need to >>>> be fixed. >>>> >>>> My ideas on changing the interface run along the lines of the >>>> ClearCanvas workstation: >>>> >>>> See the first screenshot on the left here >>>> >>>> http://sourceforge.net/projects/clearcanvas/ >>>> >>>> for more details. >>>> >>>> Having all search controls and search results on one page makes the >>>> search experience quite pleasant. >>>> Also, since a PACS workflow is study based, you only need to have a >>>> single table of studies, rather than >>>> the three in the current implementation: patient, study, series. The >>>> user can always search by patient id or name >>>> if they want. >>>> >>>> Once I get familiar with the code, I will see if I can come up with a >>>> prototype for this. >>>> >>>> Cheers, >>>> Aaron >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Feb 13, 2014 at 7:44 PM, Steve Pieper wrote: >>>> >>>>> Hi Aaron - >>>>> >>>>> Thanks for your offer of help - much appreciated! >>>>> >>>>> In terms of development, you can build the CTK code stand-alone and >>>>> use the ctkDICOM2 application as a stand alone to do query/retrieve and >>>>> play with the database display. This is pretty quick since the testing app >>>>> is small. >>>>> >>>>> On the slicer side, everything is just python code that uses the >>>>> widgets from the ctk code. Since slicer takes a while to start up, I >>>>> typically use a little helper code to rebuild a copy of the DICOM module >>>>> for testing. Slicer allows you to have a .slicerrc.py in your home >>>>> directory that loads a script with customizations. I have a .slicerrc.py >>>>> file in github [1] that includes a reloader for the DICOM module [2]. So >>>>> if you edit the python code and hit a keybinding [3] you get a new copy of >>>>> the interface without exiting and re-starting slicer. This makes it pretty >>>>> efficient to tweak & test the python code quickly. >>>>> >>>>> -Steve >>>>> >>>>> [1] https://github.com/pieper/SlicerRC >>>>> >>>>> [2] >>>>> https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L186-L212 >>>>> >>>>> [3] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L250 >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 10:57 AM, Aaron Boxer wrote: >>>>> >>>>>> Thanks, Steve. I'm happy to fix bugs. >>>>>> >>>>>> What is your dev environment like? Can you build the DICOM widget >>>>>> standalone, or do you need to run it from the Slicer project? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 8:27 AM, Steve Pieper wrote: >>>>>> >>>>>>> Hi Aaron - >>>>>>> >>>>>>> The code is split between the core functionality in ctk [1] and the >>>>>>> slicer module's use of that code [2]. You could review and contribute to >>>>>>> the issues [3]. >>>>>>> >>>>>>> HTH, >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/commontk/CTK/tree/master/Libs/DICOM >>>>>>> >>>>>>> [2] >>>>>>> https://github.com/Slicer/Slicer/tree/master/Modules/Scripted/DICOM >>>>>>> >>>>>>> [3] >>>>>>> http://na-mic.org/Bug/search.php?project_id=3&category=Module+DICOM&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 12, 2014 at 9:44 PM, Aaron Boxer wrote: >>>>>>> >>>>>>>> I have some ideas about improving the user expericne for the DICOM >>>>>>>> widget. What tools would I need to build and modify this ? >>>>>>>> >>>>>>>> Thanks very much, >>>>>>>> Aaron >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> slicer-devel mailing list >>>>>>>> slicer-devel at bwh.harvard.edu >>>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>>>> To unsubscribe: send email to >>>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>>>> the subject >>>>>>>> >>>>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>>>> >>>>>>>> >>>>>>>> The information in this e-mail is intended only for the person to >>>>>>>> whom it is >>>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>>> the e-mail >>>>>>>> contains patient information, please contact the Partners >>>>>>>> Compliance HelpLine at >>>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>>>> you in error >>>>>>>> but does not contain patient information, please contact the sender >>>>>>>> and properly >>>>>>>> dispose of the e-mail. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Feb 25 14:23:56 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 25 Feb 2014 09:23:56 -0500 Subject: [Ctk-developers] CTK compilation under Xcode 5.02 (clang5.0) In-Reply-To: References: Message-ID: Hi Sergio, I just pushed a topic updating the version of VTK used in CTK to the head of the 5.10 release branch. See https://github.com/jcfr/CTK/tree/ctk-clang-compilation Let us know if this fixes the issue, then we will integrate the patch. Hth Jc On Tue, Feb 25, 2014 at 9:13 AM, Steve Pieper wrote: > Hi Sergio - > > Slicer compiles against the latest clang/Xcode/Mavericks setup. It builds > VTK and CTK so you could investigate what's different in your builds. > > -Steve > > > On Tue, Feb 25, 2014 at 3:59 AM, Sergio Vera wrote: > >> Hello anyone has been able to compile CTK under Mac OS X Maverick / Xcode >> 5.02 (clang5.0)? >> >> VTK fails to compile. As far as I have read, VTK 5.10 refuses to compile >> against Maverick (10.9) SDK but compiles fine in mountain lion (10.8) OS X >> SDK. However, even after changing the target SDK inside Xcode, the VTK >> cloned by CTK does not compile. >> >> Best regards >> >> -- >> Sergio Vera >> >> Alma IT Systems >> C/ Vilana, 4B, 4? 1? >> 08022 Barcelona >> T. (+34) 932 380 592 >> www.alma3d.com >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > _______________________________________________ > Ctk-developers mailing list > Ctk-developers at commontk.org > http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Feb 25 23:01:44 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 25 Feb 2014 18:01:44 -0500 Subject: [Ctk-developers] DCMTK JPEG 2000 support (was: [slicer-devel] JPEG 2000) Message-ID: ---------- Forwarded message ---------- From: Aaron Boxer Date: Fri, Feb 21, 2014 at 3:28 PM Subject: Re: [slicer-devel] JPEG 2000 To: "slicer-devel at bwh.harvard.edu" Well Folks, I've been able to successfully decode jpeg 2000 images on my dcmtk branch. You can find the branch here: https://github.com/OpenRadStack/dcmtk/tree/j2k I am still using git submodules and manual build to build openjpeg; haven't had a chance yet to follow Jcr's build advice. If you would like to try it out, you can follow these steps: 1) clone the project 2) run $ git submodule init & git submodule update 3) use cmake to build openjpeg (third-party/openjpeg) into third-party/openjpeg-build folder (enable shared library) 4) make sure that openjp2 shared library is in your path For testing, I am running the dcmtk dcmj2pnm command line tool to convert dicom images to bmp. Command line I am using: +ob +Wm dicomFile destinationFile.bmp Cheers, Aaron On Thu, Feb 20, 2014 at 2:26 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Aaron, > > This is great news. > > I don't think DCMTK should use either git submodule or External project, > instead you should assume the library is either installed on the system or > related path passed at configure time. You could then just call: > > find_package(OpenJPEG NO_MODULE) See [1] > > in the 3rdparty.cmake. See [2] > > When configuring DCMTK, it means you would simply pass the path the > OpenJPEG build tree passing -DOpenJPEG_DIR:PATH=/path/to/openJPEG-build > > > [1] This is possible because a OpenJPEGConfig.cmake is configured. see > http://code.google.com/p/openjpeg/source/browse/trunk/cmake/OpenJPEGConfig.cmake.inand > http://code.google.com/p/openjpeg/source/browse/trunk/CMakeLists.txt#298 > > [2] https://github.com/commontk/DCMTK/blob/patched-3/CMake/3rdparty.cmake > > > On Thu, Feb 20, 2014 at 2:08 PM, Aaron Boxer wrote: > >> Update: I am closing in on a jpeg2000-enabled branch from DCMTK master. >> Should be ready next week. >> One issue I am having: I have added the openjpeg project (which is a >> cmake proj) to dcmtk as a git submodule. >> Now I need to figure out how the cmake externalproject command works. >> >> ( >> http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject >> ) >> >> If anyone here is familiar with this, and would like to help, please let >> me know. >> >> Thanks, >> Aaron >> >> >> >> On Mon, Feb 17, 2014 at 9:45 AM, Steve Pieper wrote: >> >>> Hi Aaron - >>> >>> I like your plan of reviewing the osirix implementation and taking >>> advantage of the latest developments in OpenJPEG - very exciting to see >>> this moving ahead! >>> >>> Regarding your questions about thumbnails in ctkDICOM2: CTK only uses >>> DCMTK, not GDCM, so it currently fails to create thumbnails for images not >>> directly supported by DCMTK. CTK doesn't have a mechanism to use ITK or >>> GDCM, although I suppose this could be added. In ctk we really wanted to >>> have robust networking support in CTK and as you noted DCMTK has a well >>> established track record in this. >>> >>> Best, >>> Steve >>> >>> >>> On Mon, Feb 17, 2014 at 8:53 AM, Aaron Boxer wrote: >>> >>>> Hi Steve, >>>> >>>> >>>>> That would be an awesome contribution - useful for slicer but also for >>>>> CTK and other DCMTK users. The situation right now is that slicer builds >>>>> dcmtk (without jpeg2000 as you noted) so none of the dcmtk-based code can >>>>> access that kind of image. So for example in the ctkDICOM app the >>>>> thumbnails aren't displayed for data of that type. The osirix sample data >>>>> is a good source of images that are compressed in a way dcmtk doesn't like. >>>>> >>>>> That said, when slicer actually goes to read the data it is delegated >>>>> to ITK's readers, which include GDCM and that supports jpeg2000 so the >>>>> files load. >>>>> >>>> >>>> Interesting. Can the ctkDICOM app use GDCM for the thumbnails? >>>> >>>> >>>>> >>>>> This is an oddly messy situation. Personally I wish ITK had used >>>>> DCMTK from the start, since that includes all the networking and other >>>>> support. But instead it started with GDCM, on the idea that it's lighter >>>>> weight and has support for things like jpeg2000 and then later added DCMTK >>>>> support too. Since slicer delegates to ITK, there are some situations >>>>> where DCMTK is used and others where GDCM is used. >>>>> >>>> >>>> Yes. GDCM and DCMTK seem to excell in orthogonal areas: GDCM on DICOM >>>> image reading and DCMTK on DICOM networking. So, I can see why ITK chose >>>> GDCM initially, because it is an image-focused toolkit. >>>> >>>> I would like to see more networking in GDCM, and more transfer syntaxes >>>> supported in the open DCMTK version :) >>>> >>>> Anywho, I would be happy to add both JPEG2000 and JPEG-LS to DCMTK. >>>> >>>> Cheers, >>>> Aaron >>>> >>>> >>>> >>>> >>>>> >>>>> On Sat, Feb 15, 2014 at 10:05 AM, Aaron Boxer wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I was wondering about types of compression supported by the slicer >>>>>> DICOM module. >>>>>> As you probably know, many DICOM images are compressed with JPEG 2000 >>>>>> compression. And I believe that DCMTK sells support for JPEG 2000, which >>>>>> leads me to believe that the slicer version of DCMTK does not support JPEG >>>>>> 2000. >>>>>> >>>>>> Is this the case? Because I have done some work on the OpenJPEG >>>>>> project, and I think I could integrate OpenJPEG support into the slicer >>>>>> DCMTK. >>>>>> >>>>>> Kind Regards, >>>>>> Aaron >>>>>> >>>>>> _______________________________________________ >>>>>> slicer-devel mailing list >>>>>> slicer-devel at bwh.harvard.edu >>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>> To unsubscribe: send email to >>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>> the subject >>>>>> >>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>> >>>>>> >>>>>> The information in this e-mail is intended only for the person to >>>>>> whom it is >>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>> the e-mail >>>>>> contains patient information, please contact the Partners Compliance >>>>>> HelpLine at >>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>> you in error >>>>>> but does not contain patient information, please contact the sender >>>>>> and properly >>>>>> dispose of the e-mail. >>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> slicer-devel mailing list >> slicer-devel at bwh.harvard.edu >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >> To unsubscribe: send email to >> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the >> subject >> >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you >> in error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> >> > > > -- > +1 919 869 8849 > _______________________________________________ slicer-devel mailing list slicer-devel at bwh.harvard.edu http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel To unsubscribe: send email to slicer-devel-request at massmail.spl.harvard.eduwith unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Feb 25 23:16:37 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 25 Feb 2014 18:16:37 -0500 Subject: [Ctk-developers] [slicer-devel] DICOM Module In-Reply-To: References: Message-ID: See this thread [1] for the discussion related to Jpeg 2000 [1] http://public.kitware.com/pipermail/ctk-developers/2014-February/001312.html On Tue, Feb 25, 2014 at 9:19 AM, Aaron Boxer wrote: > > > > On Fri, Feb 21, 2014 at 10:16 AM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> Hi Aaron, >> >> Your contribution are very welcome. >> > > > Thanks. My patch will probably not be accepted by Offis, since they have > their own commercial jpeg 2000 product. > So, using this means that we will have to use an unofficial DCMTK build. > > My patch changes very little in the library, so it is quite safe. > Aaron > > >> >> Let's also note that version of DCMTK used in CTK is 2yrs old ( See >> [1][2] ) >> >> We could consider upgrading but we should also note that the version in >> debian stable is still 3.6.0 [3] >> >> @Marco: What do you think ? >> >> Jc >> >> >> [1] >> https://github.com/commontk/CTK/blob/4cfeaaf79e54dba8ed73fab1d15fad36bffd209d/CMakeExternals/DCMTK.cmake#L27 >> >> [2] https://github.com/commontk/DCMTK/commit/ae3b946f6e6231 >> >> [3] https://packages.debian.org/search?keywords=dcmtk >> >> >> On Mon, Feb 17, 2014 at 8:40 AM, Aaron Boxer wrote: >> >>> Thanks, Steve. I will pick up the discussion with the CTK folks. >>> I really like the modularization/OSGI features of CTK, but I see a lot >>> of room for improvement on the UX side. >>> By day, I work on an in-house Clear Canvas based RIS/PACS system for a >>> large hospital network, and I see all the >>> time how little UI improvements make big differences for the users. >>> >>> Cheers, >>> Aaron >>> >>> >>> On Sun, Feb 16, 2014 at 10:51 AM, Steve Pieper wrote: >>> >>>> Hi Aaron - >>>> >>>> I suggest we move this discussion over to the ctk-developers mailing >>>> list (you might want to sign up [1] if you haven't already) since as you >>>> saw that level of the code is housed in CTK and there's active work going >>>> on among that group. I've cc'd ctk-developers here to get the ball rolling. >>>> >>>> Regarding the shared/static libraries issue with DCMTK it would be >>>> great to file that as an issue on the ctk issue tracker [2]. Probably the >>>> configuration of the ctkDICOM2 executable isn't getting the right flags. >>>> >>>> As for the user interface options you are right - there's a lot that >>>> can be done to simplify/streamline the interface. There's been quite some >>>> research and discussion on that [3] and your contributions would be most >>>> welcome. Alireza at BWH and Andreas at DKFZ have been taking the lead on >>>> this and we're aiming for an architecture that allows the flexibility to >>>> support various use cases as seen in Slicer and MITK. >>>> >>>> By the way, as a reminder to people with an interest in this topic, >>>> please sign up on the wiki page if you plan to attend the May CTK hackfest >>>> [4] either in person or electronically. >>>> >>>> Best, >>>> Steve >>>> >>>> [1] http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> [2] https://github.com/commontk/CTK/issues >>>> >>>> [3] >>>> http://www.na-mic.org/Wiki/index.php/2014_Project_Week:Slicer_DICOM_Module_Interface_Redesign >>>> >>>> [4] http://www.commontk.org/index.php/CTK-Hackfest-May-2014 >>>> >>>> >>>> On Thu, Feb 13, 2014 at 9:56 PM, Aaron Boxer wrote: >>>> >>>>> Thanks, Steve. I did manage to build CTK under VS 2010. >>>>> >>>>> It seems that the Cmake script caused DCMTK to build as static >>>>> libaries, but when I tried to run ctkDICOM2, it was looking >>>>> for ofstd.dll, for example. So, these dlls were not in the CTK build. >>>>> Once I put the Slicer DCMTK binary >>>>> folder on the path, ctkDICOM2 ran ok. But the CMake script may need to >>>>> be fixed. >>>>> >>>>> My ideas on changing the interface run along the lines of the >>>>> ClearCanvas workstation: >>>>> >>>>> See the first screenshot on the left here >>>>> >>>>> http://sourceforge.net/projects/clearcanvas/ >>>>> >>>>> for more details. >>>>> >>>>> Having all search controls and search results on one page makes the >>>>> search experience quite pleasant. >>>>> Also, since a PACS workflow is study based, you only need to have a >>>>> single table of studies, rather than >>>>> the three in the current implementation: patient, study, series. The >>>>> user can always search by patient id or name >>>>> if they want. >>>>> >>>>> Once I get familiar with the code, I will see if I can come up with a >>>>> prototype for this. >>>>> >>>>> Cheers, >>>>> Aaron >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 7:44 PM, Steve Pieper wrote: >>>>> >>>>>> Hi Aaron - >>>>>> >>>>>> Thanks for your offer of help - much appreciated! >>>>>> >>>>>> In terms of development, you can build the CTK code stand-alone and >>>>>> use the ctkDICOM2 application as a stand alone to do query/retrieve and >>>>>> play with the database display. This is pretty quick since the testing app >>>>>> is small. >>>>>> >>>>>> On the slicer side, everything is just python code that uses the >>>>>> widgets from the ctk code. Since slicer takes a while to start up, I >>>>>> typically use a little helper code to rebuild a copy of the DICOM module >>>>>> for testing. Slicer allows you to have a .slicerrc.py in your home >>>>>> directory that loads a script with customizations. I have a .slicerrc.py >>>>>> file in github [1] that includes a reloader for the DICOM module [2]. So >>>>>> if you edit the python code and hit a keybinding [3] you get a new copy of >>>>>> the interface without exiting and re-starting slicer. This makes it pretty >>>>>> efficient to tweak & test the python code quickly. >>>>>> >>>>>> -Steve >>>>>> >>>>>> [1] https://github.com/pieper/SlicerRC >>>>>> >>>>>> [2] >>>>>> https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L186-L212 >>>>>> >>>>>> [3] https://github.com/pieper/SlicerRC/blob/master/slicerrc.py#L250 >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 10:57 AM, Aaron Boxer wrote: >>>>>> >>>>>>> Thanks, Steve. I'm happy to fix bugs. >>>>>>> >>>>>>> What is your dev environment like? Can you build the DICOM widget >>>>>>> standalone, or do you need to run it from the Slicer project? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 13, 2014 at 8:27 AM, Steve Pieper wrote: >>>>>>> >>>>>>>> Hi Aaron - >>>>>>>> >>>>>>>> The code is split between the core functionality in ctk [1] and the >>>>>>>> slicer module's use of that code [2]. You could review and contribute to >>>>>>>> the issues [3]. >>>>>>>> >>>>>>>> HTH, >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> [1] https://github.com/commontk/CTK/tree/master/Libs/DICOM >>>>>>>> >>>>>>>> [2] >>>>>>>> https://github.com/Slicer/Slicer/tree/master/Modules/Scripted/DICOM >>>>>>>> >>>>>>>> [3] >>>>>>>> http://na-mic.org/Bug/search.php?project_id=3&category=Module+DICOM&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=90 >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 12, 2014 at 9:44 PM, Aaron Boxer wrote: >>>>>>>> >>>>>>>>> I have some ideas about improving the user expericne for the DICOM >>>>>>>>> widget. What tools would I need to build and modify this ? >>>>>>>>> >>>>>>>>> Thanks very much, >>>>>>>>> Aaron >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> slicer-devel mailing list >>>>>>>>> slicer-devel at bwh.harvard.edu >>>>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>>>>> To unsubscribe: send email to >>>>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>>>>> the subject >>>>>>>>> >>>>>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>>>>> >>>>>>>>> >>>>>>>>> The information in this e-mail is intended only for the person to >>>>>>>>> whom it is >>>>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>>>> the e-mail >>>>>>>>> contains patient information, please contact the Partners >>>>>>>>> Compliance HelpLine at >>>>>>>>> http://www.partners.org/complianceline . If the e-mail was sent >>>>>>>>> to you in error >>>>>>>>> but does not contain patient information, please contact the >>>>>>>>> sender and properly >>>>>>>>> dispose of the e-mail. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> >> >> -- >> +1 919 869 8849 >> > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Feb 25 23:18:12 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 25 Feb 2014 18:18:12 -0500 Subject: [Ctk-developers] DCMTK JPEG 2000 support (was: [slicer-devel] JPEG 2000) In-Reply-To: References: Message-ID: Cross-posting answer from Aaron: On Tue, Feb 25, 2014 at 9:19 AM, Aaron Boxer wrote: > > Thanks. My patch will probably not be accepted by Offis, since they have > their own commercial jpeg 2000 product. > So, using this means that we will have to use an unofficial DCMTK build. > > My patch changes very little in the library, so it is quite safe. > On Tue, Feb 25, 2014 at 6:01 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > > > ---------- Forwarded message ---------- > From: Aaron Boxer > Date: Fri, Feb 21, 2014 at 3:28 PM > Subject: Re: [slicer-devel] JPEG 2000 > To: "slicer-devel at bwh.harvard.edu" > > > Well Folks, I've been able to successfully decode jpeg 2000 images on my > dcmtk branch. > > You can find the branch here: > > https://github.com/OpenRadStack/dcmtk/tree/j2k > > I am still using git submodules and manual build to build openjpeg; > haven't had a chance yet to follow Jcr's build advice. > > > If you would like to try it out, you can follow these steps: > > 1) clone the project > 2) run $ git submodule init & git submodule update > 3) use cmake to build openjpeg (third-party/openjpeg) into > third-party/openjpeg-build folder (enable shared library) > 4) make sure that openjp2 shared library is in your path > > For testing, I am running the dcmtk dcmj2pnm command line tool to convert > dicom images to bmp. > > Command line I am using: > > +ob +Wm dicomFile destinationFile.bmp > > Cheers, > Aaron > > > > > > > On Thu, Feb 20, 2014 at 2:26 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> Hi Aaron, >> >> This is great news. >> >> I don't think DCMTK should use either git submodule or External project, >> instead you should assume the library is either installed on the system or >> related path passed at configure time. You could then just call: >> >> find_package(OpenJPEG NO_MODULE) See [1] >> >> in the 3rdparty.cmake. See [2] >> >> When configuring DCMTK, it means you would simply pass the path the >> OpenJPEG build tree passing -DOpenJPEG_DIR:PATH=/path/to/openJPEG-build >> >> >> [1] This is possible because a OpenJPEGConfig.cmake is configured. see >> http://code.google.com/p/openjpeg/source/browse/trunk/cmake/OpenJPEGConfig.cmake.inand >> http://code.google.com/p/openjpeg/source/browse/trunk/CMakeLists.txt#298 >> >> [2] https://github.com/commontk/DCMTK/blob/patched-3/CMake/3rdparty.cmake >> >> >> On Thu, Feb 20, 2014 at 2:08 PM, Aaron Boxer wrote: >> >>> Update: I am closing in on a jpeg2000-enabled branch from DCMTK master. >>> Should be ready next week. >>> One issue I am having: I have added the openjpeg project (which is a >>> cmake proj) to dcmtk as a git submodule. >>> Now I need to figure out how the cmake externalproject command works. >>> >>> ( >>> http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject >>> ) >>> >>> If anyone here is familiar with this, and would like to help, please let >>> me know. >>> >>> Thanks, >>> Aaron >>> >>> >>> >>> On Mon, Feb 17, 2014 at 9:45 AM, Steve Pieper wrote: >>> >>>> Hi Aaron - >>>> >>>> I like your plan of reviewing the osirix implementation and taking >>>> advantage of the latest developments in OpenJPEG - very exciting to see >>>> this moving ahead! >>>> >>>> Regarding your questions about thumbnails in ctkDICOM2: CTK only uses >>>> DCMTK, not GDCM, so it currently fails to create thumbnails for images not >>>> directly supported by DCMTK. CTK doesn't have a mechanism to use ITK or >>>> GDCM, although I suppose this could be added. In ctk we really wanted to >>>> have robust networking support in CTK and as you noted DCMTK has a well >>>> established track record in this. >>>> >>>> Best, >>>> Steve >>>> >>>> >>>> On Mon, Feb 17, 2014 at 8:53 AM, Aaron Boxer wrote: >>>> >>>>> Hi Steve, >>>>> >>>>> >>>>>> That would be an awesome contribution - useful for slicer but also >>>>>> for CTK and other DCMTK users. The situation right now is that slicer >>>>>> builds dcmtk (without jpeg2000 as you noted) so none of the dcmtk-based >>>>>> code can access that kind of image. So for example in the ctkDICOM app the >>>>>> thumbnails aren't displayed for data of that type. The osirix sample data >>>>>> is a good source of images that are compressed in a way dcmtk doesn't like. >>>>>> >>>>>> That said, when slicer actually goes to read the data it is delegated >>>>>> to ITK's readers, which include GDCM and that supports jpeg2000 so the >>>>>> files load. >>>>>> >>>>> >>>>> Interesting. Can the ctkDICOM app use GDCM for the thumbnails? >>>>> >>>>> >>>>>> >>>>>> This is an oddly messy situation. Personally I wish ITK had used >>>>>> DCMTK from the start, since that includes all the networking and other >>>>>> support. But instead it started with GDCM, on the idea that it's lighter >>>>>> weight and has support for things like jpeg2000 and then later added DCMTK >>>>>> support too. Since slicer delegates to ITK, there are some situations >>>>>> where DCMTK is used and others where GDCM is used. >>>>>> >>>>> >>>>> Yes. GDCM and DCMTK seem to excell in orthogonal areas: GDCM on DICOM >>>>> image reading and DCMTK on DICOM networking. So, I can see why ITK chose >>>>> GDCM initially, because it is an image-focused toolkit. >>>>> >>>>> I would like to see more networking in GDCM, and more transfer >>>>> syntaxes supported in the open DCMTK version :) >>>>> >>>>> Anywho, I would be happy to add both JPEG2000 and JPEG-LS to DCMTK. >>>>> >>>>> Cheers, >>>>> Aaron >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> On Sat, Feb 15, 2014 at 10:05 AM, Aaron Boxer wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I was wondering about types of compression supported by the slicer >>>>>>> DICOM module. >>>>>>> As you probably know, many DICOM images are compressed with JPEG >>>>>>> 2000 compression. And I believe that DCMTK sells support for JPEG 2000, >>>>>>> which leads me to believe that the slicer version of DCMTK does not support >>>>>>> JPEG 2000. >>>>>>> >>>>>>> Is this the case? Because I have done some work on the OpenJPEG >>>>>>> project, and I think I could integrate OpenJPEG support into the slicer >>>>>>> DCMTK. >>>>>>> >>>>>>> Kind Regards, >>>>>>> Aaron >>>>>>> >>>>>>> _______________________________________________ >>>>>>> slicer-devel mailing list >>>>>>> slicer-devel at bwh.harvard.edu >>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>>> To unsubscribe: send email to >>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>>> the subject >>>>>>> >>>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>>> >>>>>>> >>>>>>> The information in this e-mail is intended only for the person to >>>>>>> whom it is >>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>> the e-mail >>>>>>> contains patient information, please contact the Partners Compliance >>>>>>> HelpLine at >>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>>> you in error >>>>>>> but does not contain patient information, please contact the sender >>>>>>> and properly >>>>>>> dispose of the e-mail. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> slicer-devel mailing list >>> slicer-devel at bwh.harvard.edu >>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>> To unsubscribe: send email to >>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the >>> subject >>> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>> >>> >>> The information in this e-mail is intended only for the person to whom >>> it is >>> addressed. If you believe this e-mail was sent to you in error and the >>> e-mail >>> contains patient information, please contact the Partners Compliance >>> HelpLine at >>> http://www.partners.org/complianceline . If the e-mail was sent to you >>> in error >>> but does not contain patient information, please contact the sender and >>> properly >>> dispose of the e-mail. >>> >>> >> >> >> -- >> +1 919 869 8849 >> > > > _______________________________________________ > slicer-devel mailing list > slicer-devel at bwh.harvard.edu > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > To unsubscribe: send email to > slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the > subject > > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. > > > > > -- > +1 919 869 8849 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Tue Feb 25 23:35:14 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Tue, 25 Feb 2014 18:35:14 -0500 Subject: [Ctk-developers] DCMTK JPEG 2000 support (was: [slicer-devel] JPEG 2000) In-Reply-To: References: Message-ID: Hi Aaron et al., Looking at the topic named "j2k" [1], I noticed that you backported the change originally implemented by Osirix folks [2] Few ideas: 1) Checking the osirix history, there are also more general bug fixes that could probably be contributed to upstream DCMTK. We should probably look into these. 2) Based on Michael answer [3], I don't think they would be against integrating support for Jpeg2k. @Michael: Assuming we also add test validating the proper integration, would you be up to consider upstream integration ? 3) Waiting change are pushed into the official upstream DCMTK, may be CTK and Osirix folks could share a common repository ? Let me know what you think, Thanks Jc [1] https://github.com/OpenRadStack/dcmtk/commits/j2k [2] https://github.com/pixmeo/osirix/commits/develop/Binaries/dcmtk-source [3] http://slicer-devel.65872.n3.nabble.com/JPEG-2000-tp4030949p4030965.html On Tue, Feb 25, 2014 at 6:18 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Cross-posting answer from Aaron: > > On Tue, Feb 25, 2014 at 9:19 AM, Aaron Boxer wrote: > >> >> Thanks. My patch will probably not be accepted by Offis, since they have >> their own commercial jpeg 2000 product. >> So, using this means that we will have to use an unofficial DCMTK build. >> >> My patch changes very little in the library, so it is quite safe. >> > > > > On Tue, Feb 25, 2014 at 6:01 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Aaron Boxer >> Date: Fri, Feb 21, 2014 at 3:28 PM >> Subject: Re: [slicer-devel] JPEG 2000 >> To: "slicer-devel at bwh.harvard.edu" >> >> >> Well Folks, I've been able to successfully decode jpeg 2000 images on my >> dcmtk branch. >> >> You can find the branch here: >> >> https://github.com/OpenRadStack/dcmtk/tree/j2k >> >> I am still using git submodules and manual build to build openjpeg; >> haven't had a chance yet to follow Jcr's build advice. >> >> >> If you would like to try it out, you can follow these steps: >> >> 1) clone the project >> 2) run $ git submodule init & git submodule update >> 3) use cmake to build openjpeg (third-party/openjpeg) into >> third-party/openjpeg-build folder (enable shared library) >> 4) make sure that openjp2 shared library is in your path >> >> For testing, I am running the dcmtk dcmj2pnm command line tool to convert >> dicom images to bmp. >> >> Command line I am using: >> >> +ob +Wm dicomFile destinationFile.bmp >> >> Cheers, >> Aaron >> >> >> >> >> >> >> On Thu, Feb 20, 2014 at 2:26 PM, Jean-Christophe Fillion-Robin < >> jchris.fillionr at kitware.com> wrote: >> >>> Hi Aaron, >>> >>> This is great news. >>> >>> I don't think DCMTK should use either git submodule or External project, >>> instead you should assume the library is either installed on the system or >>> related path passed at configure time. You could then just call: >>> >>> find_package(OpenJPEG NO_MODULE) See [1] >>> >>> in the 3rdparty.cmake. See [2] >>> >>> When configuring DCMTK, it means you would simply pass the path the >>> OpenJPEG build tree passing -DOpenJPEG_DIR:PATH=/path/to/openJPEG-build >>> >>> >>> [1] This is possible because a OpenJPEGConfig.cmake is configured. see >>> http://code.google.com/p/openjpeg/source/browse/trunk/cmake/OpenJPEGConfig.cmake.inand >>> http://code.google.com/p/openjpeg/source/browse/trunk/CMakeLists.txt#298 >>> >>> [2] >>> https://github.com/commontk/DCMTK/blob/patched-3/CMake/3rdparty.cmake >>> >>> >>> On Thu, Feb 20, 2014 at 2:08 PM, Aaron Boxer wrote: >>> >>>> Update: I am closing in on a jpeg2000-enabled branch from DCMTK master. >>>> Should be ready next week. >>>> One issue I am having: I have added the openjpeg project (which is a >>>> cmake proj) to dcmtk as a git submodule. >>>> Now I need to figure out how the cmake externalproject command works. >>>> >>>> ( >>>> http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:ExternalProject >>>> ) >>>> >>>> If anyone here is familiar with this, and would like to help, please >>>> let me know. >>>> >>>> Thanks, >>>> Aaron >>>> >>>> >>>> >>>> On Mon, Feb 17, 2014 at 9:45 AM, Steve Pieper wrote: >>>> >>>>> Hi Aaron - >>>>> >>>>> I like your plan of reviewing the osirix implementation and taking >>>>> advantage of the latest developments in OpenJPEG - very exciting to see >>>>> this moving ahead! >>>>> >>>>> Regarding your questions about thumbnails in ctkDICOM2: CTK only uses >>>>> DCMTK, not GDCM, so it currently fails to create thumbnails for images not >>>>> directly supported by DCMTK. CTK doesn't have a mechanism to use ITK or >>>>> GDCM, although I suppose this could be added. In ctk we really wanted to >>>>> have robust networking support in CTK and as you noted DCMTK has a well >>>>> established track record in this. >>>>> >>>>> Best, >>>>> Steve >>>>> >>>>> >>>>> On Mon, Feb 17, 2014 at 8:53 AM, Aaron Boxer wrote: >>>>> >>>>>> Hi Steve, >>>>>> >>>>>> >>>>>>> That would be an awesome contribution - useful for slicer but also >>>>>>> for CTK and other DCMTK users. The situation right now is that slicer >>>>>>> builds dcmtk (without jpeg2000 as you noted) so none of the dcmtk-based >>>>>>> code can access that kind of image. So for example in the ctkDICOM app the >>>>>>> thumbnails aren't displayed for data of that type. The osirix sample data >>>>>>> is a good source of images that are compressed in a way dcmtk doesn't like. >>>>>>> >>>>>>> That said, when slicer actually goes to read the data it is >>>>>>> delegated to ITK's readers, which include GDCM and that supports jpeg2000 >>>>>>> so the files load. >>>>>>> >>>>>> >>>>>> Interesting. Can the ctkDICOM app use GDCM for the thumbnails? >>>>>> >>>>>> >>>>>>> >>>>>>> This is an oddly messy situation. Personally I wish ITK had used >>>>>>> DCMTK from the start, since that includes all the networking and other >>>>>>> support. But instead it started with GDCM, on the idea that it's lighter >>>>>>> weight and has support for things like jpeg2000 and then later added DCMTK >>>>>>> support too. Since slicer delegates to ITK, there are some situations >>>>>>> where DCMTK is used and others where GDCM is used. >>>>>>> >>>>>> >>>>>> Yes. GDCM and DCMTK seem to excell in orthogonal areas: GDCM on >>>>>> DICOM image reading and DCMTK on DICOM networking. So, I can see why ITK >>>>>> chose GDCM initially, because it is an image-focused toolkit. >>>>>> >>>>>> I would like to see more networking in GDCM, and more transfer >>>>>> syntaxes supported in the open DCMTK version :) >>>>>> >>>>>> Anywho, I would be happy to add both JPEG2000 and JPEG-LS to DCMTK. >>>>>> >>>>>> Cheers, >>>>>> Aaron >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Sat, Feb 15, 2014 at 10:05 AM, Aaron Boxer wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I was wondering about types of compression supported by the slicer >>>>>>>> DICOM module. >>>>>>>> As you probably know, many DICOM images are compressed with JPEG >>>>>>>> 2000 compression. And I believe that DCMTK sells support for JPEG 2000, >>>>>>>> which leads me to believe that the slicer version of DCMTK does not support >>>>>>>> JPEG 2000. >>>>>>>> >>>>>>>> Is this the case? Because I have done some work on the OpenJPEG >>>>>>>> project, and I think I could integrate OpenJPEG support into the slicer >>>>>>>> DCMTK. >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Aaron >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> slicer-devel mailing list >>>>>>>> slicer-devel at bwh.harvard.edu >>>>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>>>>>> To unsubscribe: send email to >>>>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as >>>>>>>> the subject >>>>>>>> >>>>>>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>>>>>> >>>>>>>> >>>>>>>> The information in this e-mail is intended only for the person to >>>>>>>> whom it is >>>>>>>> addressed. If you believe this e-mail was sent to you in error and >>>>>>>> the e-mail >>>>>>>> contains patient information, please contact the Partners >>>>>>>> Compliance HelpLine at >>>>>>>> http://www.partners.org/complianceline . If the e-mail was sent to >>>>>>>> you in error >>>>>>>> but does not contain patient information, please contact the sender >>>>>>>> and properly >>>>>>>> dispose of the e-mail. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> slicer-devel mailing list >>>> slicer-devel at bwh.harvard.edu >>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >>>> To unsubscribe: send email to >>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the >>>> subject >>>> >>>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >>>> >>>> >>>> The information in this e-mail is intended only for the person to whom >>>> it is >>>> addressed. If you believe this e-mail was sent to you in error and the >>>> e-mail >>>> contains patient information, please contact the Partners Compliance >>>> HelpLine at >>>> http://www.partners.org/complianceline . If the e-mail was sent to you >>>> in error >>>> but does not contain patient information, please contact the sender and >>>> properly >>>> dispose of the e-mail. >>>> >>>> >>> >>> >>> -- >>> +1 919 869 8849 >>> >> >> >> _______________________________________________ >> slicer-devel mailing list >> slicer-devel at bwh.harvard.edu >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel >> To unsubscribe: send email to >> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the >> subject >> >> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ >> >> >> The information in this e-mail is intended only for the person to whom it >> is >> addressed. If you believe this e-mail was sent to you in error and the >> e-mail >> contains patient information, please contact the Partners Compliance >> HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you >> in error >> but does not contain patient information, please contact the sender and >> properly >> dispose of the e-mail. >> >> >> >> >> -- >> +1 919 869 8849 >> > > > > -- > +1 919 869 8849 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From onken at offis.de Tue Feb 25 23:59:55 2014 From: onken at offis.de (Michael Onken) Date: Wed, 26 Feb 2014 00:59:55 +0100 Subject: [Ctk-developers] DCMTK JPEG 2000 support (was: [slicer-devel] JPEG 2000) In-Reply-To: References: Message-ID: <530D2E7B.6040909@offis.de> Hi JC and everybody, On 26.02.2014 00:35, Jean-Christophe Fillion-Robin wrote: > Hi Aaron et al., > > Looking at the topic named "j2k" [1], I noticed that you backported > the change originally implemented by Osirix folks [2] > > Few ideas: > > 1) Checking the osirix history, there are also more general bug fixes > that could probably be contributed to upstream DCMTK. We should > probably look into these. I already have the patches in my working pipeline. Many of them are fixes taken over from DCMTK into the Osirix copy. But I have to go through them step by step which will take some time. > > 2) Based on Michael answer [3], I don't think they would be against > integrating support for Jpeg2k. @Michael: Assuming we also add test > validating the proper integration, would you be up to consider > upstream integration ? As Aaaron said, I do not think we can do that. Our JPEG2000 library is one of the components used to finance open source DCMTK development. I raised the question in OFFIS and they have not been too enthusiastic... Further, copying a quote from Aarons original posting: > My [JPEG2000] patch changes very little in the library, so it is > quite safe. As far as I remember our JPEG2000 module does not change *anything* in the existing code of all other parts of DCMTK. Thus it should be possible to have your own JPEG2000 extension completely separated from the official DCMTK, too, in an extra directory or whatever. You just have to register the compression/decompression codecs at runtime using the corresponding mechanism in DCMTK. One can perfectly see how it works in the "dcmjpeg" module in DCMTK which does the same for our JPEG codecs (or "dcmjpls" for the JPEG-LS codecs), which do not interfere with other parts of the DCMTK code either. HTH, Michael -- Dipl.-Inform. Michael Onken FuE Bereich Gesundheit | R&D Division Health OFFIS FuE Bereich Gesundheit | R&D Division Health Escherweg 2 - 26121 Oldenburg - Germany Phone/Fax.: +49 441 9722-149/111 E-Mail: onken at offis.de URL: http://www.offis.de From sergio.vera at alma3d.com Thu Feb 27 11:41:49 2014 From: sergio.vera at alma3d.com (Sergio Vera) Date: Thu, 27 Feb 2014 12:41:49 +0100 Subject: [Ctk-developers] CTK compilation under Xcode 5.02 (clang5.0) In-Reply-To: References: Message-ID: Hi Jean Yes, your fork seems to work properly (now XCode complains that Qt is 32 bits and I'm trying to compile CTK in 64bits, I'm farly new to XCode and OSX and I'm still trying to figure out some basic thinks) Many thanks :D On Tue, Feb 25, 2014 at 3:23 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Sergio, > > I just pushed a topic updating the version of VTK used in CTK to the head > of the 5.10 release branch. > > See https://github.com/jcfr/CTK/tree/ctk-clang-compilation > > Let us know if this fixes the issue, then we will integrate the patch. > > Hth > Jc > > > On Tue, Feb 25, 2014 at 9:13 AM, Steve Pieper wrote: > >> Hi Sergio - >> >> Slicer compiles against the latest clang/Xcode/Mavericks setup. It >> builds VTK and CTK so you could investigate what's different in your builds. >> >> -Steve >> >> >> On Tue, Feb 25, 2014 at 3:59 AM, Sergio Vera wrote: >> >>> Hello anyone has been able to compile CTK under Mac OS X Maverick / >>> Xcode 5.02 (clang5.0)? >>> >>> VTK fails to compile. As far as I have read, VTK 5.10 refuses to compile >>> against Maverick (10.9) SDK but compiles fine in mountain lion (10.8) OS X >>> SDK. However, even after changing the target SDK inside Xcode, the VTK >>> cloned by CTK does not compile. >>> >>> Best regards >>> >>> -- >>> Sergio Vera >>> >>> Alma IT Systems >>> C/ Vilana, 4B, 4? 1? >>> 08022 Barcelona >>> T. (+34) 932 380 592 >>> www.alma3d.com >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> >> _______________________________________________ >> Ctk-developers mailing list >> Ctk-developers at commontk.org >> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >> >> > > > -- > +1 919 869 8849 > -- Sergio Vera Alma IT Systems C/ Vilana, 4B, 4? 1? 08022 Barcelona T. (+34) 932 380 592 www.alma3d.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Feb 27 21:54:41 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 27 Feb 2014 16:54:41 -0500 Subject: [Ctk-developers] CTK compilation under Xcode 5.02 (clang5.0) In-Reply-To: References: Message-ID: Thanks for the feedback. I just integrated the topic into CTK master. Instead of using XCode, could you try compiling CTK using "Unix Makefile" generator ? Hth Jc On Thu, Feb 27, 2014 at 6:41 AM, Sergio Vera wrote: > Hi Jean > > Yes, your fork seems to work properly (now XCode complains that Qt is 32 > bits and I'm trying to compile CTK in 64bits, I'm farly new to XCode and > OSX and I'm still trying to figure out some basic thinks) > > Many thanks :D > > > On Tue, Feb 25, 2014 at 3:23 PM, Jean-Christophe Fillion-Robin < > jchris.fillionr at kitware.com> wrote: > >> Hi Sergio, >> >> I just pushed a topic updating the version of VTK used in CTK to the head >> of the 5.10 release branch. >> >> See https://github.com/jcfr/CTK/tree/ctk-clang-compilation >> >> Let us know if this fixes the issue, then we will integrate the patch. >> >> Hth >> Jc >> >> >> On Tue, Feb 25, 2014 at 9:13 AM, Steve Pieper wrote: >> >>> Hi Sergio - >>> >>> Slicer compiles against the latest clang/Xcode/Mavericks setup. It >>> builds VTK and CTK so you could investigate what's different in your builds. >>> >>> -Steve >>> >>> >>> On Tue, Feb 25, 2014 at 3:59 AM, Sergio Vera wrote: >>> >>>> Hello anyone has been able to compile CTK under Mac OS X Maverick / >>>> Xcode 5.02 (clang5.0)? >>>> >>>> VTK fails to compile. As far as I have read, VTK 5.10 refuses to >>>> compile against Maverick (10.9) SDK but compiles fine in mountain lion >>>> (10.8) OS X SDK. However, even after changing the target SDK inside Xcode, >>>> the VTK cloned by CTK does not compile. >>>> >>>> Best regards >>>> >>>> -- >>>> Sergio Vera >>>> >>>> Alma IT Systems >>>> C/ Vilana, 4B, 4? 1? >>>> 08022 Barcelona >>>> T. (+34) 932 380 592 >>>> www.alma3d.com >>>> >>>> _______________________________________________ >>>> Ctk-developers mailing list >>>> Ctk-developers at commontk.org >>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>>> >>>> >>> >>> _______________________________________________ >>> Ctk-developers mailing list >>> Ctk-developers at commontk.org >>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers >>> >>> >> >> >> -- >> +1 919 869 8849 >> > > > > -- > Sergio Vera > > Alma IT Systems > C/ Vilana, 4B, 4? 1? > 08022 Barcelona > T. (+34) 932 380 592 > www.alma3d.com > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: