That’s correct and actually due to how browsers behave.
Zammad does not compress / touch the original image if you attach the file to the article directly.
The reasons for this behavior can be found here:
Possibly indirectly caused by Inline image conversion from jpeg to png causes huge overhead · Issue #3538 · zammad/zammad · GitHub as well.
Note that most browsers do run some level of compression automatically as they’re trying to be more and more clever. This can cause issues. I checked on the relevant change mentioned above and can’t find a reason for compression.
When I checked attached image I could note slight compression which does save storage by factor 2.5 but does not affect readability. Might be because of the chosen file through.
I’m not entirely sure if this is really a Zammad bug. I suspect this is rather a browser thing.
Above image is compressed just to a similar factor like in Zammad. I believe it’s okay… any way.
This might be related to our maximum 1000px width setting. I believe this is for browser performance reasons but a developer might have deeper insights.
Thank you very much for your explanation.
So I did some tests in Chrome and Firefox. I pasted a screenshot in my Firefox session. In Firefox it looks ok (everything is readable, although the image is still compressed). When I look at the same image in Chrome, it looks worse and is barely readable. Funnily enough when I paste something in the Chrome session it looks bad in Chrome but looks ok in Firefox.
Looks like I’ll be using Firefox more in the future.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.