Hi everyone, It’s been aeons (well, 7.5 years) since I had time to contribute to this list, and alas, I still owe this list a set of data wrt/ ICC camera profiling from back then (see the end of this mail if you care). But I wanted to make time for reporting a very basic color related issue I encountered on OS X. OS X includes a framework called "Core Image" that allows easy implementation of all basic image editing features (exposure, contrast, saturation, white balance, sharpness etc.). If you use a native Cocoa OS X app that offers basic image editing capabilities (e.g. Preview) or in some cases even is all about image editing (e.g. Pixelmator), you can most probably assume that Core Image is used. Also, for developers, the Image Kit framework including the IKImageView class uses Core Image. However, as it turns out, there is an architectural problem in Core Image that makes the editing result of most of its effects dependent on the monitor profile that’s currently in use. If you switch to another monitor profile, the effects change. That, of course, must not happen. If you render your edited image to a bitmap file (i.e. store the image in the file with the modifications applied), it means that the current monitor profile determines how your editing tools behave, which is bad enough. But it’s even worse if you use Core Image effects non-destructively, i.e. when you store the settings of your Core Image editing pipeline and leave the bitmap image untouched. Because in this case, the result of your edits changes each time you switch to a new monitor profile. ******* Reproduction ******** If you want to, you can reproduce the issue with the following steps, using the Preview application as an example. To make the issue obvious, I will use ProPhoto RGB (aka ROMM RGB) as a bogus monitor profile. Of course, no monitor comes close to the ProPhoto RGB gamut, so the colors will be completely off (desaturated) on an *absolute* basis. But as you will see, the important thing for this test are *relative* color changes, and these will become especially obvious with a monitor profile that deviates as much from other monitor profiles as ProPhoto RGB does. In real life, the deviations will be much smaller, but big enough to pose an actual problem (something like 5-20 of 255 for any RGB component). You can download two test image files here: ftp://ftp.ritual.org/common/ColorManagement/CoreImageBugTestFiles.zip OS X 10.11 El Capitan includes ROMM RGB as a system profile. Otherwise, if you don't have ProPhoto.icc, you can download it from Kodak: http://www.kodak.com/global/en/professional/member/service/software/kproHost... ******* Reproduction Steps ******** 1. In System Preferences > Displays > Color, set your monitor profile to sRGB (you must uncheck "Show profiles for this display only" to be able to so) 2. Open ColorTest.png (included in CoreImageBugTestFiles.zip) in Preview. 3. In Preview’s menu, choose Tools > Adjust Color… and set the Exposure slider to the rightmost value. Note that the colors look reasonable (i.e. still red, green and blue). 4. In Preview’s menu, choose File > Take Screenshot > From Window… and make a screenshot of the window that contains ColorTest.png 5. In System Preferences > Displays > Color, set your monitor profile to ROMM RGB (you must uncheck "Show profiles for this display only" to be able to so) Expected Results: The colors will change (because of the new monitor profile that does not represent the monitor hardware correctly), but will do so consistently, i.e. the colors in Preview’s document window that displays ColorTest.png and the colors in the screenshot of this window will still be identical relative to each other. Actual Results: While the colors in the screenshot behave as expected (basically still red, green and blue, just very desaturated), the colors in the ColorTest.png document window (that are calculated by Core Image) are completely off; red has become orange, green yellow and blue purple. This means that as soon as you switch to another monitor profile, the Core Image edits change their behavior (otherwise the colors in the ColorTest.png document window would change exactly as the colors in the screenshot). ******* Variants ******** Preview’s behavior cannot be changed from the outside; the same applies to IKImageView (at least when sticking to the documented API). But developers who use Core Image in their own drawing code can use the options dictionary in the CIContext factory method +contextWithCGContext:options: to specify a specific output color space. If they do, the output color space (instead of the monitor profile) will determine the behavior of Core Image, so the Core Image effects are isolated from the monitor profile and are not affected anymore by a switch of the monitor profile. But that is not really a solution, either. The developer could do one of three things: 1. Specify an output color space with a gamut like sRGB. Then, Core Image’s Exposure filter will always behave as in reproduction step 3 above, i.e. the colors will always look reasonable. However, any image with a gamut larger than sRGB will have its gamut compressed to sRGB, so images with e.g. a ProPhoto color space will be heavily cut down. 2. Specify an output color space with a very large gamut like ProPhoto RGB. Then, no image will have its gamut compressed, and (as an example) Core Image’s Exposure filter will always behave identically, i.e. it will behave consistently. But it will behave consistently wrong, i.e. like in the Actual Results step from the reproduction steps above. (Because obviously, the Core Image filters are set up with an sRGB like gamut in mind.) Even images with an sRGB gamut, which could be Core Image filtered just fine without having their gamut compressed, will display the distorted colors with the Exposure filter applied. 3. Specify the image color space as the output color space. Then, no image will have its gamut compressed, and Core Image’s Exposure filter will work just fine on images with an sRGB like gamut. But the effect of the Core Image filters will vary wildly from image to image, now depending on the image’s color space. So none of the three possible variants is a consistent solution. Variant 3 is used by Pixelmator. If you like to verify, convert a copy of ColorTest.png to the ProPhoto RGB color space. Then open both ColorTest.png files in Pixelmator and apply the same Exposure setting to both. The results will differ strongly (no matter what the monitor profile is). I’m not aware of any commercial application that uses variant 2. You would think that ColorSync Utility, of all applications, behaves consistently wrt/ color, but alas, it uses variant 1 (as soon as you apply one of its basic image editing tools and thereby enable Core Image – otherwise, it works as expected). You can check the effects of variant 1 by using the second image in CoreImageBugTestFiles.zip, Color Test Chart Float ProPhoto RGB.tiff. This test chart image contains color patches in ProPhoto RGB, with all RGB components of any patch either 0, 50, 100, 150, 200 or 250. So when you set your monitor profile to ProPhoto RGB and measure a patch with DigitalColor Meter (popup set to native values), you can see at a glimpse if the color of this patch is undistorted – in which case no RGB component can have a value other than 0, 50, 100, 150, 200 or 250. So, with your monitor profile set to ProPhoto RGB, open Color Test Chart Float ProPhoto RGB.tiff in ColorSync Utility. You can confirm with DigitalColor Meter that all color patches are correctly displayed. Then, click on the Image Correction icon in the toolbar of the document window. As soon as you move any slider in the appearing tool window – and be it the Sharpness slider which shouldn’t affect colors at all apart from the edges –, you can watch the image gamut collapse. Again, if you stay away from these Image Correction tools, ColorSync Utility works as expected. I have filed a bug with Apple, but of course, I don’t know if and when this will be fixed. As long as it isn’t fixed, unfortunately you cannot a priori trust any Cocoa app when it comes to color consistency. :-( ******* A historic appendix ******** Finally, as promised at the beginning of this post, a short look back. In September 2008, in the threads "Media Testing for maclife.de" and then "Camera profiling with ICC et al" (and maybe others), I had presented results of a test of camera profiling methods. The test results said that building ICC camera profiles with X-Rite’s Profile Maker and using Capture One Pro proved superior to Adobe’s DNG profile approach. This was heavily disputed – specifically by someone from Adobe ;-) –, but unfortunately, the test was published in German in a German magazine, so most participants were not able to read it. Therefore, I promised a translation. Ironically, the huge argument on this list devoured all my time, and I never got around to finishing the translation. I had even prepared the original measurement data and written a script that would have allowed an automated evaluation of the data with X-Rite’s ColorLab application, but the English text was still missing, as I wrote in a post to this list on September 15. Then, suddenly all hell broke loose on the stock market, which unfortunately affected me in several ways simultaneously and left me no time at all, and later I never got back to it. Then ColorLab (a PowerPC application) stopped running on OS X, and a little later X-Rite discontinued Profile Maker and switched to DNG profiles with i1Profiler, so this is all history now. Still, about one year ago I built new DNG profiles with the current Adobe software and my data from 2008, and the Profile Maker ICC camera profile together with Capture One Pro still was superior, metrologically and visually. Oh well ... Anyway, sorry this ended the way that it did in 2008. Bye Uli _________________________________________________________________________ Uli Zappe, Christian-Morgenstern-Straße 16, D-65201 Wiesbaden, Germany http://www.ritual.org Fon: +49-700-ULIZAPPE Fax: +49-700-ZAPPEFAX _________________________________________________________________________