where there’s smoke there’s forum fire
@jph Where/how can we verify the D800 hdmi out is 10-bit?
Has anyone using a D800 with an external recorder noticed increased moire when compard to the video recorded internally to cards? I haven't done any good testing, just seeing some god awful moire on my externally recorded video and wondering if Nikon has some processing along with it's compression while recording internally.
I was testing a d800 and found that when setting the output to 1080i the signal would come out with some form of interlacing when recording to uncompressed mov on the black magic shuttle. To fix this set the hdmi output to auto. This is not the case on the d4 for some reason. Files were fine when setting it to 1080i. The files came out as progressive on the other end.
I'm not sure about the 10bit but the uncompressed files coming out of the black magic shuttle are very nice. I will be trying to pull some keys off the footage in a few weeks. I'll post some results.
Rob
I also want to add that I opted for the black magic over the ninja because of uncompressed capture. We have gotten plates from the Alexa that use prores and avid DnxHD and found those plates to be practically impossible to key fine details. You can also start to see the compression blocks after heavy CC. I'm going to try with the uncompressed footage soon but I just need to find the time. Oh and those files are Huge!
Hey all -- so glad to see there is some activity over here!
Ok, with regard to the signal and "uncompressed HD output": The camera records in 4:2:2 YUV. By definition, this is a lossy *image* compression. Yes, it would be nice if Nikon had true 4:4:4 RGB capture with "burst capture" but it doesn't -- it's just not the way the sensor works...
OK -- now that we have the signal -- a sequence of 4:2:2 images... what to do...
1. Store to an onboard memory card -- the sequence of 4:2:2 images is then compressed additionally (according to a predefined size) to fit onto your CF/SD card...
2. Stream to Ninja -- the sequence of 4:2:2 images is then compressed additionally (compression according to Ninja settings -- uncompressed is NOT an option with the Ninja, last I checked) If Ninja added uncompressed as an option I think many would chose it. The fact that some argue against adding it puzzles me... honestly it won't make a difference to some
3. Stream to Black Magic Shuttle -- the sequence of 4:2:2 images is NOT compressed additionally -- you are getting whatever signal the Nikon is outputting un-fettered. Now, in theory, the HDMI will carry a 10-bit signal however, I'm honestly not sure how Nikon is using the bandwidth. This is the option for the "purest" data... YES, these files WILL BE HUGE. And, no, it won't eliminate the fact that you are recording to 4:2:2 -- you will have color and edge artifacts no matter what. Some software (such as Nuke) can account for Video and has processes to make it easier, but not fool proof; and the more color data you can provide, the better solution it will provide -- *this* is the reason I opt for "uncompressed" quicktime. (Remember, the quicktime isn't compressed, but the individual frames used to make up the sequence are recorded at 4:2:2 -- no way around that)
I'm hoping this helps clear up any confusion I may have caused... please keep the great discussion going!
422 is not really compression though..it's samples in YCbCr. So we are getting 4 samples in luminance, 2 samples in Chroma Red, and 2 in Chroma blue. Data is being thrown away and you are correct it makes keying a bit harder and usually more jagged. I'm trying to find out why this is not possible in the d4 or d800 as we can scream through 14bit raw 16mp files at 10-11fps. I'm thinking it's either heat which the red cam has a huge fan to help deal with this.. Or most likely something in writing that Sony isn't allowing Nikon or others do to their sensors or to Hirt their video biz. Anyone else notice that Sony cams have 60p at 1080p?
Make no mistrake -- 422 is EXACTLY what compression is. You are representing an RGB 444 image with a YUV/YCbCr 422 representation that then has to sampled and interpolated. In a 444 image the color value for each channel is defined -- not so for a 422 representation of the same image because they are made to "approximate" the 444 image... so not only is 422 a compression, it's a lossy one at that. On top of that, you also have to consider how you are debayering your image, that's right, yet one more process intervening and munging your data... One thing film cameras have over the DSLRs is they are full color burst capture... I'm quite curious to see who will be the first to offer a true RGB 444 back -- the image quality will be superior. You can throw more pixels at it all day but until you have true 444, your just adding to the pre-processing and color noise... case and point: The Red "4K" -- not 4K at all... The difference in image fidelity between a 444 RGB and a 422 YUV/YCbCr is remarkable...
Btw, since Nikon DSLR sensors use a bayer arrangement, it doesn't matter what resolution you use... it's still 422.
I don't think any of this provides further support for the 10-bit claim, does it?
Also, I'd love to get my hands on similar footage recorded in the three flavors discussed: Uncompressed, ProRes HQ and internal h.264
I'm pretty certain the 10bit issue boils down to this:
1. The camera has an HDMI port which by definition supports 10bit data
2. The D800(E) streams chroma subsampled 4:2:2 data... depending on the codec,or lack thereof, the 4:2:2 stream can be 8 or 10 bits. *For example ProRes 422 is "10 bit"
3. Based on the DPreview article I mentioned earlier about the d800(e) video ( http://www.dpreview.com/reviews/nikon-d800-d800e/30 ), this example "uncompressed" footage is 10bit 422
(WARNING -- ~2GB FILE -- DOWNLOAD AT YOUR OWN RISK) (http://s3.amazonaws.com/movies.dpreview.com/nikon_d800/uncompressed_d800e.MOV)
Is this what you mean by the "10-bit claim"?
That link above has some nice samples of different outputs of D800(e) footage.
Cheers...
I see.
Consider this: if I save a JPEG (8-bit) file as a 32-bit TIFF, it will indeed create a file that is 4x the size, despite the fact that the original JPEG and the TIFF will look identical.
I'm pretty sure the data coming through the HDMI port is 8-bit. Nikon says so. Sony says so. Everyone else says so. Unless there are clear tests that conclusively show the feed is coming off the line as 10-bit, we must assume the aforementioned are correctly stating the facts.
Let's not conflate signal fidelity with colorspace. It's a 10bit stream carrying 422 color information and possibly some audio. HDMI, by definition is a 10bit stream... so the spec for the HDMI port is 10bit... BUT that doesn't mean the data is 10bits... and it definitely doesn't mean it's 10bit color... so why this talk about 10bit quicktimes?
Regardless of an 8bit 4:2:2 stream (which are often actually 4:2:0) or a 10bit 4:2:2 stream it's all about chroma subsampling, and more specifically the precision of the subsampling used to reconstruct 3 channels of 8bit integer data... the more subsampling, the better the reconstruction. The 10 bit 4:2:2 signal often refers to 10bit subsampling as opposed to 8bit subsampling -- I understand what you mean about packing empty channels into a higher bit depth but unlike promoting 8 bit data to 32 bits, there is a difference between the 8bit and the 10bit subsampling.
You mention you're pretty sure the "data" is 8bit and doing tests. I offered real examples of tests you can do... even if you don't own the needed equipment to make all the flavors... If you decide to do the test yourself, you'll see that the "uncompressed" quicktime is indeed tagged as 10bit. You'll also find that the ProRes quicktime is 10bit -- that's all I was saying. If you go back to my original posting, my goal was to get the purest untouched data from the camera -- the fewer processes that touched the data, the better -- I don't believe I claimed it was the best 10bit signal possible, I just observed it was a 10bit stream, that is all.
So... my goal in posting to the forum is to discuss and share best ways to process the data on the camera -- I'm puzzled as to how you would approach processing any of this video differently were it deemed a true 10bit stream by you? You say every one else says this so it must be true... I hear what you are saying and I'm actually not disagreeing with any of it -- I'm merely attempting to show where the confusion comes in and how Nikon and Sony are right when they say they are 8bit... and yet how the stream can still be using a 10bit container. The H.264 streams that come off the 5D are 16bit streams so how does that make a difference in our world? It doesn't... it's all still carrying 8bit integer color information. It's just a matter of how it is represented...
The fact that I am laying this all out shouldn't change anything about the way you process your images, in fact it should help those that are interested in the color science behind it... nothing I'm saying goes against what Nikon, or Sony, or "Everyone else" says... does it?
I can't speak as to what Nikon is doing to the data before it sends it out from the camera... so if you're asking what bit depth the video is, the answer is 8bit integer (0-255). If you're asking about the HDMI stream, it's 10bit... and if you're asking my opinion, it's just 2 bit ;)
I am not trying to argue with you. I am seeking to precisely understand for everyone's benefit, but mostly my own. You claim the D800 outputs a 10-bit stream if left untouched. Are you sure this is what the D800 is OUTPUTTING, or is it rather what any given device is wrapping it in?
Can you elaborate on the "16-bit streams" coming off the 5D? H.264 only supports between 8-14 bits. Maybe I'm mistaken, but it seems like there's something amiss with what you're saying.
I might be lacking in understanding, but coming from the stills world I understand that a 10-bit image would contain not just marginally more information than an 8-bit image, but would contain four times as much information (1,024 vs 256). This affects sharpness, detail, color fidelity, tonal gradations...
At any rate, if (for example) I wrote a script that imported all of the images off my iPhone (8-bit JPEGs) and saved them as 16-bit TIFFs, in the process, then it would be one thing: a major waste of space. There is nothing to occupy those additional 8-bits of space, unless I decided to add something in post. Even if it is D800 that is outputting the 8-bit stream in a 10-bit wrapper that doesn't mean it's a 10-bit volume of data. I have various reasons for wanting to get to the bottom of this, but mostly I'm always anxious to get the most out of my equipment. That usually begins, I have found, in understanding it precisely, as I mentioned earlier.
Thanks for your patience this far, and please let me know if I am mistaken in my understanding/reasoning.
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...
Cheers.
http://iamron.com/downloads/dropbox/ninja-qt-ss.png
http://iamron.com/downloads/dropbox/nikon-qt-ss.png
I don't seem to be seeing what you're referring to. What am I missing?
Examples!!! Right on Ron!!! Now we can start getting down to the root of any confusion and, hopefully, everyone comes out the wiser!
So... what are we looking at here? Judging by the names:
1. looks like a Ninja ProRes capture (not sure what settings you are using) -- I don't have a ninja so I can't pretend to comment on each one of it's settings... only the sample footage have access to. We may be viewing the atoms (quicktime info) differently so the 10bit flag may not be showing up for everyone... more on that below...
2. Appears to be an h264 onboard capture -- yikes... what happened to my color? ok... nothing special to see here...
So the "16-bit integer" means both are 16bit, right? JUST KIDDING!!! Seriously, that is a joke... a bad one at that but, damn, it was getting too serious around here! Ron either just chuckled -or- threw his computer across the room... hopefully it was the former ;) I repeat, neither of Ron's examples shows a 16bit quicktime... please read on...
Like I said, depending on how we view the QuickTime atoms, more info is revealed... that's not a user issue (not your fault at all) -- I blame APPLE for that but rather than go into another long winded tangent, allow me to offer this:
1. Apple ProRes
"Apple ProRes 422: A medium-bandwidth, high-quality compressed codec, suitable for mastering standard-definition video. Encodes video at 10 bits per channel with 4:2:2 chroma subsampling. Supports a variable bit rate (VBR) of 35 to 50 mbps. Supports any frame size."
2. "Uncompressed 8-Bit and 10-Bit 4:2:2 Video
These resolution-independent codecs are appropriate for all standard- and high-definition Y′CBCR video formats. Video stored using these codecs undergoes no data compression, but some color resampling may occur depending on the source video format. Because compression usually results in video artifacts, using no compression guarantees the highest level of quality, so this codec is often used for video mastering when the absolute highest quality is required. This also results in large file sizes."
*both excerpts directly from Apple: http://help.apple.com/motion/mac/5.0/en/motion/usermanual/index.html#chapter=B%26section=2%26tasks=true
3. https://dl.dropbox.com/u/29196641/d800e_HDMI_uncompressed.jpg
So, to break it down for the TL;DR crowd:
1. Apple ProRes 4:2:2 spec says it is a 10bit 4:2:2 file
2. Uncompressed 4:2:2 10-bit is superior in quality to any 4:2:2 ProRes codec
3. The D800(e) is outputting "Uncompressed 10bit 4:2:2" video via HDMI to the Blackmagic Shuttle2
To come full circle back to my original post, to take full advantage of the D800(e)'s uncompressed HD video feature (Uncompressed 10bit 4:2:2) , you need to output via HDMI to a Blackmagic Shuttle 2.
I really hope the Ninja considers adding an option for uncompressed HD -- I'd love to add one into my workflow.
If anyone is interested in reading more about the various digital recording options in genera;, here is B&H's take on the subject -- there is plenty more info here:
I hope you all find this info helpful.
Cheers...
I know this is probably going to come across as rude, and it may well be, but I don't feel like I have gotten any further answers to my questions, nor additional verification to your statements than I had two months (and a fair amount of condescension) ago. Lots of skirting, but no resolving. Just my 2¢.
Not at all Ron... honestly, even if you'd tried to be rude, it wouldn't bother me -- this stuff takes some people a long time to grasp and I am happy to help answer questions and find answers for those that really do want to make better sense of it all and take advantage of that info in their workflow.
First, if you'll remember my original inquiry was how to get the best possible quality HD video out of the D800(e) and what the exact specs of that video output are.
It pretty much boiled down to 2 options for capturing the HDMI output:
1. The Ninja which offers Quicktime ProRes 422 as it's highest quality option.
2. Blackmagic Shuttle 2 which offers Quicktime Uncompressed 10 bit 422 as it's highest quality option.
I provided documented proof from Apple, stating:
a) Your ProRes 422 captured on a Ninja are 10bit -- 8 bit integer color with 10bit subsampling; and they are lossy.
b) The uncompressed 10bit 4:2:2 captured by the Blackmagic Shuttle 2 are, again, as documented by Apple are superior in quality at the cost of file size.
c) I have offered links and visual confirmation that they are 10bit quicktimes... again -- this is due to the 10bit subsampling in BOTH -- not 10bit color.
Which of the above statements do you refute or feel are unproven or undocumented in any way?
Moving on...
I you choose to ignore Apple's own documentation regarding ProRes 422 and Uncompressed 10bit 4:2:2, that is up to you however, doing so would mean you can't give any credence to any documentation or opinion. Furthermore it means that you weren't acaully genuine in your efforts in simply finding the best output -- no big deal, just be honest. What is your goal here? What is it that you feel I'm not answering? These forums are actually about sharing ideas and trying to learn -- if you are not participating in that vein, please don't take away from what could be beneficial to others in this forum. II you look at the posts, I've made every effort to answer you in detail and provide documentation.
If you would like to state that the Ninja capture is at all, in any way superior to the Blackmagic Shuttle 2's capture -- you are patently incorrect, furthermore, with regard to skirting questions, I ask again, what software do you use to dial in/ tweak/ adjust your images/video? How is it that finding out the exact purity of the 10bit stream (knowing it's 8 bit integer color will change your process? Please do elaborate -- I'll know if you're serious about color and I'm sure the others will benefit from the discussion.
If anyone has any suggestions how I might be better able to convey the documented information, as well as any questions I might offer more information about I'd be happy to.
Looking forward to your reply.
jph, you clearly claim multiple times that the output from the D800 is 10-bit. I have, a number of times, challenged that. You have asserted in multiple ways that I have not done the homework to 'know for myself'. You offer as proof of your findings the info screen in Quicktime, which is apparently enough "proof" to back up your point. I have offered reasonable explanations as to why this may be, and may be insignificant. But when I show you my info screen that says something which again challenges your point, you "blame APPLE for" being not in agreement with your statements.
You then subtly attack my intent in being here on this forum. Let me state again, as I did in my follow-up reply to you: can you show any differences that back up your claim of superior image quality? See, despite what you think, I'm not interested in engaging you in intellectual discussions that have no real-world application for me, personally. Your assertions are still just that, and some of them seem quite mistaken given your response when they're challenged.
The bottom line is this: is uncompressed (non-ProRes) footage noticeably better than that which is contained in the more practical ProRes stream, or is it simply more expensive? I am keen to see actual quantitative results so I can determine whether or not I would personally benefit from a 10x workflow and expense bump. Rather than speculate and confabulate, I would prefer to SEE the difference — ideally by you showing it in any way you must to prove there IS a difference. Otherwise, it's all conjecture, or more simply put: a waste of time.
Ron,
You seem very frustrated -- I really am trying to help sort this out with you.
Technical pursuits such as these will require some intellectual discussion, *especially* if you want it to have real-world application in your workflow -- that's the whole reason there are forums such as these.
I stand by my original observation that 8bit colorspace and 10bit data streams seem to be getting confused for one another and incorrectly interchanged -- this is common. Hence why I want to clear it up for those interested in getting it once and for all.
As I mentioned a couple times -- A 10bit data stream DOES NOT EQUAL 10bit colorspace.
Per Apple's spec, a 10BIT container is necessary for a ProRes MOV as well as Uncompressed 422 10bit MOV. A 10bit container (due to the 10bit subsampling) will offer better RGB color reproduction than the same MOV with 422 8bit subsampling. -- this shows us that the extra 2 bits aren't merely empty and wasted.
This being the case, I'm willing to bet that anyone claiming that the D800(e) video output is "capped" at 8bit is referring to the fidelity of the 8bit colorspace, NOT the data stream -- any links you can share that discuss this "capped" at 8bit claim would be very helpful.
So, If someone says the D800(e) is capped at 8bit integer color output, that is correct -- if someone says that the HDMI data output on the D800(e) is "capped" at 8bit, that is false.
You and I both agree that, whether the stream is 10bit or not, the footage that results from it is ONLY ever 8bit integer color (0-255). Right? So, the fact that the stream is technically 10bit, is really irrelevant to those simply concerned with the proper COLORSPACE management. There is no need to even discuss 10bit COLOR from here on out.
The links to your screen shots were were accompanied by zero explanation -- just 2 images that showed some basic info (maybe that was your point). Crack open your Quicktime files and look at the atoms in Quicktime Dumpster -- I was attempting to explain why you weren't seeing the info you were looking for (i.e. 10bit container)
As I stated, it's not about what you might see with the naked eye -- those able to manipulate the footage with professional imaging software WILL notice the difference -- again, your naked eye may not see a difference but the SOFTWARE will; and this will result in higher quality output. This is why I asked several times what software you were using.... AfterEffects? Fusion? Nuke? Something else? I'm happy to offer you a test you could run on your own so you could check for yourself whether it made a difference in your workflow -- that's all man -- plain and simple, I was trying to help you see if it made a difference for your needs or not...
Short Answer:
Uncompressed quicktimes captured using Blackmagic Shuttle 2 are superior to the Ninja Pro-Res capture -- as stated by the links to Apple, DSLRReview, and B&H photo, to name a few.
ProRes 422 movs are 8bit RGB color represented by 422 10bit subsampled YCbCr DATA -- again as stated by Apple (the company that makes it).
The software you use, your process, and your end goals will ultimately determine what's best for your workflow. If using the best possible master footage is a concern, "Uncompressed 422 10bit" from the Blackmagic Shuttle 2 is the way to go.. until Ninja decides to do a firmware upgrade and offer uncompressed -- that would be AWESOME. I'd love to take advantage of all Ninja's features...
Again, if anyone is honestly interested in setting up tests that show the difference between quality and will allow you to make the best choice of quality based on workflow, I am more than happy to help.
I also am happy to answer any questions about color space, software, and methodologies -- if you think I can be more clear on something or possibly document something better, I am more than happy to follow your suggestions and answer any questions.
Ron I hope this helps -- if you choose to reply, please include the links that discuss the data cap. To someone that just joined this forum in hopes of learning and sharing (me), I find your tone and style to go directly against the goal of fostering an open and comfortable communication of information. I am trying to help you here, man -- cut me some slack... work with me... unless you're just trolling, in which case this board got WAY MORE INFORMATION about color,codecs, and containers than they ever wanted! ;)
I hope you guys realize that you might as well be speaking in a foreign language... this stuff is totally over my head. I need to go back to kindergarten on this.
The Ninja records a 10-bit 4:2:2 stream just like the blackmagic. That's not the differentiating factor here. It's really "uncompressed" vs. ProRes compressed. Am I mistaken?
Again, I'm not engaging in an intellectual debate for the mere fun of it. I added my input for the sole purpose of establishing:
A) that the Ninja was a pretty smoking deal compared with the other options in the market — one that would likely suit 99% of the readers on this forum, and
B) (assuming there are differences) that I am interested in seeing real-world examples of those differences, and how they might have an affect in real-world situations.
I may well be confusing colorspace and data streams. I don't fully understand those. But to be honest, I don't really care. I'm not saying I WON'T care, or SHOULDN'T care, just that I'm not sure why I would care until I can see a plain reason why it matters for ME, PERSONALLY (at which point I would ask whether it matters for others, and if so I would seek to pathetically communicate the reasons why they should be concerned with it as well).
I cannot recommend something I don't understand. I cannot understand something I don't care about. I will not care about something unless I sense a need which I might have in doing so.
In plain English, it is not data streams and colorspaces and lossy vs. lossless that I care about. I care about end-results. This is not to say I don't understand or won't learn about these things. I will work backwards through any and all other technical details necessary the moment I realize that they are affecting said end-results.
Do you have any end-results showing the differences between straight streams (as from the HDS; I hate calling them "uncompressed") and ProRes streams from something like the Ninja?
I have tried to resist the temptation to get involved in this discussion, but ProRes HQ is visually lossless compression with extra headroom as compared to regular ProRes and is 10 times the data rate of the internal card recording, which is not all that bad. I have a D4 with the Ninja 2 and in my experience the recording is fabulous, detailed and clean. Ultimately I usually have to output this as h.264 movie, which is still fantastic on my 27" computer. When uploaded to Vimeo or YouTube, it looks not so good. At the end of the day, visually lossless compression is all that you really need. For the same reason, I take RAW photos with the same D4 at lossless 12 bit compression. Sure, I could use 14 bit and no compression...but why?
By the way, I do believe that the HDMI output is 8 bit and wrapped in a 10 bit container by the Ninja, for whatever that is worth. Each frame of ProRes HQ is a very nice image. The files are already large in ProRes HQ, I would not want them any larger.
You must log in to post.
