Black borders on mutate (image resize with background color)

[romanov]

Prerequisites

• [+] I have written a descriptive issue title
• [+] I have verified that I am running the latest version of ImageSharp
• [+] I have verified if the problem exist in both DEBUG and RELEASE mode
• [+] I have searched open and closed issues to ensure it has not already been reported

Description

Hello,

i'm trying to resize the following test image (1500x1500) to 250x350px and keep white background:

https://ibb.co/Yk6kqBc

Steps to Reproduce

1. Upload the image above to the local folder
2. Encode it with the following code

var encoder = new WebpEncoder
{
    Quality = 100,
    Method = WebpEncodingMethod.BestQuality,
};

var resizeOptions = new ResizeOptions
{
    Mode = ResizeMode.Pad,
    Size = new Size(250, 350)
};

using var image = Image.Load(fileName, out var imageFormat);
image.Mutate(x => x.Resize(resizeOptions).BackgroundColor(Color.White));
image.SaveAsWebp(newFileName, encoder);

Expected result (green box in the middle, white background):

Actual result (green box in the middle, black background):

System Configuration

• ImageSharp version: 2.0.0
• Other ImageSharp packages and versions: n/a
• Environment (Operating system, version and so on): Microsoft Windows [Version 10.0.19043.1466]
• .NET Framework version: NET 6 Console app & ASP.NET CORE
• Additional information: n/a

[brianpopow]

I cant reproduce it, looks as expected with white border.

P.S. in your above example you are not actually using the encoder. You have to pass the Encoder to Save as a parameter:

image.Save("output.webp", encoder);

[romanov]

Yes, i provide encoder in Save (fixed code above).
I made a test solution, can u test it with my jpg file?

ImageMutateTest.zip

Same story with any other encoders (JpegEncoder, PngEncoder...)
Same story when i try image.Mutate(x => x.Pad(250, 350, Color.White));

Update
When i use png => it's working. But when i try to put the same converted png to webp => it's not

[brianpopow]

I was able to reproduce it, but I see the issue also for png.

Its seems to be an issue with applying the background, not the encoding of the image.

It seems to work with Image.Load<Rgba32>, but loading the image with Image.Load (without specifying a pixel type), does not.

[JimBobSquarePants]

That's expected. Pad uses BackgroundColor which requires an alpha component.

ImageSharp/src/ImageSharp/Processing/Extensions/Transforms/PadExtensions.cs

Lines 32 to 40 in a844c78

	var options = new ResizeOptions
	{
	Size = new Size(width, height),
	Mode = ResizeMode.BoxPad,
	Sampler = KnownResamplers.NearestNeighbor,
	};
	return color.Equals(default) ? source.Resize(options) : source.Resize(options).BackgroundColor(color);
	}

If you want to set that color you need to use the generic API and decode to an pixel format containing an alpha component.

[romanov]

If you want to set that color you need to use the generic API and decode to an pixel format containing an alpha component.

Maybe, you should add some comment or warning for mutation methods (forcing people to use generic)? Because, i've tried yesterday to convert images and spent like 20 minutes. Never knew that i need to use Image.Load<Rgba32>(...) instead of Image.Load(...)

Anyway, thank you for the explanation.

[JimBobSquarePants]

Maybe you could?

[tocsoft]

@JimBobSquarePants @antonfirsov ☝️ this is why i warned against us decoding (when using non-generic) Image into a pixel format that doesn't support the full Rgba32 color space (or at least having an alpha channel)

This 'unexpected behaviour' will likely show up again and again... it doesn't help this is also a breaking behaviour change between v1 and v2.

This change we made now means that different APIs behave different just based on the source image loaded and not on the code someone defined created. One of the major drivers of having the non-generic image was to simplify users interactions with images, we have made it more difficult the only way you can have consistent processing is decode into Image<Rgba32> which defeats most of the point of having the non-generic apis in the first place.

[br3aker]

Why not introduce forceRgba32 set to true in the Configuration then?
That way both sides should be happy: default behaviour is rgba32 with optional rgb24 for better memory consumption.

[antonfirsov]

Why not introduce forceRgba32 set to true in the Configuration then?

I had a similar idea, but got pushback 😄 Maybe we can re-evaluate. The difference is that I was recommending to optimize by default, and have a property to opt-out from the optimization.

I still believe this issue is something we can address by explaining it in conceptual docs rather than penalize every single user's memory footprint. Most users wont face similar problems.

[br3aker]

I still believe this issue is something we can address by explaining it in conceptual docs rather than penalize every single user's memory footprint. Most users wont face similar problems.

If it's only a resize type problem - we can solve it way simplier: decode-resize-encode API.

Jpeg will hopefully get that fancy downscaling decoding from me and we would need an API for any image format anyway so user won't need to call Identify and then if-else for jpeg specific path, maybe we can fit this specific case in that API?

[JimBobSquarePants]

We actually have all the information at hand to perform a version of pad with background color that works for pixel formats without an alpha component. ResizeHelper gives us the size and rectangle, we can simply fill around when required. This is the only method I can think of that is an issue. (BackgroundColor is not, since the requirement for an alpha component should be understood)

I don’t see the non-generic api behaviour as an issue that can’t be fixed by documentation. At least it doesn’t throw like some System.Drawing methods.

[JimBobSquarePants]

I think target size decoding should be specific to JpegDecoder btw. I’d rather keep that kind of functionality low level and not try to abstract it across image formats