kye

Interesting. I'd definitely raise that with Tiffen. Let us know how you go

...and when I say on the forefront, what I mean is they haven't implemented FHD 60p yet. Someone please tell me I somehow got this wrong? Seriously, there has to be something else to this.. really.

No no no no... RAW goes in, COOKED comes out!

Great stuff @leslie - keep us informed! Reading a thread like yours might be easier to get a summary than the P4K thread and it's zillion posts about if it really fits in your pocket or not ???

Everyone seemed to be in love with Cinelike-D before HLG was released, so I'm guessing that one. I haven't shot much with it myself though. Settings depends on what look you're going for I'd imagine.

Yeah, sounds like it was rendering proxies in the background. Your big load is the deflicker plugin. Most plugins work by doing something to one frame at a time, but this is one that has to analyse a bunch of them and I've noticed that it kills my machine too. A quick way to troubleshoot performance is to just play the timeline and watch the little FPS number above the viewer, and try turning on and off nodes and seeing where the load is. Often there are nodes that you can get dialled in, and then disable while you edit, then re-enable before you export. Resolve has a pretty complicated suite of performance optimising and caching functions, it's worth getting to know them so you can easily adjust things as you work to get the speed and the accuracy / quality you require at different stages of the editing process. For example: for editing you need speed so if you have compressed source footage then generating proxies will help, if you're doing dissolves or other effects then lowering the timeline resolution can help for image processing (not colour work) the load is in processing the footage so lowering the timeline resolution will help (as it has less pixels to compute) for colour grading you need high quality (and maybe not speed) so turn up the timeline resolution and just skip through the timeline, but if you need realtime playback then rendering cache on the timeline is the answer, but if you need high quality, realtime playback and can't wait for proxies to render then just hand your wallet over and someone will take care of it!

Actually, I think that it's a deeper issue. Just look at the terminology - "recovering highlights" is something that you do when things have gone brighter than white. This only makes sense if white has a shared definition, which it does if everyone is publishing in rec709. HLG is actually a delivery standard, so when someone shoots in HLG and are going to deliver in HLG then there is no recovery - if the camera clips the HLG file then that data is clipped. Same as if you shoot rec709 for delivery in rec709. If this guy was talking about filming in LOG then no-one would assume that he's delivering in LOG, so the conversation would be in the context of the default and standard delivery colour space / gamma. The point of HLG is that it's an alternative to rec709, and so now there is no default / standard / goes-without-saying reference point. Edit: coming from a camera, clipped HLG is the same as clipped 709.. that is some cameras may not actually be clipped because they might include super-whites in the output file, like I know the Canon cinema cameras do (as well as others I'm sure). Ah, I love the smell of confusion in the morning.

Yep. You use the Hue vs Hue to shift the yellows into the reds.

In Resolve I had this issue with my sunset time lapses and I found that the Hue vs Hue curve really helped. Obviously fixing it in-camera is better, but fixing it in post isn't that hard.

Definitely not a fair comparison, but they certainly both look really nice! The bokeh in the close-up shot is very nice.. and seems to be the anamorphic shape? I think you're slowly convincing yourself to go B&W! ???

Well, he makes no sense through most of that video but was absolutely right about one thing - when he said "I don't know the technicalities of what's actually going on". My understanding would be this: HLG includes the whole DR of the camera and the other profiles he tested don't FCPX is confusing him.. here's what I think is happening: FCPX takes the HLG file (which isn't clipping anything) and then converts it automatically to rec709, "clipping" it heavily but retaining that data in super-whites When he makes adjustments to lower the exposure those values above 100 get brought back into range He thinks that FCPX pushing the exposure beyond 100 somehow means the GH5 "clipped" (it didn't) He things that lowering the exposure in FCPX and getting the highlights back means you can somehow recover clipped highlights (you can't) If something is clipped then the values are lost (digital clipping is data loss) FCPX is "helping" by automatically doing things without asking you TL;DR - HLG has greater DR; exposing for HLG is different than rec709; FCPX is "helping" and confusing people; and this guy isn't the person to be listening to for this stuff.

Nice! I don't get it, but it's a cool aesthetic Made me think about that idea of having a virtual film club with some loose rules to encourage working fast to get something out and not getting too attached to making the end result perfect. I like the idea of having time limits on the stages of production and doing it all in one go. Something that could be done in an afternoon

Great video talking about HLG Talks about HLG acquisition, HLG delivery, backwards compatibility, grading, 709 conversions, exposure, HDR10, the HLG curve, cine gammas and commercial opportunities.

@BTM_Pix Belated congratulations on getting this app launched and out the door!! A lot easier said than done with technical projects like this!

I normally find that if you can run a short test to answer a question then that's normally the best way to do it. I have a GH5 and I'd run the test for you, but you should just do the test yourself and that way you get to choose the right scenario and look at the footage without internet compression Edit: quoted the wrong message first time around. fixed now

It depends on what you're trying to accomplish. When people ask about HLG they're often asking about delivering to HLG, so unfortunately it's ambiguous.

Cool. No, I haven't tried it. TBH I'm not really a gamer. This might seem strange for me to be looking at programming, but my ideas come from a place a bit different to how things are traditionally done. I've previously written complete 3D engines from scratch and so when I first contemplated getting into this I was essentially looking for a 3D VR polygon engine that I could just program, whereas these things are more like using the Doom level editor than actually coding something, which is kind of promising I think because that's not at all what I'm thinking of, so in a sense I'm likely to get different results and stand out from the crowd. Awesome, that's cool to hear. My first idea was more as a VR experience to generate the entire 3D environment using fractal mathematics, recursive algorithms and other techniques to generate alternative spaces that aren't designed to look like the real world. It seems silly to me to take computing power that can basically render whatever you want and then use it to just try and copy the real world. Anyway, once I've worked out how it works I'll probably just be creating and moving objects around with code and not really using the editor at all. I just have to work through their examples.. first step is to work out why their 3D game kit gets compiler errors. and when I say first step, I have to work out where I see those errors, then what they mean, then how to fix them

Thank goodness for that!

I have worked with GH5 HLG, and also found confusion out there. What are you trying to do?

If it doesn't cook in 10-bit then you should replace it with one that does.

I've just started with Unity. I read a bunch of comparisons and they seemed to think that Unity was better for smaller studios and for doing mobile, so I'll see how I go. In a sense I'm not the typical user because I know how to code and I don't want to use it for what it's designed for, so I guess we'll see. I've learned so many programming languages over the years that it's not that hard to pick things up, although these things are very far removed from programming, so I guess I'll see how I go. I suspect that I'll likely abandon the game interface and end up coding most things, as my goal is more around algorithmically rendered environments rather than typical 3D apps or games.

Interesting question. You get a reference clip and then encode it to whatever codec you want to measure and then compare the compressed clip to the original and then do some math and get the result. The tricky thing is that to compare BRAW with uncompressed RAW with the P4K you would have to point the camera at something recording uncompressed RAW and then set it to compressed BRAW and point the camera at the exact identical same thing, which is practically impossible. In reality you'd have to be able to take uncompressed RAW and then convert it into BRAW so you had the the same thing in the two codecs, so it's something that only BM would be able to do I think. I'd bet that looking at signal-to-noise ratios would have been done probably thousands of times during the development of BRAW, and they'd have been comparing it to all the other codecs they could analyse too, but I doubt we'd ever see any of their numbers. The only way we'd get a glimpse of it would be for someone to buy a P4K, crack it open and then tap into the RAW feed coming off the sensor before it gets to the video processing circuitry and save that stream as uncompressed RAW and let the camera record to BRAW, then to compare those two files. Of course, they would have to do a similar test for every BRAW setting, and as the codec quality is signal-dependent they'd have to do it many times for each set of settings in order to be able to reliably compare two different compression levels.

Not a waste, but it's not required. Just did a few tests. I got a project, changed the timeline to 720p, added a 4K still image, then exported at 4K, changed the timeline to be 4K, then exported at 4K again. This is what you get: if you export at 4K from a 720p timeline you get a 4K file but with 720p quality if you export at 4K from a 4K timeline you get a 4K file and 4K quality An easy way to judge what quality you're getting in the output is to add a Text generator and make the font size really big and look at how sharp the edges are in the output file, especially on curves or edges close to horizontal or vertical.

Yep - bright and wide is a nice combo.. especially paired with the extra low-light of the GH5s!

It would be interesting to see a signal-to-noise analysis of BRAW at various bitrates vs competing formats. I doubt we'll see one, but after seeing how h265 is roughly the same as h264 with double the bitrate, it might be a similar situation between BRAW and CDNG formats where BRAW gives similar image quality to a much higher bitrate CDNG stream.