8-bit log to linear 10-bit?

[anton_foy]

Hello!

I am using HDV 4:2:0 upscaled 1440x1080 50i to 1920x1080 25p footage.
Deinterlacing, denoising, HDR_AGC etc. in vdub and avisynth and encoding as Avid's 10-bit DNxHD 185 codec.

Is there any way to get as much information from the 8-bit source and maybe make it to 8-bit log, encode to 10 bit DnxHD and add a log to linear curve on the encoded 10-bit clip to get the most out of it? I am very unsure this would be a good way or even if it is possible. Any Ideas?

For the future of Avisynth I really would like to see it be capable of handling 10-bit or even higher with all the plugins and filters now existing.


Thanks!

[Sagekilla]

I don't see the point in going from 8-bit linear --> log --> 10-bit linear. It seems like straight 8-bit to 10-bit would make more sense.

[Blue_MiSfit]

It wouldn't look any better, I'm sure of it.

AviSynth will support lots of new color spaces soon, but that doesn't mean that all filters will automagically support those color spaces :(

~MiSfit

[anton_foy]

@bluemisfit & sagekilla

Yeah I agree with you totally, I was just wondering how to keep the most of the info from the 8-bit linear footage when encoding to 10-bit. Adding HDR_AGC, gradfun2db (for less visible posterization) , denoising and stuff will clean the image but I know making it real 10-bit is not possible. Though I want to keep as much information as possible to colour-grade it in 10-bit for later.

I really hope the plugins and filter authors rewrites them for 10-bits or higher in the future. :)

[Sagekilla]

Well if your footage in 8-bit has no issues with it to begin with, as in no posterization or banding effects, then you should have no problem when it gets converted to 10-bit. You'll simply have another 2 bits tacked on, with it being essentially the same exact data. But, when you do any editing like color grading that you just said, you have more precision to reduce artifacts from being introduced. No banding or posterization artifacts will be introduced when converting from 8-bit to 10-bit, and if you're not doing a lot of filtering with the colors to begin with you won't be getting any color artifacts.

The only time you really get artifacts of that nature is when you do tons of successive changes to the same frame over and over since you'll have rounding errors accumulating. IMO, if you're not doing applying a large series of effects per frame, there's no point going to 10-bit.

[Mug Funky]

i think the 8-bit lin to 8-bit log conversion will introduce quantization error rather than prevent it.

depending on how you want to finish your film (film-out? or just a HD tape master? finishing in HDCAM-SR is a good way to go that's reasonably future-proof, and allows for a film-out at a later date. HDCAM is a bit crap though - less colour resolution than even HDV, but it is cheaper than SR), it might make more sense to apply the log lut during grading, either on the input or output depending on your needs (a film-out will want to be made log at the start, then grading, then monitoring through a calibrated 3d LUT of some kind).

just remember when grading to go easy on the contrast because that can really expose some of the HDV artefacts. that said, you can get a very good look out of it given a good colourist :)

[sh0dan]

You need at least 12 bit linear to represent an 8 bit gamma corrected image. I dont see much point in 10 bit other than RGB can be represented within 32 bits.

[anton_foy]

@Sagekilla
Well there are some banding in my footage after applying some sharpen and other filters.

@Mug Funky
Yeah I will either go HDCAM-SR or print it.

@Sh0dan
10-bit is only really because DNxHD only outputs 10-bit in 1920x1080 25p.

[Mug Funky]

@ sh0dan:

10-bit is extremely common. however, most of the time processing is done in greater than 10 then dithered/truncated to 10-bit on output (because that's what the cables carry, and what the codecs encode).

so native 10-bit is probably not as important as supporting at least that much precision, preferably more.

just so long as 10-bit can be input and output, what happens in the middle is not as important, so long as internal precision is greater or equal. even a 1992 vintage colour corrector will work internally in 16 bits, though it's input and output will be 10-bit 4:4:4 or less.

[IanB]

I recently added some doodle thinking to the 2.6 avisynth.h to reserve some pixel_type bits for 16bit and 32bit per channel planar memory structures. So far this doesn't imposes any constraints about how those 16bits or 32bits are used, it's just making allowances for things like GetPitch(), GetRowSize() and GetWidth() to be able to return sensible values with code compiled with this new api without needing a recompile in the future. Processes that don't need to access the actual pixel data, like Trim(), Crop, Splice(), etc can be totally future proof.

As for my thoughts on the data layout :-

16bits could be signed 16bit integers using 15bit precision i.e. [0..32767], this allows dodging issues like holes in the MMX/SSE instructions like packssdw but no packusdw. Or perhaps only 14 bit precision i.e. [0..16383], to allow for 2:1 of overrange intermediate results i.e. Add 2 14bit streams, perform some operation on the overrange intermediate data, then scale back to the 14 bit normalized range. Each as an Avisynth statement.

32bits would be single precision ieee float. Heaps of precision, heaps of dynamic range and float operations are quite fast in SSE2. A lot of current AVS code is to do with 8bit overflow and truncation, when expressing the same algorithm in 32 bit float you can almost ignore these issues, which means the code can be much simpler and possibly even faster.

I would probably advocate holding increased bit data un-gamma corrected, so all those nice algorithm like resize, alpha blending, smoothing, deblocking, etc we love can then return true results instead of the gamma bastardized crap we accept currently. Translating for gamma could be in the input routines and the final output interface.

[anton_foy]

@IanB

That sounds VERY interesting! Loads of luck!