Get data from private fields for Philips Allura Xper
Issue #446
resolved
As demonstrated by @LuukO there are data in the Xper RDSR that we need, but they use a private coding scheme. We should adapt rdsr.py to get them.
Comments (20)
-
-
Actually Table Height Position is taken bij the extractor as it seems to only look at code meaning and not to code designator or the code itself (a bit tricky, but in this case OK). So I think the only adaptation for the import part to get all data needed by openskin is to add in _irradiationeventxraysourcedata(dataset,event):
elif cont.ConceptNameCodeSequence[0].CodeMeaning == 'Number of Frames': source.number_of_pulses = cont.MeasuredValueSequence[0].NumericValueBut I wonder if that could possibly collide with the DICOM controlled code meaning "Number of Frames", code value 121140 as I don't see the code designator is used(?)
-
reporter
I think matching also against the coding scheme addresses your last point does it @LuukO?
-
Yes
-
reporter
Refs:
#446Solves the missing Number of Pulses for fluoroscopic and rotational acquisitions on Philips Allura XPer systems.
Doesn't solve the missing end angles for rotational acquisitions in the RDSR This seems to be a more difficult issue as there doesn't seem to be a one to one relation between number of pulses and acquisition angle.
→ <<cset a615eeaaef38>>
-
reporter
-
reporter
Do you know the plane that the shutter positions are recorded at? It would be good to record the data provided, in new fields if necessary, but there are three fields that we should attempt to populate:
- collimated_field_area (Collimated field area at image receptor. Area for compatibility with IEC 60601-2-43)
- collimated_field_height (Distance between the collimator blades in pixel column direction as projected at the detector plane)
- collimated_field_width (Distance between the collimator blades in pixel row direction as projected at the detector plane)
I don't know if the blades are ever asymmetric, in which case we should definitely add fields to record the values. But maybe we should either way.
Thoughts @LuukO?
-
If I read the DICOM Conformance statement correctly, the shutter positions are in millimeters from the centerpoint and defined at one meter. So the above parameters can be calculated by adding the shutter positions and correcting for the actual source to detector distance (which is available in the RDSR). I suppose right + left shutter position will result in width and bottom + top shutter position will be height.
Agree?
-
reporter
I do agree.
I'm thinking about whether we should record the bottom/right/top/left position at 1 m anyway (in new fields), and either calculate and populate the area/height/width at the detector on import, or have a function in the model to calculate it on demand like we do for DAP units.
However I don't think the model function would work as the collimation fields are in
IrradEventXRaySourceDatawhereas the source to detector distance is inDoseRelatedDistanceMeasurementswhich comes offIrradEventXRayMechanicalData.So maybe we should record the fields as presented, and do the calculation on input too?
What do you think @LuukO? Do you have any opinions @jacole or @dplatten?
-
Refs
#446Get data from private fields for Philips Allura XperExtracting rdsr-information * If table longitudinal position is not available use privately defined beam longitudianl position instead * If table lateral position is not available use privately defined beam lateral position instead * Remark: due to the fact that we don't check for the Coding Scheme Designator for Philips Xper data we get the privately defined "Table Height Position" instead of the DICOM defined one
Calculating skin-map * If end angle for rotational acquisition is not defined and the start Angle is -120 assume a Philips XPer propeller mode scan * If end angle for rotational acquisition is not defined and the start Angle is -45 assume a Philips XPer roll mode scan (needs to be checked)
After these changes skin map does have some result, but only at the very top of the phantom (I've seen this also for Siemens data, so probably another issue)
→ <<cset beb14476d8f3>>
-
Refs
#446Imports Philips private shutter positions to calculate collimated field parameters.
Still on todo list: - Try to verify full rotation angle in roll mode - Try to verify if Philips left-right direction corresponds to DICOM width and Philips top-bottom direction to DICOM height
→ <<cset a56fce957352>>
-
Refs
#446- Removed extraction of privately defined Beam Position as it doesn't give usefull information (newer systems do export table position)
- Corrected a calculation error for collimated field height and width
→ <<cset ac5b50a36fae>>
-
Refs
#446Get data from private fields for Philips Allura XperExtracting rdsr-information * If table longitudinal position is not available use privately defined beam longitudianl position instead * If table lateral position is not available use privately defined beam lateral position instead * Remark: due to the fact that we don't check for the Coding Scheme Designator for Philips Xper data we get the privately defined "Table Height Position" instead of the DICOM defined one
Calculating skin-map * If end angle for rotational acquisition is not defined and the start Angle is -120 assume a Philips XPer propeller mode scan * If end angle for rotational acquisition is not defined and the start Angle is -45 assume a Philips XPer roll mode scan (needs to be checked)
After these changes skin map does have some result, but only at the very top of the phantom (I've seen this also for Siemens data, so probably another issue)
→ <<cset 5f3f1ad6048e>>
-
Refs
#446Imports Philips private shutter positions to calculate collimated field parameters.
Still on todo list: - Try to verify full rotation angle in roll mode - Try to verify if Philips left-right direction corresponds to DICOM width and Philips top-bottom direction to DICOM height
→ <<cset 375e443d7526>>
-
reporter
Hi @LuukO. Where are you with this task? Do you think it is ready to merge in for 0.8.0, or should it be bumped to the following release?
-
reporter
-
assigned issue to
Luuk
-
assigned issue to
-
I think it can be merged, but I'll review the current code first (and do some additional tests).
Btw. The table position as well as the Philips privately defined beam position determine together the position of the beam with respect to the patient. So for skindose to work with Philips you need both. Is this not the case for Siemens (Do you only have table position and no beam position? And what happens if the tube moves and the table position remains the same physical position? Does table position change in the RDSR? I think we need to open another issue for solving Philips geometry issues with respect to skindose.
-
reporter
Adding test file for @LuukO's PR. Refs
#446→ <<cset bfa483b0fbca>>
-
reporter
Adding pylint comment to prevent non-used Class issue. Refs
#446→ <<cset 011c649afec3>>
-
reporter
- changed status to resolved
Merged in Issue446PrivateFieldsPhilipsAlluraXper (pull request #153)
Issue446PrivateFieldsPhilipsAlluraXper
Fixes
#446→ <<cset 893b2e8affb6>>
- Log in to comment
Some additional information. I looked at the parameters that Jonathan Cole uses for the Siemens data, see figure below (could not copy it as table). Only a few of these items do have a private coding scheme. For rotational acquisitions the end angle is missing. In propellor mode it covers 240 degrees, in roll mode it covers 180 degrees. The mode can probably be derived from the number of frames (I must have the number of frames in the different acquisition modes somewhere, I'll update this issue if I found it)
According to Dicom Conformance statement:"Actual shutter distance from centerpoint of collimator specified in the plane at 1 meter. Unit: mm. End of run value is used."