walkaboutcamera
Active member
...
Last edited:
GH4 Exposing V-LOG L
- Thread starter Bern Caughey
- Start date
walkaboutcamera
Active member
It is not a matter of degrading the image the concept of vlog l and compatibility with full vlog is wrong. The gh4 is probably the best studio, fully controlled lighting camera you can buy on a budget. But that is not what we need to push our cinematic envelope and that is what any log profile is about.
walkaboutcamera
Active member
I just checked the Shogun clip released from back then, and the magenta blocking is present and accounted for:
Since we know this was Shogun footage, and since my own PIX-E5 testing shows the same macroblocking in 10 bit 4:2:2, I have to conclude that the artifacts are embedded in the signal no matter which option you choose to record it with.
Both recorders appear to be faithfully recording the image presented to them through the 10 bit 4:2:2 HDMI output.
Which means my earlier post holds regarding my theory that the image is being degraded before we have a chance to record it.
Cheers,
Paul
sorry forgot to quote in my last post
Batutta
Major Contributor
LOL. Which means, if they fix it, the V-log L Image App free lunch is over.
joe12south
Veteran
These artifacts are present no matter the profile. There's no magic fix to V-LOG L that is going to make them go away. The very nature of a LOG gamma curve exaggerates the problem.
That said, I am surprised and disappointed that this encoding error is happening early in the processing chain. It would appear that the sensor output is being manipulated in an inaccurate, bit-starved fashion before it even gets out to the H.264 compressor...that can't be *fixed* by a LUT or a new profile. One LUT or another may highlight the issue, but it's always going to be there. The question is, can it be mitigated enough to not really matter.
That said, I am surprised and disappointed that this encoding error is happening early in the processing chain. It would appear that the sensor output is being manipulated in an inaccurate, bit-starved fashion before it even gets out to the H.264 compressor...that can't be *fixed* by a LUT or a new profile. One LUT or another may highlight the issue, but it's always going to be there. The question is, can it be mitigated enough to not really matter.
DVX 200 has a different sensor.
visceralpsyche
Well-known member
Interesting! I just tried that same clip in After Effects CC 2015 and you are right - no blocking to speak of.
All my research so far has been using Adobe Premiere CC 2015. So now my next question is, where do I find out or change what bit depth Premiere is working at?
After Effects CC 2015:
The plot thickens....
Speedgrade CC2015:
Davince Resolve 12:
Thanks for that tip anti12. Always happy to be proven wrong and learn
Cheers,
Paul
Last edited:
Interesting! I just tried that same clip in After Effects CC 2015 and you are right - no blocking to speak of.
All my research so far has been using Adobe Premiere CC 2015. So now my next question is, where do I find out or change what bit depth Premiere is working at?
The plot thickens....
Thanks for that pointer anti12. Always happy to be proven wrong and learn
Cheers,
Paul
That's actually nothing new. Adobe's implementation of prores decoder has many flaws, introduces banding and macroblocking even with Alexa footage and used a deinterlace filter one every single clip one two years ago...
Can't wait for Premiere to support DNXHR, should fix these problems
As you suspect, the image below shows magenta/green color casts and blotchy gradients due to inadequate bit depth. It does not show evidence of macroblock artifacts. The output of the GH4's internal 8-bit H.264 encoder is used only to produce video files; it is not decoded and routed to the HDMI output during scene capture. The 10-bit 4:2:2 HDMI output is not processed with any type of H.264 encoding that would produce macroblock artifacts; it is converted directly from the camera's high-precision tone curve processing into uncompressed HDMI format.
Last edited:
visceralpsyche
Well-known member
Thanks for the additional info
Currently my investigation is leading me in a new direction - as you can see on page 7, if I load the 10 bit 4:2:2 footage into Speedgrade or After Effects, the macroblocking disappears entirely. So it appears that the problem lies with Adobe Premiere CC 2015 in not processing the ProRes files correctly.
In fact, with Speedgrade and the Varicam LUT, it looks like it should. Sure, the bit depth is still reduced thanks to bad mapping of the bit data to the full 0-100 IRE output of the HDMI stream, resulting in only using 10-80 IRE, but the 10 bit 4:2:2 image holds up pretty well within that limitation, IF I don't use Premiere Pro to look at it or process it.
So I'm keen to hear from anyone who may know how to fix this within Premiere. I've tried Sequence Settings and switching to Maximum Bit Depth etc, but the problem is still there.
anti12 suggested it's a fundamental problem with Premiere CC, and I'm inclined to believe him based on what I'm seeing. The question is - can it be fixed?
joe12south
Veteran
Are you sure Premiere isn't transcoding?Thanks for the additional info
Currently my investigation is leading me in a new direction - as you can see on page 7, if I load the 10 bit 4:2:2 footage into Speedgrade or After Effects, the macroblocking disappears entirely. So it appears that the problem lies with Adobe Premiere CC 2015 in not processing the ProRes files correctly.
In fact, with Speedgrade and the Varicam LUT, it looks like it should. Sure, the bit depth is still reduced thanks to bad mapping of the bit data to the full 0-100 IRE output of the HDMI stream, resulting in only using 10-80 IRE, but the 10 bit 4:2:2 image holds up pretty well within that limitation, IF I don't use Premiere Pro to look at it or process it.
So I'm keen to hear from anyone who may know how to fix this within Premiere. I've tried Sequence Settings and switching to Maximum Bit Depth etc, but the problem is still there.
anti12 suggested it's a fundamental problem with Premiere CC, and I'm inclined to believe him based on what I'm seeing. The question is - can it be fixed?
Brandon Freeman
Well-known member
Even worse news - during a shoot today I decided to see just how deep the magenta blocking issue goes, and used focus assist on a wall, punched in 6x. ON THE LCD, BEFORE ANY KIND OF RECORDING, I can see the macro-blocking.
Fortunately I've found some FilmConvert settings that seem to reduce it (it involves film grain and the GH4 CineLike D Low Contrast profile with no prior LUT applied), but that's not going to work for everyone. I'm always going for a "film" kind of vibe and enjoy FilmConvert's grain... but this has pretty much reduced V-LOG L to when I'm looking for that feel. Most of the time I'm going to stick with Portrait I think.
Fortunately I've found some FilmConvert settings that seem to reduce it (it involves film grain and the GH4 CineLike D Low Contrast profile with no prior LUT applied), but that's not going to work for everyone. I'm always going for a "film" kind of vibe and enjoy FilmConvert's grain... but this has pretty much reduced V-LOG L to when I'm looking for that feel. Most of the time I'm going to stick with Portrait I think.
visceralpsyche
Well-known member
Yep, I'm seeing that too.
What's interesting is that processing 10 bit 4:2:2 footage recording from the HDMI out in Speedgrade doesn't show any macroblocking.
So I wonder whether the camera's display code is doing something similar to the way Premiere is decoding ProRes, that's introducing macroblocking into the image stream?
This is certainly becoming quite the investigation!!
Brandon Freeman
Well-known member
If that's true, then I wonder if the H.264 encoding in camera has a similar issue also - in other words, it's not just about the 8-bit depth encoding (though it certainly doesn't HELP).
Barry_Green
Moderator
Okay, hold on -- Paul tested and declared that there was blocking in everything. Then, when pointed out that his software was to blame, he then showed that yes indeed the software was the problem and there was no blocking to be seen. Am I understanding this correctly? Is this entirely a case of operator error, and the footage is not to blame at all? If so, we should really go delete all those posts, because it's scaring people for no valid reason.
Second, Brandon says that there's blocking in the LCD. I don't have a GH4 and cannot test that. I just pointed the DVX200 at a wall and door similar to what was shown earlier. I used the Odyssey 7Q+ (in both 8-bit 4:2:2 and 10-bit 4:2:2) to check. There was zero evidence of any magenta or green blocking, at all. I varied the exposure up and down the scale, I swapped between 8-bit and 10-bit, and I magnified the display to 2x, then 4x, then 12x. No evidence of it at all on the live feed. I then recorded (internal), played it back out to the Odyssey, and checked at 2x and 12x magnification. No evidence of any blocking.
Paul, can you please verify whether you have an issue or not, by using the original footage in Speedgrade or something else?
Second, Brandon says that there's blocking in the LCD. I don't have a GH4 and cannot test that. I just pointed the DVX200 at a wall and door similar to what was shown earlier. I used the Odyssey 7Q+ (in both 8-bit 4:2:2 and 10-bit 4:2:2) to check. There was zero evidence of any magenta or green blocking, at all. I varied the exposure up and down the scale, I swapped between 8-bit and 10-bit, and I magnified the display to 2x, then 4x, then 12x. No evidence of it at all on the live feed. I then recorded (internal), played it back out to the Odyssey, and checked at 2x and 12x magnification. No evidence of any blocking.
Paul, can you please verify whether you have an issue or not, by using the original footage in Speedgrade or something else?
Brandon Freeman
Well-known member
Barry, I'm going to try to replicate my experience again on the LCD, and I'll snap a picture of the LCD with my phone if that works. However, I'm having a devil of a time figuring out how to embed images in messages without having it greatly reduced in size, and the message board keeps adding notes to Dropbox links breaking them - so I'm not sure how to share what I'm seeing.
Brandon Freeman
Well-known member
Hmmm... Looking at the footage I shot internally earlier today, the macro blocking is way less apparent on the timeline than it was on the LCD (though I can still see something, but it's behaving differently and not nearly as "pink"). Perhaps the LCD has a separate issue and should be discarded from this discussion.
visceralpsyche
Well-known member
Here's a couple of samples from my GH4 screen. Apologies for the quality, but it's really hard to get focus on the screen without the moire from the LCD pixels!
As you can see, the screen shows the magenta blocking both zoomed in and at full image display. That's for internal, 8 bit recording path.
For 10 bit I don't have the PIX-E5 recorder with me any more as I only had access to it during yesterday's presentation by Video Devices, but I have enough footage between that and the Shogun clips released that I'm confident in using the files for my testing.
Currently, using Premiere Pro CC 2015 (the latest version), there is macroblocking in both 8 bit and 10 bit footage, be it MP4 or ProRes.
I think it's important to separate the reasons because although the 10 bit 4:2:2 footage from PIX-E or Shogun seems to not exhibit the blocking in Speedgrade CC 2015 or After Effects CC 2015, it does do so in Premiere.
With the 8 bit internal 4:2:0 footage, even the MP4 files show the blocking in Speedgrade, as well as showing up on the GH4's monitor before recording. This would seem to be due to not having enough colour bit depth/mathematical precision to accurately show the subtle changes without mathematically skewing magenta or cyan.
With the 10 bit 4:2:2 ProRes footage, there is enough mathematical precision to not have adjoining colour shifts skew their colour badly enough for the human eye to discern, without heavy colour grading to the point it breaks the image.
Except, it would seem, in Premiere Pro, which appears to be dithering the ProRes image incorrectly back to a lower bit depth, as seems to be happening in camera, resulting in the macroblocking errors lots of us are seeing.
So the discussion is actually two-pronged, and incredibly important given that a large number of people use Premiere Pro as their main editing software suite. If we are handing off footage to clients who use Premiere Pro, it will come back on us if we can't figure out how to fix the footage processing.
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