Some of our users are complaining about the compression applied to images resulting in corruption, granted these are rendering engineers so they are very…fixated…on this kind of thing. But they do have a valid point, since it seems there is no way in the settings to tweak or influence anything related to image compression, with the one exception of being able to turn off automatic downloading of remote urls for specific patterns/everything.
I can think of at least 2 ways this could be handled in a fairly easy way.
Be able to use a lossless compression algorithm, perhaps even on a per-category basis since it is only problematic for certain areas, not in general.
Disable compression altogether, ditto on the per-category basis.
According to the image compression gem (I think this is what is being used), it looks like lossless compression is available, but my Ruby-fu is not strong enough at the moment to do something myself that I would have any confidence in.
Here is a reference image for what I am talking about, though obviously, this might not work very well.
I assume it is the generated image thumbnail you are referring to? Can they click through to expand to the original full-size image, that should be unmodified.
That was my original thought as well, since then the artifacts would most likely be coming from whatever filter was used to downsample the image, but apparently it’s present in both the thumbnail and the original image.
TinyPNG uses smart lossy compression techniques to reduce the file size of your PNG files. By selectively decreasing the number of colors in the image, fewer bytes are required to store the data. The effect is nearly invisible but it makes a very large difference in file size!
“nearly invisible”, eh?
I want to go on record, again, that I am opposed to using lossy compression on a lossless format like .png…
I think we are making things difficult for TinyPNG. The original image is produced by a path tracer and is inherently noisy. I can imagine that being a difficult case for any compression algorithm that’s optimized for smooth images, like photographs.
Agreed. If we’re going lossy, might as well use jpeg. Is it feasible to add an option in Discourse to disable compression?
Cool guys, thanks for persisting and fixing this! I assume it will make it into the next beta update?
On that note (and maybe this should be a separate thread), would it be possible to have some kind of summary of the features/fixes/tweaks etc available in the web based update? As it is it just gives you a link to the git repo, so you end up having to figure out which commits have happened since the last release which isn’t very helpful since a lot of things change in between updates and most commits don’t really mean very much if you are not familiar with the actual codebase.
I think because the velocity of Discourse is so high, it would be a really nice thing to have for all of the Discourse forums out there, since it would allow the admins to communicate with their community after they do an upgrade to say “Hey, we just upgraded and we now have feature X that you have been asking for, try it out!”.
