quality while converting RGB-YUV

[taigi]

Am I losing much quality converting video:
from YUV420 to YUV420P16
and
from RGB(some numbers) to YUV(some numbers)?
Converting because have no other option than one proposed by h.264.
Thanks.

[jagabo]

There should be no losses with YUV420 to YUV420P16. What are you using to convert? What are you using to view the results?

8 bit (per channel) RGB to 8 bit (per channel) YUV will lose a lot of precision. Because 8 bit limited range YUV has only about 1/6 as many colors that map to valid RGB values. So yes, you expect losses there -- smooth gradients will become posterized.

[Selur]

You naturally will lose information when lowering the color sampling or bit depth (assuming there is information to lose).
you might want to read https://en.wikipedia.org/wiki/Chroma_subsampling to understand what the sampling numbers in YUV mean,...

[taigi]

What are you using to convert? What are you using to view the results?

Using VirtualDub2 h.264 for convert, VLC or MC(something) to view.

[jagabo]

What are you doing in VirtualDub2? What codec are you saving with? You should upload a small sample of your source and the encoded video. So we can see the problem.

[taigi]

What are you doing in VirtualDub2? What codec are you saving with? You should upload a small sample of your source and the encoded video. So we can see the problem.

Using AviSynth through VirtualDub, running some scripts, saving with h.264. Original was 8bit, I'm saving 10bit. There's no big issue with THIS process, there will be a question with another one.

[jagabo]

Using AviSynth through VirtualDub, running some scripts, saving with h.264. Original was 8bit, I'm saving 10bit. There's no big issue with THIS process, there will be a question with another one.

Then why aren't you providing information about the process with the problem? How is anybody going to help you if you don't provide the right information?

[_Al_]

yes, as was said, changing bitdepth should do nothing, IF there was no processing in between or something, look at some green YUV values for example and their rgb preview values, they are the same except rounding errors, YUV420P8 is changed to YUV420P16:

[taigi]

Another process converts video from 8bit to 10bit, from RGBA32 to YUV420P16.
Am I losing much this way?
Converting to have some scripts used. AS through VD2, to h.264.
Thanks.

Then why aren't you providing information about the process with the problem?

Because I have two of them running that are connected with this question.

[taigi]

--

[_Al_]

Another process converts video from 8bit to 10bit, from RGBA32 to YUV420P16.
Am I losing much this way?

P16 is 16bit not 10bit
Not sure if it hurts an image, RGB cube is entirely within YUV cube. As long you do not convert down again to 8bit YUV. Rounding errors apply. But I assume you change syntax to 10bit (P10). Also not sure how you got that RGB in the first place. If from YUV then it is not optimal.

You can compare 8bit PNGs made from RGB 8bit and converted YUV420P16:

[jagabo]

Those difference are probably due to the way the YUV data was converted to RGB to make the images. If you convert the 16 bit YUV back to 8 bit YUV you'll probably exactly the same values back.

[taigi]

P16 is 16bit not 10bit:

I mean Bit depth - converting from 8 bits to 10 bit. Not sure is this gonna affect color questions.

[Selur]

RGBA32 to YUV420P16

the conversion from 8bit to a higher bit depth should not cause information loss.
When going from RGBA to YUV obviously, you will lose the complete alpha channel.
When going from RGB to 4:2:0 you also lose information due to the sampling. Read the link I posted before.

[taigi]

Can conversion from 8bit to 10bit compensate RGBA32 to YUV420P16?

[Selur]

Can conversion from 8bit to 10bit compensate RGBA32 to YUV420P16?

"RGBA32 to YUV420P16" is a conversion from 8bit RGB+Alpha to 16bit YUV 4:2:0.
Additional precision (8->16) has nothing to do with the alpha channel or the color sampling.
And instead of using 16bit using 10bit will not change anything regarding the alpha channel or the color sampling either.

[taigi]

I am doing this because I'm fighting overly dark footage with this great script provided by themaster1:

Code:
AVISource("snippetOfDark.avi")
hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadow s=true,corrector=0.8,reducer=1.6)
ConvertToYV16(interlaced=true)
SpotLessUV()
ConverttoRGB32(matrix="rec709",interlaced=false)

Is it logical what I do?
Video original: https://forum.videohelp.com/attachments/58884-1621050046/snippetOfDark.avi

[Selur]

That file uses 10bit 4:2:0 and is progressive.
Looking at the script,..

AVISource("snippetOfDark.avi")

Not sure why you would use AviSource, personally I would use:

LWLibavVideoSource("snippetOfDark.avi",cache=false,format="YUV420P16", prefer_hw=0)

to avoid the dependency to vfw decoders.

hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadows=true,corrector=0.8,reducer=1.6)

changes the color, okay.

ConvertToYV16(interlaced=true) <- Makes no sense to me at all.

a. why use interlaced = true when your source is progressive?
b. why convert to YV16 to begin with, SpotLessUV works fine on YV12 content

ConverttoRGB32(matrix="rec709",interlaced=false)

Why convert to RGB32 ? Why convert to RGB and why add an empty alpha channel?

-> Assuming that is the whole script, the whole color conversion make no sense to me.
So I would answer "Is it logical what I do?" with "No, not to me."


Cu Selur

[taigi]

Thanks, good analysis.

[_Al_]

I mean Bit depth

10bit is bit depth P8 is 8bit, P10 is 10 bit, P16 is 16bits vapoursynth marks it that way even 8bit video for example YUV420P8. Avisytnh just uses YV12 but you do not know how many bits it is, it is assumed 8bit, because that what Avisynth is using. YV16 is 422 subsampling but not necessarily 16 bits, it could be 8 to 16 bits. Latest Avisynth+ , that should be used by now I guess instead of older Avisynth, picks up new format explicitly mentioning subpsampling and bitdepth, but not for all, old YV12 stays I guess, it is wide spread in scripts, so back compatibility must be preserved.

Comparison of Avisynth, Avisynth+ and Vapoursynth formats where you can find what bitdepth it has is here:
http://avisynth.nl/index.php/VapourSource

[taigi]

@Selur exactly now fighting to install LWLibavVideoSource.
Any help of what driver I would need?
Went through finding/installing libvlccore.dll, libavcodec_plugin.dll...
Still "There is no function named "LWLibavVideoSource".
Running this one on 32 system.
Thank you.

[jagabo]

LSMASH: http://avisynth.nl/index.php/LSMASHSource

[taigi]

LSMASH: http://avisynth.nl/index.php/LSMASHSource

Already have this one, the error message is still the same.

[jagabo]

LSMASH: http://avisynth.nl/index.php/LSMASHSource

Already have this one, the error message is still the same.

You probably installed the wrong one (64 bit vs. 32 bit). Try loading it manually -- you will get an error message telling you what's wrong.

LoadPlugin("C:\Path\to\LSMASHSource.dll")

[taigi]

LoadPlugin("C:\Path\to\LSMASHSource.dll")

Now error message reads: "Platform returned code 127"

[jagabo]

Post your entire script.

[taigi]

Script would be like this:

FFmpegSource2("00014.MTS", atrack=1)
hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadow s=true,corrector=0.8,reducer=1.6)
SpotLessUV()

[jagabo]

Why are you posting a script using FFmpegSource2 when you said you were trying to use LWlibavVideoSource?

[taigi]

Sorry. This one:

LWLibavVideoSource("00014.MTS",cache=false,format= "YUV420P16",prefer_hw=0)
hdragc(coef_gain=10.0,max_sat=3.0,protect=2,shadow s=true,corrector=0.8,reducer=1.6)
SpotLessUV()

[jagabo]

Why aren't you loading the dll file as I suggested? What program are you using to open the AVS script? 32 bit or 64 bit? Try using VirtualDub2. It will probably give you more informative error messages.