GH4 Exposing V-LOG L

visceralpsyche said:
I'm hopeful that someone with access to the Premiere Pro team can point them here so we can all figure out the problem together, because right now the fact that myself and others are having macroblocking issues needs to be fixed, as 99% of GH4 users probably aren't going to read these posts and think, like me, that VLog-L is fundamentally broken (which I will still argue it is in 8 bit, as well as not using all the available bit depth in both 8 bit and 10 bit).

Cheers,

Paul :)
Click to expand...

For what it's worth... https://twitter.com/Hall_E_Woode/status/644970596778946560 :)
 
Perhaps it has to do with how the GH4 down converts a live image from the sensor to be seen on a very low resolution display. We see this sometimes with moire and binning where waves on water will have a color shift. This might explain why you see it on the LCD and not in the actually footage as much. If the GH4 with its limited processing power has to use a crude form of binning for the LCD it would without a doubt look much worse than the actual footage.

I'm not I would ever consider the GH4 LCD a definitive representation of what the video will look like. Sure its a good LCD but it is not perfect and we don't know how the GH4 gets the signal to that LCD with no lag at all.
 
Thomas Smet said:
Perhaps it has to do with how the GH4 down converts a live image from the sensor to be seen on a very low resolution display. We see this sometimes with moire and binning where waves on water will have a color shift. This might explain why you see it on the LCD and not in the actually footage as much. If the GH4 with its limited processing power has to use a crude form of binning for the LCD it would without a doubt look much worse than the actual footage.

I'm not I would ever consider the GH4 LCD a definitive representation of what the video will look like. Sure its a good LCD but it is not perfect and we don't know how the GH4 gets the signal to that LCD with no lag at all.
Click to expand...

Agreed. But I imagine that somewhere in the chain, we're seeing the result of the same mathematical error in processing the footage.

For now, I don't care about the monitor on the GH4 showing magenta, as long as the recorded footage doesn't have it (which in 10 bit, it appears not to, so long as you are using certain NLEs).

I still think the implementation is broken with regard to not using the whole bit bucket when capturing and outputting the image data, as it's limiting the colour bandwidth unnecessarily and artificially.
 
Here's internal, 8 bit 4:2:0 footage in After Effects CC 2015.

As you can see, the magenta macroblocking is quite prevalent.

Since we can see that 10 bit 4:2:2 ProRes footage DOESN'T appear to show macroblocking in After Effects, there is definitely something to the lack of bit depth causing the 8 bit footage to break up into magenta macroblocks.

VLogL-Test-4-AE-VLOG.jpg
 
My perspective is as an ex-computer programmer, so in bug-finding, the key is always to minimize the variables to identify what is the real root cause of the issues.

First, it looks like Premiere has a bug. You can't blame the GH4's recordings or VLOG if it grades lovely in Speedgrade or Resolve or something else, but looks bad in Premiere; if that's the case, you blame Premiere. Doesn't matter if Premiere's popular or whatever; if it is the source of the bug, you can't fix someone else's bug for them.

Regarding the purple on the LCD -- unfortunately that's not necessarily proof of anything, as it could be a problem with the LCD itself, or moire-introduced patterns in scaling down the image to fit on the LCD, or some quick and dirty conversion from internal 14-bit (or whatever it is) to 8-bit (or 6-bit or whatever the LCD is). There are several potential places that such a problem could be introduced, so I would say that is not definitive proof that the purple/green is happening at the internal processing point. Now, if you could plug the HDMI output into a high-quality 4K monitor and you still see the purple/green, then that would be a good indicator that the problem is inherent in the GH4 signal processing. As said, I used an Odyssey 7Q+, which has a great monitor and extremely good magnification tools, and I saw no evidence of purple/green on white-ish walls and a white doorframe. Anybody else here who has a GH4 and a 7Q+ who could run that same test? That would help quite a bit to narrow things down.

Has anybody asked Illya Friedman? That guy probably has more GH4 and VLOG experience than just about anyone else; surely he would have some good advice on the subject?
 
Has anyone tried using Davinci Resolve instead of Premiere Pro to see if the magenta micro blocking is caused by Adobe? I don't have a clip what has it as prominent as others have.
 
On the other hand I shot this promo with V-LOG L and I couldn't find the Magenta Micoblocking. Shot internal on the GH4. edited in Premiere Pro and graded with Varicam LUT in Lumetri Color.

The only V-LOG Footage is the anchors in front of the video wall.

https://vimeo.com/139742565


VLOG TEST.KUSI.Still004.jpg

This is from 10bit out into the 7Q+. No LUT just graded it.
 
Last edited:
visceralpsyche said:
I still think the implementation is broken with regard to not using the whole bit bucket when capturing and outputting the image data, as it's limiting the colour bandwidth unnecessarily and artificially.
Click to expand...
Again, not necessarily true. You don't know whether it's being limited unnecessarily or not. Consider that VLOG, SLOG, CLOG, all of them have a minimum floor level of 32 (in 8-bit) or 128 (in 10-bit). None of them use the codes from 0-31. Why? Probably a concession to the fact that the footage is not recorded raw, it's recorded via a video compression engine -- and the video compression would probably mercilessly attack anything encoded in those lower bit values. All the log gammas that I know of sit up on a "pedestal" to keep them out of that lower range.

It may seem unnecessary and artificial, but in a practical context it may actually be very necessary in terms of viewing the entire system as a complete system.

As far as wasting bits on the top end, yes, that one is harder to accept. The fact is that it's compliant with VLOG, and so those bits are only used in sensors that deliver more than 12 stops, and the GH4 doesn't, so those bits don't get used. In order to utilize those bits, they'd have to create a new gamma curve, a not-VLOG gamma curve. Maybe it would be called GLOG or something. Or VLOGH4? In any case, it could be done if they made a specific curve that was specifically designed for this sensor. That's not what they did at this point.
 
Erik Naso said:
Has anyone tried using Davinci Resolve instead of Premiere Pro to see if the magenta micro blocking is caused by Adobe? I don't have a clip what has it as prominent as others have.
Click to expand...
Yes, I tried it. With 10 bit 4:2:2 ProRes footage, resolve shows no macroblocking:

shogun_vlog_Resolve_lut.jpg
 
Barry_Green said:
My perspective is as an ex-computer programmer, so in bug-finding, the key is always to minimize the variables to identify what is the real root cause of the issues.

First, it looks like Premiere has a bug. You can't blame the GH4's recordings or VLOG if it grades lovely in Speedgrade or Resolve or something else, but looks bad in Premiere; if that's the case, you blame Premiere. Doesn't matter if Premiere's popular or whatever; if it is the source of the bug, you can't fix someone else's bug for them.
Click to expand...

Agreed. Premiere Pro CC 2015 definitely has a bug with regard to correctly interpreting the 10 bit 4:2:2 ProRes footage, from both the Shogun and the PIX-E (and probably other ProRes stuff too).

Barry_Green said:
Regarding the purple on the LCD -- unfortunately that's not necessarily proof of anything, as it could be a problem with the LCD itself, or moire-introduced patterns in scaling down the image to fit on the LCD, or some quick and dirty conversion from internal 14-bit (or whatever it is) to 8-bit (or 6-bit or whatever the LCD is). There are several potential places that such a problem could be introduced, so I would say that is not definitive proof that the purple/green is happening at the internal processing point. Now, if you could plug the HDMI output into a high-quality 4K monitor and you still see the purple/green, then that would be a good indicator that the problem is inherent in the GH4 signal processing. As said, I used an Odyssey 7Q+, which has a great monitor and extremely good magnification tools, and I saw no evidence of purple/green on white-ish walls and a white doorframe. Anybody else here who has a GH4 and a 7Q+ who could run that same test? That would help quite a bit to narrow things down.
Click to expand...

Yeah, the monitor thing I'm not too worried about. It's a framing tool for me, not the definitive image I'm going to see in post. It's just interesting that the macroblocking you see on the GH4 monitor matches the macroblocking seen in the internal, 8 bit footage when recorded.

Barry_Green said:
Has anybody asked Illya Friedman? That guy probably has more GH4 and VLOG experience than just about anyone else; surely he would have some good advice on the subject?
Click to expand...

At this point the main issue seems to be more about Premiere and how it deals with the 10 bit footage. Those who don't use Premiere to edit or grade likely never saw any issue with 10 bit footage.

8 bit footage internal to the camera exhibits macroblocking across all NLEs and is likely not going to be fixable without Panasonic rewriting the VLog profile to work in 8 bits more efficiently.

I'm actually curious and don't have an external recorder to test this, so props to anyone who can - record the 8 bit 4:2:0 HDMI output EXTERNALLY to a 10 bit 4:2:2 ProRes or alternate format file, and see if there is macroblocking or not. It would help eliminate another processing chain variable.

Cheers,

Paul :)
 
Erik Naso said:
On the other hand I shot this promo with V-LOG L and I couldn't find the Magenta Micoblocking. Shot internal on the GH4. edited in Premiere Pro....
Click to expand...

there are some not so nice color changes on the forehead of the actors, but this could likewise have other reasons (vimeo compression etc.):

Bildschirmfoto_2015-09-19_01-23-17.jpg
 
Kevin Monahan said:
Hi,
Can you please summarize the issue and give me precise steps on reproducing the issue with the least steps possible? Also, file bugs here to let the team know. If everyone on this thread filed a bug, it would be very helpful.

Thanks,
Kevin Monahan
Support Product Manager, Digital Video Applications
Adobe
Click to expand...
Thanks for the support Kevin!
 
Kevin Monahan said:
Hi,
Can you please summarize the issue and give me precise steps on reproducing the issue with the least steps possible? Also, file bugs here to let the team know. If everyone on this thread filed a bug, it would be very helpful.

Thanks,
Kevin Monahan
Support Product Manager, Digital Video Applications
Adobe
Click to expand...
Thanks for coming here Kevin :)

I should note that I'm on a Windows PC, so I don't know if OSX shows the same issue.

Using the latest, up to date Adobe CC 2015.

1. Download the Shogun 10 bit, 4:2:2 ProRes sample using VLog from Nick Driftwood's tweet here: https://twitter.com/Driftwood_Prods/status/618863103749529600

2. Download the VLog LUT from Panasonic and install it into Premiere's Lumetri LUT folder and After Effects: http://pro-av.panasonic.net/en/varicam/35/firmware/VLog_to_V709_forV35_ver100.zip

3. Open the ProRes sample and create a timeline with it in Premiere.

4. Apply the VLog LUT using Lumetri Color in the Basic Correction - Input LUT section. Zoom in to the woman's face and notice the magenta macroblock style banding (see below for sample). This appears to be where Premiere is not correctly handling the 10 bit 4:2:2 colour space of the ProRes file.

5. Open the same file in After Effects using 32 bit colour space. Apply the same LUT. Notice that there is no magenta macroblocking and colours appear true and well blended between shades.

That's the crux of the problem.

I'll file the same text as a bug report via your link.

Cheers!


After Effects (correct representation):

shogun_vlog_AE_lut.jpg


Premiere Pro (incorrect representation with magenta macroblocking):

shogun_vlog_varicam_lut.jpg
 
I just did a quick transcoding test:

1. Open the original ProRes file in After Effects (32 bit float project).

2. Create a new Comp and Render out as Quicktime 10 bit YUV 422 Uncompressed.

3. Open the new uncompressed Quicktime file (still 10 bit 422 like the original) in Premiere Pro.

4. Apply the Varicam LUT using Lumetri Color, just like with the original ProRes file.

Result:

The re-encoded Quicktime file has the LUT correctly applied and appears without any YUV chroma smearing.

The original ProRes file with the same LUT shows YUV chroma smearing.

So the problem seems to be something to do with the way Premiere is interpreting ProRes 10 bit 422 footage.

HTH!

Paul :)

Original ProRes (see scope displays - they look badly interpolated to me, not smooth and continuous):

render1.jpg


Uncompressed 10 bit 422 Quicktime (scopes show smooth gradations and not strange interpolation patterns):

render2.jpg
 
Last edited:
Adobe's Premiere appears to cause banding, & perhaps other issues, when applying a LUT to some 10-bit 4:2:2 SLOG3 footage so I was concerned it might not be best when working V-LOG L.
 
Played with Resolve for a second, realized that I've become old and comfortable with my Adobe set-up, so it looks like I'll be editing in Premiere and Color Grading in AE when it comes to V-LOG L and my eventual Atomos Ninja Assassin. Just like old times!
 
Barry_Green said:
As far as wasting bits on the top end, yes, that one is harder to accept. The fact is that it's compliant with VLOG, and so those bits are only used in sensors that deliver more than 12 stops, and the GH4 doesn't, so those bits don't get used. In order to utilize those bits, they'd have to create a new gamma curve, a not-VLOG gamma curve. Maybe it would be called GLOG or something. Or VLOGH4? In any case, it could be done if they made a specific curve that was specifically designed for this sensor. That's not what they did at this point.
Click to expand...

Yep As you mentioned earlier and LPowell agreed, the thing is thats what many are saying, they had so much time...yet they never created a gamma curve consistent with the 12 stop range of the GH4, instead they used the Varicam vurve minus the extra stops.
To me (and I build 3d packages with call up scripts for 3d specific apps) this definitely seems to be a cop out...or at the very least a time saving short cut.
The thing is even the "Lower End" users still want the best bang for the buck...for better or worse...so Panasonic are getting a backlash because of this, they should have done it properly in the first place.
As far as compatability with the VC? That seems pretty odd, there is an approx $50,000 difference, doesnt make a lot of sense whatever way you look at it.

As a side note...on the subject in a 32 bit workspace in AE the 8 bit footage has the same magenta banding...thats more or less been established I know, but it was queried a while back...havent tested the 10 bit yet tho.
 
You must log in or register to reply here.
Back
Top