Use of the Ops framework centers on a process of matching Op requests are to function implementations based on the parameters provided. The easiest way to make these queries is to use the `OpBuilder` syntax, which follows the [builder pattern](https://refactoring.guru/design-patterns/builder) to assemble the required components of an Op matching request from a particular `OpEnvironment`.

In this page we start after having [identified a Gaussian Blur Op](SearchingForOps) that we would like to use. We assume we already have created an `OpEnvironment`, named `ops`, as well as the input image to blur, and a pre-allocated output image for the result - `inImage` and `outImage`, respectively.

**Note:** we are incrementally building one line of code in this example. Running an intermediate step simply returns an appropriate builder that knows what has been set so far, and which step is next. If you're following along in an IDE or script editor, the code you actually *run* would be the last step, once our builder call is fully constructed.

From the `OpEnvironment`, an `OpBuilder` chain is initialized with the `OpEnvironment.op(String)` method, which describes the name of the Op that we ultimately want to call:

For this Gaussian blur, we have two inputs: `inImage` is the image we want to blur, and a `double` as our sigma parameter:

After specifying inputs, we provide preallocated outputs using the `.output()` method.

For our Gaussian blur, we will pass our output image `outImage` as a buffer for the result:

With all of our desired Op's inputs and outputs now specified, we can run it with the `.compute()` method.

In the call to `compute()`, the `OpEnvironment` will use the components of the `OpBuilder` syntax to:

* Match an Op based on the name provided, as well as the types of the provided input and output `Object`s

* Execute the Op on the provided input and output `Object`s.

Calling our Gaussian blur as a `Computer` above is great when we have pre-allocated output, but for other scenarios we can request Ops as `Functions` or `InPlaces`.

`Functions` are used when we want to *create* the final output, indicated by ending the builder with `.apply()`:

`InPlaces` are used when we want to destructively modify one of the existing inputs (which is explicitly forbidden by `Computers`). We indicate this by the `mutate#()` method, where the `#` corresponds to the *parameter index* that will be modified:

A key takeaway from this section is that how you **request** the Op does not necessarily need to match how the Op is **implemented**. `Functions` and `Computers` should be largely interchangeable. For the 1.0.0 release we do not have the necessary converters to go between `InPlaces` and the other paradigms, but it is on our [development roadmap](https://github.com/scijava/scijava/issues/47)!

When you want to call an Op many times on different inputs, the `OpBuilder` syntax can be modified to return the *Op* itself, instead of performing the computation. Instead of calling the `.compute()` function at the end of our `OpBuilder` chain, we can use the `.computer()` method (or `.inplace()` or `.function()`, as appropriate) to get back the matched Op, which can then be reused via its `.compute()` method (or `.apply()`, `.mutate#()`):

If you *know* that your `Img` will always contain unsigned byte values, for example, define your variable as an `Img<UnsignedByteType>` rather than using `Img<?>`.