John Miller

It's not quite that straightforward. No software worthy of use calculates using 8-bit integers. Transformations of 8-bit images will almost always be calculated using 32-bit integers (if not, the programmers should be shot).

Where the issue of 8-bit vs. 10-bit integers vs. 32-bit floating point comes in is how the intermediate stages of a multiple step transformation are stored, either transiently or persistently (i.e., in memory during rendering or as an intermediate file on disk that will be further edited later).

For a single step process (e.g., applying luma gain), no benefit is obtained from a greater bit depth.

For a multiple step process (e.g., apply luma gain and adding a title), then it comes down to whether the software keeps the intermediate image at a higher depth than that of the native image format. I have no idea which NLE does what and if it this that the processing claims relate to.

I'm still amazed how few NLEs perform calculations within the Y'Cr'Cb' domain. There really isn't any excuse anymore for using RGB space. Everything that can be done in RGB space can be achieved in Y'Cr'Cb' - it just requires a different set of mathematical equations.

I'm also surprised that no NLEs exist (that I know of) that can work in the DCT domain (which decreases the processing requirement by an order of magnitude) nor perform smart rendering on an intraframe basis. i.e., every NLE out there (AFAIK) will completely decode and re-encode the entire image even if you change just one luma pixel. Though it may be harder for MPEG-type compression, considerable improvements in processing capability can be made. Unfortunately, the NLE developers rely on 3rd party codecs to do the grunt work.

Smarter algorithms could turn your dual core system into the equivalent of an 8-core.