Forum Replies Created

Page 1 of 3
  • Alexis Hurkman

    November 17, 2014 at 6:21 pm in reply to: outgoing – incoming frames viewable simultaneously?

    Ah, I got you, you want to compare the In and Out frames of the SAME CLIP. There’s no control for that currently, but I can see why that would be interesting.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    November 17, 2014 at 1:35 pm in reply to: outgoing – incoming frames viewable simultaneously?

    There is actually a Split-Screen mode that automatically compares the previous two, current, and next shots automatically as a four up display, such that you can make adjustments to the current shot while monitoring all four adjacent shots. Moving to another shot automatically updates this four-up display, so you can move from shot to shot and always see a set of comparison images for grading. No still store required.

    To do this:

    (1) Turn on “Split Screen” in the top Viewer toolbar

    (2) Choose “Neighbor Clips” from the split screen mode pop-up that appears

    This is a full-frame, side-by-side comparison that you can toggle on and off. There are other useful split-screen modes as well to display other comparisons, such as my favorite, the “Selected Clips” mode that lets you see a comparison of all the clips you care to select in the timeline (up to 16). The full explanation is on p.474 of the user manual, if you want all the details.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    July 22, 2013 at 10:28 pm in reply to: Best tutorial

    Best is relative. Warren, Patrick and I all have very different teaching styles, and tackle the application and the process of grading in different ways, and over different durations. I’ve got a hard time being self-serving enough to make any sort of recommendation, other then to say that I’ve spoken to some who feel our products are somewhat complementary, so I don’t think you can go wrong. Check out the samples and see who you like listening to and watching the most.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    March 15, 2013 at 5:47 pm in reply to: ACES implementation in Resolve – bugs

    I believe the whole point of ACES is to convert image data into a color space with a gamut that’s large enough to contain all the information in the media, eliminating the need for specialized, format-specific controls.

    R3D-specific controls are for adjusting how raw media is converted to a data format usable by an image processing application, the idea being that there is potentially more image data in the raw file then can be contained in, for example, the target Rec. 709 format, so these controls help you choose what part of the image data to emphasize, and let you play with the math of the conversion in different ways.

    However, when using ACES, in theory the full data from each camera original file is converted without clipping into the huge gamut of ACES color space, using that camera’s IDT, which defines how image data from that camera is to be transformed into ACES space with the highest fidelity. In theory, the camera manufacturers control and create the IDT for their camera to provide the best data representation of their technology.

    In short, the RED IDT is supposed to put every bit of an R3D file’s data into ACES space, so there’s no need to use RED controls, you can simply use the host grading applications ordinary controls as you would with any other format.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    January 3, 2013 at 5:36 pm in reply to: Grading DPX Log Files

    This is the best explanation of the corrective use of the Log controls for logarithmic media that I’ve ever read or heard. Thanks, Mike!

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    January 2, 2013 at 7:40 pm in reply to: Grading DPX Log Files

    The name of the LOG controls is in my opinion misleading, because they’re not specifically for making adjustments to logarithmic media, with the exception of maybe the contrast control, but the S-curve it applies isn’t specific to linearizing log material, and you can do better creating your own custom curve.

    You can either manually linearize log material using the custom curves, which gives you maximum control at the expense of being a bit time consuming, or you can use some means to create a series of LUTs that are specific to your project, and use these as a starting point (for example, creating a series of LUTs of varying contrast and applying the one that works best for a given scene). If you apply a LUT using a node that’s “downstream” in your tree, then you can trim the data using an “upstream” node to account for any unwanted clipping.

    If you’re doing a LOG to LOG workflow, you can apply a LUT using the Project Settings Look Up Tables panel, either as a Display LUT or as an Output LUT, which will then effect the entire project as the last operation in the image processing pipeline. Display LUTs are never rendered into output, whereas Output LUTs are if you leave them selected. This way you can apply a universal linearizing LUT to your project, and then turn it off to render LOG output.

    I don’t do LOG to LOG workflows typically, so please someone chime in if I’ve omitted a step.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    August 1, 2012 at 11:03 pm in reply to: resolve 9. how to disable video output?

    Disabling your video card in the preferences is the current official way to do this. The team had me put the following note in the manual:

    “Note: Disabling video output can improve real time performance when external monitoring and output is not a priority. You can also choose “None” when you’re using Resolve with another application open at the same time that’s using your workstation’s video output interface. When you’ve quit the other application, you can reselect the video output interface for use by Resolve.”

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • I hate to chime in late to a thread that appears to have reached its natural conclusion, but I missed it earlier, and since Apple documentation has been brought up, it seemed interesting to add another perspective, since I wrote the passages under discussion, and it may shine a light on both some design decisions in FCP and Apple Color, and how terminology gets coined and, right or wrong, disseminated. My apologies in advance for the length of this missive.

    When FCP 3.0 was in development, the then-new color correction tools and video scopes being added were brand new to the majority of desktop video editors, and the engineering team was working to try and make this unfamiliar paradigm of lift/gamma/gain style controls and the accompanying scopes comprehensible to a new audience. It was a deliberate design decision to include one half of the in-phase axis indication line all by itself as an indicator of the general hue of skin tone, since to my knowledge the not-so-coincidental dual use of that indicator had been a documented rule of thumb of videoscope use for years prior.

    In an effort to make the purpose of this line more transparent, I and some others decided to call this the “Flesh tone line,” a decision I now somewhat regret as it muddies the history of this indicator; and yet as this was the only one of the in-phase and quadrature lines that the team elected to draw upon the FCP vectorscope, I stand by the decision as it made immediate sense to the new user, and the purpose of this indicator as intended had nothing to do with signal alignment, and everything to do with providing a flesh tone signpost to people new to reading scopes.

    Regarding the “I-bar” terminology, this was the term I decided upon when writing the Apple Color documentation, as I expected a more experienced audience would appreciate an acknowledgment of the original purpose of this line. Also, the Color team implemented all four in-phase and quadrature indicators, so it seemed appropriate, “I” for in-phase, bar because it was a line.

    I did not make this term up; after scouring different terminology from various sources, I found and settled on “I-bar” as the shortest term for purposes of documentation (try typing “i-axis indication line” ten times fast). Unfortunately, I can’t cite my source anymore as this was years ago, but nobody in a position to offer a technical review of that manual, nor any colorist who’s done either technical or casual reviews of books I’ve written since, has ever informed me that “I-bar” is wrong, and I’ve been using it consistently ever since. If, in fact, it turns out that my deadline had made me delusional and “I-bar” was the fevered ravings of a caffiene-addled technical writer, then I still stand by it since it’s less to type and is a fine abbreviation, but I cannot in truth take the credit.

    I’ve discussed the history of the I and Q axes with many folks over the years, and while it’s true that the engineering reasons behind these indicators have nothing strictly to do with flesh tones, my personal feeling is that the coincidental utility of the in-phase indicator’s position has, over time, come to outweigh its original purpose, and in fact I would consider the “I-bar” we’re currently referring to as a new thing that coopted the old, sort of like Easter coopting an earlier collection of various pagan celebrations.

    To clarify, I would never and have never suggested that this line is a strict guideline for human hue. In my “color correction handbook” I wrote and illustrated more pages then my editor may have wished about the subtle variations of human skin tone, and how the in-phase indicator under discussion is merely a general signpost; like speed limits, nobody follows them exactly, but it lets you know you’re around what you ought to be doing.

    Lastly, I’ve used scopes that have an I-bar, and I have a very expensive scope that doesn’t (in HD mode, as has been pointed out), and while I still think it’s nice to have, its absence has never hampered me from delivering attractive skin tones to my commercial clients. However, given the choice, I’d like to see this indicator as an option for folks who like it; in fact, I’d love to see someone develop the option for multiple programmable vectorscope indicators at user-selectable angles, but then I’m a bit nutty for options. The hue that, in NTSC, is represented by the I-bar can certainly be mathematically translated into the same hue in HD color space, and I see no reason why that wouldn’t be useful or appropriate, if it’s documented clearly that this is no longer in-phase, but in fact an analogous flesh tone guidepost that can be turned on or off.

    I would suggest that video scopes at this point are simply software, and it should be no sin for developers to add new features of utility to users and to label them clearly. I’m fond of pointing out that the days of fixed ground glass graticules are over, and it would be nice to see developers find more things to do with scopes for both basic and advanced users then to simply replicate functionality from analog, trace-drawn CRT technology.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    February 12, 2012 at 4:45 pm in reply to: Vectorscope accuracy once and for all! COMPARISON

    I’ve loaded all three of your test pattern files onto my Resolve suite machine, and output to my Harris VTM 4100 video scope. The Belle Nuit pattern is off, it’s displaying 100% and 75% bars, but it looks like the file was generated scaled to full digital range, rather then studio range, so that explains one of your issues.

    However, the other two test pattern files (SMPTE and DVE) fall right into the Harris’ target boxes. The DVE pattern’s Cyan bar is hugging the inner-left corner a bit, but it’s still inside.

    Comparing this output to the DaVinci software scopes, (a) it’s hard to read because the DaVinci scopes show a scatter not a trace, (b) they appear to be off for some targets but not others. If I were a betting man, I’d say the graphs themselves are probably accurate in shape, but the DaVinci software vectorscope targets are possibly being drawn for the wrong color space for some reason. However, that’s just a guess.

    Using the latest beta of Scopebox, the SMPTE and DVE patterns fall into the proper boxes of the Vectorscopes, so you may be seeing an issue from version 2 that will be fixed when version 3 comes along. Either that, or there’s a color space setting that needs to be manually adjusted in version 2 (I don’t know Scopebox all that well).

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

  • Alexis Hurkman

    February 9, 2012 at 9:19 pm in reply to: Group behavior

    That is my understanding, yes. Personally, I find I don’t use groups much, but then I don’t find myself grading that many programs with highly structured coverage or obviously repeating and identically lit headshots, etc. Others I’ve spoken with use groups a lot more. It’s a personal workflow thing.

    http://www.alexisvanhurkman.com | http://www.correctionforcolor.com

Page 1 of 3

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