We have had this plan for several years now to customize the content of the fields that appear in the DICOM browser. We wanted to get rid of the ^ character in the patient name, show the time a patient/study/series was added, show number if images in a series, etc.
I created a branch during the 2014 CTK Hackfest in Kingston that never got integrated due to the different needs of the MITK and Slicer people. However I decided to resurrect that branch hoping that we can now change this part of CTK. Here is the rebased, merged, squashed, and fixed branch that works with the latest Slicer and CTK.
In a nutshell, this is what it contains:
For Patient, Study, Series tables there is a corresponging DisplayPatient, DisplayStudies, DisplaySeries table in the database that contain the fields we want to show in the DICOM browser
Plugins can generate fields from modality-specific data and user needs
A method calls the plugins to generate the display tables from regular tables when import ended
We talked to @lassoan about how we could continue from here, and this is what we think would be a good plan:
Use the 3 tables (instead of 3+3), but add new columns for display fields (with prefix “Display”)
Easier synchronization on removal etc.
New table for column properties
Table
FieldName
DisplayName
Order (-1 for not shown?)
Format (“last name, first name”, unit properties, etc. - rules can use these for generating displayed fields)
ViewID (in case there will be multiple property tables - can add later if needed)
New columns
Number of slices for series (show number of files for simplicity)
Number of studies for patients
Insert timestamp for all three tables
Number of series for studies
We need to still decide where the plugins would come from and how. Currently all plugins are C++ and are in CTK (that’s how I did it for easy implementation and testing), but we could use the DICOM plugins in Slicer to define these “rules”.
These are great ideas to experiment with! Do you think there could be a way to develop this, at least initially, separately from CTK so it could be easier to prototype/iterate in Slicer nightlies (collect feedback from the users and developers, experiment with the plugins integration, UI customization etc) and later migrate into CTK? Or maybe we could build Slicer nightlies against your custom CTK branch for some time? I can definitely see how this potentially could be very useful, but it probably will take the time to refine the details.
Yes this is a big change and we need to make sure it’s mature and accepted by everyone before making a change in CTK master. I think you’re right and probably the best way would be building Slicer against a CTK branch. All this after 4.10.1 of course.
Great to move ahead with this. I like the idea of using the nightlies for experiments. We are always free to fork CTK to meet our needs and even create a second variant widget in CTK if MITK still needs the existing structure to remain as-is. @nolden will be in Las Palmas so we can also go over options there as needed.
I’m very happy to see this initiative, and I can even remember the first discussions in Kingston. MITK is still using the current widget, but I’m sure we could manage any API changes and I assume all of our users would be very happy to see an update here, I’m not aware on anyone particulary dependent on the current look and feel.
I cannot promise anything, but I filed this for MITK (https://phabricator.mitk.org/T25745) and think we can discuss a bit more latest at the Gran Canaria event. Thanks for your effort @cpinter
