Saving webp to jpg gives strange result

[brianpopow]

Discussed in https://github.com/SixLabors/ImageSharp/discussions/2659

^{Originally posted by **omuleanu** February 7, 2024} I tried saving an webp image to jpg using this code: ``` using var fstream = file.OpenReadStream(); // file is IFormFile var img = Image.Load(fstream); await img.SaveAsync(filePath, new JpegEncoder { Quality = 50 }); ``` and the result is quite strange, here is the result:  the original I've uploaded as zip, because webp is not allowed here [before.zip](https://github.com/SixLabors/ImageSharp/files/14200293/before.zip)

[brianpopow]

webpinfo:

RIFF HEADER:
  File size:  74554
Chunk VP8X at offset     12, length     18
  ICCP: 0
  Alpha: 1
  EXIF: 1
  XMP: 0
  Animation: 0
  Canvas size 480 x 480
Chunk VP8L at offset     30, length  74330
  Width: 480
  Height: 480
  Alpha: 1
  Animation: 0
  Format: Lossless (2)
Chunk EXIF at offset  74360, length    194
No error detected.

[dlemstra]

This is not a bug? The image is being written as a jpeg file that has no support for an alpha channel. When this happens the alpha channel is removed and the rgb channels behind it are "revealed". The user should use a method that replaces the alpha channel with a solid color before saving the image?

[brianpopow]

@dlemstra yes you are right, it is not actually a bug in the decoder. Using a format which supports transparency or applying image.Mutate(x => { x.BackgroundColor(Color.Black); }); fixes the issue:

I was jumping to fast to a conclusion.

[omuleanu]

@dlemstra Thank You, (shouldn't it default to white for transparent pixels ? ; like in mspaint when you save a transparent png as jpg)

[JimBobSquarePants]

No. We should never make assumptions that are destructive to incoming data.