ACR slice ordering

[sophie22]

This PR includes important changes to how the ACR phantom image slices are being processed prior to specific task measurements.

An instance of the ACRObject class now has the following attributes:

• dx and dy corresponding to the PixelSpacing values from the DICOM header (in x and y directions)
• slice_stack is a list of the input DICOMs, ordered by position (from ImageOrientationPatient) and ordered by phantom orientation (see below)
• there is no LR flipping of pixel values

The following methods are available for ACRobjects:

• sort_dcms: orders DICOMs based on the changing coordinate according to acquisition orientation
• order_phantom_slices: orders DICOMs based on phantom orientation - first slice is expected to have a circle while the last one is expected not to have one
• find_phantom_centre: locate the coordinates of the phantom (circle) in the image and also return its radius
• get_mask_image: pixel array with values above given threshold from input image
• circular_mask: list of coordinate matrices from coordinate vectors with given centre and radius
• determine_rotation: determines rotation angle of phantom images
• rotate_images: rotate the pixel array of all phantom slices by a defined angle
• `rotate_point': calculate new coordinates of a point (pixel) after rotation by a defined angle
• measure_orthogonal_lengths and find_n_highest_peaks are specific to task measurements

Other important changes:

In task-specific classes, the phantom centre is now being calculated based on the specific slice, not taken from the flood field slice as previously.
Resolution is now being used from the ACRObject dx, dy attributes rather than being accessed from the DICOM header values.
determine_orientation and detect_circle are new functions moved to the utilities to make them more widely reusable.
scipy version was updated to make use of a predefined function rather than specifying our own.
Unit tests were simplified for ACR tasks and new tests were added for ACRObject for a more comprehensive coverage of this class.
Some test values had to be updated to account for different rounding methods, but all are within tolerance as per ACR guidelines.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
hazenlib
ACRObject.py	107	10	91%	77–83, 119, 134–137, 191–194
HazenTask.py	28	3	89%	67–71
__init__.py	56	15	73%	102, 135–144, 146–155, 157–159, 176–180, 184
exceptions.py	21	5	76%	19–23, 42
utils.py	222	59	73%	77, 81, 102, 115, 148, 163–176, 195, 202–209, 226–228, 243–247, 263–267, 287, 292, 303, 375–376, 378–379, 384–397, 450, 453, 461–466, 469, 524, 533, 562
hazenlib/tasks
acr_geometric_accuracy.py	111	58	48%	53–100, 124–239
acr_ghosting.py	106	42	60%	42–58, 104–107, 154–157, 201–283
acr_slice_position.py	136	48	65%	56–80, 281–348
acr_slice_thickness.py	135	60	56%	45–64, 235–319
acr_snr.py	132	57	57%	60–111, 131, 227–242, 287–305, 355–380
acr_spatial_resolution.py	206	68	67%	70–100, 187, 285, 302–313, 460–539
acr_uniformity.py	80	32	60%	43–60, 150–202
ghosting.py	149	51	66%	28–47, 67, 171–172, 179, 196–197, 252–256, 271–275, 346–387
relaxometry.py	290	89	69%	210–211, 213, 226–231, 238–246, 277–326, 375, 409–431, 609, 655–659, 726, 811–833, 851–866
slice_position.py	124	40	68%	30, 43–71, 129–130, 157, 273, 283–306
slice_width.py	351	53	85%	44–48, 52, 123, 188–213, 383, 555, 560–561, 567, 572, 648–649, 1020–1084
snr.py	173	69	60%	45–48, 87, 103–113, 206–225, 237–247, 287–302, 330–340, 345–361, 399–415, 428–434, 477–495
snr_map.py	107	1	99%	159
spatial_resolution.py	246	45	82%	50–54, 58, 90, 191, 213, 294, 460–503
uniformity.py	80	19	76%	59–63, 67, 118–119, 126, 175–205
TOTAL	2885	824	71%

Tests	Skipped	Failures	Errors	Time
208	0 💤	0 ❌	0 🔥	2m 20s ⏱️

[sophie22]

• nothing works for Sagittal due to a 90 degree anticlockwise rotation.
• all tasks (and especially their report images) for all orientation need to be checked - things like correctly shifting the centre coordinates, sampling from relevant regions, etc
• report image generation should be split and moved to their respective functions calculating the values being represented

[sophie22]

all tests are failing as these haven't been updated to use the new functions yet

[sophie22]

expected values were updated following discussion with Molly, having concluded that differences are due to rounding and are well within the tolerances for their respective measurement as per ACR guidelines.

[tomaroberts]

@sophie22 – I think this is fine. Bit tricky to tell the extent of the changes, but if the tests are passing, then that's okay.

One comment about the phantom_orientation function. Ultimately, the user should configure the phantom in an orientation compliant with the guidelines, but if this helps iron out some issues, then go ahead.