Add public static string ToBase64String(this Image source, IImageEncoder encoder)

[LeaFrock]

Currently we only have the function called public static string ToBase64String(this Image source, IImageFormat format), and it uses

IImageEncoder encoder = source.Configuration.ImageFormatsManager.GetEncoder(format);.

So if we want to use specific image encoder(especially with a different Quality from the default) we have to set/change the encoder of the image configuration. It's like noise in the code, and there should already be a ready-made extension to deal with it.

    public static string ToBase64String(this Image source, IImageFormat format)
    {
        Guard.NotNull(format, nameof(format));

        using MemoryStream stream = new();
        source.Save(stream, format);

        // Always available.
        stream.TryGetBuffer(out ArraySegment<byte> buffer);
        return $"data:{format.DefaultMimeType};base64,{Convert.ToBase64String(buffer.Array ?? [], 0, (int)stream.Length)}";
    }

    public static string ToBase64String(this Image source, IImageEncoder encoder)
    {
        Guard.NotNull(encoder, nameof(encoder));

        using MemoryStream stream = new();
        source.Save(stream, encoder);

        // Always available.
        stream.TryGetBuffer(out ArraySegment<byte> buffer);
        return $"data:{format.DefaultMimeType};base64,{Convert.ToBase64String(buffer.Array ?? [], 0, (int)stream.Length)}";
    }

[smirk-dev]

This is an excellent feature request that addresses a real ergonomic issue. Your proposal is well-reasoned and the code example is clear. Let me provide some thoughts on this:

Why This Makes Sense

Your observation is spot-on. The current API forces users to either:

1. Modify the image's configuration object
2. Create a temporary encoder instance and manage it
3. Write their own extension method

All of these approaches add unnecessary complexity when you just want to specify an encoder with custom parameters like Quality.

Implementation Considerations

The overload you've proposed looks solid, but there are a few things the maintainers would likely consider:

1. MIME Type Handling

One thing I noticed in your code - you're using format.DefaultMimeType in the data URI. However, when using a custom encoder directly, we might not have the IImageFormat readily available. The maintainers might suggest:

public static string ToBase64String(this Image source, IImageEncoder encoder, IImageFormat? format = null)
{
    Guard.NotNull(encoder, nameof(encoder));
    
    using var stream = new MemoryStream();
    source.Save(stream, encoder);
    
    stream.TryGetBuffer(out var buffer);
    
    // If format not provided, try to get it from encoder's configuration
    var mimeType = format?.DefaultMimeType ?? "application/octet-stream";
    
    return $"data:{mimeType};base64,{Convert.ToBase64String(buffer.Array ?? [], 0, (int)stream.Length)}";
}

2. Encoder Definition

You might want to check if the encoder parameter should be:

• IImageEncoder encoder (interface, more flexible)
• IImageEncoder encoder, IImageFormat format (both, more explicit)

The second option would be more explicit and consistent with the existing overload.

3. Documentation

When submitted, it would be great to include:

• Usage examples showing the quality parameter scenario
• Performance considerations (if any)
• Comparison with the existing IImageFormat overload

Next Steps

I'd suggest:

1. Consider opening a PR directly if you're comfortable with it
2. Include test cases for the new overload
3. Add XML documentation explaining when to use this vs. the format-based overload
4. Check if there are any benchmarks affected

This is definitely a worthwhile addition that would improve the API's usability. The SixLabors team is generally responsive to well-reasoned feature proposals with clear use cases like this one!