Forum Replies Created

Page 17 of 39
  • Bill Ravens

    January 28, 2014 at 7:29 pm in reply to: Composer Window Timecode Display Size

    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.

  • Bill Ravens

    January 28, 2014 at 4:35 pm in reply to: Good books on Color Grading

    “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 9:00 pm in reply to: Sending Project to a Colorist
  • Bill Ravens

    January 20, 2014 at 7:46 pm in reply to: Color inconsistencies Resolve vs Quicktime player

    FWIW, 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.

  • Bill Ravens

    January 18, 2014 at 1:45 pm in reply to: DaVinci Resolve 10.1 released

    Discovered that xxx yyy is still implementing compatibility with Resolve. Software updates and workflow info will be released at a later date.

  • Bill Ravens

    January 17, 2014 at 4:15 pm in reply to: DaVinci Resolve 10.1 released

    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.:)

  • Bill Ravens

    January 17, 2014 at 2:01 pm in reply to: DaVinci Resolve 10.1 released

    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 yyy

    The User Manual is still dated October 2013. Is there a calibration procedure defined for the other 3rd party calibration software anywhere?

  • Bill Ravens

    January 14, 2014 at 3:48 pm in reply to: DNxHD 185 vs “Same as Source”

    yes, only on QT wrapped files. If I played the same file on WMP, it would appear “correct”.

  • Bill Ravens

    January 14, 2014 at 1:09 pm in reply to: DNxHD 185 vs “Same as Source”

    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).

Page 17 of 39

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy