Add support for saving HDR10 video
High-dynamic range video formats such as HDR10 and Dolby Vision are increasingly common on modern productions, and offer significant improvements in visual quality on higher-end displays. While Blender performs all of its renderings in a format with essentially infinite dynamic range(floating point precision aside), it currently has no way to format renders for a high-dynamic range display, or produce HDR formats from camera footage. This is due to a number of limitations:
Breaking issues (it's impossible to even export a valid HDR file without fixing these)
-
The default OpenColorIO config has no output transform using a PQ or HLG transfer curve, or Rec2020 primaries
-
Blender's FFMPEG module does not support setting the HDR10 metadata flags
Other problems (technically you can get something playable in HDR without fixing these, but it will have numerous quality and workflow issues)
-
The default OpenColorIO config does not support a rendering space other than linear-sRGB. HDR masters created in Blender will be limited to rec709 gamut, even if formatted to rec2020 by the OCIO output transform.
-
Several parts of Blender/Cycles/Eevee do not behave as they should with wide-gamut rendering spaces (see developer.blender.org/T68926 for the relevant TODO task)
-
Blender's FFMPEG module does not support 10bit or 12bit output formats. Banding can result in HDR without it, as 8bit PQ has only about half the code values for the typical SDR range compared to 8bit SDR formats.
-
Blender's FFMPEG module does not support FFMPEG's H.265, VP9, or AV1 encoders. While it's possible to store HDR in H.264 (especially with Main10 profile for 10bit) the file size is larger than more modern formats, especially in 4K.
7 Comments
I've asked for a "custom ffmpeg" output where we can write ourselves the ffmpeg command line arguments so that advanced users can use ffmpeg to it's full potential without the need to wait for the dev to decide to add some ui to add new options.
Still no answers so far.
With this custom ffmpeg mode, we could do anything including this without any issue.
* @-L0Lock- * Blender is using libav libav.org/ (ffmpeg as a lib) and therefore can't normal command line options be used directly. Also, the Blender included libav build doesn't have all of the various options enabled.
* @ tintwotin * so let's use raw ffmpeg instead of libav
If Blender adds the option for 10 or 12 bit video output rest of the issues with OCIO can be resolved pretty quickly.
If there's 12bit DNxHR RGBA capability implemented trough FFMPEG, especially with Blender 3.2's option to color-manage the output separately from the project it would allow users to work with smaller files for more efficient workflows.
OCIO can even let users output in different camera log formats or HLG and PQ gammas.
Here is a OCIO config I made exactly for such things. youtu.be/RigdyzR_cf0
I wish there was an option for 10 or 12 bit video output in Blender.
Let me back you with an upvote and a comment.
It would be very helpful for creators to have HDR support built in Blender, specially considering how cheaper HDR capable displays are getting. I just got a very cheap secondary 4K monitor with HDR for $150, so the tech is trickling down to many more users. And YouTube's implementation of HDR is fantastic.
Right now the workflow to produce HDR CG content is extremely difficult in Blender. This is a feature that is becoming much more important.
I like it though i wonder.
As i own a 4K video drone; how would one handle the required high disk IOPS to play (or to record) such quality video's ?
just curious.
Funny enough, following this guide ( artstation.com/blogs/jtheninja/N92E/rendering-to-hdr10-from-blender ) I've gotten extremely reasonable sizes. For instance, a 2 second 4K 30FPS video in HDR is comming up for me at 890 KB. Granted, I'm using a lossy compression, but for my use case this still gives a great result.
Uploading this test lossy video to YouTube shows a highly noticeable improvement in quality over a non-HDR video of similar characteristics. Somehow there are considerably less compression artifacts for gradients. Just for reference, here's said test video ( youtube.com/watch ).
So, huge file sizes don't need to be an issue. Working with DWAA lossy codec for OpenEXR in Blender's own Output settings gets you this completely manageable file size.