ProRes 4444 12bit Recording

Did some more searching around. Could not find a single camera that has a single CMOS sensor that produces 4:4:4 files and has an actual 4:4:4 data, be it rgb or anything else, at a native resolution. All of the cameras that write actual 4:4:4 data do so from a larger then 1080p sensor into a file that has resolution of 1080p.
Yes, I understand that 4:4:4 refers to encoding. What I also understand that 4:4:4 encoding must be a direct result of available data. Otherwise it's just a scam by marketing departments.

Did some more searching around. Could not find a single camera that has a single CMOS sensor that produces 4:4:4 files and has an actual 4:4:4 data, be it rgb or anything else, at a native resolution. All of the cameras that write actual 4:4:4 data do so from a larger then 1080p sensor into a file that has resolution of 1080p.
Yes, I understand that 4:4:4 refers to encoding. What I also understand that 4:4:4 encoding must be a direct result of available data. Otherwise it's just a scam by marketing departments.

CMOS sensors produce a raw analogue signal - which is then sometimes electronically amplified - which is then sent to a ADC - which is then sometimes digitally amplified - which is then stored as raw bayer pattern data or raw data based on however the sensor in question is able to capture an image.

To say a sensor in itself could produce a 4:4:4 file is to demonstrate a misunderstanding of terminology and technology.

When the raw bayer sensor data is debayered, the data is truly RGB data - which can then be encoded into a video file which can be described as having no chroma sub-sampling or in other words, 4:4:4.
Alternatvly, you can get Foveon X3 sensors - which happen to be able to read full RGB values per photosite before processing - can also then be saved as a video file which no chroma sub-sampling - or 4:4:4.


You are not being scammed by a marketing department, you just do not completely understand the process.

Did some more searching around. Could not find a single camera that has a single CMOS sensor that produces 4:4:4 files and has an actual 4:4:4 data, be it rgb or anything else, at a native resolution. All of the cameras that write actual 4:4:4 data do so from a larger then 1080p sensor into a file that has resolution of 1080p.
Yes, I understand that 4:4:4 refers to encoding. What I also understand that 4:4:4 encoding must be a direct result of available data. Otherwise it's just a scam by marketing departments.

CMOS sensors produce a raw analogue signal - which is then sometimes electronically amplified - which is then sent to a ADC - which is then sometimes digitally amplified - which is then stored as raw bayer pattern data or raw data based on however the sensor in question is able to capture an image.

To say a sensor in itself could produce a 4:4:4 file is to demonstrate a misunderstanding of terminology and technology.

When the raw bayer sensor data is debayered, the data is truly RGB data - which can then be encoded into a video file which can be described as having no chroma sub-sampling or in other words, 4:4:4.
Alternatvly, you can get Foveon X3 sensors - which happen to be able to read full RGB values per photosite before processing - can also then be saved as a video file which no chroma sub-sampling - or 4:4:4.


You are not being scammed by a marketing department, you just do not completely understand the process.

Tom, going to repeat again, this time with an emphasis: "Could not find a single <b>camera</b>, that has a single CMOS sensor, that can produce....", or perhaps I should use this structure: could not find a single camera that produces 4:4:4 at a native resolution, that uses a single CMOS sensor.
Yes, I understand the technology perfectly well. Please mention a single camera model that makes 4:4:4 files at the sensor resolution.

Tom, going to repeat again, this time with an emphasis: "Could not find a single <b>camera</b>, that has a single CMOS sensor, that can produce....", or perhaps I should use this structure: could not find a single camera that produces 4:4:4 at a native resolution, that uses a single CMOS sensor.
Yes, I understand the technology perfectly well. Please mention a single camera model that makes 4:4:4 files at the sensor resolution.

What you are asking is like asking someone to name a car engine which is 4 wheel drive. The engine is able to provide power to a system which then would turn 4 wheels - the engine itself is not part of what makes the car 4 wheel drive - such things are further down the line.


The BMCC has a single CMOS sensor, which when it has its data processed -can output a full RGB 4:4:4 video file at the resolution of 2400x1350.

You are still confusing oversampling and sub-sampling.


Another example of something (which is still not what you are asking for) is the Sigma SD9 - which features a sensor capable of outputting full RGB data from each photosite. It has a sensor resolution of 2268x1512 and also can be encoded into a true full RGB 4:4:4 video file.

The nature of your question is a demonstration that you do not still understand. I understand what you are trying to ask - but you are still using incorrect terminology.

Tom, unfortunately, your Sigma example doesn't really not work here, as we are talking about the Bayer pattern CMOS sensors.
Please, to prove me wrong, provide a name of a camera that produces a 4:4:4 files (ProRes in this particular case) at a native resolution, with a single CMOS Bayer pattern sensor.

Tom, unfortunately, your Sigma example doesn't really not work here, as we are talking about the Bayer pattern CMOS sensors.
Please, to prove me wrong, provide a name of a camera that produces a 4:4:4 files (ProRes in this particular case) at a native resolution, with a single CMOS Bayer pattern sensor.

Ok, first of all you said "Could not find a single camera that has a single CMOS sensor that produces 4:4:4 files" - you did not mention it having to be a bayer pattern sensor.

Second of all - of all the bayer CMOS sensors I can think of - they ALL are able to produce a 4:4:4/RGB file. Well, actually the sensor of course does not produce the file, but the image from the sensor can be processed to output such a file.

As for it being a ProRes file, you can take the raw Sensor data from the BMCC and export it as a ProRes 4:4:4 file, or Cineform 4:4:4 etc.

The problem here is that you keep referring to data from a sensor as "4:4:4" - the type of data from an image sensor is not the type of data which CAN be described as 4:4:4, 4:2:2, 4:2:0 etc - such things describe video data, Bayer sensors do not produce Video data. It would be like asking me to name a sensor which produces h.264 data. I can name many cameras which save h.264 video files, but this has nothing to do with the sensor or it being a bayer CMOS.

Also, it has been brought to my attention by a user that the tone of my responses could be considered insulting or unfriendly - I would like to publicly apologise for any offence inadvertently caused. It is never my intention to insult or be rude to anyone on here, I am just trying to explain something in clear and direct terms.

Tone is something which is very hard to express in such direct messages, so please do always consider my
responses to be friendly and relaxed, I seek to learn on here as much as I do to share what I know.

Nobody knows everything, or understands everything - it is natural for us all to have misconceptions or think we know things that are actually incorrect, if someone challenges such things or counters such things, it should not be taken as a personal attack.

If you feel as though my response could be considered rude or unfriendly - please give me the benefit of the doubt and assume that I did not mean it that way.

Also, it has been brought to my attention by a user that the tone of my responses could be considered insulting or unfriendly - I would like to publicly apologise for any offence inadvertently caused. It is never my intention to insult or be rude to anyone on here, I am just trying to explain something in clear and direct terms.

Tone is something which is very hard to express in such direct messages, so please do always consider my
responses to be friendly and relaxed, I seek to learn on here as much as I do to share what I know.

Nobody knows everything, or understands everything - it is natural for us all to have misconceptions or think we know things that are actually incorrect, if someone challenges such things or counters such things, it should not be taken as a personal attack.

If you feel as though my response could be considered rude or unfriendly - please give me the benefit of the doubt and assume that I did not mean it that way.

You now owe everyone a beer.

You now owe everyone a beer.

You now owe everyone a beer.

Oh ok then :-p

Bayer sensors do not produce Video data.

Tom, would you know where I could find a technical description of BM raw files? BMPCC preferably. How many actual bytes per pixel, how they are packed (36 bits packed into five bytes? Or even tighter?), metadata / headers - although the last one I could glimpse from generic CinemaDNG articles, I guess. My goal is to figure the max theoretical data rate of BMPCC lossless raw (assuming hard-to-compress images), as well as BM's other cameras.

Thought you might have it bookmarked somewhere, given the wealth of knowledge you're sharing.

Thanks!

Bayer sensors do not produce Video data.

Tom, would you know where I could find a technical description of BM raw files? BMPCC preferably. How many actual bytes per pixel, how they are packed (36 bits packed into five bytes? Or even tighter?), metadata / headers - although the last one I could glimpse from generic CinemaDNG articles, I guess. My goal is to figure the max theoretical data rate of BMPCC lossless raw (assuming hard-to-compress images), as well as BM's other cameras.

Thought you might have it bookmarked somewhere, given the wealth of knowledge you're sharing.

Thanks!

In short no, however if my calculations are correct (or more precisely, my process)

The BMCC has a sensor resolution of 2432x1356 - so it is comprised of: 3,297,792 photosites, at 12 bits per photosite = 39,573,504 Bits
= 4,946,688 Bytes
= 4947 Kbytes
= about 5Mb per frame (which is the case for the BMCC)

I have no idea if this method is actually accurate or just me making a big assumption, but if it is true, then....

On the Pocket camera:

1920x1080 = 2,073,600 Photosites
= 24,883,200 Bits
= 3,110,400 Bytes
= 3,110 Kbytes
= about 3 Mb Per frame.

This is obviously only for the DNG frames, you would have to factor in Audio also. I assume Meta Data is only written at the start or end of the recording, so it would not really be a factor in data rate.

These values are also only for uncompressed Raw - as for lossless compression - It depends on the compression method.

Not really cast iron or helpful info I am afraid -but I hope it helps even slightly. I am making many big guesses here so I am likely about to be proven wrong :-p

...at 12 bits per photosite

That's the part that confuses me I guess... I realize each photosite is sampled at 12 bits for the whole site (pixel) and not for each color component... but thought that after debayering and what not, the image was presented with 12 bits for each color component, given BMPCC's 1080p "12-bit raw RGB" moniker. I guess I was terribly wrong...

...at 12 bits per photosite

That's the part that confuses me I guess... I realize each photosite is sampled at 12 bits for the whole site (pixel) and not for each color component... but thought that after debayering and what not, the image was presented with 12 bits for each color component, given BMPCC's 1080p "12-bit raw RGB" moniker. I guess I was terribly wrong...

At a sensor level, the initial data to come from each photosite is not even digital information, its an analogue signal. This signal is sampled at 16 bits (apparently) but mapped into a 12 bit DNG file. Before debayering, the data per photosite is not even colour data, its a luma value of either Red, Green or Blue. When debayering occurs, the RGB value of each photosite is calculated based on the surrounding photosite values and the one in question. The Result of this is full RGB data per pixel. Depending on how you debayer the footage will depend on the quality and accuracy of the RGB values -but nevertheless, they are full RGB data values in a 12 bit form.

...mapped into a 12 bit DNG file... ... full RGB data values in a 12 bit form.

4 bits per color component? Or each pixel represents only one color? (I tried reading about it, and now my head hurts, and I need a beer.)

Tom, unfortunately, your Sigma example doesn't really not work here, as we are talking about the Bayer pattern CMOS sensors.
Please, to prove me wrong, provide a name of a camera that produces a 4:4:4 files (ProRes in this particular case) at a native resolution, with a single CMOS Bayer pattern sensor.

Ok, first of all you said "Could not find a single camera that has a single CMOS sensor that produces 4:4:4 files" - you did not mention it having to be a bayer pattern sensor.

Second of all - of all the bayer CMOS sensors I can think of - they ALL are able to produce a 4:4:4/RGB file. Well, actually the sensor of course does not produce the file, but the image from the sensor can be processed to output such a file.

As for it being a ProRes file, you can take the raw Sensor data from the BMCC and export it as a ProRes 4:4:4 file, or Cineform 4:4:4 etc.

The problem here is that you keep referring to data from a sensor as "4:4:4" - the type of data from an image sensor is not the type of data which CAN be described as 4:4:4, 4:2:2, 4:2:0 etc - such things describe video data, Bayer sensors do not produce Video data. It would be like asking me to name a sensor which produces h.264 data. I can name many cameras which save h.264 video files, but this has nothing to do with the sensor or it being a bayer CMOS.

Tom, please see my previous posts in this thread. It is obvious that we are talking about Bayer pattern sensor. To that point, I mentioned foveon sensor myself as one of the ways of getting real color data for each pixel at a native sensor resolution.
Looking at the digital cinema cameras by various manufacturers, I am failing to find a single one that produces files that are 4:4:4 at the native sensor resolution.

Tom, unfortunately, your Sigma example doesn't really not work here, as we are talking about the Bayer pattern CMOS sensors.
Please, to prove me wrong, provide a name of a camera that produces a 4:4:4 files (ProRes in this particular case) at a native resolution, with a single CMOS Bayer pattern sensor.

Ok, first of all you said "Could not find a single camera that has a single CMOS sensor that produces 4:4:4 files" - you did not mention it having to be a bayer pattern sensor.

Second of all - of all the bayer CMOS sensors I can think of - they ALL are able to produce a 4:4:4/RGB file. Well, actually the sensor of course does not produce the file, but the image from the sensor can be processed to output such a file.

As for it being a ProRes file, you can take the raw Sensor data from the BMCC and export it as a ProRes 4:4:4 file, or Cineform 4:4:4 etc.

The problem here is that you keep referring to data from a sensor as "4:4:4" - the type of data from an image sensor is not the type of data which CAN be described as 4:4:4, 4:2:2, 4:2:0 etc - such things describe video data, Bayer sensors do not produce Video data. It would be like asking me to name a sensor which produces h.264 data. I can name many cameras which save h.264 video files, but this has nothing to do with the sensor or it being a bayer CMOS.

Tom, please see my previous posts in this thread. It is obvious that we are talking about Bayer pattern sensor. To that point, I mentioned foveon sensor myself as one of the ways of getting real color data for each pixel at a native sensor resolution.
Looking at the digital cinema cameras by various manufacturers, I am failing to find a single one that produces files that are 4:4:4 at the native sensor resolution.

I have answered this question several times now.

The BMCC is such a camera.

The BMCC is such a camera.

Not at 12-bit for each color component - or not at full resolution. It's either or.

Isn't a signal described as "12-bit raw 4:4:4" presumed to be RGB, i.e. have 12 bits for each color component, unless it's specifically described as composite?

E.g. "Storage and Data Rates for Uncompressed Video" are all listed based on a specified number of bits for each color component: if it's 8-bit 4:2:2 YUV, then it's 8 bits for Y, 4 for U, 4 for V, per pixel.

Seems to me, if you want to call something "12-bit raw 4:4:4", and it's not 12 bits for each color component, you'd want to explicitly state that. Like, "12-bit raw 4:4:4 composite". Just a thought.

...nevertheless, they are full RGB data values in a 12 bit form.

I keep reading this, and keep thinking, "full RGB values? Full means 12 bits for each of the R, G and B, per pixel, right?". Otherwise they aren't full, they're just "equally sampled" and packed at 4 bits for each color component per pixel, on the average.

If not, what am I missing here?

...nevertheless, they are full RGB data values in a 12 bit form.

I keep reading this, and keep thinking, "full RGB values? Full means 12 bits for each of the R, G and B, per pixel, right?". Otherwise they aren't full, they're just "equally sampled" and packed at 4 bits for each color component per pixel, on the average.

If not, what am I missing here?

4:4:4 just means that the file has no chroma sub-sampling. The Raw Cinema DNG files from the BMCC are still image files with no chroma sub-sampling.

When debayered, each pixel at the same resolution as the image sensor - contains full RGB data with no chroma sub-sampling. So it is true to say that the BMCC can produce 4:4:4 images.

The BMCC is such a camera.

Not at 12-bit for each color component - or not at full resolution. It's either or.

Isn't a signal described as "12-bit raw 4:4:4" presumed to be RGB, i.e. have 12 bits for each color component, unless it's specifically described as composite?

E.g. "Storage and Data Rates for Uncompressed Video" are all listed based on a specified number of bits for each color component: if it's 8-bit 4:2:2 YUV, then it's 8 bits for Y, 4 for U, 4 for V, per pixel.

Seems to me, if you want to call something "12-bit raw 4:4:4", and it's not 12 bits for each color component, you'd want to explicitly state that. Like, "12-bit raw 4:4:4 composite". Just a thought.

When the footage is debayered, each pixel contains full 12 bit RGB data. Which is therefore 4:4:4.

4:4:4 just means that the file has no chroma sub-sampling.

You are sure about that? Like, absolutely sure about that?

To me, 4:4:4 means equal relationship between how components are sampled. That could mean RGB which doesn't have a separate luma component and where "chroma subsampling" is meaningless.

When debayered, each pixel at the same resolution as the image sensor - contains full RGB data with no chroma sub-sampling.

You're saying that somehow you're getting "full" (no extrapolation, up-resing or other lossy trickstery) 36 bits out of 12 original ones? I am curious about the math behind it. Last I heard, gold still couldn't be made out of lead without throwing nukes at it.

When the footage is debayered, each pixel contains full 12 bit RGB data. Which is therefore 4:4:4.

"Full" 12-bit RGB - that's 12-bit per each color component (36 bits total), or 12 bits for the whole thing?

If for the whole thing (according to the spec, that seems to be the case), then it's either a 4-bit "full" RGB, or it's not RGB, i.e. each pixel represents one of the colors.

When the footage is debayered, each pixel contains full 12 bit RGB data. Which is therefore 4:4:4.

"Full" 12-bit RGB - that's 12-bit per each color component (36 bits total), or 12 bits for the whole thing?

If for the whole thing (according to the spec, that seems to be the case), then it's either a 4-bit "full" RGB, or it's not RGB, i.e. each pixel represents one of the colors.

Tom seems to think that debayering can do magic and create data out of thin air. Yet there isn't a single Bayer pattern cmos single sensor camera that produces 4:4:4 at the native sensor resolution.

Tom seems to think that debayering can do magic and create data out of thin air. Yet there isn't a single Bayer pattern cmos single sensor camera that produces 4:4:4 at the native sensor resolution.

The problem is that you're using the wrong terminology.

4:4:4 only applies to encoded video and it's totally wrong to describe bayer sensor data in this way.

Yes the ratio is never going to be even for each colour channel but saying 4:4:4 is not the correct way to describe the point you're trying to make...that no bayer sensor ever has the same ratio of pixels for each colour channel.

We all know this. It's just wrong to describe it as 4:4:4

jb

When the footage is debayered, each pixel contains full 12 bit RGB data. Which is therefore 4:4:4.

"Full" 12-bit RGB - that's 12-bit per each color component (36 bits total), or 12 bits for the whole thing?

If for the whole thing (according to the spec, that seems to be the case), then it's either a 4-bit "full" RGB, or it's not RGB, i.e. each pixel represents one of the colors.

Tom seems to think that debayering can do magic and create data out of thin air. Yet there isn't a single Bayer pattern cmos single sensor camera that produces 4:4:4 at the native sensor resolution.

I can imagine that It would seem magic to someone who does not understand the process, but it is far from it.

4:4:4 just means that the file has no chroma sub-sampling.

You are sure about that? Like, absolutely sure about that?

To me, 4:4:4 means equal relationship between how components are sampled. That could mean RGB which doesn't have a separate luma component and where "chroma subsampling" is meaningless.

When debayered, each pixel at the same resolution as the image sensor - contains full RGB data with no chroma sub-sampling.

You're saying that somehow you're getting "full" (no extrapolation, up-resing or other lossy trickstery) 36 bits out of 12 original ones? I am curious about the math behind it. Last I heard, gold still couldn't be made out of lead without throwing nukes at it.

Regardless of what 4:4:4 means to you - what it means is what it means. It means that the video data has RGB data for each pixel and no chroma subsampling is occurring.

And yes, I am absolutely sure about this.

If you are curious about debayering process and the mathematics behind it, I suggest you have a look at this: http://www.stark-labs.com/craig/resourc ... ng_API.pdf
This: http://www.siliconimaging.com/RGB%20Bayer.htm
or this: http://www.ipol.im/pub/art/2011/bcms-ssdd/

On this site (http://www.cambridgeincolour.com/tutori ... ensors.htm) it even says:

Bayer "demosaicing" is the process of translating this Bayer array of primary colors into a final image which contains full color information at each pixel

Needless to say, the result of the debayering process is that via algorithmic interpolation - each debayered pixel contains RGB data at the said bit depth. If you were to compare this to an image of equal resolution but from a sensor where every photosite had RGB data, and so no interpolation has to occur - the actual difference in chroma data between the two images would depend on how sophisticated the debayering method was - but at best the difference would not be huge. The difference would also be very very much different from a comparison of a 4:4:4 video file to a 4:2:2 video file.

Whether from interpolation or not - the data is still at the same bit depth and contains full RGB data per channel - as such it is 4:4:4 RGB. Before becoming video data, while it is still raw data - such terms do not apply because it is not yet even video data.

Again - the number 1 point of debate going on here is still nothing to do with debayering or oversampling or having RGB data or anything like that - it is the fact that people keep describing a bayer pattern sensor in incorrect terms.

A very crude but simple demonstration can be found on the wiki page:




None of the above images in a real situation could be described as 4:4:4 or 4:2:2 or RGB or anything - they are not actual image or video data. You would be equally as incorrect to describe them as an mp3 file or text data.


The sharpness and edge quality would depend on the sophistication of the debayering process, but just as even wikipedia says:

A digital camera typically has means to reconstruct a whole RGB image using the above information

To crudely simulate a very simply debayering process, a bicubic interpolation is applied via photoshop:

Result:


Original:




Now to be clear - the simulation demosaicing process here is not really a great demonstration of how good some process can be - but it at least shows you that the end result - whether it is faithful or not - it is still full RGB 4:4:4 data.



Here is another quick example:


This is a example of it in is bayer form - again, although it is represented here as an image - the reality is that real bayer data is not even processed this far.


Process: convolved with the Gaussian kernel


Process: Threshold-based combination of the convolution with the inverted PSF and the Gaussian (background areas)


Finally, a quick gif showing the difference between the original and debayered version:



There is of course a difference - but the point is that both result in a 4:4:4 RGB image after debayering.

It's just wrong to describe it as 4:4:4

Thanks John,

Something like RGBG is a more acceptable way to describe it?

Regardless of what 4:4:4 means to you - what it means is what it means. It means that the video data has RGB data for each pixel and no chroma subsampling is occurring.

We're getting into semantics but still:

In the encoded signal, "chroma subsampling" can only apply to signals with separate luma and chroma components. I.e. it's meaningless with respect to RGB signals. That said, you're right that it "doesn't occur", even if for a different reason: it can't.

Again - the number 1 point of debate going on here is still nothing to do with debayering or oversampling or having RGB data or anything like that - it is the fact that people keep describing a bayer pattern sensor in incorrect terms.

Isn't the debate about whether BMCC raw images contain "full 12-bit RGB values" for each pixel?

RGB is not the ultimate model of color. Even CieLAB represents the full color spectrum as seen by "the average human". How about tetrachromats? (they need four primaries).
Panavision Genesis is (was?) a camera to be the ultimate RGB color machine. Using a 12Mpixel non-bayer full RGB sensor it was to rule all big Hollywood productions. Where is i today? Why bayer filter array based cameras won? Genesis had its own problems (also with color) but mostly the "good enough" principle has been at work. Interpolating information is often "good enough" . Some languages lack vowels in writing. Does it mean that Hebrew cannot be read reliably? Readers simply "guess" the missing sounds out of context--immediate or more distant*. De-mosaicing algorithms are getting closer and closer to very high reliability. At some point only a purpose built test chart will be able to break them down. By then the real alternative will be a CieLAB+ color space also serving the tetrachromat minority...
*Of course it can lead to problems, e.g.. until today the name of God cannot be ascertained because of the Bible vowel stripped record: Yahweh or Jehovah ?

When the footage is debayered, each pixel contains full 12 bit RGB data. Which is therefore 4:4:4.

"Full" 12-bit RGB - that's 12-bit per each color component (36 bits total), or 12 bits for the whole thing?

If for the whole thing (according to the spec, that seems to be the case), then it's either a 4-bit "full" RGB, or it's not RGB, i.e. each pixel represents one of the colors.

Tom seems to think that debayering can do magic and create data out of thin air. Yet there isn't a single Bayer pattern cmos single sensor camera that produces 4:4:4 at the native sensor resolution.

Sony F65 has a RGBG sensor (Bayer pattern) and via massive oversampling delivers what some people here understand as 444 signal in 2k. That means every color channel is fed by dedicated color filtered pixels. The sony sensor is tilted 45 degrees to provide "diamond" pattern, but in spite of what their marketing says it is still the Bayer pattern-- RGBG. It is very unfortunate and confusing that many manufacturers still hold to the old analogue world definitions like 444 or 422. It was always a shorthand for sampling scheme but in the digital world it causes more misunderstandings than expediency.

Isn't the debate about whether BMCC raw images contain "full 12-bit RGB values" for each pixel?

Whether it was or not - the fact is, the BMCC does deliver full 12 bit RGB values for each pixel.

In the encoded signal, "chroma subsampling" can only apply to signals with separate luma and chroma components. I.e. it's meaningless with respect to RGB signals.

Exactly - and a 4:4:4 video file contains no chroma subsampling - 4:4:4 is effectively same thing as RGB - and what is produced after debayering the BMCC Raw data is RGB Data - and so 4:4:4.

Yet again,
Just because I have a signal that is called 4:4:4 it is not a valid signal.
Yes, each pixel of debayered image might have a a full RGB value, but it is not a real data RGB value, it is a mathematical cheat.
The only valid full resolution data that can be derived from a Bayer pattern, single sensor at a native resolution, is a luminance data, as we are aware of what is the relation between red and luminance, green and luminance, and blue and luminance.
Oversampling is the only way of getting somewhat close to a real full data per pixel of the final image in this situation.

To illustrate point further: I can take a 192x108 picture inside of photoshop, and blow it up x10. Oh look, now I have 1920x1080 with each pixel having a full RGB data. Yay me! But is it a real data? No. I is not.
Debayering of the 1920x1080 sensor image to an rgb file is essentially doing that. You take 960x540 for green and 480x540 for red and blue images and then enlarge and scale them all to 1920x1080 using whatever the flavor of the kernel math you like. Also, is is almost better to debayered to YCbCr first, because at least you can get the almost close to some real luminance data for each of the pixels of the sensor.

Yet again,
Just because I have a signal that is called 4:4:4 it is not a valid signal.
Yes, each pixel of debayered image might have a a full RGB value, but it is not a real data RGB value, it is a mathematical cheat.
The only valid full resolution data that can be derived from a Bayer pattern, single sensor at a native resolution, is a luminance data, as we are aware of what is the relation between red and luminance, green and luminance, and blue and luminance.
Oversampling is the only way of getting somewhat close to a real full data per pixel of the final image in this situation.

To illustrate point further: I can take a 192x108 picture inside of photoshop, and blow it up x10. Oh look, now I have 1920x1080 with each pixel having a full RGB data. Yay me! But is it a real data? No. I is not.
Debayering of the 1920x1080 sensor image to an rgb file is essentially doing that. You take 960x540 for green and 480x540 for red and blue images and then enlarge and scale them all to 1920x1080 using whatever the flavor of the kernel math you like. Also, is is almost better to debayered to YCbCr first, because at least you can get the almost close to some real luminance data for each of the pixels of the sensor.

Then what you want cannot physically exist. A bayer cmos is a bayer cmos - any other design would not be a bayer cmos.

Furthermore, I do not dispute the fact that debayering produces mathematically interpolated values - what I disputed was you referring to this as not RGB or not 4:4:4 - which regardless of whether you class the data as valid or not or real data - it is still data. What you meant to keep saying was that you wanted an oversampled image so that each final pixel contains enough colour sub-pixels so that no values are interpolated.

However.....Even if such an image sensor DID exists - I would like to point out that the very nature of sampling an analogue signal in itself is already a deviation from "true" or "real" colour values. And even then, the accuracy or purity of any kind of colour filter array would also create a deviation from "true" or "real" colour values. In fact - it is completely fair to say that there is no such thing as "true" or "real colour values. Even film, with its analogue colour and unquantifiable infinite hues is not ever "true" or "real" colour values. The reason bayer pattern sensors and debayering interpolation as a image acquisition process has been so successful and popular is because the accuracy and fidelity of image reproduction is still very high - high enough that outside of the kind of tolerances needed for a scientific experiment - I would wager that no one, based on colour alone - would ever be able to determine that image A uses interpolated debayered values, and image B did not.

The points you raise in your most recent post are not even points I initially contested. We have now moved on to a different discussion altogether - thankfully you have now conceded that the signal is infact 4:4:4 RGB values (after debayering). The fact that part of the signal is interpolated (or "a mathematical cheat" as you prefer to put it) - is by the by and not something I have ever disputed.