[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mental challenge: the rainbow
Vladimir Ivanov wrote:
On Fri, 10 Feb 2012, Marc S. Ressl wrote:
On 10 feb, 19:55, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote:
On Fri, 10 Feb 2012, Marc S. Ressl wrote:
But the choice of color or monochrome is based upon sampling
thecolor> carrierat the beginning of the frame. Do you consider that
appropriate?
Yes, you still check for burst on each line.
Little note here - I meant that appropriate is sampling the burst
presence on each line, not on each frame.
Which you filter, and the filtered result is what actually drives the
render. Try with Michael's suggested time constant of few frames.
Thanks a lot for the comments. Would somebody be so nice as to refer
me to Michael's post on color carrier detection? I can't seem to find
it :-(.
Me neither. Google is not about searching anymore?
pd: did real monitors detect and enable color carrier recovery only at
the beginning of a frame, or is there a chance the detector toggles in
the middle of a scan line?
The monitors we're talking about, being simple analog devices, most
likely switch whenever the color burst detector filter commands - so,
yes, anywhere, including in the middle of a scan line. And because then
the color PLL is not locked you will get off colors for few lines until
it locks.
What I suggested to you is:
1) sample each line's color burst presence
2) filter it via simple filter, time constant few frames
3) render each line monochrome or color depending on filter output
Don't waste too much time over this, Marc. :-)
I agree--this is probably not too important, for the simple reason
that color killer switching time (filtering) was never standardized,
but was an engineering choice usually made for pragmatic reasons,
like acceptable performance and low cost.
In the early years of color TV in the US, color programming was
mostly limited to network shows, with most local programming and
commercials remaining in black and white. As a result, the color
killer was exercised often, with 30-second local B&W spots inserted
into network shows during commercial breaks.
With frequent switches, it was desirable to make the transition as
quickly and glitch-free as possible without incurring false triggering
due to short signal dropouts. The lower limit on switching delay
was set by the time that the color reference PLL took to lock to
the color burst stream, usually a good fraction of a frame time.
In the interest of keeping costs low, very simple low-pass filtering
was used on the instantaneous "burst detected" pulses to create the
"enable color" signal. Typically it was simply an RC filter with a
time constant on the order of a frame or two (1/30-1/15 second).
The long-standing "tradition" of going to black for several frames
between signal source switches served to mask any spurious color
or monochrome intervals, as well as masking any sync disruptions
when switching local-to-network or network-to-local.
This RC (1-pole) filter can be easily implemented as an exponential
average of the line-by-line "burst detected" signal to create the
"enable color" signal, which is then thresholded to do the mode
switch. For example, during each line processing:
enable_color = (1-1/color_time_constant)*enable_color
+(1/color_time_constant)*burst_detected;
color_mode = enable_color > .5;
Where burst_detected is either 0 or 1 and color_time_constant
is the approximate switching time constant in line times--for
example, 500.
In principle, once the color reference PLL has synchronized, it
would be possible to switch off the burst for short periods
without losing lock, and, if this were promptly detected, individual
lines could be rendered in monochrome. However, frequent resumptions
of the burst signal would always be required to maintain color lock.
-michael
NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."