FranceBB LUT Collection

[frank]

Ok, BT709_to_HLG_v3 works better. But the color contrast is lower, I guess about 5%-10%.

My 3 test options:

- VirtualDub to control avs.
- A new Dell XPS 15 9500, it has a very good display with Windows HD color. I can watch HDR or HLG encoded streams using mpv, color mapping is awesome.
- TV LG OLED 48CX (neutrally calibrated) to show the end result.

In the mean time I encoded a SDR to HLG sample with color transfer functions of Avisynth+. The result was surprisingly good.
# Converting SDR to HLG (avsresize.dll)
z_ConvertFormat(colorspace_op="709:709:709:l=>2020:std-b67:2020:l", \
pixel_type="YUV420P10",dither_type="error_diffusion",nominal_luminance=150) But I had to set the nominal_luminance to 150 (default 100) to get the right brightness.
Very difficult to distinguish from the original on the LG OLED. :) But HEVC reencoding of long HD movies like Das Boot results in 1/5 size.

[FranceBB]

Linear Transformation v1.4 (https://github.com/FranceBB/LinearTransformation/releases)

Changelog:

- Improved BT2020 HLG to Linear BT709 SDR Conversion (I'm now following the EBU Tech 3373 specifications much more closely)
- From "BT601_NTSC" to "BT601_PAL"
- From "BT601_NTSC" to "BT2020"
- From "BT601_NTSC" to "BT2020_HLG"
- From "BT601_NTSC" to "BT2100_PQ"
- From "BT601_PAL" to "BT601_NTSC"
- From "BT601_PAL" to "BT2020"
- From "BT601_PAL" to "BT2020_HLG"
- From "BT601_PAL" to "BT2100_PQ"
- From "BT2020_HLG" to "BT601_PAL"
- From "BT2020_HLG" to "BT601_NTSC"
- From "BT2020" to "BT601_NTSC"
- From "BT2020" to "BT601_PAL"
- From "BT2100_PQ" to "BT601_NTSC"
- From "BT2100_PQ" to "BT601_PAL"



I'm looking for volunteers to test those new matrices 'cause my tests have all been done with color bars.
Please test those with real life contents and come back to me with the results!

[gispos]

Thank you FranceBB,
tried the BT2020 to SDR ( HLG_BT2020_to_Linear_BT709, PQ_to_BT709_v1) and the results are very good for me.
With DGHDRToSDR I sometimes needed more than half an hour for a slightly worse result (falsified colors).
Are variations also possible? like: normal, everything darker brighter

[FranceBB]

Well not inside the matrix itself as I gotta respect the mapping points defined by the standard (any modification would be my personal choice and not the application of the documents from the regulators), anyway that is indeed possible, however, for a "normal" use case I would say that once you bring everything to BT709 SDR 100 nits, you can use any SDR-aware Color Correction filter like smooth adjust, tweaks, levels etc 'cause you're effectively just working in BT709 SDR without any Color curve applied ('cause the old fashioned resulting sigmoid in the transformation took care of it for you). For instance if you're in a NLE you can easily apply the matrix and then use the colour correction panel.

Anyway I'm glad that they're working as intended. :)

[wswartzendruber]

Hey FranceBB... It's me again and I'm up to my usual antics.

How does HLG_BT2020_to_Linear_BT709.cube work? Is it linear up to a certain point and then there's a knee like BT.2390 and Mobius? Or does it darken the overall image like Hable?

[FranceBB]

Hey FranceBB... It's me again and I'm up to my usual antics.

How does HLG_BT2020_to_Linear_BT709.cube work? Is it linear up to a certain point and then there's a knee like BT.2390 and Mobius? Or does it darken the overall image like Hable?

No worries. :)
You're right, it is linear at the very beginning and then it's "kneed" down following the EBU Tech 3373 reference (https://tech.ebu.ch/docs/tech/tech3373.pdf), in fact I used their v210 lossless color bars as reference along with the values included in their document. I gotta say, though, that I didn't follow them by the letter in the sense that if you're gonna check the bars with a scope after the transformation you won't see a straight line. The reason is that I started with that and then I adjusted myself 'cause I tried to preserve as many details as I could in the 400 nits range then I made a soft-rollback (soft-clip) of the 1000 nits highights. The reason is that while the vast majority of HLG movies peak at 1000 nits, I noticed that the vast majority of sporting events from 2017 onward 'till nowadays generally peak at 400 nits.

[wswartzendruber]

No worries. :)
You're right, it is linear at the very beginning and then it's "kneed" down following the EBU Tech 3373 reference (https://tech.ebu.ch/docs/tech/tech3373.pdf), in fact I used their v210 lossless color bars as reference along with the values included in their document. I gotta say, though, that I didn't follow them by the letter in the sense that if you're gonna check the bars with a scope after the transformation you won't see a straight line. The reason is that I started with that and then I adjusted myself 'cause I tried to preserve as many details as I could in the 400 nits range then I made a soft-rollback (soft-clip) of the 1000 nits highights. The reason is that while the vast majority of HLG movies peak at 1000 nits, I noticed that the vast majority of sporting events from 2017 onward 'till nowadays generally peak at 400 nits.
I think that would work for what I want. My idea is to convert a frame of a movie to HLG using pq2hlg, then downconvert that output using this LUT of yours. I should then compare it against a BT.709 Blu-ray screenshot of the same frame, in order to see if I need to increase or reduce the PQ's brightness.

Until now, I've just been using MPV and VLC to compare how they look on BT.709, but VLC's Hable implementation darkens the whole frame while MPV seems have shifting levels of brightness. So I'm looking for a more firm source of truth on what a HLG frame's BT.709 representation should really be.

[FranceBB]

I think that's gonna work.
On the other hand, I very much like the MPV approach and you can try to play with:

--target-peak=<auto|nits>
--tone-mapping=<value>
--tone-mapping-param=<value>
--tone-mapping-max-boost=<1.0..10.0>
--hdr-compute-peak=<auto|yes|no>
--hdr-peak-decay-rate=<1.0..1000.0>
--hdr-scene-threshold-low=<0.0..100.0>
--hdr-scene-threshold-high=<0.0..100.0>
--tone-mapping-desaturate=<0.0..1.0>
--tone-mapping-desaturate-exponent=<0.0..20.0>

in particular, you can easily tweak the dynamic tonemapping of MPV to also behave like a "normal" static mapper and have a more consistent result. I would do that for testing only 'cause I very much like the dynamic tonemapping of MPV and I'd very much like to see it implemented in FFMpeg one day 'cause the way it is implemented in FFMpeg right now is sort of unfinished 'cause the mapping is static and doesn't adjust itself on a scene-by-scene basis, which is a shame.

For me the real deal are those three parameters in particular:

--hdr-compute-peak=<auto|yes|no>
Compute the HDR peak and frame average brightness per-frame instead of relying on tagged metadata. These values are averaged over local regions as well as over several frames to prevent the value from jittering around too much. This option basically gives you dynamic, per-scene tone mapping.

--hdr-peak-decay-rate=<1.0..1000.0>
The decay rate used for the HDR peak detection algorithm (default: 100.0). This is only relevant when --hdr-compute-peak is enabled. Higher values make the peak decay more slowly, leading to more stable values at the cost of more "eye adaptation"-like effects (although this is mitigated somewhat by --hdr-scene-threshold). A value of 1.0 (the lowest possible) disables all averaging, meaning each frame's value is used directly as measured, but doing this is not recommended for "noisy" sources since it may lead to excessive flicker. (In signal theory terms, this controls the time constant "tau" of an IIR low pass filter)

--hdr-scene-threshold-low=<0.0..100.0>, --hdr-scene-threshold-high=<0.0..100.0>
The lower and upper thresholds (in dB) for a brightness difference to be considered a scene change (default: 5.5 low, 10.0 high). This is only relevant when --hdr-compute-peak is enabled. Normally, small fluctuations in the frame brightness are compensated for by the peak averaging mechanism, but for large jumps in the brightness this can result in the frame remaining too bright or too dark for up to several seconds, depending on the value of --hdr-peak-decay-rate. To counteract this, when the brightness between the running average and the current frame exceeds the low threshold, mpv will make the averaging filter more aggressive, up to the limit of the high threshold (at which point the filter becomes instant).

[joearmstrong]

I downloaded your LUT collection v1.4 and tested PQ to BT709. v1 is working but v2 cannot be loaded - tested with AviSynth+ and your LinearTransformation plugin. Error message: AVSCube - cannot open cube file.
My AviSynth command was: LinearTransformation(Input="BT2100_PQ", Output="BT709").

Edit: It seems to be a problem of the LinearTransform plugin. Using PQ_to_Bt709_v2.cube with Avsresize is working fine.

z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:l=>rgb:st2084:2020:f",dither_type="none")
Cube("PQ_to_Bt709_v2.cube", fullrange=true)
z_ConvertFormat(pixel_type="YV12",colorspace_op="rgb:709:709:f=>709:709:709:l",dither_type="ordered")

[FranceBB]

Only v1 is included in Linear Transformation, though (check the conditional at line 38):

Input=="BT2100_PQ" && Output=="BT709" ? "PQ_to_BT709_v1"

therefore there's no way to call v2 from within the plugin.
Shall I add v2 inside as well?

Besides, did you set mypath at the very beginning in line 6 of the script?
By default it's:

mypath = "C:\Program Files (x86)\AviSynth+\LUTs\"

which means that it's gonna look for the LUTs in a folder called "LUTs" inside the main Avisynth+ folder, however, if you have them in some other place, you gotta specify it

[joearmstrong]

Yes, I specified the folder where I stored your cube-file. I found a solution: Renaming PQ_to_BT709_v2.cube to PQ_to_BT709_v1.cube fixed the issue.
Adding v2 to Linear Transformation would of course be better.

Do you prefer v1 or v2 for HDR to SDR?

[chmars]

Hi,

I'm trying to see how far I could grade without the use of Resolve.
My capture rushes are in Slog3 (Sony FS7 XAVC-I).
As starting point, I tried
s = FFVideoSource("D:\davinci_eric_folder\test_sources\490-christophe_010-XAVCI-4K-BLD-Trim_Crop.mov").KillAudio().assumefps(25)
s = s.trim(2528, 2578).crop(80,90,-70,-80)
s1 = s.convertbits(16).ConvertToYUV422()
s2 = s.LinearTransformation(Input="SLog3", Output="Linear_BT709")


return(stackhorizontal(s1, s2))

But I get a strange result (source/lineartransformed):
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/vTjCG1D8RrILl2Y/download
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/vTjCG1D8RrILl2Y/download

Here is the clip (https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/tRsJqj7kfndpdRm/download)
Where is my error?

[FranceBB]

Where is my error?

No error, the result is consistent with what I get by using:

FFVideoSource("Z:\490_trim_crop.mov")
ConvertBits(16)
ConverttoPlanarRGB()
Cube("C:\Program Files (x86)\AviSynth+\LUTs\Slog3_to_BT709.cube", fullrange=true)

So I assume that the blue shift is already in the very old source, you're not seeing it in the Slog3 file 'cause it's impossible to see it with a naked eye.
As an example, here's a real Slog3 image after the Linear Transformation:

https://i.imgur.com/8xxQEA4.png


Of course, in your specific case this can be easily fixed by playing with the ASC-CDL with a 0.66 slope reduction on the mapping of the blue values:

https://i.imgur.com/59PH90J.png

which leads to this:

https://i.imgur.com/iO9ZTsS.png
https://i.imgur.com/wuJ3qdq.png
https://i.imgur.com/z1767GX.png


Released Linear Transformation v1.5 (https://github.com/FranceBB/LinearTransformation/releases)

Changelog:

Updated LinearTransformation() for Super8 Slog3 captures:

LinearTransformation(Input="SLog3_Super8", Output="BT709")

https://github.com/FranceBB/LinearTransformation/releases

[chmars]

Whaaa, great, thanks for the work+explanation, one more Avi saint!:)

So I assume that the blue shift is already in the very old source, you're not seeing it in the Slog3 file 'cause it's impossible to see it with a naked eye.
Hmmm...wait... before concrete dries, maybe, this counts:

On the pro side, in the studio, we are used to shoot with cameras (Red...) which have daylight sensors. So we shoot with daylight sources. This allows not to increase the noise in post-production, noise which would appear mainly in the red, by lifting up the color temperature to compensate artificial CTT light sources (halogen...).

I followed the same logic here when I set up my contraption. Blue filter to convert the contraption halogen bulb from 3200°K to 5600°K. To be seen as white by the sensor.
But is the FS7 sensor daylight? I am 90%sure but don't find the official information about that. Sensor is an EXMOR R CMOS...

Anyway, I guess the LUT to be used for 8mm/S8mm conversion via Slog3 also depends on the light source of the scanner/projector. Some use fixed temp LEDs, others RGB LEDs, halogen...

Back to our case:
It's great to have a LUT that approaches me to the final image so much in one step. Resolve LUT also gave crazy results. So, till now, I had to manually correct the colors levels and curves.

If you are interested, here (https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/5tVHzmKspSdFQ3n/download) is a more complete test file.
It contains various scenes. Also some sea takes where blue (and miss of magenta?) still appear a bit excessive with the new LUT:
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/9vi5uL5dFiGIHHg/download
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/9vi5uL5dFiGIHHg/download

Detail:
LinearTransformation(Input="SLog3_Super8", Output="Linear_BT709")didn't work butLinearTransformation(Input="SLog3_Super8", Output="BT709")did. I think the new output name wasn't changed in the new avsi.

[FranceBB]

one more Avi saint!:)


lol



On the pro side, in the studio, we are used to shoot with cameras (Red...) which have daylight sensors. So we shoot with daylight sources. This allows not to increase the noise in post-production, noise which would appear mainly in the red, by lifting up the color temperature to compensate artificial CTT light sources (halogen...).


Yes, when shooting using a logarithmic curve you would end up getting much more noise than you would normally do otherwise 'cause the camera would save all the frequencies the sensor gets and especially in the blacks there are gonna be many more details than you would get with a classic SDR curve or even with an hybrid curve like HLG as the values are "lifted", making those completely logarithmic curves start much higher, so it's ok for you to try to compensate this on the camera side before getting to post-production just to play it safe.


I followed the same logic here when I set up my contraption. Blue filter to convert the contraption halogen bulb from 3200°K to 5600°K. To be seen as white by the sensor.
But is the FS7 sensor daylight? I am 90%sure but don't find the official information about that. Sensor is an EXMOR R CMOS...


Right. It should be correct, but could you try to record a bit without the blue filter just to see what the output is gonna look like? It might be that the camera is adjusting itself automatically, so we get the blue shift as the processing is applied twice.



Anyway, I guess the LUT to be used for 8mm/S8mm conversion via Slog3 also depends on the light source of the scanner/projector. Some use fixed temp LEDs, others RGB LEDs, halogen...


Absolutely.



Resolve LUT also gave crazy results. So, till now, I had to manually correct the colors levels and curves.


Yeah, I'm not surprised. The matrix created by the Blackmagic engineers is probably gonna follow the same logic as mine, so taking aside the personal taste, the basic mathematical implementation should be the same, so...


If you are interested, here (https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/5tVHzmKspSdFQ3n/download) is a more complete test file.
It contains various scenes.


I'm totally interested and I've seen that using Slog3 might be a bit of an overkill for those poor 8mm, 'cause there are no details whatsoever in the blacks and the whites are easily clipped out in the source. Especially in the blacks, in the scene where there's the rock in the water, underneath the rock, in the inner part of what looks like an inlet, there's... well... nothing, back then it was impossible for the camera sensor to record those frequencies (after all we're talking about analog technology from several years ago).
I'm gonna play with it a bit more, but not now 'cause I'm technically at work and I should really be working on our TV Series :P

'later ;)

[chmars]

It might be that the camera is adjusting itself automatically, so we get the blue shift as the processing is applied twice.

No. With Slog3 XAVC-I, the camera has no correction enabled.
Ok, I'll try to record the same footage with/without blue (asap but have few time atm).

I'm totally interested and I've seen that using Slog3 might be a bit of an overkill for those poor 8mm,

Great :-)
Yes Overkill, I know. My whole workflow is overkill also in resolution and compression terms, as I don't feel able to find the right limit. Afraid to miss something in tests to find the acceptable limit. Basically, I am a lighting guy, not a video freak :D

impossible for the camera sensor to record

IIRC, they were talking about...film...or something approaching :cool::p:D

I'm gonna play with it a bit more, but not now 'cause I'm technically at work and I should really be working on our TV Series :P
'later ;)
Great!

[FranceBB]

IIRC, they were talking about...film...or something approaching :cool::p:D

Yeah, it was shot on film, but I mean, it was impossible for the camera to capture enough nits and put them on that little piece of celluloid xD
I mean, I'm an engineer, but I'm still relatively young, so back when 8mm / Super 8 were a thing I wasn't even born and I don't really know much about their technology and how many stops the cameras had at the time, but I wouldn't be surprised if they turned out to have less than 6 stops (so less than the standard 100 nits SDR)...

[chmars]

Yeah, it was shot on film, but I mean, it was impossible for the camera to capture enough nits and put them on that little piece of celluloid xD
I mean, I'm an engineer, but I'm still relatively young, so back when 8mm / Super 8 were a thing I wasn't even born and I don't really know much about their technology and how many stops the cameras had at the time, but I wouldn't be surprised if they turned out to have less than 6 stops (so less than the standard 100 nits SDR)...

I was just teasing you :) you certainly know way more than me on those subjects.

Yes, the film was probably (almost) not exposed at this place.
I am capturing an image which dynamic is about half of the camera histogram. I pull it almost on the top of histogram as I understood there is more room to store information in the high light. Please correct me if I am wrong.
Anyways, film clips before the cam does. I mean, no details in shadows or light means it was clipped at exposure time (or, eventually because of under/over development).

[chmars]

... but could you try to record a bit without the blue filter just to see what the output is gonna look like?...


Done.
Quick and dirty color temp test only. (Whole capture setup stowed on a shelf cause dusty workshop ATM, might be not perfectly stable neither 100% sharp.)
But ok for light temp comparison.

https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/ziYXm4PgohyfkUd/download
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/ziYXm4PgohyfkUd/download

Two captures of the same footage. S-Log3/S-Gamut3:
1. "daylight"
2. "tungsten"

Light correction made with 1/1 CTB filter.
I compensated the filter removal by closing the iris by approx 1 F-stop.

Here are the frame accurate trimed-croped mov files. (https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/tZ8DlfXGyP7AW0L/download)
Here are the original files, with side (metadata?) files. (https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/eZuOozvxyxwDnQF/download)

--------------------------------------------------------------

Here, fore reference, a X-Rite Munsell Color chart clip (https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/yUZihjNMrf8afvC/download).
I think this can be helpfull to verify LUT.
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/yzPB4NLXgDUP3Dx/download
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/yzPB4NLXgDUP3Dx/download

--------------------------------------------------------------
EDIT:
I tested your S8 and non S8 LUTs on all these.
Works perfectly on the chart. Or?
On the captured footages, it behaves very strangely. Like if it would exaggerate the saturation. Blue is excessive on the 5600°K capture, Yellow-green is excessive on the 3200°K one.
I don't know phenomenon happens here?
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/t375pGdJZ3Uv47d/download
https://nmldqjct.preview.infomaniak.website/shared_files/index.php/s/t375pGdJZ3Uv47d/download

[FranceBB]

Alright, so I've grabbed the Tungsten one you made, namely MBGV0503.MXF and I tried to work my way around that.
I used both the PSST-CDL to reduce the blue and the ASC-CDL to bring the slope of the red from 1.00 to 1.63.
As to the knee, I made sure that the point in which is was going to be kneed down was Gray 18% + 8 stops to make it change concavity much more nicely, like so:

https://i.imgur.com/eXo5eGp.png
https://i.imgur.com/Qb1WMID.png


So I think I've got it right this time:

https://i.imgur.com/IRLKOll.png
https://i.imgur.com/x7gIQRL.png
https://i.imgur.com/LtvYUVr.png
https://i.imgur.com/UZNv189.png
https://i.imgur.com/DbyJiqe.png

however my fear is that it's gonna change and it's not gonna be static. I don't know if it's the nature of how things are in those kind of film or if it's the projector, but once it turns to another scene with another subject, like the trees, everything is different. I mean, it's really hard to get something done properly...
Try to apply it to the whole reel but I think it's not gonna be good (I mean the final result).
At this point I'm almost tempted to ask you one last attempt if the last LUT doesn't work: namely trying HLG, let the camera adjust itself dynamically and hope for the best. :(





Linear Transformation v1.6 Released! (https://github.com/FranceBB/LinearTransformation/releases)

- Fixed typo
- Improved Slog3 Super 8 to BT709
- Got rid of the "Linear" voice in front of the regular SDR curve like BT601, BT709 and BT2020

The new syntax is like:

LinearTransformation(Input="SLog3_Super8", Output="BT709")

[chmars]

At this point I'm almost tempted to ask you one last attempt if the last LUT doesn't work: namely trying HLG, let the camera adjust itself dynamically and hope for the best. :(

Yes, I could do what you need but I'm afraid camera auto-adjust will not work. The system will gonna turn crazy with this huge black borders and this flashing blue LED.
Too bad there is not yet an embedded version of Avisynth to allow treating only one part of the frame!

Film is always different.
Film was changing a lot. every batch of reels had its curve, colors (little changes, but still)... If you add exposure errors and age, you get a nightmare.

When we use to shoot in film for features, they always asked to get the same batch to avoid testing again and again to know exactly how to expose.

If some characteristics common to all films exist, the LUT must be limited to those (probably your original Slog3-LUT?). The rest is to be made by hand or automatic filters.
Maybe would VideoFred or JohnMeyer have some clever suggestions...

One point I don't get: why applying the LUT seems to turn to a so unstable result, exaggerating sometimes the yellow-green, sometimes the blue?

[FranceBB]

Yes, I could do what you need but I'm afraid camera auto-adjust will not work. The system will gonna turn crazy with this huge black borders and this flashing blue LED.


Right, there's also that LED that will screw things up... :(



Film is always different.
Film was changing a lot. every batch of reels had its curve, colors (little changes, but still)... If you add exposure errors and age, you get a nightmare.


I see...




If some characteristics common to all films exist, the LUT must be limited to those (probably your original Slog3-LUT?). The rest is to be made by hand or automatic filters.


Yeah, it's constantly changing, there isn't much I can do.
I was trying to make a comparison with this:


FFVideoSource("Super8_Slog3_AppleProRes.mov")
original=Subtitle("Original Analog Super8 film", size=60)

p0=FreezeFrame(0, 1, 0).Trim(0, 1).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(64, 0.40, 940, 64, 940, coring=false)
p1=trim(1, 344).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1)
p2=trim(345, 717).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(64, 0.20, 940, 64, 940, coring=false)
p3=trim(718, 1400).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1)
p4=trim(1401, 1451).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().tweak(hue=-4, dither=true).ConvertBits(bits=10, dither=1)
p5=trim(1452, 1599).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(200, 1, 810, 64, 940, coring=false)
p6=trim(1600, 1772).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(200, 1, 810, 64, 940, coring=false)
p7=trim(1773, 2344).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(200, 1, 810, 64, 940, coring=false)
p8=trim(2345, 2504).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(64, 0.40, 900, 64, 940, coring=false).tweak(sat=1.81, dither=true)
p9=trim(2505, 2634).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(64, 1.0, 800, 64, 940, coring=false).tweak(hue=-24, dither=true)
p10=trim(2635, 3204).ConvertBits(16).ConverttoPlanarRGB().Cube("Slog3_to_BT709.cube").ConverttoYUV422().ConvertBits(bits=10, dither=1).Levels(64, 0.40, 940, 64, 940, coring=false).ColorYUV(autogain=true, autowhite=true).tweak(sat=1.81, dither=true)

p0++p1++p2++p3++p4++p5++p6++p7++p8++p9++p10

Crop(90, 20, -20, -0)

SpotLess(RadT=16, ThSAD=1000000, ThSAD2=1000000, pel=2, chroma=false, BlkSz=64, Olap=4, tm=false, glob=false, bBlur=0.0)
SpotLess()

super = MSuper(pel=2, sharp=1)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super,bv1,fv1,bv2,fv2,thSADC=1400, thSAD=1400)

SpotLess()

dfttest(sigma=64, tbsize=1, lsb_in=false, lsb=false, Y=true, U=true, V=true, opt=0, dither=0)


FrostyBorders(1650, 1150, frosty=false)
Subtitle("Digital Avisynth Remaster", size=60)
filtered=last

StackHorizontal(original, filtered)
first=last

waveform=TurnRight.Histogram.TurnLeft.Crop(0, 0, -0, -1150).Spline64Resize(3300, 706)

StackVertical(waveform, first)

FrostyBorders(3840, 2160, frosty=false)


and it's encoding at the whopping speed of 0.04fps on a 56c/112th at 7% CPU usage.
1 Day and 2 hours remaining... DX



Maybe would VideoFred or JohnMeyer have some clever suggestions...



They're definitely more expert than me in terms of Remastering old reels. They're the masters of Remastering. They were doing this long before I was, so maybe they're gonna have a trick or two for us, I don't know. :P



One point I don't get: why applying the LUT seems to turn to a so unstable result, exaggerating sometimes the yellow-green, sometimes the blue?

'cause the input is unstable, it constantly changes, it's incredibly hard to work with!
It's really really hard when you have each "cut" different from the other. In your sample I had to divide it in 10 parts and threat each one of them individually in a different way 'cause otherwise I would have got some pretty bad results.
On top of that, the results I've got in the end are far from being great as I should have opened Davinci Resolve and played with them a bit, but I didn't want to and since I was doing everything in Avisynth I ended up with a compromise.
Anyway, I'll send you the results just for curiosity.
At least I'm happy about one thing, though: SpotLess() got rid of (almost) all the spots. :D

[chmars]

Yumy, rich answer!

If I dare: I am afraid we might spread our minds all over and loose our point if we talk about spot removal, stabilisation, denoising, etc.
However, I am very curious to see your results color-wise, sure, but also about your cleaning approach, frosty borders...

Only some words...
[Off topic parenthesis begin]
Just to explain: Alone, Spotless eats parts of moving subjects (balls, feet, hands...). It needs a colleague to bring them back.
A whole study was made in this thread (https://forum.doom9.org/showthread.php?t=182831) about spot removal (and, somehow, grain keeping).
Brilliant results thanks to Stainlesss with Spotless and Zorr with Delta Restore. Really efficient and impressing. The flavour I use and now tested a lot is here (https://forum.doom9.org/showthread.php?p=1946031#post1946031).
Here, you can see an example (Zorr) of what Spotless removed and what Delta Restore bought back:
https://i.postimg.cc/Gm826khp/dark-mask-v2.gifd
You know that place, don't you? ;)

[Off topic parenthesis end]

the results I've got in the end are far from being great as I should have opened Davinci Resolve and played with them a bit, but I didn't want to and since I was doing everything in Avisynth I ended up with a compromise.

Yes, I had great results with DR but it is totally anti-productive for such a task. I know John also uses an NLE to grade sometimes.
It would really be great having a tool that automates some part of the work like Fred/John scripts do but a bit further ifever possible.

I tried with Gammac and Autolevels.
Major problem is that Gammac will also correct the sky, sea or grass color when they fill the whole image.
Maybe, good approach would be to have one correction mixing all the scenes, plus one scene-by-scene correction. And percentages to balance these two corrections.
Well, off again....

Still: By looking at the scenes differences with the projector on a screen, differences are not so extreme as when LUT is applied on the capture. I am sure there is something to understand here.
Just intuition. No tools, no knowledge. Maybe you could see some moment in the process where colors go crazy?

[FranceBB]

Released Linear Transformation v1.7 (https://github.com/FranceBB/LinearTransformation/releases)


Changelog:

- Added support for ZLog2 HDR to BT709 SDR 100 nits


Full Screen Pictures: ZLog2 HDR (https://i.imgur.com/3OXYddV.png) - BT709 SDR (https://i.imgur.com/L9GU2QQ.png)

Comparison:

https://i.imgur.com/wOOdIb4.png
https://i.imgur.com/NzxlprK.png

Waveform:

https://i.imgur.com/morBVGB.png

Plotted matrix of transformation with In and Out:

https://i.imgur.com/pBC0YSQ.png

[FranceBB]

I'm gonna take the chance to post a conversation occurred in PM with a user.

So basically they've asked my opinion for a BT2020 UHD stream and I noticed that the color transfer was set to BT2020, which means BT2020 SDR 100 nits, however the user was concerned about the possibility that it could have been an HDR HLG stream.

Original Picture: https://i.imgur.com/NbxFvXN.jpg


So, I indexed the stream to take a look at it and... Oh my God, what a mess they've done...

I gotta say that I don't know SK 4K as a channel, but they've done a mess.

See here:

https://i.imgur.com/fcJpEQn.png

In the middle you see those "arcs" and then straight line. Those are in the middle, namely in the 3.18 Y HLG relative value. In other words, that's the peak for reference white in HLG, in fact if you look at the bottom, this should be white:

https://i.imgur.com/YODOSjl.png


So far so good, 'cause we would think that it's just a stream tagged wrongly and we can just easily tag it as arib-std-b67, so HLG in color transfer and that's it, right?

WRONG!

THIS is where they screwed up:

https://i.imgur.com/JI63qKF.png

They overlayed a BT2020 SDR 100 nits logo in a BT2020 HLG stream!!
You can't do that, of course, in fact the waveform skyrockets to 940 as it shouldn't...

Now, this is the original picture: https://i.imgur.com/NbxFvXN.jpg

This is what TVs get with the "wrong" BT2020 SDR 100 nits flag (as they're currently airing): https://i.imgur.com/3YfmBY9.jpg


And this is what you would get with the BT2020 HLG HDR flag (as they should be airing): https://i.imgur.com/WN9S2b0.jpg

Of course, by doing that the TV will have to compensate the logo as it's not HLG and has therefore the wrong values...

[FranceBB]

2021, what a year we're living in: a year in which users are now responsible to set the right frame properties themselves ehehehehehe

https://i.imgur.com/KtaDiIi.png

[FranceBB]

Linear Transformation v1.8 Released!!


Changelog:

- Introduced frame properties support for Avisynth 3.7.1


https://github.com/FranceBB/LinearTransformation/releases

[MaxLt]

Is this something I can use to "convert" HLG video to PQ?

Via some unusual events, I ended up with dozens of short HLG 10-bit videos that look exactly as needed on equipment that supports HLG correctly. So I do not need to colour grade them or edit them - the goal is to keep them looking as close to the way they do now but be compatible. I'd like to try to convert them to PQ because PQ videos display correctly on all equipment I have, and if that fails, convert them to SDR.

I tried doing it in Davinci Resolve with just one video (without these LUTs), and it seems to work very well. But ideally, I'd be able to do it in a batch with FFMpeg. I batch transcode them to the needed bitrate via FFMpeg anyway, so if I can also convert to PQ in that step, it would be ideal. Am I on the right track?

[FranceBB]

ideally, I'd be able to do it in a batch with FFMpeg. I batch transcode them to the needed bitrate via FFMpeg anyway, so if I can also convert to PQ in that step, it would be ideal. Am I on the right track?

Definitely. You can totally use my LUTs to go from HLG to PQ, either by using LinearTransformation() in Avisynth or by applying the LUT directly from FFMpeg. Additionally, if you need something that takes care of automatic encoding and works with both Avisynth and FFMpeg, you might wanna check our product: FFAStrans. It's free and available for everyone to use and it's the one that is handling the encoding of the overwhelming majority of contents here at Sky.
I think that FFAStrans is what you're looking for ;)

https://ffastrans.com/wp/

[MaxLt]

I think that FFAStrans is what you're looking for ;)

https://ffastrans.com/wp/

Thank you! Just tried it, and my mind is blown. It is exactly what I need if I can make it work. So far the PQ result is too dark for some reason (and I cannot figure out how to use CRF rather than fixed bit rate with HEVC output module there, which would be a good option to have but not critical).

I seem to have been able to localize the cause of dark image to the 2020 HLG -> 2100 PQ linear transform filter. Using all the same settings for PQ but BT709 source and BT709->PQ linear transform works fine. Similarly, using 2020 HLG source with HLG to BT709 transform works fine. Only 2020 HLG to 2100 PQ produces a very dark image but with correct colors (white is about the level of SDR white and shadows are all near black). Either there is a bug or I'm doing something wrong. I will try directly with FFMpeg, but I have difficulty figuring out the command line parameters there.

[FranceBB]

Thank you! Just tried it, and my mind is blown. It is exactly what I need if I can make it work.

Perfect. :)


So far the PQ result is too dark for some reason


This is weird.


I seem to have been able to localize the cause of dark image to the 2020 HLG -> 2100 PQ linear transform filter. Using all the same settings for PQ but BT709 source and BT709->PQ linear transform works fine. Similarly, using 2020 HLG source with HLG to BT709 transform works fine. Only 2020 HLG to 2100 PQ produces a very dark image but with correct colors (white is about the level of SDR white and shadows are all near black). Either there is a bug or I'm doing something wrong. I will try directly with FFMpeg, but I have difficulty figuring out the command line parameters there.


Perhaps you found a bug.
Can you please check this build: Link (https://onedrive.live.com/?authkey=%21AssQd1UcoAirKwU&id=A2FB73D8F2992944%21373799&cid=A2FB73D8F2992944)

and do a simple test with: Watch -> Encoder

and choose Auto LUT in the encoder?

If it still doesn't work correctly, then I'm gonna have to ask you to provide me privately a very small sample to work with.

[MaxLt]

I tried the new build and also tried with FFMpeg directly with just commend (to remove possible issues) and got the same result in every case. I'll upload the source and result samples and PM a link to it later today. Thanks for all your help!

[MaxLt]

I figured it out, I think. The LUT is for BBC HLG and what I had was "base HLG". I was able to generate a LUT that worked well with this tool: https://cameramanben.github.io/LUTCalc/LUTCalc/index.html

[FranceBB]

That's totally fine, no problem.
You can apply a custom Avisynth Script within FFAStrans and apply your custom LUT just as easily ;)

[wswartzendruber]

What is the difference between "BBC HLG" and "Base HLG?"

I know that in the early days, HLG had the reference white put at 0.5. Now the ITU has come along and put it at 0.75. Is that the difference between them?

[MaxLt]

What is the difference between "BBC HLG" and "Base HLG?"

I know that in the early days, HLG had the reference white put at 0.5. Now the ITU has come along and put it at 0.75. Is that the difference between them?

Yes, the "Spec Base/NHK HLG" white is 6 stops above neutral and "BBC HLG" is 4.5 stops above neutral. The red line here is Spec Base and the blue line is BBC. I'm surprised how few sources even mention this difference. Sony cameras seem to output the "Spec base/NHK HLG" with the brighter white point.

[wswartzendruber]

Yes, the "Spec Base/NHK HLG" white is 6 stops above neutral and "BBC HLG" is 4.5 stops above neutral. The red line here is Spec Base and the blue line is BBC. I'm surprised how few sources even mention this difference. Sony cameras seem to output the "Spec base/NHK HLG" with the brighter white point.
I think of these two as being labelled "ARIB STD-B67" (reference white = 0.5) and "ITU-R BT.2408" (reference white = 0.75).

Am I right in assuming that BT.2408 is the norm?

[FranceBB]

Sony cameras seem to output the "Spec base/NHK HLG" with the brighter white point.

Of course, Japanese people are playing at home with Sony Cameras ehehehehehe

I think of these two as being labelled "ARIB STD-B67" (reference white = 0.5) and "ITU-R BT.2408" (reference white = 0.75).

Am I right in assuming that BT.2408 is the norm?

Not here. Over here, we definitely use arib-std-b67 and we follow BBC Specs.

[wswartzendruber]

Not here. Over here, we definitely use arib-std-b67 and we follow BBC Specs.
You guys are putting reference white at 0.5? Because that's what ARIB STD-B67 calls for. At least on the copy I read.

[FranceBB]

You guys are putting reference white at 0.5? Because that's what ARIB STD-B67 calls for. At least on the copy I read.

Yes, definitely.

[wswartzendruber]

Oh for crying out loud!!!

I've got more to ask, but will do so in the that HDR10-to-HLG thread in this same forum.

[FranceBB]

Linear Transformation v1.9 Released! (https://github.com/FranceBB/LinearTransformation/releases)



- Following 75% ref white BBC Spec and assuming 1000 nits PQ all the time for PQ to HLG conversion
- Improved precision with 3D 65 size PQ to HLG conversion

In case you were wondering, it all came out from this: https://forum.doom9.org/showthread.php?p=1960698#post1960698

[Selur]

Small feedback:
I like the dvhe0509_to_BT709.cube, which works fine for some DV files,
using:

clip = core.resize.Bicubic(clip=clip, format=vs.RGB30, matrix_in_s="2020ncl", range_s="limited")
# color adjustment using TimeCube
clip = core.timecube.Cube(clip=clip, cube="I:/Hybrid/64bit/vsfilters/ColorFilter/TimeCube/dvhe0509_to_BT709.cube")

the color is off with the NASA file from https://www.demolandia.net/4k-video-test/dolby-vision/page-2.html which can be clearly seen when looking at the parts where the sun is shown.
It's identified by MediaInfo as "Dolby Vision, Version 1.0, dvhe.05.09, BL+RPU", same as the "LG Amaze Dolby Vision UHD 4K Demo" and the "LG Earth Dolby Vision UHD 4K Demo" files.
Since I don't really have DV content it's not really an issue for me, but I wanted to let you know that there is still room for improvement. ;)

Cu Selur

[FranceBB]

Yeah there's definitely room for improvement and I also promised you that I was gonna take a look at the colour bars, but I really didn't have time as I'm fighting against muxing .STL subtitles in .MXF as vbi_vanc_smpte_436m. If I can get that sorted tomorrow or in the coming days, I'll take a look at this again, I swear.

[FranceBB]

One of my retired colleagues named Livio Aloja (algie on Doom9) is working on it and he's getting closer, but not quite.

Top: original dvhe0509, Middle: LUT BT709 SDR, Bottom: Official Dolby Vision Decoder

https://i.imgur.com/Nk8kcju.png
https://i.imgur.com/NMf90Gj.png
https://i.imgur.com/mKa5vZc.png

[quietvoid]

Isn't it pointless unless the LUT is regenerated when the reshaping metadata changes?
Not sure what's currently being attempted, but a single LUT will never work properly.

The color mapping should be the same, though.

[wswartzendruber]

Isn't it pointless unless the LUT is regenerated when the reshaping metadata changes?
Not sure what's currently being attempted, but a single LUT will never work properly.

The color mapping should be the same, though.
Are you talking about the whole collection? There's plenty in here that makes sense to have in a LUT. Namely:

1. BT.601 to BT.709
2. BT.2100 HLG to BT.601
3. BT.2100 HLG to BT.709

...and the inverses of all of these.

EDIT: I have written a utility that generates a LUT for converting PQ to HLG based on reference white adjustment and MaxCLL.

https://github.com/wswartzendruber/hlg-tools

[nevcairiel]

Are you talking about the whole collection?

No, just Dolby Vision. It has a lot of metadata that impacts the image, which makes a single 3DLUT practically impossible, as those properties can change from scene to scene even.

[FranceBB]

No, just Dolby Vision. It has a lot of metadata that impacts the image, which makes a single 3DLUT practically impossible, as those properties can change from scene to scene even.

Yes but they affect luma not chroma.
The attempt is to get chroma right here, guys.
The user can then do whatever he wants with luma as I'm leaving it sort of flat.

[wswartzendruber]

Is there anything like a 4D LUT where we can define different tables for different durations?