Converting FS700 AVCHD files for OS X Premiere CS5?

Gene Sung

Veteran
I'm on a Mac and using Premiere CS5.

I read this article on EOSHD which states that OS X clips the Blacks and Highlights if you edit the AVCHD footage natively when using Premiere CS5. From the pictures in the article, it certainly looks that way.

http://www.eoshd.com/content/8076/how-mac-osx-still-screws-your-gh2-fs100-nex-footage-a-must-read

The article suggested using 5DtoRGB which transcodes the AVCHD footage to ProRes and keeps the black and highlights from clipping. I have several questions

1) Mac users, do you guys transcode your footage (a serious pain in the neck and something I wish to avoid), and if you edit natively, have you noticed this dynamic range loss issue? Is there a work around or some type of box in Premiere to check that will bypass the clipping problem?

2) If you do transcode, which Mac based application do you use? Is 5DtoRGB the best app. for this?

3) Finally, which flavor of ProRes do you guys prefer? 422 HQ, 422 or 422 Lite?

Edit: I just checked myself and there is a very noticeable gamma shift when comparing the 5DtoRGB transcoded ProRes footage to what is natively imported into Premiere (same clip, side by side). I'm hoping someone knows of a way to work with the AVCHD footage natively and still get the proper dynamic range, without having to transcode footage (Sucks big time).
 
Last edited:
Well, I have to dock the guy 9.9 credibility points for this statement:

Overall the dynamic range of the camera is reduced 1-2 stops by OSX.
​


That's just wrong, OSX doesn't do anything with your footage.

I have seen many people comment that if you shoot with superblack / superwhite, Premiere will clip IF you don't take care to grade properly and pull the tonal range into legal values. I haven't seen anything about Premiere clipping in a way that can't be fixed.

In other words, if you shoot with 109% whites, it's your responsibility to pull those down to 100% before exporting.
 
Yes, you do have to take what EOSHD says with a grain of salt since he is very emotional. But in this case, he is 100% correct. Look at the pic I attached. The Left screen shot is imported Natively into Premiere CS5, while the right screen shot has been converted to ProRes 422 LT using 5DtoRGB. There is a very noticeable shift in the Gamma. The image on the left is much more crushed.

Sigh.... I wish I could avoid Transcoding.

GammaShift1.jpgY
 
Must be an OSX thing? Premiere CS5-6 for windows has usually been the one NLE I usually find I can trust to make my footage look right, broadcast safe or not. FCP and quicktime on OSX usually tends to destroy footage from just about any camera if its not handled right.

I always just try to minimize issues in post by shooting broadcast safe.
 
Gene: Sure, but in the non-transcoded case, is the extra range actually lost? Or can it be pulled back in by correcting?

Since 5dtoRGB can get it back, the information is obviously in the file, and I would be VERY surprised if Premiere genuinely clipped it on the IMPORT side. It will certainly clip on EXPORT if you leave the whites above the 100% line.
 
@ seven.b. What is Procamp? If it's a filter, probably won't do anything. I'm hoping there is a check box somewhere to interpret the footage differently. I think that's the only way. I'll check later, but Premiere does have different settings for interpreting color. Maybe that will do something.

I've also noticed that playback in Premiere when using native AVCHD introduces a lot of artifacting that isn not present when the footage is converted to ProRes. I guess OS X just doesn't like AVCHD, probably because it's not an Apple product, so they just don't care to make it work well.
 
@ seven.b. What is Procamp? If it's a filter, probably won't do anything. I'm hoping there is a check box somewhere to interpret the footage differently. I think that's the only way. I'll check later, but Premiere does have different settings for interpreting color. Maybe that will do something.

I've also noticed that playback in Premiere when using native AVCHD introduces a lot of artifacting that isn not present when the footage is converted to ProRes. I guess OS X just doesn't like AVCHD, probably because it's not an Apple product, so they just don't care to make it work well.

I haven't tried it, as I don't have my FS700 just yet.. but read this: http://mattdavis.wordpress.com/2012/07/12/dealing-with-109-whites-the-footage-that-goes-to-11/
 
Does this only occur while editing on a mac? How about pc with cs5 or cs6?

Nope it's not a Mac thing, it'll happen on any system operated by someone who hasn't got a clue about broadcast legal levels.

OS X and the Mac have been wrongly accused of gamma shifts for years. It goes back to Apple's choice of 1.8 gamma for their monitors and that FCP was hard coded to work with a gamma of 1.8 even though most of us used monitors with a gamma between 2.2 and 2.4. So when viewing files with FCP on a 2.2 gamma monitor the images were incorrect although the VAST majority of people assumed it was correct.

These people would also then play files back in QT or another video player and get a gamma shift because those players supported a correct gamma for the display device. There was always a shift going from FCP to Color for grading then another shift when you went from Color back to FCP. Color was correctly displaying the images but FCP was not, to display the correct image in FCP you had to set your monitor to 1.8 gamma.

I can go on and on about colour management as it's a pet subject but Apple has made it super simple as of Snow Leopard by using Colour Sync. As long as you calibrate your monitors correctly OS X will display the correct image. FCPX is a joy to use with a Dreamcolor.

Of course it is still possible to screw up colour management if you don't have a clue and if your software doesn't support colour sync you still have to manually keep abreast of things.

People are quick to blame their own incompetence on software or OSes. If you train yourself up in colour theory, colour management and broadcast legality you will be able to produce better, more consistent results and get more from your camera than those who choose to ignore it (and write blogs instead).

You can find that some codecs require a certain input range and give unwanted clips and shifts, again it's up to the diligence of the person producing the work to know these things. I have a test scene that contains colour bars and standard scenes of broadcast illegal and legal files that I put through the system when testing a new workflow so there aren't any surprises at the end.
 
Premiere CS 5.5 on PC never clips superwhites! You can´t see them in the preview because the preview only shows broadcast legal levels, but on the waveform it´s all there up to 109 and can be pulled back to 100.
 
So here's what I'm finding....
  • The PP "framework" doesn't clip superwhites.
  • But some of the effects do.

The problem with PP effects is that they're a pretty diverse eollection of mini-programs written at different times by different people, and to different standards. Adobe have been very bad at bringing them up to current standards and making them consistent. So you more or less need to figure out each effect's limitations individually.

A particular example is in the handling of superwhites -- some effects do, in fact, run a strimmer (or "weed whacker") right along the 100% line BEFORE they do anything else -- so even if you use the effect itself to pull the whites down, it will STILL clip them. Other effects do a far better job.

Here's a test I've just done in PP CS6:
  1. Load up a clip which has whites just nicely going up to 109 IRE. (Obviously, if I export this as is, it will be clipped, since the output MP4 file can only take whites up to 100. So the whites need to be pulled down.)
  2. Switch the monitor to YC waveform mode (chroma off) to see what's happening.
  3. To bring them down to 100 IRE, I add the "Luma Corrector" effect.
  4. IMMEDIATELY, the whites are clipped at 100 IRE -- the smoothly feathered peaks are now hard lines on the YC graph.
  5. Set "Pedestal" to -0.1, to bring the whole graph down by 10 IRE.
  6. Now my whites are clipped at 90 IRE! Yuck!

So, Luma Corrector sucks. Now try an alternative:
  1. Kill Luma Corrector.
  2. Add ProcAmp.
  3. Note that with ProcAmp added, but no settings tweaked yet, I still have my whites feathering off at 109 IRE.
  4. Set "Brightness" to -10, to bring the whole graph down by 10 IRE.
  5. Now my whites are nicely feathered off at 100 IRE -- success!
  6. If my blacks are below 0, I'll use "Contrast" to squish my dynamic range.

So choose your effects with care! It sucks that Adobe don't go through their effects and bring them up to snuff -- and chuck out some of the trashier obsolete ones -- but there you go.

Hope this helps.
 
Last edited:
On further investigation, it looks like:

  • Luma Corrector, Brightness and Contrast, Broadcast Colors, Gamma Correction and Levels all clip super-whites.
  • ProcAmp, Luma Curve, and RGB Curves (master) handle super-whites, but introduce "banding" in the YC graph -- looks like they're rounding the luma levels rather crudely. I don't know if that has any real visible effect.
  • Fast Color Corrector and Three-Way Color Corrector (using the Input Levels and Output Levels controls) do it nicely -- no clipping, no banding.
 
Great report. I generally use Fast Colour Corrector or Magic Bullet Curves for level adjustment. Not sure if MB is clipping just by applying an effect.


On further investigation, it looks like:

  • Luma Corrector, Brightness and Contrast, Broadcast Colors, Gamma Correction and Levels all clip super-whites.
  • ProcAmp, Luma Curve, and RGB Curves (master) handle super-whites, but introduce "banding" in the YC graph -- looks like they're rounding the luma levels rather crudely. I don't know if that has any real visible effect.
  • Fast Color Corrector and Three-Way Color Corrector (using the Input Levels and Output Levels controls) do it nicely -- no clipping, no banding.
 
Great report. I generally use Fast Colour Corrector or Magic Bullet Curves for level adjustment. Not sure if MB is clipping just by applying an effect.

I guess you'd have to check it. It looks like an effect can do the right thing, it's all down to how it was coded.
 
Back
Top