How to get Scarlet 4K HDRX at 24 fps ... my proposed method

[Les Dittert]

I'm a big fan of high dynamic range capture and processing. As we all know, right now the 4K HDRX is not there on Scarlet.
I think I have a solution that is a slight modification of the scheme that Red currently is using.
This method relieves the compression overhead of the X track by only compressing the actual highlights that are
useful in the subsequent processing ( blending or toning ) of the two tracks.

It has been indicated that the processing limits the HDRX frame rates. Understandable as it has to compress double the number of frames!
If the code is allowed to skip over a threshold for localized brightness, much of a frame does not have to be compressed at all. In a crude sense this is a form of compression in itself ... a rather harsh quantizer, as it were...

Complications:
The scene turns into almost all 'bright stuff' that overload the X track compression anyway. Possible solution is to reduce compression of the A track as well, via a similar RLE or skipping strategy. After all, you only really need image from one track or another. Overlap a little for transition areas.

The simple 'blend' RCX HDR fails. Yes, that would have to be updated for this new mode. Perhaps to true high bit depth HDR that still guys use.



I worked up a little video to help show this. The above may make more sense after seeing the video. The result at the end was actually processed from the reduced compression requirement X track with a normal A track. You really don't need those dark X track pixels anyway! So why compress them ?

Video: http://dl.dropbox.com/u/61349012/demo_HDR_method.mp4

Comments are welcome!

[Brennan Clark]

Dood, you'z smart! Maybe Red will hire you as a freelance programmer to make this work. What a great idea. I'm sure there's some sort of reason why this hasn't been done. But who knows, not everyone can have every idea all at once!

[Brian Iannone]

Les, you are indeed a genius. :-)

Let us hope that RED will implement this as 4K at 24 fps with HDRx would be a nice addition to Scarlet's capabilities.

[James Fleming]

Make that 4K at 25 fps for us PAL-landers.

[Wayne Morellini]

Red was to have 150fps 3k on the fixed, how come they can't manage a 24fps hdr mode (please nite this is not getting into why there leading sensor can't do normal, simpler and superior, multi-slope or other from the 1990's, they use in $70 HD video camera). I give merit to your scheme les, but why can't Red store a 48fps 4k stream and integrate in post, a lot less data than 3k at 120fps even. You can even use the overlap between the track to form 48fps new hdr track in post. The software will have to fill in missing 24fps frame data in the highlights and dark areas, which should be very possible with modern software. Now we are close to 50p broadcast, another bonus if it records at that frame rate.

On what you say Les, yes it should easily be able to clip off the top or bottom useful data and integrate it with the other track on the fly to have just one 24fps track compressed and recorded (if need be) with clip point per frame if need be. It will still have to have the offsetted clip data realigned through software. Looking at this, and the way comoressiin works, a seperate track maybe preferable, but compression still gets stuffed around with table top curves, you could just define the curve to be conveniently rounded, and replace during integration, but loss some of the efficiency, but if it is maxed out anyway you would still be lossing it. The issue is, is red code capable of a 16-24bit pixel? If so that is the way to go, as 16bit is the extra precision of the curve which is seperate from the amount of compressed data.

[Norbert Jalitsch]

Red was to have 150fps 3k on the fixed, how come they can't manage a 24fps hdr mode (please nite this is not getting into why there leading sensor can't do normal, simpler and superior, multi-slope or other from the 1990's, they use in $70 HD video camera). I give merit to your scheme les, but why can't Red store a 48fps 4k stream and integrate in post, a lot less data than 3k at 120fps even. You can even use the overlap between the track to form 48fps new hdr track in post. The software will have to fill in missing 24fps frame data in the highlights and dark areas, which should be very possible with modern software. Now we are close to 50p broadcast, another bonus if it records at that frame rate.

On what you say Les, yes it should easily be able to clip off the top or bottom useful data and integrate it with the other track on the fly to have just one 24fps track compressed and recorded (if need be) with clip point per frame if need be. It will still have to have the offsetted clip data realigned through software. Looking at this, and the way comoressiin works, a seperate track maybe preferable, but compression still gets stuffed around with table too curves, you could just define the curve to be conveniently rounded, and replace during integration, but loss some of the efficiency, but if it is maxed out anyway you would still be lossing it. The issue is, is red code capable of a 16-24bit pixel? If so that is the way to go, as 16bit is the extra precision of the curve which is seperate from the amount of compressed data.

25 fps instead of the 24 and 50 fps instead of the 48 would be enough for me for the beginnning ;-))) but your idea sound's great...

[Sverker Hahn]

Get a proper home

[Les Dittert]

Wayne,
I'm proposing this as a short term solution. Probably less than 500 lines of code.
Your other ideas are interesting, but I have a 5 micron sensor in my cameras that has no well capacity to do heavy HDR images without multi exposures.
Let's keep this thread for more 'easy to get in 8 weeks' & 'with current hardware' type of discussions.
Thanks.

[Sascha Rossier]

Great idea! A question about RED integrating these inputs: Is RED usually responding to that kind of proposals/ideas and if so, how long can it take to integrate (i know that kind of a "when-wil-my-scarlet-ship" question ;-) ... but still. In the Epic Forum i see a lot of feature requests-posts and i've never seen a single one of these integrated into the camera build yet.

[Wayne Morellini]

Great idea! A question about RED integrating these inputs: Is RED usually responding to that kind of proposals/ideas and if so, how long can it take to integrate (i know that kind of a "when-wil-my-scarlet-ship" question ;-) ... but still. In the Epic Forum i see a lot of feature requests-posts and i've never seen a single one of these integrated into the camera build yet.

We are talking about one of them, it took a few years, and I have had several integrated into Red products, except the fixed. Look through the thread history, I was one of the first to independently suggest the multi-exposure her scheme as a simple firmware fix due to even cheap picket cameras having her with 16 stop plus latitude. But my suggestion to back to back the exposures, leaving the only sizable shutter gap between sets of exposures, so that movement difference would be miminised (instead of this compromise scheme that adds sizable gaps that have to be integrated). They are not gods you know. The fixed redone dynamic is very much like a market segregation strategy I suggested around 2004 either in the original anonymous Red camera suggestion thread or the original DIY digital cinema project thread Jim followed, and the original scarlet seems very much like the compromised camera I put forward there. About the pocket camera idea that became the scarlet, I was on Jim about the pocket camera around 2006, maybe earlier, I had an idea that I referred to as The Director's Veiwfinder. They claim big things shortly, I hope so, they are light years behind so far. Without the feedback of many other people aswell, Red would not be the success it is today.