Welcome to our community

Be a part of something great, join today!

Log in
  • 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 :)

HDRx success...and puzzler (DRAGON sensor or RR-X decoder vs. LEDs)

Michael Tiemann

Michael Tiemann

Well-known member
Joined
Oct 4, 2008
Messages
2,216
Reaction score
1
Points
38
Website
manifoldrecording.com
When I first got my EPIC DRAGON nearly 2 years ago, one of the first things I tried to do was to use HDRx to capture the blinking lights of my Buchla synthesizer. That experiment largely ended in failure because I could not figure out the right math.

Over the break, I'm tentatively declaring victory with my new WPN-W. Truth be told, now that I've learned the trick, I think I can make it work with any RED DRAGON camera (my own SCARLET DRAGON included). More about the success later.

The puzzler has to do with the way the camera (using the STD OLPF) reacts to progressively the progressively blurred out LEDs at the end of the sequence. I've put an R3D snapshot in a folder called "RR-X Torture" on DropBox: https://www.dropbox.com/sh/rq3ezuxsne146ky/AACTn2suRVyi2jNiv3ASnSWaa?dl=0

When I examine this frame in RCX using my RR-X, the blue and green orbs look like they were painted through a screen door. When I use software rendering, they are very grainy, as if the debayer algorithm really, really didn't want to split the differences between blue and green. For the record, we're looking into LED lights through a Canon 85L-II at f1.4, substantially blurred out, so I would expect these orbs to be smooth as can be. Strange that they are not smooth!

Anyway, back to my success story. UPDATED: as explained in a later post, I had better success with an enhanced version of tone-mapping.

For historical interest, here's what I thought would be a winning approach (and it kinda was) until I realized I was really papering over a problem that a simpler solution could better solve.

I figured out that for this application, I needed to create 3 layers (total) from my two sources (A and X frames). The bottom layer, which Resolve paints first, is the A frame. It anchors the image as-is. This frame is not enough because when the LEDs blink on with full intensity, they clip the sensor and thus render more white than colorful.

The second frame layered above the A-frame is a selection from the X frame, namely the pixels from the bright LEDs. Since the HDR knocks these down, they hold their color better, but it also means that their brightest true color is necessarily darker than the blown-out white they sit on top of, and as the light intensity falls off from the very center of the LEDs, that falloff gets even darker. When layered on top of the A-frame, the LEDs all look like they have raccoon eyes: a bright colorful center falling off to a saturated dark rink that then inexplicably becomes very bright and less saturated as it then finally decays to nothingness. The obvious, and wrong solution is to just let the X-frame's LED cover everything, blurring out its effect as wide as the underlying luminance of the LED in the A-frame. This is wrong because as the LED blinks, or as the focus blurs them out and they lose intensity as the light spreads out across the frame, there's a very artificial transition from X to A frame.

The solution is a third A-frame layer rendered on the very top. For this final over-painting, we select no pixels that are perfectly unsaturated, and we ramp up our selection until we get to pixels that are moderately saturated. This conveniently knocks out the ugly clipped highlights, allowing the beautiful X-frame colors to show through. But where there is realistic color in the A-frame, it has priority over the twilight coloring of the X-frame. What about a natural white, or an 18% gray card in the image? Not a problem: the top layer won't contribute any pixels, nor will the X-frame (not sufficiently luminous), so it's down to the bottom layer, which is the A-frame as-in. We get the unsaturated colors from there.

Maybe this is a good general solution after all!
Click to expand...

Here are 6 levels of HDRx, with sound, showing the superior tone-mapping results:

 
Last edited:
Thanks for sharing
 
Hello,

Thanks a lot for your research. I was also wondering how to preserve the color of a bright orange sunset. This could be a solution...
One question, isn't the Redgamma4 (wich clips the highlights over RG3) and DragonColor2 (edited) wich clips saturated led colors also the first problem of your test?

Pat
 
Patrick Tresch said:
Hello,

Thanks a lot for your research. I was also wondering how to preserve the color of a bright orange sunset. This could be a solution...
One question, isn't the Redgamma4 (wich clips the highlights over RG3) and RedColor2 wich clips saturated led colors also the first problem of your test?

Pat
Click to expand...

No...they clip in Linear Light, so they are well and truly clipped (in the A-frame).
 
Patrick Tresch said:
Yes they also clip but differently than in RG4 DC2.

PS: I meant DragonColor2 not Redcolor2
Click to expand...

Ah...Chroma clipping vs. Luma Clipping. I now see that when you are referring to my "problem", you were talking about the R3D puzzler, not the problem of getting a naturally-behaving HDRx result (independent of luma clipping).
 
I believe you can mix HDRx more accurately and more selectively within color-correction programs like Resolve.

I've also found about 75% of the time, you don't need to use the HDRx image at all: you'll have the exposure range to include all the detail, particularly with the newer Red cameras. It always helps if the shot is reasonably well-exposed. I've argued for a long time that HDRx isn't an excuse to shoot without lights, and we still have to constrict the dynamic range to make the image visible on a regular monitor. The trick is finding a way to do this precisely and selectively, and power windows/shapes and masks all help enormously.
 
Marc Wielage said:
I believe you can mix HDRx more accurately and more selectively within color-correction programs like Resolve.

I've also found about 75% of the time, you don't need to use the HDRx image at all: you'll have the exposure range to include all the detail, particularly with the newer Red cameras. It always helps if the shot is reasonably well-exposed. I've argued for a long time that HDRx isn't an excuse to shoot without lights, and we still have to constrict the dynamic range to make the image visible on a regular monitor. The trick is finding a way to do this precisely and selectively, and power windows/shapes and masks all help enormously.
Click to expand...

Marc, your comment made me doubt the approach I trumpeted at the start of this thread. Though you didn't stand up to defend tone-mapping (the approach that failed me when I first started this adventure two years ago), something in the way you wrote what you wrote made me realize that my three-layer premise was really a way of papering-over (with the third layer) what should be a more accurate selection process when dealing with the second layer (the X-layer). So I went on a merry chase trying to simply, but powerfully select the really right pixels for replacement. And lo, I came up with a better result using only two layers and...tone mapping!

What made the difference this time around was that I realized that I was not using the right LUMINANCE key. The wrong thing I was doing was to simply use a qualifier to select a threshold value of luminance from the X-channel for the key, but no matter how I tried to qualify it, blur it, deal with saturation, etc., I could never get a range that got all my LEDs to make a good key. The red LED (ironically) just wouldn't activate the key unless I used a very low luminance value--so low that lots of my wires started to get into the act. This created all sorts of HDR ghosting effects--very ugly. My a-ha moment was the realization that the REC 709 coefficients for translating RGB to monochrome (for the luminance values driving the key) were just not right for my application. I figured out a set of coefficients that caused my red, amber, yellow, green, and blue LEDs to all have very similar luminance values, and WOW did that made a large difference. With a much better behaved key, tone mapping suddenly became a much simpler prospect.

One of the trickiest parts of this particular setup is to make the transition from out-of-focus to in-focus look credible. When the LEDs are out of focus, the light is spread out across the whole region of the bokeh. It's a 2-stop reduction in intensity for every doubling of the size of the bokeh vs. the initial source. Thus a blur that's 16x larger than the original source, the LED intensity value drops 2 * 4 stops = 8 stops. Which means that when substantially blurred, the LEDs in the A-frame will be lower in intensity than in-focus LEDs in the X-frame, even when the X-frame is 6 stops below the A-frame. The challenge then becomes--how to credibly shift from sourcing the blurred-out A-frame to sourcing the sensibly-exposed X-frame as the focus becomes tighter, without going too far down in intensity in the middle. The first solution I came up with was to use a corrector node with a long-ish ramp on the qualifier so that when luminosity of the X-frame was very low, it didn't trump the A-frame, but as the luminosity rose to its max level on the X-frame, it did trump the A-frame. But that still had a pretty big dip in the middle because the linear ramp brought too much X-frame in too soon. I solved that problem by also defining a similarly long ramp feeding the KEY input of the corrector. This basically gave me a quadratic, rather than a linear ramp, which meant that it only really started to come on as the focus really tightened up. The result is not entirely artifact free, but the artifacts look credible to me.

The net result of all of the above, for me, is validation that simple approaches to HDRx can lead to powerful results, if you have tools powerful enough to make the problems simple.

I'm rendering new videos now and will edit the head of this thread so that people looking for answers can find them in obvious places rather than somewhere near the end of the thread.
 
This is a fantastic post Michael - thanks for sharing! I love that there are solutions for HDRx like this. I wonder if Red can update their HDRx processing to take account of the luminance translations the way you have, in their slider system?

Cheers,

Paul :)
 
You must log in or register to reply here.
Back
Top