Webp green pixels at the bottom of picture #112
-
Hi! I really appreciate your tool it's working fantastic. I have an issue with the .webp format and I hope you can help me. I'm using the 0.13.2 version of MagicScaler and the 1.2.4-preview1 version of "PhotoSauce.NativeCodecs.Libwebp". I registered the codecs at the start-up: In the image process, the input is a byte array and the output is a stream which I convert back to a byte array. I set the encoder format like this: These are my settings: I would really appreciate it if you could give me any further ideas on what can I do to prevent this issue. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
Howdy! Glad you're finding the library useful. That output looks like a bug, possibly to do with the odd crop height. I'd need a full repro to diagnose it, though. Can you share your full code, environment info, and source image? |
Beta Was this translation helpful? Give feedback.
-
If I send you the repo and the source image via email, is that work for you? Unfortunately, the real repo is inside an organization. |
Beta Was this translation helpful? Give feedback.
-
I was able to reproduce the issue with this code snippet as well. It's a net7.0 console app. Windows 11, dotnet version: 7.0.203 using System.Drawing;
using PhotoSauce.MagicScaler;
using PhotoSauce.NativeCodecs.Libwebp;
CodecManager.Configure(codecs => { codecs.UseLibwebp(); });
var image = Image.FromFile("D:\\ImageProcessor\\cheetah.jpg");
using var ms = new MemoryStream();
image.Save(ms,image.RawFormat);
var bytes = ms.ToArray();
var settings = new ProcessImageSettings { Height = 465 };
settings.TrySetEncoderFormat(ImageMimeTypes.Webp);
using var outputStream = new MemoryStream();
MagicImageProcessor.ProcessImage(bytes, "D:\\ImageProcessor\\cheetah_output.webp", settings); |
Beta Was this translation helpful? Give feedback.
Thanks! I was able to reproduce the issue using your sample.
There is an off-by-1 bug in the encoder that's triggered by an image height that happens to be exactly one greater than a multiple of 8 (e.g. 465 = 58 * 8 + 1) under certain circumstances, leaving the last row of the image undefined. The fix is simple, but I'll need to adjust my release strategy to get an updated package published. Might take me a few days to figure out the best way to handle it.