Correctly handle identity transforms with varying dimensions

[JimBobSquarePants]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

Fixes #1911

• Fixes a situation where given source and destination rectangles can cause an ImageProcessingException during transforms when an identity matrix is passed.
• Renames Buffer2DRegion{T}.GetRowSpan(y) adding the Dangerous prefix to match other implementations. CC @antonfirsov
• Removes the exception wrapping from the base cloning processor Do we really need exception-wrapping in ImageProcessingContext<T>.Execute() ? #1827

[antonfirsov]

It looks like the rest of AffineTransformProcessor<T> code doesn't respect SourceRectangle.

The following two tests have a tiny difference in input matrices, yet they produce very different results after this change in the PR:

[Theory]
[WithTestPatternImages(100, 100, PixelTypes.Rgba32)]
public void Identity<TPixel>(TestImageProvider<TPixel> provider)
    where TPixel : unmanaged, IPixel<TPixel>
{
    using Image<TPixel> src = provider.GetImage();

    Matrix3x2 m = Matrix3x2.Identity;
    Rectangle r = new Rectangle(25, 25, 50, 50);
    src.Mutate(x => x.Transform(r, m, new Size(100, 100), KnownResamplers.Bicubic));
    src.DebugSave(provider);
}

[Theory]
[WithTestPatternImages(100, 100, PixelTypes.Rgba32)]
public void AlmostIdentity<TPixel>(TestImageProvider<TPixel> provider)
    where TPixel : unmanaged, IPixel<TPixel>
{
    using Image<TPixel> src = provider.GetImage();

    Matrix3x2 m = Matrix3x2.CreateRotation(0.0001f, new Vector2(50, 50));
    Rectangle r = new Rectangle(25, 25, 50, 50);
    src.Mutate(x => x.Transform(r, m, new Size(100, 100), KnownResamplers.Bicubic));
    src.DebugSave(provider);
}

Identity:

AlmostIdentity:

On master they are equally broken not respecting the SourceRectangle. It seems like ProjectiveTransform suffers from the same issue.

I wonder how to proceed? I see two options:

1. Open a tracking issue & fix the processor
2. Drop sourceRectangle the Transform overloads so the API is in sync with actual functionality, and open a tracking issue to implement them.

[JimBobSquarePants]

Well caught! I actually thought they we're and I'd just made an oversight.

I'll actually have a look at the entire implementation and see if it can be a quick fix.

[JimBobSquarePants]

Fix was easy enough. I've updated two ref files to match correct results but wondering what the best approach for coverage is. I could add refs for the tests you provided and do one using Matrix4x4.CreateRotationX for perspective equivalents but would like to avoid more ref images if possible.

[antonfirsov]

More ref images should not cause trouble as long as they are small (a few bigger ones can weight much more than many small ones). We can transform the 30x30 central part of a 60x60 image to keep the output as small as possible.
I would turn AlmostIdentity into a theory and test a few more rotation angles. (Eg pi/4 -pi/4) We should see it rotating smoothly and the epsilon rotation should be visually indistinguishable from the special-cased 0 rotation.

[JimBobSquarePants]

Done

[JimBobSquarePants]

@antonfirsov I've seen this pop up 2X now. Should we be concerned or is it a simple memory pressure thing driven by the environment.
https://github.com/SixLabors/ImageSharp/runs/4913118322?check_suite_focus=true#step:13:319

[antonfirsov]

It should be environmental, will attempt to fix, or at least reduce flakiness by moving it out of process so at least it doesn't race with parallel tests for the same virtual address space.

[JimBobSquarePants]

Ace. I'll rerun these anyway to get he green light

[antonfirsov]

Looks good, well done!