@alcomposer Good idea.

Specs

• MacBookPro6,2 • Mac OS 10.7.3 • FCP: 10.0.3

Attached in a zip file are two folders: one with the actual profiles and another with the dispcalGUI settings used to create them (well, not all of them—I experimented a lot—but they reflect the workflow).

P.S. The ICC files in the archive are after I ran repair on them in ColorSync Utility.

@alcomposer Thanks for doing the tests!

Darn it, I don’t know where to begin. I already spent a day trying to fix the problem. Force-swithing the GPUs doesn’t make any difference. I’ll try a clean install on a temporary partition and see if it helps.

Note, however, that one of the release notes for FCP 10.0.1 (http://support.apple.com/kb/HT4589 scroll down) says:

Fixes an issue in which custom ICC color profiles affected the image in the Viewer.

Perhaps the bug hasn’t been fully fixed, or was reintroduced in one of the subsequent releases. Also possible, as you suggested, that the problem affects certain GPUs.

@alcomposer Thanks! I’m on it.

EDIT: Just tried it on Low. No change in FCPX behavior. The setting generates noticeably worse quality profiles, though.

Okay, I did some extensive testing. I tried all the profile types on all profile quality settings. According to my tests, the profile quality setting doesn’t affect FCPX’s behavior. However, I’ve found that FCPX works fine with the following profile types:

— Lab* LUT

— Gamma + matrix

— Single gamma + matrix

“It looks like most OS X generated profiles don't include Matrix data.”

i1Profiler allows you to choose between two profile types—matrix based (default) and table based. I use the matrix based one and FCPX is pretty happy about it.

Phew. Gotta go grab something to eat.

Well, let’s hope so!

There’s one more (little) issue with dispcalGUI’s ICC profiles. Somehow Mac OS doesn’t consider them to be display profiles. If the “Show profiles for this display only” option is selected in System Preferences > Displays > Color, all profiles created by dispcalGUI disappear from the list, along with some other profiles such as Adobe RGB, Generic RGB, and sRGB IEC61966-2.1.

Could you confirm this issue for me, Alex?

alcomposer, I said that sRGB uses the rec.709 RGB to YUV color conversion matrix.

But while the GH2 manual says that video mode uses sRGB, it is not clear whether it is using the sRGB matrix, primaries, transfer function, or all three. And Blu-ray uses the rec.709 matrix and primaries (which are the same as sRGB's), but I doubt most discs are mastered with the rec.701 transfer function.

Hi everyone (beware, somewhat lengthy post incoming ;))

"Supposedly rec.709 is 2.2, but should be viewed in a 2.4 environment."

The rec. 709 transfer function uses a power of 1.0 / 0.45 (≈ 2.22) with a straight segment at the dark end (average gamma is around 1.88). What you said about viewing conditions sounds feasible (sRGB, while having an overall gamma of about 2.17, is also intended to be viewed with a display gamma of 2.4).

"With all the quality settings at maximum, it took over 5 hours on an 8 core."

I assume most of that time was the measurements? The Spyder devices are very slow unfortunately (even a i1 Display 2/LT is a lot faster, and with the i1 Display Pro you can measure 1000 patches in well under 10 minutes, if need be). The profile creation after the measurements should take anywhere from under a minute (for a 'single curves + matrix' profile) to 30+ minutes (for a LUT profile), also depending on the number of patches that were measured (I wouldn't go over the default amount for matrix profiles) and cpu speed.

"sRGB is very close to rec.709"

sRGB uses rec. 709 primaries. The transfer function is the only difference (it uses a power of 2.4 with a straight segment at the dark end, average gamma is around 2.17).

"FCPX 10.0.3 seems to choke on ICC profiles generated by DispcalGUI: no video in the viewer, hangs upon playback."

Some softwares seem to have problems with XYZ LUT profiles (some even with LUT profiles in general). That's a shortcoming of the respective softwares (incomplete or faulty ICC implementation). You best bet for compatibilty is one of the matrix profile types.

"AFAIK icc profiles are somewhat useless for video monitor lut generation (having to do with the fact that they are historically of a print world)"

Don't know where you got that impression but it's incorrect :) ICC profiles currently only cannot be used safely for conversion from or to DPX log because of roundtrip errors, but there is a proposed addendum for ICC format version 4.2 which enables storing true floating point values in profiles (I just don't think this is already implemented anywhere). Basically, for anything that is not DPX log, the mentioned limitation is a non-issue.

"[...] 3DLUT is a transform matrix."

What's important though is that it's not just a matrix calculation (otherwise the 3DLUTs could be three-liners), and it depends a bit on the types of profiles that are used to create the 3DLUT. 'Matrix' profiles usually contain curves or atleast gamma values for the device channels (R,G and B in this case). Matrix profiles only work for devices that behave linearly additive (like displays). LUT profiles don't have that restriction and can be used to characterize just about any device.

"Hm, just ran profile verification in ColorSync Utility, and it reported the following error for dispcalGUI profiles: Header padding is not null."

Technically ColorSync utility is correct, but imho it is being a bit pedantic: It is complaining about the profile ID (basically an MD5 hash of the profile contents) that has been introduced in ICC version 4, and that dispcalGUI also writes out for the (v2) profiles it generates. But in reality, this isn't a real problem because ICC v2 compatible software will ignore the bytes where the ID is stored as padding, regardless of content. 'Repairing' the profile in ColorSync utility therefore does nothing more than removing the profile ID (it sets the bytes where it is stored to binary zero).

"It looks like most OS X generated profiles don't include Matrix data."

I don't think that's true. As far as I'm aware, the Mac OS X visual calibration utility ONLY can create matrix profiles (but I haven't used it in a while). Or did you mean the 'effect' profiles that come with every Mac OS X install like the 'Blue Tone', 'B & W', 'Sepia' etc? (they are LUT-based, so-called abstract profiles, in contrast to device profiles)

"There’s one more (little) issue with dispcalGUI’s ICC profiles. Somehow Mac OS doesn’t consider them to be display profiles. If the “Show profiles for this display only” option is selected in System Preferences > Displays > Color, all profiles created by dispcalGUI disappear from the list"

Hmm, this shouldn't happen with the current version (0.8.9.3), it could be a bug. Does your display appear with an unique name in the "Display device" dropdown? Or does it show as generic, e.g. "Screen 1" or the like?

"It has to do with putting them in a specific folder, more than anything else."

Yes and no. Profiles that should show up for a specific display also need to include specific information (the so-called, proprietary 'mmod' tag which contains display identification info. dispcalGUI writes it from v0.8.9.3 onwards).

"But while the GH2 manual says that video mode uses sRGB, it is not clear whether it is using the sRGB matrix, primaries, transfer function, or all three."

If it adheres to the sRGB standard, it should use the primaries (the primaries give the matrix) as well as the transfer function (sRGB is intended to be viewed in dim surround with a display gamma of 2.4, so they could be using that instead of the sRGB transfer function. Some simplified models also use a pure power of 2.2 instead).

Yes, it does. It says “Color LCD @ 0, 0, 1400×900 (Primary).”

Maybe we can figure this out. If you could send/upload the dispcalGUI profile which is not showing when “Show profiles for this display only” is on and one profile which is showing, I can compare what's different in the 'mmod' tag.

FCPX appears to play nice with the Lab LUT profile. Or is it different from XYZ LUT profiles?

The internal colorspace is different.

Slightly off topic, but while we’re at it, while dispcalGUI is running—even if the sensor isn’t connected—it wreaks havoc with USB devices, namely my keyboard and trackpad. They become unresponsive for a second or two. Console is going crazy.

Hmm, I've not seen that before. dispcalGUI polls for device changes every 10 seconds or so, and I've seen this causing mouse cursor hitching for a split second on a number of occasions, but nothing extreme. What's interesting to me is that it goes along with output on the console in your case? Can you show me that output? Although I think what I should maybe do, is only polling automatically once at the start of dispcalGUI, and only manually after that.

Answered: http://www.poynton.com/notes/brightness_and_contrast/

Thanks for this most informative thread. I have been trying dispalGUI on my Mac pro and have a question perhaps those contributing to this thread can help with. I am trying to calibrate a Sony Artisan monitor using DispcalGUI. The Sony, in addition to its now difficult to run software/dedicated hardware has several manual controls I am trying to understand. These include brightness and contrast, as well as for each RGB channel brightness and contrast. According to manual: For Black Level, I use brightness control. For White Point " using the display's RGB gain controls" I've been using the R, G and B channel brightness controls to calibrate. Is this correct? For Brightness, adjust overall display contrast. Finally, for Black Point, manual states "If your display has RGB offset controls, you can adjust the black point as well, in much the same way that you adjusted the whitepoint." Is this RGB channel contrast? Basically, I'm trying to parse the terms brightness and contrast to the terms gain and offset.

Any help greatly appreciated!

John

@Mr_Moore: Ok, thanks.

[0xffffff8013e4fa00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in.  It will keep retrying.  (Port 3 of Hub at 0xfa100000)

What USB device(s) do you have connected (including eventual external hubs)? It seems one is hanging while being enumerated. You should see the same output in the Console (with same symptoms) as above if just running the following command in Terminal: dispcal -? (in your Argyll_vX.X.X/bin directory)

The other (unrelated) problem is that dispcalGUI seems to be unable to figure out the display's EDID, so it can't write the 'mmod' tag. It would help me if you could upload 'ioreg.log' created by running the following command in Terminal: ioreg -c IODisplay -S -w0 > ioreg.log

(sidenote: The profile name consists of 'display<no>-<hash>.icc' if it contains special characters, it's not influenced by where dispcalGUI is run from. The internal profile description will always be what you see in dispcalGUI)

@jam:

[...] as well as for each RGB channel brightness and contrast

I'd assume the RGB 'brightness' is offset and RGB 'contrast' is gain, then (because on CRTs 'brightness' usually influences things on the 'dark end' and contrast on the 'bright end'). I may be wrong though.

@florian Running dispcal -? produces the same output:

kernel: USBF: 50418.720 [0xffffff8013e4fa00] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 3 of Hub at 0xfa100000)

2/20/12 12:12:49.000 AM kernel: com_apple_driver_AppleUSBCardReaderUMC:: Stop::Controller Reset

kernel: 0 0 AppleUSBCDC: start - initDevice failed

kernel: USBMSC Identifier (non-unique): 000000009833 0x5ac 0x8403 0x9833

Now, 0x5ac is Apple’s Vendor ID, 0x8403 is Product ID of the built-in card reader, and 9833 is the card reader’s version/serial number.

The card reader shares the bus with the keyboard/trackpad and the Bluetooth module (the other bus is used by the iSight and IR receiver).

My display EDID:

"IODisplayEDID" = <00ffffffffffff000610a39c0000000000130103802115780af595a3554f9c260f505400000001010101010101010101010101010101ab22a0a050841a30302036004bcf10000018000000010006103000000000000000000a20000000fe004c503135345750342d544c4131000000fe00436f6c6f72204c43440a2020200000>

The profile name consists of 'display-.icc' if it contains special characters . . .

I see. Since Mac OS supports Unicode characters, is it possible to save the profile with a human readable file name, instead of the hash? That would be super awesome!

EDIT: Attached ioreg.log.

Could you report the problem on the Argyll CMS mailing list?

Thanks! I will.

I'd need the ioreg.log

Uploaded.

@florian, the primaries do not give the matrix. The colorimetry of the primaries is independent of the matrix that is used to convert RGB values to YUV values.