Page MenuHomePhabricator
Files F514

dicom-tests.txt
Public
Actions

Authored By
maleike
Mar 22 2011, 3:29 PM
Size
2 KB
Referenced Files
None
Subscribers
None

dicom-tests.txt
View Options

Tests for DICOM image loading
=============================
Necessary data
--------------
- around 20 images, at least representing three groups of sizes and spacings.
- fully anonymized (persons, institutions, addresses, manufacturers)
Test design
-----------
1. A very simple commandline application mitkDICOMDump should be created,
which loads a given (commandline arg) set of DICOM images into mitk::Images
and then dumps out the generated image geometries in a human-readable text
format.
The application could take a couple of arguments to determine in which way
DicomSeriesReader is used.
2. A second commandline application should be able to determine if two
geometries (as dumped by mitkDICOMDump) are equivalent. This is a simple
diff in the easiest case. However, it should allow to specifiy allowed
tolerances, e.g. for float comparisions or to perform only a number of
specified tests.
3. CMake functions should be created to easily create calls to above
applications for changing input combinations. This way we can easily create
a whole number of slightly differing tests without typing too much.
4. Test data must be grouped into test cases. Expected results must be
documented in form of geometry dumps (see 2.) and become part of the CMake
function calls.
Test cases
----------
To simplify notation of test data a little, I'll use a notation of SnZnTnNn where n is replaced by numbers or 'x' (if not relevant)
Sn = Slice n (world position n)
Zn = Size group n (size/spacing parameters groups n)
Tn = Time step n (if relevant)
Nn = Slice number (DICOM tag)
After loading, verify
- number of created mitk::Images
- origin of each slice
- right/down vectors of each slice
- number of pixel rows/columns (uncritical until now, but should be verified)
A minimum number of test cases is described below. More complicated cases can be constructed when errors or potential problems in
the implementation become apparent
Simplest case
- - - - - -
S1Z1TxNx
S2Z1TxNx
S3Z1TxNx
Simple gap case
- - - - - -
S1Z1TxNx
S2Z1TxNx
S4Z1TxNx
S5Z1TxNx
Gap, then different spacing case
- - - - - -
S1Z1TxNx
S2Z1TxNx
S3Z1TxNx
S4Z1TxNx
S5Z1TxNx
S6.1Z1TxNx
S7.1Z1TxNx
S8.1Z1TxNx
Unclear differnt spacing case
- - - - - -
S1Z1TxNx
S2Z1TxNx
S3Z1TxNx
S4Z1TxNx
S5Z1TxNx
S6Z1TxNx (does this belong to the first or second part? Definition needed)
S7.1Z1TxNx
S8.2Z1TxNx
S9.3Z1TxNx
Interleaved case
- - - - - -
S1Z1TxNx
S1.3Z1TxNx
S2Z1TxNx
S2.3Z1TxNx
S3Z1TxNx
S3.3Z1TxNx
S4Z1TxNx
S5Z1TxNx

File Metadata

Mime Type
text/plain
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
492
Default Alt Text
dicom-tests.txt (2 KB)

Event Timeline

maleike added a comment.Mar 22 2011, 3:29 PM

Description of how tests could look like

MITK · MIC · IMSY · DKFZ