#21...

[gbalaji]

Well, For Epic with modular design, Can two cameras combine to form HDR using 3D RIG with manual control in shutter speed, f-stop, ISO cant be better than single camera intend to do HDR?

 

[Lawrence Bansbach]

If it's related to read/reset times as Peter suggested, then I assume we would see the return of the skew that was present in the early builds of RED One or like on other slower sensors like the Nikon D90 or others. Since the sensor would compound times to produce a single image, a native read/reset time of 5ms would turn into 10-12ms for HDR in the scenario outlined by Peter earlier.

Even if the HDR process involves the read-reset time, how do you know Red hasn't found a way to reduce the native, non-HDR read-reset time to, say, 2-3 ms to compensate?

 

[JD Holloway]

Who said it had to reset?

You could read Vo at photosites several times and not reset until the 1/48 shutter duration was complete. Vo's could then be re-mapped log/lin and output via normal ASIC as R3D. This could be one "mode". It would be a sort-of "data/voltage reciprocity failure" where the output Vo doesn't represent linearly the exposure light...like film. photosites that collect high voltages early (will overexpose and blow out) will contribute data only from early in their read cycles in the final r3d

:confused5:

...but who knows...

Heck maybe the photosites can leak voltage as they fill up with some other route to ground before the normal read/reset.

 

[Rick Burnett]

Even if the HDR process involves the read-reset time, how do you know Red hasn't found a way to reduce the native, non-HDR read-reset time to, say, 2-3 ms to compensate?

The question I have is pertaining to just reading. What if you don't reset? That way, while the sensor is recording, you make a quick pass of reads that don't reset. You lose the time while the row is reading out, but as you can imagine, that is a VERY short period of time per row. This is to grab your highlight data that will be blown out. Then, at the normal end of the exposure, you read out like normal. Then you have two frames that are actually the same thing, you just saved the highlights before they blew out. (And I think motion is the shot is fine because of motion blur and what you'd see.)

 

[JD Holloway]

3 mins lol

 

[Rick Burnett]

3 mins lol

Haha, nice! Just beat me to it! Damn proofreading!

 

[Bill Anderson]

Reaching one set of values means (potentially) passing through many sets of values- particularly in the lower end of the scale, I would imagine, as far as manageable temporal space is concerned. Just as walking from A to B entails passing through many states, so does the data describing the light that hits the sensor???? If one could access that (intermediate) data and intermix it with another temporal state's data then... ???
Just a film addled brain's guess. It's one thing to imagine the advantages of such a feat, and an other thing making it work.

 

[Steven Hammer]

Well if it needs to be processed in camera, like it seems to be the case, then it's not RAW anymore, is it ?
I guess all depends on what they're doing exactly, which we don't know for sure.

It will be interesting to see what kind of file HDR mode outputs. Will it be a 16 bit RAW file, but with a higher dynamic range? A 20-bit RAW file? Or, is the bump from 12-bit to 16-bit being done to accomodate HDR mode?

OR

Two (or more) 16-bit RAW files that are combined later in post?

 

[Chris Kenny]

The question I have is pertaining to just reading. What if you don't reset? That way, while the sensor is recording, you make a quick pass of reads that don't reset. You lose the time while the row is reading out, but as you can imagine, that is a VERY short period of time per row. This is to grab your highlight data that will be blown out. Then, at the normal end of the exposure, you read out like normal. Then you have two frames that are actually the same thing, you just saved the highlights before they blew out. (And I think motion is the shot is fine because of motion blur and what you'd see.)

The initial readout, if it were taken, say, halfway through exposing the frame, would only show half the amount of motion blur -- on a 1/48 exposure, it would be identical to a standalone frame shot at 1/96. So the trick then becomes, how do you combine that with the full 1/48 exposure in a way that doesn't create artifacts?

 

[Bill Anderson]

But then there is the HDR in-camera post treatment of the data from a single frame,
through the (theoretical) application of the best of two or three different ISO performances. I mean how many ways are there to skin this cat without approaching (temporal based) image registering type issues... ????

 

[Gavin Greenwalt]

The initial readout, if it were taken, say, halfway through exposing the frame, would only show half the amount of motion blur -- on a 1/48 exposure, it would be identical to a standalone frame shot at 1/96. So the trick then becomes, how do you combine that with the full 1/48 exposure in a way that doesn't create artifacts?

The idea is that you shoot *2* 1/96 exposures and then add them together. Then the motion blur (assuming there is no delay between the two exposures results in a single 1/48th exposure.

But RED has already said that's not what they're doing so the details of that methodology aren't terribly important.

 

[Casey Green]

The speculation on EPIC's HDR mode can end... schematics of how the sensor and processing works released:

But seriously, keep up the amazing work guys! ;-)

 

[jonnycom]

How's it going down at WETA? Tell Peter I say hi.

I can't wait to try HDRx.

Here's our version of HDR with non MX sensors, I think we are getting between 16 and 18 stops of DR.

http://vimeo.com/12828140

 

[Jeff Coatney]

The idea is that you shoot *2* 1/96 exposures and then add them together. Then the motion blur (assuming there is no delay between the two exposures results in a single 1/48th exposure.

But RED has already said that's not what they're doing so the details of that methodology aren't terribly important.

Yeah, but it doesn't mean that a secondary exposure can't be used as a mathematical basis for interpretation of the previous frame or the following frame. This would only need a secondary exposure every fourth or fifth or more frames. The RAW data is captured off the sensor like normal, including higher frame rates, then a reference frame is taken to determine highlight protection at some interleaving interval that forms the basis for reinterpreting the original data.

This would allow the claimant to state that they are not doubling the frame rate to achieve the HDR data necessary to reconstruct the shot, which is the most accessible way of getting the extra stops. But since we're talking about a finite range of sensor feedback (for example 0 to 1000 levels of light amplification per photosite per channel) then taking a reference frame at lower ISO settings would give us the computational road-map (in theory) to re-interperet the RAW data of the shot that was taken at 800 ISO without limiting the camera's overall frame rate range more than 5% to 10%

Not related but cool: If you have inertial data that tells you how fast the camera is moving, then a slower moving camera would require fewer referential samples than a camera that's moving very fast. A faster camera movement, in theory, has less kinetic image predictability frame to frame than a slower moving camera. If the camera moves slowly, then it is theoretically possible to "predict" the image information on future frames based on previous frames. In fact, at higher frame rates, this predictable pattern would be increased, so you could (--sigh-- in theory) need less HDR reference frames to accomplish the HDR.

Actually, using this method may only require one or two referential frames per take, because you are only concerned about the highlight protection, you probably only need enough data to determine the clipping and falloff rates in the shot, per photosite, per channel. This is all post-processing, BTW.

 

[Gavin Greenwalt]

Actually, using this method may only require one or two referential frames per take, because you are only concerned about the highlight protection, you probably only need enough data to determine the clipping and falloff rates in the shot, per photosite, per channel. This is all post-processing, BTW.

This would do little to nothing though for something like tail lights in a city.

It would work fine for the sky but not well for anything that changes such as tail lights, fire, explosions, moving clouds (clouds move surprisingly fast even in short takes).

Optical flow isn't up to the task yet. And there have been been some papers in doing just this. I was talking to one of the SIGGRAPH paper writers from a few years ago. They had some interesting proof of concepts in using a high dynamic range set of 'key frames' to enhance a low dynamic range, low resolution video. But again... has to be a static subject, still is full of artifacts and isn't really usable yet for production without a bunch of cleanup. Except as a shortcut on what would already be an FX shot the tech just isn't there and it's full of 'gotchas'. Not to mention that your over-brights would also need motion blur applied since they would be too crisp. Think headlines driving through frame. There would be a lot of motion blur on the headlights... Good luck reconstructing a HDR from a single fast shutter still and tracking it to a white streak.

 

[Rick Burnett]

This would do little to nothing though for something like tail lights in a city.

It would work fine for the sky but not well for anything that changes such as tail lights, fire, explosions, moving clouds (clouds move surprisingly fast even in short takes).

Optical flow isn't up to the task yet. And there have been been some papers in doing just this. I was talking to one of the SIGGRAPH paper writers from a few years ago. They had some interesting proof of concepts in using a high dynamic range set of 'key frames' to enhance a low dynamic range, low resolution video. But again... has to be a static subject, still is full of artifacts and isn't really usable yet for production without a bunch of cleanup. Except as a shortcut on what would already be an FX shot the tech just isn't there and it's full of 'gotchas'. Not to mention that your over-brights would also need motion blur applied since they would be too crisp. Think headlines driving through frame. There would be a lot of motion blur on the headlights... Good luck reconstructing a HDR from a single fast shutter still and tracking it to a white streak.

This is a very good point, because the problem is, the bucket (if you will) for measuring photon activity is just not deep enough. The problem comes down to how fast the bucket fills up relative to the time the frame is active. I think your example of the tail lights is perfect, as the movement of the bright source means that it's already blown out the frame where the lights don't even exist anymore on the sensor. Hadn't thought of it that way but that certainly explains why it isn't going to work for moving objects.

In principle, if you divided any shot into multiple exposures without reset, you could measure the point on any pixel where it blows out, but from that point forward, the data existing before it blew out is not representative of what is happening after that point in time, with moving objects, and therefore would make it difficult. You'd need a reset to allow that newer data to get captured.

The question becomes how long is a row off while it reads and resets. (not the whole sensor, as we just care about the data lost during that time). If we know the sensor takes 5ms to read/reset all the lines, one line could take (assuming 2304 lines) 2.17uS of time. To me that doesn't sound like a lot of time lost, the question becomes how much error you see in the motion at the point when you add the two exposures together.

Unless I misunderstand the read/reset value's meaning.

 

[Álex Montoya]

A far fetched ocurrence: maybe they can make say four photosites work as just one improving sensitivity and latitude?

 

[Rick Burnett]

A far fetched ocurrence: maybe they can make say four photosites work as just one improving sensitivity and latitude?

I don't think that is far fetched at all personally. Having two different sensitivity photosite under the same filter color could allow for detecting a larger range.

 

[Will Devine]

How's it going down at WETA? Tell Peter I say hi.

I can't wait to try HDRx.

Here's our version of HDR with non MX sensors, I think we are getting between 16 and 18 stops of DR.

http://vimeo.com/12828140

wow man, it really gives a nice sparkle on the highlights. You have a nice curve on that.

I want a Scarlet more than anything... except an Epic maybe... blah blah.

Don't know why I check this site every few minutes, I can't afford a Scarlet now even if it was released.

 

[Lee Saxon]

A far fetched ocurrence: maybe they can make say four photosites work as just one improving sensitivity and latitude?

Not at all far fetched. Some of Phase One's digital backs do this, they call it pixel binning.