Upgrading to Photoshop CC

I have been a Creative Cloud subscriber for more than a year. I think it’s a great licensing construct for my business. So I was eagerly awaiting the current CC release (I use Photoshop, Illustrator and InDesign) all day yesterday. No luck. Then this morning Application Manager showed that I have some updates!

This isn’t an upgrade

Actually Photoshop CC is not an upgrade. Not even for existing CC subscribers. That means that Application Manager will install it side-by-side with CS6, leaving all CS6 stuff intact. On first startup I was asked whether I want my actions and stuff imported. I definitely wanted to do this! The good news is PSCC was able to successfully import all my actions and workspaces.

App settings (including color settings) were left in the dust, however. I had to manually set up everything from memory configuration to cursors – which is a royal pain in the butt. This is especially irritating because almost all settings are the same! Adobe, you could do much better in this regard.

Fortunately I still had CS6 sitting around, so it served as a guide for my preferred settings. Moral: do not uninstall CS6 beforehand!

Trying to select my L* workflow color setting preset brought up the following warning:

pscc-color-settings-warning

Surprisingly clicking OK brought every setting in, so I’m curious what settings aren’t supported… To make sure everything will be fine next time I just re-saved my color presets.

Then uninstalled CS6.

Plugin compatibility

This is always a question when one updates Photoshop. Here’s a quick rundown of the three plugins I use.

  • PhotoKit Sharpener works fine, you just have to grab the new CC-aware setup.
  • Perceptool wasn’t even CS6 compatible, but you can download a free action incarnation of it that works well on CC. It’s definitely worth trying – especially at this price point.
  • NoiseWare Pro 5 doesn’t work. It crashes Photoshop. I use this only on older images, so not being able to use now isn’t that much pain. Update: Further investigation showed that this is a retina display specific problem. On my external EIZO everything works fine. Already contacted Imagenomic, so that they can fix it.

Getting rid of Bridge

Another good news is Bridge doesn’t get installed automatically. I used it only for browsing my master images, but I’ll try to move this workflow step into another app (likely OS X’s Finder) and save some precious megabytes on my SSD. For those who use it: it is now retina display aware.

Conclusion

The entire process went smoothly (including my monkeying around with copying settings). From now on I will only work with CC, and will post if I find something worth talking about.

Canon Software Crashing on OS X 10.8

Shameless plug: If you are shooting tethered, I recommend you to check out Kuuvik Capture, an app that I wrote for Kuuvik Digital. It’s light years ahead of EOS Utility. You can find my posts related to the app here.

October 10, 2012: Canon has released EOS Utility 2.12.0, which resolves the problem. You can download it from here.

September 24, 2012: both applications produce the exact same behavior on the latest OS X 10.7.5 update. So now Lion users are also affected.

Let’s begin with the hard facts: Canon’s latest EOS Utility (2.11.4, released a week before the public 10.8) crashes on Mountain Lion each every time I connect my 5D Mark III. The version I got with the camera on the included CD (2.11.0) works just fine. Also, the current version of the app works fine on Lion.

EOS Utility Crash

Moreover, the CaptureCoreServer component in Capture One 6.4.3 is also crashing every time I connect the camera. This happens periodically, as the main app tries to restart the just crashed server.

Capture One Crash

Phase One states in the 6.4.3 release notes that new features are (among others):

  • Added support for Mac OS X 10.8 Mountain Lion.
  • Tethered support for Canon 1D X and 5D Mark III.

It seems that Phase One has serious issues with their quality assurance department (nobody ever tried this setup, they just blindly released it). Which is a bad thing for such an expensive software.

Being really upset with these I decided to do a little private investigation on my own. I’m a developer, so the goal was to at least identify who is responsible for screwing things up so badly. From the crash logs I was able to quickly identify a component named “com.canon.edsdk”, which lives in the EDSDK framework. The following is a prettified excerpt from the crash log:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib
    objc_msgSend + 27
1   libobjc.A.dylib
    (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 490
2   com.apple.CoreFoundation
    _CFAutoreleasePoolPop + 51
3   com.apple.Foundation
    -[NSAutoreleasePool release] + 125
4   com.canon.edsdk
    CIccMan::SendPtpCommand(void*, tagEdsPassThrough*) + 961
5   com.canon.edsdk
    CMacPtpInterface::SendCommandSelf(void*, SPtpParam*) + 120
6   com.canon.edsdk
    CPtpInterface::DS_SetRemoteMode(void*, DS_REMOTE_MODE_T) + 156
7   com.canon.edsdk
    CPtpCamera::OpenSessionSelf() + 314
8   com.canon.edsdk
    CEdsCamera::OpenSession(long) + 69
9   com.canon.edsdk
    EdsOpenSession + 77
10  com.canon.EOS Utility 2
    -[MainController openSession] + 182
11  com.canon.EOS Utility 2
    -[MainController connectCamera] + 353
12  com.canon.EOS Utility 2
    -[MainController launchApp] + 555

0xb0000000 - 0xb0050ffb +com.canon.edsdk (2.11.4.3 - 2.11.4.3)
EOS Utility.app/Contents/Frameworks/EDSDK.framework/Versions/A/EDSDK

It seems that the EOS Utility calls the EdsOpenSession function (in stack frame 9, marked with bold) in the EDSDK framework, which causes the crash down the road.

Now that I know the name of the component that causes the crash I quickly checked the EDSDK version in the old and new EOS Utility as well as in Capture One. The numbers are the following:

  • EOS Utility 2.11.0 – EDSDK version 2.11.1.12
  • EOS Utility 2.11.4 – EDSDK version 2.11.4.3
  • Capture One 6.4.3 – EDSDK version 2.11.3.0

So the responsible party (for the crash) is either Canon or Apple. My bet is that Canon introduced this bug between 2.11.1.12 and 2.11.3.0 versions of their framework. Even if Apple has changed something that caused the framework to break, Canon is guilty in not testing their software on upcoming OS releases. This is especially irritating in these days when platform providers like Apple release a new operating system each year. Saying that “oh, it works fine on last year tech” is a surefire way to alienate customers. Phase is just guilty in not testing what they release (which is also a cardinal sin in my book).

I had filed bug reports with all three companies when I ran into the issue. Canon Europe’s response was the usual: nothing, nada, zip. Not even a “thank you for your feedback” message. Apple and Phase are both working on the bug, but made no progress during the last week or so.

I’ll let you know when progress is made, but given Canon’s track record of fixing things don’t expect it to happen overnight. Do your tethered shooting with the old EOS Utility in the meantime. Oh, and don’t forget to disable the Canon provider in Capture One to avoid interference between the two apps!

Disable the Canon provide in Preferences

EIZO ColorEdge Monitors with OS X 10.8

As I mentioned in my previous post, EIZO’s ColorNagivator software (that is used to calibrate and profile their hardware-calibration capable ColorEdge line of monitors) does not work correctly on Mountain Lion. After installation colors looked awful on my CG241W, which the calibration only made worse. Checking the validation results clearly shows why.

ColorNavigator 6 Validation Results

Instead of the usual ~2 deltaE2000 maximum difference I got more than 5. Even cheap, crappy LCD panels produce better results. This is totally unacceptable.

There’s a solution, however.

About a year ago I had tested the basICColor display package. It worked great, but I had decided against it as the quality difference over ColorNavigator had not been  that big.  So I downloaded and installed the 14-day trial on my current machine. Although the manufacturer says it’s Mountain Lion compatible, the installer is not digitally signed, so Gatekeeper prevented the install. The usual right-click – Open trick worked like a charm (opening an app this way you have the option to add it to the Gatekeeper white list).

Besides this glitch the app worked flawlessly. Here is the validation result.

basICColor 5 display Validation Result

The calibration is even more precise than it was with ColorNavigator. This proves that the cause of this issue lies within EIZO’s software. Unfortunately, they have no usable technical support at all (you can contact the local reseller, but this effectively shields the development team from any user feedback).

I’ll give EIZO a week or two to fix this issue, then I’ll give up and buy basICColor display. It is EUR 100, but the manufacturer has no web shop, so purchasing it might present some issues… All in all, I’m really angry that manufacturers of super-high-tech (and super expensive) equipment does leave their customers in the dirt, and they doesn’t seem to care at all. An even better example of this is Canon, but I’ll tell you about that in the next post.

Integrating Perforce with Xcode 4

I prefer to work with first rate tools. You might call it snobbery, but I’m just too old for spending my precious time on fiddling with inferior products. That’s why I’m using Mac OS X and even more the reason I chose Perforce as our source control system. It simply blows the competition away.

When Apple introduced Xcode 4, I had realized with horror that they removed Perforce support. This was simply unacceptable for me. I would give up on Xcode much easier than giving up one of the cornerstones of our business. So I waited patiently, filed bug reports with Apple, until the buggy-to-the-level-of-unusability Xcode 4 was released. I decided to stick with Xcode 3 for the foreseeable future (until of course Apple dropped the tools and I had to migrate).

I did not want much from the Xcode side – just let me check out the files when I start working on them. I usually handle all the other stuff (like diffing, code review, etc) from P4V. Then while walking through all the Xcode 4 options and menu items (to familiarize myself with the inevitable new tool) I found something on the Behaviors preference pane.

You can execute a shell script every time Xcode unlocks a file. Fortunately Perforce locks all the files that are under source control and not in the checked out state – so you can be sure that all your files will be locked when not checked out. This fits perfectly with the Unlock file behavior. When you start working on a file Xcode wants to unlock it and executes your script. The script could then check out the given file from Perforce. The checkout will unlock the file, so everybody will be happy.

My xcode4edit.sh script is pretty straightforward:

#!/bin/sh
`cat ~/.profile | grep P4PORT`
`cat ~/.profile | grep P4CHARSET`
`cat ~/.profile | grep P4USER`
`cat ~/.profile | grep P4CLIENTPATH`
/usr/local/bin/p4 edit ${1#file://localhost}

This is checked in into the root of the depot so every team member have access to it. My .profile (as well as other members of the group) contains the actual configuration parameters:

export P4PORT=<server>:1666
export P4USER=<user>
export P4CHARSET=utf8
export P4CLIENTPATH=/Volumes/Data/Workspace

Of course you can add additional configuration variables to the script and into .profile if you want.

Output from the p4 edit command will go into the Console, so you can use that for debugging any problems you face.