Hmm, looks like that’s exactly what the forum did. Sigh. Is there a place in the forum to upload files and not have them be modified in any way? These two files that I tried to post links to are really good test files. But turning them into jpegs completely mitigates their value.
I’m confused slightly - the first image in your post is a 16-bit png. (Click on the image, then use the download link.
Can you try again with just the second image on a post of it’s own? You’re certain both were png files?
If it’s converting them to jpg, why did it not do your first image as well? I can try testing again a little later today, but you want to try attaching the smooth radial gradient image again (or someone), we can see what’s going on.
We absolutely can add these to the github repo as well (or on the main site), but I’d rather track down what’s going on with attaching them to posts first and get that sorted out to work as expected.
Hmm, another difference is the linear gamma profile in the large png is a V2 profile (linear gamma Rec.2020), and in the smaller png it’s a V4 profile (linear gamma sRGB). Functionally there should be no difference.
Hmm, after the server did its thing, the file was renamed and made smaller.
Hmm, after downloading the resized png-turned-to-jpeg, the embedded ICC profile is RT_sRGB gamma sRGB(IEC61966 equivalent), which is not the profile that was embedded in the original png that I uploaded- very inventive that server must be!
@patdavid Posting images have been tricky for me as well. In fact, I cannot reliably predict the behavior. What I know is that providing an external link tends to alter the file more than when using the upload tool. So, I usually acquire a local copy beforehand.
I guess there are a number of other factors such as what is happening upstream, the size, properties, etc., of the image in question. One feature that I would like the file to retain consistently is the file base name. At one point, this was true but now it is just a long string of nothing. Also, a chance to change the base name. E.g., I sometimes upload nonsense names such as _.jpg, forgetting to change it before uploading. I can change the post raw contents but the discourse system still shows the old name (and downloads it with a long name).
The server creates multiple versions of the images on upload to serve for different purposes. The resized version is what will show in posts, usually as a jpg, in order to save on load times/bandwidth. In this context it is what makes the most sense for the use-case of a forum in general. For that reason, I’m not at all perturbed by the change in the embedded image in the post itself.
The full-size image, on the other hand, should stay the same as what was uploaded.
We did submit a patch to fix the embedded color profile being stripped, but now I’m wondering if it regressed somewhere along the line. When I get some time I’ll test with one of @houz test jpg files we used earlier. In order to avoid derailing this original thread, I’ll probably go ahead and move the relevant posts to a new topic.
However, if the image is less than or equal to 690px in width, then this may not hold true. That said, all I have been writing is based on my memory, so it may not be true .
Well, using exiftool will show whether a png has an embedded ICC profile, and if so, what profile it is. Here is the terminal output for a sample png with an embedded profile:
$ exiftool linear-srgb-blocks-gradients.png
ExifTool Version Number : 10.63
File Name : linear-srgb-blocks-gradients.png
Directory : .
File Size : 15 kB
File Modification Date/Time : 2017:11:18 07:10:38-05:00
File Access Date/Time : 2017:11:18 07:10:38-05:00
File Inode Change Date/Time : 2017:11:18 07:10:38-05:00
File Permissions : rw-r--r--
File Type : PNG
File Type Extension : png
MIME Type : image/png
Image Width : 747
Image Height : 590
Bit Depth : 16
Color Type : RGB
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
Profile Name : ICC profile
Profile CMM Type : lcms
Profile Version : 4.3.0
Profile Class : Display Device Profile
Color Space Data : RGB
Profile Connection Space : XYZ
Profile Date Time : 2016:05:01 13:25:01
Profile File Signature : acsp
Primary Platform : Unknown (*nix)
CMM Flags : Not Embedded, Independent
Device Manufacturer :
Device Model :
Device Attributes : Reflective, Glossy, Positive, Color
Rendering Intent : Perceptual
Connection Space Illuminant : 0.9642 1 0.82491
Profile Creator : lcms
Profile ID : 0
Profile Description : sRGB-elle-V4-g10.icc
Profile Copyright : Copyright 2016, Elle Stone (http://ninedegreesbelow.com/), CC-BY-SA 3.0 Unported (https://creativecommons.org/licenses/by-sa/3.0/legalcode).
Media White Point : 0.9642 1 0.82491
Chromatic Adaptation : 1.04788 0.02292 -0.05022 0.02959 0.99048 -0.01707 -0.00925 0.01508 0.75168
Red Matrix Column : 0.43604 0.22249 0.01392
Blue Matrix Column : 0.14305 0.06061 0.71393
Green Matrix Column : 0.38512 0.7169 0.09706
Red Tone Reproduction Curve : (Binary data 16 bytes, use -b option to extract)
Green Tone Reproduction Curve : (Binary data 16 bytes, use -b option to extract)
Blue Tone Reproduction Curve : (Binary data 16 bytes, use -b option to extract)
Chromaticity Channels : 3
Chromaticity Colorant : Unknown (0)
Chromaticity Channel 1 : 0.64 0.33002
Chromaticity Channel 2 : 0.3 0.60001
Chromaticity Channel 3 : 0.15001 0.06
Device Mfg Desc : sRGB chromaticities from A Standard Default Color Space for the Internet - sRGB, http://www.w3.org/Graphics/Color/sRGB; also see http://www.color.org/specification/ICC1v43_2010-12.pdf
Image Size : 747x590
Megapixels : 0.441
Why do you suppose this is? Pngs have supported ICC profiles for a long time.
On the other hand, support for ICC profile color management for pngs isn’t as good as it is for jpegs and tiffs, meaning the occasional color-managed software still does have various issues with recognizing that pngs can have embedded ICC profiles, for example Geeqie doesn’t color-manage pngs.
I have no idea. I remember asking the why and how back when support was truly thin. Nowadays, it isn’t a problem for me but now I have gotten into the habit of using JPGs and TIFs. Maybe what people are used to is the answer.
Hi @patdavid - according to exiftool, that’s actually a grayscale image that has an RGB ICC profile embedded - I removed some parts of the exiftool output to make it easier to see the relevant parts:
$ exiftool *16b96.png
ExifTool Version Number : 10.63
File Name : 55a2dd8ee55a4b02f9c0169ce93d80243fe16b96.png
Directory : .
File Size : 1695 kB
File Type Extension : png
MIME Type : image/png
Image Width : 1200
Image Height : 1200
Bit Depth : 16
Color Type : Grayscale
Profile Name : ICC profile
Profile CMM Type : lcms
Profile Version : 2.2.0
Profile Class : Display Device Profile
Color Space Data : RGB
Profile Connection Space : XYZ
Profile Copyright : Copyright 2016, Elle Stone (http://ninedegreesbelow.com/), CC-BY-SA 3.0 Unported (https://creativecommons.org/licenses/by-sa/3.0/legalcode).
Media White Point : 0.95045 1 1.08905
Media Black Point : 0 0 0
Red Matrix Column : 0.67349 0.27904 -0.00194
Green Matrix Column : 0.16566 0.67535 0.02998
Blue Matrix Column : 0.12505 0.04561 0.79686
Red Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Green Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Blue Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract)
Profile Description : Rec2020-elle-V2-g10.icc
Image Size : 1200x1200
Megapixels : 1.4
Opening the downloaded file in GIMP-2.9, GIMP identified it as a grayscale image, discarded the embedded RGB ICC profile, and assigned the GIMP built-in grayscale profile. Assigning a linear gamma profile from disk does restore the proper tonality.
If all three channels of an image are identical, imagemagick will automatically set the colorspace to grayscale.
a. If it’s a jpeg, to fix this, set -define colorspace:auto-grayscale=off
b. If it’s a PNG, set the output file to PNG24:outfile.png
For example, on Imagemagick 6.9.5-7 Q16:
$ convert.exe linear-rec2020-radial-smooth-gradients.png test.png
convert: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG 'test.png' @ warning/png.c/MagickPNGWarningHandler/1656.
The logic to manage this edge case severely complicates the forum image handling code.
The solution
If you need to use weird colorspaces or custom profiles, then zip/tar/bzip the file up and upload that. Then you can be assured the file will transfer as-is.
Other images you want people to see should all work fine, even in sRGB, AdobeRGB or some other colorspace (that is, our patch from last year should have fixed the colorspace getting nuked).
OK, my apologies, but I don’t know what a weird color space or custom profile is. Could you be more specific?
If it helps, to convince ImageMagick to behave itself with RGB pngs in which R=G=B everywhere, the png equivalent to "-type TrueColor " is “-define png:color-type=2”.
.
