Gary Adcock
Forum Replies Created
-
[Manuel Garcia] “I’m digitizing a tape and taking time code from a betacam BVW75. Is there a setting that will allow the file created to follow those time code breaks? “
if you are looking for the KiPro to handle creating subclips?
it cannot be done via analog.
If you had a digital (HDSDI) deck, you set up the KiPro as you would for recording from a camera, turing on the Arm/TC IN setting and use the Timecode over SDI RP188 then every TC break would start and stop the recording creating a new clip at every TC break.
but only in digital.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Chris Crawford] “We are recording at 720/59.97 ProRes 422”
I ask because there are some formats that have differing audio settings- in Germany for instance audio is set to +15db instead of +24
you might try some tests with the Audio gain set to +18 or +15 and see if your audio levels get better.
Note that analog audio is usually set at a lower level than digital audio is.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
OK
you do not say what formats you are recording,
“Toned and set levels using meters to 1st yellow light on Ki-Pro.”
Chris, this seems low to me also
if you turn on Menu Item 41.3 (Audio Sg) and then set the unit to “1Khz Tone” you will see that AJA has the tone calibrated to the show the first Orange/ Yellow Bar on the audio meter, if that is too low you will need to adjust the acquisition to record the audio that fits your workflow.gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Rob Grauert] “hmm, well, I’m glad regular ProRes is just fine for most cameras, cause this is WAAAY over my head.”
I am sorry that it gets into head butting Rob,
Most people accept the simplest answer, that ProRes standard is more than good enough for the vast majority of users, HQ is needed if you really want to maintain fidelity at the cost of greater hardware and storage needs and that 4444 ProRes from a camera original is really only for the highest level workflows. (FYI – currently only certain models of the Arri Alexa can capture onset as ProRes 4444 and I happen to be one of the very few people that have access to one of these cameras)
Quality to some is a judgement call, to me its about maintaining the quality of my images thru post – not about how much space or bandwidth the compression uses.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Dennis Couzin] “ProRes4444 is 10-bit RGB+alpha.”
Dennis Couszin – You need to refresh your knowledge of the the article you keep quoting since the July 2009 Apple White paper on ProRes clearly states that “Apple ProRes 4444 supports 12-bit pixel depth with an optional, mathematically lossless alpha channel for true 4:4:4:4 support” on page 4, in the middle of paragraph 3.
So if Apple states that the codec in 12bit- How do you know that it is only 10bit.[Dennis Couzin] “(Allow me to write YUV instead of Y’CrCb, since the terms Cr and Cb tend to be misunderstood.)”
Y’Cr’Cb’ is the correct SMPTE designator for digital component video in HD, how is that somehow misunderstood?[Dennis Couzin] “If the original material is 4:2:2 YUV, as it is in Anthony DeRose’s original example, why does Gary Adcock suggest that transcoding this to 4:4:4 RGB (ProRes4444) is better than transcoding it to 4:2:2 YUV (ProResHQ)?”
I did not, I clearly state that [gary adcock] “So in mainstream use, the 4444 codec is designed to handle graphics and animations.” in my note to Phil regarding his question on when to use other flavors of ProRes.
[Dennis Couzin] “REDCode material, derived from the RGGB Beyer filtered sensor, is not straight RGB. If RED patent application 12/422,507 is to be believed, the camera outputs a kind of quasi 4:2:2 YUV.”
So you have never used a RED Camera have you? The video output from the RED is not considered to be more than a confidence monitoring signal- REDCODE is captured as an R3D file on a RED Drive or CF card and has little to compare with the video signal out of the camera. The R3D format from RED is considered to carry more than 10bits of data so why wouldn’t it benefit from the best desktop codec that can handle more than a 10bit signal?
[Dennis Couzin] “Why does Gary Adcock call ProRes4444 lossless?”
Once again Dennis Couzin, while calling me out, you have incorrectly read or reported on my remarks, and in some cases erroneously state claims are not true.
I clearly state here that [gary adcock] ” ProRes HQ is considered to be the equivalent to HDCAM SR, and that is considered a lossless archival and delivery format”
SO it is HDCamSR that is that is considered “Lossless for Archiving” though it is technically not lossless.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Phil Incorvia] “keeping HQ and 4×4 in mind for RED and EX1 footage might be smart.”
For REDCode yes.
but not the for the EX, that is still an 8 bit 4:2:0 long GOP mpeg recording.gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Phil Incorvia] “Could you give some examples of what ‘heavy’ has meant in your experience?”
Sure Phil, but lets define a few things-
I almost never work with compressed camera original content, I prefer uncompressed or camera native in the case of Phantom, SII, RED and the h.264 from the Canon DSLR’s. This means I am looking at content that has little compression to start with (except for the DSLR’) so my standards of quality reflect what my preferred capture format is.
Secondly I work with really really fast storage, on fairly new computers running the latest software- I never cut content on a firewire drive except when on location.
Lastly I measure the loss by what the tools tell me, using the best hardware and software tools made to evaluate the signal and the images, I do not rely on my eyes, as they have been known to trick me after a long day.
I have tested the ProRes HQ codec extensively, I have run generational lost tests, signal degradation tests and plain old user tests. I have yet to find any need for anything greater than the HQ version of ProRes for ANY camera that is not able to capture greater than 10bit internally, ProRes HQ is considered to be the equivalent to HDCAM SR, and that is considered a lossless archival and delivery format.
Since the vast majority of users are not working with HDSR, or have access to a $100,000+ deck, that makes ProRes HQ a better format than they currently acquire in.
ProRes 4444 is designed to handle up 12bit files with an Alpha Channel and there are very very few cameras on the market that actually can handle the full 4096 levels of gray per channel. Yet, I do not know of one that can also produce an Alpha at the same time. So in mainstream use, the 4444 codec is designed to handle graphics and animations.
I have tested the ProRes HQ codec and did not find any technical or visual errors until the nearly the 50th re-encoding of the same file in the same codec.
I consider it heavy processing anytime I need to re-encode the same file more than 4 times, and that is something that is just not done in modern filmmaking.
The Canon DSLR content is recorded as 4:2:0 LongGOP at 8bits and compressed for direct web delivery in Full Range SMPTE RGB as an h.264 file. The sheer compression of the original file shot by these cameras does not offer anything to gain by going to the 4444 codec.
does this help?
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Fred Connors Jr.] “It is 7.5 not 10, and it is usually in the setup playback preferences of the HDCam deck”
THERE IS NEVER “SETUP” IN DIGITAL FORMATS
sorry fred,
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Dennis Couzin] “Not all H.264 has been smushed to the point where ProRes and ProRes HQ transcodes are indistinguishable”
That would not be the experience of a number of people on this forum, file compression itself, has little to do with the image compression/ decompression cycle. We are discussing the internal compression from a canon 5D camera, which has been compressed about as much as is possible, then using an intermediate codec to achieve smooth playback and editing in Post.
Anthony,
using the standard vs HQ flavors of ProRes allow you smaller files and less cpu power to handle the playback, so the Standard version of ProRes will allow better playback, more RT effects and easier load on your computer and both codecs are full raster 10bit, iframe @4:2:2 without any additional compromise in your quality.Using the HQ codec only offers advantages if you are planning on doing heavy effects or corrections within the ProRes codec or the FCS3 suite, and if you are you should be working in the lossless 4444 version, You gain nothing going to HQ if the compositing is being done outside of the FCP/ Color workflow, nothing at all.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640
-
[Ashley James] “Nothing to do with the monitor. Its the timeline that’s choking.”
IF the IoHD is attached to your computer and your timeline is set to use the device- the timeline will choke under RT extreme.
The Ex camera uses Long GOP mpeg compression that processor dependent to decode and playback, if you are also trying to output that signal via the IoHD it is going thru a secondary step to convert it it prores for playback.
gary adcock
Studio37Post and Production Workflow Consultant
Production and Post Stereographer
Chicago, ILhttps://blogs.creativecow.net/24640