Grayscale images get belgium-ed
-
Continuing the discussion from Mad Hatter Hijinx:
Followup: SPOT THE DISCOURSISTENCY!
<img src="/uploads/default/13745/a82e9bffd88cf6c0.png" width="690" height="275">
Let me guess... it got scaled, one red pixel got lost in the process and it got darkened, AGAIN!
$@#%#$%^$#@^%&#$%^#$%^#%^
Uploading a purely grayscale image causes the image to be darkened when displayed by discourse. This applies to images in posts, as well as images uploaded as avatars. for example, take this image:
This is much darker that the image is supposed to be. However, if I shift the R,G, or B value of a single pixel, it will display correctly. In this case, I have shifted the top left pixel from (172,172,172) to (173,172,172). This is the only change I have made between the source images.
Now, because of the R value being shifted in one pixel, the image is being displayed accurately.
Unfortunately, this fix is not reliable for avatars. Once the image is scaled down, the shifted pixel gets lost and the smaller image gets darkened again. As a result, you can end up with a grab bag of light and dark avatars. To make it work for avatars, you pretty much need to shift a region of pixels, instead of just a single pixel.
-
Reported on meta.d:
-
Discourse should be doing image resize, and that's it. There's no reason for it to re-gamma grayscale images.
-
There was no reason for it to display an MD5 hash of an asterisk either, but that was the situation we were in for a while. How does this sort of thing come about unintentionally?
-
How does this sort of thing come about unintentionally?
This is discourse we're talking about. Complete with discodevs.
-
Unfortunately, this fix is not reliable for avatars.
fun fact humans are typically not able to distinguish a color that is off by 1 in one of the RGB octets than the other.
make the whole background 173, 172, 172 and it should survive resize. ;-)
-
fun fact humans are typically not able to distinguish a color that is off by 1 in one of the RGB octets than the other.
make the whole background 173, 172, 172 and it should survive resize. ;-)
You mean like I did for @signatureguy?
Or mentioned here?
-
I agree with whatever @abarker posted just above.<t7704p7>
-
My guess is that the gamma gets fucked up - the difference is that one of the images is stored as a grayscale PNG and the other as a
RGB8-bit colormap PNG. Manually setting the gamma to 1/2.2 on the darker one seems to fix it.Doesn't happen with my version of ImageMagick (6.8.9), though. (It also converts to grayscale when possible, but not to the colormap.)
-
My guess is that the gamma gets fucked up - the difference is that one of the images is stored as a grayscale PNG and the other as a <strike>RGB</strike> 8-bit colormap PNG. Manually setting the gamma to 1/2.2 on the darker one seems to fix it.
Doesn't happen with my version of ImageMagick (6.8.9), though. (It also converts to grayscale when possible, but not to the colormap.)
Not sure what version of ImageMagick dicsourse uses, but a response on meta.d indicates that they use ImageMagick and ImageOptim. Maybe it's ImageOptim that's causing the issue.
-
root@forum:/# convert --version Version: ImageMagick 6.7.7-10 2014-03-06 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC Features: OpenMP
@sam perhaps a base image upgrade is in order?
-
I tried upgrading it once before and it made no diff, will look at this issue again next week.
-
Is it anything adding
-set colorspace RGB
to the convert command would fix?
-
Definitely something up here, has been reported a few times, seems specific to greyscale images somehow.
-
seems specific to greyscale images somehow.
That would be indicated by the fact that changing a single pixel to no longer be truly gray prevents the issue, as described in the OP here and in the bug report on meta.d. Also in posts 6 and 7 of this topic, as well as the posts linked to by post 7 of this topic.
tl;dr: we already know it's specific to grayscale.
Edit: Oh, and I forgot to mention the title of this topic points out the very same thing.
-
no damage in trying it sounds like it could work, expiring all the old sized down images is going to be hell though.
Before all of this I need to start from a clean repro command line repro, can anyone repro the issue directly from command line outside of Discourse?
-
title of this topic points out the very same thing.
I read the title as "grayscale images get legumes" and thought to myself, delicious humous.
-
Before all of this I need to start from a clean repro command line repro, can anyone repro the issue directly from command line outside of Discourse?
Nope, no repo so far. I wanted to look at the raw info in the PNGs (i.e., the gAMA chunk and the raw pixel values) and see if anything's fishy there. Haven't gotten around to it yet, though.
-
Do you have a link to an original image (not a discourse-modified one) that causes the problem?
-
root@forum:/# convert --version
Version: ImageMagick 6.7.7-10 2014-03-06 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP@sam perhaps a base image upgrade is in order?
I tried upgrading it once before and it made no diff, will look at this issue again next week.
According to this, there were some grayscale issues in the IM version @riking posted. I have 6.8.9-3 installed and cannot reproduce the problem.
-
@sam we should update ImageMagick version for sure, we need a new base image anyway.
-
aha, I think I fixed it
I will check to see if an image magic upgrade fixes it as well
-
http://www.imagemagick.org/discourse-server/viewtopic.php?t=23435
It's strange that the folder named
discourse-server
contains neither Discourse nor a server.
-
I just tried 6.9 and it exhibits the same issue until I force colorspace ...
-
We still do not have a fix for this unfortunately. Sam's idea affected gamma on ALL images which was.. bad. So that had to be reverted. And we know upgrading to latest ImageMagick does not help.