-
-
Notifications
You must be signed in to change notification settings - Fork 842
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PNG Encoder produces too huge images and different sizes in Linux and Windows #1027
Comments
OK, at least, I now understand why compression levels 1 to 5 and 6 to 9 give the same results and I now suspect the issue is indeed inside .NET's implementation of By the way for levels 6 to 9, my repro app gives the same results as Linux when targeting net472 under Windows. The so-called optimization of DeflateStream in Windows .NET Core has for side result to double the size of the output... |
@odalet Thanks for raising this and adding so much detail. 👍 I spoke to a member of the MS team last night and he said we should raise an issue against CoreFX. If you could do that and reference this issue hopefully we can figure out why the difference is so dramatic for the zlib instances and get them to provide a fix. Maybe we can convince them to expose the proper compression levels also! Edit... I see you've already added to the existing issue. Great!! |
Thanks for the prompt reaction!
That'd be so great, this CompressionLevel enum does not make much sense to me as well! And by the way, thanks for your great job: the little part of the API I've played with is a pleasure to code against. |
I've been experimenting with a managed 53.9KB using Adaptive filtering at Compression level 9. Results will be identical cross platform. I't's still very much a work in progress though as I have to do a lot of optimization work on the code but I think I can get reasonable performance out of it. |
Thanks for working on this subject! There is no urgency on my side for this to be implemented quickly; and even if there was, I would of course never dare put any pressure on you; I'm simply pleased to notice improvements are on their way! |
@odalet My pleasure! I think my PR is about as good as I can get it now. If anyone else fancies a look though please do. |
I just had a quick look at the PR and it seems that moving to this implementation of zlib has the additional benefit of really using the compression level. Great! |
Sorry in advance for chatting under closed issues, I'm reusing this discussion to avoid TLDR noise under the related dotnet BCL issue. @odalet can you post some details about your use-case (where do your real-life images come from)? I want to use it as an argument, when posting an issue against Intel-Zlib. |
You'll find attached one of the images generated once with .NET Core 2.2 and another time with .NET 4.7.2 (both times on Windows). The generation app depends on ImageSharp 1.0.0-beta0007. Here is some insight on our use case: I hope this helps you understand a bit what we are doing. I'm afraid I can't share here anything too specific about our process. NB: none of these images are really real-world cases ;) because we are still experimenting with our generation process, but they model - at least a part of - the images we'll generate when gone production. That is:
Hope this helps |
@odalet thank you, this helps a lot! |
Prerequisites
DEBUG
andRELEASE
modeDescription
When saving an image to PNG I end up with a file that is more than 5x larger than what I would obtain by using System.Drawing (or Paint.NET)
Attached are the images I generated using ImageSharp, and the same one opened/saved with Paint.NET.
I've tried to tweak the
CompressionLevel
andFilterMethod
(not so sure what this one is about)properties of the encoder, but this changes nearly nothing in the output image size:
FilterMethod
set toAdaptive
, I obtain slightly better results; however, far from my expected 55 KBI can see there's a related issue (#702); however, regardless of the different output sizes in Linux vs Windows, I still think my issue stands as a bug as I'd very much like to be able to obtain a ~50 KB image instead of 300 KB.
Steps to Reproduce
Here is the code I used to exhibit this behavior:
Attachments:
System Configuration
The text was updated successfully, but these errors were encountered: