Marvin Albert

> I am working on a dask-image implementation of ndimage.rotate. The functionality is there and I am now trying to get the tests up and running similar to affine_transform. Cool...

Wrote a response in the PR https://github.com/dask/dask-image/pull/213!

Hi @martinschorb, that's a great idea :) I also think it makes sense to make more `interpolation` functions available here! Here are some thoughts: I quickly went through https://github.com/scipy/scipy/blob/master/scipy/ndimage/interpolation.py and...

Hi @jmontoyam, you're completely right that `dask_image` shouldn't be significantly slower than the "pure dask" example you provide. Cool that you provide code and timings! I had a look at...

> why does dask-image use pims for loading the images?...why not use, for instance, a standard delayed skimage.io.imread? @jmontoyam That's a good question. Regarding the `delayed` part of your question,...

> From @jakirkham in #194 (comment) One could create a hybrid solution. Namely use PIMS just to find shape and dtype info and then use skimage.io.imread or similar to read...

Hey @VolkerH :) Definitely `affine_transform` can be used for stitching transformed values! Hmm I was thinking about whether it would make sense to be able to provide an output `dask.array`...

> Report benchmark results for dask_image.imread.imread() and dask.array.image.imread() (for an apples to apples comparison, you might need to explictly pass pims.open as a keyword argument to dask.array.image.imread()) Wanted to link...

> Presumably we could add this behaviour to dask.array.image if that's useful. Definitely. Wouldn't currently think it's too critical though.

I'd also think that "stage 2" is not easy to solve optimally. For the case of stage 1 (which should cover most use cases for now): The problem I'd see...