Ron -- no worries, man -- forums are all about discussing ideas, trying things, breaking them, sharing them, and fixing them!
One request -- can we please stop using the word "claim"? I am offering my results and observations -- these are not "claims"... the data is there for *anyone* that chooses to take the time to look... I am hoping some of you are following along and actually looking at the data I'm taking the time to provide along with my observations... please, don't take my word for it, follow up with your own research; I'd be more than happy to look at other tests and data... Every time I see the word "claim" is says to me that this person isn't bothering to look at the data... so I then feel that the poster isn't really keeping up with the thread and commenting on things I've SHOWN already... if we are to have a productive and fruitful discussion let's take the time to examine the examples and go over what we see... "Claims" are sales tools... or a place you dig for gold... what I'm sharing is hard facts and observations... Don't think for a second that everyone at Sony, or Nikon, or "everyone else out there" understands colorspace... it is so simple in theory but so littered with sales talk and misinformation.
A couple things I should re-iterate:
1. I have said, and repeated, the video files are 8bit integer colorspace (0-255)
2. I specifically stated that they are NOT 10 bit color files -- (like a Cineon or DPX file) -- it is an 8bit 422 color model with 10bit subsampling packed into a 10bit quicktime container, not a 10bit color file.
3. The 10bit quicktime is to account for the 10bit subsampling -- this can not be put into an 8bit container. (Which is why many 422 streams are 10bit... check your favorite ProRes.. tell me what you see...)
4. The stream that comes out of the camera carries 10bits. Please just do a quick "get info" (command+i in QT7) on the quicktime it outputs... you'll see 10bit. Again, I can't speak as to what Nikon is doing with the data -- how they are packing in audio -- but the uncompressed (still feels strange to call it that) HDMI stream coming out of the D800(E) is a 422 stream with 10bit subsampling packed into a 10bit container... in fact, both the "uncompressed" stream as well as a ProRes Ninja capture are written to a 10bit Quicktime container. I've given multiple examples of how to see this for yourself -- please, try this and see for yourself. You've asked for hard proof -- I'm giving you the pudding... it's up to you to taste it. ;) And please SHARE an example if you can produce otherwise. I have provided my proof -- if you'd like to contravert my findings please provide the files to back up your point.
5. Personally, I think 422 is a deprecated technology that was developed to successfully compress and broadcast an SD signal; it's lackluster and riddled with color noise, contamination, and anomalies that compromise the quality -- I would never try to convince anyone otherwise. That said, to your point, we are all about making the most of what the camera gives us... again, a 4:2:2 10BIT quicktime is superior to a 4:2:2 8bit quicktime due to the SUBSAMPLING. To the orignal point of this thread (man, it seems so long ago!) I prefer the data as untouched as I can get it -- I will take the uncompressed quicktime any day of the week over ProRes... To Ron's point, I can always pair out the extra data but once it's gone, I can't promote empty data to replace it.
6. With regard to promoting empty bits (writing 8 bit integer color data to a larger file like 16bit integer, or 32 bit float) I get your point -- I spoke to it the first time you presented it. Some systems can't produce specific data models... so, for example, some systems can't produce a proper 10 bit data model so they will pack 10bit information into a 12bit or 16 bit stream. An example of this in the post world is when a 10bit DPX file comes in and the client wants to process it in a "Flame Suite", the flame doesn't have a 10bit color model build it so it promotes the 10bit files to 12bit -- is it the best answer? NO -- is it more common than not? YES... Same thing is happening with the Canon 5D h264's... I'm not sure this is the case with all 5D h264's (quality setting?) but for the project I'm thinking of all the 5D h264s were 16bit right from the camera. Is this 16bit color? No It's 8 bit color... I have NO clue why they are going to 16 bit... honestly, I stopped caring about Canon at h264 -- that's no way near high enough quality... which is precisely why I was interested in the "uncompressed" HDMI output.
So, if I may ask... what programs are you using to process and/or do color tweaks on your imagery?
What do you consider to be a true "10bit volume of data" encoded to a quicktime? As opposed to a ProRes that encodes an 8bit Tiff sequence as 422 with 10bit subsampling... that's by ProRes' spec (they tout it highly as a feature)... not sure you could even encode a ProRes 422 with 8bit subsampling... now if you'd like to get into it with Apple asking why they encode that way, more power to you... I have a few things to say to them as well about screwy color representation... there is truth to the saying that "friends don't let friends use quicktime in production" -- they do some VERY convoluted and lossy color transforms. ProRes is for editors and FCP... I think it's sad that people actually consider ProRes a valid "HD deliverable" because it's "up to spec" -- that doesn't mean its suitable to use for mastering and source... only for output of properly mastered footage... It completely falls apart when you see it next to a true 4:4:4 RGB source -- no question. The sad fact is that when one comes to really do understand colorspace,he/she is one of a very few... instead of using your knowledge to do everything correctly, you'll more often find yourself having to use that knowledge to undo what 9/10 of people do to the footage before you get it.
I totally appreciate that you want to know exactly what is going on with your data -- we're 2 peas in a pod there! I'm sure we can get down to the bottom of what's REALLY going on here ;)
Looking forward to hearing what you find...