# Image compression results in artifacts
**URL:** https://meta.discourse.org/t/image-compression-results-in-artifacts/31079
**Category:** Feature
**Created:** [July 15, 2015, 2:07pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079 "2015-07-15T14:07:52Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@Jake\_Shadle](https://meta.discourse.org/u/Jake_Shadle)
#### Post date: [July 15, 2015, 2:07pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/1 "2015-07-15T14:07:52Z")
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.
1. 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.
2. Disable compression altogether, ditto on the per-category basis.
According to the [image compression gem](https://rubygems.org/gems/image_optim) (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. 😄
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [July 15, 2015, 9:46pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/2 "2015-07-15T21:46:24Z")
@zogstrip are there any switches we can add here?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 15, 2015, 9:49pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/3 "2015-07-15T21:49:05Z")
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.
---
### Author:  [@Jake\_Shadle](https://meta.discourse.org/u/Jake_Shadle)
#### Post date: [July 15, 2015, 9:50pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/4 "2015-07-15T21:50:14Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 15, 2015, 9:51pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/5 "2015-07-15T21:51:53Z")
Can you provide a good reference image here so we can test it? Also provide the raw image.
---
### Author:  [@kayru](https://meta.discourse.org/u/kayru)
#### Post date: [July 16, 2015, 8:53am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/6 "2015-07-16T08:53:39Z")
Here’s the original image: [https://dl.dropboxusercontent.com/u/1010228/cornellbox.png](https://dl.dropboxusercontent.com/u/1010228/cornellbox.png)
---
### Author:  [@kayru](https://meta.discourse.org/u/kayru)
#### Post date: [July 16, 2015, 8:57am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/7 "2015-07-16T08:57:59Z")
> [@codinghorror](#):
>
> 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.
Even if artifacts were only in generated thumbnails, it would still be important for us to fix them. Rendering engineers are picky like that 😛
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 17, 2015, 8:23am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/8 "2015-07-17T08:23:18Z")
OK, let’s see:
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 17, 2015, 8:26am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/9 "2015-07-17T08:26:23Z")
Looks like it is related to this:
> [https://tinypng.com/](https://tinypng.com/)
>
> 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`…
---
### Author:  [@kayru](https://meta.discourse.org/u/kayru)
#### Post date: [July 17, 2015, 9:03am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/10 "2015-07-17T09:03:23Z")
> [@codinghorror](#):
>
> “nearly invisible”, eh?
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.
> [@codinghorror](#):
>
> I want to go on record, again, that I am opposed to using lossy compression on a lossless format like .png…
Agreed. If we’re going lossy, might as well use jpeg. Is it feasible to add an option in Discourse to disable compression?
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [July 17, 2015, 9:05am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/11 "2015-07-17T09:05:50Z")
Just pushed a fix that revert back to using lossless PNG compression 🐼
[https://github.com/discourse/discourse/commit/92660a74bf2153804f2a8eac32658826f6ac844e](https://github.com/discourse/discourse/commit/92660a74bf2153804f2a8eac32658826f6ac844e)
It’s slow as hell though ☹
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 17, 2015, 9:15am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/12 "2015-07-17T09:15:57Z")
ALL FIXED! _Now, about those battlefront invites…_
---
### Author:  [@Jake\_Shadle](https://meta.discourse.org/u/Jake_Shadle)
#### Post date: [July 17, 2015, 9:21am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/13 "2015-07-17T09:21:02Z")
Awesome, thanks for the quick support!
> [@codinghorror](#):
>
> Now, about those battlefront invites…
You can ping @repi about that, me and @kayru are but lowly peons. 😉
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 18, 2015, 2:12am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/15 "2015-07-18T02:12:55Z")
We had to revert that change for a bit here is the PNG uploaded with much less aggressive lossy optimization
Still bad though so we will need to fix the lossless compression.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [July 22, 2015, 4:13pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/16 "2015-07-22T16:13:15Z")
I just pushed the same change [I did last time](https://github.com/discourse/discourse/commit/92660a74bf2153804f2a8eac32658826f6ac844e), and now it works just fine… 😕
>
_Computers, how do they work?_
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 22, 2015, 7:13pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/17 "2015-07-22T19:13:35Z")
Looks OK!
---
### Author:  [@Jake\_Shadle](https://meta.discourse.org/u/Jake_Shadle)
#### Post date: [July 23, 2015, 8:14am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/18 "2015-07-23T08:14:25Z")
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!”.
Anyway, just some thoughts! 😃
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 23, 2015, 9:20am UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/19 "2015-07-23T09:20:35Z")
Yes we do this for each major release but it would be a productivity tax to do it on each weekly beta release.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 15, 2015, 7:55pm UTC](https://meta.discourse.org/t/image-compression-results-in-artifacts/31079/20 "2015-09-15T19:55:32Z")