Fake 4:4:4

[kolak]

Is there a way to say for sure if file was 4:2:2 at some point and then was exported to 4:4:4?

[StainlessS]

Maybe some inventive use of Avisynth SeparateColumns [on separate 4:4:4 chroma channels],
with something to split into even/odd columns and WeaveColumns and Subtract for comparision, with some Levels amplifier thingy too.
Above a bit vague, but do-able I think [although I dont know how].
I'm a bit busy doing multiple W10 setups at the moment.

SeparateColumns:- http://avisynth.nl/index.php/SeparateFields
WeaveColumns:- http://avisynth.nl/index.php/Weave

EDIT: "say for sure", maybe not for sure, unless even / odd always identical.
[Any lossless [EDIT: Lossy] encoding would of course make it mostly best-guess-work]

[kolak]

Source is ProRes444, so compression is not strong.
I see it on bars edges, which gives me obvious answer.
Problem is that it can be only bars, not the actual video :)

How would real 444->422 look compared to fake 444->422?
Any obvious, measurable difference?

[VoodooFX]

Theoretically:

v = LWLibAvVideoSource("D:\video444.mkv")
U = v.UToY8 # or VToY8
F = U.Spline16Resize(v.width /2, v.height).Spline16Resize(v.width, v.height)

If you see difference between U and F then it's not fake.
If you don't see difference between U and F then it's fake.

First do a test with a known real 4:4:4 video to check if you can see a difference. :)

[kolak]

Will Check.:thanks:

[kolak]

I can see big difference in case of 444 and tiny for 422 saved as 444 (looks like scaling side effects), so it suggest method is working :)
Need to do test on real footage, not just bars.

[VoodooFX]

I can see big difference in case of 444 and tiny for 422 saved as 444 (looks like scaling side effects), so it suggest method is working :)
Need to do test on real footage, not just bars.
On real footage you shouldn't see that "tiny" difference with a naked eye, and "big" probably won't be that big.

PS:
If you see a difference then it's definitely not fake.

[kolak]

Ok- going to create real 444 which I know is 444 and check.

Can't we add subtract filter to see difference ?
They are different sizes and it's not easy to say :)

Looks like I have other 444 file which is some mess - ProRes444, but mediainfo says 4:2:2 :) For this file U and F are different size.
Studios can't even supply proper 444 file :)
Need to create proper file myself.

[StainlessS]

Nice Solution VX.

[VoodooFX]

Can't we add subtract filter to see difference ?
Then you'll see some differences in both cases. :)
I never had problem with this kind of visual inspection, but I wasn't using it to check a chroma channel, so I only doubt about ability to see difference.
Once I met a guy who couldn't tell a difference between 4:3 <-> 16:9 distortions, go figure... :D

[kolak]

I have some real 444 file. I see small differences and U seems to be more "detailed (pixel perfect)". Is this correct ?

[VoodooFX]

I have some real 444 file. I see small differences and U seems to be more "detailed (pixel perfect)". Is this correct ?

Yep, that's what you are looking for.

[kolak]

And now I made fake 444 of it and I see "no difference".
It's not crazy easy to judge but once you know what to look for it's quite objective.

There must a be a way to make it more obvious :)

[kolak]

And my suspected file confirms to be fake 444.
Thank you a lot :)

[kolak]

What if we scaled it normal way and then keeping UV and scaling just Y and then compare both end results ?
Is this based on similar idea?

[VoodooFX]

There must a be a way to make it more obvious :)

Ask SssS for an upscale checking plugin/script, that would output subtitle with fake/not-fake info for every channel, should be easy to make. :D

What if we scaled it normal way and then keeping UV and scaling just Y and then compare both end results ?
Is this based on similar idea?
Then it would be hard to differentiate where you see luma or chroma difference.
If you use this method on whole video then it's good to check if it's upscale or not.

EDIT:
Misunderstood your question, if you don't do that scaling on UV then how and what you expect to compare then? You would see a luma difference and chroma would be uncomparable.

[kolak]

Ignore my idea- rather blind suggestion.
Your method works. It could be just somehow improved for easier judgment (but I think I have 99% confidence, which is fine).

[kolak]

Is type of scaling algorithm important?
I tried Point and then I cant' judge anymore :)

[VoodooFX]

Is type of scaling algorithm important?
I tried Point and then I cant' judge anymore :)
It's, Point is most unsuitable for this task.
Looks like SssS' RT_Stats has needed stuff to make calculations, so maybe later this weekend I'll write some func for auto-detection, now down to the pub... :)

[kolak]

Found it hard way :p

[kolak]

For CGI title difference is veeery obvious:

https://i.postimg.cc/y6QYYFZn/Untitled.png

[VoodooFX]

Just realized that I don't have real 4:4:4 and 4:2:2 clips to test, anyway some draft func I posted there (https://forum.doom9.org/showthread.php?t=184247), not for chroma testing yet. Could you share some real 4:4:4 clip[s]?

PS:
Please post there (https://forum.doom9.org/showthread.php?t=184247), I don't get notifications from this subforum...

[DTL]

"real 4:4:4 clip[s]?"

It can be easily created in AVS:


LoadPlugin("ResampleMT.dll")

function Ast2(clip c, int isize)
{
Subtitle(c, "R",font="Arial",size=isize,align=4,halo_color=$FF000000, text_color=$00e01010)
Subtitle(last, "G",font="Arial",size=isize,align=5,halo_color=$FF000000, text_color=$0010e010)
Subtitle(last, "B",font="Arial",size=isize,align=6,halo_color=$FF000000, text_color=$001010e0)

return last
}

BlankClip(100,2400,800,"RGB24",25)

Animate(last, 0,100,"Ast2", 70, 600)

AddBorders(100,100,100,100)
UserDefined2ResizeMT(width/10, height/10,b=90,c=-12)
ConvertToYV24() # 4:4:4 source is here = last

degraded=ConvertToYUV422().ConvertToYUV444()

StackVertical(last, degraded)

SincLin2ResizeMT(width*3, height*3, taps=8)


Frame 5
https://i5.imageban.ru/out/2022/07/13/dc690ef0f89fabf863cc7801a0262203.png

It shows G channel also degrades a bit.

Is there a way to say for sure if file was 4:2:2 at some point and then was exported to 4:4:4?

In 4:2:2 in addition to other ugly distortions of non-perfect current colour digital subsampled formats the bandwidth of UV is half in horizontal direction.

So one possible check is to convert to 4:2:2 and back to 4:4:4 and compare - if there will be no or very few degradation of H-colour resolution in mostly R and B channels - it mostly probably was in 4:2:2 at some point.

[kolak]

Easy when you have generated text over black background (best case scenario).
Try same with real footage- not so obvious anymore.


So one possible check is to convert to 4:2:2 and back to 4:4:4 and compare - if there will be no or very few degradation of H-colour resolution in mostly R and B channels - it mostly probably was in 4:2:2 at some point.

I think this is very similar to VoodooFX method.

[DTL]

"Try same with real footage"

To get real world 4:4:4 footage you first need 4:4:4 camera. It is typically film-scan or 3-chip or downscale from 8K..12K single chip cam to 4K or better to FullHD.

Also better to test on scene with small details red and blue objects.

Or the ugly nature of subsampled systems are best visible on 1->2-primaries transients like Green to Magenta (R+B), Red to Cyan (G+B), Blue to Yellow (R+G). So the colour-keying with Green background and some magenta saturated object will also create bad transient at subsampled system like 4:2:2. That cause not only colour sharpness and saturation losses but also significantly visible luma distortions at transients.

So only very complex non-linear convertors from 4:4:4 to subsampled may be Neural-networks based can only make some more or less low-distorted subsampled footage at least with low enough luma bugs. It is to be designed in the future of this civilization if it will not die too fast. Or may be finally the ugly subsampled 4:2:2 and 4:2:0 will die.

Here is with colour transients:

LoadPlugin("ResampleMT.dll")

function Ast2(clip c, int isize)
{
Subtitle(c, "R",font="Arial",size=isize,align=4,halo_color=$FF000000, text_color=$00e01010)
Subtitle(last, "G",font="Arial",size=isize,align=5,halo_color=$FF000000, text_color=$0010e010)
Subtitle(last, "B",font="Arial",size=isize,align=6,halo_color=$FF000000, text_color=$001010e0)

return last
}

RB_clip = BlankClip(100,800,800,"RGB24",25, color=$00e010e0)
GB_clip = BlankClip(100,800,800,"RGB24",25, color=$0010e0e0)
RG_clip = BlankClip(100,800,800,"RGB24",25, color=$00e0e010)

StackHorizontal(GB_clip, RB_clip, RG_clip)

Animate(last, 0,100,"Ast2", 70, 600)

AddBorders(100,100,100,100)
UserDefined2ResizeMT(width/10, height/10,b=125,c=-18)
ConvertToYV24()

degraded=ConvertToYUV422().ConvertToYUV444()

StackVertical(last, degraded)

SincLin2ResizeMT(width*3, height*3, taps=8)


Frame 20:
https://i5.imageban.ru/out/2022/07/13/ee8fdb6d8625186fe0ea89cd0d14d238.png

[huhn]

what's wrong with taking a computer game and making a screenshoot?

[kolak]

"Try same with real footage"

To get real world 4:4:4 footage you first need 4:4:4 camera. It is typically film-scan or 3-chip or downscale from 8K..12K single chip cam to 4K or better to FullHD.


This is the usage case. High-end masters which meant to be 444 and typically are done from RAW above UHD resolution assets.

You don't really need 8K to get UHD 444 from Bayer, do you?
Something like 1.6x oversampled (not sure where I read about it) should be enough.

How precisely do I use your script with real footage? Just this I assume:
degraded=ConvertToYUV422().ConvertToYUV444()
StackVertical(last, degraded)
SincLin2ResizeMT(width*3, height*3, taps=8)

[DTL]

"You don't really need 8K to get UHD 444 from Bayer, do you?"

Bayer is only close to 4:2:0 and also need additional antialias filtering to be less aliased and more MPEG-friendly. So it really a bit lower 4:2:0 in full chip resolution. To get about good 4:4:4 in full colour resolution it is typically required 3-chip shifted system or downsample from about 2x more resolution bayer. So 8K bayer -> 4K 4:4:4. 4K bayer -> FullHD 4:4:4 . Better case is 8K chip with good AA optical filter -> 4:4:4 FullHD.

"degraded=ConvertToYUV422().ConvertToYUV444()"

You can try simple


degraded=ConvertToYUV422().ConvertToYUV444()
Subtract(last, degraded)


Subtraction returns lost components from 4:4:4 -> 4:2:2 downsampling :
https://i1.imageban.ru/out/2022/07/13/5fdae95b0342b26e38418bb0f8278097.png

Why G-channel is also degrades significantly - not sure.

"High-end masters which meant to be 444"

May they have FX rendered in 4:4:4 or some subtitling. If they taken by low resolution single chip bayer-based camera it will have low colour resolution on many parts of frames. Not covered by FX and other true 4:4:4 overlay. Also complete 3D rendered scenes may be put as 4:4:4. If you shoot 70mm IMAX-like camera all movie and make good filmscan - it may be full movie as 4:4:4 for 4K. The 35-mm based shootings typically accepted as FullHD1080. Or may be special 3-chip cams upto 8K (like UHC-8300 sometime designed by NHK). I think typical movies up to 4K is some balance between 4:2:0 and a bit higher. But not up to full-res 4:4:4. So it is hard to find difference when trying to test 4:2:2 possible downsample in production chain.

" with real footage?"

It is also demonstrated with about real digital moving pictures footage.

If you like to test with some camera-content - take any and ConvertToRGB24().UserDefined2ResizeMT(width/5,height/5). It will simulate about perfect 4:4:4 digital moving pictures camera-produced footage in RGB. Or may be ConvertToYUV444().UserDefined2ResizeMT(width/5,height/5) for YUV. Progressive better, interlaced may be not as good. For better quality of simulation - use width/10, height/10. To view difference better on pixel-based PC monitor - place at the end of script upsampling like SincLin2ResizeMT(width*3, height*3, taps=8)

"Something like 1.6x oversampled "

To make perfectly sharp and good antialiased full-colour res 4:4:4 it shoud be 2.0+ oversampling at physical camera. May be 2.5..3+ . But most of todays use cases do not need full colour res footages - with real viewing cases it is typically enough to have 4:2:0.

So good broadcast-level antialiased 3-chip camera uses 1/2 sample diagonal chips shift and try to process internally at 2x resolution before final AA grading in digital form to output system resolution. With real good enough graded 4:4:4 output if required.

[kolak]

This won't work for real footage, so easily. It gets you to the same place as VoodooFX method, but his output is easier to judge.
Will check with extra scaling.

Not getting anywhere. Sticking with other method.

[DTL]

If your footage simply do not have enough colour data for 4:4:4 so it can be downconverted to 4:2:2 or 4:2:0 and back without significant losses. The first question is to make sure the 'initial 4:4:4' is really have enough data and not just some intermediate upsampled format. So it may be not Fake 4:4:4 because of somewhere in between being 4:2:2 - it may be not-4:4:4 from the beginning.

May be someone may make analysis with FFT-plugins to measure the power of components above 0.25 Fd in the UV channels (or simply put High-Pass brick-wall HPF with transient frequency about 0.25+ of Fd to UV planes and add contrast with Levels). Also make 'detection' and final logical result - if it 'true/false 4:4:4.

High-Pass with enough sharp transient may be as subtraction of SincResize(width/2, height, taps=20) from input.

So visual detector may be for 4:4:4 input to check: (for U channel)

u_clip=UtoY()
u_lpf=SincLin2ResizeMT(u_clip,width/2, height, taps=20)
u_lpf=SincLin2ResizeMT(u_lpf, u_lpf.width*2, u_lpf.height, taps=20)
Subtract(last.UtoY(), u_lpf)


*works not very perfectly but shows some difference between 4:4:4 and 4:4:4->4:2:2->4:4:4*

[kolak]

You never be sure 100%.
I just need to be able to flag potential issue with file not been 444.
With high-end productions main masters are 444. Sometimes in the chain they go to 422 and back to 444 ( due to poor procedures or sloppy work). These cases can be detected with quite high accuracy.

If I know title was shot with 6K+ sensor then I expect 444 to show difference to 422.
If I see bars which don’t have clean edges then this is a warning flag straight away.
It’s not about judging real chroma information, but fact if master went through 422 format and back to 444.

[kolak]

So visual detector may be for 4:4:4 input to check: (for U channel)

u_clip=UtoY()
u_lpf=SincLin2ResizeMT(u_clip,width/2, height, taps=20)
u_lpf=SincLin2ResizeMT(u_lpf, u_lpf.width*2, u_lpf.height, taps=20)
Subtract(last.UtoY(), u_lpf)


*works not very perfectly but shows some difference between 4:4:4 and 4:4:4->4:2:2->4:4:4*

This is about what I use now with VoodooFX method. Just no subtract but human visual judge by looking at 2 images. Works better than judging subtract (once you saw few examples).

[DTL]

" if master went through 422 format and back to 444."

It mean limiting H-bandwidth of chroma to 1/2 of full-band (or may be even adding some more aliasing if convertor was of poor design). May be even for anisotropic 4:2:2 a detector of UV-bandwidth spatial anisotropy is possible like:

If H and V UV spectrums are equal = it is 'as true as possible in this current usecase 4:4:4'
If H spectrum of UV is < V spectrum of UV = it mostly probably pass anisotropic 4:2:2.