Make pixel blenders public

[vpenades]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

I miss some method to write a single pixel with a blend state, for example:

Let's say I have an image, and I want to do something like this:

image.SetPixel(RGBA.Red,PixelBlenderState.Multiply, 0.7f);

I know I can use Mutate Fill with a rectangle selecting a single pixel, but I think it's a bit overkill.

Alternatively, it could be good enough to extend the PixelBlenderMode operations to pixel format colors:

Argb32 color1 = Argb32.Red;
Argb32 color2 = Argb32.Blue;
Argb32 color3 = Argb32.Blend(color1,color2,PixelBlenderMode.Multiply);

or

pixelBlender = Argb32.GetBlender(PixelBlenderMode.Multiply);
Argb32 color3 = pixelBlender(color1,color2);

Steps to Reproduce

not applicable

System Configuration

not applicable

• ImageSharp version: 1.0.0-beta0002
• Other ImageSharp packages and versions:
• Environment (Operating system, version and so on):
• .NET Framework version:
• Additional information:

[vpenades]

After reviewing how ImageSharp handles pixel operations, here's a proposal:

internal PixelBlender should implement a public IPixelBlender that, at least, has the public abstract TPixel Blend(TPixel background, TPixel source, float amount); method

At PixelOperations rename the existing internal GetPixelBlender to GetPixelBlenderInternal or something like that, and add a public GetPixelBlender returning the IPixelBlender interface

That would allow users to access this feature.

[antonfirsov]

@vpenades we need to do a performance review of these API-s before turning them public. This issue is very similar to #381.
@JimBobSquarePants should we add this on our 1.0 milestone?

[JimBobSquarePants]

@antonfirsov I think the blend implementation we have that takes Span<T>already caters for any performance implications. If we offer an additional per-pixel API that should be ok.

[tocsoft]

Our blend providers currently support single pixel operations.. The API to access the pixel blenders currently is:

PixelBlender<TPixel> blender = PixelOperations<TPixel>.Instance.GetPixelBlender(PixelBlenderMode.Default); 
TPixel background = ...;
TPixel source= ...;
float blendAmount= 1; // value from 0 - 1 for opacity like effects (depending on blender)
TPixel blendedPixel = blender.Blend(background, source, blendAmount);

We would need to expose PixelOperations<TPixel>.GetPixelBlender() as a public API + make make at least part of the PixelBlender<TPixel> class public too,

[JimBobSquarePants]

Remind me to go through the codebase and standardize any Instance Current properties.

[antonfirsov]

The current state of the PixelBlender API looks good an future-proof to me, so I think we can manage this for RC1 or 1.0.

[vpenades]

Reviewing the code, I have these considerations:

If PixelBlender is made public, the use cases can be:

1. Use the Single Pixel "Blend" on random access pixel drawing.
2. Use the Full Row "Blend" for specialised bulk drawing.
3. Third parties implementing their own blending functions.

if (3) is going to be allowed, the API should have to allow to pass the custom pixel blender with GraphicsOptions structure. not a big change.

if (3) is going to be disallowed, I would consider not making PixelBlender public, and seeking for an alternative to allow the single pixel blend funcion accessible. maybe with a public IPixelBlender interface, a delegate 😓 ... or a IBlendedPixelsRandomAccess interface ...

[antonfirsov]

PixelBlender<T> is a very thin and clean API now, introducing stuff like delgates would just make it worse. We can consider introducing an IPixelBlender<T> interface, but I see no benefit from this. There abstract classes across the whold .NET framework (ArrayPool<T>, Stream etc.) as well as the SixLabors libraries (MemoryAllocator) without having a base interface, and it seems much simpler to me.

To allow passing a pixel blender to GraphicsOptions, we need to introduce some kind of factory mechanism (IPixelBlenderFactory with a .CreatePixelBlender<T>(colorBlendingMode, alphaCompositionMode) method ?), but this is not a trivial design job, so I would remove (3) from the scope of this proposal. We can deal with that concern later.

[vpenades]

@antonfirsov I can envision a custom PixelBlender would have nothing to do with the colorBlendingMode and alphaCompositionMode but something completely different. Think about some crazy psychodelic pixel effect.

So the API would be something like this IPixelBlenderFactory.GetPixelBlender<T>()

GraphicsOptions would use an instace of DefaultPixelBlenderFactory(alphaCompositionMode ,colorBlendingMode ); by default

Personally I think the PixelBlender feature is quite complete already (some ColorBlending ops still missing) but there's always people around experimenting new things, and who knows...

[antonfirsov]

PixelBlender<T> and PixelOperations<T>.GetPixelBlender() have been made public in #1028.