Return-Path: Received: from mail-la0-f41.google.com ([209.85.215.41] verified) by media-motion.tv (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 4908478 for AE-List@media-motion.tv; Sun, 25 Nov 2012 19:09:14 +0100 Received: by mail-la0-f41.google.com with SMTP id m15so5418293lah.28 for ; Sun, 25 Nov 2012 10:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=qhzG89j6Nr8lUpBVhjL0qKmy/I2hyof6Mg0X3pUGvzc=; b=WhGW6wCez84TrL2xxMBZKJgQZIvZQDwsdIxSMP+XcHp6pVhIGcdOYxOLVHY4IL6Pfz gj/qniovhndSNPWrZGobd19+vzBW3QMByD948FATv2ra5wc3tILVaRBoL7pz4SpqCQuQ xobHTlSTfAshZWU6W/+yX2YDyrFjpOBd27Z8QMr6ovX/tehLchbOQc7eySmr1ai/XqkR cnlc0Y85e3fvPs90pYLhr1lU3LbFuNT3Db1R3qrD+nC++gizw4U3NnkKFYz8yx4dlQZX K4J9aG1VaNDSbs0myyBdzGpelDkSI1DI5RrBXVgtWYmhT8c/f9v4qbLc17u8iJB+slY9 IiQA== Received: by 10.152.147.100 with SMTP id tj4mr8593252lab.42.1353867172614; Sun, 25 Nov 2012 10:12:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.135.41 with HTTP; Sun, 25 Nov 2012 10:12:12 -0800 (PST) In-Reply-To: References: From: Teddy Gage Date: Sun, 25 Nov 2012 13:12:12 -0500 Message-ID: Subject: Re: [AE] Arri flat To: After Effects Mail List Content-Type: multipart/alternative; boundary=e89a8f22bd89e5921a04cf55c349 --e89a8f22bd89e5921a04cf55c349 Content-Type: text/plain; charset=ISO-8859-1 OK that helps. That's sort of what I was doing already- but I'd really like to avoid having to work on the effects directly in c-log, it's gonna be a huge headache with color space conversion and preview. I was thinking maybe a round trip through dnxHD 10-bit may be the answer. The final deliverables are going to be HD5 for broadcast as far as I can tell, and maybe a DCP. Looks like I need to have another conversation with the director and online editor to figure out this workflow and how they're doing the color correct. I wish they'd just shot dnxhd in the first place... -TG On Sun, Nov 25, 2012 at 12:58 PM, Jim Curtis wrote: > I touched on this already, but what I've done is to put a first instance > of levels on the clips or an adjustment layer to get the levels on a WFM in > the ballpark of 1-100. Then, I add a second instance of other plugs (I > like Frishchluft FL Curves best) for fine tuning. > > What you render to depends on where you're going. I was doing broadcast > spots, so I rendered to ProRes422 (in RGB color space) and made MPEG2 for > distribution via DG and ExtremeReach from those. > > To be honest, I don't know if that's a great method, but the footage looks > great, and I love the expanded dynamic range and the minimizing of clipping > in the whites that I often see with lesser capture formats. > > Monitoring: I have a calibrated HP DreamColor display and a Sony > Trinitron CRT hooked up to a Kona for accurate monitoring. I use an Apple > Cinema Display for my computer monitor, and I can attest that the images > are vastly different between the computer display and the broadcast > monitors. What looks right on the broadcast monitors is super-saturated on > the ACD (using the default Cinema HD Apple profile - not flat). > > You can check yourself by looking at the scopes in Ae bundled Color > Finesse, if you don't have any other scopes available. Or, you can check > your work by using the scopes in Pr, if you have that. I run Synthetic > Apps Test Gear full-time in Ae. > > I'm sure you're aware that home HDTVs have picture settings that alter the > contrast, saturation, etc. Whether your HDTV gives you an accurate look > depends on many settings and the hardware feeding your HDMI signal. But, > if that's all you have, then see if your output compares favorably to what > you watch on TV. If it looks right, maybe it is right. > > > > > On Nov 25, 2012, at 11:26 AM, Teddy Gage wrote: > > ok looks like it is 4444, 276 mbps. I wasn't aware the arri encoded > directly to prores so that solves one problem, namely what I thought was a > bad transcode. Looks like these clips are direct from camera. > > Now what's the best way for this footage to make the round trip, FX-wise, > without destroying the integrity of the 10bit 4444? I'm thinking: > > - convert to log c color space / 32bpc to work in. Match all FX footage / > roto / stock elements to the log c preview? > - render back out to lossless QTs in 10bit YUV from AE > - do I render in video color space or should I render out in the log c > profile? > > I don't have an HD monitor, I have a high-end "graphics" monitor (the eizo > CG222, extremely flat response, color accurate, 99%+ of adobe RGB) but to > get an accurate final preview I may throw it onto my HDTV (not ideal, I > know, but at least should give me an idea what I'm looking at, right?) > > Any other tips / gotchas would be greatly appreciated. > -TG > > > > On Sun, Nov 25, 2012 at 10:53 AM, Jim Curtis wrote: > >> You can tell if it's 422 or 4444 by looking at the clip info in the Ae >> Project pane, or by using Get Info in QT Player. >> >> The Alexa footage I've worked with (just three projects, so I'm no >> expert), the camera was connected to a cinedeck via 2 BNC cables, and the >> native footage was ProRes4444+, or IOW, no transcoding was done or >> necessary. >> >> If it was recorded to ArriRaw and transcoded with settings "baked," you >> have been robbed of the post-production benefits of recording in RAW. >> >> >> On Nov 25, 2012, at 9:40 AM, Teddy Gage wrote: >> >> OK so j. Penzer said the arri is using log c color space. This is the >> answer I was looking for. Here's my concern. I am ingesting prores >> transcodes, not the original camera files. The histogram for this footage >> in 32bpc is compressed on both sides and very clipped in the middle >> a) I am concerned the editor didn't do the transcodes properly. I'm not >> even sure whether they were converted to 8 bit 4:2:2 or 10bit 4:4:4. I am, >> unfortunately, one of the more tech savvy people on production. Is there >> any way to figure this out? >> >> B) how should I handle final outputs? Should I use color space >> conversion back to log c on export so it's consistent in fcp? Does fcp do >> this conversion automatically? >> >> Thanks! >> >> >> > > > -- > Animator & Editor > www.teddygage.com > Brooklyn > > > -- Animator & Editor www.teddygage.com Brooklyn --e89a8f22bd89e5921a04cf55c349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK that helps. That's sort of what I was doing already- but I'd rea= lly like to avoid having to work on the effects directly in c-log, it's= gonna be a huge headache with color space conversion and preview. I was th= inking maybe a round trip through dnxHD 10-bit may be the answer. The final= deliverables are going to be HD5 for broadcast as far as I can tell, and m= aybe a DCP. Looks like I need to have another conversation with the directo= r and online editor to figure out this workflow and how they're doing t= he color correct. I wish they'd just shot dnxhd in the first place... -TG

On Sun, Nov 25, 2012 at 12:58 PM, Jim= Curtis <jpcurtis@me.com> wrote:
I touched on this already, but what I&#= 39;ve done is to put a first instance of levels on the clips or an adjustme= nt layer to get the levels on a WFM in the ballpark of 1-100. =A0Then, I ad= d a second instance of other plugs (I like Frishchluft FL Curves best) for = fine tuning.

What you render to depends on where you're going. =A0I w= as doing broadcast spots, so I rendered to ProRes422 (in RGB color space) a= nd made MPEG2 for distribution via DG and ExtremeReach from those.

To be honest, I don't know if that's a great method,= but the footage looks great, and I love the expanded dynamic range and the= minimizing of clipping in the whites that I often see with lesser capture = formats. =A0

Monitoring: =A0I have a calibrated HP DreamColor displa= y and a Sony Trinitron CRT hooked up to a Kona for accurate monitoring. =A0= I use an Apple Cinema Display for my computer monitor, and I can attest tha= t the images are vastly different between the computer display and the broa= dcast monitors. =A0What looks right on the broadcast monitors is super-satu= rated on the ACD (using the default Cinema HD Apple profile - not flat). = =A0

You can check yourself by looking at the scopes in Ae b= undled Color Finesse, if you don't have any other scopes available. =A0= Or, you can check your work by using the scopes in Pr, if you have that. = =A0I run Synthetic Apps Test Gear full-time in Ae.

I'm sure you're aware that home HDTVs have pict= ure settings that alter the contrast, saturation, etc. =A0Whether your HDTV= gives you an accurate look depends on many settings and the hardware feedi= ng your HDMI signal. =A0But, if that's all you have, then see if your o= utput compares favorably to what you watch on TV. =A0If it looks right, may= be it is right.



On Nov 25, 2012, at 11:26 AM, Teddy Gage wrote:

ok looks like it is 4444, 276 mbps. I wasn't aware = the arri encoded directly to prores so that solves one problem, namely what= I thought was a bad transcode. Looks like these clips are direct from came= ra.

Now what's the best way for this footage to make the round trip, FX= -wise, without destroying the integrity of the 10bit 4444? I'm thinking= :

- convert to log c color space / 32bpc to work in. Match all FX footage= / roto / stock elements to the log c preview?
- render back out to loss= less QTs in 10bit YUV from AE
- do I render in video color space or sho= uld I render out in the log c profile?

I don't have an HD monitor, I have a high-end "graphics" = monitor (the eizo CG222, extremely flat response, color accurate, 99%+ of a= dobe RGB) but to get an accurate final preview I may throw it onto my HDTV = (not ideal, I know, but at least should give me an idea what I'm lookin= g at, right?)

Any other tips / gotchas would be greatly appreciated.
-TG


On Sun, Nov 25, 2012 at 10:53 AM, Jim Curt= is <jpcurtis@me.com> wrote:
You can = tell if it's 422 or 4444 by looking at the clip info in the Ae Project = pane, or by using Get Info in QT Player.

The Alexa footage I've worked with (just three projects,= so I'm no expert), the camera was connected to a cinedeck via 2 BNC ca= bles, and the native footage was ProRes4444+, or IOW, no transcoding was do= ne or necessary. =A0

If it was recorded to ArriRaw and transcoded with setti= ngs "baked," you have been robbed of the post-production benefits= of recording in RAW.


On Nov 25, 2012, at 9:40 AM, Teddy Gage wrote:

OK so j. Penzer said the arri is using= log c color space. This is the answer I was looking for. Here's my con= cern. I am ingesting prores transcodes, not the original camera files. The = histogram for this footage in 32bpc is compressed on both sides and very cl= ipped in the middle
a) I am concerned the editor didn't do the transcodes properly. I'm= not even sure whether they were converted to 8 bit 4:2:2 or 10bit 4:4:4. I= am, unfortunately, one of the more tech savvy people on production. Is the= re any way to figure this out?

B) how should I handle final =A0outputs? Should I use color = space conversion back to log c on export so it's consistent in fcp? Doe= s fcp do this conversion automatically?=A0

Thanks!<= /span>





--
Animator & Editor
www.teddygag= e.com
Brooklyn




--
Animator &am= p; Editor
www.teddygage.c= om
Brooklyn

--e89a8f22bd89e5921a04cf55c349--