androidlad

I removed the free fix, and created a package with more options, including DCTLs: http://colorizer.net/index.php?op=technical
On the bottom of the page you'll still find an option to fix these issues for free using FFMPEG.
I can include more stuff in the package if any of you have suggestions.

Respecting or disrespecting the matrix coefficients tag won't result in blown-out footage. I believe you're talking about transfer characteristics, which is basicly the linearization function.
Disrespecting the matrix coefficients tag will result in different colors, as you have seen in my video.
I can show you what I mean. This is from a HLG video using the BT.709 matrix, extracted with FFMPEG. (Resolve has the same colors, I checked it.)

 
This is the same frame using the BT.2020 matrix, this is actually how FFMPEG extracts the frame without any extra options, since it respects the tags by default. But I also used zscale to do the scaling manually and the results are identical to what FFMPEG does by default:

 
Open the files in different tabs and switch between them. You might say that this doesn't matter to you, but the difference is there.

The issue this video covers was already mentioned in several topics, but I promised a video explanation and fixes, so here it is.
Beware: long, boring, bad English.
 

I finally figured out why I experienced problems with the LUT. An incorrect YCbCr->RGB conversion will result in values outside the 0-1 range. The LUT sees these values as 0 and 1 in Resolve, that's the reason for the inaccuracy. Premiere handles the LUT differently, there is no clamping there, and the results will be perfect, identical to using the DCTL version in Resolve. However it's possible the build a perfect LUT for Resolve as well, which will come in handy for non-Studio users. I actually built one, I plan to publish it alongside a video describing the problem in detail.

Yes, i will do some more testing with Alexa and LUTCalc's settings. Resolve also.
LUTCalc is pretty amazing. I didn't know there is something like this, but now I do thanks to you. So, thanks!

You're asking the guy who just so happens to have a gay porn actor as his profile picture
I know, I know, how do I just so happen to know that... the URL of his picture is telling.

Following @androidlad's findings i did some tests trying to decide which to choose, Flog or HLG.
Camera Settings:
FLOG: ISO 640 - SHUTTER 2000 - WB 5300K - F8
HLG: ISO 1000 - SHUTTER 3200 - WB 5300K - F8
Both shots exposed with Multi Metering aiming at 0 on the display meter.
Here are the results:
 
FLOG CLEAN


 
 HLG CLEAN


 
FLOG + FUJIFILM FLOG to WDR BT.709 LUT


 
HLG + LUTCalc HLG to ALEXA X2 LUT


 
HLG + LUTCalc HLG Rec709 LUT


 
FLOG + FUJIFILM FLOG to WDR BT.709 LUT + MINOR EXPOSURE ADJUSTMENTS


 
HLG + LUTCalc HLG Rec709 LUT + MINOR EXPOSURE ADJUSTMENTS


 
 
You can download the original files if you want.
https://we.tl/t-1qqI0lonhz

@androidlad Upon further inspection I found out that the Rec709toRec601.cube LUT is not 100% accurate, sometimes it will be slightly off. This problem might be something that can't be fixed with a single LUT, or matrix. For a really accurate conversion transcoding seems to be the only way:
ffmpeg -i INPUT.MOV -vf colorspace=all=bt709,scale=in_range=full:out_range=full -c:v prores_ks -profile:v 2 -c:a copy OUTPUT.MOV
Just remember to switch ProRes to full range once it's imported.
 

That's why I believe that assumption is wrong and the data itself is different.
EDIT: Forgot to tell you that I experimented with extracting the raw stream and inserting it into another container without any flags. In this case even Scratch shows the difference, so my theory seems to be correct.
EDIT2: Or just use this script: ffmpeg -i INPUT.MOV -c copy -bsf:v hevc_metadata=matrix_coefficients=1 OUTPUT.MOV
It only changes the matrix coefficients tag to BT.709, and immediately you can see a difference in Scratch. So it's respecting the tags.

It's not going to do any good if both of us to keep repeating ourselves.  I'll try a different explanation.
 
In the first place, dynamic rage was originally a property of analog systems to indicate the useful amplitude range rated in decibels (not "stops").  It is similar to the property of signal-to-noise ratio in that it gives some idea of the useful amplitude range above the noise floor.  DR now applies both to analog and digital systems.
 
Bit depth on the other hand is strictly a digital property that simply gives the number digital level increments mapped to an amplitude range (usually including the noise floor).
 
So, the useful amplitude range (analog or digital) and the number of digital increments mapped to the entire amplitude range are two very different, independent properties.  The noise floor of the sensor and/or ADC determines the actual dynamic range at that point in a camera's signal pipeline -- not the number digital level increments mapped (log, linear, whatever) to the signal's amplitude range.
 
 
Or perhaps we are confusing usable capture contrast range with dynamic range.

I go to the NAMM show every year, as I work for a major player in the music industry, and me and my parents headed up to Point Dume. 

I totally agree on calling out BS, so here goes - your post is BS.  
You're right that it's optimised for lower bitrates, but the advantages remain at higher ones.
This paper shows the objective (Peak Signal-to-Noise ratios) and subjective (blind test) comparison of the two: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7254155
The graphs in the paper test bitrates on UHD 60Hz up to 38Mbps H.264 and 18Mbps HEVC (broadcast bitrates) and they conclude:
And what about higher bitrates?
This paper here shows the relatively quality of the two at higher bitrates - up to about 250Mbps: https://pdfs.semanticscholar.org/b0bc/9342d1031250db0c7e2aabd2eeed51beef2e.pdf
Figure 3 shows that the 50% saving seems to extend up to around 6Mbps H264 (where the equivalent HEVC is about 3Mbps) but after that point there is a knee in the HEVC curve.
Figure 4 shows that the HEVC bitrate required to match the H264 goes above 50% up to the point where 40Mbps H264 requires about 30Mbps HEVC.
Figure 5 shows that the HEVC bitrate required to match the H264 goes back closer to 50% where 250Mbps H264 requires about 120Mbps HEVC, and for another clip 200Mbps H264 requires about 110Mbps HEVC.
Fact-checking the internet is fun, but it helps if you actually know the facts when you do it.
Yeah, some higher bitrates would have been nice.
I came late to the GH5 party so I don't know what the original specs were or what people thought of them, but they did introduce the 400Mbps and 5K Open Gate modes in firmware updates, so maybe there will be updates for this too?  I guess time will tell.

With the "marketing" promotions - what we are dealing with right now - we start to lose words meaning.
If you accept this "kind of RAW" as a loss way to record video, it is up to you.
Will you accept me saying you are a FAT GUY since you have more than 5 lbs?
What ? This is MY WAY to say you are beatifull !
Who am I ? I am the best marketing guy in the galaxy, you have to believe me that you are FAT!
No one else can contradict me, right ??? !!!
Andrew, I appologize for this OFF-TOPIC... 
Mea culpa!
But we need to respect the words for what they means - if we want to understand each-other!

And this is the final look i'm aiming...
For this I use the V3 to LogC and then a B&W film lut.

Holy F@ck !!! Sony sensors are a camera designers wet dream. I wish I was working with a start-up that was in the imaging space. The sheer number of camera sensor choices is Insane. At every size and imaginable spec. 

@androidlad
If half of the "leaks" you've posted are even close to the truth, I'll be absolutely floored.
So it's going to be a 60 megapixel camera that shoots a full readout downsampled to 4k 60p, outputting RAW to the AXS-R7 recorder utilizing a quad-base ISO? Oh yeah, and the E to E mount focal reducers. You are saying that Sony--who lost the 10-bit photo/video hybrid race to Panasonic, Nikon and even Canon--and who currently maxes out at a 100 Mbps codec--is going to release a camera that leapfrogs the market, logic, and physics itself.
If any of these are true, I'll be the first to admit you were right. But to say I'm skeptical is an understatement.

https://www.proav.co.uk/catalogsearch/result/?q=weebill
Standard - Creator - Master Package.
I didn't want/need the other stuff in the packages, and like I say, they're not yet available here, so I just bought that standard to use for now and will get the follow focus down the line.
Test video will be live here when YouTube are ready: 
Download the original files here (10gb): https://mega.nz/#F!TA8URCjb!v3AOrZUdFOtpNDmTjI5XUw
We're going to do another session tonight, turn the mics down, close the aperture and boost the ISO.

I don't agree with you on this one not even for a bit other than about barrel distortion, obviously. That one, you can easily correct. So?
Wanna facts?
P4P is oversharpened. Fact.
Not all of us are obsessed with edges but perception. Another fact.
MP2 ends to be more cinematic. My opinion, at least.

Yes, I have the same problem, didn't find a solution yet.

I was referencing 1080 on the GH5. Perhaps I should have said GH3 instead of GH5. 
You put out great content Andrew but sometimes it is worrying skewed with confirmation bias. 
Anyway, i find this whole place insufferable these days, so slay me here now if you wish. 

You go out of your way to try to disprove/discredit another reviewer for their fair criticism and still deny you're biased?

The new firmware is out!
 
https://www.atomos.com/firmware/ninja-v
 
Bug fixes:
Release NotesAtomOS 10.01
26 October 2018
- Fixed a monitoring issue with some cameras where the areas of peak brightness in images would appear black on screen when viewing using selected 3D LUTs.
- Improved HDMI signal locking to prevent the input from dropping with some camera settings. - Fixed an issue with audio delay where audio was corrupted at selected frame rates.

Just did a very non scientific power bank test with the X-T3. I fully charged the battery inside the camera with the factory charger, and I wanted to see how much time it takes until 1 unit on the camera display's battery level indicator is lost when using 4K60 recording (and boost mode turned on) with a power bank attached:
Anker 20000 PD: 25 mins until heat warning, I decided to stop the test there, indicator still showed full battery
Asus ZenPower 10050 (no PD on this one, just a regular power bank): 17 mins
No power bank attached: 13 mins
It seems it's a good idea to get a power bank with PD support. Actually this is what Fuji recommends as well.

If you don't like the 4GB file splitting and don't mind a bit of work, download ffmpeg, put ffmpeg.exe and your mov files you want to concatenate into a folder, and create a bat file (in windows) in that same folder with the following two lines:
(for %%i in (*.mov) do @echo file '%%i') > mylist.txt
ffmpeg -f concat -i mylist.txt -c copy output.mov
Running this will concatenate all the mov files in that folder without re-encoding into a file named output.mov. Keep in mind that on an average HDD this can take at least 1 minute/4GB.

IV been a bad boy today......