BoxBlur(1) on Image<L8>: is the generic Vector4 path expected? (ImageSharp 3.1.12)

[Vit0GG]

I'm working on a university image-convolution project. My own 3×3 box blur was faster than ImageSharp's BoxBlur(1) on 100 JPEG images decoded as Image<L8>. I then tried to isolate the filter from JPEG I/O and from my own wrapper. I am not reporting an incorrect output; I would like to understand whether the behavior below is expected or whether I have missed a better way to use ImageSharp.

Controlled comparison

The two runs below use the same Image.Load<L8>(file), image.Save(output), input files, and outer Parallel.ForEach (up to 12 files at once). Only the filter call changes:

Filter between load and save	Median time for 100 JPEGs
ImageSharp 3.1.12: image.Mutate(c => c.BoxBlur(1))	8.417 s
Separate L8-only, two-pass box filter	2.872 s

The images are 3840×2160. Measurements are Release/.NET 9, one warm-up and five full-folder runs per variant, in shuffled order; these are medians of elapsed time measured by Stopwatch. The L8-only control makes a horizontal three-pixel average followed by a vertical three-pixel average, replicates edge pixels, and rounds the intermediate result to L8 after the first pass. Both passes are row-parallel. It produced zero differing pixels on a checked 4K image, and the saved JPEG SHA-256 hashes matched for all 100 files. I did not modify the ImageSharp package or its source for this folder comparison.

L8-only control filter

using System;
using System.Threading.Tasks;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Advanced;
using SixLabors.ImageSharp.PixelFormats;

static void GrayBoxBlur(Image<L8> image, ParallelOptions options)
{
    int width = image.Width, height = image.Height;
    using var middle = new Image<L8>(width, height);

    Parallel.For(0, height, options, y =>
    {
        Span<L8> input = image.DangerousGetPixelRowMemory(y).Span;
        Span<L8> output = middle.DangerousGetPixelRowMemory(y).Span;
        for (int x = 0; x < width; x++)
        {
            int sum = input[Math.Max(0, x - 1)].PackedValue
                + input[x].PackedValue
                + input[Math.Min(width - 1, x + 1)].PackedValue;
            output[x] = new L8((byte)((sum + 1) / 3));
        }
    });

    Parallel.For(0, height, options, y =>
    {
        Span<L8> above = middle.DangerousGetPixelRowMemory(Math.Max(0, y - 1)).Span;
        Span<L8> current = middle.DangerousGetPixelRowMemory(y).Span;
        Span<L8> below = middle.DangerousGetPixelRowMemory(Math.Min(height - 1, y + 1)).Span;
        Span<L8> output = image.DangerousGetPixelRowMemory(y).Span;
        for (int x = 0; x < width; x++)
        {
            int sum = above[x].PackedValue + current[x].PackedValue + below[x].PackedValue;
            output[x] = new L8((byte)((sum + 1) / 3));
        }
    });
}

For context, my own row-parallel CPU implementation completed the same folder in 4.201 s, but that row uses a different load/save path, so the 8.417 vs 2.872 s pair above is the controlled comparison.

The process's total CPU time (summed across threads, including I/O) was 92.344 s with BoxBlur and 28.047 s with the L8-only control. In a separate Visual Studio CPU Usage sample of repeated BoxBlur calls on a preloaded Image<L8>, 46.9% of the CPU samples landed in Vector4Converters.Default.UnsafeFromVector4Core. That points to the generic Vector4 → L8 conversion as a hot spot, but it does not establish that this one method explains the entire elapsed-time gap.

Environment and question

• ImageSharp 3.1.12; .NET 9.0.11; Windows 10; Intel Core i5-12450H (12 logical processors).
• Image<L8>, BoxBlur(1) (3×3), 100 JPEG inputs at 3840×2160.
• I have not measured a newer ImageSharp release yet.

Is the general Vector4 path expected for BoxBlur(1) on Image<L8>? Is there a supported configuration/API for a faster grayscale-only path, or a correctness/quality consideration that my control misses? If a recent release has changed this path, a pointer would help. I can share the full benchmark harness and input details if useful.

[JimBobSquarePants]

Yes, the Vector4 path is expected. ImageSharp processes TPixel through a common floating-point representation so the same convolution implementation works across pixel formats and retains precision during the calculations. It also handles alpha correctly for formats that have it.

Your control is specialized for L8, a fixed three-pixel kernel, and opaque grayscale data. It can avoid the pixel conversions and general processing work, so it is reasonable for that narrower implementation to be faster. Matching output for these inputs does not remove the need for the generic path.

There is no configuration switch that selects an L8-only box blur. Your conversion profile is useful evidence of an optimization opportunity, but the use of Vector4 itself is intentional.