We should add an option for image operations to switch between mutating the original image and returning a new image while leaving the source image untouched.
Maybe out overloads?
No I don't think out based overlaod that would be the best api for this.
I was thinking it would actually require a significant API redesign to make it work intuitively.
I was more thinking if we changed our api to be more like this:
``c#
// could easily be extension methods instead of instance methods
// all they do in instantiate a newImageOperations
// then call Apply/Build etc on it at before returning.
class IImage
{
// applies the configured ImageOperations
void Mutate(Action
// generates a new destination Image<TPixel> and then applies the
// configured ImageOperations<TPixel> to that image. (trying to be
// clever around things like resize to prevent unnecessary pixel coping)
Image<TPixel> Generate(Action<ImageOperations<TPixel>> action);
}
this would make operations look more like this:
```c#
image.Mutate(ctx => ctx.Resize(...).Rotate(...)); // returning void so chaining only happens inside Mutate
image.Save(...);
or
c#
using(var image2 = image.Generate(ctx => ctx.Resize(...).Rotate(...)))
{
image2.Save(...); // altered version
}
image.Save(...); // orig image unalterd
ImageOperations<TPixel> would cue up the operations and apply them all before Mutate/Generate returns but not immediately on calling the method. (this could allow us in a second/third pass to try and be smart about operation orders etc but initally it would pretty much work as today and apply them in sequence) .
I think it's a good idea, using the current API I think it's counterintuitive to both return an Image reference and modify the source one.
My use case is this : I need to cut a rectangle into 4 smaller rectangles.
Using the Crop method, I need to load the source image 4 times.
I would have expected either a void method signature, to let the developer know it's going to modify the source, or a new reference returned.
Or am I doing something wrong for my use case ?
your use case seems fine... that sort of scenario is is exactly why I've proposed the API change.
I also ran into confusion because of a non-void return type. I ended up having to open the image twice for two courses of action.
Hows #275 going? I see it's still open but looks finished. Do you need contributors?
Hi @AmadeusW
We've actually merged those changes into #299 as part of our beta1 launch. We've got one thing we're trying to work out regarding the best fit for our image frame API and we'll be set to launch that.
As far as contributors go, yes, always. We'd love to have you help out. There's a lot of up-for-grabs issues currently open.
Cheers
James
Most helpful comment
No I don't think
outbased overlaod that would be the best api for this.I was thinking it would actually require a significant API redesign to make it work intuitively.
I was more thinking if we changed our api to be more like this:
``` and to the current image.> action);
c# // could easily be extension methods instead of instance methods // all they do in instantiate a newImageOperations// then call Apply/Build etc on it at before returning.
class IImage
{
// applies the configured ImageOperations
void Mutate(Action
}
or
c# using(var image2 = image.Generate(ctx => ctx.Resize(...).Rotate(...))) { image2.Save(...); // altered version } image.Save(...); // orig image unalterdImageOperations<TPixel>would cue up the operations and apply them all before Mutate/Generate returns but not immediately on calling the method. (this could allow us in a second/third pass to try and be smart about operation orders etc but initally it would pretty much work as today and apply them in sequence) .