GH4 ACES support for the GH4

mash_gh4

Active member
over the last couple of weeks i developed a set of IDTs (input devices transformations) to use all the traditional photo styles of the GH4 in an ACES workflow. cinelike-d, natural or standard mode can by utilized this way like the v-log profile. an aproach that balazer tested and advised a while ago.

you can download the ready made OpenColorIO configuration set:

http://users.mur.at/ms/projects/gh4_aces/gh4_aces_1.0.1_0.2.zip

or take a look at the source code:

http://users.mur.at/ms/git/gitweb/?p=OpenColorIO-Configs.git

on most OpenColorIO based applications (natron, nuke...) you only have to choose the included config.ocio and you will get all the GH4 related input transformations.

auswahl.png


the available options may look a little bit confusing at first glance. the naming conventions for ACES color transformations suggest this notation:

first part: transfer function - second part: gamut name

colorspaces that start with 'Linear - ' will convert to or from a specific gamut but not apply a transfer function.
colorspaces that start with 'Curve - ' will apply a transfer function but not convert between gamuts.

i used the keyword 'legal' to flag the IDTs for footage recorded in 16-235 mode.

those IDTs labled with 'calibrated' use a measured 3x3 color optimization matrix to get a more accurate color rendition, while the others use only mandatory transformation constants for color transformation, but their luminosity handling is also based on empirical measurements. the 'calibrated' variants usually work very well. only v-log looks like an exception. in this very case the straight linearization may lead to more pleasant results.

a lot of confusing instructions, but you usually only have to look for entries of the form:

"... - GH4-Cinelike-D - GH4-Cinelike-D-Gamut Calibrated"
or
"... - GH4-V-Log - GH4-V-Log-Gamut"

you could also use the OpenColorIO 'ociobakelut' utility to bake 3D LUTs out of this quite complex transformations, to use them in other non ACES/OCIO compatible applications, but i would not recommend it. the benefits of the ACES workflow are strictly connected to its much higher processing accuracy in comparison to typical 3D-LUT application and a much more unified context of operation that helps to avoid a lot of mistakes.

the strive for a more accurate handling of GH4 video content was the main motivation to start this development. it doesn't want to represent just another magic bullet to get beautiful looking results out of your native footage. instead of inducing untraceable and irreversible color changes, it tries to limit its side effects to a minimum and respect given technical impossibilities. there are are always limitations that can not be transcended by given set of precise tools. it's quite trivial to compensate the luminosity behavior of most photo styles and linearize it. but on the color side the situation is much more complex. an inversion of all the gamut mappings that are baked into the usual photo styles of the GH4 looks almost impossible. if it could by done at all, it would require operations, that are hardly reconcilable with this strive for accurate and lossless processing. in this respect the corrections of this actual IDTs are quite limited. nevertheless the results look quite encouraging. the linearized representation builds an optimal ground for further manual correction and grading.

the inversion of the various gamma curves works very well for all picture styles. there are hardly any remarkable differences. even V-Log doesn't behave better.
here a comparison of the original pansonic V-Log IDT and my GH4 ITDs on the example of the natural picture profile:

v-log-panasonic-wb.png


natural-cal-wb.png


the differences on this level of linearization are neglectable. but this changes, when it comes to colors!
but, don't worry. using the luminosity linearization and a simple matrix color correction we will get acceptable results:

[please ignore the green tint / white balance in some of this screenshots! this issue does not exist in the real results!
i'm very unhappy about this misleading illustration, but i keep it, to make the deviances between different picture styles more visible.]

cine-d-cal-ref-cc24.png


cine-d-cal-uv-cc24.png


std-cal-ref-cc24.png


std-cal-uv-cc24.png


what we can not grasp by just analyzing this color checker examples, are the issues related to gamut compression and perceptual rendering in common rec709 footage. the GH4 picture styles are no exception in this respect. it's almost impossible to remove this color shifts.
this is the point, where V-log really shines! the huge V-Gamut doesn't have to twist all colors in such a way. watch the primary and secondary (especially: cyan and yellow) colors of an IT8 test chart:

v-log-panasonic-uv.png


natural-cal-uv.png


cine-d-cal-uv.png


v-log-panasonic-ref.png


natural-cal-ref.png


cine-d-cal-ref.png


concerning accurate color rendition V-Log looks brilliant. it can not be outperformed by processing usual picture profiles. they are tainted to much by gamut mapping related issues. but otherwise the image quality of the preprocessed traditional modes is so much better, that it still looks like an very attractive alternative.

keep in mind, that this IDTs are based on measurements of the the camera behavior using default conditions. if you change the settings, the correction will not fit anymore...

i hope, somebody will find this work useful.

please report errors or feature requests. maybe i can fix them.
 
I'm starting to work on comprehending the whole ACES thing and think there is potential for advanced hobbyists like me.

Are you saying VLOG is STILL better colors than NATURAL, even though it drags in a boat load of weird noise and limited bit usage?

Also, does ACES allow us to stretch our current contrast and colors out to REC.2020 and/or whatever that DOLBY VISION spec has coming?
 
I'm starting to work on comprehending the whole ACES thing and think there is potential for advanced hobbyists like me.

for simple private amateur video it may look like an overkill, but there is a lot to learn from ACES.
and it's the only application/platform independent standard to organize this kind of workflows in a more compatible way.

Are you saying VLOG is STILL better colors than NATURAL, even though it drags in a boat load of weird noise and limited bit usage?

no -- i would not recommend 8-bit vlog for any serious work. it looks horribly compared to the traditional image styles.

in a comparsion of "standard" vs. "vlog", both shot using the same settings, you can see:

a) visible color smearing in the neutral regions (magenta and green dots in the gray)...

vlog-pink.png


b) increased makro blocking issuses (this seams to be a side effect of lesser noise filtering, overcharging the compression/bandwidth) and lesser tonal nuances.

vlog-makro.png


c) there is a lot more noise in the dark regions of vlog

vlog-noise.png


all this issues are grave enough to keep away from vlog. it may work better with external 10-bit recording, but that could be true for the more traditional styles too...

but when it comes to accurate color rendition and gammut mapping related issus v-gamut has some positve impact that can not be archived by other recording modes.
some tricky 3d-luts could compensate the color deviations close to the narrow gamut borders of rec709, but this will never work very well.

you may think, this doesn't matter much, if you only want to produce standard hd video output using the same limited color range. this may work somehow, but you will never get not very well results if the colors are not at place in the actual working space. perceptual gamut compression in the output device transfomation have to misinterpret this colors and render them wrong.

therefore v-gamut has to be seen as a very important new feature -- much more worthy of remark than v-logs minimal dynamic range increase --, but on the other hand it is one of the reasons for all this actual troubles in 8 bit mode. a wider gamut range leads to less optimal used values too. that doubles the troubles we got by the 7-79 IRE limitation!

Also, does ACES allow us to stretch our current contrast and colors out to REC.2020 and/or whatever that DOLBY VISION spec has coming?

ACES supports very wide gamuts in its internal workspace. but it doesn't do it without caution. the much more limited 12bit ACES proxy for example, uses a much more limited gamut and dynamic representation to avoid issues similar to our actual v-log situation. and in general, this wide color ranges in ACEs are more seen as working space. in the output stage they usually get compressed in the most useful way for different reproduction devices.
 
Last edited:
Thank you mash_gh4 for those excellent reports!

It would be great if someone could confirm V-LOG-L on the GH5 with respect to using V-Gamut as opposed to Rec709's gamut.

Also a comparison between the smearing and increased marco blocking in V-LOG-L due to compression bandwidth limits between the 8-bit GH4 and 10-bit GH5 internal may be interesting.
 
Back
Top