|
QuartzCrystal: Rendered mov video has different colors than quartz compositionHello, I converted following quarz composition into Motion JPEG A HD video. Settings of the QC file: 1920x1080, 25fps, length 2 min 20 seconds, only Apple standard patch used. Settings of mov file: 1920x1080, 25fps, length: 40 seconds Motion JPEG A, quality High, Antialiasing 4 or 6 (doesn't matter) The rendered file shows different colors than the QC source file. See the attached image that shows a part of QuartzCrystal and QuickTime video. Note that the preview displayed in the QuartzCrystal has the right color (left side on the picture) I used huey for monitor calibration. Regards Nico
|
It would be interesting to see the first frame rendered out in a number of different codecs to compare. It's the only way to identify if it is a bug or an issue that can be addressed on the developer side. It may be a result of the codec compressing the color space.
There are tons of color-space quirks in QuickTime, often on a per-codec basis. There's no sane way to properly handle it.
For what it's worth, QuartzCrystal has 0 lines of code dedicated to color space handling/correction -- everything from generation to output takes place in virtual color space domain, so no conversions should be necessary.
I've noticed some slight color shifts from all codecs when comparing the preview and the movie side-by side -- this again is QuickTime doing color space "correction". Can't really fix that (there aren't any options to disable it either, without dropping to the procedural QT api, quite a nightmare...)
Hello,
the codecs doesn't matter. I tested with Animation, H264, DVPAL. See attached pictures. Seems to be an internal rendering problem in QuartzCrystal.
Regards Nico
Added: If I export the composition to the QuickTime mov, I open it in QuickTime (Pro) and then I export it again using Motion JPEG A or other codec, the colors are exactly the same. Only the gradient quality in Motion JPEG A was poor. Thus I bought the QuarztCrystal.
I've had endless trouble with rendered output being different from QC. The last demo I did had a lot of noise overlays, and when that was rendered out the noise was totally missing!
To get around it, I've found putting the whole composition in a render-in-image and turning colour correction off seems to help massively.
Quicktime's color space handling is a joke. I'm sorry.
In order, left to right: Preview (from image sequence), None, PNG, H264, MPEG4, Animation, QuartzCrystal. Once QuickTime is The Holy Grail Authority of proper color handling, I'll use it as a benchmark, but for now, there isn't a single Right solution. The amount of time it would take to properly solve this is far more than it seems (because each codec has its own idea of what color correction it should be doing, which is different from all others), and people on the QT-API mailing list whine about this incessantly.
Hello,
now I checked the playback with the VLC Media Player. As far as I know, it doesn't use the QT Libraries, it has own mov playback library.
This way we omit the "Quicktime's color space handling" and see the real color quality.
The color differences are still the same (see attached picture).
By the way Mr. C. Wright: I see only very small color differences in image you provided. I measured the values/colors with the Color Meter tool. The differences were only +/- 10 for every of the R, G and B values.
In my case the value for the B differ near by 49 (100 instead of 51) and for G by 17 (80 instead of 63).
Summary:
Does QuartzCrystal have to "touch" and render the source material or not? I yes, then it have to deal with the colors too, don't have?
Regards
Nico
QuartzCrystal uses QuickTime to encode video, so you're not omitting it by playing in another player. The color correction takes place on Encode (by the codec), not on Decode (well, a conversion takes place there too, but that's more consistent). By using VLC (or MPlayer, or anything other than QT), you've removed the QT Decode correction, but that doesn't affect how the underlying color data was corrected prior to encoding.
Your test with quicktime is incomplete -- my example demonstrates several different gamuts used by each codec. Encode the same source image with different codecs, and you'll get slightly different non-artifact differences in QuickTime. You should also experiment with image sequences (which don't make use of the QuickTime pipeline at all) -- if the problem is as severe there, there might be something we can do about it.
Means that I rewrote how the images are captured from Quartz Composer and handled through CoreImage (for antialiasing, motion blur, and some other processing sometimes). Apple changed how CoreImage worked between 10.5.4 and 10.5.5, and the changes I made took those into account (otherwise, there were some artifacts/blank image problems).
QuartzCrystal doesn't have to touch source material -- if you render without Antialiasing or Motion Blur, and have a registered version, it takes image data directly from the QCRenderer context, and feeds it to QuickTime directly. Even if further processing happens (AA and MB), no color correction operations take place explicitly in our code.
Hello Mr. Wright
Thank you for yours reply. It's nice to have possibility to write to the developer directly :-)
I found something what deals with colors in QuartzComposer, QuickTime and QuickTime Player.
I don't know how you programmed your application, but maybe it will be usable for you.
http://www.mail-archive.com/quartzcomposer-dev@lists.apple.com/msg00611.html
Here my answers on your comment:
I agree with you in one point: the color correction takes place on Encode. But why the colors are correct, when I export as mov out of QC and then export out of QT Pro in any encoded video ? I use QT Pro and it uses QuickTime or not?
I would be happy if I had so small color differences as you
Very, very good :-) You application renders very good gradient quality.
Yes, I have registered version. If you init QCRenderer with default values maybe it uses different colorspace than QT player. Do you use CGL too and render using the hardware renderid? I didn't found any for my ATI 2600 XT video card in the documentation. I would be very happy if you/we could get the QuartzCrystal working as I expect.
That's for QuickTime rendering -- we don't do that. All colorspaces are LinearRGB.
Here's all 1 line of code in QuartzCrystal that sets up colorspaces:
colorSpace = CGColorSpaceCreateWithName(kCGColorSpaceGenericRGB);
The results are identical if you use
kCGColorSpaceGenericRGBLinear
, and if you use any other types, you can't initialize an offscreen QC context.They have access to more quicktime stuff that we do -- I simply use QTKit, because QuickTime API is gigantic and confusing. I admit that this might be part of the reason, but it's not a battle I'm willing to fight (too much time, too much code)
Can you do a test for me, and see if Image Sequences produce similar shifts? That would indicate something in our pipeline that we can address. The difference between the Image Sequence and the QuickTime Movie are the color shift that QuickTime introduces on its own.
We don't use any hardware acceleration, because we want consistent results regardless of video card quirks. Here's another snippet of magical code:
We have a total of 2 lines of OpenGL/CGL code, used to clear contexts between frames:
There -- I've now opensourced 100% of the color handling and OpenGL portions of QuartzCrystal :)
Mr. Wright hello again !
I have three issues:
Which gamma value is used for kCGColorSpaceGenericRGB ?
colorSpace = CreateSystemColorSpace();
The function code is as follows:
(Source from http://developer.apple.com/qa/qa2004/qa1396.html)
Other interesting information about gamma:
http://www.cgsd.com/papers/palette.html http://www.chriscox.org/gamma/
Regards
Nico
With kCGColorSpaceGenericRGBLinear vs. kCGColorSpaceGenericRGB, the output is identical, so gamma seems to have no effect. While perhaps technically different, in this context they produce no change.
The system colorspace seems to make the colors match. I'm concerned because this ties color profiles to the display currently in use (such that both of us rendering the same composition with identical settings will produce different results) -- And herein lies the problem: We're Not Using the Display at all while rendering. So either QTKit assumes that's what we want to do, and this is an idiom for reversing that (can change at Apple's Whim), or Quartz Composer has a bug where off-screen contexts are created with on-screen color profiles (which can also change at Apple's Whim). I'll make that the standard behaviour in 1.4, but hope that it'll be portable to 10.5.7, 10.5.8, and 10.6.x (where 10.6.0 gets the new gamma stuff, and this all gets thrown in the trash again anyway.) I still stand by my opinion that these are all Apple-caused/Apple-related issues, where color profiles are improperly applied in inconsistent ways.
To render image sequences, use the Codec dropdown, and select one of the bottom codecs (PNG Sequence, TIFF Sequence, OpenEXR Sequence, JPEG Sequence).
SOLVED !
It is really the colorspace ! I don't need to do tests with image sequences anymore.
I did the following test: I simple switched to the standard ICC profile and created the video again. The colors were exactly as in Quartz Composer.
It seems that all your customers use standard ICC profiles for monitors, so nobody of them saw the difference ! I use the calibrated monitor and the colors were shifted because of difference between standard ICC and calibrated ICC color profile.
I you want to reproduce the error with colors (what I saw on my monitor) install the ICC profile that I attached to this post (unzip before).
Two Questions: - when new QuartzCrystal version will be available? (Please consider that my video production is stopped now)
I am very happy that we found the solution ;-)
Regards Nico
PS: The color staff is really hard to understand.
"It seems that all your customers use standard ICC profiles for monitors, so nobody of them saw the difference !"
Don't assume. I can be a bit "ornery" about this subject, and colorspace/correction/profiling in general as it's been involved in one of my jobs. I definitely noticed this (and I notice color dif WITHOUT any profile swapping), but I don't feel it's a reasonable complaint for the reasons Chris has noted. I'm a bit wary about color being tied to system. YMMV, and obviously does. I'm pretty amazed that this has stopped any production, but I guess people can be pretty detail oriented about colors...
Now, I'm doubly interested in the conclusion that since you are actually imposing a "calibrated" profile on your monitor and getting incorrect results... that it necessitates different color handling in QCrystal???? What exactly IS your monitor calibration method, because I have done this numerous times and it isn't like there is such a thing as a perfectly calibrated monitor, at least in my opinion. Calibrated to WHAT? (I do see your profile attached profile) At the end of the day, it is still just someone saying "yeah this looks like that, so it's the profile"... and you decide it works for you or not, and you go back and tweak the profile. I'm not really too impressed with many monitor calibration systems... it's a fancy way of doing something different, not necessarily more accurate.
Have you ever given any thought to how different your color looks if you change the x angle on your monitor 5 or 10 degrees either way, let alone what it looks like on a different monitor? Please understand, I'm not "poo-pooing" your comments, I actually think they are really cool, and have resulted in some interesting discussion/revelations. I think it makes more sense for QCrystal to deliver consistent results from machine to machine though, and would be a bit disturbed if this led to that not happening, or aspects that Chris mentions about Apple "at whim" api changes.
And it seems you DID find the solution, which is to switch to standard profile, not whatever the "tweak" is, no? Yet... you are still going to see color differences with different codecs, so not sure if that would satisfy you either?
Ok... looking at the Huey profile...
Been a long day, want to make sure I'm not misunderstanding.
So nico, your theory is that QCrystal should actually take this curve into account?
If that is so, what happens in an environment where you have people working on multiple related version of qtz's, rendering on their own (different model/calibration/whatever) computers, and then wanting to edit all of it together at the end? In my opinion, that seems like it would be a real cluster.
The more I look at this, the more I think the above solution is actually a programming idiom for "Don't Cook My Colors".
Here's what goes down:
So, if we use the "correct" color space (the one QC uses by default), it essentially tells QuickTime that no conversion is necessary. (How Win32-esq, requiring explicit code to Not Do Things....)
I'm going to run this through a few tests on my two machines tomorrow, and see if things are coherent and sane. If so, I'll probably leave it as-is, and then just keep an eye out for when/if Apple decides QuartzComposer should properly use neutral destination colorspaces for offscreen renderers.
ohhhh. ugh. sucks to be you right now :o) (sorry had to say it)
QuartzCrystal 1.4 uses system/screen color profiles to address this problem (hopefully without side effects)
Excellent news.
I read Real World Color Management (1st edition) twice and (mostly) understood it. I'm pretty sure a "neutral" colour-space does not exist either.
The desire for a simple convert to "neutral" colour-space at input -> process data in a 'safe' neutral space-> convert to an output profile on outputting device, while an attractive methodology in theory, is practically stymied by physics, mathematical representations/models of colour and industry considerations.
Above reference explains the complexities and models methodologies as well as anything I have read on the subject and debunks a few documents (like Adobe's CS colour management and Apple's colorsync documentation) that offer a reductionist simplification of the issues at best, glaring errors in the worst cases.
There is always colour management happening whether it is by intent or by neglect. eg: Putting Adobe colour management settings in Photoshop to "Do not manage" = neglect.
(If I had a dollar for every time a graphic designer/IT consultant said "Oh change the document to CMYK that will make it print correctly"...)
Interestingly enough, this "fix" actually breaks (as in, crashes) on Snow Leopard on ATI X1600 graphics cards... back to the drawing board with how to properly solve this problem.