Get data from private fields for Philips Allura Xper

Issue #446 resolved
Ed McDonagh
created an issue

As demonstrated by @Luuk 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.

Refs google groups message

Comments (20)

  1. Luuk

    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)

    test.png
    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."

  2. Luuk

    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].NumericValue
    

    But 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(?)

  3. Ed McDonagh reporter

    Refs: #446

    Solves 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>>

  4. Ed McDonagh 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 @Luuk?

  5. Luuk

    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?

  6. Ed McDonagh 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 IrradEventXRaySourceData whereas the source to detector distance is in DoseRelatedDistanceMeasurements which comes off IrradEventXRayMechanicalData.

    So maybe we should record the fields as presented, and do the calculation on input too?

    What do you think @Luuk? Do you have any opinions @Jonathan Cole or @David Platten?

  7. Luuk

    Refs #446 Get data from private fields for Philips Allura Xper

    Extracting 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>>

  8. Luuk

    Refs #446

    Imports 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>>

  9. Luuk

    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>>

  10. Luuk

    Refs #446 Get data from private fields for Philips Allura Xper

    Extracting 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>>

  11. Luuk

    Refs #446

    Imports 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>>

  12. Luuk

    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.

  13. Log in to comment