March 2016 - colorsync-users

Re: Turn off color management!
by Kai-Uwe Behrmann 07 Mar '16

07 Mar '16

Am 04.03.2016 um 01:59 schrieb colorsync-users-request(a)lists.apple.com: > Message: 7 > Date: Fri, 04 Mar 2016 01:16:35 +0100 > From: Uli Zappe <uli(a)ritual.org> > To: Martin Orpen <martin(a)idea-digital.com> > Cc: ColorSync <colorsync-users(a)lists.apple.com> > Subject: Re: Turn off color management! > Message-ID: <D70CB7E3-87AC-4AC9-82C5-D9EDFE4CCF2E(a)ritual.org> > Content-Type: text/plain; charset="windows-1252" > >> > Anybody running a business that relies on Apple products in their workflows is in a very risky position. > No risk no fun. :-) The risk sounds to me like to talk only with the jailer. Not the kind of social live I prefer. >> > Maybe you should do another search of the Apple’s Developer Library to see if you can find anything about ColorSync written in our current decade? > Why should I do another search? > > I have already found all I need. :-) > > Some docs I recently used: > > https://developer.apple.com/library/mac/technotes/tn2227 (2011, ColorSync & AV Foundation) > https://developer.apple.com/library/mac/samplecode/ImageApp (2012, ColorSync & Core Image) > https://developer.apple.com/library/mac/samplecode/From_A_View_to_A_Movie (2013, ColorSync & OpenGL) > https://developer.apple.com/library/mac/samplecode/convertImage (2013, ColorSync & Accelerate) > https://developer.apple.com/library/mac/technotes/tn2313 (2014, ColorSync Best Practices, a technology overview with code examples) Thanks for sharing. However, what I expect from your previous posts some info about, how to get (and eventually set) the print and monitor device color profiles programatically. As you and some others described here, these profiles would be needed to created a NullTransform on OS X these days. Last time I looked into that topic, all existing API's became deprecated without a public known substitute. Thanks >

5 4

Proofing Husky Opaque (Uncoated sheet)
by Roger Breton 05 Mar '16

05 Mar '16

Been increasingly getting my feet wet into M0 vs M1 characterization. Harvesting the data from the press sheets is a cinch, using the current crop of M1 instruments such as with the Minolta FD-9. But what about proofing? Does one really need a proofing substrate with a "matching" white point? Here, inspecting the measurements with PatchTool, Husky Opaque unprinted paper yields 93.21 2.10 -8.53 using M0 and 93.53 2.30 -10.97 using M1. Does it mean that I need to find a proofing substrate close to a b* = -10.97? To have a fighting chance at an acceptable visual match? Best / Roger

3 2

Re: Proofing Husky Opaque (Uncoated sheet)
by Matthew Louis 04 Mar '16

04 Mar '16

Hello Roger, Matching press and proofing stock as closely as possible with all measurement modes is helpful. The photo at the bottom of Gordon's page gets the point across. http://the-print-guide.blogspot.com/2009/03/issues-of-optical-brightening-a… I’ve been proofing CRPC3 with decent results. Press work targets CRPC3 with SCCA M0 white point. The proofer is profiled with M1 but the reference profile is made from CRPC3 data substrate corrected to the M0 press stock. When I profile the proofer with M0, absolute colorimetric paper simulation looks a bit green. The proofing stock is uncoated. Domtar Lynx (i1Pr02) M0 95.94 1.63 -7.60 M1 96.17 1.98 -10.30 M2 95.97 -0.84 0.03 Fuji DS103 M0 95.96 2.45 -9.27 M1 96.21 2.86 -12.25 M2 95.75 -0.34 -0.79 On press I get numbers along the lines of: L* a* b* de76 dE2000 C 60.19 -24.92 -45.49 3.65 1.04 M 56.78 60.01 -3.74 3.06 0.97 Y 91.02 -6.31 73.49 5.18 2.72 K 34.15 1.43 1.35 3.33 2.69 R 55.10 55.89 29.58 1.54 0.93 G 55.20 -46.69 14.63 3.16 1.48 B 38.97 10.49 -32.49 2.29 1.26 The notes I have verifying the proofer with an Idealliance 3 story control strip to CPRC3 M1 - SCCA On: Paper dE76=0 Primaries Max dE76 2.8 Primaries Max dH 1.8 Overprints Max dE76 1.2 Grays Avg wCh 0.4 Grays Max wCh 0.5 NPDC Avg wL 0.3 NPDC Max wL 0.6 Overall Avg dE 0.8 Overall Max dE76 2.8 Thanks, Matt Louis

1 0

Mundane color problem
by Roger Breton 04 Mar '16

04 Mar '16

I need to pursue the following line of reasoning. Here's the situation. I have a superlative CMYK to CMYK RIP. I have a characterization of its "full gamut" on Brand X paper. Rather well linearized but not rigorously spaced when you look at it in 3D. My problem is, I want to "design" a CMYK gamut around this particular CMYK characterization? A CMYK gamut that would fit it as close as possible. My plan is to use this fitted CMYK space for converting into from, say, Photoshop, and then, later convert from that fitted CMYK space to the characterized full gamut of the printer in the RIP. So the conversion would go like : A) say I have swell RGB imagery in some "wide" RGB spaces; B) I convert to TO that sort of intermediary space in Photoshop ; B) and then, in the RIP, the conversion would go from that fitted CMYK space to "full gamut" of the printer. Using some rudimentary tools I have at my disposal, I already undertook to modify what I consider a well-behaved "large gamut" CMYK space, such as CRPC-7. Alas, the tools I use only allow modification of the CMYK colors - not the RGB, which would allow the better fit to the "full gamut" I'm trying to mimic. I already compared AdobeRGB, eciRGB, and lot's of other RGB spaces as potential candidates, instead of insisting on an CMYK space but I find them all way too big. Sounds like a trivial problem? There must be something I'm missing. I know some RIP allow modeling the printer as an RGB device such as GMG but not this one, not that I know of, at least. If all fails, I'll end up making an ICC profile out of this "full gamut" characterization to convert images straight into it. Hope my life is not too complicated for you ;-) / Roger

6 11

Core Image bug distorts colors
by Uli Zappe 02 Mar '16

02 Mar '16

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/kproHos… ******* 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 _________________________________________________________________________

2 2

Re: i1Pro weirdness & fix
by Alexey Gribunin 01 Mar '16

01 Mar '16

Hello Graeme! Thank you very much! It's very interesting research! By the way, just as an idea - is it possible to make special "cleaning" utility for i1Pro and Spectrolino, which will turn lamp on forcibly for some seconds to "clean" it? It would be great, because Lino has no possibility to measure strips, so it's not possible to "clean" the lamp with the native measurements. Also I think it can help to restore some i1Pro lamps because when the lamp became too dark, the software failed to calibrate it, so it's not possible to "clean" the lamp with the regular strip measurements. What do you thing about it? Whether it can help to restore lamps? Best regards, Alexey Gribunin, UNIT Color Technologies, Moscow, Russia. > In fact > after "cleaning", the worst I could get was 0.08 Delta E, a 20x reduction, > and back in line with instrument specifications... > I've seen similar effects on all my i1Pro's, and also Spectrolino's, > although none as dramatic as the Rev E was. .. > So if you do lots of spot measurements with your i1Pro's, and get the > impression that your accuracy and consistency of measurement is getting > squirrelly, you may be right. But there is a way of fixing it!

8 11

profile data manipulation
by Dan Bergstrom 01 Mar '16

01 Mar '16

Any experience out there in manipulating lab data for profiles? I’d sometimes like to force the profiling software (i1Profiler) to pick a different TAC than it’s default. I THINK it picks its TAC preferring minimum chroma and I want to allow I little more chroma and pick a lower L*. Or sometimes just force yellow under magenta in rich black of resulting profile. thanks -- Dan Bergstrom | Color Technology and Quality | PRIMARY COLOR ORANGE COUNTY http://www.primarycolor.com | T 949 660 7080 C 949 616 4986

4 6