.Net 5.0 RC-1 breaks ImageSharp

[lofcz]

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

I've encountered a strange bug when mutating images after migrating mvc app from net fw48 to net5 rc1. I've swapped to async image handling. Steps I do (async action on a controller):

1) await HttpContext.Request.ReadFormAsync()
2) Image<Rgba32> img = Image.Load<Rgba32>([first image from form].OpenReadStream(), out IImageFormat imgFormat);
3) await img.SaveAsync("some path"); // saves the image correctly
4) img.Mutate(x => x.Resize(w, h, s)); // thumbnail; used Bicubic, tried Lancoz3 to check if that could be the problem
5) await img.SaveAsync("thumbnail path");

// also tried alternative
5) await using FileStream stream = System.IO.File.Create("some path");
6) await img.SaveAsync(stream, imgFormat);

Extremely frustrating is that this is happening only on production, not on my local machine. I've tried to use another sampler and use latest dev build of ImageSharp, neither helped. In each and every case the first half of an image is mutated correctly, while the other is either blank or filled with artifacts. I'm clueless about how should I move forward, the only option so far would be to go back to sync processing of images which I'd very much like to avoid. Attaching some test images:

Saved thumbnail 1:

Saved non-mutated image 1:

Saved thumbnail 2:

Saved non-mutated image 2:

Saved thumbnail 3:

Saved non-mutated image 3:

System Configuration

• dev: windows 10 20206_rsprerelease, net5 rc1
• production: windows server 2016 datacenter 10.0.14393, net5 rc1

ImageSharp version:

• tried 1.1, then 1.0.2 alpha 7

[JimBobSquarePants]

It's hard to be sure by reading from your code sample but it looks to me like you are not disposing of your input stream nor the image.

Image<Rgba32> img = Image.Load<Rgba32>([first image from form].OpenReadStream(), out IImageFormat imgFormat);

Should be.

using Stream inputStream = [first image from form].OpenReadStream();
using Image<Rgba32> img = Image.Load<Rgba32>(inputStream, out IImageFormat imgFormat);

In the case of Image, the GC would collect everything eventually but it's wasteful so you should always dispose after using.
The stream though must be disposed of to ensure the content is all written from any internal buffers.

[lofcz]

@JimBobSquarePants thanks, I've noticed that when I clone the image and then mutate the clonned copy it works properly both on dev and prod. Couldn't that be caused by ConfigureAwait(false) ImageSharp is using when processing async save?

[JimBobSquarePants]

I couldn't tell you. Could you please post a complete sample so that we can correctly replicate and diagnose any issues.

[klogeaage]

I can confirm this issue, which started occurring after I upgraded from Net Core 3.1 to 5.0 RC1. I am NOT using the async variants of the ImageSharp methods, except the controller if of course async, and I believe I am using/disposing of Image and Streams correctly. Going back to .Net Core 3.1 fixed the issue, but of course I would also like to move to 5.0.

[JimBobSquarePants]

I’ll need a means to replicate the issue. Without one nothing happens.

[klogeaage]

Sure, I'll see if I can replicate in some unit tests.

[JimBobSquarePants]

Thanks. That would be incredibly helpful!

[klogeaage]

Argh, it's working fine in an Xunit test with just the imaging and stream operations :-(

So for what it's worth, here is my ResizeTo method:

public MemoryStream ResizeTo(Stream input, int width)
{
    var output = new MemoryStream();
    input.Seek(0, SeekOrigin.Begin);
    using Image image = Image.Load(input);
    image.Mutate(x => x.Resize(width: width, 0));
    image.SaveAsJpeg(output);
    output.Seek(0, SeekOrigin.Begin);
    input.Seek(0, SeekOrigin.Begin);
    return output;
}

And here is the simple test that is working with .Net Core 3.1 and .Net 5 RC1:

using System.IO;
using System.Threading.Tasks;
using Xunit;

namespace JourneyDoc.API.Services.Tests
{
    public class ImageProcessorTests
    {
        readonly ImageProcessor _imageProcessor = new ImageProcessor();

        [Theory]
        [InlineData(@".\TestData\20200826_132801730")]
        public async Task ResizeTo_ReturnsExpectedOutputAsync(string inputFileName)
        {
            string outputFileName = inputFileName + "_out.jpg";
            using Stream inputStream = new FileStream(inputFileName + ".jpg", FileMode.Open, FileAccess.Read);
            using (MemoryStream lowResStream = _imageProcessor.ResizeTo(inputStream, ImageProcessor.LowResWidth))
            {
                using (Stream outputStream = new FileStream(outputFileName, FileMode.Create, FileAccess.Write))
                {
                    await lowResStream.CopyToAsync(outputStream);
                }
            }
            // Assert.Equals missing here, but image looks fine when just inspected manually
        }
    }
}

[klogeaage]

And the code (fragment) that is not working in .Net 5.0 RC1:

    var imageResizer = new ImageProcessor();
    // Build low-resolution version as well
    using (MemoryStream lowResStream = imageResizer.ResizeTo(destinationStream, ImageProcessor.LowResWidth))
    {
        await _blobStorageClient.UploadAsync(file.FileName, file.ContentType, lowResStream, blobId + 
            ImageProcessor.LowResExtension);
        _logger.LogInformation($"Uploaded low-res image of {blobId}.");
    }
...
    string uri = await _blobStorageClient.UploadAsync(file.FileName, file.ContentType, destinationStream, uploadId);
    destinationStream.Dispose();
    originalStream.Dispose();

All quite simple, I think. Very strange...

The only good thing is that it is going wrong very consistently in the Asp.Net production environment in Azure. So it is not an intermittent problem..

[JimBobSquarePants]

I’m assuming you confirmed that the issue isn’t with the Azure upload by saving the output to the file system before uploading?

[klogeaage]

No, I haven't, but it is uploading the original image as well as video and sound files with no issues, so I don't think there is an issue with that. Also, the Azure blob storage libraries are used extensively in many applications so any problem with those is likely to be reported and fixed very quickly.
And this has been working for months until earlier this week where I did the 5.0 update.

[klogeaage]

@lofcz Could you please elaborate a little on the workaround you mentioned with Cloning the image?

[JimBobSquarePants]

It’s best to check just to rule out any possibilities.

What is ImageProcessor? What happens when you use LoadAsync?

I wouldn’t recommend Clone since that creates an unnecessary copy.

[klogeaage]

ImageProcessor is simply my encapsulation of your library, i.e. it is a service class for the controller. Here it is:

using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Metadata.Profiles.Exif;
using SixLabors.ImageSharp.Processing;
using System.IO;

namespace JourneyDoc.API.Services
{
    public class ImageProcessor
    {
        public const string LowResExtension = ".low";
        public const int LowResWidth = 700;
        public const int DefaultQuality = 90;

        public MemoryStream ResizeTo(Stream input, int width)
        {
            var output = new MemoryStream();
            input.Seek(0, SeekOrigin.Begin);
            using Image image = Image.Load(input);
            image.Mutate(x => x.Resize(width: width, 0));
            image.SaveAsJpeg(output);
            output.Seek(0, SeekOrigin.Begin);
            input.Seek(0, SeekOrigin.Begin);
            return output;
        }

        public Stream ReCompress(Stream input, int quality = DefaultQuality)
        {
            var output = new MemoryStream();
            input.Seek(0, SeekOrigin.Begin);
            using Image image = Image.Load(input);
            image.Mutate(x => x.AutoOrient());
            image.SaveAsJpeg(output, new SixLabors.ImageSharp.Formats.Jpeg.JpegEncoder { Quality = quality });
            output.Seek(0, SeekOrigin.Begin);
            input.Seek(0, SeekOrigin.Begin);
            return output;
        }

        /// <summary>
        /// Rotate image so it always is displayed correctly. Workaround for client not doing this.
        /// </summary>
        /// <param name="input"></param>
        /// <returns></returns>
        public Stream AutoOrient(Stream input)
        {
            input.Seek(0, SeekOrigin.Begin);
            using Image image = Image.Load(input);
            IExifValue exifOrientation = image.Metadata?.ExifProfile?.GetValue(ExifTag.Orientation);
            if (exifOrientation?.GetValue() == null || exifOrientation.GetValue().ToString() == "1")
            {
                input.Seek(0, SeekOrigin.Begin);
                return input;
            }
            var output = new MemoryStream();
            image.Mutate(x => x.AutoOrient());
            image.SaveAsJpeg(output, new SixLabors.ImageSharp.Formats.Jpeg.JpegEncoder { Quality = DefaultQuality });
            output.Seek(0, SeekOrigin.Begin);
            input.Seek(0, SeekOrigin.Begin);
            return output;
        }
    }
}

I don't use LoadAsync or any of the other async methods in ImageSharp, I probably should - do you think it could have a positive effect on this problem? It seems that @lofcz was using them, so now we know it doesn't seem to really influence this issue.

P.S.
It's getting late here in Denmark, so don't expect any immediate response tonight.