HDRx Feature Request

[Gavin Greenwalt]

Since HDRx is a data hog I have a proposal: throw away most of the data.

If I have one track which is exposed properly and I have a +2 track I really only need about a 1-2 stop blending range. Yes you would lose the motion blur free 'tracker' pass which would be useful in some situations but as an alternative mode why not just ditch the bottom 9 stops of data and black it out.

if trackABitmap[x][y].value < 0.88 then (trackBBitmap.value = NULL) else ()

You could black out probably 90% of the image in most situations and really save media run time. It would make HDRx a no-brainer. If it's blown out... record it. If it's not blown out, ignore it.

 

[jake blackstone]

Great idea. No reason to record redundant data twice.

 

[Martin Stevens]

Genius.... I love common sense.

It would be great to have this as an option.

+1

 

[paulherrin]

I figured that's what they were working on already... good idea though, I obviously agree.

 

[Andrew Gentle]

I'm sure RED have considered this type of compression. I suppose it would depend on the way the blending worked as to how much you could block out. You would essentially be reducing the 16 bit sensor capture range down to a lesser number of bits and an offset to save data. How many you could get away with losing would depend on the point where the user wants to blend. Another issue may be the relative intensities. If HDRx blending works on the luminescence of the debayered pixel instead of the colour values, you may have thrown away information you need. For example, if you have an intense blue light which isn't emitting much red or green, the red and green values of that pixel, although low, could be still important. Even on the chance that it works interdependently on red, green and blue pixel values, the difficult part would be preempting the cutoff point ahead of blending in post production. The user is sacrificing flexibility for a reduced data rate.

Those are my thoughts, it's hard to say if it's possible without knowing how HDRx works but I think that if it were this simple, they would have already implemented something like it. I'm sure the solution Jim hinted at during the Scarlet announcement will be more complicated. Graeme is pretty clever. Perhaps since the pixel values in A frame and the X frame would often have a similar difference (proportional to the exposure, until the point of clipping), the wavelet compression they already use to compress the R3Ds could be adapted to work in pairs of pixel values for the same photosite instead of separate frames?

 

[Deanan]

We have another compression system we're working on for HDRx to enable higher rates on Scarlet.

 

[jake blackstone]

We have another compression system we're working on for HDRx to enable higher rates on Scarlet.

Higher rates, as in frame rates or compression rates?

 

[Deanan]

Higher rates, as in frame rates or compression rates?

Target is to get to 25fps HDRx on scarlet for 4K QHD.

 

[Nick Wernham]

Target is to get to 25fps HDRx on scarlet for 4K QHD.

That would be wonderful. I'm less concerned about the lack of slow motion (at least beyond the very modest slow motion that 30fps for 24fps playback would yield) in 4K QHD than I am about the lack of HDRx. Any way of making HDRx at a resolution with a lower crop factor would be a welcome addition.

 

[Jarek Zabczynski]

Target is to get to 25fps HDRx on scarlet for 4K QHD.

Any chance of 120fps in anything higher than 1k? I was really lusting for the 120fps 2k mode on the proposed Epic-S. 1.5k would be roughly 720p no?

 

[DJ Meyer]

Target is to get to 25fps HDRx on scarlet for 4K QHD.

Awesome.

 

[Gary Paul Walker]

We have another compression system we're working on for HDRx to enable higher rates on Scarlet.

Could such a new compression system be transposed to frame rates outside of of HDRx (of course, if you can't say anything for fear of spilling the secret sauce...)