Bill Ravens
Forum Replies Created
-
As I recall, the settings are tied to font and size for another parameter, perhaps the Bin font/size. Trial and error should pinpoint it.
-
“COLOR CORRECTION HANDBOOK” by Alex Van Hurkman
and
“THE ART AND TECHNIQUE OF DIGITAL COLOR CORRECTION” by Steve Hullfish -
-
Bill Ravens
January 20, 2014 at 7:46 pm in reply to: Color inconsistencies Resolve vs Quicktime playerFWIW, I contacted the vendor for Calman to get a workflow definition. They’re still working on incorporating their cal software in Resolve, even tho’ resolve 10.1 is ready for it.
-
Discovered that xxx yyy is still implementing compatibility with Resolve. Software updates and workflow info will be released at a later date.
-
Juan….
You’re right. but the last time I posted that name, my post was blocked. So, I used the generic name xxx yyy so my post wouldn’t be blocked.:)
-
The following two notes are provided in the v10.1 README:
• Support for rectangle patch size for monitor calibration
• Added monitor calibration support using xxx yyyThe User Manual is still dated October 2013. Is there a calibration procedure defined for the other 3rd party calibration software anywhere?
-
yes, only on QT wrapped files. If I played the same file on WMP, it would appear “correct”.
-
For a while I was using Hamlet’s Videoscope to read and measure my final output file color and luminance values. I began to notice the curious phenomenon that ALL my Quicktime wrapped files were 16-235. At this point, I started using external WFM’s to confirm what Videoscope was telling me. I discovered that Quicktime will consistently remap luma values during playback, even if the original footage is already 16-235. The net effect is that 16-235 native footage will display as something like 32-220, giving that chronic milky washed out look. And 0-255 native footage will display as proper (16-235) REC709, even if the footage is actually 0-255.
As far as I’m concerned, it would be a HUGE step forward if QT gave the user the ability to set the flag in the header. But, I know I’m just day-dreaming as Apple will never relinquish this control.
-
Bill Ravens
January 14, 2014 at 12:59 pm in reply to: is 8-bit YUV via HDMI good enough for color correction?All consumer grade monitors in today’s market only display 8-bit. It’s rather pointless to worry about sending a 10-bit signal to an 8-bit monitor. So, unless you’re working with a professional 10-bit monitor, that BMD card is OK.
The real question to be concerned with is whether your monitor is calibrated to display the right colors and luminance values. This is where you can be misled in grading, when your monitor isn’t displaying the right color gamut (REC709?)
As an aside, grading native 8-bit footage won’t result in the wrong colors, but, it will result in banding in subtle gradients, like the sky. As long as you’re working in 8-bit, this will happen. So, even with a 10-bit display, if the data pipeline has an 8-bit component, such as having 8-bit native footage, there’s nothing that can be done to mitigate the quantization errors(banding).