EncoderInfo not set correctly if output to Stream

[nquandt]

Given some image.. and EncoderOptions set to Webp type.. The output stream is not encoded correctly unless I manually call TrySetEncoderFormat.. (where I was under the impression this should be set based on the EncoderOptions)

var newStream = new MemoryStream();

var settings = new ProcessImageSettings()
    {        
        EncoderOptions = new WebpLossyEncoderOptions(80), 
    };
MagicImageProcessor.ProcessImage("./image.webp", newStream, settings); // load an image however..

var bytes1 = newStream.ToArray();

var newStream2 = new MemoryStream();

var settings = new ProcessImageSettings()
    {        
        EncoderOptions = new WebpLossyEncoderOptions(80), 
    };

settings.TrySetEncoderFormat("image/webp"); // this line makes it different
MagicImageProcessor.ProcessImage("./image.webp", newStream2 , settings); // load an image however..

var bytes2 = newStream2.ToArray();

Assert.Equal(bytes1.Length, bytes2.Length); // returns false (should be true)

If I output to a file path instead of a stream it sets the encoder correctly (i believe because of this line)

ctx.Settings.EncoderInfo ??= getEncoderFromPath(outPath);

[saucecontrol]

That behavior is as designed -- encoder options do not affect the codec selection, because they may be in conflict. For example, if you supply JpegEncoderOptions and then call ProcessImage with a .png output path, you will get PNG output, and the encoder options will be ignored.

In the absence of any call to TrySetEncoderFormat or a file extension on output path (as in Stream output), codec selection is automatic based on the properties of the input image.

If the codec options you supply happen to match the encoder chosen, they will be used. In fact, if the options supplied match the shape of the options for the chosen codec, they will also be used. e.g. JpegEncoderOptions and WebpLossyEncoderOptions both implement ILossyEncoderOptions, so you can use either to set the quality level for any lossy codec.

[nquandt]

I think I understand.. I might have misunderstood this comment stating the codec would be selected based on the EncoderOptions provided.

Here is a .NET 7 console app example of essentially what I'm trying to do.. I'd like all my transformation done without writing IO.. In my real app there are more transforms created via a pipeline, but this example shows exactly where I ran into issues. Basically when I save the .webp to a stream it seems to be saving as a bitmap instead of encoding as webp, despite my EncoderOptions being set as WebpLossy. Intuitively I would look at this and think the image would be processed and saved as WebpLossy. Feels awkward to have to specify specifically the encoder (and with an extra method and not as a part of the ctor for ProcessImageSettings) and to specify the EncoderOptions.. Is there a typical strategy used when transforming images in memory alone? Is it just what I have and I live with it or am I missing something elsewhere?

Thanks for the comments and help on this!

using PhotoSauce.MagicScaler;
using PhotoSauce.NativeCodecs.Libwebp;

CodecManager.Configure(codecs =>
            {
                codecs.UseLibwebp();
            });

var client = new HttpClient();

var resp = await client.GetAsync("https://www.gstatic.com/webp/gallery/1.webp");

var originalBytes = await resp.Content.ReadAsByteArrayAsync();


var newStreamWithEncoder = new MemoryStream();
var settings = new ProcessImageSettings()
{
    EncoderOptions = new WebpLossyEncoderOptions(80)
};
settings.TrySetEncoderFormat("image/webp");


MagicImageProcessor.ProcessImage(new MemoryStream(originalBytes), newStreamWithEncoder, settings);

var newStream = new MemoryStream();
MagicImageProcessor.ProcessImage(new MemoryStream(originalBytes), newStream,  new ProcessImageSettings()
{
    EncoderOptions = new WebpLossyEncoderOptions(80)
});

var newBytesWithEncoder = newStreamWithEncoder.ToArray();
var newBytesWithoutEncoder = newStream.ToArray();

Console.WriteLine("Original Bytes: " + originalBytes.Length); // 30320
Console.WriteLine("New Bytes with Encoder: " + newBytesWithEncoder.Length); // 30916
Console.WriteLine("New Bytes without Encoder: " + newBytesWithoutEncoder.Length); // 42564

[saucecontrol]

Ah, yeah, I see what you mean. The comment you linked is definitely incorrect. I had intended at one point to allow the EncoderOptions to be used as a hint in codec selection, but in addition the issue of potential disagreement between the options and requested file extension, that feature would require that the core library know what all the potential EncoderOptions types are and how they map to codecs, which it can't today since many codecs (including WebP) are provided as separate plugin libraries.

Feels awkward to have to specify specifically the encoder (and with an extra method and not as a part of the ctor for ProcessImageSettings) and to specify the EncoderOptions

Agreed. I think it might be ok to use the EncoderOptions as a hint as described in the doc comments, where that selection may still be overridden by an explicit codec selection through TrySetEncoderFormat or output file extension. Ultimately, the encoder selection must be something that's imperative and expected to throw (or return false) to tell you that your requested codec isn't available. For that reason, TrySetEncoderFormat won't go away, but maybe we can make it optional.

[nquandt]

Thanks for the context! I'll toss TrySetEncoderFormat into all my settings creations for what I need. Would it be too implicit to allow EncoderFormat as a param on the ctor for ProcessImageSettings()?

new ProcessImageSettings(myMimeTypeOrExt)
{
   blah blah blah
}

That might not make sense intuitively, just a thought.. Either way I'm good if you want to close this comment. Thanks again for walking me through the thought process. It makes more sense now.

[saucecontrol]

That's a good question. I'm trying to strike a balance between making things easy for uses who want to take advantage of the "magic" parts of MagicScaler while providing a full API for more advanced use. I'm not sure whether codec selection and settings fall on the advanced side or not, but it's kind of an awkward split as is.

I'll think about this some more for next version and leave it open in case anyone else has comments. I do appreciate the feedback, so thanks for bringing this up!