Why Rgba32?

[antonfirsov]

Branching a new discussion from SixLabors/ImageSharp#1986 (comment)

ImageSharp.Web could never have taken advantage of it because we need to allow users to change format and the easiest way to do that was to use Rgba32.

I'm not familiar with ImageSharp.Web architecture, but I don't understand how can target type decoding block the format change. I'd say, we should be able to dogfeed this 2.0 optimization to ImageSharp.Web. It eliminates 25% of the memory footprint in many cases. If there is an inherent issue adapting it, it's a problem we should eventually solve.

[JimBobSquarePants]

It's actually the same issue BackgroundColor, I spoke incorrectly in the other discussion. Rgba32 was the easiest way to ensure it always worked. (I have no idea what processors occur in the wild which would also be affected).

width=100&height=200&rmode=pad&bgcolor=white

Will fail for jpegs without decoding to Rgba32. BackgroundColor and Resize are two separate operations and should remain separate.

[antonfirsov]

If individual processors could decide and communicate whether they need an alpha channel with a given set of args, the middleware could decide if it has to do an alpha-aware decode or not.

I'm just wondering if there is an inherent API issue, or it's just a piece of non-trivial optimization work. Obviously, the FormattedImage public API would have to switch away from using generic Image<Rgba32>. I don't see why is it currently necessary to expose a specific pixel type to the user.

[JimBobSquarePants]

I don't see why is it currently necessary to expose a specific pixel type to the user.|

It's not necessary, we just do it currently.

If individual processors could decide and communicate whether they need an alpha channel with a given set of args, the middleware could decide if it has to do an alpha-aware decode or not.

Processors are currently stateless and very loosely coupled to the middleware. The only information they can provide to the middleware is their key collection for recognized commands so correct processing order can be returned by matching the earliest index of a command key to the input command collection in a single loop. If we inverted that operation and made it possible for the processors to individually return both an index and a value indicating alpha component requirements we dramatically increase the operation complexity as each processor would then be required to iterate the collection.

[antonfirsov]

Maybe it can be a separate operation to be invoked after establishing the order but before doing the decoding and the actual processing? Seems like a candidate for method taking some sort of contextual information / state and return a bool.

Need to familiarize myself with the details of the underlying logic though to make an actual usable proposal.