Guys, it is easy to make filmmakers happy and it requires only small software modification.
Add 48p,50p and 60p modes in your encoder. Restrict selectable ISO to native ISO values only. And store each frame two times (24p becomes 48p, 25p - 50p, and 30p becomes 60p). But process frame each time differently. Making some kind of exposure bracketing. So even frame will represent low 8 bits and odd frame will represent top 8 bits. And store it using intra coding and highest available bitrate.
@CRFilms Totally agree man! These guys have to get over corporate crap and get with the program!
HV20 did this when there was NO way to record the stream .... now that its easy- oh no! NO NO NO! Darn... Hopefully HDMI one day can be fixed... :.( I tells you maybe @VK should have a 'collection' just for HDMI coding, and testing etc... that would be very popular.
introduce s-log style, or fully customizable picture profiles! (increased flexibility / sensibility of parameters) How hard can it be? 10 bit camera capture 8 bit video.. this should be a clear indication of improvement area.
@fatpig Editing such a stream is easy. All you need is simple plugin for leading editors. Not only it is preserving dinamic range, but also, if you slightly change encoding for even frames you could preserve more color information (going to 4:2:2 in reality).
That is a great and reasonable alternative to reds HDRx. The raw frame pre compression, could be written as a highlight optimized and a shadow optimized frame. I do a 1 exposure HDR from a raw still in lightroom or camera raw. There is enough info in the raw frame to get detail in highlights and shadows and still live within the limits of 8 bit.
These are great ideas but need manufacturer's will to join the program. It will limit your exposure speeds marginally because you need a small extra margin for the second exposure (let's say 1/8th) . I don't know how good/bad it might work, but I guess perhaps an available alternative (even though infinitely less elegant in every aspect) is to "glue" two cameras together and record them at different shutter speeds. The plugin would have to deal with parallax errors but these days there are plenty of Computer Vision solutions for that problem. This could work but there are evident limitations: no zooming, no panning, absolutely stable camera and no fast moving subjects. All but the first limitation would also apply to VK's suggestion. Different shutter speeds render different footage whenever there is any kind of motion involved, be it camera or subject.