Dirac

Hi,

>18 bits are only used for temporary values in the up- or down-conversion,
>so there's no need to store video on RAM at 18 bits, I wouldn't think. Eg,
>for you calculate things like
>
>(coeff1*sample1 + coeff2*sample2 + ..) >>8
>
>where the coefficient is an 8-bit number and the samples are 10-bit video,
>so the result is a 10-bit value again, and it's only the output that needs
>to go in RAM storage. Isn't it?

Well, not exactly. It depends on the number of terms in the sum, or more precisely, of the sum of the coefficients. If you
have two terms: ((2^8-1)(2^10-1)+(2^8-1)(2^10-1))>>8 = 2038 > 2^10.

However with the downsampling filter, where the coefficients are
86,46,4,-8,-4,4, since the original data is on 8 bits and the shift is >>8,
the precision needed is the precision necessary to represent
86+46+4+4=140. It is still on 8 bits. (this is for the first downsampling,
but it is still true with the upsampling). My mistake here, for some
(probably stupid) reason, I thought the value would be on 12 bits, then on
16 and finally on 18 bits.

Since this is plain wrong, I don't have a problem, after all.


Afterwards, the biggest possible value is 140*140>>8 = 76. And for the 1:8
scale, one has 140*76>>8 = 41.


>I'd be ok with using 8-bit video throughout, which would have only a small
>impact on compression performance. In that case the output of the up- and
>down-conversion filtering process would still be 8 bits. But replacing the
>formula above with, say,
>
>(coeff1*sample1)>>8 + (coeff2*sample2)>>8 + ...
>
>could have quite a large impact on compression performance, especially if
>the video samples were just 8 bit. Was this what you had in mind?

No. This would indeed be a bad idea.


>BTW, even if the video is 8 bits you still need 9 bits for
>motion-compensated difference frames as these will be the difference
>between sets of 8 bit numbers.

Yes. But atm I only care about the motion vector. Once it is known, computing
the motion-compensated difference is trivial, and relatively fast, even in
software.



I believe the documentation for the implementation of the Motion Estimator
will be ready in one or two weeks. The code will not be in VHDL, but
written in a language adapted to the platform I'm working on. It's called PamDC. Hopefully, translating it to VHDL will not be too difficult, since
PamDC is lower-level than VHDL. I don't know if I will have the time to do
that myself. However, the documentation and the code in PamDC will make
that an easy task.

Cheers,

/.er