Exporting ProRes 4444 12 bit versus 10 bit from Resolve

Anyone know how to export ProRes 4444 12 bit from Resolve 10?
When I select ProRes 4444 in the deliver page and export, the resulting file is only 10 bit, not 12 bit. There is no option that I can see to select the color bit depth of the export. I've searched the latest version of the Resolve manual and the forum, but there is no information on how to control the bit depth of a ProRes 4444 export. For comparison, when exporting ProRes 4444 from After Effects (on Mac) there is an option to choose either "millions" or "trillions" of colors -- Apple's annoying nomenclature for selecting between 10 bit and 12 bit color.

Actually that's apples nomenclature for 8bit vs 16bit. But of course 16bit doesn't actually make it into prores.

Di you really need 12 bits or you want it? (Just curious)

Any answer to this thread?

Although I never got all the answers to my OP, this may be of interest to you…

http://reduser.net/forum/showthread.php?104779-Keeping-it-12-bit

I saw no resolution on the Red Forum discussion as to why 12-bit is necessary or desirable. Believe me, you can get there in 10 bits. What display device can handle 12 bits? Every blockbuster movie of the last decade has used 10-bit log DPX files (except for the handle using 16-bit EXR), and I think they work just fine.

I'm curious what the o.p. expects to gain from this process.

RED raw: 12-bit (or 16-bit)
ProRes 4444: 12-bit
DCI (jpeg2000): 12-bit

So why not? Remember when 128kbps MP3's were considered adequate? DCDM's are not likely to be redone from the raw files anytime soon, so keeping that accuracy might be important. True, it may not be visible with current technology, but if it makes the client feel better…

Not sure if digital projectors can actually reproduce those 12 bits now. Also, which is more harmful to an image—the (light) compression of ProRes, or the (minimal) rounding errors of a 10-bit DPX?

[Rohit Gupta]

Anyone know how to export ProRes 4444 12 bit from Resolve 10?
When I select ProRes 4444 in the deliver page and export, the resulting file is only 10 bit, not 12 bit. There is no option that I can see to select the color bit depth of the export. I've searched the latest version of the Resolve manual and the forum, but there is no information on how to control the bit depth of a ProRes 4444 export. For comparison, when exporting ProRes 4444 from After Effects (on Mac) there is an option to choose either "millions" or "trillions" of colors -- Apple's annoying nomenclature for selecting between 10 bit and 12 bit color.

PR4444 exports are always 12-bit. There is no way to limit it to 10-bit.

I wonder why the o.p. believes the 4444 renders are 10-bit?

I checked the ProRes4444 exports from Resolve 10 and they were flagged as 10 bit not 12 bit. I needed 12 bit it to meet the spec requested by a distributor. Other option was TIFF sequence, so I ended up having to send that instead.

[Rohit Gupta]

I checked the ProRes4444 exports from Resolve 10 and they were flagged as 10 bit not 12 bit. I needed 12 bit it to meet the spec requested by a distributor. Other option was TIFF sequence, so I ended up having to send that instead.

Where was it flagged as 10-bit? How did you check?

In the media o conform page you can set up a new column with the bit depth infos.
Actually, the Prores 444 is usually flagged 16 bits. Even Prores444 from Alexa are 16 bit even if they should be only 12 bit

I think Resolve is reporting that's it's not 10 bit, it may not report 12 bits but chooses the next option, 16. PR 444 is 12 bit, no choice.

The new 500mbps QX Prores 444 should give raw some competition.

I checked the ProRes4444 exports from Resolve 10 and they were flagged as 10 bit not 12 bit. I needed 12 bit it to meet the spec requested by a distributor. Other option was TIFF sequence, so I ended up having to send that instead.

Where was it flagged as 10-bit? How did you check?

If file can be played in ffplay or processed by ffmpeg than it means it's 10bit.
ffmpeg has no support for 12bit ProRes, because NO ONE has shown 12bit sample. If "claimed" 12bit sample can be decoded over 10bit pixel format without broken image than something is not right.

Few source claim to have 12bit ProRes: Alexa sample, sounddevices etc, but they are all 10bit!

As far as ProRes can do it, I wish to see a REAL sample. There is something not very clear around 12bit ProRes.

This may be one of the possible explanations:

"Arri's Alexa records in ProRes 444 C-Log, letting you store the equivalent of a 12bit dynamic range image in 10bit..."

Few source claim to have 12bit ProRes: Alexa sample, sounddevices etc, but they are all 10bit!

As far as ProRes can do it, I wish to see a REAL sample. There is something not very clear around 12bit ProRes.

This may be one of the possible explanations:

"Arri's Alexa records in ProRes 444 C-Log, letting you store the equivalent of a 12bit dynamic range image in 10bit..."

Where is that quote from? ARRI states its ProRes4444 recording option as 12 Bit RGB everywhere (e.g. see in the manual). How can you read out the factual bit depth of a file? (Mediainfo doesn't do the trick) How does ffmpeg do that?

Cheers,
Gerhard

There is really no flag for bit depth (as far as I know), so you can't easily check it.
It's not Arri quote.

The point of using ffmpeg to prove it, lies in fact that ffmpeg can decode only 10bit ProRes files. Decoder is not written to support 12bit, so if you have real 12bit file than you should see some garbage when decoded with ffmpeg. This was mentioned by few ffmpeg developers.... None of them confirmed that decoder will read 12bit and convert to 10bit for the output (maybe this is what happens for 12bit files).
Even so I have not seen a sample which would not decode properly over 10bit chain, so I'm not that convinced about this 12bit.
ProRes as per design can do even more than 12bit, but we need some proof.

Many manufactures claim ProRe 444 12bit mode, so it has to be real?!

I've done some tests in AE and there is some difference in HQ and 444 (16bit gradient source with heavy curve), but it's not good enough to prove lack/existence of 12bit.

Hi Andrew,

When I open ProRes422HQ and ProRes4444 in Resolve they show 10 Bit and 16 Bit.
According to my information bigger then 10 Bit is always packed into 16 Bit, so 12 Bit too.

If you don't have sample footage of the ARRI Alexa here is a link:
http://www.arri.com/ES/camera/alexa/lea ... e_footage/

Here is a little screenshot from Resolve media tab:
https://dl.dropboxusercontent.com/u/26453396/ProRes.png

Cheers,
Gerhard

According to my information bigger then 10 Bit is always packed into 16 Bit, so 12 Bit too.

Anything bigger than 8-bit is packed into 16-bit. Even 10-bit is part of the 16-bit empire for the simple mathematical relationship of 2 raised to the power of n. 2, 4, 8, 16, 32, 64. Every byte is 4 bits, one Octal word, two words is one hexadecimal value... FFFF is... what decimal value? (skill-testing question)

jPo

JPo, thanks for clarification.
FFFF is 65535 Am I skilled?

Interesting is that Resolve says HQ is 10 Bit and ProRes4444 is 16 Bit, which leads me to the
question how does it read out/determine that information?

FFFF is 65535 Am I skilled?

If you can explain how (apparently) 2 raised to the power of 16 is an odd number. (But you are correct)

jPo

F --> 2^0 + 2^1 + 2^2 + 2^3 = 1 + 2 + 4 + 8 = 15

FF --> 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = 255
FFF --> 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 + 256 + 512 + 1024 + 2048 = 4095
FFFF --> 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 + 256 + 512 + 1024 + 2048 + 4096 + 8192 + 16384 + 32768 = 65535

Or much easier:

FFFF --> 2^16 - 1

Or much easier:
FFFF --> 2^16 - 1

Very good. Would be even easier if we had 16 fingers and thumbs.

jPo

Or much easier:
FFFF --> 2^16 - 1

Very good. Would be even easier if we had 16 fingers and thumbs.

jPo

It is actually 65536 code values starting from 0 to 65535.....

0 counts. ... (#0000)

65536 code values

Yes, in the sense that it is the same arithmetic problem as how many fence posts if spaced 2 metres apart to go 500 metres? Divide (500/2) +1, because you need one at metre zero.

FFFF is similar to the decimal value 9,999 in the sense that the next number is the "even" 10,000.
FFFF+1 is written as 10000 (base 16 / hex).

Fun with math...

For those who don't work in different number bases...
in decimal we count 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11... (you know how it goes... I hope, after all, numeracy is?)
In hex, we count, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10, 11, ... 19, 1A, 1B, 1C, 1D, 1E, 1F, 20, 21... because we don't know what to call the single-digit numbers after 9 because our natural understanding jumps to 10, so we use the first 6 alphanumerics.
Like in 4-bit binary, the way computers think, there is no "2"... the data registers look like:
0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, 1001... where 0100 is the decimal "4" and so on...

some of the blinking lights on the front panel of the DEC PDP-8, anyway... some of them were hex codes for assembler language.... [theremin music starts in the background]

jPo

I'm with you JPo...

Hi Andrew,

When I open ProRes422HQ and ProRes4444 in Resolve they show 10 Bit and 16 Bit.
According to my information bigger then 10 Bit is always packed into 16 Bit, so 12 Bit too.

If you don't have sample footage of the ARRI Alexa here is a link:
http://www.arri.com/ES/camera/alexa/lea ... e_footage/

Here is a little screenshot from Resolve media tab:
https://dl.dropboxusercontent.com/u/26453396/ProRes.png

Cheers,
Gerhard

It probably reads src_pix_fmt, or color sampling header. This is enough to assume (but not really 100% know) if file is 10 or 12 bit.
Other than that- 10bit ProRes files can be also read as 16bit. ProRes decoder can provide few pixel formats on the output regardless of ProRes file type.

Anything bigger than 8-bit is packed into 16-bit. Even 10-bit is part of the 16-bit empire for the simple mathematical relationship of 2 raised to the power of n. 2, 4, 8, 16, 32, 64. Every byte is 4 bits, one Octal word, two words is one hexadecimal value... FFFF is... what decimal value? (skill-testing question)

Ah, this makes sense. I think this may answer the question.

Where was it flagged as 10-bit? How did you check?

Another place to check is with ffmpeg. It identifies the files as yuv444p10le, and it displays them correctly.

I'm curious what the o.p. expects to gain from this process.

I know this was an old thread, but now 10-bit is no longer sufficient for HDR, it is likely to show banding. There are several monitors out now that can take 12-bit 4:4:4.

You can also argue that in order to produce proper 10bit final master your source and calculations should be higher precision (specially when you do heavy grading).
In the same time you can argue if any RAW files, even from high-end cameras really have useable >10bit information (when noise etc is taken into account).
HDR is definitely a thing which needs more than 10bits (again-specially to start with and for processing).