🚀 go-pugleaf

In article <1992Aug14.121823.27891@bcrka451.bnr.ca> sandness@bnr.ca (Glen Sandness) writes:
>
>Several CCD image sensors I have read about generate the interleaved
>NTSC signal by simply dumping the same 200+ scan lines for each field
>of a complete frame.  This means that the second field of the frame
>is actually offset in time from the first field.  Is this how all
>video cameras operate?

Most pro video I've seen seems to shoot 60 distinct fields per second,
where if you do a frame still you may get motion artifacts due to the
fields being taken from different points in time.

I don't know about consumer cameras.

>I know that motion picture film is converted to video by periodically
>re-using frames to reconcile the 24-frame/sec motion picture rate with
>the 30-frame/sec video rate.  Does that mean that in this case the
>second field of the frame is NOT offset in time from the first field
>(i.e. both fields have been recorded from the same static movie frame)?

The method normally used is "3-2 pulldown" in which half of the film
frames use 2 fields and the other half use 3 fields, in an alternating
fashion:

video frame  |1    |2    |3    |4    |5    |
video fields |  :  |  :  |  :  |  :  |  :  |
film frame   |1 :1 |1 :2 |2 :3 |3 :3 |4 :4 |

So 2 out of 5 video frames have fields taken from different film
frames.

                                              -Dave Dodge/dododge@wam.umd.edu

sandness@bnr.ca (Glen Sandness) writes:
>I'm doing a little research as to what it would take to design a
>scan-doubler/enhancer.

 [ ... ]

>The tasks involved would be:
>
>    * translate the line level video or s-video to RGB
>
>    * digitize the RGB signal for storage (off-the-shelf chip from
>                                                       Brooktree)

Philips has a chipset that will do this in the digital domain, I believe.
(I.e. it digitizes the composite signal using (or 2 for S-video) ADCs,
then does the decoding to RGB wholly digitally

>Now, the only way I can design interpolation circuitry is to correctly
>model the sampling operation which produced the original video signal.
>
>Several CCD image sensors I have read about generate the interleaved
>NTSC signal by simply dumping the same 200+ scan lines for each field
>of a complete frame.  This means that the second field of the frame
>is actually offset in time from the first field.  Is this how all
>video cameras operate?

Well, a CCD sensor that *properly* mimiced the way a tube camera is
*supposed* to operate would have 484 scan lines of photosensors.
The even lines would be read out for one field, and the odd lines for
the other field.  So the even and odd fields are offset in position,
and each field represents an "exposure time" of 1/30 second, offset
1/60 second in time from the previous and following fields.  I believe
that at least some CCD's operate this way.

Then there are CCD's that have only 240 lines of pixels or so, but which
can *electrically* move the light-sensitive portion of the chip up or down.
The odd fields are generated with light falling on an area of the chip
that is one half pixel-row offset in position from the area used for the
even fields.  Because of this electrical offset, the even and odd fields
contain different information, and the vertical resolution is at least
potentially the same as a 480-line chip.  But each field is the result of
an exposure of only 1/60 second instead of 1/30, so motion blur is reduced
and strobing artifacts increased.

Then there are the type Glen mentions above - 200 rows of pixels and no
offset.  Here, the even and odd fields are the same for a still image,
and vertical resolution is reduced to half.  Again, each field is a
1/60 second exposure.

For proper interlaced video, every field coming from the camera should be
offset in time from the one before it.  All the cameras above have this
property.  On the other hand, much computer graphics is calculated at
30 FPS, and the two fields that make up a frame are not offset in time
from each other.

>I know that motion picture film is converted to video by periodically
>re-using frames to reconcile the 24-frame/sec motion picture rate with
>the 30-frame/sec video rate.  Does that mean that in this case the
>second field of the frame is NOT offset in time from the first field
>(i.e. both fields have been recorded from the same static movie frame)?

The frame rate conversion is done by holding film frames for alternately
2 then 3 fields of video.  No film frame is reused for two whole video
frames.  The pattern looks like this:

	film frame	1 1 2 2 2 3 3 4 4 4 5 5 6 6 6 7 7 8 8  8
	video frame	1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10

Another thing to keep in mind: the sort of processing you want to do
depends on whether there is significant motion *in that area of the image*.
If nothing is moving, you want to show the 242 scanlines of the previous
field combined with the 242 scanlines of the current field as a single
output frame - this preserves the full vertical resolution while
eliminating flicker.  However, showing each field twice in this manner
produces a double image of high-contrast fast-moving edges.

For *moving* areas of the image, you want to show each input field just
once, synthesizing the missing scanlines by interpolation (or just
plain replication).  This avoids the motion artifacts, but at a cost
of halving the vertical resolution.  In addition, single-scanline-wide
horizontal lines will flicker just like they did in the original interlaced
video.

If you pick either of these strategies alone, there are conditions under
which the output picture will look *worse* than the input.  So you need
to be prepared to switch back and forth between the two methods based
on picture content - ideally on a block-by-block basis within the image,
or line-by-line or at least field-by-field.

If you want to be *really* ambitious, you could retain full vertical
resolution on moving objects without double images by analyzing the
two fields to determine how each area of the image is moving between
frames, and moving the pixels from the old field to match the new field.
This is not easy.

	Dave