Siggraph Present
O.K. Don, after digging through my manuals this is what I found, which outlines
what I've been telling you.
This is regarding the 8 bit portion of the CCIR 601 specification.
"The CCIR 601 Digital Standard specifies that 8 bits of information for
LUMINANCE and 8 bits for CHROMINANCE axes are samples and stored… 8 bits
allows a maximum 256 levels of information to be represented for each component
(reduced slightly in CCIR 601 to minimise clipping of noise and overshoots).
Approximately 16 million unique values can be represented in the CCIR 601
system.
A random change of one Least Significant Bit (LSB) in 8 bits represents a
SIGNAL to NOISE RATIO of approximately 54 db. This realistically exceeds the
noise performance of most analogue video sources, recording and transmission
systems. 8-bits was therefore chosen as a practical and commercially realistic
standard for the industry."
This is regarding the 10 bit portion of the CCIR 601 specification.
"The CCIR 601 digital component standard specifies 8 bits to define gain
RESOLUTION for LUMINANCE and CHROMINANCE signals and the D1 and D2 digital tape
formats specify 8 bits recorded on tape."
You'll also note that A65's A64/60's and some other's output 8 bits as well, so
its hardly a 10 bit world… but to continue…
"Two extra bits can be carried (if available) between equipment, via the 25 way
parallel or serial digital interconnections. The extra two bits offer some
improvement of images only when the source, recording means and replay systems
work to this precision. This is rarely the case. The number of bits on the
external connections should not be confused with the internal precision of a
system. When 10 bit sources are connected to eight bit destinations by simply
losing or truncating the last two bits the results are worse than an eight bit
source."
You'll note that in the PVR specs that they do not claim CCIR 601
specification. They claim a CCIR 601 resolution of 720 x 480. I suspect the
reason they don't claim to meet the CCIR 601 specification is because its all
processed in 10 bits. Where as the Ill Pro can claim CCIR 601 as it meets that
specification in the model with 720×486 rectangular pixels. Outputting in CCIR
601 is only as good as the material you're inputting, same with the PVR.
The truth is, although its of marginal relevance, <g> that while the PVR does
not meet CCIR 601 specifactions and cannot integrate into a digital environment
like say an Abekas Diskus which is also 10 bit but CCIR 601 compatible (as
outlined in previous citations), the output can be theoretically better than D1
as a result.
Theorectically is theorectically. There are alot of factors. Like in an Abekas
you have 1 bit per disk arrays, whereas no configuration of the PVR allows for
this kind of arrangement. So while it may be possible for frames from an
animation to have that level of performance, it is highly dubious whether
sampled live video will attain anywhere near that level, although I would
expect it to exceed that which is currently available on the PAR. Another
factor is how the 10 bits in encoded from RGB and what kind of rounding occurs
when converted from RGB to YUV. This can get real messy and cause banding and
contouring. This will be of more concern in the case of Non Linear editing and
multiple pass layering, than of concern to the animator who just wants to store
frames into it for real time playback. Something to check out though if you
also plan to use it that way.
For me its a cost effective solution, provided the output looks as good as I
believe it will, and I won't have to give up my nice Ill Pro Framebuffer in the
process as I would with the Max, so the two should wed well together. I can set
the Ill Pro to run at the same resolution as the PVR. The options being 720×486
and the later, 720×480 being the same as the PVR which should allow me to paint
box my life away. (well at least a portion of it, when I'm not animating. <g>)
John