Closed Bug 1135380 Opened 10 years ago Closed 8 years ago

Bad rendering of png processed by imagemagick

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
35 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: lemaitre.dulotus, Assigned: glennrp+bmo)

References

Details

(Whiteboard: gfx-noted)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150126171358 Steps to reproduce: I took some screenshots of a movie with mpv. Some of theses screenshots (Bluray and KINeMA720) were processed with a simple imagemagick script like : for i in {1..60}; do convert bak/SinKINe801/SinKINe801_$i.png -background black -extent 1920x802 SinKINe801/SinKINe801_$i.png; done I uploaded theses screenshots to my dropbox : https://dl.dropboxusercontent.com/u/105404/Sin/ScreenComp.html Actual results: Screenshots that weren't processed by imagemagick render in Firefox like they rendered in my image viewer. Screenshots that were processed by imagemagick render in firefox with wrong/darker colors. All the screenshots render with good colors in Webkit-Konqueror/Chromium. All the screenshots render with "good" colors in the image viewer. Expected results: All the scenshots should render with "good" colors in Firefox.
Are you by chance using color profiles?
Flags: needinfo?(lemaitre.dulotus)
Hum... I don't know... I have done nothing fancy at least... Find that on google : http://cameratico.com/guides/firefox-color-management/ Modes 1 and 2 have the issue. Mode 0 gives me right colors for all the images. Someone told me a few hours ago that imagemagick could indeed be the culprit. Maybe it is tagging wrong color profiles ? Color profiles that would only be "read" by Firefox...
Flags: needinfo?(lemaitre.dulotus)
Component: Untriaged → ImageLib
Product: Firefox → Core
Some versions of ImageMagick (I think version 6.7.7 through 6.9.0) write grayscale images with gamma = 1 (linear). Use "convert|head -2" or "convert -version" to find out what you're using.
Any ideas here?
Flags: needinfo?(seth)
Whiteboard: gfx-noted
I still have the bug with this version : Version: ImageMagick 6.9.3-0 Q16 x86_64 2016-01-16 http://www.imagemagick.org Features: Cipher DPC HDRI Modules OpenCL OpenMP Delegates (built-in): bzlib cairo fftw fontconfig freetype gslib jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png ps rsvg tiff webp wmf x xml zlib
The ImageMagick-processed files contain gAMA=0.45455 chunks while the others contain no color-management info. for x in *.png; do echo $x; pngcheck -v $x | grep gAMA; done SinBluRay01.png chunk gAMA at offset 0x00025, length 4: 0.45455 SinKINe800pad_01.png chunk gAMA at offset 0x00025, length 4: 0.45455 SinMCgrainYama01.png SinMCYama01.png You can use the "-strip" option to prevent ImageMagick from adding the gAMA chunk.
See Also: → 621474
Good to know ! Thanks :)
The issue is still there, e.g. with a PNG created with simple Bitmap Save from .NET (Or created in Paint) I wrote a bit more on it here with examples, and quite small 150b test-files. Both FF and Chrome are affected, but IE/Edge are NOT affected. http://eskerahn.dk/wordpress/?p=1566 (It is NOT the qAMA tag it is in both files, see the hex dumps)
The two test files at eskerahn.dk (ColourChart_1-300x300.png and ColourChart_2-300x3--.png) are identical (they have identical content, not just looking identical). Both contain a 3144-byte sRGB profile which is known to be faulty. The 4048x3036 jpeg does not contain any color profile, while the "1800x1200" one (actually 1600x1200) contains the 3144-byte color profile. The appearance of the Firefox rendering would depend upon the gfx.color_management_mode setting. Matters should improve if you replace the 3144-byte color profile with a good sRGB color profile, or, in the PNG files, replace it with the sRGB chunk.
You need to click to enlarge, or look at the small blue ones. (wordpress is confusingly creating identical reduced versions) Do you see the difference for the small blue ones?
(sorry for the confusion, have clarified the text)
All right, I clicked to enlarge then downloaded ColourChart_1.png and ColourChart_2.png. 1 has the sRGB chunk while 2 does not. Both have a gAMA .45455 chunk. The pHYs chunks are slightly different but that's irrelevant. The IDAT data (pixels) is identical. With Firefox 49 and 52a1 running on Ubuntu 16:04 I can't see the color problems that you described. "pngcheck -v ColourChart_?.png" says File: ColourChart_1.png (64052 bytes) chunk IHDR at offset 0x0000c, length 13 956 x 956 image, 32-bit RGB+alpha, non-interlaced chunk sRGB at offset 0x00025, length 1 rendering intent = perceptual chunk gAMA at offset 0x00032, length 4: 0.45455 chunk pHYs at offset 0x00042, length 9: 3779x3779 pixels/meter (96 dpi) chunk IDAT at offset 0x00057, length 63945 zlib: deflated, 32K window, fast compression chunk IEND at offset 0x0fa2c, length 0 No errors detected in ColourChart_1.png (6 chunks, 98.3% compression). File: ColourChart_2.png (64039 bytes) chunk IHDR at offset 0x0000c, length 13 956 x 956 image, 32-bit RGB+alpha, non-interlaced chunk gAMA at offset 0x00025, length 4: 0.45455 chunk pHYs at offset 0x00035, length 9: 3780x3780 pixels/meter (96 dpi) chunk IDAT at offset 0x0004a, length 63945 zlib: deflated, 32K window, fast compression chunk IEND at offset 0x0fa1f, length 0 No errors detected in ColourChart_2.png (5 chunks, 98.3% compression). And ImageMagick's "identify" shows that the pixel data are identical: identify -verbose ColourChart_?.png | grep igna signature: a2ec78ab6f0a78c2bffce99ed5e598d400916a624b13b2a4cb1029127392bd69 signature: a2ec78ab6f0a78c2bffce99ed5e598d400916a624b13b2a4cb1029127392bd69
Assignee: nobody → glennrp+bmo
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I meant to mention that I used gfx.color_management.mode=1 and 2.
I'm also not seeing any difference between the appearance of ColourChart_?.png with chrome Version 54.0.2840.59 (64-bit)
Interesting that the data section of the two is identical, Thanks. I never checked that - sorry, but yes, except the 13 bytes longer header, the files are binary identical, so the only differences seems to be in the pHYs segment and the extra sRGB. But I guess the easily reproducible 16x16 files would be more handy to work with for debugging. Anyway the big question is why does clean blue generate purple pixels in FireFox when the sRGB tag is present? (both for gfx.color_management.mode set to 1 and 2) And even more weird, why does some see the problem and others does not??? When I spotted it on dpreview a few more joined in with the exact same issue. And you can find a few screendumps of real life versions of the bug here: https://www.dpreview.com/news/7796952518/google-posts-gallery-from-upcoming-pixel-smartphone?comment=0774331134 I I understand the previous postings in the matter it OUGHT to be the sRGB one that was reproduced correctly, and the one without that should be problematic. But it is the other way round, and that to the extend where colours end as the same. e.g. several ends as pure green 00FF00, as described in red print here http://eskerahn.dk/wordpress/wp-content/uploads/2016/10/ColourChart_1_2_cmp.png
You've probably got a bad display profile on your system. When the sRGB chunk is present and Firefox gfx.color_management.mode is non-zero, the image will be handled with Firefox's CMS (color management system). When only a gAMA chunk is present, that's not sufficient information for the CMS so the gamma correction is done inside libpng, without using the system display profile. You can find out what display profile you are using by looking at about:build, gfs.color_management.display_profile (but sorry I can't help you with replacing it with a better one).
Thanks for the input. But note that it is when the SRGB tag *IS* present there is a problem, NOT with files where it is omitted. So per your description it IS the firefox CMS that is causing the issue. I assume you mean "about:config" and "gfx.color_management.display_profile"? And that string is blank on both my FireFox and DevFox BTW.
**NOTE** Things works if I set gfx.color_management.mode to ZERO. :-) That is disabling firefox CMS (If I understand your post correctly) So this seems to indicate further that the Firefox CMS is in error - or at the least do not work correctly with other parts of the system.
Right. Setting gfx.color_management.mode to zero disables Firefox CMS. So does omitting the sRGB chunk. But as I said, I think the error is in your display profile. The CMS works with what it's got, and if the display profile is bad, then the image will be rendered poorly.
Thank you again. Well it might well be so, but both monitors has the default profiles. But perhaps it could be intel's driver that has some error, as this would be the common factor. I think it is highly unlikely that both Lenovo and Phillips should have made the same error in their profiles for their monitors - though of course not impossible I just found this test page: http://petapixel.com/2012/06/25/is-your-browser-color-managed/ And it displays the car CORRECTLY with both 1 and 2 but not zero, so setting it to zero only fixes it for some images. So sort of back (near) to square one...
Do I conclude correctly if I claim that the real problem is if someone marks a file as sRGB, but without providing the corresponding colour profile embedded in the file? That is FireFox needs to make a fallback to a default sRGB profile that might be incorrect for the data. And it seems like both windows Paint and .NET do this by default, and even large sites like dpreview.com uses tools that has the same problem....
When the PNG sRGB chunk is present the PNG iCCP chunk should not also be present. The sRGB chunk is a short-hand way of representing the sRGB source profile, meaning that a PNG decoder is supposed to supply a complete sRGB source profile (and Firefox does that). The viewer (your computer) is supposed to supply a "display profile" which it combines with the "source profile" to render the image on your screen; it is the "display profile" that I feel is incorrect.
Ah I'm beginning to see (finally)... So the sRGB is referring to a standard, and this is decoded incorrectly on both my displays. If I remove the tag, the file displays as intended. But it is still strange that FF and Chrome interprets this tag in one way, and both IE/EDGE, local "Windows Photo Viewer" and "Skitch Touch" interprets it otherwise... So is Microsoft really adding a sRGB tag in .NET that they ignore or misinterpret when displaying it? If it was my display profile only, I guess it should show up as purple on their browser and picture viewers too? All four browsers+photo viewer handles the yellow car with icc profile correctly. http://petapixel.com/assets/uploads/2012/07/QCy7u.jpg (From http://petapixel.com/2012/06/25/is-your-browser-color-managed/ ) (Though not entirely identical hue either, but the last part could of course be the same issue as the sRGB and an incorrect display profile, FireFox and Chrome have identical hue the other three have duller red in different degrees) http://eskerahn.dk/wordpress/wp-content/uploads/2016/10/YellowCar_Collage6.png
The color profile support in Windows Photo Viewer at least is very incomplete. You'd be better off looking at the image in something like GIMP or Photoshop for a fair comparison with Firefox. The way this works in Firefox is like this (with gfx.color_management.mode set to 2): Image with embedded profile (tagged image): [raw pixels] -> [apply embedded profile] -> [apply display profile] -> [display on screen] Image with no embedded profile (untagged image): [raw pixels] -> [display on screen] So your display profile is only used for tagged images. If you set gfx.color_management.mode to 1, it works like this: Image with embedded profile (tagged image): [raw pixels] -> [apply embedded profile] -> [apply display profile] -> [display on screen] Image with no embedded profile (untagged image): [raw pixels] -> [apply display profile] -> [display on screen] And setting gfx.color_management.mode to 0 disables color management support, as you saw. Does that clear things up? You can try setting gfx.color_management.mode to 1 and see if everything looks wrong, which would confirm that your display profile is to blame. Some monitor vendors ship drivers for their monitors with broken display profiles and these are sometimes provided through Windows Update, so you might have a non-default display profile even if you don't think you do (you can confirm it by going to the Color Management settings though).
Thanks for the (further) clarification . When I set it to one, then yes both the sRGB tagged and the untagged blue squares gets wrong, on both monitors. It should be said that the wrong tint is by far worst on my external BDM4065UC. On the built in it is more a matter of 'different' than obviously wrong.
...Just to make absolutely sure I got it, should your explanation for case 2 not be divided in THREE cases? Image with embedded profile (icc tagged image): [raw pixels] -> [apply embedded profile] -> [apply display profile] -> [display on screen] Image with embedded profile (sRGB tagged image): [raw pixels] -> [apply display profile] -> [display on screen] Image with no embedded profile (untagged image): [raw pixels] -> [display on screen] OR does the sRGB imply a a standard profile you apply instead of an embedded one in the icc case?
Yeah, I think technically my explanation was slightly incorrect. The process looks more like this: [raw pixels] -> [interpret using embedded profile -> transform to display profile] -> [display on screen] sRGB is a legit profile, but it's also the default profile assumed for all images on the web. It's just that we skip that 2nd step entirely in case 2 when the image is untagged. In case 1, there should be no difference in processing between an untagged image and an image tagged with sRGB.
Oh, and IIRC formally that second step is done by transforming from the embedded profile (or sRGB) to a *connection* space like CIECAM02, then transforming from that space to the display profile (or sRGB). In practice I think Firefox takes some shortcuts where it can. In case 1, if the image is untagged and you have no display profile then we assume sRGB for both and nothing needs to be done.
Right, in practice any CMS should use the source profile and destination profile to create a single transformation from the image -> connection -> display, and in the case where the source profile is sRGB and the destination profile is also sRGB, the CMS should recognize that and do nothing.
Thanks. :) I will start the hunt for a less incorrect icm for my BDM4065 then :) The one I use is from Philips http://download.p4c.philips.com/files/b/bdm4065uc_11/bdm4065uc_11_dw8_aen.zip But at it is a discontinued display it could be hard to find So I guess I have to find out how ICM's are build and modify it my self...
Without an actual calibrator like an X-Rite i1Display Pro (other options are available ;)) you're probably better off not using a profile at all (so it'll default to sRGB). Except for some really generic corrections a predefined profile is unlikely to be very accurate, and unfortunately a lot of profiles distributed by manufacturers seem to be broken. The display in question seems to have an sRGB mode (I don't know whether that's on by default) so you're probably best off just using that.
Thanks. I tried both to remove the BDM4065.ICM from the monitor, boot and test, and to add the "sRGB IEC61966-2.1", boot an test. If there are any differences, it is insubstantial, the file with sRGB still shows purple. Are there any kind of debugging I can turn on, so I can find out what display profile FF are actually getting?
PS I tried removing from both the user profile and the system default, for the case yo took the system and not the user one. Same result
(In reply to Eske Rahn from comment #32 > > Are there any kind of debugging I can turn on, so I can find out what > display profile FF are actually getting? Go to "about:config", look at gfx.color_management.display_profile
Thanks. As I said in #17 that string is BLANK, could this be the base of the problem? That FF is unable or not allowed to get the active profile from Windows?
If the string is blank Firefox will attempt to use the system profile. You can set it to the location of a profile of your choice to force Firefox to use that (though if the profile is invalid Firefox will still reject it), but in general you can't use it to infer what profile is active. Unfortunately I don't think there's anything in about:support either.
THANK YOU Emanuel Hoogeveen! Explicitly setting the string to * C:\Windows\System32\spool\drivers\color\BDM4064.icm fixed the problems :-D Even afterwards selecting any other icm, or even setting it to a non existing thing like "XXXXX" or even BACK to blank it still works?!?!?!? And even more surprising it also fixed the issue for Chrome?!?!? So something must have been wrong on the windows-side that somehow got fixed by setting this string once from FF.
PS I now see a SLIGHT difference in the two colour charts with and without the sRGB tag, as would be expected. :-D
I think we're done here, resolving as WORKSFORME. Thenks, everyone.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: needinfo?(seth.bugzilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.