Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 Doom9's Forum FranceBB LUT Collection
 Register FAQ Calendar Search Today's Posts Mark Forums Read

 8th February 2019, 23:24 #2  |  Link gonca Registered User   Join Date: Jul 2012 Posts: 1,209 Thank you for this. One question Should it be fulldepth=true or false since false would return 8 bit I believe
9th February 2019, 04:12   #3  |  Link
FranceBB

Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,737
Quote:
 Originally Posted by gonca Should it be fulldepth=true or false since false would return 8 bit I believe
Nope, they both return 16bit, but fullrange=true is for full range (PC Range) sources, while fullrange=false is for limited range (TV Range) sources.
Limited range for 8bit is 16-235, for 10bit is 64-940 and so on.
Full range for 8bit is 0-255, for 10bit is 0-1020 and so on.
It depends on your source, but keep in mind that the majority of sources are TV Range and if you encode something for the TV, it has to be Limited TV Range.

Last edited by FranceBB; 9th February 2019 at 16:40.

 9th February 2019, 12:37 #4  |  Link gonca Registered User   Join Date: Jul 2012 Posts: 1,209 My mistake I originally read fulldepth in your sample script, but after re reading it I realize that it actually says fullrange
9th February 2019, 14:56   #5  |  Link
StainlessS
HeartlessS Usurer

Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,880
Quote:
 Full range for 8bit is 0-255, for 10bit is 0-1024 and so on.
Nit Pick, 1023.

EDIT: Hmmm, I'm wrong too.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 9th February 2019 at 18:22.

 9th February 2019, 16:44 #6  |  Link FranceBB Broadcast Encoder     Join Date: Nov 2013 Location: Royal Borough of Kensington & Chelsea, UK Posts: 2,737 Sorry about that. Actually, this is the right one, I think (from the Avisynth Wiki): __________________ LUT Collection FFAStrans Videotek - AAA - SafeColorLimiter
 9th February 2019, 20:48 #7  |  Link huhn Registered User   Join Date: Oct 2012 Posts: 7,773 these "issues" come from the understanding that 10 bit is 4 times as big as 8 bit so we just have to multiply by 4. 8 bit RGB 255 255 255 as 10 bit is 1023 1023 1023 not 1020 1020 1020 has a very slightly lower brightness and is just 4x the original number. the correct way to increase 8 bit to 10 bit is taking the first 2 bits from the 8 bit source and add them to the end. or as an small example: 11111111=255 100 % brightness 1111111100=1020 ~99.7% brightness 1111111111= 1023 100% brightness
9th February 2019, 21:41   #8  |  Link
wonkey_monkey
Formerly davidh*****

Join Date: Jan 2004
Posts: 2,478
Quote:
 Originally Posted by huhn the correct way
But according to whom? The wiki seems to indicate the other way - simple shifting - is correct. What's the broadcast standard?

And what's the correct way to go back down? Is there bit-ty way to do it, or do you have to divide by 4.0117647059?

And I thought 16-235 was a headache...
__________________
My AviSynth filters / I'm the Doctor

 9th February 2019, 22:02 #9  |  Link huhn Registered User   Join Date: Oct 2012 Posts: 7,773 i just ask you a different question who stops you from creating a native 10 bit source with 1023 in it? a bad way to go back to 8 bit is by removing the last too bits truncation. another one would be dithering.
9th February 2019, 22:19   #10  |  Link
wonkey_monkey
Formerly davidh*****

Join Date: Jan 2004
Posts: 2,478
Quote:
 i just ask you a different question who stops you from creating a native 10 bit source with 1023 in it?
Umm, okay, but my questions weren't rhetorical. Nothing stops you from creating a native 8 bit source with 255 in it, but that is - according to broadcast standards - an "illegal" value.

Quote:
 a bad way to go back to 8 bit is by removing the last too bits truncation. another one would be dithering.
Dithering still needs a convention as to what values, integer of fractional, correspond between the bit depths.
__________________
My AviSynth filters / I'm the Doctor

9th February 2019, 22:39   #11  |  Link
huhn
Registered User

Join Date: Oct 2012
Posts: 7,773
Quote:
 Originally Posted by wonkey_monkey Umm, okay, but my questions weren't rhetorical. Nothing stops you from creating a native 8 bit source with 255 in it, but that is - according to broadcast standards - an "illegal" value.
full range is a thing. computer games work in it it's part of display port and HDMI.

while BD source is all ways limited range this doesn't change that even full range encoding is a thing and totally supported by programs like x264.

and be aware that this is about RGB not YCbCr.
so clearly not illegal
Quote:
 Dithering still needs a convention as to what values, integer of fractional, correspond between the bit depths.
does it? how should i even know what an dithering algorithm is working internal. i know it using the "errors" truncated parts to spread noise if it is max 1023 or 1020 shouldn't matter. it will just use what it has available.

 9th February 2019, 22:49 #12  |  Link wonkey_monkey Formerly davidh*****     Join Date: Jan 2004 Posts: 2,478 Okay, we're getting off-track. The original point is: the Avisynth wiki says 8-bit 255 is equivalent to 10-bit 1020. You say it's 1023. Who's right? __________________ My AviSynth filters / I'm the Doctor
 25th February 2019, 22:30 #13  |  Link silverwing Registered User   Join Date: Nov 2017 Location: Russia, Nizhny Novgorod Posts: 25 FranceBB, thank you! So. These are examples with your lut "PQ_to_HLG.cube". I get a similar result only with the help of a long selection of curves in the plugin "SmoothCurve". Good work. Attached Images
19th March 2019, 05:59   #14  |  Link
FranceBB

Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,737
Quote:
 FranceBB, thank you! So. These are examples with your lut "PQ_to_HLG.cube". I get a similar result only with the help of a long selection of curves in the plugin "SmoothCurve". Good work.
Thanks, I tried to tweak things correctly.

Update: Added Slog3 to BT709 LUT

Whenever I work for the News channel or for our Sport channel, I receive footages shot normally, but whenever I work on TV Series, I receive footages shot in Slog3 and I always have to bring them to BT709 to encode everything in a standard old-fashioned FULL HD SDR.
I'm gonna share with you my Slog3 to BT709 LUT as well.

Slog3 first, BT709 second:

Some people may think that it's ok-ish, but slightly dark on some low-light scenes, but actually this is because I added a knee to the curve and there's a reason for that: trying to stay in the Limited Tv Range avoiding clipping.
Let's take a look at this example here with a strong light coming from behind.
Raw footage in Slog3:

If I try to apply a transformation without using a knee, the white level gets too high and I get out of legal range, therefore everything over 235 gets clipped out:

By adding a knee, however, I manage to get thinks right in 16-235 without the need to clip so many details out:

If you take a look at the curve of the transformation you can see how the unclipped one gets so high that it almost looks like a function that reaches a vertical asymptote:

While the knee manages to smooth things out and generates a proper curve:

Last edited by FranceBB; 24th March 2019 at 05:31.

 24th April 2019, 03:41 #16  |  Link FranceBB Broadcast Encoder     Join Date: Nov 2013 Location: Royal Borough of Kensington & Chelsea, UK Posts: 2,737 Alright, let's crack on and view some examples. You'll find the original C-Log3 footage, the BT709 SDR one, the HDR HLG one and the HDR PQ one. I tried to keep the BT709 LUT as usable as possible, but limiting C-Log3 to BT709 SDR means that many details are really gonna be clipped out and you can definitely see it from the examples below. As to the HDR HLG BT2100, it pretty much resembles the BT709 SDR version, but it does show more details, despite being still capped out. Finally, the HDR PQ BT2100 is the best looking version, with a very natural look and it almost feel like as if you were there for real with 3500 nits worth of data. C-Log3 BT709 SDR BT2100 HDR HLG BT2100 HDR PQ C-Log3 BT709 SDR BT2100 HDR HLG BT2100 HDR PQ C-Log3 BT709 SDR BT2100 HDR HLG BT2100 HDR PQ C-Log3 BT709 SDR BT2100 HDR HLG BT2100 HDR PQ __________________ LUT Collection FFAStrans Videotek - AAA - SafeColorLimiter
 25th April 2019, 22:54 #17  |  Link gonca Registered User   Join Date: Jul 2012 Posts: 1,209 Once again, thank you for your contribution
 1st May 2019, 08:13 #18  |  Link Sharc Registered User   Join Date: May 2006 Posts: 3,977 Perhaps a dumb question: How do people select the "correct" LUT? Is it a matter of personal taste, or do we need reference pictures for comparison?
1st May 2019, 14:08   #19  |  Link
FranceBB

Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,737
Quote:
 Originally Posted by Sharc Perhaps a dumb question: How do people select the "correct" LUT? Is it a matter of personal taste, or do we need reference pictures for comparison?
What do you mean?
Each LUT is a matrix of linear transformation that goes from a curve to the other, which basically means that, depending on your source color curve, you use the one to go from it to your target color curve.
For instance, if you have an HDR PQ video and you wanna go to HDR HLG, you are gonna use my PQ_to_HLG LUT.

If you are asking how to create a LUT yourself, then that's a whole different question and... no, it's not a matter of personal taste only, it's a matter of linear algebra, defined standards and personal taste.
You generally start with a linear conversion from a curve to the other and then tweak it trying to get into the right values according to the standard. After that, you can fine-tune it 'till you'll get something that looks best for your taste, as long as you are still respecting the standards.
Anyway, it really depends on your source and your target, 'cause if you have two curves that are really different one to the other, then you are gonna have to choose which parts of the input you wanna keep while you go to your desired output.
Let's suppose that you have a C-LOG3 in input and you wanna go to BT709 SDR in output; you can basically get the calculations right, but you still have to choose what you wanna sacrifice as the BT709 SDR is able to retain very little informations compared to the input and THAT is a personal choice according to what you think it's best.
When I make my LUTs, I always try to keep as many things as possible and make them usable for pretty much every scenario. Let's suppose that we have a scene with snow, a white dog and the sky: you are gonna have three different tonalities of white, one for the snow, one for the dog and one for the highlights (sky). If you originally shoot in BT709 SDR, you have one of those three tonalities of white clipped out, while if you shoot in C-LOG3 you are gonna have as many details as your camera can get, then, in encoding, you can decide to retain the desired part of the image, with the desired tonalities of white. In this specific case, you wouldn't be able to do it with my LUT, 'cause my LUT is gonna take a decision for you and clip what I thought it was supposed to be an acceptable compromise for every scenario, but it's better to do it manually, 'cause by doing it manually you can choose which things you are gonna preserve for that specific shot.
I hope this answer your question; if you want, I can get into more technical details.

Cheers,
Frank.

Last edited by FranceBB; 1st May 2019 at 16:44.

 1st May 2019, 14:49 #20  |  Link Sharc Registered User   Join Date: May 2006 Posts: 3,977 Thank you Frank for enlightening me. Your short tutorial answered my nebulous question about the LUTs nicely Last edited by Sharc; 1st May 2019 at 14:52.