This forum has been archived. All content is frozen. Please use KDE Discuss instead.

ProRes DNxHD editing format?

Tags: None
(comma "," separated)
seandarcy
Registered Member
Posts
16
Karma
0

ProRes DNxHD editing format?

Fri Jan 27, 2012 11:29 pm
I have some old 16mm news film being digitized. I'll hope to be editing them with kdenlive. My choices for editing format are:

Apple ProRes 422HD
Apple ProRes 4444HD
DNxHD

Can kdenlive work with them all? Any preferences? I'm leaning toward Apple ProRes 4444HD.

sean

FishB8
Registered Member
Posts
53
Karma
0

Re: ProRes DNxHD editing format?

Sat Jan 28, 2012 3:54 am

- DNxHD 8bit -> Yes

- DnxHD 10bit, any ProRes format 8bit or 10 bit -> Yes, IF you have a very recent version of ffmpeg installed. (>= 0.9.0)

Latest version of ffmpeg is 0.10.0 released a few days ago.

Be aware, even though ffmpeg can decode / encode 10 bit video, I'm not sure how KdenLive / MLT handle 10 bit video. I doubt many of the visual effects would work properly with 10 bit. I may be wrong though, never tried it.
yellow_drupal
Registered Member
Posts
748
Karma
0

Re: ProRes DNxHD editing format?

Sat Jan 28, 2012 7:45 am
10bit is dithered to 8bit and most color tools in kdenlive are 8bit precison too I think.

I had about 50 8mm cine films frame scanned at 10bit uncompressed 4:2:2 a while back, had to provide a external hard drive and now see companies are doing image sequences as well.

Blender built with a recent ffmpeg build will handle 10bit import and work at 32bit precision that may be an alternative, it offers a proxy workflow although its painful compared to kdenlive which will do the job if you're ok with 8bit output.

I went with 10bit captures as I only wanted to pay once and get best available copy for archive, but more than happy with kdenlive to edit and output 8bit for viewing.
markoc
Registered Member
Posts
342
Karma
1

Re: ProRes DNxHD editing format?

Sat Jan 28, 2012 10:40 am
When scanning film, you trade bit depth for resolution.

The smaller the pixels (higher resolution), the less bits per pixel the film can give you.

Film is actually a binary medium, a grain of silver can either be "on" or "off". Film can only reproduce grays because the grains are quite small, and there are a number of them in each "effective pixel". The percentage of grains being "on" determines the gray level. This is very similar to how a laser printer prints photographs, you need to trade resolution for number of grays.

The bigger the resolution, the less film grains are in a pixel, the less gray levels they can represent (equivalent to a higher effective noise).

So, if you scan 16mm film at 1080, you will not need more than 8 bpp.

You can check this by measuring a flat area with pr0be, on 256 scale. If the RMS value is bigger than 0.5, the noise of your input signal is bigger than the 8 bit quantization noise. Note that 0.5 is the max possible value of quantization noise, reached when half the pixels have the value N and the other half N+1. In practice, it is less (image dependent) - so this is a conservative test!

(if you do not switch to "256 scale", the max value of 8 bit quantization noise is cca 0.002)


Of course, if you apply a lot of processing (resampling, effects, etc.) the arithmetic round up errors of an 8 bit pipeline can accumulate to values significantly higher than the pure quantization noise. Therefore a higher precision processing pipeline would be desirable in some cases.

I vote for float... or at least 16 bits, to give some headroom for final conversion to 10b output - 10b arithmetic would also be clumsy on byte oriented CPUs




Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], Sogou [Bot], Yahoo [Bot]