Image upload color profile

All,

@houz noticed over on this thread:

That in some cases images uploaded to the forum will have their embedded color profiles stripped.

The forum will usually fetch external images and save them locally to make sure there are no broken image links. The problem is that during the fetch the image is passed through imagemagick to generate smaller versions (if needed), and the save process strips the embedded profile.

I have asked the upstream discourse developers if they can allow an option to either not strip the color profile, or to possibly convert the image to sRGB, and then identify it as such during the imagemagick pipeline:

For now, if you are going to link images to the forum that have a color profile other than sRGB, please convert to sRGB first before uploading (so the colors don’t get all wonky – see the first post I linked above).

Thanks for the head-up @patdavid
Or use http://filebin.net/ until the problem is fixed upstream.

Even when hosting the images elsewhere (as I was doing with mine) the forum still fetches them.

I can’t answer over there on the discuss website, but IIUC then images are first passed through convert and optipng afterwards. So if the convert call made sure that the image is sRGB everything would be fine and dandy. In the linked code I can see two places where convert is called. You could try adding -profile sRGB.icc to those (and put that profile into the directory). I often use the following script to convert RGB to CMYK images, maybe it’ll show you how to use that option:

#!/bin/sh
if [ "$#" -ne 4 ]; then
  echo "Usage: $0 <input image> <input profile> <output image> <output profile>" >&2 
  exit 1
fi
convert $1 -alpha off -profile $2 -profile $4 -alpha on $3

When omitting the first -profile it should use the embedded profile which is what we want here.

Yes, it’s doing that to avoid broken images in the forum. They responded to me over on meta.discourse.org with a link to the relevant section of code (in ruby). Now I just need to see about getting a test environment setup to test it…

I tried their call to convert, just adding -profile sRGB.icc after quality does the trick for me.

1 Like

Ok, we’re issuing a PR to discourse for the fix, with -profile RT_sRGB.icm added just before output during optimization. It appears to fix the problems on our test discourse.

Thanks to @darix and @patdavid the proposed changes were accepted upstream and active here, too.

This is rotate 180° from the original farbkreis.jpg (and uploaded directly):

Are the colors supposed to match the words? Or is it not fixed yet? They don’t match for me on mobile Firefox 44.0.2; rot is blue.

We’re still fiddling with this at the moment. :smiley:
fingers crossed! :wink:

270° rotation:

uploaded, rotate 315°:

I was reading another color management thread and thought about this one… Seems discourse still hasn’t taken the patch. :pouting_cat:

Well, I’m not sure. They accepted the patch upstream, but it obviously isn’t working. So now I’m worried that the patch was ineffective. This warrants further checking and investigation, I think.

This should be fixed now. The image metadata should be preserved now.

1 Like