Calling DrawImage with top image that overhangs bottom image in Y direction fails with exception

[aceoft]

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

ImageSharp version

3.1

Other ImageSharp packages and versions

SixLabors.ImageSharp.Drawing 2.0.1

Environment (Operating system, version and so on)

Win10 22H2

.NET Framework version

7

Description

After upgrading the ImageSharp nuget package today, several of my unit tests started failing. They are all related to overlaying images that hang over the bottom edge of the bottom image.

The exception being thrown is:

System.AggregateException: One or more errors occurred. (Specified argument was out of the range of valid values. (Parameter 'DangerousGetRowSpan(100). Y was out of range. Height=100')) ---> System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'DangerousGetRowSpan(100). Y was out of range. Height=100')

It only seems to happen when a Y value is larger than the height of the bottom image.

I'm just getting started with ImageSharp and have been impressed by the amount of thought and hard work that has been put into the library. Thank you, and hopefully I provided everything we need here.

Steps to Reproduce

Test method to reproduce the exception:

public void TestOverlayImageOffEdge()
{
	using var bottom = new Image<Rgb24>(100, 100, Color.Black);
	using var top = new Image<Rgb24>(100, 100, Color.White);

	// OK (expected)
	bottom.Mutate(i => i.DrawImage(top, new Point(0, 0), 1f));

	// OK (expected, overhangs X direction by 1 pixel)
	bottom.Mutate(i => i.DrawImage(top, new Point(1, 0), 1f));

	// throws System.AggregateException
	bottom.Mutate(i => i.DrawImage(top, new Point(0, 1), 1f));
}

I had a quick look at the source code and wondered if providing a source rectangle would help -- it did. The below line appears to be a workaround.

// OK
bottom.Mutate(i => i.DrawImage(top, new Point(0, 1), new Rectangle(0, 0, 100, 99), 1f));

Images

No response

[aceoft]

It appears that more than one behavior was changed in this area. I am also having trouble with overlaying images with the origin point being outside the dimensions of the bottom image.

For example, an origin of -100, -100 appears to be getting reset to 0, 0 before overlaying now.

[JimBobSquarePants]

Yeah, lots of changes.

#2447

For example, an origin of -100, -100 appears to be getting reset to 0, 0 before overlaying now.

That makes sense. The rectangle passed represents the source bounds to be drawn so you would pass a positive XY point to offset an image negatively.

[aceoft]

Thank you for your response! I'm sorry, I wasn't clear enough in my last statement. I meant passing negative values for the X or Y values in the location (renamed to backgroundLocation) argument.

In 3.0.2, the top image would originate from that location correctly (you end up losing part of the left/top of the top image as intended). In 3.1, it doesn't seem to allow a backgroundLocation with negative values. It silently resets to 0, 0 and draws from there.

[JimBobSquarePants]

No, it’s ok, I got you the first time. If you look at the linked issue you will see why the behaviour was changed. (That change was specifically called out as breaking btw in our blog post).

Essentially negative offsetting the background position cannot work (previous implementation was buggy). You should specify the region you want to draw as a positive offset of the overlay image.

[aceoft]

Cool, thanks for the follow up. I see there was an intended breaking change regarding the extra parameter/parameter names, but was the other breaking change (no longer supporting negative positions) intended? I don't see it mentioned in the post, changelist, or code review.

It appears that it is indeed possible to do this safely using the region like you described. Should that have been implemented alongside the other changes so that the outward behavior wasn't changed, with the result of breaking consuming code? That to me feels like the breaking change that could have been avoided and may have been unintentional.

Now that it's the default behavior in 3.1, I can see how it would be undesirable to change it again. I would at least consider throwing an exception if the geometric coordinates are going to be completely rejected/manipulated before drawing. At least that way we'd know we aren't going to get the result we expected. In that case my unit tests would have failed. As it was, I only noticed because I happened to look closely at one of the thumbnails and noticed it wasn't drawn correctly anymore.

I'm afraid I've gotten off into the weeds a bit though and distracted from the original point of this filed issue though.

Again, mad respect to you and your team and all the contributors for creating this amazing library for us.

[aceoft]

I checked the source code and I think I see the issue around these lines:

ImageSharp/src/ImageSharp/Processing/Processors/Drawing/DrawImageProcessor{TPixelBg,TPixelFg}.cs

Line 89 in 3d69f21

foregroundRectangle.Width += this.BackgroundLocation.X;

The foregroundRectangle.Width is adjusted by the background location X value if it was negative. This is resulting in cropping off the right side of the top image, not the left. Same for the Y direction just below that.

I created a test project to demonstrate the difference to make sure I wasn't going crazy, but here is an illustration:

Above: 3.0.2 behavior. The top/left of the top image is lost (expected due to negative coordinates).

Above: what I believe the code in 3.1 is intended to do. The output would remain the same. I believe adjusting the rectangle's X an Y (in addition to removing it from the Width and Height) could have this effect. I am not an expert at what's happening below there, though, so I could be wrong.

Above: what is actually happening. The top image is indeed painted in the same box, but it originates from the top left corner and cuts off the bottom/right of the image instead of the top/left.

Thanks again for your time!

[tehsoul]

Just want to chime in that I see the exact same behavior of appearing to not respect negative origins and resetting to 0 after having bumped to 3.1.0.
I was going to investigate and create an issue if I got a few hours for it but you beat me to it with this great explanation!
I reverted to 3.0.2 for now

[JimBobSquarePants]

@tehsoul Please do not revert. That's the worst possible thing you could do!!!

The behavior in 3.0.2 is incorrect and you are basing your implementations on incorrect behavior. I will try to explain why.

Take for example the overlay image shared in issue #2447

If we wanted to render the following result that contains what you both would consider a negative offset off the overlay

you should write the following code:

using var src = Image.Load<Rgba32>("numbergrid.png");
using var dst = new Image<Rgba32>(100, 100, new Rgba32(0, 255, 255));

dst.Mutate(c => {
    c.DrawImage(src, new Point(64, 10), new Rectangle(32, 32, 32, 32), 1.0f);
});

dst.SaveAsPng("result.png");

As you can see from the code says to render the source image at position [64,10] taking from the source image a rectangle at position [32,32] and size 32x32.

To consider this a negative offset in coordinate terms is incorrect. The rectangle parameter specifically represents the area of interest within the overlay bounds to draw.

Ignoring negative values is a common way to normalize out of bounds properties hence why Rectangle.Intersect exists in here, System.Drawing, and many other libraries.

@aceoft What you think is the "intended behavior" is absolutely not intended at all. We explicitly want to avoid negative values in the overlay rectangle and the background location because they simply do not make sense.

I will repeat this again. The behavior you saw in v3.0.2 was unintentional and incorrect.

Does that make things clear?

[JimBobSquarePants]

I'll have a look at the original issue but there will be no reversion to the buggy behavior present in previous versions.

[tehsoul]

@JimBobSquarePants I agree with the logic in your example.
However, here is a very simplified version of what I'm trying to achieve (screenrecording from manually doing the action I want to automate in Paint.NET):

--> basically my code starts with the top left point as input, which is where I'm drawing it on the destination layer:

using var src = Image.Load<Rgba32>("numbergrid.png");
using var dst = new Image<Rgba32>(512, 512, Color.HotPink);

dst.Mutate(x=>x.DrawImage(src, new Point(-300, -150), 1.0f));

dst.SaveAsPng("result.png");

3.0.2 output:

3.1.0 output (for my scenario, totally not what is intended):

[tocsoft]

@JimBobSquarePants the difference is between passing a Rectangle and just a Point. Based on the images provided I would have to agree that behaviour is broken in the case of a Point rather than a Rectangle. For a Point I would expect a negative offset to work and show the bottom right of the overlay image, however when passing a Rectangle I do agree it should be the explicit region defined.

I.e. Passing a Rectangle implies a crop followed by a draw operation, but passing a Point implies a straight draw operation leaving only the part of the overlay that happens to intersect visible.

[tehsoul]

To add to this, the following related behavior is also weird and imo inconsistent in 3.1.0:

Moving the image positively on the X axis so it overlaps destination - WORKS

using var src = Image.Load<Rgba32>("numbergrid.png");
using var dst = new Image<Rgba32>(512, 512, Color.HotPink);

dst.Mutate(x => x.DrawImage(src, new Point(300, 0), 1.0f));

dst.SaveAsPng("result.png");

--> works as expected

Moving the image positively on the Y axis so it overlaps destination - FAILS WITH EXCEPTION

using var src = Image.Load<Rgba32>("numbergrid.png");
using var dst = new Image<Rgba32>(512, 512, Color.HotPink);

dst.Mutate(x => x.DrawImage(src, new Point(300, 0), 1.0f));

dst.SaveAsPng("result.png");

Fails with error:

System.AggregateException
One or more errors occurred. (Specified argument was out of the range of valid values. (Parameter 'DangerousGetRowSpan(537). Y was out of range. Height=512')) (Specified argument was out of the range of valid values. (Parameter 'DangerousGetRowSpan(623). Y was out of range. Height=512')) (Specified argument was out of the range of valid values. (Parameter 'DangerousGetRowSpan(580). Y was out of range. Height=512')) (Specified argument was out of the range of valid values. (Parameter 'DangerousGetRowSpan(512). Y was out of range. Height=512'))

--> this worked in 3.0.2 as expected:

[JimBobSquarePants]

@tocsoft Passing a negative point implies virtual pixels outside of the background image. I don’t think that is wise and is inconsistent with the rest of the library. It’s the same situation for our ImageBrush in Drawing.

@tehsoul that’s literally the raised issue. We should be clipping the vertical bounds

[tocsoft]

I would argue this is more inconstant with the other Drawing APIs. if you do the same operation with a vector I'm pretty sure it'll work as expected, i.e. drawing a circle with a negative offset will draw the bottom right portion of the circle not the top left.