Skip to the content.
  1. Event pictures {| |Panorama of the hackfest room! |Hard coders in action! |More hard coders in action! |}

  2. Introduction Date: February 7-11, 2011

Location: Chapel Hill, North Carolina, USA: The Franklin Hotel

Goal: A follow on to the wildly successful previous hackfests!

Requirements: Attendees must be willing to spend their time with the details of dicom, git, cmake, c++, Qt, vtk, itk, openinventor, and related technologies. People who do not feel qualified for this are politely not invited :)

Group size: Maximum 20 participants so we can have a manageable working meeting. The organizing committee will invite and select participants based on input from TheTeam.

Organizers: Ivo Wolf, Steve Pieper, Stephen Aylward

Site Hosts: Kitware’s office in North Carolina: Julien Finet, Jean-Christophe Fillion-Robin, Stephen Aylward

Future Events: Future hackfests will be announced in advance, and we hope lots of people will be interested in participating. The venue and activities at future hackfests will be determined based on the number of active participants in the project. We welcome participation via the CTK email lists, the source code repository, and this website.

  1. Attendees Please add your name below or [mailto:stephen.aylward@kitware.com;pieper@bwh.harvard.edu;i.wolf@hs-mannheim.de email the hackfest organizers] if you wish to attend the Hackfest. Please also indicate if you plan on staying at the hotel (anticipated room rate is $139/night): {| border=”5” cellpadding=”10” ! Name ! Organization ! Staying at Hotel |- | Jean-Chistophe Fillion-Robin | Kitware | No |- | Julien Finet | Kitware | No |- | Steve Pieper | Isomics | Yes |- | Ivo Wolf | Hochschule Mannheim | Yes |- | Stephen Aylward | Kitware | No |- | Marco Nolden | DKFZ, Heidelberg | Yes |- | Sascha Zelzer | DKFZ, Heidelberg | Yes |- | Daniele Giunchi | SCS, Bologna | Yes |- | Beno�t Bleuz� | INRIA, Sophia-Antipolis | Yes |- | Lawrence Tarbox | Washington University St. Louis | Yes |- | Nicholas Herlambang | AZE, Japan | Yes |- | Dave Partyka | Kitware | Yes |}

  2. Preparation Developers should bring a laptop with the current CTK source code downloaded and built.

Use the CTK developers mailing list to discuss build issues and topics for ongoing work.

  1. Topics and Projects

General set of topics (attendees, please flesh this out with your own ideas!)

1. DICOM - ctkDICOM app functionality ** Q/R  *** make CTK work with the official DCMTK release, maybe host the find-scu code in CTK *** integrate with DICOM central test node ** integrate indexer and SQLite *** Parse DICOMDIR ** ctkDICOMWidgets design and implementation plan [http://www.commontk.org/index.php/Documentation/WidgetPlans#Medical_Imaging_Widgets](http://www.commontk.org/index.php/Documentation/WidgetPlans#Medical_Imaging_Widgets) *** Display Study/Series  ** IHE standardized viewer application built using ctk? (icons, naming) *** Drill down to images *** Possibly follow guidelines from the  [IHE Basic Image Review (BIR) Profile](http://www.ihe.net/Technical_Framework/upload/IHE_RAD_Suppl_BIR_Rev1-1_TI_2010-11-16.pdf) **** Although we may not implement all of BIR, it might be nice to follow the BIR GUI conventions, such as behavior of the mouse and mouse buttons, the study/series strip, the basic GUI icons and behavior.  Perhaps these could be widgets or objects in CTK, to make it easy for users/developers to create applications that follow the spirit of BIR conventions? **** Note that we can jazz up (e.g. use 3D shading, change button shape, color) the standardized icons shown in the profile and still be compliant, as long as the basic icon form (e.g. arrow, double arrow, etc.) is recognizable. ** Local DICOM Directory and Database Structure  - Application Hosting ** Hosting Logic ** QtSOAP vs Axis2C implementation details *** Should be discussed but probably not be changed during hackfest ** How does data move?  Rendering tie in?  Need to handle dynamic data? ** What level of demo application is possible? *** Interoperable with C# and Java Implementation? *** Example hosted command line modules? (file based) *** Start work on DICOM native models ("trickle in data") ** Hosted Interface Generation *** Complicated *** XAxis2c *** CXF http://cxf.apache.org/

1. Widgets - Light image viewer

1. Events and Communications - Event Bus integration: Daniele and Sascha ** Driving use case *** Multi-process communication within an app **** Remote GUI/Viewer **** Stream bitmap ** Move protocol to core library ** Create new connector for remote comm (remote event bus) *** Using zeromq: http://www.zeromq.org/ **** Addresses limitations of QtSOAP *** Complimentary to DICOM App Hosting **** For arbitrary comm between remote apps

1. GIT / Gerrit - Review wiki instructions
  1. Accomplishments and Next Steps 1. ctkDICOM
    1. Major Classes Some of the key parts of the code that got active work during the hackfest: - Libs/DICOM/Core (wrappers around DCMTK) ** ctkDICOMDatabase - manages sqlite index, directory hierarchy, thumbnails ** ctkDICOMModel - exposes database in Qt MVC pattern ** ctkDICOMIndexer - populates database ** ctkDICOMQuery - run queries (C-Find) ** ctkDICOMRetrieve - get data (C-Move) ** ctkDICOMDataset - represent dicom data in memory ** ctkDICOMImage - expose the image data - Libs/DICOM/Widgets (QWidget subclasses for the GUI) ** ctkDICOMAppWidget - top level (used by ctkDICOM application) ** ctkDICOMQueryRetrieveWidget - implements the query/retrieve dialog ** ctkDICOMQueryWidget - exposes options for date, modality, keyword search ** ctkDICOMServerNodeWidget - options for dicom servers, AETitles, ports ** ctkDICOMThumbnailWidget - for study/series preview ** ctkDICOMDatasetViewWidget - image display, pan, zoom

See the CTK doxygen documents for more information.

Directory layout used by ctkDICOMDatabase:

pre ctkDICOMDirectory/ ctkDICOM.sql # index to files in this dir thumbnails/ StudyUID/ SeriesUID/ InstanceUID.png # one png per instance DICOM/ StudyUID/ SeriesUID/ InstanceUID.dcm # the dicom file

ctkDICOMDirectory is the one configured in the ctkDICOMViewer directory select box. ctkDICOM.sqlite caches some header values from the files locally but can also point to external directories (depending on the state of the checkbox when the user selects the Import option in the ctkDICOMViewer). /pre

  1. End User Functionality ![State of the ctkDICOM application as of 3:26pm on Friday afternoon.](/ctk-wiki-archive/images/CtkDICOM-hackfest-Feb-2011.png) These classes are tied together into the ctkDICOM application that allows the user to do the following: - Local Library ** import dicom files from disk (optionally copy files to library directory) ** view local database directory in embedded viewer ** selecting series in tree view populates thumbnails for that series ** selecting image in tree view displays it in viewer - Query/Retrieve ** use a query dialog to access remote dicom resources (PACS, scanners, etc) ** retrieve remote datasets into local database

  1. Next Steps A lot of fine tuning and testing is required on this code.  Emphasis this week was on the naming conventions and major functional components so that an end-to-end demonstration of the PACS-to-viewer pipeline.

Major pieces for further work:

Airport

Lodging

Meeting Location

Weather

Connectivity