Computer ops do not prevent user from selecting out == in

[ctrueden]

When running a computer op, napari-imagej does not issue an error message when specifying the same layer for both input and output. But some computer ops fail when attempting to use the same image for input and output. Example steps to reproduce:

1. Launch napari-imagej via Plugins → ImageJ2 (napari-imagej)
2. Open an image via File → Open File(s)... – I used NESb_C2_TP1.tiff from NESb.zip of the SCIFIO sample images
3. Type gauss into the napari-imagej search bar
4. Expand the Ops (13) tree branch
5. Double click filter.gauss(img "out", img "in", double[] "sigmas") -> (img "out")
6. Note that the "out" and "in" point to the same layer

[gselzer]

It seems like that would be pretty tricky to implement in practice.

Right now, napari-imagej delegates completely to magicgui to make the layer selector boxes. As such, any solution would require overriding the layer ComboBoxes.

I think that if we did this we'd need to add an I/O indicator field to each selector. Then, for each layer, we'd have to pass the Layer choices function to each ComboBox that is created by a module. More specifically, it should probably be a Callable object that knows whether it is an input or output ComboBox, along with a callback mechanism that other ComboBoxes can use to identify the Layers that are off-limits.

While I bet it's possible, it certainly hurts my brain to think about. Do you envision an easier way to do this, @ctrueden?

[ctrueden]

Yeah, we can just do post-dismissal validation, similar to how we handle the settings dialog. If it's a computer op and the in == out, display an error dialog and do not proceed with the execution.

[gselzer]

Yeah, we can just do post-dismissal validation, similar to how we handle the settings dialog. If it's a computer op and the in == out, display an error dialog and do not proceed with the execution.

You know @ctrueden, since this is a problem outside of napari-imagej, maybe this validation should be added to the OpListingModule upstream? Then it would be fixed everywhere...

EDIT: Although, it may be tough to ensure that the same napari layer isn't both input and output within Ops. I don't know whether scyjava returns the same UnsafeImg object for multiple calls to ij.py.to_java(<py image>), or if those UnsafeImgs would be considered equal if they aren't the same object.