FFAStrans forum

Hi,

Noticed there is now a broadcast colour limiter filter which is great!

Wondering if there is a way to also limit RGB Gamut levels that Vidchecker Post looks for in our template?

RGB Gamut
RGB level limits: 64-943 ± 5%

Thanks.

Hi Graham,

10bit setting sets it to min_luma=64, max_luma=940, min_chroma=64, max_chroma=940
Doesnt that fulfilll your needs?

Unfortunately not, Vidchecker checks for the below. I did a test with the limiter on. Whilst it didn't flag any issues with Luma Chroma it was failing the file for RGB Gamut. See attached the Vidchecker template.

in that case @FranceBB will be happy to comment on the intentions of his plugin and provide you some options how you can get to your goal

Safe Color Limiter is a "limiter" which means that it limits luma and chroma to be within the limited tv range for each and every bit depth, ranging from 8bit planar all the way up to 32bit float.

In other words,
8bit sources will be limited to 16 - 235 luma and 16 - 240 chroma
10bit sources will be limited to 64 - 940 luma and 64 - 960 chroma
12bit sources will be limited to 256 - 3760 luma and 256 - 3840 chroma
14bit sources will be limited to 1024 - 15040 luma and 1024 - 15360 chroma
16bit sources will be limited to 4096 - 60160 luma and 4096 - 61440 chroma
32bit sources will be limited to 16/255.0 - 235/255.0 luma and -112/255.0 - -112/255.0 - 112/255.0 chroma



Now, clipping values makes luma legal, but it's not the same for chroma.
For instance, it's entirely possible to have 16-240 chroma in 8bit, which is made of legal values, but it's represented as out of range in the scope.
The reason for this is relative to the intensity and not the code values in which the signal spans, in fact if you take this 12bit input (sorry Emcodem, I'm reusing the sample you sent me ages ago):



we can see that luma is slightly lower than 256, sitting at around 210, so, it's slightly out of range, and chroma slightly above 3935, so it's out of range as it's supposed to be 3840, however, if I limit the values to


(which is what FFAStrans would do since it uses this function I made https://github.com/FranceBB/SafeColorLimiter)

the luma is gonna be in range but the chroma is still gonna be out of range, especially in the green component and it takes a
to bring it in range.



The fact is that, technically speaking, there's nothing wrong with the current Avisynth implementation of clipping, I mean, Limiter does what is supposed to do, namely limit the range to the correct values (in this case Limited TV Range), however, that is not enough for chroma as it not only has to be in that range in terms of values in which the signal is spanning, but it also has to be inside the 75% relative intensity as per standard, so it's still out of range despite being limited to span the correct values, which is what your AutoQC suite is "complaining" about.
To make your AutoQC suite happy you would need an implementation that can also de-saturate the input signal by a certain percentage according to the specs instead of just getting rid of the illegal values (which is what SafeColorLimiter() does).

In short, if i understand right, FranceBB suggests using a custom avisynth filter processor with the following content:

emcodem wrote: ↑Thu Nov 10, 2022 2:17 pm In short, if i understand right, FranceBB suggests using a custom avisynth filter processor with the following content:

Code: Select all

m_clip = tweak(m_clip, sat=0.90, dither=true) 
Return m_clip

That's exactly right, place it either before or after SafeColorLimiter in FFAStrans and it's gonna do the trick.

Hi,

Thanks so much for the very detailed help! Appreciated!

I had to adjust the values to 0.86 before vidchecker allowed the test file to pass without RGB warnings.

Can I confirm which way up the value is de-saturating the pictures? Higher or lower for de-saturating?

Thanks,
Michael

That sounds like a lot, don't you see a great huge change in the picture after doing 0.86 ? Could this be some full vs narrow range problem or similar? (e.g. input file is wrongly flagged narrow or some ffastrans internal problem )
Just thinking loud because in 8 bit at least, if 100% is full, 88% is narrow. That comes pretty close to your 0.86 (in case the saturation works kind of linear ) Might be on a totally wrong track here tough... because you limited the range already hmpf

Anyway, i don't have experience with the limiter so you can just ignore what i thought above I usually just take care that the source metadata is correctly interpreted by the transcoder so i usually dont need additional helpers. But i also never work with 10 bit nor have i got automated Gamut check activated...

sat>1.0 increases the saturation.
sat<1.0 reduces the saturation.

http://avisynth.nl/index.php/Tweak

Hi,

Yeah there is quite a shift with reds in particular.

I've attached before / after.

Having the filter set to .90 resulted in far less RGB gamut fails but it still flagged two instances. I've run a few tests and .86 is where vidchecker passes the file without issue.

I'm looking into this with FFastrans as we currently use a Premiere Plugin called i-Comply. This always results in a pass when used and there is very, very little difference in before/after when applied. However, this company has ceased trading - looking to future proof myself. The Premiere limiter also results in RGB Gamut fails from time to time.