ITK/Release 4/DICOM/Tcon 2011 08 25

• steve: pretty consistent, no surprise
• ron
• - based on ctk which is on top of DCMTK, on the verge of working for slicer (works on steve's almost on ron's)
• - that s the chosen direction
• - we are also planning to developed an internal format that can be stored and retrieved from a PACS (in principle) we called it lollipop internally.
• - now today itk being based on gdcm, the result is some inconsistencies that lead to reading (/writing) twice the images which is wasting.
• - DICOM RT would be nice
• - better support for diffusion (MRI?)
• > steve
• - that s pretty much it
• - ( never understood why DICOM protocol / PACS gdcm support was stressed that much )
• - we have to do a major work to support ITK because of gdcm today and if we have to move to gdcm 2.x it will be a lot of work
• > terry
• - it was not clear at that time that the licence was ok for dcmtk
• - it was not clear that such an active group would exists around DCMTK
• - it's not ITK role to handle GUI, it makes a lot of sense for ctk. Its kind of a PACS GUI lego
• - DCMTK *nowadays* are very active, the overall situation is different today
• - can someone tell me about licencing concern?
• - can someone comment about stability today?
• - metadata dictionnary support should be handled for example outside of the pure image processing (ITK) pipeline for example.
• > steve
• - for really testing, you need to test against hospital environement
• - and against vendors's machine (siemens) and such.
• > terry
• - understand, we need such partners
• - most of our PACS are running within pvt networks, so having an (ITK) dashboard would be great.
• - one of the strength of the ITK project are the volunteers providing machines: NIH, HMS, GE, ...
• - They could check that it operates on a daily basis (even though we might have to drill a hole).
• - If we can achieve that we will have given help to a lot of people. Wether it is gdcm or DCMTK.
• - Did not mean to be defensive of the review process, but we need to check carefully the licence.
• > steve
• - there is no such problem, at least for the parts we are using.
• > terry
• - there is also the concern of the sixe, even though it is not such a concern for itk v4 thanks for modularity
• > steve
• - we are using the 3.6 release now
• - git server in germany slow, might have to mirror
• - 3.6 release was updated to make ctk compiled. everything was sync'ed and the DCMTK team was very proactive
• > bill
• - especially since feb hackfest
• > ron
• - the fact that lots where in europe helped.
• > steve
• - david gobbi shared some cmake script around SLC's NAMIC (3 years ago)
• - since then it s been quite a success story for open source in general
• > bill
• - integration ( gdcm / dcmtk) was fuzzy untill earlier this year
• - realy the communication was the most important
• - but having it in the toolkit did not really make sense
• - the way we used it even before was to use dcmtk to get the image here then use ITK.
• > steve
• - really, to go back to terry point of view, the problem of keeping metadata around
• - also to go back to ron, to avoid rewriting around, keeping the metadata support in ITK, or even in sql DB, that would be ideal.
• > stephen
• - discussion tuesday about streaming
• - do you actually at anytime want to stram directly from the pacs to an ITK pipeline
• - I personally don t think so as we multitask
• > steve
• - I can t imagine any case where we would want to stream directly
• > ron
• - closest usage scenario would be using batch mode
• > steve
• - yeah but you would still want to use FS.
• > bill
• - as it turns out, you never know what kind of DS you will get, so you still will have to parse out the data before you decide what to do with it
• > steve, stephen
• - exactly
• > steve
• - the way we do it in CTK, we first store it in th DB then write it to disk
• - the point is in your DB you construct your DB with knoledge of the hierarchy and so on
• - then you can handle the DB to set up the pipelines and even reconstruct the ITK Image without havign to reparse anything
• - We can then tell ITK not to try to reconstruct anything
• > stephen
• - the way I see it is that we will have to eventually make a choice between gdcm and dcmtk.
• - the reason being once the parsing is done (with dcmtk) you odn t want gdcm to come in because the parsin, the DS to support tags would be different.
• > bill
• - can CTK make the ITK image for you.
• > dan
• [...]
• > bill
• - there are methods in ITK to create an image from a pointer
• - so so the application could form the image and handle it to ITK
• - point being, ctk handle the dicom part and handle the image to ITK
• > dan
• - yeah, it works very well for us, dicom is handled separatly from the (ITK) toolkit, as we need to handle our tags anyway
• > steve
• - in terme of the slicer interface, we will have the same kind of income / outcome filter.
• - when you are ready you can reassociate the rsult with a patient and the metadatat get grafted back in.
• > bill
• - in a way it makes more sense.
• - ITK should not have to know how the metadata shoudl be handle (or even exist)
• > stephen
• - yeah, the analogy is teaching a resampling filter that he has to also modify ....
• > terry
• - what should we do between now and december?
• > alex:
• - drop the PACS implementation in gdcm
• - use dcmtk and ctk for that, at the application level (steve: there is still work, but it s really ahead of gdcm today)
• > terry
• - streaming directly from PACS to ITK pipeline ?
• - alex: consensus on no usage case
• - bill: maybe the only one is a more passive case: a DICOM listener
• - terry: let me rephrase: we shoudl be running tests. Where does those data come from?
• - ron: we had this discussion for ctk. it would be good to have some PACS available for that. without needing to go to IT people
• - steve: realistically, they won t be that helpful as clinical people will not want you to mess with their data / systems.
• - stephen: one step back. Heard from Alex: no PACS in gdcm. Will do RT, diffusion MRI, and streaming from disk. Redirect some effort wrapping/simpleITK effort.
• - stephen: dan point of view: three steps process dcmtk for dicom, then itk, then ... What is mayo clinic plan ? SOme tasks might have a lower priority for ITK v4 point of view?
• - terry: ctk having a script to connect to a PACS and make sure the filters continue to work the way they used to. This testing is important.
• - stephen: sure, but streaming directly in memory is not.
• - terry: yeah, but do you need to have slicer in between to access the legion DS?
• - stephen: i don t think anybody is proposing that.
• - terry: The mayo group might want to take a look at ctk/dcmtk to check.
• - ron: the reason why we use ctk is to compensate for things that are in nobody's else territory.
• - stephen: dan, do you see the solution you are providing will require ctk?
• - dan: no. [...] Now at the meeting last year, mathieu and alex would do the networking, so we decided not to dump dcmtk in ITK. So we decided we would support and take more a testing role for cosmo. As things have evolved, simpleITK took most of effort, and gdcm never went to the point where they would need our help with PACS station.
• - steve: everything related to Qt integration in ctk is not relevant to ITK. But anything that would help bypass the double parsing problem would be beneficial to ITK.
• - terry: what are we going to deliver by december: RT, diffusion, .... but then what ? I hear more basic problem, double parsing. Managing metadata. This is less important for image processing, but to the user it is maybe the most important.
• - stephen: is it the right thing to do it on filter to filter basis? Instead of having a way to handle a "parallel" entity (gdcm? dcmtk?) that handle the metadata part.
• - steve: the concept of modularity, with inter beneficial nature is important. At the dcmtk/ctk level we should be able to do the network and the infrastructure, perhaps in the DB. it would be great if ITK could be pointed to the DB and get infos from there to reconstruct the image. That would be great. Other thing would be for us to be able to within itk to define the in memory metadata dic equivalent of the DB structure. In a ctk application (slicer) then it would be easy to go back and forth. Maybe the API exists today, but convention for metadata dic is not defined. I don t think that IT needs to depend on ctk, we just need as a community to agree on the format.
• - stephen: The capacity from ctk to be able to get data from pacs to the DB should be able to be extracted, not to depend on ctk, and could be integrated in ITK then, maybe as a third party module.
• - steve: yeah, it should be doable. It would be great. As long as we have a convention it could be either a metadata dic or q sqllite, doe snto matter, there would be a one-one mapping.
• - stephen: if we had a DS to represent a dicom study (hierarchical DS), it would be much easier.
• - steve: it will be essential anyway to support dicom RT.

• - terry: what are the action item to make it happen?
• - stephen: i like alex idea, but it creates a gap. The part of including dcmtk in itk is on nobody's plate.
• - terry: This might have priority on other stuff. Make Slicer community happy. We have to deliver a dicom work. It has to meet someone happy. I have one customer I want to make happy, this is slicer. What I just heard from the slicer community is: double parsing is more important than ..., better integration is more important, RT - STRUCT is more important than PACS support.
• - terry: stephen, as you have some idea on how this is implemented, steve piepper as you seem to be the person that has more understanding on how this is integrated, alex, as you are under contract, I want you to coordinate.
• - steve: we will have capacity to help.
• - terry: it needs to be done. stephen , steve, alex, make a new roadmap and deliverable. Drop or close current gdcm tickets. Dan & Bill should/could also join if they want.