DEBUG and RELEASE modeLoading the following PNG (from a Stream or ReadOnlyMemory<byte> instance) throws an ArgumentException.
https://user-images.githubusercontent.com/561862/54476020-e3ab4c00-47ce-11e9-9cb1-2542507bf23c.png
Which has the following message:
Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
Notes:
Use the above image in a FileStream (or any Stream representation).
Load the image (this can be copied/pasted into a .NET Core 2.2 console app and the ImageSharp libraries referenced):
````
static async Task Main()
{
try
{
// Use http client.
var client = new HttpClient();
// Make the request.
using (Stream stream = await client.GetStreamAsync(
"https://user-images.githubusercontent.com/561862/54476020-e3ab4c00-47ce-11e9-9cb1-2542507bf23c.png")
.ConfigureAwait(false))
{
Image<Rgba32> image = Image.Load<Rgba32>(stream, new PngDecoder());
}
}
catch (Exception e)
{
Console.WriteLine(e);
throw;
}
}
````
Hi there,
I did find this as an issue but had to set the decoder explicitly to being a png otherwise it failed. This was in a .NET Core solution as well whereby I loaded via a stream from Blob Storage in Azure, just giving more information to help.
@clintonrocksmith Thanks for the reply, much appreciated.
That said, I didn't have any luck setting the decoder explicitly. Using HttpClient to download the link above, I still get the same error using this:
````
static async Task Main()
{
try
{
// Use http client.
var client = new HttpClient();
// Make the request.
using (Stream stream = await client.GetStreamAsync(
"https://user-images.githubusercontent.com/561862/54476020-e3ab4c00-47ce-11e9-9cb1-2542507bf23c.png")
.ConfigureAwait(false))
{
Image<Rgba32> image = Image.Load<Rgba32>(stream, new PngDecoder());
}
}
catch (Exception e)
{
Console.WriteLine(e);
throw;
}
}
````
May I ask how you were able to get it to load?
@casperOne @clintonrocksmith The two issues are not related. There鈥檚 something about that png that causes our current decoder to fail. I fixed the issue locally today though.
The other issue sounds like it was due to the input stream being in the wrong position for us to identify the decoder.
@JimBobSquarePants Thanks for the follow-up. I'll keep an eye on this to be closed when a PR gets merged. Looking forward to the next push to Nuget for the fix.
Thanks!
@casperOne Don't forget we have rock solid development releases on Myget
@JimBobSquarePants Thanks for addressing this, I've confirmed this works, and have used the MyGet repository.