@Socolin I'll have another look at this soon. I've been wiped out with the flu for the last 10 days so have not been able to do anything. I'll likely pull down your fork and make some initial code changes to add the appropriate extension method to ColorProfileConverter to allow both processes.

@Socolin I have re-implemented the per-image version of the operation in ImageDecoderCore.

I also took a closer look at the per-scanline variants, and I am not convinced they are a net win in this case. The color conversion must occur after any blending, which already forces a separation between decoding and conversion. That means we do not get to fuse the work into a single pass anyway, and we explicitly want to avoid per-pixel conversion because the ICC path is computationally expensive and not structured for that granularity.

The per-image approach has a practical advantage here: the conversion is applied over the entire pixel buffer using ProcessPixelRowsAsVector4, which internally partitions the work into n = Environment.ProcessorCount parallel chunks. Each chunk processes multiple rows, amortizing allocator usage, reducing per-row setup overhead, and allowing the ICC conversion to run over contiguous spans with better cache locality. In contrast, a per-scanline API would serialize more of that overhead. Even if scanlines were scheduled in parallel, each invocation would still pay the fixed costs of buffer setup, conversion dispatch, and synchronization at a much finer granularity, which tends to dominate the actual math.

So while a per-scanline API looks attractive on the surface, in practice it would be slower for this workload. The per-image conversion aligns better with how the ICC code wants to operate, and it lets us fully exploit coarse-grained parallelism rather than fragmenting the work into many small units with higher overhead.