ITK/Release 4/DICOM: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
 
(22 intermediate revisions by 5 users not shown)
Line 3: Line 3:
= Goals =
= Goals =


* Improve the support for DICOM needs by the ITK community
== Improve the support for DICOM in ITK ==
** DICOM communication layer (PACS connection)
** type checking
** minimum DICOM skeleton generation


= Discussions =
# DICOM communication layer (a.k.a. PACS support, DICOM Protocol)
# Streaming of DICOM Objects
# Read and write RTStruct
# Type checking
# Minimum DICOM skeleton generation


== [[ITKv4_DICOM_Communications_Discussion | Communications Discussions]] ==
== Other requests from the ITK community ==
== how to test against PACS automatically ? ==


( thanks to steve piepper)
* handling of higher order manifold as described in DICOM standard
I had a chance to ask Lawrence Tarbox of Washington University your question
* handling of DICOMDIR format disk archives (navneeth)
about dicom testing.  Lawrence is a participant in CTK and a long-time dicom
** Unlike a standard dicom series (located in a single directory) the DICOMDIR format spreads files across directories
standards participant too (he's actually working on the hosted application
** A reader that reads the DICOMDIR file and parses appropriate files & directories is desirable
specification, which we should ultimately be compatible with).


For PACS-like testing, he pointed to two well established efforts, linked
= Development process =
below.  Lawrence knows people involved in these and thinks they might be
receptive to seeing integration with ctest and cdash if you want to pursue
that.  In any case I think we can learn a lot from these efforts.


http://www.ihe.net/Connectathon/  (look for the MESA test suite)
The idea is to simplify the maintenance in the future:
* update included version of gdcm
* synchronise included version and gdcm proper
* send the patches upstream


http://www.dvtk.org/
To do this, we forked a version of gdcm in github to use for integration and maintenance in iTK v4 (https://github.com/ComplexSystemsModeling/GDCM).
This fork will get all the modifications and patches from ITK, and will let us easily send them upstream.
Builds for ITK using this fork and the original gdcm (https://github.com/malaterre/GDCM) have been set up. Eventually there will be three kinds of itk/gdcm builds on the dashboard:
* ITK with included gdcm
* ITK with SYSTEM_GDCM using our fork
* ITK with SYSTEM_GDCM using gdcm proper


=== Contestants ===
Modifications should go to our fork of gdcm first, so we expect the ITK with GDCM FORK to be the greenest. Then, we should transfer those to ITK, and eventually upstream.


* http://www.na-mic.org/Wiki/index.php/CTSC:ARRA:Mockup
dev process:
* http://www.dicomserver.co.uk/
* modify code (this can be either in ITK or in GDCM FORK, depending on the modification)
* (re) install GDCM FORK on the system (as ITK does not work with a build tree of gdcm)
* check ITK with GDCM FORK (local-experimental-nightly)
* push to itk-gerrit
* check ITK proper builds
* gerrit merge


Seting up a dcm4che server:
That means, developers need to maintain both a SYSTEM GDCM FORK build and an ITK build locally.
* http://www.osirix-viewer.com/PACS.html


=== design proposal ===
= Discussions and Brainstorming =


[[ITK Release 4/DICOM/MetaData]]
== Discussions about PACS Support ==
 
* [[ITKv4_DICOM_Communications_Discussion | Initial discussions about PACS Support]]
 
== Discussion about Streaming ==
 
* Original GDCM Milestone [https://sourceforge.net/apps/trac/gdcm/milestone/%5BMM-09%5D%20%E2%80%93%20Streaming here]
* Overview (should be made JIRA tickets. Some of them are done already, to check)
** Create a gdcm.StreamImageReader
** Add support for extent to ImageCodec hierarchy
** Make JPEG2000Codec Streamable
** Make JPEGCodec Streamable
** Make RAWCodec Streamable
** Make RLECodec Streamable
** Make JPEGLSCodec Streamable
** Update CharLS for streaming capability
** Add support for BasicOffsetTable
 
* Malaterre: to the best of my knownledge they can be executed in this order. The goal being to import subportion of large file in ITK. For this one'll need to implement a new gdcm.ImageReader (I called it gdcm.StreamImageReader), I have explained the implementation details of this class in bug #53.
* Once this class is done, you will start by making the RAW codec 'streamable'. It should only read a subportion of a RAW (uncompressed) DICOM file, then you'll move on to more complex one (JPEG, J2K, RLE and JPEG-LS).
 
== Discussion about RT-Struct ==
 
* there is an existing implementation in vtk. Reading should be easier than writing, the later requiring some DICOM knowledge.
** vtkGDCMPolyDataReader [http://gdcm.sourceforge.net/html/classvtkGDCMPolyDataReader.html here]
*** The actual function needed is [https://sourceforge.net/apps/trac/gdcm/browser/trunk/Utilities/VTK/vtkGDCMPolyDataReader.cxx#L229 here] int vtkGDCMPolyDataReader::RequestData_RTStructureSetStorage(gdcm::Reader const &reader, vtkInformationVector *outputVector)
** vtkGDCMPolyDataWriter [http://gdcm.sourceforge.net/html/classvtkGDCMPolyDataWriter.html here]
** vtkRTStructSetProperties [http://gdcm.sourceforge.net/html/classvtkRTStructSetProperties.html here]
** Examples/Cxx/GenerateRTSTRUCT
* there is IJ papers to read and write RTSTRUCT
** [http://hdl.handle.net/1926/1521 write]
** [http://hdl.handle.net/10380/3132 read]
 
* Some leftover GDCM milestone [http://sourceforge.net/apps/trac/gdcm/query?group=status&milestone=%5BMM-12%5D+-+RT+support here]
 
= Roadmap =
 
* [[DICOM_Roadmap_Dec2011 | September 1, 2011 to December 31, 2011]]


= TCons =
= TCons =


* [[ITK_Release_4/DICOM/Tcon_2011_08_25|TCon 2011/August/25]], [[ITK_Release_4/DICOM/Minutes_2011_08_25| Minutes 2011_08_25]]
** See complimentary set of meeting notes [http://wiki.na-mic.org/Wiki/index.php/Events:2011-08-24-DICOM-ITK-Discussion#DICOM.2FWrapping_in_ITKv4 HERE].
* [[ITK_Release_4/DICOM/Tcon_2011_06_09|TCon 2011/June/09]], [[ITK_Release_4/DICOM/Minutes_2011_06_09| Minutes 2011_06_09]]
* [[ITK_Release_4/DICOM/Tcon_2011_05_20|TCon 2011/May/20]], [[ITK_Release_4/DICOM/Minutes_2011_05_20| Minutes 2011_05_20]]
* [[ITK_Release_4/DICOM/Tcon_2011_05_13|TCon 2011/May/13]], [[ITK_Release_4/DICOM/Minutes_2011_05_13| Minutes 2011_05_13]]
* [[ITK_Release_4/DICOM/Tcon_2011_04_22|TCon 2011/April/22]], NoMinutes
* [[ITK_Release_4/DICOM/Tcon_2011_04_15|TCon 2011/April/15]], [[ITK_Release_4/DICOM/Minutes_2011_04_15| Minutes 2011_04_15]]
* [[ITK_Release_4/DICOM/Tcon_2011_04_15|TCon 2011/April/15]], [[ITK_Release_4/DICOM/Minutes_2011_04_15| Minutes 2011_04_15]]
* [[ITK_Release_4/DICOM/Tcon_2010_10_11|TCon 2010/10/11]], [[ITK_Release_4/DICOM/Minutes_2010_10_11| Minutes 2010_10_11]]
* [[ITK_Release_4/DICOM/Tcon_2010_10_11|TCon 2010/10/11]], [[ITK_Release_4/DICOM/Minutes_2010_10_11| Minutes 2010_10_11]]

Latest revision as of 16:00, 9 December 2011

Improving DICOM Support

Goals

Improve the support for DICOM in ITK

  1. DICOM communication layer (a.k.a. PACS support, DICOM Protocol)
  2. Streaming of DICOM Objects
  3. Read and write RTStruct
  4. Type checking
  5. Minimum DICOM skeleton generation

Other requests from the ITK community

  • handling of higher order manifold as described in DICOM standard
  • handling of DICOMDIR format disk archives (navneeth)
    • Unlike a standard dicom series (located in a single directory) the DICOMDIR format spreads files across directories
    • A reader that reads the DICOMDIR file and parses appropriate files & directories is desirable

Development process

The idea is to simplify the maintenance in the future:

  • update included version of gdcm
  • synchronise included version and gdcm proper
  • send the patches upstream

To do this, we forked a version of gdcm in github to use for integration and maintenance in iTK v4 (https://github.com/ComplexSystemsModeling/GDCM). This fork will get all the modifications and patches from ITK, and will let us easily send them upstream. Builds for ITK using this fork and the original gdcm (https://github.com/malaterre/GDCM) have been set up. Eventually there will be three kinds of itk/gdcm builds on the dashboard:

  • ITK with included gdcm
  • ITK with SYSTEM_GDCM using our fork
  • ITK with SYSTEM_GDCM using gdcm proper

Modifications should go to our fork of gdcm first, so we expect the ITK with GDCM FORK to be the greenest. Then, we should transfer those to ITK, and eventually upstream.

dev process:

  • modify code (this can be either in ITK or in GDCM FORK, depending on the modification)
  • (re) install GDCM FORK on the system (as ITK does not work with a build tree of gdcm)
  • check ITK with GDCM FORK (local-experimental-nightly)
  • push to itk-gerrit
  • check ITK proper builds
  • gerrit merge

That means, developers need to maintain both a SYSTEM GDCM FORK build and an ITK build locally.

Discussions and Brainstorming

Discussions about PACS Support

Discussion about Streaming

  • Original GDCM Milestone here
  • Overview (should be made JIRA tickets. Some of them are done already, to check)
    • Create a gdcm.StreamImageReader
    • Add support for extent to ImageCodec hierarchy
    • Make JPEG2000Codec Streamable
    • Make JPEGCodec Streamable
    • Make RAWCodec Streamable
    • Make RLECodec Streamable
    • Make JPEGLSCodec Streamable
    • Update CharLS for streaming capability
    • Add support for BasicOffsetTable
  • Malaterre: to the best of my knownledge they can be executed in this order. The goal being to import subportion of large file in ITK. For this one'll need to implement a new gdcm.ImageReader (I called it gdcm.StreamImageReader), I have explained the implementation details of this class in bug #53.
  • Once this class is done, you will start by making the RAW codec 'streamable'. It should only read a subportion of a RAW (uncompressed) DICOM file, then you'll move on to more complex one (JPEG, J2K, RLE and JPEG-LS).

Discussion about RT-Struct

  • there is an existing implementation in vtk. Reading should be easier than writing, the later requiring some DICOM knowledge.
    • vtkGDCMPolyDataReader here
      • The actual function needed is here int vtkGDCMPolyDataReader::RequestData_RTStructureSetStorage(gdcm::Reader const &reader, vtkInformationVector *outputVector)
    • vtkGDCMPolyDataWriter here
    • vtkRTStructSetProperties here
    • Examples/Cxx/GenerateRTSTRUCT
  • there is IJ papers to read and write RTSTRUCT
  • Some leftover GDCM milestone here

Roadmap

TCons

Meeting