First off, thank you for looking into this. Been doing some comparisons myself in FCPx the last couple of days. Mostly in ProRes 422. 5DtoRGB definitely cleans up/smooths out the reds in comparison to the MTS file and even the FCPx render. Really apparent if one pushes the color saturation and blows up the image. In most practical cases it seems to be a minor but real improvement over FCPx.

One thing I am curious about is the issue of using full range luminance vs. broadcast. I did a simple experiment in FCPx. Two different shots. One a contrasty outdoor scene. The other a low contrast interior. Imported several versions of both shots (MTS and various ProRes 422...FCPx, 5DtoRGB Broadcast (at gammas 1.0, 1.1, 1.2, and 1.4), then 5DtoRGB at Full luminance.

I then sequenced them in the timeline just as I listed them above. Opened the Luma video scope and skimmed through the shots. In both shots, the first three (MTS, FCPx, and 5DtoRGB Broadcast at default gamma of 1.0) all looked the same and had virtually identical readings on the luma chart. Moving through the shots as the gamma adjustment goes from 1.1 to 1.4, the top end limit of the luma remains pretty much the same while the shadows at the bottom are lifted progressively with each increase in gamma. Visually, shadows open up and more detail in those areas is obviously revealed. Then finally, the 5DtoRGB at Full luminance shot shows a much flatter looking image, with luminance values obviously in a significantly more narrow range. Especially in the lower contrast scene where it looks totally washed out.

So, broadcast seems to be what the camera is spitting out (luminance in MTS=FCPx=5DtoRGB at Broadcast). Why would it be advantageous to have those luma values remapped to a narrower range during the encode only to be remapped again with another adjustment in a color correct to add contrast? In the test that was done, Full does retain more detail than Broadcast. But maybe that's because of the pretty severe S curve added to the footage. The curve squashed the top and bottom of the luminance range where Broadcast had quite a bit of information and Full had very little.

What would happen if you did a pretty straightforward grade of both so they looked the same by creating a well-balanced scene with good balance and detail across the whole luminance range? This is where most of the colorists I've worked with start. Seems like that would be the fair comparison.

So, I started doing just that. I stacked different versions of the clips and color corrected them to what I consider a good, balanced scene. It's amazing how with just one or two exposure adjustments in FCPx, you can bring all the different encodes very close to one another. The question then becomes, where is it best to have the math done…in the original encode or in the color correct? Will look more closely at comparing this and other footage over the next couple of days to reach a more definitive conclusion, but, intuitively it seems like the less math that's done on the footage, the better.

Does anyone have a batch script that will work with the 1.5.8 Lite (Mac) version? The one I tried from earlier in this thread doesn't work with it.

Thanks

@Swiss_Boy that is why we have things called "change orders" with every client I have as a freelancer, they sign a contract that says at the end of the edit process they will "sign off" literally on the edit, usually by email confirmation form the project lead, before moving on. If for any reason they want to go back and change something they have to pay a "change fee" which is steep. But it's also the secret to making money in this biz, and not letting clients drive you crazy. Because if you don't you will eventually grow to hate your clients because clients usually have no fucking clue what they want, and lack the skills to communicate it even when they do know.

There are many ways around having to start over. One is to go back, make the changes, re-export xml, and only grade the changes that were made. Take both master timeline and place them in one comp, and do a quick 3 point edit. I'll try to do a tutorial on this.

@Swiss_Boy you are using PP? Then when I say xml, just think. "import PP project". XML is for the rest of us NOT using PP.

And with FCPX you need to get xto7 and 7tox to use the AE XML workflow. export fcpxml > import to FCP7 using xto7 > then export from FCP7 to XML > import into AE using Automatic Duck.

But with FCP7 and Vegas and automatic duck (a free program) you can absolutely import an XML or AAF into AE.

@shian yes i'm using premiere pro but i will probably switch to fcpx cause i really start to like the timeline,sync and multicam.

Yep I've said it before and I'll say it again. I would love to work in native MTS in the Adobe apps but there's just no comparison yet.

I don't know whether discussion about 5DToRGB is mostly Mac-based or there are some improvements on PCs as well? Namely, make the following script in AviSynth:

DirectShowSource("Name_of_your_video.MTS")

Then import it into VirtualDub. The red problems dissapear similarly as when using 5DToRGB. Note that you can adjust gamma and brightness range in AviSynth or VirtualDub if needed.

Please, DON'T import original MTS file directly into VirtualDub by using "DirectShow input Driver" under "Files of type" load option. You'll get back red problems.

So, is there any difference concerning aliasing/red problems between 5DToRGB and AviSynth - VirtualDub approaches?

By the way, something strange happens as well... The original clip and Avisynth-VirtualDub approach result in the same number of frames. On the other side, by using 5DToRGB approach, number of frames (reported in VirtualDub) is increased.

@Duartix, could you left somewhere the original MTS footage and HuffYUV created by 5DToRGB for testing?

@duartix

This isn't just a RED channel issue. It is massive and it's all over!!! Loading straight MTS files into AE is an aliasing holocaust.

Looks like AE is only displaying a single field in the case of the MTS file and both fields in the case of the MOV file created by 5DtoRGB. Since it’s a 29.97 fps clip, I assume the GH2 was in the HBR mode, so the resulting file is interlaced to begin with.

In any event, I’m not having your aliasing problem when I open your MTS file directly in QuickTime Player. I get something very close to your second snapshot (well, minus 5DtoRGB’s chroma blurring or whatever it does, naturally).

Can you force AE treat a clip as progressive?

Here is frame no. 40 of the video imported into VirtualDub via Avisynth script:

DirectShowSource("00000.MTS")

It seems quite OK. Also "reds" are more than OK.

@bwhitz, can you upload your original mts clip as well in order to test it?

I made an experiment with one of my clips with GH1 taken as 50i (interlaced wrapper). I imported the clip into Sony Vegas MS and marked the clip as progressive. Then put it in the timeline and exported it by using loseless Lagarith codec. The results from sony are shown by the first two pictures (the first picture is there by mistake) denoted by SonyMSHDP.

I compared the results by importing the MTS clip directly into VirtualDub (by using "DirectShow input Driver" under "Files of type" load option) [the third picture denoted by "MTS"], by using 5DToRGB [the fourth picture, denoted by "5DToRGB"], and by importing AVS script into VirtualDub (similar script as one above) [the last picture, denoted by "AVS"]. The results are below (cropped part of the entire picture and resized 400% by Laczos filter). It can be seen that AVS and 5DToRGB route do not suffer from "chroma upsampling error"

http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html

Both AVS and 5DToRGB results seem similar (5DToRGB is more flat, but it might be made by AVS route as well) except that AVS footage is slightly sharper. Since sharpness is very important for me (3D), I'll probably keep AVS route. If anybody knows some other advantages of 5DToRGB over AVS route, let me know.

I'm not an expert in this field but I don't think so... Artifacts are artifacts.

EDIT: I've just noted that Duartix's pictures are smaler (1725x882px). That's maybe the reason why artifats looks less visible.

EDIT n2: Ok, I got what you mean by "flatter" (less contrasty, isn't it?). You may be right...

Interesting - having seen the difference in your files when imported into Sony Vegas, and then gone back and dealt with the interlace issue, I then found the same thing, no difference.

Just to check further though, I played around in both Sony Vegas and in AE with one of my own MTS files, a very detailed clip with highly saturated graphic colours,comparing it with the same clip imported via 5DtoRGB and I could detect no difference between the native MTS and the 5DtoRGB import in either Vegas or AE.

Although my copy of 5DtoRGB (windows x64) will only convert one file and then creates huge .mov files with no video (only audio). Don't know what's happening there but that's a side issue. I've probably got a corrupt install, or it doesn't like the files Cake produces, or something.

But when I get it to work for me, 5DtoRGB is useful for certain applications that don't work natively with .mts, and it's pretty quick to convert. I'm thinking here of the original verion of Speedgrade NX, which won't look at mts files hence they need to be converted first to import into that particular software.