dcmjs-org / dcmjs

Javascript implementation of DICOM manipulation
https://dcmjs.netlify.com/
MIT License
300 stars 112 forks source link

Slice Thickness Field is absent in created SEGs. #29

Closed JamesAPetts closed 5 years ago

JamesAPetts commented 5 years ago

Tag – 0x00180050DICOM Standard part 3 (IODs) - C.7.6.16.2.1 Pixel Measures Macro:

Slice Thickness is type 1C. Required if SOP Class UID is Segmentation Storage ("1.2.840.10008.5.1.4.1.1.66.4") and Frame of Reference UID (0020,0052) is present.

For SEGs generated with dcmjs The FoR field is present, but the required Slice Thickness field is absent.

Apologies for any brevity, writing this here for further notice!

malaterre commented 5 years ago

That's accurate:

fedorov commented 5 years ago

Mandatory pointer to the discussion involving David Clunie on a dcmqi issue that triggered the correction proposal "CP 1426 Correct condition in Pixel Measures, Plane Position and Orientation Functional Groups for Segmentation" (ftp://medical.nema.org/medical/dicom/final/cp1426_ft.pdf) adding this attribute: https://github.com/QIICR/dcmqi/pull/89

Note that it was not present in the original version of the Segmentation IOD (and google often gives results that point to DICOM version 2013!) so it is not impossible to get objects that are invalid now, but were valid in an older version of the standard, or at the time they were created before 2015 ...

fedorov commented 5 years ago

Correction - that was not the discussion that triggered the CP, must have been something else, but the referenced discussion might still be important to consider as you are implementing and will face eventually corner cases where it is not obvious what to do.

JamesAPetts commented 5 years ago

So as far as I understand, Slice Thickness in the Image Plane module is type 2, i.e. we can only assume its present and empty. But Slice Thickness in SEG's Pixel Measures Sequence is type 1C (with the always satisfied condition of being a SEG SOPClass... so type 1).

This is a bit of a problem, as we need to fill the field with something. You can't derive the Slice Thickness from other parameter's if its empty.

It seems like you can't make a standard compliant SEG for single-frame images where the Slice Thickness is missing (even though these are valid images)?

JamesAPetts commented 5 years ago

After some discussion in the dcmjs slack channel, we've come to the conclusion that the only logical thing to do if Slice Thickness is missing in the base images is to fill it in with the closest calculable quantity, being the distance between slices.

In reality the Slice Thickness of the acquired images could be less than, equal to, or greater than the distance between slices, but the original acquisition value is non-calculable should the field not be present. The distance between slices should at least be the same order of the 'true' value, and its the best you can do.

P.S. I'll make this change.

JamesAPetts commented 5 years ago

Fixed generation of the SliceThickness field when making the intermediate derived multiframe from single frames. This has been pushed to master.