[Ctk-developers] [slicer-devel] DICOM Module

Jean-Christophe Fillion-Robin jchris.fillionr at kitware.com
Fri Feb 21 15:16:46 UTC 2014


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 <boxerab at gmail.com> 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 <pieper at isomics.com> 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 <boxerab at gmail.com> 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 <pieper at isomics.com>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 <boxerab at gmail.com>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 <pieper at isomics.com>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 <boxerab at gmail.com>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: <http://public.kitware.com/pipermail/ctk-developers/attachments/20140221/0861e18e/attachment.htm>


More information about the Ctk-developers mailing list