Converting a video from 8-bit to 10-bit color

[magnetite]

I have a question about converting a video from 8-bit to 10-bit color. Can you use the output depth parameter from Avidemux to change it to 10 bit with x265? Or do I also have to apply the ConvertBits(10) from Avisynth+ to it as well?

This kind of fits into two categories of forums, so I wasn't sure which one to post it in.

[Emulgator]

Worth considering: Once you decide to use algos like SmoothCurve16() within AviSynth you obtain 16-bit data.
Other AI stuff or feisty2 algos even work in 32bit, so once generating HBD data you keep it as such within AviSynth.
These lesser significant bits are meaningful bits now, only at the end, just before encoding you would call ConvertBits(10).
It would make not much sense only to ConvertBits(10) from 8-bit-data, dithering aside.

[magnetite]

The original source videos were recorded in 10-bit HDR, but due to the limitations of the video editing program I was using, that extra color information was lost during the encoding process.

I went searching for an updated version of Avidemux a few hours after I made this post and couldn't find one on their main site. So I went to check if there was any beta builds, and they did have one which included 10-bit HDR encoding.

[tormento]

Originally Posted by Emulgator

use algos like SmoothCurve16()

For normal use, i.e. just converting to HBD, what is the advantage over a plain z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv420p16")?

I tried many times AIUpscale too but I have some issues with color coherence, i.e. I almost always have small variation from the original.

[Emulgator]

z_ConvertFormat is fine, Smooth() algos mean no advantage if you aim at "just converting to 10bit".
Advantage only if algos are involved that will populate the 2 new LSB with "meaningful" bits, aside from dithering, the latter can roughly be compared to adding noise.
Just run Smoothadjust16 on a B/W clip with a tiny Y-curve dip like SmoothCurve16(ConvertTo16bit().ConvertToStacked()...,forget to #ConvertFromStacked() at the end,
activate debug and you will see the green LSB plane populated with usefully interpolated shades of new LSB bits 8 and 9.
On a second note: AI color shifts I can confirm with Topaz, there it boils down to lifted Y, thereby losing lome saturation in the darks.
Can be mended easily afterwards while still operating in 10 bit, UHD-BD being the goal here.

[FranceBB]

Yes, Emulgator is right.
To put what he said in practical terms, here's a picture of a cat in yv24 so 4:4:4 8bit:



Here's what happens when I use

Dither_convert_8_to_16()

We're now in 16bit stacked which is formed by 8bit MSB (top) + 8bit LSB (bottom), which is why it's also called "double height" as opposed to 16bit interleaved which is "double width" and the MSB/LSB are "interleaved" together. As you can see, the lower part of the image is completely uniform, so just green without anything in terms of different values, which means that it's full of 0 (i.e completely empty). This is because the original bit depth was 8bit so by converting it to 16bit stacked we haven't really improved it, we've just added zeroes, lots of them. On the other hand, as soon as I use any filter that is high bit depth capable (in this case f3kdb in 16bit stacked mode) this is gonna change:

f3kdb(range=15, Y=45, Cb=30, Cr=30, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, mt=true, keep_tv_range=true, input_mode=1, input_depth=16, output_mode=1, output_depth=16)

As you can see, the 8bit LSB at the bottom is now populated because f3kdb (a debanding filter) made use of the 16bit precision to perform its calculation. This means that by working with 16bit stacked precision we actually achieved a better result with more precise calculations than we would have had with just 8bit precision.


In other words, the idea is to:

1) Index
2) Convert to 16bit (planar, stacked or interleaved)
3) Perform all the filtering with 16bit precision (planar, stacked or interleaved)
4) Dither down to the output bit depth and feed the encoder


Going back to the original poster question, if you're just converting to 10bit but you're not doing any additional post-processing, then you're not gonna have any benefit than just feeding the encoder with 8bit data 'cause the 2 additional bits in 10bit would be filled with zeroes. On the other hand, if you perform processing, then it's better to convert to high bit depth immediately and then dither down to the output.

On this last note, please note that both x264 and x265 can handle dithering on their own, so if you happen to be working with 16bit precision you can feed the encoder directly with 16bit data and it will work, however keep in mind that while x264 supports both 16bit interleaved and 16bit planar, it doesn't support 16bit stacked. In the same way, x265 only supports 16bit planar, so it's just better in general to output normal planar high bit depth rather than stacked or interleave these days.

[tormento]

Originally Posted by Emulgator

Can be mended easily afterwards while still operating in 10 bit

How?

P.S: I hate you for the small font, making me feel old.

[tormento]

Originally Posted by FranceBB

here's a picture of a cat

How many kibbles did it cost to you?

Originally Posted by FranceBB

then you're not gonna have any benefit

Of course I am converting it to HBD to have further processing. My question was IF using a standard resize function would be different than using SmoothCurve16 in terms of a better HBD result.

Originally Posted by FranceBB

both x264 and x265 can handle dithering on their own

I tested many times and I find separate dithering faster and more tunable, mostly by using fmtc_bitdepth.

[Emulgator]

small font, making me feel old.

Plus 4K on 17" here. Muuhahaha. I deserve such pain.

[FranceBB]

Originally Posted by tormento

if using a standard resize function would be different than using SmoothCurve16 in terms of a better HBD result.

Converting to high bith depth will be the same because it doesn't matter if it's ConvertBits(), z_convertformat() or SmoothCurve16(), all they're doing is just adding zeros, so none of them can add zeros better than the other, they're just zeros.

Converting from high bit depth is a different matter as each one of them dithers in a different way. SmoothAdjust lets you "adjust" the parameters including the dithering strength, while ConvertBits() and z_convertformat() only allow you to choose the dithering algorithm. Whether you prefer one to the other is a personal taste.

[kolak]

Originally Posted by magnetite

I have a question about converting a video from 8-bit to 10-bit color. Can you use the output depth parameter from Avidemux to change it to 10 bit with x265? Or do I also have to apply the ConvertBits(10) from Avisynth+ to it as well?

This kind of fits into two categories of forums, so I wasn't sure which one to post it in.

You won't gain much. Once 10bit precision is lost, recovering and making it up is not easy in real world. Technicolor use to have a filter for it, but this it's all with limitations.
You can try mentioned tools, but don't expect miracles.