[Ctk-developers] [slicer-devel] new dicom interface

Sun Nov 10 14:58:41 UTC 2013

Thanks for the feedback!  I'm forwarding the thread to the ctk developer
list since some ideas relate to the ctk components and some to the slicer
integration.

I agree with most of the suggestions and I think they will be pretty
straightforward to implement (pull requests welcome!). This is sort of a
first-pass with the new layout so we can iterate on some of these issues.
 I didn't want to delay implementing the new table display since it was
identified as a critical issue for SlicerRT.

-Steve

On Sat, Nov 9, 2013 at 1:08 PM, Andriy Fedorov <fedorov at bwh.harvard.edu>wrote:

> I agree configuration is complex and should be in advanced. I was
> thinking about list of sources. See attached the way it's done in
> syngo.via, would be great to have a similar concept in Slicer, as a
> replacement of the directory button.
>
> I also agree with you completely that the way DICOM database button
> functions right now (file dialog popup) is very confusing.
>
>
> On Sat, Nov 9, 2013 at 12:55 PM, Andras Lasso <lasso at queensu.ca> wrote:
> > The main problem with the directory selector is that the users think
> that it is for importing. I've helped several users with this problem, they
> all thought that the DICOM import was broken because they used this
> database directory selector instead of the Import button. Even after
> finding the Import directory they are still confused what this database
> directory selection is for and they are not sure if they have to set it to
> the directory where they store their DICOM files. We just should not show
> this database directory selector on the main GUI. Showing just a listbox
> (or checkboxes) with a list of database names (either local filesystem or
> remote systems) would be also fine.
> >
> > In general, _setup_ of DICOM hosts/connections, databases are too
> complex operations for most users (IP addresses, port numbers, AE titles,
> database directories, ...). However, once they are set up, the
> query/retrieve, push, etc. operations are easy to use. So, to reduce
> frustration of users and administrators, the GUI for setup should be
> clearly separated. GUI for users should be simplified and the GUI for all
> DICOM configuration settings should be editable in the Slicer Application
> settings. This applies to the Query/Retrieve GUI. The user should only see
> a list of data sources and search options; and editing server name, aeitle,
> address, port, cget flag, add/remove server, etc. should be only displayed
> in the Application settings.
> >
> > Andras
> >
> > -----Original Message-----
> > From: Andriy Fedorov [mailto:fedorov at bwh.harvard.edu]
> > Sent: November 9, 2013 12:23 PM
> > To: Andras Lasso
> > Cc: pieper at bwh.harvard.edu; slicer-devel at bwh.harvard.edu
> > Subject: Re: [slicer-devel] [Ctk-developers] new dicom interface
> >
> > On Sat, Nov 9, 2013 at 10:06 AM, Andras Lasso <lasso at queensu.ca> wrote:
> >> ·         On a laptop screen only 3-4 patients, studies, and series are
> >> visible – we should see at least about 10 of each. Change the layout
> >> (e.g., move the loadables list into a second column; hide the plugin
> >> list by default and use a >> button – similar to the one in the
> >> Application settings/Modules – to show it), decrease the row height of
> >> the patients/studies/series tables (it looks to have about 1.5-2x line
> >> spacing and/or larger font)
> >>
> >
> > I had a similar concern. Does it make sense to have Patient/Study/Series
> panels collapslible? It is currently possible to move the separator all the
> way down to use all space for one panel, but it requires a lot of mouse
> interaction.
> >
> > I like the idea of ">>" for plugins list.
> >
> >> ·         Move “Local database” selector and Make DICOM browser
> persistent
> >> to an advanced options section (in a popup window or hidden by
> >> default) to save space and reduce clutter
> >>
> >
> > Here I would suggest not to hide it, but have a drop-down (ideally --
> > checkable) list of databases. In the future, it would be great to
> integrate the remote sources that can be queried into this single drop-down
> list to provide a unified experience (this is how syngo.via does it). But
> even without remote sources, the use case is often there may be different
> databases for different projects, and right now Slicer is not very friendly
> in supporting more than one database.
> >
> >
> >
> >>
> >>
> >> Other changes to consider:
> >>
> >> ·         We could remove the “Close” button (having the “X” in the
> window
> >> corner and adding an “Esc” button shortcut should be enough)
> >>
> >> ·         View header: make it a right-click accessible option on the
> >> loadables list (note that currently if no loadable is selected it’s
> >> still enabled and shows the latest selected loadable’s info) or a
> >> small icon next to the series search bar
> >>
> >> ·         Remove: make it a right-click accessible option (now it’s so
> far
> >> from all the patient/study/series selector that it’s not very
> >> intuitive that it refers to them) or a small trashcan icon next to
> >> each search bar
> >>
> >>
> >>
> >> Andras
> >>
> >>
> >>
> >> From: ctk-developers-bounces at commontk.org
> >> [mailto:ctk-developers-bounces at commontk.org] On Behalf Of Steve Pieper
> >> Sent: November 7, 2013 2:49 PM
> >> To: slicer-devel at bwh.harvard.edu; ctk-developers at commontk.org
> >> Subject: [Ctk-developers] new dicom interface
> >>
> >>
> >>
> >> Hello from the CTK hackfest in London! [1]
> >>
> >>
> >>
> >> For a while now several of groups have been working on improving the
> >> dicom browser in CTK (the one used in the Slicer DICOM module) to make
> >> it more consistent with clinical systems and to make it easier to
> >> customize.  Work really got going at the last hackfest at Queens in
> >> Kingston [2] where a design was worked out that would help with a
> >> number of longstanding issues faced in SlicerRT [for example, 3] and
> >> some issues intrinsic to the way the old DICOM tree view was
> implemented [4].
> >>
> >>
> >>
> >> After a lot of work at the CTK level by Adreas Fetzer and Marco Nolden
> >> of DKFZ and Csaba Pinter and Andras Lasso of Queens we now have a new
> >> interface to address these issues.  Plus Alireza Mehrtash of BWH has
> >> added a DICOM header browser option to address a longstanding missing
> >> feature of slicer4 [5].  These have now been integrated into the
> >> slicer trunk [6] and the new interface is documented on the nightly
> section of the wiki [7].
> >>
> >>
> >>
> >> Of course this big of a change may take a little time to settle out,
> >> so please let us know if you see build or run time issues.
> >> Suggestions are welcome too.
> >>
> >>
> >>
> >> Cheers from jolly old England,
> >>
> >> Steve
> >>
> >>
> >>
> >>
> >>
> >> [1] http://www.commontk.org/index.php/CTK-Hackfest-Nov-2013
> >>
> >>
> >>
> >> [2]
> >> http://www.commontk.org/index.php/CTK-Hackfest-May-2013#DICOM_Database
> >> _and_Networking
> >>
> >>
> >>
> >> [3] http://na-mic.org/Bug/view.php?id=2828
> >>
> >>
> >>
> >> [4] http://na-mic.org/Bug/view.php?id=3106
> >>
> >>
> >>
> >> [5] http://na-mic.org/Bug/view.php?id=1838
> >>
> >>
> >>
> >> [6]
> >> http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=226
> >> 89
> >>
> >> [7]
> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/Modules/D
> >> ICOM
> >>
> >>
> >> _______________________________________________
> >> 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/Devel
> >> opers/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: <http://public.kitware.com/pipermail/ctk-developers/attachments/20131110/3089d116/attachment.htm>