[Nat Jencks]

You may be outputting RGB 444 to a display thats expecting YUV 422. check your output prefs.

[Nat Jencks]

You could draw power windows shaped like numbers and animate them to count down 🙂

-Nat

[Nat Jencks]

[Mike Most] “You can easily create a node to implement the log to video conversion and use that as a key source, by piping the alpha channel from it into a color node that is fed from the original log image. That way you get both coloring flexibility and the more accurate mattes.
“

Thanks Mike, this is a good tip. I’d still love a HSV keyer which could scale to log appropriate ranges, but this is a good work around in a pinch if this became a big issue for a specific problematic shot.

Thanks!
-Nat

[Nat Jencks]

[Marc Wielage] “This is kind of like saying, “doctor, it hurts when I do THIS.” And the answer is, “don’t do that.””

Grading in LOG (under a curve) is not exactly an obscure edge case use for color grading software. Many of the colorists I know doing features work this way. And of course grading in LOG works perfectly well in resolve, but the HSV ranges and curves ranges could use some help.

Most folks that work this way just make do with the HSL ranges being a little whacked. Adjusting the ranges to allow a “Log Mode” with more appropriate ranges isn’t exactly re-architecting the software its a fairly simply change.

This is more like going to a doctor and saying “sometimes my ankle hurts when I walk up stairs in these shoes”, and the doctor saying “well then don’t use stairs” 🙂

[Nat Jencks]

[Marc Wielage] “I prefer to drop the camera Raw LUT in first (or use it in the config as an input LUT), because this way you aren’t struggling with keys and other issues. But not everybody agrees with this method.
“

Yup, LUTing on input certainly solves this specific problem, but thats not the way I work. There are advantages to both ways of working but for me and many others, working underneath the curve and output color transform has many advantages.

Best-
-Nat

[Nat Jencks]

Hi Robert, how are you debarring the R3D? REdLogfilm and then an output LUT, or Redgamma3 etc? If you are debayering as Log and then grading under a curve, your are correct that the HSL ranges are way wrong.

This is true for v10 as well.

It would be very nice if there was a setting to change the HSL keyer to a “log mode” with log appropriate ranges.

This may not be your issue, but it is something I have noticed.

Best
-Nat

[Nat Jencks]

Yeah, I’m really enjoying caching, but there are some quirks with input side caching… If I have a 6K dragon file and want to cache it on the input side, if I copy a grade from another shot via middle click. it looses its cache. BMD are working on it though!

So great to have this. For things like Temporal NR, and the heavier Sapphire FX etc the caching feature is really a god send.

best-
-Nat

[Nat Jencks]

The confusion about gamma is related to the fact that there is no strict standard for display gamma in Rec709, this isn’t really an issue for your DCP, this is only an issue of when you playback a DCP on a Rec709 display you must of course tell the playback device what the target gamma of the rec709 display is, and this will vary depending on if you say 2.2 or 2.4.

Display gamma in an actual DCI cinema does not vary and the image will always look the same.

So this is just an issue of playback to rec709 display and that REc709 doesn’t have a strict gamma.

best-
Nat

[Nat Jencks]

Hi Vedat, no this isn’t really a good method to “test” this.

Once you’ve encoded the DCP its in XYZ space and expecting a display gamma of 2.6

When you play back the DCP with easyDCP easyDCP can do the XYZ->RGB conversion, but for it to display correctly it will need to make some assumptions about the gamma of the target display. From what you have described it sounds like easyDCP may well assume a display gamma of 2.2 when you playback on a normal computer display which wouldn’t be unreasonable since typical computer displays are sRGB which has a gamma of 2.2

So, short answer, not this is not a good way to test this.

I’d suggest taking the colorists word that it was graded to a rec709 display with gamma 2.4. I’d also have your colorist screen the finished DCP in a proper DCI environment to check it.

good luck
-Nat

[Nat Jencks]

Traditionally RAM usage for Nuke has been as much as you can throw at it, since it uses RAM for caching on playback.

However, with the boot drive now offering very fast read write times (~1000MBps) disk caching is a viable option and can actually provide decent performance.

Using the internal boot drive for disc caching is sort of a poor mans FusionIO card.

Thanks for the feedback re Motion AE and FCPX. I don’t use those, but I don’t doubt that if I have Nuke and Resolve open at the same time as well as some OFX plugins grabbing their own share of RAM, that 32GB might get used up.

Anyone else have thoughts?

Thanks again.
-Nat