GH4 GH5 Owner / User Reports

[Cary Knoop]

It's V-LOG L, not V-LOG, and in that important distinction lies your answer. The GH5 records up to 12 stops of DR. Varicams record up to 14. In order to use the same curve for both (god knows why this matters) the V-LOG L signal fits in the bottom 12 stops.

It's a big plus because it is compatible.

For instance DaVinci RCM and ACES have built-in input transforms for V-LOG (both gamma and gamut) which can now be used for the GH5 as well!

Two questions to find out (I do not have a GH5 yet) is if the GH5 uses V-Gamut or Rec709 in its log implementation and if it correctly set for video levels (as opposed to data levels).

 

[Thomas Smet]

I've no experience of the GH4 so don't know what has gone before but all other things being equal an intra-frame codec is going to have a better image than a long-gop one if it is given the necessary extra data to record those frames properly. Did the GH4 have this data bump when it offered All-I recording as well?

Similarly a log recording mode is only of any use/benefit if there is enough information to fill the log container. 150mbs is what, 18.8MBs, compared to the 50MBs of the promised 400mbs update. At 10-bit as well, that is a setup that could yield a great and robust log image.

At the moment having it there is more of a marketing gimmick in my opinion and there is probably more mileage to be had in shooting in the other gammas while 150mbs is the only thing on offer.

Yes it did for HD recording. There was a 200mbps HD all-I recording mode that left a lot to be desired. ProRes422 smoked it visually. With that said that was based on 1080p 60p while the 400mbps on the GH5 is only based on up to 30p. So if you recorded 24p with the all-I you were only getting around 80mbps. On the GH5 24p should get around 320mbps. That is still only 4x more for 4x more data so visually I'm not sure if I would expect miracles from the all-I codec if the Gh4 is any indication of how poorly those turn out. I hope to be surprised but so far every all-I codec on the GH3 and GH4 we have had has been pretty bad.

AVC-Ultra is Panasonics high end 4k codec which also happens to use 400mbps all-I. When shooting detail this codec looks phenomenal and comparable to ProRes422 HQ which is around 800mbps. It is the areas of flat color and subtle color changes that can fall apart with a log format. ProRes422 HQ keeps the color in very good shape with V-log more so then what I have experienced with AVC-Intra (HD form of Ultra).

If you shoot log and a lot of flat subtle gradients an external recorder and ProRes422 HQ will likely be a better choice.

We will have to wait and see for sure however.

 

[Thomas Smet]

It's V-LOG L, not V-LOG, and in that important distinction lies your answer. The GH5 records up to 12 stops of DR. Varicams record up to 14. In order to use the same curve for both (god knows why this matters) the V-LOG L signal fits in the bottom 12 stops. That's why 100% white peaks at 80% IRE.

I have always found this to be a good thing.

Monitoring devices, NLE/grading software and tutorials/white papers now only have to be written to support one log format vs multiple log and lut formats. Log is difficult enough for many people without adding a lot of extra complexity on top of it where people need to try to figure out if they should use S-log1, S-log2 or S-log3. Sometimes flexibility is not as positive of a user experience and Panasonic wants to make their log format are widely supported as possible.

It may be true that not many Varicam shooters will have a Gh5 shooting next to them as well but it is the industry support and learning curve where it makes sense to have a single log format.

Besides V-log is one of the flattest log formats out there are very close to Arri C-log. In fact many people use Arri lots on V-log material since they are so close. On my Atomos Blade I actually find the built in Arri out to give better results than the built in V-log lut. Since Arri is a film standard, V-log can create a similar workflow for those used to working with Arri log material.

The choice to use such a stretched curve with a 12 bit camera may seem frustrating at first but it does have advantages once you get into solid recording formats. V-log L material has some serious manual grading potential in post compared to some other log formats. If you give it a format robust enough to not break it will serve you well.

 

[joe12south]

I'm not counting on it. I'm just discounting using log until that comes along and the container is more filled. As I said this is my nice little B-camera for when I don't want to use the main one. Plenty of times when log is not the best way to shoot on a camera like this and my one shoot so far Cinelike D was fine.

Red R3Ds are smaller in size than Pro Res too. XVAC-I from an FS7 smaller than the same pro res files it spits out too for very little if any gain in IQ. Bitrate isn't everything if you are comparing apples to oranges.

I mentioned ProRes just as an example, not for direct comparison. Again, if you do the math (I'm too lazy to do it again now) to compare the 2 versions of the h264 codec you will find that 150 --> 400 should not necessarily be expected to yield a quality increase. In fact, it is *more* bit starved, and the amount of compression per frame could go *up*. This same challenge the caused the all-i codec to be obviously inferior on the GH4.

 

[joe12south]

I have always found this to be a good thing.

Monitoring devices, NLE/grading software and tutorials/white papers now only have to be written to support one log format vs multiple log and lut formats. Log is difficult enough for many people without adding a lot of extra complexity on top of it where people need to try to figure out if they should use S-log1, S-log2 or S-log3. Sometimes flexibility is not as positive of a user experience and Panasonic wants to make their log format are widely supported as possible.

It may be true that not many Varicam shooters will have a Gh5 shooting next to them as well but it is the industry support and learning curve where it makes sense to have a single log format.

Besides V-log is one of the flattest log formats out there are very close to Arri C-log. In fact many people use Arri lots on V-log material since they are so close. On my Atomos Blade I actually find the built in Arri out to give better results than the built in V-log lut. Since Arri is a film standard, V-log can create a similar workflow for those used to working with Arri log material.

The choice to use such a stretched curve with a 12 bit camera may seem frustrating at first but it does have advantages once you get into solid recording formats. V-log L material has some serious manual grading potential in post compared to some other log formats. If you give it a format robust enough to not break it will serve you well.

Note that the flatness of the curve is not related to how much of the available bandwidth the curve utilizes. The net result of Panasonic's mapping choice is that yes, the same LUTs will work with GH's and Varicams, but that has very, very little practical benefit because if other things are equal it is trivial to adjust in post. All other things are not equal, though. The colorimetry of the cameras differs a good bit, so none of the Varicam LUT's look good out of the box anyhow. (Panasonic's base 709 LUT is way off on the GH4.)

The real important ramification of the decision is this: 30%+ of the precious available bandwidth is wasted...and when you're dealing with a highly compressed signal that you are then expecting to heavily manipulate in post, well, throwing away 30%+ is a *big deal.

For the 7 people out there who run both Varicams and GH's together, fine, keep V-LOG L. For the rest of us, add V-LOG G.

 

[joe12south]

It's a big plus because it is compatible.

For instance DaVinci RCM and ACES have built-in input transforms for V-LOG (both gamma and gamut) which can now be used for the GH5 as well!

Two questions to find out (I do not have a GH5 yet) is if the GH5 uses V-Gamut or Rec709 in its log implementation and if it correctly set for video levels (as opposed to data levels).

I find that a pretty weak argument for further hobbling an already very compressed signal. BMD would take the small effort to add a different input if it was needed. Just like they do for the Canon and Sony flavors. Hell, FilmConvert has already profiled the GH5.

 

[SystemAgnostic]

I mentioned ProRes just as an example, not for direct comparison. Again, if you do the math (I'm too lazy to do it again now) to compare the 2 versions of the h264 codec you will find that 150 --> 400 should not necessarily be expected to yield a quality increase. In fact, it is *more* bit starved, and the amount of compression per frame could go *up*. This same challenge the caused the all-i codec to be obviously inferior on the GH4.

I would think that the image quality would depend on the material. If there is a lot of movement & change in the content, then the all I compression at 400 Mbps would be better. If the content is fairly static, then the IPB compression at 150 Mbps would look better. I'm not sure though, it would be nice to see some tests when it comes out. Perhaps someone did these tests for the GH4?

 

[Steve Ogden]

filmguy123, check out this white paper by Barry Green on v-log L w/DVX200, should shed some light on your question.
http://pro-av.panasonic.net/en/dvx4k/pdf/ag-dvx200_tech_brief_vol6_en.pdf

 

[Ben Scott]

I mentioned ProRes just as an example, not for direct comparison. Again, if you do the math (I'm too lazy to do it again now) to compare the 2 versions of the h264 codec you will find that 150 --> 400 should not necessarily be expected to yield a quality increase. In fact, it is *more* bit starved, and the amount of compression per frame could go *up*. This same challenge the caused the all-i codec to be obviously inferior on the GH4.

I guess we'll see down the line and hopefully Panasonic has addressed this. Either way, I won't be relying on log for this camera in the short term.

 

[Sweden]

Why not just buy the Atomos Inferno and record externally and get the benefit of the monitor?

I have.

 

[joe12south]

I would think that the image quality would depend on the material. If there is a lot of movement & change in the content, then the all I compression at 400 Mbps would be better. If the content is fairly static, then the IPB compression at 150 Mbps would look better. I'm not sure though, it would be nice to see some tests when it comes out. Perhaps someone did these tests for the GH4?

Not necessarily. All of the sophisticated vectoring and motion-prediction goes out the window with an all-i codec...that's why it is faster to decode. There are certain possible motion artifacts that are eliminated, but by in large, PQ is not the reason to pick the all-i version of the same codec.

 

[Ron Evans]

Not necessarily. All of the sophisticated vectoring and motion-prediction goes out the window with an all-i codec...that's why it is faster to decode. There are certain possible motion artifacts that are eliminated, but by in large, PQ is not the reason to pick the all-i version of the same codec.

I don't think that is true. The encoder is different from what the camera presents as an image which is where the vectoring etc comes in. The reason its faster to decode is that there is no need to assemble frames from the GOP stream they are already individual frames.

 

[Kin869]

How's the 1080 recording quality compared to 4K? I know the GH4's 1080 resolved a lot less detail than 1080 downscaled from 4K. Even my GX85's 1080 mode has reduced resolution and a lot of moire/aliasing compared to shooting 4K.

If anyone's taking requests, it'd be nice to see a test comparing the sharpness difference between 24fps, 60fps, 120fps, and 180fps at 1080 and between 24fps and 60fps at 4K.

 

[Ben Scott]

I don't think that is true. The encoder is different from what the camera presents as an image which is where the vectoring etc comes in. The reason its faster to decode is that there is no need to assemble frames from the GOP stream they are already individual frames.

Exactly. Everything from CMOS smear to motion cadence should be improved from an All-I codec over a long gop one, as long as there is enough data being recorded.

 

[filmguy123]

If you've got the camera, post up some footage and tests! I know there have been plenty online, but will be great to have some from pro users here who can also answer follow up questions etc.

 

[Ben Scott]

I'd never het hired again if I posted footage from paying jobs without getting permission. I even had to clear posting that screengrab of Stephen Fry a page or two back. If I get anything decent on this shoot tomorrow I'll be allowed to post some stills at least.

 

[filmguy123]

No need to post footage from private paid jobs, and I certainly hope you're shooting personal tests with the camera and not making the paid jobs your tests!

 

[joe12south]

I don't think that is true. The encoder is different from what the camera presents as an image which is where the vectoring etc comes in. The reason its faster to decode is that there is no need to assemble frames from the GOP stream they are already individual frames.

I phrased my response poorly. Certainly the encoding, and the heaviest lifting, happens on the camera. But that info created during the encode is indeed the "hinting" that your CPU has to use to decode and build individual frames.

Regardless, my point still stands. All-I codecs are easier to decode. Being all-i does not bring meaningful PQ benefits in and of itself. All-i implementations require much more bandwidth to even break even in terms of PQ. If someone simply looks at it as: 400mbps is much more mbps than 150mbps, they'll be sorely disappointed.

 

[joe12south]

...as there is enough data being recorded.

^^^ The key point. 400mbps for 4K/10b/4:2:2 is not much bandwidth.

 

[Ben Scott]

No need to post footage from private paid jobs, and I certainly hope you're shooting personal tests with the camera and not making the paid jobs your tests!

Nope. Had to shoot for a documentary the day after receiving the camera as my other camera hadn't arrived. Not ideal but all went well. Seems pretty foolproof as long as you're not being silly with it.