Original:
https://upload.wikimedia.org/wikipedia/commons/0/04/B-control-group-lang-detection-test.png
Interestingly, Phabricator's thumbnailer also makes it look yellow. Do view the original in the image viewer on Phabricator or from the above url.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Gilles | T135862 Some PNG thumbnails have a yellow tint (color profile changed and then dropped by conversion) | |||
| Resolved | Gilles | T136133 Keep iCCP chunk (ICC profile) of PNG originals in thumbnails |
Probably a color profile issue?
$ identify -verbose B-control-group-lang-detection-test.png ... Profiles: Profile-icc: 3900 bytes Description: Color LCD Calibrated Manufacturer: Color LCD Calibrated Model: Color LCD Calibrated Copyright: Copyright Apple Inc., 2016 ...
The thumbnails have no profiles. IIRC the thumbnailer distorting less commonly used color profiles is a pretty common bug class.
An ImageMagick issue; I can reproduce it locally (ImageMagick 6.7.7-10). Also in a less sophisticated desktop image viewer (Shotwell) the original image has the same yellow tint. So there is a color profile changing it into silver (which Chrome recognizes but other image viewers might not) and conversion drops that. Not sure if that's an imagick bug or we just omit some parameter that would tell it to preserve the profile.
It doesn't look like this really would count as a bug in imagick. The PNG specification defines the iCCP chunk as ancillary, meaning it's acceptable behavior for a decoder to ignore it if it doesn't understand it, and the image with the color profile ignored really is the yellowish version.
Seems like an IM bug. I can reproduce on VM with 6.7.7-10, but not on my OS X dekstop with 6.9.3-7
The usual thumbnailing command we use:
convert -quality 95 -background white original.png -thumbnail 120x90! -set comment 'File source: http://dev.wiki.local.wmftest.net:8080/wiki/File:Original.png' +set 'Thumb::URI' -depth 8 -rotate -0 foo.png
We don't use the -strip option, so the ICC profile should be left as-is for PNGs.
That's correct behavior for an unknown ancillary chunk with the "safe-to-copy" bit unset (i.e. "iCCP" rather than "iCCp") when critical chunks are being modified, as is the case with that command. See https://www.w3.org/TR/PNG/#table52 and https://www.w3.org/TR/PNG/#14Ordering.
Interesting, TIL! Thanks for the pointers. "iCCp", however isn't standard, only iCCP is. I tried setting a lowercase p in hexfiend and pngcheck gave me:
original2.png illegal (unless recently approved) unknown, public chunk iCCp
Also, the modified PNG gets a yellow tint in OS X, indicating that iCCp is ignored.
I can't find which version of IM marked the change of behavior for that PNG chunk.
The workaround for the version of IM we use would be to extract the ICC profile with IM or exiftool from the original and to re-apply it to the generated thumbnail.
Yeah, "iCCp" doesn't exist. That's just the name it would have were it safe-to-copy.
Another workaround would be to load the image in something that understands the profile, then save it with no profile or with a profile that IM does know about (if there are any), then reupload.
Thumbor is affected as well. However I have logic in place for JPGs that have non-sRGB color profile that might work for PNGs as well. I'll make a separate task for that.
Maybe something is off with the source file or the specific kind of profile being used.
My ImageMagick thumbor engine does, I haven't tried the default one. Phabricator probably doesn't care about that sort of media fidelity. Google might have made the conscious choice to not include the profile in thumbnails in order to save bandwidth.
LGTM. I guess this was fixed by Thumbor.
These both look the same now (no tint).
Yes, Thumbor copies non-sRGB profiles from the original to the thumbnail. The thumbnail linked in the task description is still broken though, but it's an old cached version. Not sure how that should be purged.
last-modified: Thu, 24 Mar 2016 03:32:41 GMT etag: b12c7f03d1b315d818d1a9b6ff7fe646 x-timestamp: 1458790360.14060 server: ATS/8.0.7 age: 0 x-cache: cp1090 hit, cp1078 pass x-cache-status: hit-local server-timing: cache;desc="hit-local"