Handle Dataset parameters gracefully about imagej-ops

[ctrueden]

See also imagej/ImageJ#60

[dietzc]

In general: The low-level operations really shouldn't work on Img/ImgPlus/... they should work on IterableInterval/RandomAccessibleInterval. The higher-level ops (e.g. Commands) should then be composed of several low-level ops and may base on Img/ImgPlus/Labeling.

[ctrueden]

@dietzc: In some cases, yeah. But an Img is an IterableInterval as well as a RandomAccessibleInterval so of course you can pass an Img to any op with an input typed by those interfaces. This is good. The problem documented by this ticket is that ImageJ2's Dataset is actually not an Img or an ImgPlus nor even an IterableInterval. I mean, conceptually it is—it just doesn't implement those interfaces. Rather, it has an ImgPlus which it wraps (i.e., composition rather than inheritance). But OPS relies on types using the inheritance pattern. For that reason (as well as lots of other reasons), it makes sense for Dataset to implement the relevant interfaces here so it can be passed to an op without a clunky dataset.getImgPlus() or dataset.getImgPlus().getImg() unwrapping step.

[dietzc]

@ctrueden: correct. this way it makes sense (let dataset implement XY). wouldn't make sense to have dedicated ops for dataset.

[dscho]

Yes, thanks for clarifying @ctrueden! @dietzc I only wanted to document the problem rather than the solution so that we know what to test after fixing it.

[ctrueden]

This issue will be largely addressed by imagej/imagej-common#46.

[ctrueden]

Closing, since it will be taken care of by the data model update of imagej/imagej-common#46.