I installed Tiger on April 29. My existing 10.3.9 installation was fully backed up to a bootable Firewire drive, so I wasn’t worried about losing anything or reverting. Despite having developer access to 10.4 for almost a year, I didn’t run it on anything but a beaten-down iBook, and really didn’t spend much time with that either. If I were only doing FXScript, I probably should have waited until FCP 5 shipped before moving up, but I need to know about 10.4 in I can answer questions and eventually upgrade the machines at IOP. Mostly though my curiosity had me installing Tiger right away.
The first thing I noticed when I opened FCP4.5 in 10.4 was the wrong color debugging text in the filter I’ve been working on for the past few weeks. What should have been white was yellow, with chunky pixelated edges. This caused a small amount of panic while thinking all my text-drawing routines would be broken. (they weren’t)
What I’ve found is that DrawString and DrawStringPlain break when applied to an FXScript image buffer which has been affected by several FXScript image processing functions, this one used LevelMap. It doesn’t make any difference whether the levelmap changes anything or is a clean linearRamp passthrough. The problem only happens in ‘naive’ color space, that pseudo-RGB space FXScript uses when YUVaware isn’t declared at the beginning.
Here’s what the text looks like in FCP4.5 running under 10.3.9 with QT6.x:
And here’s the same text in FCP4.5 running under 10.4 with QT 7:
There’s one other wrinkle, enabling transparency with
exposedbackground=1; causes several of DrawString’s outputs to disappear while DrawStringPlain’s results punch out to transparent.
It’s not just white that’s affected. Here’s a quick chart of what happens to the various color constants:
|kWhite||yellow w/ white edges||white|
|kGray||dark yellow w/ gray edges||pale bluish violet|
|kred||black w/ blue edges||blue|
|kMagenta||green w/ cyan edges||cyan|
|kYellow||red w/ magenta edges||magenta|
I tried a bunch of other generative functions; FillPoly, DrawSoftDot and BlitRect, but none of those showed any adverse effect. Other processing functions did produce similar results. Several Convolve kernels caused problems, but it was hard to pin down when they’d break.
So the solution is to just set the effect to be YUVaware. The good side of all of this is that working in YUVaware generally gives effects a measurable speed increase. Still, this problem does cascade through subsequent effects, so it’s something to watch out for.
Download the simple filter I used to isolate the problem: LevelMap & DrawString Color Bugs.fxscript (1k) Please let me know what you see if you try it out.
Disclaimer: This effect simply demonstrates a visual problem with FCP 4.5HD and MacOSX 10.4 Tiger. It can’t damage your computer. Still, this is offered as-is, with no warranty of any kind, implied or otherwise.