ITK/Release 4/DICOM/Tcon 2011 08 25

Mayo clinic update

- bill ryan / dan

slicer 4 community

- steve / ron > 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 shoudl 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 ....

> alex thinking: - examples of painfull re-reading, re-writing that slicer users have today to see if we can ease their pain.

discussion and decision

- all