HD For Indies

Hi Mike,

This is indeed a huge issue. It's not so much an AE issue as a Quicktime one, although one could consider it to be a bug in the interoperability of AE and Premiere Pro (which I do), as the same clipping happens there as well.

I have actually written a comprehensive tutorial for my book about working around this exact problem! I provide workflows for FCP and PPro.

The problem can be mitigated by processing the clips in FCP and exporting to a lossless YUV codec such as Blackmagic. The processing wants to be a simple gain in Y, but that doesn't seem to be an option in any YUV filters, so my solution in FCP is to reduce the Opacity of the clip (over a black slug) until all the Y falls below 100 IRE. Make sure you use the high quality settings when you render.

It's a bit easier in PPro, but the scopes aren't as helpful. It's treacherous waters, and something we need to harass Apple and Adobe about fixing.

Hope that helps!
 

Stu - thanks for taking the time, I know you're a busy guy. Feel free to plug the book any time!

: )

-mike
 

Mike: dropping by to report an ongoing spat with Apple on this. From my Avid ABVB and Meridien days I've been able to export beautiful QT, but the OSX transition introduced a host of no-no QT 'features', not the least of which was the introduction of 7.5 set-up or pedestal into whatever stream is fed to QT. The first iterations of Compressor were the worst offenders. By being all things to all apps, QT is just a little too smart for its britches. Apple needs us pros to be able to tinker under the hood, calling out settings that fit our workflow requirements, rather than spitting out a 'safe' be-all media product.
 

Bill - I wholeheartedly 100% agree - "too smart for its own britches" nails it.

I'm fine with that as a default behavior, but we need some stuff available when we hit the "Options" button.

Also, as long as we're requesting features, a radio button for 601 vs 709 color space for the Apple uncompressed codecs - at present it guesses based on size of frame rendered, and in a compositing environment I could see it being entirely likely that you'd kick out too big or too small and get the wrong colorspace.

-mike
 

Yes, it's the eternal problem of YUV codecs carrying information in the 'sub-black' and 'super-white' ranges by setting the black level at 16 (out of 255 of 8-bit) and the white level at 235. This would be ok(ish) if it was consistent, and the levels remained the same when converted to RGB. This was what Media 100 used to do (wow that takes me back!) but it meant you had to be very aware of it when working in say After FX. FCP tries to make it 'easy' for you by pretending at least at a surface level that YUV and RGB levels are the same thing (though it gets more complex if you start writing your own FXScripts.) It particularly pretends that the black level is really at zero, so that eg two black areas of image composited in 'add' mode give a black result, rather than a level of 32 (ie 16 above black).

There is no easy solution. If you are exporting clips to AFX or Shake, or any non YUV aware application, the safest approach is probably to do a primary grade in FCP before exporting to make the levels 'legal'. If you do this in a 10-bit codec, you minimise quantisation caused by doing this.

Looking back at what I've just written, I've probably confused more than helped anyone who reads it. I'd be a lousy teacher. Guess I'd better stick to editing!

Nick Shaw
 

Mike, here's my take at explaining the same thing everyone else is:

After Effects works in RGB mode. So it asks Quicktime to do the YUV -> RGB conversion. Problem is, Quicktime sucks at it.

Remember FCP 1.0 & 1.1? It kept clipping the highlights on DV footage. That was because FCP was RGB-only, DV footage was YUV and Quicktime's YUV <-> RGB conversion sucked.

Then they released FCP 1.2 with YUV mode and "superwhite" option and the world cheered...

...however Apple never bothered to fix the original Quicktime YUV <-> RGB conversion suckiness.

So, either Adobe needs to bring in YUV Quicktimes as YUV and write their own YUV <-> RGB converter or else Apple just needs to get their YUV <-> RGB conversion right. Since this problem has been around for 5 years, I am not holding my breath. Until then, the workarounds mentioned above are good.

Bruce Allen
 

mike,

i had a long discussion about this on the shake list, and actually Gavin from the shake engeneering team confirmed that it's the QT YUV to RBG conversion that causes the problem.. here's a quote:

"It seems in the process of typing that, you realized one thing already: It isn't Shake. It's the YUV codecs themselves. Shake tells the codec what kind of buffer is required, and in the case of Shake (and After Effects, I believe), that buffer is 16-bit RGB (assuming a 10-bit YUV source). Then Shake has to depend on the QuickTime codec to fill that buffer with appropriate image data. Right now, the codecs are clipping the data. I don't know why this has gone unaddressed, but I can assure you it's under active discussion right now.

Meanwhile, I don't know what the best solution is. Some kind of linear dynamic-range compression in the originating app and then expansion in Shake, but you'll obviously lose a little precision. "


my problem is that with this approach (besides taking up more disk space and render time) is that it introduces chroma smoothing on compressed footage which sucks because i cant do any advanced artifact reduction anymore.. still waiting for a solution

++ chris
 

- now if i only could remember how to sepll engineering ;)
++ c
 

Here in Spain there's a company called SGO, creators of a DI solution called "Mystika". They developed a format of their own, called "Extended YUV", which I think is a RGB 16bits file. They say that format you can work in RGB without any clipping of whites over 100%.

Talk with them, anyways. They're quite open
 

1.) Exporting to QuickTime will do this truncation

as far as I explored, this is not the point.
instead:
any conversion that QT does, seems to go through RGB and this process will truncate.
so any app that needs the image from QT in a format different than the original file, will get troubles concerning super values.

Bruce's comment points into the same direction.

kudos to mikes comment about the 601/709 problem.
we need either a FCP-plugin (FXscript function) to do the conversion by ourself, or better: an option to define the correct colorspace within the source setting of a clip.

today I had to export stills from a HD sequence - guess what happend : QT didnt respect the 709 sequence color space, all resulting images are looking too dark and too red.

Kurt Hennrich
 

Hmm, this is all worse than I thought. I've run into a few issues regarding this myself.

Quicktime 7, was the first major QT update in a long time and it was the first real dive into OS X specific updates to the source. Since this is a long-standing complaint it does look like it's going to be around for a long time, but maybe now that they've done the QT 7 tweaks Apple will do more with Quicktime going forward (other than supporting iTunes updates). Supposedly QT 7 still contains a lot of crusty code that is pre OS X, which could include the YUV to RGB.

It seems like we have more and more codecs to deal with, therefore more conversion issues that can come up, so if I was a QT engineer I'd clean up all the legacy conversion code since so I could build off that.

Mike has mentioned mixing different codecs on the same timeline as a shortcoming of FCP, so if they were working on making that happen I'd think they might be looking at updating some of this. We can hope.
 

I noticed that white-clipping problem a while ago whenever I'd export a clip to be worked on in After Effects. I simply attributed it to a step or setting I'd missed along the way.

To get past this export problem I'm using Automatic Duck and having AE reference the original media file, rather than exporting a file out of FCP.
 

dean,

unfortunately this will *not* solve your problems (at least not the ones i am bugged about) as upon reading the original YUV video files (such as DV, DVCPRO, uncompressed 4:2:2 etc) after effects will have to translate them to RGB files, and since AE will QT handle this conversion you end up with clipped data before AE is even able to display it.

so far the only way to do this is by compressing the levels in a native YUV app (such as FCP) which brings me to another issue: why the hell does FCP have no proper levels color correction tool (with histogram and gamma while we're at it).

love a lot of things about QT and final cut, but these two thing i cannot tolarate (well, actually i have to as i cant stand avid, which does this properly, but at least i can bitch about it ;)
++ chris
 

Well, after reading this post, just for fun, I hit Software Update. Lo and behold, here were Final Cut Pro 5.1.2, Cinema Tools 3.1.2 and Pro Apps Update! I went ahead and installed them. Living dangerously!
 

Troubling indeed... I recently started creating DVDs to submit to fests for my animated feature... I exported a QT from FCP and then imported it and made a quick DVD in iDVD... not only did it clip the whites it also seemed to shift the gamma making everything about 2 stops brighter... So I guess I got a double whammy of crappy RGB--YUV and Mpeg2 encoding...Whatever the case it made all my hard work look like a mess...I hope this gets resolved soon... but I'm gonna buy Stu's book in the meantime...Thanks for posting this news Mike!
 

Kurt Henrich emailed me some further useful info:

after reading all the comments, I would like to add that some of you should not think that a better QT YUV>RGB conversation might solve all of your problems observed. here are some points to consider:

1) in FCP there are two ways to export a movie:
- FCP movie, which will produce a 1:1 stream of the sequence data/format if the options are untouched
- QT conversion, primarily for exporting of final(!) video to another format
FCPmovie is the prefered method for intermediate works in other apps if the app involved can handle your YUV-sequence format native.

2) when YUV>RGB conversion is envolved, there are another two options:
- RGB255: will map YUV/Black to RGB:0/0/0 and YUV/White to RGB:255/255/255
- RGB235: will map YUV/Black to RGB:16/16/16 and YUV/White to RGB:235/235/235
RGB235 is good for video work, because it can preserve super whites and super blacks outside the 0-100% range using RGB:0-15 and RGB:236-255 for these values, BUT: viewing such an RGB235 image within a graphic app like photshop leads to a poor looking image: blacks are dark grey and whites are dimmed. also: an image produced in photoshop with RGB:0-255 values imported into FCP should not produce super whites and super blacks as default. QT tries to solve these problems behind the scenes without any option for the user. as a result, with QT automatically converting YUV>RGB255, the resulting image/video will look correct in graphic levels but all super values are lost.
my tip: for export to RGB apps, try using sheer video codec. it does handle conversion to different color spaces and gives the user options which color space to use.

3) a YUV>RGB conversation of a final (!!) movie is not that a bad idea as you might think,
as shane ross in his initial blog has explored:
in fact, a YUV>RGB>YUV conversion is the only 'workaround' I have found to produce bulletproof broadcast levels within FCP because of FCP's lack of other reliable methods (incl. broadcastsafe-filter). So I use my own mastering plugin to be on the safe side (see www.1z1.at/plugins/) which is based on the pros of colorspace conversion.
to explain the issue of 'broadcast safe', I will try to point out some aspects and why we have to deal with them.
for this, it helps to understand how whites & blacks are built in RGB versus YUV. for simplification I will use RGB255 as graphics format and YC (luma&chroma) as video format:
when working with an RGB image, true black is RGB:0/0/0 and true white is RGB:255/255/255.
when working in video, black is 0% luma, white is 100% luma.
but what about the chroma component of the video?
does 0% luma / 100% luma also mean that chroma is 0% ?
NO! but it should, because per definition pure black&white is without color!
but when working in YUV within FCP it is easy to produce highly saturated blacks, just by crashing the blacks without affecting the original chroma level. the same is true with super whites (100+%) that are lowered to fall within the 100% range: these areas of the image are recorded with some chroma level so one ends up with saturated white.
a good conversation from YUV to RGB and back to YUV can solve such problems:
0% luma with any value of chroma will result in RGB:0/0/0, and back to video, both luma & chroma will be 0% which means 'legal'.

BUT: this positiv side effect of the YUV>RGB conversation only make sense as the very last step in processing.
so my rules in FCP are:
- for YUV processing (broadcast) stay within FCP whenever possible, or convert to 4:4:4 as soon as possible for film work mastered with HDCAM-SR
- for export/reimport to RGB processing apps, I use sheer video codec to handle proper colorspace conversion
- during color correction with the 3way-CC, bringing any superwhites that should be visible into the 100% range
- as a final step for broadcast/dvd I am 'legalizing' , as the last step before playout to digiBeta/hdcam or dvd-encoding

during legalizing, all remaining superwhites and superblacks are truncated AND with the help of YUV>RGB>YUV black/white saturations are no more illegal. THIS IS ALL GOOD even if some very subtle areas of an image may alter a bit, because that is just the result of the respect of video specifications. if I think that something alters too much, I have to correct the shot by going back to the underlying 3way-CC to adjust for better results (which rarely is the case).

concerning the FCP scopes, which were the starting point to this and/or shane's blog:
the scopes in FCP are by no way useful to produce a video within the videospecs for shure. they can help, but they should not make you feel save, for several reasons:
there is no gamut measuring, which means no control if your colors are within the allowed color space(s)..... spaces: because digital, analog YUV, analog RGB, and last not least the analog composite signal, which is kind of mother of all the others, all these formats have there own possibilities/restrictions to reproduce colors. composite video is still heavy in use and every video may go through such a cable sometimes (transmission, vhs recorder, etc). the vector scope is not able to show a videos gamut (!) and dont have a clue about different color spaces.
an approximation is possible with the FCP scope by monitoring that luma and color together dont exceed 100% which should be equal to 0.7V of the analog composite signal (I only remember that in PAL, maybe equal in NTSC).
next: what ends up on tape most time is still a video signal, in most cases through SDI. so measuring levels should allways be AFTER the video card on the SDI/HDSDI signal, and thats why hardware is build/bought for this purpose, even expensive one. and there are other hardware-plus: better display resolution, and BEEP when illegal values are detected (no need to allways look on the meter, concentrate on the image).

hopefully this all is not too wrong and even helpful for someone.
all the best,
kurt hennrich
 

[quote]"2) when YUV>RGB conversion is envolved, there are another two options:
- RGB255: will map YUV/Black to RGB:0/0/0 and YUV/White to RGB:255/255/255
- RGB235: will map YUV/Black to RGB:16/16/16 and YUV/White to RGB:235/235/235
[...]
my tip: for export to RGB apps, try using sheer video codec. it does handle conversion to different color spaces and gives the user options which color space to use."[/quote]

the RGB235 option is exactly what i'm looking for, however, quicktime doesnt offer this option and even using the sheer codec i get clipped super whites, no matter which option i choose... how did you do it ? ;)
++ chris ++
 

情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,情趣,情趣,情趣,情趣,按摩棒,跳蛋,充氣娃娃,情境坊歡愉用品,情趣用品,情人節禮物,情惑用品性易購,A片,視訊聊天室,視訊,視訊聊天,視訊交友網,免費視訊聊天,聊天室,UT聊天室,免費視訊,視訊交友,免費視訊聊天室

免費A片,AV女優,美女視訊,情色交友,免費AV,色情網站,辣妹視訊,美女交友,色情影片,成人影片,成人網站,A片,H漫,18成人,成人圖片,成人漫畫,情色網,日本A片,免費A片下載,性愛

A片,色情,成人,做愛,情色文學,A片下載,色情遊戲,色情影片,色情聊天室,情色電影,免費視訊,免費視訊聊天,免費視訊聊天室,一葉情貼圖片區,情色,情色視訊,免費成人影片,視訊交友,視訊聊天,視訊聊天室,言情小說,愛情小說,AIO,AV片,A漫,av dvd,聊天室,自拍,情色論壇,視訊美女,AV成人網,色情A片,SEX,成人圖片區

情趣用品,A片,免費A片,AV女優,美女視訊,情色交友,色情網站,免費AV,辣妹視訊,美女交友,色情影片,成人網站,H漫,18成人,成人圖片,成人漫畫,成人影片,情色網


情趣用品,A片,免費A片,日本A片,A片下載,線上A片,成人電影,嘟嘟成人網,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,微風成人區,成人文章,成人影城,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,臺灣情色網,色情,情色電影,色情遊戲,嘟嘟情人色網,麗的色遊戲,情色論壇,色情網站,一葉情貼圖片區,做愛,性愛,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,美女交友,做愛影片

av,情趣用品,a片,成人電影,微風成人,嘟嘟成人網,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,成人文章,成人影城,愛情公寓,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,aio,av女優,AV,免費A片,日本a片,美女視訊,辣妹視訊,聊天室,美女交友,成人光碟

情趣用品.A片,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,色情遊戲,色情網站,聊天室,ut聊天室,豆豆聊天室,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,免費A片,日本a片,a片下載,線上a片,av女優,av,成人電影,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,成人文章,成人影城,成人網站,自拍,尋夢園聊天室
 

a片,成人網站,美女交友,美女視訊,a片,成人網站,美女交友,美女視訊,a片,成人網站,美女交友,美女視訊,聊天室,美女視訊,聊天室,美女視訊



成人網站,成人影片,av女優,h漫,成人網站,成人電影,a片,色情,成人影片,色情,成人電影,色情,h漫,成人影片,成人電影,免費A片,色情,成人電影,成人影片,免費A片,色情,成人網站,情趣用品,免費A片,成人網站,色情,a片,成人影片,情色,免費A片,微風成人,情色,成人影片,微風成人,av女優



成人網站,色情網站,av女優,色情,成人網站,成人影片,成人電影,av女優,a片,成人網站,成人網站,成人網站,成人影片,av女優
色情,h漫,sex,情色,a片,成人網站,成人影片,av女優,色情
h漫,sex,情色,辣妹視訊,080視訊聊天室,美女交友
情色視訊,哈啦聊天室,ut聊天室,聊天室



美女交友,美女交友,美女交友,視訊辣妹,視訊辣妹,視訊辣妹,視訊聊天室,視訊聊天室,視訊聊天室,成人交友,成人交友,成人交友,視訊美女,視訊美女,視訊美女,聊天室,聊天室,聊天室



成人網站,av女優,成人網站,a片,成人影片,成人電影,h漫,成人電影,色情,成人影片,色情,免費A片,成人影片,免費A片,情色,微風成人
美女交友,美女交友,視訊辣妹,視訊辣妹,視訊聊天室,視訊聊天室,成人交友,成人交友,視訊美女,視訊美女,聊天室,聊天室
美女交友,美女交友,美女交友,視訊辣妹,視訊辣妹,視訊辣妹,視訊聊天室,視訊聊天室,視訊聊天室,成人交友,成人交友,成人交友,視訊美女,視訊美女,視訊美女,聊天室,聊天室,聊天室



a片,成人網站,av女優,h漫,成人影片,免費a片,情趣用品,色情,微風成人,情色,sex,成人電影,聊天室,美女交友,辣妹視訊,視訊聊天室,成人交友,美女視訊,聊天室,美女交友,辣妹視訊,視訊聊天室,成人交友,美女視訊,成人網站,情色,情趣用品,色情,sex,免費a片,h漫,av女優,成人影片,a片,微風成人,成人電影聊天室,美女交友,辣妹視訊,視訊聊天室,成人交友,美女視訊,聊天室,美女交友,辣妹視訊,視訊聊天室,成人交友,美女視訊,成人電影,成人網站,情色,情趣用品,色情,sex,免費a片,h漫,av女優,成人影片,a片,微風成人,聊天室,美女交友,辣妹視訊,視訊聊天室,成人交友,美女視訊,聊天室,美女交友,辣妹視訊,視訊聊天室,成人交友,美女視訊



a片,a片,a片,a片,a片,av女優,av女優,av女優,av女優,成人網站,成人網站,成人網站,成人網站,h漫,h漫,h漫,h漫,成人網站,成人網站,成人網站,成人網站,免費A片,免費A片,免費A片,免費A片,成人影片,成人影片,成人影片,成人影片,成人電影,成人電影,成人電影,成人電影,免費A片,免費A片,免費A片,免費A片,成人電影,成人電影,成人電影,成人電影,色情,色情,色情,色情,成人影片,成人影片,成人影片,成人影片,成人影片,微風成人,微風成人,微風成人,微風成人,色情,色情,色情,色情,情趣用品,情趣用品,情趣用品,色情,色情,色情,色情,成人影片,成人影片,成人影片,成人影片,情色,情色,情色,情色,打卡鐘,跳蛋,持久液,色情網站,黃金回收,借錢,植牙,牙醫,成人網站,成人影片,av女優,色情,h漫,情色,sex,黃金價格,黃金,黃金買賣,黃金存摺,鑽石價格,鑽石回收,鑽石買賣,當舖,辣妹視訊,080視訊聊天室,美女交友,情色視訊,哈啦聊天室,ut聊天室,聊天室,打卡鐘,火鍋吃到飽,創業加盟,賺錢,吃到飽麻辣鍋
 

酒店經紀人,
菲梵酒店經紀,
酒店經紀,
禮服酒店上班,
酒店小姐兼職,
便服酒店經紀,
酒店打工經紀,
制服酒店工作,
專業酒店經紀,
合法酒店經紀,
酒店暑假打工,
酒店寒假打工,
酒店經紀人,
菲梵酒店經紀,
酒店經紀,
禮服酒店上班,
酒店經紀人,
菲梵酒店經紀,
酒店經紀,
禮服酒店上班,
酒店小姐兼職,
便服酒店工作,
酒店打工經紀,
制服酒店經紀,
專業酒店經紀,
合法酒店經紀,
酒店暑假打工,
酒店寒假打工,
酒店經紀人,
菲梵酒店經紀,
酒店經紀,
禮服酒店上班,
酒店小姐兼職,
便服酒店工作,
酒店打工經紀,
制服酒店經紀,
酒店經紀,
菲
梵,1