>I've done a little test with yuvscaler and y4mscaler. The input is a
...
>It seems there is some bad effects with cubicCR, cubic, sinc4hann,
>sinc4lan and sinc8lan (look at scaler-vcd-2.png).
>
>Any additional comments ?
I found the problem, and it will be fixed in a new release in the next few
days --- out-of-range pixel values were not properly clipped. (This is
only a problem for the above mentioned scaling modes because they are the
ones with negative coefficients, leading to ringing, leading to out of
range over- and under-shoot on "noisy" input sources.)
Question for developers:
Does anyone have any suggestions on fast ways to:
a) Convert an int32_t to uint8_t, using clipping to [0,255] first?
b) Above, but clipping to an arbitrary [min, max] range?
c) Either of the above, but first arithmetic-right-shift the int32_t by
a number of bits?
I'm mostly interested in generic C/C++/g++ solutions, but any MMX/AltiVec
ideas are welcome for future reference.
Thanks,
-matt m.
ps: gcc-3.3 appears to have access to MMX/SSE/3DNOW/AltiVec routines
built-in now... perhaps the custom macros in the source tree can
be retired? (just letting people know; i've never used any of
that stuff myself.)
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
