Image compression results in artifacts


(Jake Shadle) #1

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 (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. :frowning:

Here is a reference image for what I am talking about, though obviously, this might not work very well. :smile:


(Sam Saffron) #2

@zogstrip are there any switches we can add here?


(Jeff Atwood) #3

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.


(Jake Shadle) #4

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.


(Jeff Atwood) #5

Can you provide a good reference image here so we can test it? Also provide the raw image.


#6

Here’s the original image: https://dl.dropboxusercontent.com/u/1010228/cornellbox.png


#7

Even if artifacts were only in generated thumbnails, it would still be important for us to fix them. Rendering engineers are picky like that :stuck_out_tongue:


(Jeff Atwood) #8

OK, let’s see:


(Jeff Atwood) #9

Looks like it is related to this:

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? :ghost:

I want to go on record, again, that I am opposed to using lossy compression on a lossless format like .png


#10

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?


(Régis Hanol) #11

Just pushed a fix that revert back to using lossless PNG compression :panda_face:

https://github.com/discourse/discourse/commit/92660a74bf2153804f2a8eac32658826f6ac844e

It’s slow as hell though :frowning:


create_upload often very slow
(Jeff Atwood) #12

ALL FIXED! Now, about those battlefront invites…


(Jake Shadle) #13

Awesome, thanks for the quick support!

You can ping @repi about that, me and @kayru are but lowly peons. :wink:


(Jeff Atwood) #15

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.


(Régis Hanol) #16

I just pushed the same change I did last time, and now it works just fine… :confused:

https://github.com/discourse/discourse/commit/933e2ce6b618f8f825f2e2422dc19ae14244b241

Computers, how do they work?


(Jeff Atwood) #17

Looks OK!


(Jake Shadle) #18

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! :smiley:


(Jeff Atwood) #19

Yes we do this for each major release but it would be a productivity tax to do it on each weekly beta release.


(Jeff Atwood) #20