Luma lift with Quartz Crystal - incorrect luma after rendering out movie

vade's picture

Hello

I was hoping to use Quartz Crystal to offline render some effects on to my Quicktime movie files for use in an edit, in doing some test renders I've noticed that Quartz Builder lifts the luma levels in the output Quicktime file by a pretty serious amount.

I did some tests with a simple movie and passthrough composition (Quartz Composer Movie importer -> Billboard, color correct on, High Quality hint on, no effects, just play the movie) and what I noticed was:

Quicktime shows proper luma, Final Cut Shows Proper Luma, Quartz Composer rendering view shows proper luma, and even Quartz Builders previews shows proper luma. The final render however does not.

I rendered to Apple Pro Res 422 @ 1920x1080, original source is Apple Pro Res 1920x1080, no intermediate processing other than the simple pass through Quartz Comp. Ive tried other codecs, and all show the luma lift, so clearly there is some conversion going on during rendering that is not happening in Quartz Composer itself.

Looking at the color shift in digital color meter looks like Quicktime and Quartz Composer rendering are within half a percent color wise, but the Quartz Crystal render is on the order of 10% + brighter.

I would love to see this fixed, as it makes working with serious edits rather difficult. Thanks!

Attached is a screenshot of the original QT movie, QC playing it 'live', and a render from Quartz Crystal showing the luma shift.

As a side note, it might be nice to have an advanced preference for QT rendering that gives pixel aspect ratio hints, as some times you want to render to say 1440x1080 with HDV pixel aspect ratio so sequences in Final Cut are just that much happier.

Thanks guys, curious on your feedback.

PreviewAttachmentSize
Screen shot 2009-09-26 at 12.13.54 PM.png
Screen shot 2009-09-26 at 12.13.54 PM.png1.31 MB

cwright's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

Please read http://kineme.net/BugReports/QuartzCrystalRenderedmovvideohasdifferentco...

Let me know if you think this is pertinent -- in older versions (1.3 and earlier) we used a generic colorspace, while in 1.4 and later, we use the system colorspace (as that appeared to address the issue in the topic above).

If you have a moment, can you try 1.3, and see if that fixes your problem? If it does, I officially give up, and no longer care about color correction in QuickTime, as that'll clearly demonstrate its brokenness (apps that "get it right" secretly just have a million users whine about every possible special case, and then the devs hard-code color profiles to match the non-standard transforms used in the codec components -- this is not a viable way to deal with this sort of problem).

If 1.3 or earlier does not fix the problem, let's talk some more, and see what's going on.

Please try other codecs as well, and see if the problem persists. If it's codec-specific, then it's a bug in the codec code, not ours.

[p.s. -- also try this on leopard -- with Snow Leopard's gamma change, this might be related to that. If that's the case, I'll have to figure out how to properly compensate for the newly changed screen gamma...]

vade's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

Ill try 1.3. I was on 1.4 (as you guessed), and tried two YUV component based codecs, and both had the issue, Uncompressed 422 and Pro Res 422. Rendering to an RGB based codec like Apple Animation makes no difference. Ill DL 1.3 and try it now.

And trust me, I hear you with QT colorspace issues. The good news is the Quicktime X path supposedly re-writes all of this and makes it all 'just work'. but we've heard this all before ;)

vade's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

So 1.3 has the issue, but its much less noticeable. With 1.3 rendering it looks like luma is ok, but saturation is way down (this is at least judging by eye). Attached is screenshot comparing original with 1.3 rendered animation codec.

Whats the colorspace path in the app out of curiosity?

Edit, I should say I dont have a 10.5 machine hanging around, so I might have to wait a bit before I can test Leopard, all of these tests are on 10.6 (for now).

Thanks for the prompt reply, its appreciated.

PreviewAttachmentSize
Screen shot 2009-09-26 at 1.26.34 PM.png
Screen shot 2009-09-26 at 1.26.34 PM.png1.23 MB

cwright's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

1.3 and earlier simply used this:

CGColorSpaceRef colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);

In 1.4, it was changed to this:

static CGColorSpaceRef CreateSystemColorSpace()
{
        CMProfileRef sysprof = NULL;
        CGColorSpaceRef dispColorSpace = NULL;
 
        // Get the Systems Profile for the main display
        if (CMGetSystemProfile(&sysprof) == noErr)
        {
                // Create a colorspace with the systems profile
                dispColorSpace = CGColorSpaceCreateWithPlatformColorSpace(sysprof);
 
                // Close the profile
                CMCloseProfile(sysprof);
        }
 
        return dispColorSpace;
}
 
...
   colorSpace = CreateSystemColorSpace();//CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);
...

Because the latter method appeared more correct on Leopard. If this is a gamma issue, it'd be nice to know (the latter method is still correct, we're just using the wrong gamma -- no idea how to deal with that though, but at least we know where to look). If it's not gamma, we're back to the drawing board (where I throw my hands up, and say "oh well")

vade's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

OK, correct me if Im wrong, but why would the display calibration/color profile have anything to do with this? Display Calibration is for final output, and will not effect the output of the digital color meter at all. Im mentioning this because it seems like you are creating the QCRenderer based on the displays output color space, which seems odd to me as a) the renderer is off screen, and b) the display colorspace is only for final output correction, not internal color transforms. This would also mean rendering results (as measured by the digital color meter/vector scope etc) would vary based on your display calibration? Perhaps Im misunderstanding though..

You can do a test and edit the color profile on the fly with the Colorsync tool and see that the digital color meter output does not change if you lock it to a certain pixel. This is what you want, because otherwise the display would be changing the internal color representation of the source pixels, where it should just be altering an output transform to correct for display device discrepancies.

I suspect something else is going on here where colorspace keys need to be passed in to Quicktime somehow to tell it what colorspace the source representation is. Core Video has keys for the major video spaces (601, 709, and conversion matrices), so I'm going to assume something somewhere needs to be told the source representation of the input pixels from Quartz is Generic RGB (or, whatever it ends up being). I know this is a major pain in the ass though as I see many posts on this all the time. However you are going RGB to encode, not from a weird YUV with super whites etc to RGB, so you are in a more common scenario.

From my tests with this in the various things I've done (and, don't get me wrong, I'm not trying to be patronizing, just trying to be helpful, you know more about this shit than I do, Im just speaking from my experience), is that I've used the 1.3 method (generic RGB space) as the working and output space for my video playback apps and have had no issues display wise with a myriad of codecs/colorspaces.

Granted display is a simpler "path" than encoding, and I'm sure you've stared at this a lot longer than I have, but I'd imagine 1.3 is more correct color space wise, as I just can't see how the display colorspace would effect an offscreen renderer?

Ill see if I can find some time to throw 10.5 on a spare drive and see where that gets me. Thanks.

cwright's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

vade wrote:
OK, correct me if Im wrong, but why would the display calibration/color profile have anything to do with this?

That's where the magic is -- QuickTime shouldn't be touching the colors. Quartz Composer shouldn't be touching the colors. Since it's offscreen, like you said, it should be a neutral colorspace.

But it's not.

It doesn't work that way.

Until someone at Apple gets the breathtakingly genius idea of an ACTUALLY HOLY-CRAP-NOT-GONNA-COOK-YOUR-COLORS Neutral color space (as in, I put in 255,0,0 for Red, and get 255,0,0 Red output), And implements it in QuickTime, CoreImage, CoreVideo, And Quartz Composer, there will be quirks that depend on the system display for no apparent reason.

There's no rhyme or reason to this.

There's no way to win.

I suppose I could manage an NSOpenGLContext myself, and write low-level QuickTime code (right now I'm just using QTKit for convenience), and then I could manually bake stuff, but it's really not worth the effort -- it should take exactly 0 (but I'll accept up to 1) lines of code to tell these effing frameworks to stop trying to reinterpret my colors.

Philosophically, the colorspace handling in OS X in fundamentally broken -- everything should be in a neutral colorspace, and conversions should happen in exactly 2 places: On output (in the dusplay driver, according to screen calibration), and on Input (in the importer/by the capture device). Who the hell cares what a Nikon D70's native color space is? It needs to be able to output colorspace agnostic images (whether or not it does is academic). Who the hell cares what my display profile is? It's not the app's job, it's the display drivers.

By adopting this remarkably earth shattering theory of STOP TOUCHING CRAP YOU DON'T NEED TO TOUCH, everyone could win. But it's way less complicated, so all the engineers who are currently screwing it up would have to get reassigned. I hear there are some openings on the OpenCL-for-ATI team...

(P.S. the "YUV" colorspace-based codecs actually have multiple standards to choose from: CCIR 601, CCIR 709, and variations of the above with support for super-white/super-black, gamma curves, etc. QuickTime components today use a mixture of the above, depending on the implementers whim. That's fundamentally broken).

(PPS -- I personally preferred the 1.3 method as well, as that made the most sense to me (the display profile has no business being in the app), but I got grilled for it (in the linked thread), and discovered no obvious workaround in QTKit without dropping to the C API -- I'm not that motivated to work around this issue, as QT X is supposed to be the holy grail that saves all of mankind from their colorspace conversion sins. Or something like that. Or maybe that was obama? ;)

vade's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

Well, to be pedantic the YUV variants are for very specific reasons, Rec 601 is for anything NTSC as a source/destination, 709 for anything for/from HDTV / shot with a modern HD camera. The matrices are for the differing luminance components the standards agreed upon when doing conversion from various different other color spaces, so are somewhat reasonable to be there, so you be within spec.

But, regardless It sounds like what you are saying is that my monitor profile effects how Quicktime renders movies (at least in that other thread, and how 1.4 does the color space creation). I don't think that is the case. A simple test can show that changing your calibrated profile does not effect how Quartz Crystal 1.4 or Quicktime output the same input file according to the digital color meter (before output correction which is what I care about).

Now, I totally agree with you on the 'stop fucking with my colors' routine, it took me way to long to realize that QC does this behind your back all the time, let alone all of the other shit out there doing nefarious things behind your back... but man It would be really nice to get rid of this shift, its really noticeable on my system, so much so footage does not even feel the same :(

Thanks for the discussion :)

cwright's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

Your YUV pedantry is completely correct -- however, there are codecs that deal with neither NTSC nor HD, yet arbitrarily use one or the other. Not that one is more "right" than the other, but really, having 2 matrices without explicitly noting which you use is a disaster in the making (making? more like already happening...)

I honestly don't know which conversions are/aren't taking place in QCrystal now -- the 1.3-and-earlier method should have been the don't-use-my-monitor method, while 1.4 should. However, I don't think that's the case in either situation... like you say, it's a deeper, more nefarious (well, mostly lousy design, not actually malicious) quirk that happens somewhere (Though finding out where is half the battle -- image sequences shouldn't get the colorspace treatments that QT movies get, but they still might get other ImageIO colorspace hand holding... too many variables, not enough functions. :/

I'll try to see what's up with the shift, and what I can do to fix it. I can't make any promises, but at least you know your voice is heard, right? :)

vade's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

Thanks, I totally get it, and honestly, if it makes you crazy don't bother too much with it. Ill see if I can find a codec it does not happen with, or if you know / can imagine any other work arounds ill give them a shot. This is a personal project so I am probably bringing in too much day job bullshit but sometimes I can't help it.

However it is a small stumbling block for folks who may want to use this in post/mo-graph land. Might be worth trying to nip it in the bud, or maybe have an advanced output tab for that pixel aspect ratio and hard coded colorspace shit? Thanks again, good to know its heard !

dust's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

ahh the joys of color correcting.

vade's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

Technically this is not even color correction, its more like color calibration :P

dust's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

im there with you man i have a bunch of different calibration settings for various monitors / projectors. it bugs when they are not the same as well. i suppose color correcting and calibrations go hand in hand because you can't really color correct if you don't have the right calibrations, with print, film or digital video. i think print is tad bit easier given you can use a real densitometer.

usefuldesign.au's picture
Re: Luma lift with Quartz Crystal - incorrect luma after ...

vade wrote:
Technically this is not even color correction, its more like color calibration :P
Well, technically colour management I reckon, because that's the table those seats sit around.

If the Tables not flat (ie a mathematically sound theory for the preservation of data) at the OS level sounds like an uphill battle for developers and users alike. I don't envy you cwright and vade. Fortunately I work more in print where colour management tools are much misunderstood but consistent and doable if you know what your doing.