ITK/Release 4/DICOM: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
Line 18: Line 18:
* Unlike a standard dicom series (located in a single directory) the DICOMDIR format spreads files across directories
* 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
* 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 GDCM FORK
* check GDCM FORK (local)
* 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 and Brainstorming =

Revision as of 09:27, 6 August 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
  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 GDCM FORK
  • check GDCM FORK (local)
  • 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

  • JPEG2000

Discussion about RT-Struct

TCons

Meeting

Retrieved from "https://public.kitware.com/Wiki/index.php?title=ITK/Release_4/DICOM&oldid=41973"