Integrated 24-bit and 32-bit pixel interface?

[Hakoyu]

Like this

interface IPixel24
{
    public byte R;
    public byte G;
    public byte B;
}
interface IPixel32
{
    public byte A;
    public byte R;
    public byte G;
    public byte B;
}

Bgr24, Rgb24 Inheritance IPixel24
Abgr32, Argb32, Rgba32, Bgra32 Inheritance IPixel32
This operation makes it easier to get the RGB or ARGB value of a pixel without having to convert it for each pixel.
Because IPixel<T> does not contain RGB values directly, it is limited to use this as a generic function.

[JimBobSquarePants]

What's your use case that would require such functionality? Do you have an example of what you are trying to do?

[JimBobSquarePants]

Why not decode each image to the specific Image you want and compare that?

[Hakoyu]

I have implemented this, but decoding reduces performance a bit.

[Hakoyu]

You know, no matter how efficient the conversion is written, the fastest way is still to process the raw data.

So you can add a method to get the original format of the image, so that I do not have to write it myself.

[JimBobSquarePants]

That’s a terrible benchmark not comparing what I mean at all.

use Image.Load<Rgba32> for both images. No need to clone anything.

[Hakoyu]

Well, I found that regardless of the generic type of Image.Load<T>(), it takes roughly the same amount of time.
Perhaps using only one pixel format would be a good enough solution.

[antonfirsov]

interface IPixel32
{
    public byte A { get; }
    public byte R { get; }
    public byte G { get; }
    public byte B { get; }
}

This would lead to 4 interface calls with virtual dispatch for each pixel, which would perform terribly. Our internal conversion algorithms are heavily optimized, so consolidating to a single pixel format should be fast.