Active vs Full Array?

[Ivan G]

Is there anyway of recording Full Pixel Array? If not, why?

Active Pixel Array:
4520 (h) x 2540 (v)
Full Pixel Array:
4900 (h) x 2580 (v)

[Stuart English]

The maximum recordable pixel array is 4520 x 2540. The pixels outside of that area are used for sensor alignment.

[Ivan G]

The maximum recordable pixel array is 4520 x 2540. The pixels outside of that area are used for sensor alignment.

Ah ok. When would the sensor ever need to be aligned?

[Brook Willard]

While I believe sensor alignment goes beyond this, I know that they're used to set true "black" on the sensor.

[Jannard]

It is a bit more complicated than this, but we feel no need to explain exactly what we are doing. What matters is you can record incredible 4k REDCODE RAW with a look outside the recording area. Or you can record 4.5K with the RAW Port.

Jim

[Jay A. Kelley]

It is a bit more complicated than this, but we feel no need to explain exactly what we are doing. What matters is you can record incredible 4k REDCODE RAW with a look outside the recording area. Or you can record 4.5K with the RAW Port.

Jim

Come on Jim, don't be coy.. I'm sure people want to know ALL about your sensor... Hmm, guess that's not actually a "good" thing is it?

:)

Jay

[Axel Mertes]

It is a bit more complicated than this, but we feel no need to explain exactly what we are doing. What matters is you can record incredible 4k REDCODE RAW with a look outside the recording area. Or you can record 4.5K with the RAW Port.

Jim

Hi Jim,

now you confused me. You say we could use the RAW port. Recently Jarred nailed down that RAW port will not be released. We asked for the tech details, as we would be interested in making a third party solution here.

So, given RED will not do it on its own, contact us offsite the forum. The request is real.

Axel

[luis bustamante]

Yes, I agree with Axel (by the way, great footage! congrats). I don't need to know the inner works of the sensor, but I do wonder what you're planning as an alternative to get 60fps 4k out of the camera (or full 120 fps 2k). I even wonder if you've completely given up on the idea of letting people access the true RAW stream off the sensor (not that I need it, but some big budgeters might see a benefit to that craziness). I know you've stated repeatedly that you have some alternatives up your sleeve but still, it would be good to know.

[Chris Kenny]

4:1 compression with a modern algorithm can be as close to lossless as makes no difference, but is a lot more practical than uncompressed RAW. An external box that could compress a RAW signal like this and write it to a relatively small SATA array could be a pretty attractive solution.

For that matter... 4:1 compression is presumably a fair bit less processor-intensive than 12:1 compression. Maybe the camera even has enough processing power to do this on-board. If that were the case, you might be able to push 60 fps @ 4K out over the SATA interface that currently connects to the Red Drive (assuming it's SATA II, anyway), and therefore enable it with nothing more than a faster digital magazine and a firmware update. (Note that I'm not remotely qualified to say how plausible this is.)

And then there are all sorts of interesting possibilities involving recording to some sort of RAM buffer or highly parallel flash-based storage, and then dumping to cheaper storage slower than real-time. (The Phantom camera uses a RAM buffer like this.)

[jbeale]

I have no idea how Red's sensor works, but just as background: As far as I know, every single CCD or CMOS video camera ever made has more "total" pixels than "active" pixels. It's not something RED-specific. I believe these pixels are masked off with a metal layer during chip fabrication, and are used during operation to set the black level which naturally varies with temperature.

If temperature was the only factor, a few pixels would do it. But there are also minute processing variations across the die, causing minute changes in individual sense amps etc. giving you fixed-pattern noise in rows & columns. I believe that this can be factored out using the entire perimeter of dark pixels, looking at the variance of a given row against the average of all rows, and so forth. So, I suspect firmware build #12 used those perimeter dark pixels in some more effective way than earlier builds did, resulting in lower noise in dark or black areas. That's just the "obvious" stuff, Red may be doing something more clever. Was this geeky enough for you? :-)