What are the lines of resolution for 3K Scarlet

[Peter Majtan]

Peter, I totally understand, and all is fine. When I go into those long-winded explanations I am conscious that I'm not writing for an audience of one, this is there for all to see, so I try to explain it roundly and fully. In no way was I addressing you personally.

I've never taken this personally - quite the contrary - my point was that so many people (of different knowledge levels) will read our posts, so we do have responsibility to be accurate. No hard feelings here - we can drop this part...

The final summation of Scarlet having a 3K-sized recording frame, and making wonderful 2K finished products, is probably very accurate. My point was that we don't know what the total resolution will be until we test a finished product.

Point well made and accepted. We can drop this one too...

As far as pixels equating to end-frame pixels: I can't agree, because they don't. There is no direct correspondence at all. Genesis uses 12 million photosites in its sensor, and 2 million pixels in its recorded frame. Red uses 8 million pixels in its sensor, and 8 million pixels in its recorded frame. Panasonic uses 1 or 2 million pixels in each of its sensors, *3 = 3 million to 6 million sensor photosites, but 2 million pixels in their recorded frame. In the SD days you had a recorded frame of 345,000 pixels, yet you could have a Canon XL1 with 235,000 sensor photosites (per sensor) or you could have a Sony PDX10 with over a million photosites (per sensor) all recording to that same 345,000-pixel frame.

You cannot directly track the presence or existence of any particular photosite throughout the chain of imaging. There is no way to say that any particular sensor pixel "becomes" any final recorded frame pixel. Especially in a single-sensor system, where basically all the sensor photosites get thrown into a big "soup" of pixels, and new (entirely different) pixels are synthesized and extracted.

Now here is where we agree to disagree... If that was the case You could film night scene in Tokyo and end up with night scene of Paris if there was no direct correspondence between the photo-sites and recorder pixels. Please note here that "direct" does not equal "1:1". In case of RED (lets narrow this discussion to this forum) the photo-sites in the Bayer mosaic are interpreted with Graeme's voodoo magic into the final image. I bet You anything that You could pin-point all the relative photo-sites that influence the final computed pixel including their eact %-age of actual influence. Sure there is an overlap and same photo-site will "provide" their information to several surrounding pixels. But the actual level of influence can be precisely calculated by reverse-engineering the de-mosaicking algorithm. Custom filters are used to deal with aliasing and other related issues and at the end You end up with beautiful night scene of Tokyo, not Paris...

Further compounding it is that CCD sensors are analog devices. There is no way to access any individual sensor pixel. The CCD outputs an analog signal that needs to be sampled back into the digital domain -- it's more like a microphone in that aspect (and nobody ever asks if your microphone is "16-bit", right? Just because we're recording 16-bit digital audio, we don't go around shopping for "16-bit" microphones, do we? We all understand that microphones output an analog voltage signal, which needs to be "digitized" into 16-bit samples. Well, a CCD does the same thing.)

Not so with CMOS and since RED is not using CCD, let's focus on things relevant to this forum...

I'm just pointing out that sensor pixels are decoupled from recorded-frame pixels. In the case of the Red One, you'll have a front end where 2 million blue pixels, 2 million red pixels, and 4 million green pixels all get poured into the mix, stuck in the oven and baked, and out the other end will come 8 million 12-bit full-color RGB pixels. What happens in the sensor pixels influences what happens in the final pixels, obviously, but it's not like the sensor pixels are directly represented in the final recorded frame.

A) 8 million Bayer photo-sites will never result into 8 million RGB pixels - at least not if You care about quality and aliasing artifacts... This is where the Graeme's 78% VooDoo Magic comes to play... (I can see this becoming part of our slang just as 18% Grey :biggrin: )

B) They are represented - just not in 1:1 way, but rather their values (or partial values) are represented in a limited group of pixels (that can be identified) they are influencing based on the algorithm... Is it "direct"? Yes. Is it "1:1"? Not.

You can be "directly" represented on board of directors, but how much Your vote influence the final decisions depend on the "algorithm" of Your position...

Maybe is time for Graeme (or any other RED engineer) to step in and clarify this, because if I am wrong I would love to know as this will greatly affect two projects we are working on. No one is perfect...

 

[Barry Green]

Okay, time for a step back into the land of simplicity.

If you window the Red into 2048x1024 mode, you get mediocre 2K performance. If someone felt that the pixels on the sensor should represent the pixels on the final frame, they'll actually end up quite disappointed. It just doesn't work that way. Maybe if you were using a Foveon, but for anything else, no.

Yes, of course the photosites on the sensor are related to the final frame's outcome. My point is only in that the photosites on the sensor are mixed together and synthesized into something new. They are not used directly.