Sage

They are Exposure Pres, conversions made with the same interpolation system as the other conversions (converting color in the mix). Its a lot of fun to use in conjunction with the conversion. The P4Ka workflow video shows it in action in Resolve, though it applies to every NLE (and the Posts, which are an essential part of the picture): They may be stacked in order of greatest to least, and all may be used in conjunction with gain key/opacity to dial in an exact value (Post or Pre).

Sharpness at -5 for sure. NR can be a personal preference (some are noise averse and prefer the ease of NR in cam). Though -5 would be the Arri equivalent, from a purist perspective. Indeed, for VLog, 400 is the base. Then it goes to 200 for Cine-D, but this is just the labeling (200 really is 400, in VLog land) Yes; lately I've been recommending the simple rule of thumb to anchor everything around the center of the waveform (leaning higher rather than lower), no matter the profile. This is because all profiles share this middle 'cross point', and diverge from there (with varying contrasts), and 50-60 is generally where midtones should place (in exposure for EC709, not for post placement). The great news is that exposure/luma is about to become a breeze, in roughly a week.

With Cine-D, you'll want to set Saturation to -5, and the rest at default. Also, use ISO 200 (instead of 400; 200 is the electronic equivalent of HLG/VLog's 400). Highlight range (and gamut) are a 1:1 with HLG/VLog, once PRE'd. Here is an overlay of samples clipping (VLog overlayed on Cine-D):

The 1080p mode on the GH5 is really quite good; if like me, you are happy with a dense 2K image, then 1080p offers the most bitrate saturated options in the camera (no affect on color) Cine-D has a slight bit depth density edge over VLog, while VLog has a slight extreme gamut edge. With 8 bit, Cine-D is decidedly better Great work Parker and Benjamin! Alas, I've got to get the next update out.. Just finished writing one last tool that I believe will be critical for automating camera support, to do the Exp Pres (it is the fourth 'sub-section' of the ECE)

Crazy as it sounds, that's a possibility. My main concern there is bit depth density; SLog would probably not be the focus. The GH5S is next around the corner

Hehe, no idea there

These are quite good, reference samples from every current model: https://www.arri.com/en/learn-help/learn-help-camera-system/camera-sample-footage

HLG is a video *display format; its intended for use by a consumer who might theoretically show it directly on their HLG screen. It has to conform to video levels so that it will have correct contrast (and no range clipping on TVs). For computer *data formats, such as VLog, this isn't a concern, because its destined by design for the color suite (the computer display world is 0-1023). In practice though, because of the greater midtone contrast and upper range use of HLG combined with .mp4 compression, HLG has a bit depth density edge, over GH5 VLog.

That's the plan - I'm almost finished setting everything up for cameras going forward. I will really be able to accelerate now; a good indication will be how fast the GH5S is supported after the release of V4 for GH5. If a matter of weeks, then that is a very good sign for other cameras. Things will accelerate from there.

I believe he may have used Emotive on the Ursa portions; he is a huge fan of GHa and has P4Ka as of 3 weeks ago. The rolloff on the sunny leaves etc. feels right, but the colors are very off and green; its a safe bet that the Ursa has quite a different color science than the P4K, and will need its own conversion (working towards that day)

Its not too much a concern; in fact, HLG/Cine-D are more robust from a codec perspective. Speaking Gen.4, the extreme gamut is perhaps where VLog will have the slight edge in directness, but the others might be preferable overall. Attila - It does include perceptual luma weightings of RGB. To revisit the earlier discussion, everything fell into place with the engine rewrite (Pt.2). I've been working on the web side this week, and mostly wrapped that today. Now its back to finishing GHa V4, and last the Pdf (and streamlining it for future cameras).

XT3 is in the plans, indeed. At this moment, its down to documenting the process of adding a camera to the server, and then streamlining the Pdf writing process as best I can (later today). This will make a camera cycle as efficient as possible. From the LogC alone, V4 isn't that different from V3 for the average image. When saturation becomes more extreme, V4 is quite a bit better (much, much more accurate to Alexa). And when using V4 on unintended formats (i.e. Rec709 footage), V4 holds up, while V3 doesn't. Here is a comparison with one of the more saturated images I've got (most notable shift), using Soft (most equivalent variation between 3 & 4): V3 V4

Attila does great work, he has an excellent grasp of the technical; highly recommended That 4K 60 sounds quite good (super-sampled 10 bit) Ironically, I've still been working away at the EC engine, and fixing copious bugs (its inevitable that when I think a thing is finished, the work has just begun ) That being said, I think today I've fully tested it, and everything is working really, really well. This is a GHa Tungsten LogC render from this morning; the wheels on the far left and right are completely theoretical extreme gamut, beyond what the camera can record - the ones in the center are actual log gamut (and V3 for comparison): V4: V3:

Its something to test; even when flagging is settled, NLEs can have their own slightly unique 'color interpretations' of formats (cough, Premiere) So it goes up to 120 in HLG? (downscale or crop?)

The slightly different ways NLEs can interpret footage keeps me up at night. If the rendition is different, I'll have to do Pres, with the goal of supporting default timeline rendition in each NLE. Thankfully the P4K was simple in this regard. Given its a 10bit only format - is there any limitation on framerate?

In that case, HLG will likely be the primary format. The idea of variant NLE flagging is a concern though

Within the month. Yes indeed - everything will be entirely new

The XT-3 likely has better; DR and gamut are interrelated (i.e. where r, g, and b clip). Sensor determines how much of both one can have. At ISO 400, the Alexa has more than the GH5 (more saturated, higher brightness clip point). The GH5 and P4K have rougher blue clipping (like Alexa red clipping under tungsten WB) The P4K has slightly less than the Alexa at 400, or including HR range, slightly more artifacted range. If image quality is primary, the P4K takes the cake (completely smooth codecs). The GH5 is best for its IBIS, or little things, like the viewfinder in sun. I intend to support the XT-3 directly this year, sooner rather than later.

Very nice! From this morning, here is an interesting one. This is GHa Tun v4 extreme gamut finished with the new system (Tungsten extreme gamut is the most difficult scenario). GHa v4 Tun actually outperforms the Alexa in extreme red (Arri has the edge in blue though). Also note the slight banding apparent in blue/cyan/green (VLog All-I), a non-issue on the P4K (GH5 on the bottom):

Its a party bulb I picked up from the local hardware store. It has a hue rotate mode that, paired with a gradient, is completely unforgiving

Another tricky thing is the hand-off from the measured space under a given light source (sunlight or halogen) to extreme gamut simulation. This is because extreme saturation is only achievable with color light sources (i.e. red leds etc.). This amounts to two different 'perceived' color spaces from the same sensor. The challenge is to preserve hue lines of the measured light source as they move into extreme gamut, while simulating the behavior of extreme gamut. Hence, extreme gamut cannot be an exact match - note the difference in cyan and yellow especially (though can be similar enough as to be perceptually equivalent)

Happy New Year! Alexa has a distinctive red (when LogC is paired up with the intended display primaries). It is a deep magenta red, and twists moreso approaching extreme saturation. This can look stunning. Other cameras may opt for the default of twisting towards orange with increasing saturation because Cmos red clips to yellow, and the gamut clipping is more coherent. For example, the Alexa has an especially messy extreme red clipping at tungsten WB. With Gen 4, this extreme red behavior is simulated. Here is P4Ka v Alexa in extreme gamut, with EC709 (P4K at bottom): Apart from desired hue twists, like Arri display gamut, hue twists when conforming color spaces via interpolation (in log etc) have generally been one of the main challenges in developing EC (to keep the true clean hue lines as they should twist). At many stages, I've coded the engine to preserve clean hue lines. Hue is perceptually salient in color, and has a privileged place in the engine today (whereas once upon a time, it was just 'one of three' in the engine)

Working on it as we speak Its really neat; now I think several new cameras are achievable (in 2020). Days have been compressed to minutes

Very nice. Soon to put this one on the website - That's the plan. Today I finished a major engine rewrite, to greatly accelerate supporting new cameras. Its the most ambitious work yet, that self calibrates and auto iterates. It was enormously difficult, and I discovered legacy code mistakes dating back to the very beginning.

Its almost certain to be the case. Efficiency is vital. I have been deep in the code bunker this week, writing a special segment for the EC engine. This will greatly accelerate supporting new cameras, as it minimizes the amount of intervention necessary to conform data (with superior results). As of today, I have a new luma conform tool that is completely free of either hue or saturation distortion, and I am thrilled with it right now (not even Resolve's luma tools work this way). Now, I have to finish the second piece of the puzzle, and (accelerated) camera support will commence.