Closed csboling closed 5 days ago
This is odd. We explicitly wrap non seekable streams https://github.com/SixLabors/ImageSharp/blob/release/3.1.x/src/ImageSharp/Formats/ImageEncoder.cs
I can reproduce this issue when writing to a Zip Output Stream, examining the webp file in a hex editor shows that the header doesn't contain a length value. Using version 2.1.9, it works fine.
Ok. Thanks for investigating. I’m on holiday in Europe currently don’t have access to a laptop just now so will need someone to debug the issue.
I've found a few issues with the current ChunkedMemoryStream
implementation. Rewriting it now.
Fixed via #2828
Prerequisites
DEBUG
andRELEASE
modeImageSharp version
3.1.5
Other ImageSharp packages and versions
N/A
Environment (Operating system, version and so on)
Windows 10 19044.2604, 64-bit
.NET Framework version
.NET 8
Description
Encoding an
Image
as WebP to aMicrosoft.AspNetCore.Http.HttpContext
(a non-seekableStream
) produces an image that cannot be displayed in the browser (Firefox 129.0.2, Chrome 128.0.6613.114) and has a different length and contents from the sameImage
written to a file. Writing anImage
as TIFF in the same way produces a file which cannot be displayed in the Windows image viewer and contains no valid IFDs. All other formats currently supported by ImageSharp produce valid images when written in this way. Tested with bothImage<Rgba32>
andImage<Rgb24>
. I would guess it affects other non-seekableStream
s with these formats as well.Steps to Reproduce
Here is a code sample reproducing the problem. A complete project can be found here: https://github.com/csboling/imagesharp-webp-http
Images
This ZIP contains example 1x1 pixel RGBA32 images encoded to WebP and TIFF to an
HttpContext.Response
, then downloaded with Chrome (invalid.webp, invalid.tif) as well as images encoded directly to a file (valid.webp, valid.tif).examples.zip