Is there a better Windows ProRes equivalent than DNxHR?

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache. Any other codec that would be good for render cache to match my Macbook's ProRes LT 4:2:2 10-bit?

Other than for playback performance, what is the purpose of the caching in your workflow?

https://lowepost.com/courses/blog/the-d ... codecs-r4/

https://support.apple.com/en-bh/102207

https://avidtech.my.salesforce-sites.co ... ifications

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache. Any other codec that would be good for render cache to match my Macbook's ProRes LT 4:2:2 10-bit?

ProRes LT is nothing to write home about. Given it is a 10-bit codec, what exactly do you mean that DNxHR sacrifices color depth?

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache.

What?

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache. Any other codec that would be good for render cache to match my Macbook's ProRes LT 4:2:2 10-bit?

Cineform is the obvious choice if you want Davinci do the caching. 4:2:2 10 bit and 1/5 the size of DNxHR HQX.

Under Windows CineForm is an excellent choice.
It works on MacOS too, but all recent Macs are faster with ProRes.

+1 for Cineform

Under Windows CineForm is an excellent choice.
It works on MacOS too, but all recent Macs are faster with ProRes.

True. To add some perspective, even a low end M1 Pro it will encode a UHD timeline to CineForm at more than 200 frames per second (with higher CPU usage compared to hardware accelerated ProRes of course).

You could also try Grass Valley Canopus HQX not HQ.

Cineform in the only CQ codec option available. For that reason, it gets my vote.

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache.

Both codecs offer high color accuracy, but the specific color depth and accuracy depend on the variant of the codec used. All DNxHR codecs under HQX are 8bit - so there is no surprise that you sacrifice color depth when working with 10bit material...
The advantage of CineForm is that, unlike most other intermediate codecs, it has a variable bitrate - which makes the files significantly smaller - but it is not as compute-intensive as h264, for example.

DNxHR is practically same efficiency compared to ProRes. Around 5% difference is meaningless in real world.
10bit vs 8bit is another story. ProRes is always 10bit and DNxHR is not. Use proper variant to have 10bit.
DNxHR has real RGB mode (as well as YUV) for 444 variant, where ProRes is internally always YUV, so there is always a RGB->YUV->RGB conversion happening.
Cineform is bit less efficient, but it's fast and wavelet based, so you can decoded it at lower resolution at proportionally lower CPU load. 444 mode is always (if I remember well) RGB based and 12bit (opposite to what wrong Resolve preset says).
DNxHR by default is strictly CBR based which is not a good thing as it means difficult frames have lower relative quality than easy ones. ProRes is semi VBR, which allows it to lower bitrate for easy frames and raise for more difficult, but there eis hard limit how far it can go above target bitrate (I think around 10%). Cineform is real VBR and can change bitrate a lot per frame, so all frames have relatively same quality (which is one of the key feature behind its design).
All option are good and OS, etc. dictates the choice. All are 12bit for 444 modes.
If you are not happy with DNxHR then Cineform is definitely good alternative.

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache. Any other codec that would be good for render cache to match my Macbook's ProRes LT 4:2:2 10-bit?

ProRes LT is nothing to write home about. Given it is a 10-bit codec, what exactly do you mean that DNxHR sacrifices color depth?

Most DNxHR qualities are 8-bit, leading to banding.

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache.

What?

It is a worse quality codec up until HQX 10-bit.

Most DNxHR qualities are 8-bit, leading to banding.

That's an absurd statement. Take a white or black color solid. Use any codec you want. No banding. You can't claim absolutes, where relative applies. Correlation is not causation.

"If you work hard, and become successful, it does not necessarily mean you are successful because you worked hard, just as if you are tall with long hair it doesn’t mean you would be a midget if you were bald. " ―  Lemony Snicket

DNxHR 8bit variants will show banding. It's normal.
Solid color? You need ramp, not a solid color to test banding.

I have noticed that DNxHR is a worse quality codec than ProRes, mainly that it sacrifices color depth in all except HQX which is not good as a smallish render cache.

What?

It is a worse quality codec up until HQX 10-bit.

It's 8bit, so banding will be there as it's a 'nature' of 8bit precision regardless of the codec.
It's quite interesting choice by AVID to use 8bit (most likely related to decoding efficiency) because higher precision actually compresses "easier" than lower (at given bitrate).
I'm not 100% sure, but Cineform should be 10bit for all variants, like ProRes.

Quality is more associated with compression artefacts and in this respect DNxHR is about the same as ProRes.

Could I suggest you look at Voukoder? It's a tiny bit obtuse but once you get the hang of it, you can output Prores from Resolve.

https://www.voukoder.org/

Prores for days!

Screenshot 2024-12-15 160619.jpg (486.73 KiB) Viewed 2875 times

As for banding in 8 bit, that's kind of par for the course. You can get around it with enough grain/noise to break up the gradients but anything less than 10bit is a crap shot for things like motion graphics.

Solid color? You need ramp, not a solid color to test banding.

Yes. It is relative. I mentioned solid color because output is relative to the input. Quality is correlated to 8-bit but it depends on the context. Its like when people claim you need the biggest color space with biggest color gamut available or you destroy the image. Not if you are working black and white.

Having banding in the source footage, won't make it magically go away if codec for cashing is 10-bit, but it might help not make it visibly worse. On the other hand if the footage is not heavily compressed to start with and there is no scenes with demanding gradations, 8-bit for temporary cashe should be no problem at all.

Banding is not ever present or ever visible phenomenon, it is seen when available number of shades is not enough to represent image which requires smooth gradients. Noise or film grain or dither will of course hide the problem in many cases as well. And there needs to be correct processing pipeline in place or the problem will show at the weakest link in the processing chain. Including if the original footage already is showing banding.

"Internally to DaVinci Resolve, all image data is processed as full range, uncompressed, 32-bit floating point data. What this means is that each clip in the Media Pool, whatever its original bit-depth or data range, is scaled into full-range 32-bit data. How each clip is scaled depends on its Levels setting in the Clip Attributes window, available from the Media Pool contextual menu.

By converting all clips to uncompressed, full-range, 32-bit floating point data, Resolve guarantees the highest quality image processing that’s possible. As always, the quality of your output is dependent on the quality of the source media you’re using, but you can be sure that Resolve is preserving all the data that was present in the original media

All content in the DaVinci Resolve Fusion page is processed using 32-bit floating-point bit depth, regardless of the content’s actual bit depth. "

If the data being processed is not already showing signs of banding and you are not forcing the banding by force, it should be fine, especially if footage itself is not compromised.

Caching is what some programs call rendering, or temporary rendering to speed up playback. As I've asked the OP, what is the need for caching? Just playback performance or something else. These things should be considered before someone chooses a particular workflow, and there are quite a few variables.

Playback performance can be improved in variety of ways and for verity of use cases. Usually if you need quality you don't need timing, and if you need timing you don't need quality, and if you need both there are options which can be used at the expense of processing time and file size.

While smaller formats take less room on scratch disk, there are two good reasons to use higher-quality formats for creating cached media and they are not because of banding.

Preventing Clipping: format you choose will determine whether out-of-bounds image data is preserved when the signal is optimized. If you find that image data (typically super- white levels) are clipped after optimization, you should switch to 16-bit float, ProRes 4444, or ProRes 4444 XQ; in particular, any of these three codecs are appropriate optimized formats for HDR grading.

Preserving Alpha Channels: format you choose will determine whether Alpha Channels will be preserved, if they’re present in the clips being Optimized. Currently, the Uncompressed 10-bit, Uncompressed 16-bit Float, ProRes 4444, ProRes 4444 XQ, and DNxHR 444 formats preserve alpha channels.

If there is no need to worry about clipping, and no need to preserve alpha channels, than why use these formats that will requires a lot of storage space for process of temporary rendering, aka caching. ? If there is no need to for maximum image quality at full speed, why do rendering before rendering is done in final delivery? Caching can be turned on and off at any point and there are different mechanisms of caching and which ever one chooses the nature of it is that only really can be displayed after it has been cached and no new changes are made. Most of it is temporary anyway. So no real harm is done to the files themselves. Even if one works with banding, it doesn't mean the final file will also have it.

Most of the color grading process is not full of motion but working on shorter clips that are static, so playback performance is not as important as for editing and for editors quality of image is less important and what matters is real time playback performance. Its fairly rare that both are needed at the same time until the final render. But there are times when one might use either HDR workflow or have alpha channels with transparency where some of the higher level formats make more sense. If its just for playback, I would rather use lower resolution timeline or change timeline playback performance where I don't have to render duplicates or wait on rendering. While most transitions and other effects can be cashed separately.

The only other X factor is re timing, especially with optical flow where caching can be useful. But even there, instead of banding what really matters is interpolation artifacts and ghosting issues, which will show up in both 8-bit or 10-bit.

Delivery of final footage from the deliver page is a differnt matter of course. That too is also dependent on the platform and what other processing might be done.

Cashing codec is nothing different then delivery codec. Once nice 32bit float data hits 8bit it's destroyed and gone. If someone grades with cashing then will see banding. It won't show on any footage, but on some and then it can be crazy obvious. If you work with anime or clean footage from a good camera then you will see it in basically every project. There is a reason why you want 10bit monitoring with good monitor, to not see it and not distract you.
On top of that you want high precision processing and delivery format.

Not sure why you trying to complicated simple thing- don't want banding during work, don't use 8bit caching codec. Plain simple. Fortunately there are options in Resolve to solve it.
Original question is very valid and also points 'unevenness' of Resolve related to different OS.

Not sure why you trying to complicated simple thing- don't want banding during work, don't use 8bit caching codec.

I would not use 10-bit either. There is a reason 32 float is used!

Is there a 32-bit Float option for Cache?

The best I'm seeing is Cineform RGB 16 bit.

A bit overkill for Cache, in my view. The YUV 10 bit is fine.

No, there’s none, and it’s not needed.

So, I think this is why that check box in Delivery is so important. The one that says, "Use render caches." I never realized that there is no 32bit caching. Just never thought of it. In Fusion, you cache with BRaw or exr so it's 32Bit capable but once you're back in the timeline, it's 12 or 16 bit. You can deliver in DPX at 32bit because you can bypass all the caches unless you check that box. I suppose that's where "Render in Place" could cause a quality drop if it's not a high enough bit rate for what you need.

One shouldn't be using 8bit anything with these new cameras. Use DNxHR at 10bit, sprinkle some noise in the clip, and keep the bitrate high and you won't get any banding.

Is there a 32-bit Float option for Cache?

The best I'm seeing is Cineform RGB 16 bit.

A bit overkill for Cache, in my view. The YUV 10 bit is fine.

I started using render cache to lower my export times. It works well.

Bitrate can only be too low for GOP codecs.
All intermediate codecs have pretty much fixed bitrate for any given quality setting (well, DNxHR has some variation). If you choose a level with adequate quality, bitrate will not be your issue (apart from storage space).

Depending on your sources and the intended delivery, these versions should suffice for >90 % of workflows:
– ProRes 422 HQ
– DNxHR HQX 10 bit
– CineForm YUV 10 bit
– GrassValley HQX
These are all available in QuickTime, some in other wrappers too.
Even these can be already more than needed if your sources are 8 bit only and/or massively compressed. Higher ones, like ProRes 4444, are just a waste of space if your sources are not high-end cameras or CGI in very high-quality formats.

Is there a 32-bit Float option for Cache?
:The best I'm seeing is Cineform RGB 16 bit.

@ Jim: 16float cache is avb, compressed @ DNxHR444_HDR, or uncompressed @ EXR
@ Uli: it's needed in ACES workflows

one can output uncompressed 16float DNxHR in a MXF wrapper as well

ProRes via vocouder is a good workflow if someone in the pipeline insists on ProRes. You only have to set it up once per output variant and then you can render out ProRes directly from resolve.

@ Uli: it's needed in ACES workflows

Yes, the Academy is suggesting one of the variants of EXR. I was rather aiming at those around here who need less than that.

Not sure why you trying to complicated simple thing- don't want banding during work, don't use 8bit caching codec.

I would not use 10-bit either. There is a reason 32 float is used!

You can, but if you render in full quality later then just for grading/preview you won’t see any real difference between 32 bit float and 10bit.
32bit float hasn’t been chosen for 'final delivery' (which cashing sort if is) but for internal processing where many operation adds up to create final image. Then it may be needed although you could probably be fine with lower precision also. It’s more an obvious choice when GPU is heavily involved like in Resolve case.

Fortunately you have basically all needed options in Resolve, so everyone can pick its preferred caching format. Best if you wouldn’t need to cache at all

With respect to "half float," i.e., 16-bit float, that is fine for log but not for linear sources.

With respect to "half float," i.e., 16-bit float, that is fine for log but not for linear sources.

what kinda sources?

typicaly i have camera raw, either ArriRAW, Venice OCN or R3d, show i'm on today is R3d @ full premium / 16b
and VFX shots in linear wraped EXR @ 16float
i'll typicaly cache to EXR, and use caches for delivery
never an issue, either to my eye, scopes, or tier1 QC

Aside: was using one of your DCTL's last week, many thanks for shareing them!

With respect to "half float," i.e., 16-bit float, that is fine for log but not for linear sources.

what kinda sources?

Any linear source needs better than 16-bit float (half float) resolution. Half float only has a 10-bit mantissa for precision, a 5-bit exponent for range scaling, and 1 sign bit. While the exponent gives a good dynamic range, the 10-bit mantissa doesn’t have enough precision to show the full dynamic range in linear light. This is different from log-encoded sources, where the logarithmic encoding allows for a better spread of precision across the brightness range.

With respect to "half float," i.e., 16-bit float, that is fine for log but not for linear sources.

what kinda sources?

Any linear source needs better than 16-bit float (half float) resolution. Half float only has a 10-bit mantissa for precision, a 5-bit exponent for range scaling, and 1 sign bit. While the exponent gives a good dynamic range, the 10-bit mantissa doesn’t have enough precision to show the full dynamic range in linear light. This is different from log-encoded sources, where the logarithmic encoding allows for a better spread of precision across the brightness range.

You have it backwards. Half float storage is fine for linearized color data but not for log. The ”spread” of values in log storage is counter-productive for the way float storage works. Or rather, code values in int data (which log encoding usually uses) have the same absolute precision over the whole value range. Float data on the other hand has ~same relative precision, but absolute precision is halved per each additional stop (there are 10 bits for every stop in half-float). Due to this, normalized range 0.5-1.0 which would cover half the range of lets say 16bit unsigned int only has 10 bits of precision, but must store 15bits worth of data, regardless of the meaning of the data: different source code values will be bunched together to same resulting code values. And issue would be way worse without normalization.

Long story short, 16bit half float can store 10bit integer based data (log, rec709, whatever) without significant loss, but not 12 or more. 16bit half float can store 16bit log data IF linearized just fine for all practical purposes. There is a reason why render engine outputs which are linear by nature usually utilize exr-s not some log based int storage. 32bit float is necessary if precision actually counts, and this is the case for non-color data like depth etc. For color data STORAGE, half-float linear storage is all and more ever needed. Resolve interally processed data at full float because precision errors compound through operations and also 32bit floats are the workhorse base datatype for GPU processing.

I stand corrected.