There are a couple of concerns with the current Op Transformation system:

• It is not very extensible. We are not really able to define multiple ways to perform a transformation, which could be useful. Take, for example, the Function->Computer transformation, which requires a create Op to create the output to pass to the Computer. There could be multiple viable ways to create that input based on the arguments to the op, however we do not support having two parameters.
• Making a new transformer is complicated and the current transformation system is confusing and cluttered.
• There is no priority hierarchy for Op Transformations. We do ensure that the smallest possible chain of transformations is used, however there is no way to say that one transformation should be used over another.

For these reasons I propose we revamp the transformation system into a collection of transformation Ops. These ops will all be named adapt (so that we do not confuse this namespace with the transform namespace of imagej-ops), and must all be Functions outputting the requested op and taking some other Op type as input. This will allow:

• Extensibility: if someone wants to add a new transformation it is as easy as adding a new Op
• Priority: Ops already have priority, so it is easy to sort the available adapt Ops by priority.
• Op chaining: Transformations can have an OpDependency
• Organization