Page MenuHomePhabricator

Sorting method in DicomSeriesReader makes wrong interpretation of image position attribute
Closed, ResolvedPublic

Assigned To
None
Authored By
santos
Jan 12 2011, 2:29 PM
Referenced Files
F654: patch-6506
Jan 30 2011, 7:12 PM
F653: DicomSeriesReader_sorting.patch
Jan 28 2011, 2:45 PM
F652: dicom_sorting.patch
Jan 17 2011, 10:48 AM

Description

The image sorting method in DicomSeriesReader tests if the image position of an image is smaller than the position of another image using the "<" operator, which in turn performs a lexicographic comparison of the attribute.

The problem is that I assumed that the image position was a single value, which is not true: image position is a point.

As the direction of the axes is defined fully by the patient's orientation (see http://www.dclunie.com/medical-image-faq/html/part2.html), the correct behavior would be to use the z coordinate if the image was acquired in the axial axis, the x coordinate if it was acquired in the sagital axis, and the y coordinate if the acquisition was in the coronal axis.

Event Timeline

According to David Clunie (http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/4568635e083a3fba/e2a8ceec23032601?lnk=gst&q=sort+slices), the best way to sort is NOT the one I mentioned before, but to "sort along a vector normal to the plane of the image (determined from Image Orientation (Patient)) by the value of Image Position (Patient) projected onto that vector".

Fix for the bug.

[SVN revision 28935]
FIX (#6506): change sorting logic and interface of DicomSeriesReader (mostly Thiago's work)

[SVN revision 28940]
FIX (#6506): disable loading of private and sequence tags for means of sorting (not used anyway)

Just commited changes by Thiago and me. Open issues:

  • GDCMSeriesFilenames does NOT seem to care for SeriesDetails. Tiago volunteered to investigate this. Should be incorrect interface usage / expectations ..
  • we agreed that slice sorting should prioritize ImagePositionPatient over AcquisitionTime. Reason for this is that ImagePositionPatient is mandatory and gives a consistent spatial sorting. Acquisition time is optional only (though common) and would give different results depending on whether the scanner is scanning head-to-feet or feet-to-head

In order to load 4D datasets, both "sort" and "check_4d" parameters must be enabled.

I put some effort into fixing both remaining issues:

  1. GDCMSeriesFilenames seems to have issues with GDCM 2. After talking to Klaus, the easiest solution seemed to implement sorting of images into groups of identical (orientation, size, spacing, ..) on our own.
  1. Thiago provided a patch for a different sorting logic, which is already used in this new patch. Additionally, the loading is adapted to load 3D+t after this sorting.

While this works nicely with ExtApp, I'd like to put a little time into considering the interface and class structure again. It all looks a bit messy now and should at least get some documentation on how to use it.

[SVN revision 29381]
FIX (#6506): sort by position first, then by acquisition time; adapt 3D+t loading to this change; sort files into groups of similar image properties

[SVN revision 29382]
FIX (#6506): clean up code and enhance documentation on usage

[SVN revision 29383]
STYLE (#6506): change typos and simplify bloated code

[SVN revision 29384]
STYLE (#6506): integrate Philips special case with other loading paths

[SVN revision 29388]
COMP (#6506): make code compile with GDCM < 2

[SVN revision 29395]
COMP (#6506): avoid std::map::at(), which does not seem to exist enough

Seems to compile on all platforms now (Windows7, XP, Suse)