>> (Not to say that your code doesn't have bugs, but this isn't one of them. ;^)
>What do you mean, or which places in the code ?
I think you swapped "inarea.hoffset" and "inarea.voffset" at the beginning
of set_inactive() --- I'll take another look at the code.
(Oh, and "pixels" and "chroma" are consistently misspelled. :)
>> to think that it is 'defined' by the four original surrounding chroma
>> samples. This is only true when a (spectrally-poor) box filter is used,
>> which downsamples by simply averaging the four closest pixels. Better
>> filters will use more pixels, weighted appropriately, for both downsampling
>> and upsampling.
>OK. But if I only want to set a area to a certain color, that should not
>matter ?
Correct.
>Or would it be wise to make "soft border" by filtering the pixles on the
>border ?
Nope --- since you are synthesizing 4:2:0 chroma-subsampled data, in some
sense the borders are _already_ soft, because the chroma data is at half
the resolution of the luma data.
The only problem was the expectation that the borders will look perfectly
sharp when upsampled to individual 4:4:4 pixels.
-matt m.
(ps: In case you were curious, the word 'pixel' was created as a contraction
of 'picture' and 'element'. The compression literature uses the word
'pel' a lot, which also seems to be the contraction of 'picture' and
'element'.
If anyone knows any difference between 'pel' and 'pixel', I'd love to
know what it is.)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
