FranceBB LUT Collection

[ClubM]

Just wanted to say thank you FranceBB for sharing these!

[FranceBB]

New day, new matrix of linear transformation.
This matrix has been inspired by something that hello_hello was talking about here which is basically going from BT2100 HDR PQ not to BT709 SDR but rather to BT2020 SDR. Although, generally, whenever we have PQ contents we go to HLG to keep HDR compatibility as much as possible up to 1000 nits, however the more it gets closer to the original HDR source, the more it gets dull on BT2020 SDR monitors/TVs, so it does actually make sense to have such a matrix as it can come in handy.
So, the idea behind this is to make use of the wide BT2020 but limiting the nits to get an SDR material. In other words, this content will look far better on UHD SDR TV that can handle 4K but that don't interpret any curve and would just ignore information about HLG in an HLG source and would interpret the matrix correctly.

Since we're dealing with BT2100 PQ and our output is going to be a BT2020 it's very strongly suggested to work with 16bit and output either a 12bit or a 10bit file also 'cause 8bit BT2020 is not officially supported (although Sony likes to make weird files and I've seen cameras being able to encode an 8bit file with BT2020 which is a mediocre compromise).

Alright, enough talking, let's see the curve!
If you take a look at it, it basically bring an HDR BT2100 PQ and maps it in order to get a gamma 1.90 (which is something we expect from an SDR source) BUT making use of the wide BT2020 matrix.
The knee at the very top is to avoid hard clipping and its slope is kinda high 'cause the amount of nits we have in our output is gonna be extremely low compared to the input, so our linear transformation is "onto" which means that it maps different points of the input to a single point of the output. If we call our input PQ "X" and our output Linear BT2020 SDR gamma 1.90 "Y", then the function is "onto" because every element in the codomain is the value of f(x) for at least one element x in the domain.





Screenshots are gonna be a little bit tricky though 'cause I have nothing to make you visualize them correctly if you have an old monitor which is not compatible with BT2020 SDR as I'm going to compare BT2100 HDR PQ with BT2020 SDR, none of which is supported by old monitors.



BT2100 HDR PQ (Top)
Linear BT2020 SDR (Bottom)











Temporary Link to the LUT for testing (it will be added to the main repository soon): Link

[DavidK_]

Frank!

I am helping Anatol on this conversion issue and tested your HLG to PQ lut. Very close - nice work - just had a couple of notes/adjustments if possible.

We're trying to get FFMPEG to match a source file and an output from an non-FFMPEG encoder. I measured the source, the version from an adobe media encoder and your lut via ffmpeg. Here are some of the results/observations comparing the three outputs:

1) Histogram:
Source MXF: RGB values: 7.774 6.701 7.267
Adobe Media Encoder H265: RGB values: 5.829 5.803 6.125
FFMPEG HLG TO PQ LUT: RGB values: 1.554 1.459 1.512
It does feel too red still and you'll notice that yours has just slightly elevated Rs instead of G and B with Blue being too low compared to Source and Media Encoder.

2) RGB peaks stop well below what the source and Media Encoder. Yours are at around 80/.8 whereas the source and Adobe version hit 100/1.

3) It feels too contrasty and darker with the LUT compared to what is expected. But just a little.

[FranceBB]

Originally Posted by DavidK_

Frank!

I am helping Anatol on this conversion issue and tested your HLG to PQ lut. Very close - nice work - just had a couple of notes/adjustments if possible.

We're trying to get FFMPEG to match a source file and an output from an non-FFMPEG encoder. I measured the source, the version from an adobe media encoder and your lut via ffmpeg. Here are some of the results/observations comparing the three outputs:

1) Histogram:
Source MXF: RGB values: 7.774 6.701 7.267
Adobe Media Encoder H265: RGB values: 5.829 5.803 6.125
FFMPEG HLG TO PQ LUT: RGB values: 1.554 1.459 1.512
It does feel too red still and you'll notice that yours has just slightly elevated Rs instead of G and B with Blue being too low compared to Source and Media Encoder.

2) RGB peaks stop well below what the source and Media Encoder. Yours are at around 80/.8 whereas the source and Adobe version hit 100/1.

3) It feels too contrasty and darker with the LUT compared to what is expected. But just a little.

A feedback is always welcome 'cause other people will always test more scenarios than I do on my own. I gotta say that I did notice a light dominance in red but that probably was because of my test source, so although the intent was to match it as much as possible, I think I "fixed" it when I was creating it so that the output was going to be ok, however that probably ended up with me matching the wrong points; the blue makes sense as it's the one that got compensated in favor of red. Anyway, I'll try to make another one but it would help to have a very short sample if you can provide one so that I can send you multiple outputs.

[PatchWorKs]

Hi there, just a question: do you think I need a "color conversion" lut for Canon HF100' shootings ?

I guess it *should* record in 4:2:0 8-bit AVCHD (.mts) Canon RGB...

[FranceBB]

Originally Posted by PatchWorKs

Hi there, just a question: do you think I need a "color conversion" lut for Canon HF100' shootings ?

I guess it *should* record in 4:2:0 8-bit AVCHD (.mts) Canon RGB...

Uhm... so it's basically an H.264 yv12 (4:2:0 planar) 8bit muxed in an .mts container, but that tells me nothing, honestly.
I mean, I tried to google it up and it doesn't seem to be able to record in any logarithmic curve, so my guess is that it actually records in Linear BT709. If that's the case, then no, you don't need a matrix of linear transformation, however I don't really know your model. Just scroll through the settings and check whether it says anything about "C-Log" (since it's Canon) or HLG. If it doesn't, then you're probably fine and it should say somewhere "BT.709". If you're uncertain, just record a short sample and upload it here via WeTransfer.

[PatchWorKs]

Ok, i did some searches too and found this interesting article:
Video editing for scientific analysis

That claims:

Color spaces – Studio RGB vs. Computer RGB vs. Canon RGB

One thing you may notice when using Vegas or viewing the output files after processing in Vegas is that the video looks “washed out” or too dark or contrasty. These problems come from color space conversion problems. Different video players use different color spaces, so the same video file might look fine in one player, and bad in another.

The brightness and color of pixels displayed on your computer screen is determined by three numbers, for the brightness of Red, Green, and Blue in each pixel. Each number can range from 0 (darkest) to 255 (brightest). If Red, Green, and Blue (RGB) are all 255, they combine to make bright white. This is the “Computer RGB” color space – each color has the range from 0 to 255.

The “Studio RGB” color space uses only the values from 16 to 235 to represent the RGB brightness. Values in the range of 0 to 15 are called “superblacks” and values 236-255 are “superwhites”. Standard televisions and video cameras are supposed to use the Studio RGB system. On a TV display, superblacks are all displayed as the same color of absolute black, and superwhites are all displayed as the same shade of whitest white, so 16 is as black as you can get, and 235 is as white as you can get.

But this is not true in the Computer RGB system. 16 is not pure black – it’s dark, but 0 is a lot darker. And 235 is not as bright as the computer display can get – full brightness comes at 255. So if you show a Studio RGB video (16-235) on a computer (0-255), it will look washed out, with low contrast. The blacks won’t be very black, and the whites will be grayish. And vice-versa; if you show a Computer RGB video on a TV, there will be too much contrast, with all the dark details (0 to 15) lost as black, and all the white highlights (236-255) “blown out” to pure white.

So a color space correction is needed when converting from one system to the other. Sony Vegas has the “Sony Color Corrector” video effect that you can use to do this conversion – it has presets for converting Computer to Studio RGB and another for the other direction.

But. If you look at the video files the Canon HF100 generates, you’ll find it uses the values 16-255, instead of either of the two standard systems. If you treat this as Studio RGB, the video will lose the bright highlights (236-255). If you treat it as Computer RGB, the black levels are wrong (16 instead of 0).

You can fix this by converting Canon RGB to Computer RGB (assuming you’ll view on a computer).

In the Sony Color Corrector, set Gain to 1.067 (this is (17+ 255)/255), and set an Offset of -17. The Color Corrector first multiplies all the color values by the Gain setting, so 16-255 becomes 17-272. Then it adds the Offset to all the values, so the range 17-272 becomes 0-255. I saved this setting as “Canon HFxxx to Comptuer RGB”.

...i still don't know if a lut is needed, but according to the article's author a "color shift" would be useful.

[FranceBB]

Ok so the first part is just talking about Limited TV Range and Full Range.
For 8bit:

Limited TV Range is 16-235 (0.0-0.7V)
Full PC Range is 0-255.

Your camera is behaving like some other Canon camera do while shooting in Linear BT709 8bit: they're set in Limited TV Range 16-235 however they leave the highlights unclipped so that they can go as high as 255.
In their mind, it's the cameraman that has to look at the waveform monitor and make sure that it doesn't overshoot and it's at the sweet spot instead (235).
This happens on professional productions while shooting live sports events as well, which is why I generally put a hard clipping to 16-235 at the very end of the chain just to be sure in case the cameraman goes mad and a player passes through a very strong light almost straight into the camera.
In your case, I would advise you to check your waveform monitor (if the camera has one built-in) and then make sure that your highlights never exceed 235 as you're gonna lose them.
Once in post-production, you can do a soft-clipping to bring what exceeded down to 235 and just be safe.
I don't really use Sony Vegas as NLE, I use AVID Media Composer instead (and sometimes Davinci Resolve for color-correction and masks), so I can't tell you how to do soft-clipping there, but if there's something called "Broadcast Safe" or "Broadcast colors" then go for it.
On Avisynth there are two ways of doing it as well:

#Indexing
FFMpegSource2("whatever.mts", atrack=-1)

#Clipping
Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

OR

#Indexing
FFMpegSource2("whatever.mts", atrack=-1)

#Canon Levels to Limited TV Range
Levels(0, 16, 255, 16, 235, coring=false)

The latter will assume that you shot on Canon Levels 16-255 and that your white is left unclipped to 255, so it keeps the black level at 16 and lowers down all the white values from 255 to 235. It should work.
Please keep in mind that the reason why I'm suggesting you that you work in Limited TV Range instead of using the Full PC Range 0-255 by just lowering the black of your Canon from 16 to 0 is that although you can encode and flag a stream with Full Range, it would be correctly reproduced by a bunch of computers only and a very little number of TVs will be able to correctly reproduce it; besides, not even ALL the players for computer will read the flag correctly and respect it, so my suggestion is to play safe and go for Limited TV Range 16-235.

This is an example of what I mean:



As you can see, clipping brutally "cuts" everything above 235 (which in that scale is 100% luma) while Levels just scales it down.

Oh, as a final remark, you don't really need a LUT for that; a LUT is a matrix of linear transformation, it maps a space into another and - in this case - points of a curve into points of another curve. In your case it would be from Linear BT709 with highs unclipped to Linear BT709 in limited TV Range, so it shouldn't really be needed considering that there are tons of other tools available for video levels that do a way better job. Anyway, just out of curiosity, a matrix of linear transformation from out of range Linear BT709 values to legal Linear BT709 values would look something like this (where 100% in this case means 255):







Please note that there are tons of topics about this subject here on Doom9 if you're curious.

I hope this clarifies your doubts.


Cheers,
Frank.

[DavidK_]

Originally Posted by FranceBB

A feedback is always welcome 'cause other people will always test more scenarios than I do on my own. I gotta say that I did notice a light dominance in red but that probably was because of my test source, so although the intent was to match it as much as possible, I think I "fixed" it when I was creating it so that the output was going to be ok, however that probably ended up with me matching the wrong points; the blue makes sense as it's the one that got compensated in favor of red. Anyway, I'll try to make another one but it would help to have a very short sample if you can provide one so that I can send you multiple outputs.

Okay I think you're right - we should reference something together. Here is a link to the file I used:

https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/

I'll reply back tomorrow with settings that I'm trying to match. And thank you!!!! You're insight has been very enlightening.

[DavidK_]

Originally Posted by FranceBB

A feedback is always welcome 'cause other people will always test more scenarios than I do on my own. I gotta say that I did notice a light dominance in red but that probably was because of my test source, so although the intent was to match it as much as possible, I think I "fixed" it when I was creating it so that the output was going to be ok, however that probably ended up with me matching the wrong points; the blue makes sense as it's the one that got compensated in favor of red. Anyway, I'll try to make another one but it would help to have a very short sample if you can provide one so that I can send you multiple outputs.

Originally Posted by DavidK_

Okay I think you're right - we should reference something together. Here is a link to the file I used:

https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/

I'll reply back tomorrow with settings that I'm trying to match. And thank you!!!! You're insight has been very enlightening.

And here are the settings to match:
LG Sample levels to match:
Source Timecode: 00:00:01:00
Source: R .802 G .672 B .795
Adobe Match: R 1.472 G 1.202 B 1.334

At least keep those proportions. And keep black levels a bit lower - the LUT feels a bit too contrasty/dark/inky I thought. Your lut currently is still too red - your lut levels were:R 2.877 G 2.654 B 2.56 - notice your's is too green and too red. Red and Blue should be more even etc.

[DavidK_]

Originally Posted by FranceBB

A feedback is always welcome 'cause other people will always test more scenarios than I do on my own. I gotta say that I did notice a light dominance in red but that probably was because of my test source, so although the intent was to match it as much as possible, I think I "fixed" it when I was creating it so that the output was going to be ok, however that probably ended up with me matching the wrong points; the blue makes sense as it's the one that got compensated in favor of red. Anyway, I'll try to make another one but it would help to have a very short sample if you can provide one so that I can send you multiple outputs.

Did you see my note below? (I have a sample for us to share and settings to match etc)

[FranceBB]

Originally Posted by DavidK_

Did you see my note below? (I have a sample for us to share and settings to match etc)

I did, but it's been 18 days since I left the office due to coronavirus and it seems like there's no plan for me to get back there AT LEAST 'till April. Right now I'm sitting at home waiting for this whole mess to calm down. Making a LUT with a crappy commercial 4K TV and monitor wouldn't be wise when I have a 50'000$ Sony monitor at work. Anyway, since this whole think is like a surreal situation, if you want me to try on my commercial TV and monitor, I will, it's just that I don't know how good the output will be.

[PatchWorKs]

Originally Posted by FranceBB

#Indexing
FFMpegSource2("whatever.mts", atrack=-1)

#Clipping
Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

OR

#Indexing
FFMpegSource2("whatever.mts", atrack=-1)

#Canon Levels to Limited TV Range
Levels(0, 16, 255, 16, 235, coring=false)

Ok, how to translate into FFMPEG ?

ffmpeg -i whatever.mts -vf "colorlevels=rimin=##/255:gimin=##/255:bimin=#/255:rimax=###/255:gimax=###/255:bimax=###/255, eq=gamma=#.##" -y out.mov

[FranceBB]

@PatchWorks... Clipping in ffmpeg is fairly easy:

ffmpeg -i "sample.mov" -vf lut=y=clipval:u=clipval:v=clipval

[frank]

There are only 3 BT... cubes in your download.
You have 6 BT... cubes at the first page.

I'm very missing the BT2100 HDR PQ to BT709 SDR cube.

[FranceBB]

Originally Posted by frank

There are only 3 BT... cubes in your download.
You have 6 BT... cubes at the first page.

I'm very missing the BT2100 HDR PQ to BT709 SDR cube.

Because it's called "PQ_to_BT709.cube" as file and there are two versions of it because one is the one I made at the very beginning when I first began to make matrices of this kind and the other one is my second attempt. The unusual name comes from the fact that at the very beginning I thought that nobody was ever going to be so mad to put a PQ curve into something else other than BT2100 with 10 or 12bit precision, so I just specified the curve and not the matrix in the name of the file only to find out later on that unfortunately there have been people doing weird thing so I changed the name of the post but I didn't change the name of the file (yet).
At the time of the creation whenever I wrote PQ I clearly meant a BT2100 with a PQ curve applied and when I wrote BT709 I clearly meant Linear BT709 with the plain old standard gamma. I hope this clarifies your doubts. Please try the two matrices and let me know.

[frank]

Thank you.

I have tested in Avisynth+ using avscube. The source was an UHD movie mkv:

LWLibavVideoSource(...)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f",dither_type="none")
Cube("C:\Program Files (x86)\AviSynth+\LUT\PQ_to_BT709_v2.cube", cpu=2, fullrange=true)
z_ConvertFormat(pixel_type="YV12",colorspace_op="rgb:linear:709:f=>709:709:709:l",dither_type="ordered")

Sorry, results have too much contrast and clipping from midtones upward.
There must be a problem with the level. It's not usable.

The Cube function only works in RGBP16, maybe floating point like RGBPS is needed.

edit: linear is wrong.

[PatchWorKs]

Originally Posted by FranceBB

@PatchWorks... Clipping in ffmpeg is fairly easy:

ffmpeg -i "sample.mov" -vf lut=y=clipval:u=clipval:v=clipval

I just found this interesting repository that explain how to generate a "measurement gif" of a clip with FFMPEG: https://github.com/dericed/ffmpeg-mpeg2video-clipping

This is the (33Mb !) GIF for 10s of my shooting:



As clearly viewable, the "Video editing for scientific analysis" was right: the Canon HF100 generates a "shifted" range files.

The "recalibration" of it with the clipval parameter generates this instead:



So the next question is: is possible to "shift down" everything (and constrain inside broadcast range, of course) in order to preserve the maximum possible color quality ?

Thanks again and sorry if I'm too nagging.

[frank]

IFAIK Canon has a converter software for the HF100. Maybe they use 16-255.
You have to ask Canon.

[FranceBB]

Originally Posted by PatchWorKs

So the next question is: is possible to "shift down" everything (and constrain inside broadcast range, of course) in order to preserve the maximum possible color quality ?

Thanks again and sorry if I'm too nagging.

Yes, absolutely. Since you're actually producing a non standard file with 16-255 you can also avoid clipping and just remap the highlights to 235 with levels in Avisynth as I pasted the code before

Levels(0, 16, 255, 16, 235, coring=false)

As it says that the input is 16-255 and the output is going to be 16-235. I'm pretty sure other thing that soft-clipping instead of hard-clipping can be done in ffmpeg as well, but I don't use it that much to post you a command line for that as well. Are you sure you don't wanna give Avisynth a try?

Originally Posted by frank

Sorry, results have too much contrast and clipping from midtones upward.
There must be a problem with the level. It's not usable.

The Cube function only works in RGBP16, maybe floating point like RGBPS is needed.

Did you try both the two .cube files for PQ to BT709? Do they have the same problem? 'cause that's really weird...