Hi!
> From: [EMAIL PROTECTED]
> The effect was cool though - diagonal black lines across the screen.
>
> Actually, this was crippling: the first set of loops goto'd out when
> num_dark reaches pixel_thresh. So num_dark <= pixel_thresh always,...
>
> Also, as it stands it doesn't actually report the number of dark
> pixels; it reports num_dark from the first set of loops, which clips
> at pixel_thresh.
Turns out that y4mblackfix is a bit _too_ simple minded after all ;(
For the immediate goal of reducing the blotches on fades to/from
black it works great.
Unfortunately in scenes with black colors that are supposed to be
there the lack of color matching rears its head. Watching a DVD
I made tonight on a real TV set exposed the problem. A man's black
coat looked really awful with shimmering shades of grey/black (and what
appears to be a bit of a green color cast - but those could be from
the pixels that weren't replaced).
The replaced pixels are a different 'shade' than the ones that were
not changed. Thus all I've done is shift the problem from area
to another ;(
Search surrounding areas for 'black' and replace those too? Or perhaps
use the value of the surrounding pixels instead of the center point
values.
Not sure exactly sure what to do - sleep on it and think about it
I suppose.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
