ImageOrientationPatient and ImageType issues for creating stacks.

[davecg]

There were two issues which were preventing many exported DICOM folders from stacking properly for me with your package.

1. For whatever reason, there is often a small amount of variation in ImageOrientationPatient in the least significant digits (usually < 1e-6) which would prevent images from the same series from stacking properly. I had to change stack_and_group to round this field to get stacking to work.

2. Some scanners export derived and original images which are otherwise mostly indistinguishable by DICOM tags, which would cause stacking errors. This could be fixed by allowing lists to be included in keys for grouping (would need to be converted to a tuple when creating the key for the dict) and adding ImageType to the default group keys. (Adding ImageOrientationPatient to the group keys is also helpful for splitting survey series into the three appropriate stacks, similar in behavior to dcm2nii.)

Adding support for lists in keys should not be too hard (just requires tuple conversion for the list in the key).

I'm not enough of a DICOM expert to know how much ImageOrientationPatient can be safely rounded in general, but adding an option to round that field would make it easier to fix a lot of errors.

[moloney]

Hi,

Thanks for this report and sorry for my delayed response.

The ability to test that floating point numbers are close rather than exactly equal when "grouping" the files has been there for a while. In fact that should be the default for ImageOrientationPatient (see the close_tests argument to the parse_and_group function). However the tolerance is currently hardcoded at 5e-5, so that might have been insufficient for your data? I guess I should make that tolerance configurable.

I also agree that it would be helpful if elements with list values could be used in group_by. I think it is bad practice to stick the derived data into the same series as the original data (they should be in their own series with a unique SeriesInstanceUID) but that doesn't mean we shouldn't make it easier to deal with this data.