Dean Manion
Forum Replies Created
-
Hi Peter,
I imagine the issue lies in the compression of H.264
There’s no guarantee that a compressed QuickTime format will not be altered in any number of ways from the original (compressed, albeit less) source file. The reduction in file size alone tells you something major is going on to get it there, not the least of which is reduced luma and chroma range. The client should really judge the original on a calibrated panel. Otherwise all bets are off.Dean
-
jPo is correct and thorough. You need a hardware limiter with correct settings based on your delivery specs, and maybe add a little soft clip to help out.
Correcting gamut errors in Resolve will limit your creativity and eat up your time. Spend the $$ on a Harris and sleep at night.
d
-
I’m seeing a significant performance drop with dynamics. I used to be able to play through iris fixes just fine and now it drops to a ridiculous stutter no matter what I do. It makes it untenable for screening anything. Any kind of key framed adjustment slows to a stutter. Very frustrating.
-
Dean Manion
May 21, 2012 at 4:35 pm in reply to: I bar please in Ultrascope. Or Resolve. BMD, come on, how hard it this?“Your eyes will lie to you. A scope tells the truth.”
There are many truths (or skin tones). Some prefer to measure, others prefer to feel, and still others prefer a good glass of scotch. Me? Depends on my mood. It’s all relative – color grading, skin tones… even scotch. In a relative world, what is truth?
-
Dean Manion
May 21, 2012 at 2:04 pm in reply to: I bar please in Ultrascope. Or Resolve. BMD, come on, how hard it this?I (in-phase) and Q (quadrature) are old analog throwbacks and actually have nothing to do with skin tone at all. These signal references are merely a tool for determining if the original color subcarrier modulation of the NTSC signal was conforming to its phase and amplitude standard. I and Q are just like an X and Y axis for a vector scope signal presentation. The skin tone position on the vector is only coincidentally in the same area as the I axis, depending on the skin of course. I prefer to use my eye.
-
Dean Manion
May 9, 2012 at 4:55 am in reply to: FCP7 motion tab and PTZR settings in Resolve 8.1/8.2dark metadata
That gives me chills.
It’s awesome.
Thank you for that, Rohit. Really. -
The 23.976 and 29.97 scanning frequencies are mathmatically compatible with the original 59.94 scanning frequency of the NTSC color system. The 59.94 frequency was a modification of the original black and white TV system in the US which scanned at 60hz in sync with the AC power frequency. The modification to 59.94 Hz was necessary to maintain backward compatibility with the older B&W tv sets with regard to the audio signal. The new 3.58 mHz color subcarrier had to jibe mathmatically with the number of total scan lines per second (525×30) and in order to do so and still jibe with the original audio subcarrier (4.5 mHz), a small reduction (.1%) had to be made, hence 59.94. We are still conforming frame rates and scanning frequencies to a 60 year old analog engineering compromise. Go figure.
In this regard, 23.976 is the universal master frequency as it conforms mathematically to all the other standards, with certain pulldowns applied where needed.
dm
-
This has been a huge oversight since the first build. I’ve been very frustrated with the lack of a true C-mode sort. Toggling the up/down arrow simply sorts in source code order, with NO source reel sorting. This makes it completely useless for most long form work.
True C-mode sorts the reel names first, then the source code, so all the clips from the same reel are lined up. This is imperative for correcting by reel first, then fine tuning by clip. In a Preconform workflow this is the only way to correct based on reels. Not having it is a huge disadvantage.
BMD, PLEASE FIX THIS!! Pleeeeease!
-
This has been a huge oversight since the first build. I’ve been very frustrated with the lack of a true C-mode sort. Toggling the up/down arrow simply sorts in source code order, with NO source reel sorting. This makes it completely useless for most long form work.
True C-mode sorts the reel names first, then the source code, so all the clips from the same reel are lined up. This is imperative for correcting by reel first, then fine tuning by clip. In a Preconform workflow this is the only way to correct based on reels. Not having it is a huge disadvantage.
BMD, PLEASE FIX THIS!! Pleeeeease!
-
Hey Robbie,
Would love to hear your results and settings/levels with a gamut limiting LUT or track node. This problem is becoming prevalent now with file based delivery. We need a solution that works as well as the DL860. Please post your findings if you would be so kind.Thanks!
dean