Operations: Fix Crop Coordinates ROI not updating when switching between stacks

[RasmiaKulan]

Issue Closes #3115

Description

• Added validation within set_stacks to refresh the ROI field using the current stack if the currently selected filter is Crop Coordinates, and the ROI field exists.
• Added a test for roi_field_called_with_auto_bounding_box_on_different_stacks

Developer Testing

• I have verified unit tests pass locally: python -m pytest -vs
• I have verified the test roi_field_called_with_auto_bounding_box_on_different_stacks passes locally. Tested using the debugger as well to check if the variables were returning expected results.

Acceptance Criteria and Reviewer Testing

• Unit tests pass locally: python -m pytest -vs

ROI within FoV steps:

• Load two datasets, one with a larger (x, y) axis than the other.
• Open the Crop coordinates operation and select the larger stack
• Resize the ROI to be larger than the smaller stack and click okay, but don't apply the change
• Using the stack selector, select the smaller sample
• Open up the ROI editor view
• The ROI should be within the FoV of the imagestack

Auto-crop is re-activated when switching between stacks when multiple datasets are loaded:

• Load two datasets, one with a larger (x, y) axis than the other.
• Open the Crop coordinates operation and open ROI editor - autocrop will work as expected
• Using the stack selector, select the smaller sample
• Open up the ROI editor view and confirm that the autocrop updates correctly

Documentation and Additional Notes

[coveralls]

coverage: 68.032% (+0.03%) from 67.999% — 3115-Fix_rescale_and_autocrop_in_crop_coordinates_operation into main

[JackEAllen]

Thank you for adding a fix. Functionally this works well and resolves the issue 🥳
I do have a small question about the test I'd like to get your opinion on, but otherwise happy with the change.

We can explore improving the extendability of updating fields on stack change for specific operations such is the case with this fix separately as part of #3152

[JackEAllen]

Are the stacks used in this test if we are mocking get_bounding_box?
I think that when the init_roi_field runs, it does not inspect stack.data, it just uses the mocked return values via the side_effect so you may be abel to remove them so long as you keep the distinct stack assignment and init calls by having two:

self.presenter.stack = mock.Mock()
self.presenter.init_roi_field(mock_roi_field)

where assigning one stack object to the presenter.stack and calling init_roi_field performed twice may be enough to emulate a stack change.

[JackEAllen]

The main assertion here looks good, but do we need the mock attributes here?
They are set, but don't seem to be asserted anywhere after being passed to the mock unless i've missed something.
As do_update_previews is not mocked, I wonder if this could silently succeed or fail for unrelated reasons. i'd be tempted to add it ( @mock.patch('mantidimaging.gui.windows.operations.presenter.FiltersWindowPresenter.do_update_previews')) as an additional patch and we could then simplify to:

        stack = mock.Mock(name="test_stack")
        self.presenter.set_stack(stack)

[RasmiaKulan]

@JackEAllen I still needed to keep:

with mock.patch("mantidimaging.gui.windows.operations.presenter.BlockQtSignals")

because self.view in the test is a MagicMock rather than a real Qt QObject. Without the patch, BlockQtSignals runs its real assertion:

assert isinstance(obj, QObject)

which causes the test to fail before reaching the behaviour under test.

I also still needed to specify num_images on the stack mock because set_stack() accesses self.max_preview_image_idx, which evaluates:

self.stack.num_images - 1

If num_images is left as the default auto-generated Mock, this results in:

TypeError: unsupported operand type(s) for -: 'Mock' and 'int'

Since do_update_previews is now mocked, the additional attributes like shape and num_sinograms are no longer required, so the test can still be simplified to only the minimal attributes actually used by set_stack().