ACR geometric accuracy potentially using the wrong slices

[sophie22]

Describe the bug Based on the documentation and earlier version of the geometric accuracy script, the get_geometric_accuracy_slice1 and get_geometric_accuracy_slice5 functions should create a mask and find the centre based on slice 1 and 5 respectively. However, in the current implementation (since the refactoring) the mask and centre is created for slice 7, and distances are measured on slice 7 rather than 1 and 5.

Previous code: https://github.com/GSTT-CSC/hazen/blob/3ee1bb6b82385daf79d4b786a9660c8d805e11ad/hazenlib/tasks/acr_geometric_accuracy.py#L170 Current code: https://github.com/GSTT-CSC/hazen/blob/main/hazenlib/tasks/acr_geometric_accuracy.py#L116

Expected behaviour Please confirm whether mask and length calculation should be performed on slice 7 and overlayed on slice 1 and 5 for the report images, or calculated separately for slices 1 and 5.

Additional context Add any other context about the problem here.

[YassineAzma]

This is a bug. It will only have impact on the results if there is any form of tilt between slices due to a positioning error.

[sophie22]

Thank you for your prompt reply. Is it simply a matter of replacing slice 7 with 1 and 5 to create the mask from?

[YassineAzma]

Thank you for your prompt reply. Is it simply a matter of replacing slice 7 with 1 and 5 to create the mask from?

Yes, I think I ended up defaulting to slice 7 by mistake when refactoring because I had the idea that a flat image would be far easier to mask than the busier slices 1 and 5.

[sophie22]

Is the centre expected to be the same across all slices? I'm getting slightly different values especially for the vertical distance in the unit tests. Is there an alternative method for calculating the 'true' values to set in the unit tests?

[YassineAzma]

Is the centre expected to be the same across all slices? I'm getting slightly different values especially for the vertical distance in the unit tests. Is there an alternative method for calculating the 'true' values to set in the unit tests?

How much is the centre changing? 1 or 2 pixels in either direction? How much are the length values changing by? I wouldn't be too concerned if it's less than 1mm and remains within tolerance.

When it comes to a true value for the unit test, that is a very challenging thing to define I think. The true value would be that as measured by a person, but that in itself is subject to variation due to the fact that most DICOM viewers allow you to achieve "super-resolution" when using a calliper tool, so you end up with horizontal and vertical lengths that are not an integer multiple of the pixel dimensions, but to a much finer precision. This makes the variance due to measurement technique, such as choice of windowing and manual dexterity hard to concretely define. For this reason, I've been using the output of the Hazen task itself as its own ground truth for the unit test. My understanding is that the unit tests are there to ensure accuracy of Hazen tasks across different Python environments, not to act as a validation of the output itself. That type of assessment should be done separately and against manual measurement. I have this data for my old MATLAB code, but not for the Python code.

Ideally, I would have done the masking, and subsequent calculation of the centre of the object, by using a histogram to define a noise region of signals and a phantom region of signals. I'd then then mask so that all values outside the phantom region are 0, but this wouldn't work with the spine coil data (massive intensity gradient across the phantom) that Elizabeth sent me related to a previous issue. If I have assurance that the ACR phantom will be used with just the head coil (as the guidelines describe) or the integrated body coil (a uniform receiver), I could happily make these improvements.

In short, the geometric accuracy task needs improvement. I have some ideas, but my time is incredibly limited by my PhD studies.

[sophie22]

resolved by #399