Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

EPIC HDR...

That pic that Jim posted is really beautiful - no cheesy HDR look - it's a new look that reminds of me of Hyperrealist painting more than anything. To shoot motion with this... WOW.
 
I agree... the question could be asked, if this HDR really works, why would people use the "normal" mode?

Aside from the obvious answers of course (Needing higher frame rate.)

Jay
 
I agree... the question could be asked, if this HDR really works, why would people use the "normal" mode?

Aside from the obvious answers of course (Needing higher frame rate.)

Jay

There are lots of times you don't need more than 13 stops.
 
There are lots of times you don't need more than 13 stops.

There is just something about that comment that seems almost surreal. What a dilemma to be faced with... "Hmmm, do I need just 13 stops or should I go for more?" :emote_happyhappy:
 
"Hmmm, do I need just 13 stops or should I go for more?"


What about making the Camera choose for you... Auto DR? I wonder how that could work? Lol
 
What about making the Camera choose for you... Auto DR? I wonder how that could work? Lol

Well if you're shooting 48fps or less it could check the histogram if >% pixels @ > 1.0 luminance for >## frames encountered don't discard the HDRx™ stream for the take.

If the card is filling up and it's still under the conditions for an AutoHDRx™ shot then discard the HDRx™ stream and continue recording normally.

Could be handy for Documentary mode. Maybe in a take you pan across a window that fills 5% of the frame @ > 1.0 luminance for more than 3 seconds. It keeps the HDRx™ stream. In another take your subject stays entirely within 13 stops and it tosses the extraneous data when you stop recording.

That would of course assume that the double data-rate is a separate and additional data stream easily discard-able though.
 
Red guys, you sent film to long deserved rest. Unbelievable, congrats on achieving your dream.

Any estimates how much DR could have fixed Scarlet with HDR? 14 steps?
 
Well if you're shooting 48fps or less it could check the histogram if >% pixels @ > 1.0 luminance for >## frames encountered don't discard the HDRx™™ stream for the take.

If the card is filling up and it's still under the conditions for an AutoHDRx™™ shot then discard the HDRx™™ stream and continue recording normally.

Could be handy for Documentary mode. Maybe in a take you pan across a window that fills 5% of the frame @ > 1.0 luminance for more than 3 seconds. It keeps the HDRx™™ stream. In another take your subject stays entirely within 13 stops and it tosses the extraneous data when you stop recording.

That would of course assume that the double data-rate is a separate and additional data stream easily discard-able though.
Gavin, that's an interesting thought process! I wonder if Epic would have the CPU power to determine that in real time? Maybe a 10s or 30s buffer (like pre-record) to enable frame accurate HDRx frames only when a highlight would normally clip and combine them at the end? Same framerate limitations as full-time HDRx but more economical on the data store?

Nice thinking!

Cheers,

Paul
 
If something like Gavin suggested is possible I'd add option of auto deleting segments of HDR stream which are not necessary. If it cannot be done in camera, to save recording space, maybe it could be done in Redcine X.

Dial in stops + Auto HDR tolerance and HDR required parts of the clip are marked in metadata. For manual work HDR tolerance is not necessary and just metadata could be useful. One could have additional graph above Redcine X timeline showing two curves of 1) HDR pix % and 2) amount of luminance over normal DR.

That way one could simply use razor tool to cut the HDR stream and delete redundant parts. It will save storage space and redundant HDR processing for shots with mixed DR scene.
 
Gavin, that's an interesting thought process! I wonder if Epic would have the CPU power to determine that in real time? Maybe a 10s or 30s buffer (like pre-record) to enable frame accurate HDRx™ frames only when a highlight would normally clip and combine them at the end? Same framerate limitations as full-time HDRx™ but more economical on the data store?

Nice thinking!

Cheers,

Paul

yes I think thats' brilliant - unless the fine minds at Red just said "hey wait a minute, we should implement that before we ship the camera" and now we have to wait longer for our Epic - in that case I take back that I think you're brilliant :furious3:
 
AHhhhh the foundry might be the hint to it all?!?! :)

Reading out each line twice means the only setback you have is twice the rolling shutter - now lets see what kind of products the foundry makes - yes the only anti rolling shutter plugin for popular compositing applications available - now that algorithm could probably be implemented in camera - and bingo you have a HDR mode without temporal artificacts and less/no rolling shutter.

Maybe I am reading too much into it all but it does make some sense. And having that anti rolling shutter algorithm in camera - well that would be awesome in general ;)

these algorythms have their own artifacts - and have user interfaces for a reason - they don't just automatically fix everything without issue.

Besides, MX sensor is capable of completely rolling-shutter free output, which proved problematic of Red One, at least for now (not sure what the problems were - maybe heat related) but I;m sure will be running perfectly well on Epic. Anyway, rolling shutter is an overrated problem - I've seen it very few times in our footage, like maybe twice over thousand of clips to teh point where it was objectionable
 
I won't bother making a conjecture as to the actual function of this technology...but I will say that I look forward to putting it into practice!
 
I notice on the app for iPhone (first HDR program ive used), sometimes if the HIGHS are TOO high against the LOWS, it causes a glow or halo around the subjects in the overexposed shot. Same thing on the Canon 5d footage you can see floating around the internet. Don't know how this transfers over on EPIC though.

Are there any sort of anomalies that show up on HDR footage vs. non HDR footage ? For example more noise or artifacting ?
 
, rolling shutter is an overrated problem


I know that rolling shutter is better on Epic the idea was that each sensor line would be read out twice for the HDR function (this is the thread about HDR remember) and that would make the sensor 2x as slow hence you would introduce rolling shutter again probably to the tune where you have it on the red one now and my thought was that to mitigate that they used some of the rollingshutter code from the foundry.
And to say "rolling shutter is an overrated problem" you have probably never in your life needed to 3d track a shot with rolling shutter.

But I am on the wrong tree as Jannard put it so nicely - but was worth a thought ;)
 
Last edited:
My guess is that the sensor is being read twice, but not one complete sweep after the first. Its more like each row is read twice in the single scan. Think of two waves sweeping down the sensor, one right behind the other.

No matter how it works, I'm sure RED HDR is second to none!
 
Two questions:

It would seem impossible to increase dynamic range without also increasing exposure assuming the regular image were properly exposed (nearly saturating the cells) since on the bottom end noise is restricting DR. Does this approach require increasing exposure either through longer shutter times, bigger apertures or less ND? Apologies if this was answered up thread. I didn't see it.

Second question. In theory, could this approach be extended to arbitrarily large amounts of dynamic range given sufficient exposure? Stacking, long used in astrophotography, can offer up huge amounts of dynamic range (I've seen over 30 stops) with sufficiently short sub exposures and a sufficiently large number of them, or by combining long and short exposures together in the stack. Could this approach be used to duplicate those results?
 
Back
Top