Capture Question

[Jay Kelley]

I am getting teased from the "professionals" in my area since I am getting a NEW digital camera (The panansonic AJ-SDX900). Their complaint is that toaster is only capturing 8-bit uncompressed instead of 10-bit and that makes a difference in the color areas.

Is this true? If I capture in SDI am I only capturing in 8-bit vs. 10-bit?

Let me know

Jay

[Paul Lara]

There's a reason VT captures in 8-bit. Because YUV is 8-bit and everything coming in, processed, and outbound in Toaster is handled in native YUV colorspace (which is, again, 8-bit).

Many systems have to capture in 10-bit because they are actually captuing in RGB colorspace, not video's YUV-native.

[Jay Kelley]

Do I understand you correctly that what you are saying is that NTSC video is YUV native and that is an 8bit type of signal?

So this means that even if you capture in 10bit you are going to end up in 8bit YUV should you ever want to show your work in Television..

However.....

I can see a purpose for this in terms of getting the most bang for the buck in color correction and so on..

Since you are using an SDI card and Toaster is mostly software driven... If I were able to find a codec that captures in 10bit, and is a windows CODEC, would I be able to use it? Or is everything in toaster based on this 8 bit situation?

Perhaps this does not really matter, but I am just exploring the possibilities and trying to learn. I make movies so image quality is very important to me.

Jay

[tmon]

I know that YUV is important to the elegant, efficient RTV format, and to the true real-time efficiency of VT[x], but it is irritating when these other jealous NLE people try to use their tired RGB (i.e., multiple conversion) arguments to try and dismiss VT[X]. I would prefer that the troops be armed with data to counter them.

Canopus did one, but I bet NewTek could do better, particularly since we're dealing in D1 uncompressed, not just DV:

http://www.canopus-aust.com/US/pdf/Storm_comparison.pdf

[Paul Lara]

Originally posted by Jay Kelley
Do I understand you correctly that what you are saying is that NTSC video is YUV native and that is an 8bit type of signal?


Correct.

Some competitors who claim 10-bit capture speak half-truths, since the software used to process the captured signals work in 8-bit.

If you're concerned with quality, then uncompressed D1 component is your best bet, which is exactly what Video Toaster gives you. ;)

[bbeanan]

The comparison PDF that was refered to was very informative, and I too would love such "ammo" to combat the VT3 questions of quality, and if it is a professional system...

A great item would be one of those standard comparison charts which lists all of the features down the side and all of the NLE systems across the top and a dot next to the features that the system has... I would bet that the VT3 would have the most dots. Granted it would be best to get a Magazine to verify the info and publish it (Hey there Alien PR guys!!!).

[Paul Lara]

Originally posted by bbeanan
The comparison PDF that was refered to was very informative, and I too would love such "ammo" to combat the VT3 questions of quality, and if it is a professional system...

A great item would be one of those standard comparison charts which lists all of the features down the side and all of the NLE systems across the top and a dot next to the features that the system has... I would bet that the VT3 would have the most dots.

::sigh::
Of course, such a matrix would be purely subjective, because I'd begin by listing ONLY the things VT does well, and omitting the others. While that works great in an Ad, it's not at all objective. I'm more interested in resellers and customers knowing the truth, instead of falsely hyping Toaster.

Granted it would be best to get a Magazine to verify the info and publish it (Hey there Alien PR guys!!!).

Yeah, that'll happen.
If you're not keen on the realities of trade magazines, Read Dilbert's take on the issue (http://www.dilbert.com/comics/dilbert/archive/dilbert-20030528.html)

[bbeanan]

Yea during my dot bomb (opps dot com) days when I had a normal 9-5 job as the Director of Marketing, I would drop an average of $100k per month on Ad space and you should have read the rave reviews our site and service got... I could pretty much write up anything submit it and one of the staff writters would reword it a bit (sometimes not at all) and publish the artical under their name... and just like that we got our next round of funding.

[Jay Kelley]

Thanks for the response Paul.. I forwarded it to another board (A forum on the New Panasonic camera) where we are discussing the highest quality way to capture the SDI footage from the camera. I sent him a post of yours about the issue from a toaster forum. Here is his reply. I would be interested you in your response.

Reply:

Clearly, the sdx900 is an outstanding camera that can go head to head with any sd camera on technical merits alone, without any special arguments or sales-pitching tossed into the mix. So let me respond to Lara's comments to you.
1st, he's right about keeping video in native YUV space. If all you're ever going to do is bring video in and then send it back out, you can't go wrong with staying in YUV.
However, unless you're running a Quantel system, where all graphics are maintained in YUV space, the moment you start introducing anything that's computer-generated, you've just broken into RGB space, and that's where problems begin. If you do some searches on the web you can find some heavy-duty explanations on why 10-bit support is needed to get better conversion from RGB to YUV space. One place to check out is
http://www.poynton.com/papers/Discreet_Logic/index.html

Another note of interest is Charles Poynton's comment, "Upon conversion from 8-bit R'G'B' to 8-bit Y'CBCR, three-quarters of the available colors are lost." Why sales brochures and reps pretend that video editing can all occur within YUV space alone, without need for titling, photography, gradients, color streaks, animation, and the like is a little beyond me. Unless, of course, all you do is fade up and down from black and then simply cut. . .
So the first big problem is getting simple 8-bit computer generated art to transfer to video space accurately. As a test, draw a blue gradient (with 10 or so points of difference between the two blue values) across a video-sized frame in Photoshop . Then import it into the toaster and display it. You'll see a series of blue bands with distinct edges on your monitor (clearest in component mode). Not exactly a gradient. This can't be fixed with blurring or dithering, as the problem is mathematical because you don't have enough integers in 8-bit systems to fix the rounding errors that you are viewing. In these cases, you're better off using a compressed editing system, believe it or not.
The next problem is that higher-end cameras, such as the SDX900 feed their YUV SDI signal out in 10-bit space. With an 8-bit system you're unnecessarily tossing out data before you even get to see it. Digital Voodoo (whose products I don't own), in explaining their reason for going with 10-bit capture add, "The extra two bits in 10-bit video works out as four times as many brightness levels than 8-bit video." (http://www.digitalvoodoo.net/products/10bit) 10-bit cards can be bought for under $2000.
3rd, many editing solutions are set up to let you decide how to interpret RGB values so they can support super black or super white, if you need it.
But I'm really lost here. I don't know how they can assert that there is a loss of image fidelity when converting to RGB. Not only can 8-bit RGB space hold more information than 8-bit YUV, but the YUV signal you're playing with has already trashed HALF of the color information it was capable of holding from the start! It's like saying you shouldn't bring DV footage into an uncompressed system, because an uncompressed system can't handle all the information of the trampled-on, squished-down, and zipped-up data of 3.7MB/sec DV! So I find it hard to believe. But even if it was true, to preserve 8-bit YUV "purity" for extremely apparent RGB to YUV conversion problems seems less than pragmatic.
Lara admits 10-bit is (only) needed for color conversion, but seems to imply it only occurs when RGB editors apply effects or something. He's apparently ignoring a whole lot of other issues, and potentially leading you down a frustrating road. I haven't seen their "complex dithering" work, nor does it explain the hypocrysy of fudging RGB data (dithering) while claiming that YUV purity is somehow the ultimate goal of video capture.
Perhaps Lara really believes that "Since these are never stored at higher than 8bit color precision there is no real benefit of having 10bit YUV output." But that doesn't explain why Newtek engineers do. And it doesn't explain what you're doing to those extra 2-bits of data that the SDX900 is throwing at you

Really not trying to stir things up, and taking a chance on the thought that you might be interested in a non-Newtekian opinion.
Happy story-telling,
Glen

[Jay Kelley]

Clearly each camp believes they are right on this issue. And I have respect for both sides.

A quick solution for me when faced with "one choice or the other" is to say BOTH!

So I ask this question again:

Since toaster can capture SDI and is software driven, is it possible to use a RGB 10bit codec on captureing.

I would not be interested in switching this. Just seeing the waveform and vectorscop and saving the video to the hard drive. I would be shooting a movie so I would be working one shot at a time.

That way I can see for myself and decide then.

Jay

[SBowie]

Since it was a) germane to this discussion, and b) was posted previously in a public forum, I'm going to take the liberty of copying here some comments made in January on the VTNT list at yahoogroups.com by the good Dr. Cross. He was remarking on image quality tests performed by a user:

(p.s. - the 'snip' is mine)

> I tried the same 10 generations of exporting that test image with VT2 from TEd and was pleased to see NO VISIBILE changes with the 720x486i from the initial render to the last.

Snip....

Thanks a lot for your comprehensive tests. To give a couple of details that might help here ...

When the Toaster does RGB to YUV (or vice versa) color conversion, internally it does all calculations in 16 bits per pixel. Rather then then rouding the the nearest 8 bit destination value it will choose a dithered 8 bit destination, giving it an effective color precision that exceeds 8 bits, and should never give any visible artifacts. There are two additional things to note here :

1) The Toaster is uncompressed, which allows us to perform some dithering tricks to acheive effective color precisions beyond 8 bits. If we where running through a DCT operation, pretty much everything would be truncated and result in bandind og a drop in chroma resolution.

2) We only ever actually convert color space when and if we actually need to. Within TEd it is only possible to perform a single RGB -> YUV color conversion process, and then it is never needed to convert back (even for DV file writing.)

... Indeed, if you where to import an RTV, then write it out at exactly the same length and resolution, you could compare the files byte-by-byte and they would be identical ...

[End Quote]

[SBowie]

p.s. - as suggested, I just created a fairly radical blue gradient in Aura, saved it as a 32bit PNG, and dropped it in a DDR for output.

There is certainly no visible banding on my NTSC monitor, nor anywhere in the interface.

[jcupp]

Originally posted by Jay Kelley

[Reply received from another forum] ...So the first big problem is getting simple 8-bit computer generated art to transfer to video space accurately. As a test, draw a blue gradient (with 10 or so points of difference between the two blue values) across a video-sized frame in Photoshop . Then import it into the toaster and display it. You'll see a series of blue bands with distinct edges on your monitor (clearest in component mode). Not exactly a gradient.

So what he is saying , if I understand correctly, is that one shouldn't create graphics (like a DVE for example) in RGB color space then convert them to YUV. DOH! Isn't this exactly what Paul said the Toaster doesn't do? I think the person quoted by Jay doesn't quite get that everything in the VT works in YUV colorspace so NO conversions to or from RGB ever need take place so 10 bit is un-necessary.

Digital Voodoo says "There have been a lot of arguments about which colorspace is the best to use, computer RGB or Y,Cr,CB We think that there is no argument, if you want to use computers to do post production work, you will always need to convert between the RGB and Y, Cr,CB"

But this is cearly not true. They should have said "... only if you want to use print applications, jury rigged for video, to do post production work, will you need to convert between RGB and Y, Cr, CB.

For final delivery on currently available video standards like NTSC or High Def:
Best - no color space conversion (VT)
Better - Higher prescision colorspace conversion (10 Bit)
Not good - low precision color space conversion (8 Bit)

[SBowie]

p.p.s - I suppose it's my own biases showing, but in assessing the worthiness of a source, I always deduct points when anyone consistently uses the last name only to refer to someone holding a different view.

Save when done accidentally or in a scholarly work, this is a none too subtle condescension, a component of a form of argumentation based on the 'tyranny of authority.' When used, it only reflects badly on the one doing so, implying as it does not merely disrespect, but that he or she is so certain of their facts that anyone offering a contrary view must surely be wrong. This latter mindset has not served science or humanity well, as history proves generously.

[Paul Lara]

Originally posted by Jay Kelley
Thanks for the response Paul.. I would be interested you in your response.


Forgive me Glen, but I really don't have time to engage in an online debate with some other group. :p

[ted]

Thanks Steve and Paul for helping to clear up some of this.

What it all comes down to is...every manufacturer will use techy jargin to justify their own method of making video.

So far I've not seen anything that VT does to mess up my video. And my clients would really bury me if they saw anything they didn't like.

[Rich Deustachio]

I think the quality of the VT2/3 speaks for itself. Forget all the numbers and hype, just look at the output.

[Jay Kelley]

Let's be careful here: Glen has done nothing but try to help me by offering his opinion and I am grateful to him for it. I would suggest we debate the SUBJECT and not the people. That way we can learn something.

Also don't blame Glen or knock him. This is all my doing, I have copied responses he made to me from another forum on this forum so that I could LEARN (The reason we are here, remember?) about this subject since it is hotly debated.

Now.. I will ask the same question I have asked 3 TIMES with no answer:

Since toaster can capture in SDI is it POSSIBLE to capture in 10-bit RGB if I can find a CODEC that will do so?

I am not asking if it is right.. I am asking if it is possible. That said would the waveform and vectorscope work?

I currently own the Toaster, SDI, SX-8, and have purchased a full version of Lightwave back in the 5.5 days so I feel comfortable when I say I am a loyal Newtek customer.

As a consumer I am confused by these issues surrounding RGB vs. YUV and I am grateful for EVERYONE'S opinion. From the discussions held here I am unable to draw any firm conclusions as yet, but I feel safe that BOTH formats deliver excellent quality and I will probably do well with either one of them. Since I have already dumped a buttload of money into Toaster, I guess you can figure what direction I am going in.

Jay

[SBowie]

Originally posted by Jay Kelley


1) Also don't blame Glen or knock him... snip.

2) Since toaster can capture in SDI is it POSSIBLE to capture in 10-bit RGB if I can find a CODEC that will do so?
1) I never quibble with someone's right to express an opinion (providing the opinion is not morally reprehensible, of course). Having never heard of or met Glen I have no reason to knock him. But I don't like it when comments are couched in language that is unnecessarily disrespectful, either, and am not stepping away from having pointed out an example of such. I have no idea who authored the remarks, nor does it matter.

2) I doubt it, but cannot answer authoritatively. I suspect more specific info (as to the SDI card and what it can or cannot do) will have to come from an engineering source.

I've offered the best information I have at hand on the way the Toaster handles these matters. I've also performed the gradient test as suggested with results that differ from what was indicated should result. That should provide some level of comfort that despite the complexity of the issues, if the proof of the pudding is in the eating, NewTek's point has been made.

[jcupp]

Originally posted by Jay Kelley
Since toaster can capture in SDI is it POSSIBLE to capture in 10-bit RGB if I can find a CODEC that will do so?


I'm going to go out on a limb here and say no. The SDI input on the VT is for standard 8 bit YUV serial digital, D1, compatible uncompressed video. That is what the VT uses internally. This is not to say that in the future it would not be possible for NewTek or someone else to use the SDI hardware for some other format data streams with the VT. As the software currently stands there are no options for "codecs" etc with the SDI.

But again there is no operational reason to import 10 bit RGB, no tape formats exist that store 10 bit RGB. Digibeta decks optionally support such SDI transfers but the information is stored on tape in a slightly compressed 8 bit YUV format and is transcoded to RGB for transfer. The reason they use 10 bit RGB is to reduce the degradation caused by the YUV to RGB conversion. D5 supports 10 bit YUV storage but costs more than a house.

[Quiet1onTheSet]

p.p.s - I suppose it's my own biases showing, but in assessing the worthiness of a source, I always deduct points when anyone consistently uses the last name only to refer to someone holding a different view.

Save when done accidentally or in a scholarly work, this is a none too subtle condescension, a component of a form of argumentation based on the 'tyranny of authority.' When used, it only reflects badly on the one doing so, implying as it does not merely disrespect, but that he or she is so certain of their facts that anyone offering a contrary view must surely be wrong. This latter mindset has not served science or humanity well, as history proves generously.

Wow, Stever. I was thinking along the very same lines, as I just a moment ago, finally got around to reading this thread, including that apparently condescending in that other forum.

[This writer's seeming condescension expressed by the phrase "in that other forum", is deliberate.] :hey:

Q1