These are screenshots of the original GH2 mts file and transcoded file. There is a huge difference. So, the software does give flatter image with GH2 but not with GH3.

EDIT: I just noticed that I named the screenshots incorrectly. Files names should be reverse, but you can see the difference anyway: flatter image is the transcoded one.

Thanks. I've read many different posts all over the net so I'm a bit confused what's best. Some mention the benefits of full range other are against.

I might go with Broadcast Range, just to be safe. But, I would still like to find out why GH3 files are not giving me flat image, like GH2. For my information, at least.

Thanks again

In that thread, shian mentioned no difference with GH3 files.

@vicharris

You're not supposed to be transcoding to full range.

This is essentially not correct... the contrary… as long as you are referring to 5DtoRGB's setting called "fullrange".

In 5DtoRGB the setting "fullrange" means: "preserve the full luminance levels contained in the source file". In other words: "do not remap luminance levels".

When the source file contains fullswing levels 5DtoRGB's setting "fullrange" will output a file containing fullswing levels. When the source file contains studioswing levels 5DtoRGB's setting "fullswing" will do exactly the same - it preserves the full range of luminance levels contained in the source file. BUT: studioswing utilzes luminance levels from 16-235 (8bit naming) for image content. However, broadcast-safe colors ("studioswing") also contain luminance levels from 0-15 and 236-255. These levels are not utilized for image content but are preserved for footroom and headroom (so while not utilized for image content these levels are still present in the file - note that Rec709 technically always contains 0-255 luminance levels).

Therefore 5DtoRGB's setting "fullrange" essentially will output files from the GH2 and the GH3 that look "dull" on a computer screen when viewed in appropriate software (but they look absolutely correct on a TV-screen). Of course, if you transcode to ProRes-QT the files contain tags assigned for viewing purposes on a computer screen - in effect the files look like "fullswing" in Quicktime (also in the interface of most other video-viewing-softwares designed for computers… for instance VLC, Movist etc. - and AFAIK this applies also to FCP7 / FCPx since these softwares are based on Quicktime). But this is just an "issue" of the respective viewing-softwares. When you view the respective files in a professional video editing software and open the Y-waveform-monitor you will see that the actual image content lives within 16-235 (see attachments).

So... again: using the "fullrange" setting in 5DtoRGB will preserve the full range of luminance levels contained in the source file!

In other words: this (and only this) setting will achieve a "lossless" transcode to ProRes.

You can remap broadcast safe levels from 16-235 to 0-255 when you set the setting to "broadcast". But the transcode remaps in 10bit. I feel much better to preserve the luminance levels of the source files and remap to fullswing (or whatever...) in the editing software in 16bit (or 32bit). Therefore I always set 5DtoRGB to "fullrange" (= "preserve the original luminance levels of the source file" = "no remapping").

@vicharris

can you give me a pointer to the respective thread ... I don't know it.

Thanks in advance!

@inqb8tr

I have been transcoding my GH2 files as BT.709 "broadcast range" most of the time. So I was basically not gaining but also not losing any information, except for leaving to 5DtoRGB to remap 16-235 to 0-255 in 10bit space.. Is that right?

yes, that's absolutely correct!

In most cases 10bit is totally fine. Really! Only in very rare cases (especially when you lift the shadows in post) it is preferable not to remap in 10bit (through 5DtoRGB) but to preserve the original luminance levels on transcode and then apply a curve in the NLE in 16 (or higher) bit. Since I don't want to dig too deep into the actual footage in my workflow I always transcode/import everything without remapping and apply high bit curves in the NLE afterwards. But this is just a matter of workflow standarization ... which I personally am finding easier to manage.

@towi I didn't mean the explanation you gave was absurd, just the fact this can't be decided on, that's all. It wasn't a swipe at you by any means. So is this statement not true?

"if you do a test, which i did earlier in this thread, you can see that full range is actually just lifting your shadows and compressing your highlights. The cam records in broadcast. So you are actually baking a shadow lift and highlight compression into your footage. And 601 does some odd stuff too."

Everything is Quite confusing :)

@mastroiani

Everything is Quite confusing :)

this may make things a bit more clear: http://www.belle-nuit.com/test-chart

In addition here's also a chart containing only broadcast safe colors: http://www.file-upload.net/download-7791434/HD_Testchart.tif.html

sigh It's getting to the point where I don't even care anymore. Do whatever the hell you feel like doing. BUT

There is zero difference between 5DtoRGB, 709, "Broadcast" ProRes 422 HQ transcodes and FCP7 and FCPX ProRes 422 HQ transcodes. None.

"Full Range" actually stretches the luma out. But there is zero difference in quality between transcoding full in 5DtoRGB and manually taking footage transcoded at "Broadcast" and stretching the Luma out in post. None. Not on a WFM and not to the eye.

So whether the computer does it, or you do it manually. The result is the same.

Now with 4444 footage I did some serious pixel peeping in my test and could see very slight, and I mean infinitesimal amounts of color distortion on FCP and 5DtoRGB broadcast footage when zoomed at 400% versus when using full range 4444 transcodes which showed no distortion. I was bending the shit out of the image, farther than you ever would in any serious grade to get this distortion, and it is not noticeable to the naked eye at 100%. What you gain from transcoding full @ 4444 vs. broadcast @ 422 is not worth the extra drive space. And between 422 broadcast and Full is not even worth the amount of words I've poured into this post.

In the end - it is all much ado about nothing. Today, I only use 5DtoRGB to transcode when for some reason FCP won't recognize my hacked footage.

No worries, Vic. I did these tests to save people time and energy, and in the end it accomplishes next to nothing. So I stopped doing them.

I'm glad at least some people pay attention.

More samples...

I was hoping that at least 5dtoRGB wouldn't mess up my footage, but this is really bad.