Return-Path: Received: from smtpout07.prod.mesa1.secureserver.net ([64.202.165.230] verified) by media-motion.tv (CommuniGate Pro SMTP 4.2.10) with SMTP id 4569335 for AE-List@media-motion.tv; Tue, 20 Dec 2011 22:51:38 +0100 Received: (qmail 16995 invoked from network); 20 Dec 2011 21:57:46 -0000 Received: from unknown (76.206.254.56) by smtpout07.prod.mesa1.secureserver.net (64.202.165.230) with ESMTP; 20 Dec 2011 21:57:41 -0000 Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: References: Content-Type: multipart/alternative; boundary=Apple-Mail-7-366191852 Message-Id: <699733E7-1883-42D7-8DEA-AA6EB099D5EC@influxx.com> From: adam mercado Subject: Re: [AE] [OT] H264 Gamma Shift Date: Tue, 20 Dec 2011 13:57:39 -0800 To: "After Effects Mail List" X-Mailer: Apple Mail (2.753.1) --Apple-Mail-7-366191852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Thanks Chris. A really informative read. That article was written in =20 2008 I noticed, yet here we are on the doorstep of 2012, four years =20 later and we are still having these problems. Thats atrocious. I have been aware of the QT -> FCP gamma shift problem, I asked about =20= it in this list last year. Not tried x264 yet though, I will now. My =20 issue today though is the blacks getting crushed, not fading, on =20 encode to H264 via Telestream Episode. I'll contact them to see if =20 they have any idea about gamma tags being used. All in all highly =20 frustrating for professionals trying to deliver good looking work to =20 their clients after all the hard work, the creative and keyframing, =20 is done. Anyone done any tests with Adobe Media Converter and the Main Concept =20= codec? I will give that a run for comparison too cheers for all the advice and discussion Adam Mercado Influxx Media Production Fullerton, CA Moving Images. For Business 714=B0928=B09896 http://www.influxx.com http://www.twitter.com/influxx http://www.linkedin.com/in/influxx http://influxx.tumblr.com/archive http://www.flickr.com/photos/influxx On Dec 20, 2011, at 12:17 PM, Chris Meyer wrote: > That doens't always work, unfortunately. > > The secret is to use x264, not h.264 (available from http://=20 > www003.upp.so-net.ne.jp/mycometg3/ - scroll down a few entries). > > For more: http://provideocoalition.com/index.php/cmg_blogs/story/=20 > brightness_issues_with_h264_quicktime_movies/ > > - Chris > > > On Dec 20, 2011, at 12:33 PM, David Torno wrote: > >> I have found that H.264 outputs from QuickTime are too bright and =20 >> the fix I use is to open the H.264 back in QuickTime, Bring up the =20= >> Properties window (cmd+j), select the Video Track, select the =20 >> Visual Settings tab, then change the Transparency dropdown to =20 >> Composition. Save file. >> >> David Torno >> Visual Effects Artist & Supervisor >> http://www.ghosttownmedia.com >> O: 213.739.2290 >> C: 818.391.6060 >> --------------------- >> http://www.sydefxink.com >> http://aeioweyou.blogspot.com >> http://mactex.blogspot.com >> >> "The most useless day is that in which we do not laugh" >> -Charles Field >> >> On Dec 20, 2011, at 11:28 AM, adam mercado wrote: >> >>> I'm having a hell of a time trying to get a render off to my =20 >>> client that resembles to color shown in AE. Workflow is this: >>> >>> PSDs imported and animated to 16bit comps (the artwork is a =20 >>> concrete texture with a black vignette over, lots of greys, =20 >>> blacks blending into each other) >>> Rendered to 16bit PhotoJPEG .MOVs (the masters look fine, no =20 >>> gamma shift at this stage but at 750MB too large to upload to =20 >>> client) >>> Encoded in Episode to H264 (blacks are crushed, all detail is =20 >>> lost, gamma is generally shifted darker) >>> Encoded in QuickTime to H264 (gamma is shifted lighter and reds =20 >>> are shifted towards blue) >>> >>> I've tried playing with various options and settings in Episode, =20 >>> but any gamma compensated reverse shift I apply brightens the =20 >>> highlights but the blacks are still crushed. Playing with the QT =20 >>> export filters are really hit or miss with little effect. >>> >>> Anyone come across this before and found a workaround? Or a =20 >>> better encoder. I had an old version of compressor at one time =20 >>> but removed it as it was so unstable and buggy and required a =20 >>> reinstall every two weeks. >>> >>> At this stage I've resorted to trying to introduce the reverse =20 >>> gamma shift as an adjustment layer in AE prior to final render to =20= >>> compensate for the shift in Episode. So far I have yet to find =20 >>> the sweet spot that solves the problem >>> >>> many many thanks >>> >>> Adam Mercado >>> Influxx Media Production >>> Fullerton, CA >>> >>> Moving Images. For Business >>> 714=B0928=B09896 >>> http://www.influxx.com >>> http://www.twitter.com/influxx >>> http://www.linkedin.com/in/influxx >>> http://influxx.tumblr.com/archive >>> http://www.flickr.com/photos/influxx >>> >>> >>> >>> >>> > --Apple-Mail-7-366191852 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Thanks Chris. A really informative read. That article was written in = 2008 I noticed, yet here we are on the doorstep of 2012, four years = later and we are still having these problems. Thats = atrocious. 

I have been aware of the QT -> = FCP gamma shift problem, I asked about it in this list last year. Not = tried x264 yet though, I will now. My issue today though is the blacks = getting crushed, not fading, on encode to H264 via Telestream Episode. = I'll contact them to see if they have any idea about gamma tags being = used. All in all highly frustrating for professionals trying to deliver = good looking work to their clients after all the hard work, the creative = and keyframing, is done.

Anyone done any tests = with Adobe Media Converter and the Main Concept codec? I will give that = a run for comparison too

cheers for all the = advice and discussion



On Dec 20, 2011, at 12:17 PM, Chris Meyer = wrote:

That doens't always work, = unfortunately.

The secret is to use x264, not h.264 = (available from http://www003.upp.so-ne= t.ne.jp/mycometg3/ - scroll down a few = entries).


 - = Chris


On Dec 20, 2011, at 12:33 = PM, David Torno wrote:

I have found that H.264 outputs from QuickTime = are too bright and the fix I use is to open the H.264 back in QuickTime, = Bring up the Properties window (cmd+j), select the Video Track, select = the Visual Settings tab, then change the Transparency dropdown to = Composition. Save file.

David Torno
Visual Effects Artist = & Supervisor
http://www.ghosttownmedia.com<= /div>
O: 213.739.2290
C: = 818.391.6060
---------------------
http://aeioweyou.blogspot.com<= div>http://mactex.blogspot.com

"The most useless day is that in which we do not = laugh"
-Charles Field

On Dec 20, 2011, at = 11:28 AM, adam mercado <adam@influxx.com> = wrote:

I'm = having a hell of a time trying to get a render off to my client that = resembles to color shown in AE. Workflow is = this:

PSDs imported and animated to 16bit comps (the = artwork is a concrete texture with a black vignette over, lots of greys, = blacks blending into each other)
Rendered to 16bit PhotoJPEG = .MOVs (the masters look fine, no gamma shift at this stage but at 750MB = too large to upload to client)
Encoded in Episode to H264 = (blacks are crushed, all detail is lost, gamma is generally shifted = darker)
Encoded in QuickTime to H264 (gamma is shifted lighter = and reds are shifted towards blue)

I've tried = playing with various options and settings in Episode, but any gamma = compensated reverse shift I apply brightens the highlights but the = blacks are still crushed. Playing with the QT export filters are really = hit or miss with little effect.

Anyone come = across this before and found a workaround? Or a better encoder. I had an = old version of compressor at one time but removed it as it was so = unstable and buggy and required a reinstall every two = weeks.

At this stage I've resorted to trying to = introduce the reverse gamma shift as an adjustment layer in AE prior to = final render to compensate for the shift in Episode. So far I  have = yet to find the sweet spot that solves the = problem

many many thanks

Adam = Mercado
Influxx Media Production
Fullerton, = CA

Moving = Images. For Business
714=B0928=B09896




=



= --Apple-Mail-7-366191852--