ripytide

On the other hand standardizing image ops into traits does make it possible to do more advanced usage in generic scenarios such as taking any image ops as an input...

I'm not sure I understand your last three comments @cospectrum. Reading and writing to the same memory does not violate the borrow checker? From what I gather this issue is...

Well if it's about reducing allocations by reusing buffers then variant 2. and 3. are exactly what you'd want as they let you supply your own already allocated re-usable memory...

> This is just an example. We already have a convention to implement _mut functions (in place or with an output buffer). So I don't see how owned brings anything...

If you grep for `let mut out = image.clone()` there are about 15 places where we forward the implementation to the `_mut()` variants which is pretty sub-optimal when we could...

No I think we should replace `func(&I) -> I` with `func(&I, &mut I)` which is a matter of performance not style since non-in-place functions can be much faster than in-place...

I also think we should get rid of shallow functions like this: ```rust pub fn open(image: &GrayImage, norm: Norm, k: u8) -> GrayImage { let mut out = image.clone(); open_mut(&mut...

This also applies to `equalize_histogram_mut()` as well.

How about an alternative approach for stabilization where `itertools` renames any methods that the standard library promises to stabilize, like `Itertools::intersperse()` to `Itertools::it_intersperse()`. Then after this is released for a...

Then we could then add clippy lints for these renamed methods to encourage people to switch back to the stabilized `std` versions.