drascic@ecf.UUCP (06/05/87)
I want to overlay the graphics output of a computer onto a video image of the real world, to implement a cursor. This means that I have to sync the camera to the computer's video, which is reasonably easy to do. But once I have the two signals, I have to combine. Someone suggested that "keying" was the route. This involves switching between the two signals, depending on the level of one of them. Unfortunately, this seems to be very expensive. Is it possible to simply add the two signals through appropriate resistors? Or are there chips available suitable for building a simple keyer? Any hints, suggestions, or suppliers would be much appreciated. David Drascic UUCP: drascic@ecf.toronto.edu OR drascic@utecfb
mwtilden@orchid.UUCP (06/06/87)
In article <173@mv06.ecf.toronto.edu> drascic@ecf.toronto.edu (David Drascic) writes: >Is it possible to simply add the two signals through appropriate >resistors? Or are there chips available suitable for building a >simple keyer? Any hints, suggestions, or suppliers would be much >appreciated. > When I did this a few months ago, I used a MC14052 analog mux/demux to select between the cursor-present signal and the normal video. A high grade amplifier has to re-boost the signal to 75 Ohm status but otherwise there is no distortion at all. These are all NTSC signals of course. The problem with mixing computer with video through resistors is computers generate single repeated sync signals of 262 scan lines (normally) and not the 262.5 demanded by NTSC standards. A bad jitter in your picture signal is the result along with partial to complete color loss. If you only have RGB coming out of your computer then I would recommend the MC1488 chip. Works fine with a minimum of components (the funny coils they insist you use can be easily faked with RC equivalents). I have still to get a reasonable circuit to color lock the video with this chip but I'm not worried, grey scale looks good for now. -- Mark Tilden: _-_-_-__--__--_ /(glitch!) M.F.C.F Hardware Design Lab. -_-___ | \ /\/ Un. of Waterloo. Canada, N2L-3G1 |__-_-_-| \/ work: (519)-885-1211 ext.2457, "MY OPINIONS, YOU HEAR!? MINE! MINE! MINE! MINE! MINE! AH HAHAHAHAHAHAHAHAHA!!"
asm@utcsri.UUCP (06/07/87)
In article <8037@orchid.UUCP> mwtilden@orchid.UUCP (M.W. Tilden, Hardware) writes: >[ some stuff deleted ] >If you only have RGB coming out of your computer then I would recommend the >MC1488 chip. Works fine with a minimum of components (the funny coils >^^^^^^ >they insist you use can be easily faked with RC equivalents). I have >still to get a reasonable circuit to color lock the video with this >chip but I'm not worried, grey scale looks good for now. > > >-- >Mark Tilden: _-_-_-__--__--_ /(glitch!) M.F.C.F Hardware Design Lab. >-_-___ | \ /\/ Un. of Waterloo. Canada, N2L-3G1 > |__-_-_-| \/ work: (519)-885-1211 ext.2457, >"MY OPINIONS, YOU HEAR!? MINE! MINE! MINE! MINE! MINE! AH HAHAHAHAHAHAHAHAHA!!" I think Mark means the MC1377. This is an RGB->composite video converter. -- Anees Munshi @ University of Toronto Engineering. ARPA asm%csri.toronto.edu@csnet-relay.arpa BitNet asm@utcsri.UTORONTO CSNet asm@csri.toronto.edu UUCP {allegra,ihnp4,decvax,pyramid}!utzoo!utcsri!asm Reality is so much better!
mwtilden@orchid.UUCP (06/09/87)
In article <4880@utcsri.UUCP> asm@utcsri.UUCP (Anees Munshi) writes: >In article <8037@orchid.UUCP> mwtilden@orchid.UUCP (M.W. Tilden, Hardware) writes: >>MC1488 chip. Works fine with a minimum of components (the funny coils > ^^^^ > > I think Mark means the MC1377. This is an RGB->composite video > converter. > Yes, indeed I did. Sorry about that. (What are they putting in the coffee around here?) By the way, the Motorola App Note number is AN932 if anybody's interested. -- Mark Tilden: _-_-_-__--__--_ /(glitch!) M.F.C.F Hardware Design Lab. -_-___ | \ /\/ Un. of Waterloo. Canada, N2L-3G1 |__-_-_-| \/ work: (519)-885-1211 ext.2457, "MY OPINIONS, YOU HEAR!? MINE! MINE! MINE! MINE! MINE! AH HAHAHAHAHAHAHAHAHA!!"
king@dciem.UUCP (Stephen King) (06/09/87)
You could also try looking at Motorola's MC1378, a complete video overlay synchronizer. I have put together the evaluation board, as shown in the application notes, and found it to work quite well. Some of the passive components in the circuit may be hard to find (colour burst bandpass transformer, 200nS delay line). Even the chip itself may be hard to get. (I got engineering samples from Motorola) It does, however, provide genlock, RGB input, 36Mhz clock (10x colour frequency), NTSC or PAL composite video input and overlay enable. Well worth investigating! /* these are, of course, only my own humble opinions */ ...!utzoo!dciem!king sjk.
hedley@cbmvax.cbm.UUCP (Hedley Davis) (06/10/87)
In article <173@mv06.ecf.toronto.edu> drascic@ecf.UUCP writes: >I want to overlay the graphics output of a computer onto a video image >of the real world, to implement a cursor. This means that I have to >sync the camera to the computer's video, which is reasonably easy to do. >But once I have the two signals, I have to combine. Someone suggested >that "keying" was the route. This involves switching between the two >signals, depending on the level of one of them. Unfortunately, this >seems to be very expensive. > >Is it possible to simply add the two signals through appropriate >resistors? Or are there chips available suitable for building a >simple keyer? Any hints, suggestions, or suppliers would be much >appreciated. > > David Drascic UUCP: drascic@ecf.toronto.edu OR drascic@utecfb The synchonization is the tricky part. For a simple cursor, you could probably do it with hardware of small complexity. For anything more complex, there is really only one cost effective solution. Please no flames for this ( requested ) advert. The Amiga seris of computers from Commodore support genlocking. This allows the amiga video output to be synchonized with, and overlayed upon an external composite video source ( like a camera or VCR ). The genlock then produces a composite video output ( suitable for feeding to a VCR or monitor ). If your needs are immediate, I suggest that you obtain a A1000 with a A1300 genlock ( manufactured by commodore ). If you can wait a few months the A2000 ( fancier box with better expansion capabilities ), with its genlock would be a better bet. Still later, other goodies ( as yet unannounced ) will be forth coming. On the software end, several video titlers and animiation packages are available now ( and others are RSN ). If indeed this is for the university, we have a discount program for such originizations. You might contact Dave Archambault at (215)-431-9193 about such policies. He is the man handling all the university marketing and accounts. Hedley
ex499mih@CS.UCLA.EDU (06/12/87)
IBM has recently released a piece of hardware which it calls "Infowindow". Its purpose is as a controller for level III interactive videodisc courses. One of its primary functions is to "mix" computer graphics and ntsc video on the same display. This is accomplished by using the EGA resolution mode which most closely matches the resolution of the ntsc signal (I'm no video expert, so please excuse my vagueness). Special hardware stops the EGA at the beginning of each screen refresh in order to synch it with the ntsc scan. The User (program) selects one graphics color which the hardware will consider to be "transparent" to video. As the EGA is "read" during refresh, any pel which is to have the same value as the transparent color is given the ntsc signal at that time (i.e. EGA goes to the display until transparent color, if = transparent color then NTSC). That's about it I guess.
phil@osiris.UUCP (06/15/87)
In article <6583@shemp.UCLA.EDU>, ex499mih@CS.UCLA.EDU writes: > The User (program) selects one graphics color which the hardware will > consider to be "transparent" to video. As the EGA is "read" during refresh, > any pel which is to have the same value as the transparent color is given > the ntsc signal at that time (i.e. EGA goes to the display until transparent > color, if = transparent color then NTSC). Wow, what a novel concept! :-) Suppose IBM will try to patent it? But seriously.. this sounds just like a digital form of chroma keying. (I even seem to remember someone suggesting chroma keying as a solution to the original poster's problem.) Question for all you serious broadcast people out there: I imagine the original chroma key hardware was analog. Is it still done that way, or is it done digitally now? Seems to me that with these new-fangled digital video controllers stuff like this would be getting much simpler, if not cheaper... ...!decvax!decuac!\ Phil Kos ...!seismo!mimsy!aplcen!osiris!phil The Johns Hopkins Hospital ...!allegra!/ Baltimore, MD
hedley@cbmvax.cbm.UUCP (Hedley Davis) (06/16/87)
In article <1171@osiris.UUCP> phil@osiris.UUCP (Philip Kos) writes: >Question for all you serious broadcast people out there: I imagine the >original chroma key hardware was analog. Is it still done that way, or is >it done digitally now? Seems to me that with these new-fangled digital >video controllers stuff like this would be getting much simpler, if not >cheaper... > Typically, the computer is phase locked to the incoming video signal. The actual switching is done with analogue hardware. This avoids ever having to digitize the incoming video signal ( an expensive proposition ). I've heard of full digital units which do digitize the incoming video. These often give you other bells and whistles like freeze frame, color and contrast corrections ( under software control ), and frame grabbing. They are more expensive then your run of the mill genlock. Hedley
jhma@eagle.UUCP (06/18/87)
Summary: Expires: Sender: Followup-To: The Atari ST range of computers can be genlocked: Ask Atari and I'm sure they'll be glad to tell you..... Also the old MSX ( Remember them? ) machines used a chip ( 9918? 9938? Something like that ) which had a video plane immediately in front of it's background plane and behind all the sprite planes. Try digging up a data sheet: I'm sure it's still available. Tris Mabbs. ~~~~~~~~~~~ ...!seismo!mcvax!ukc!tehm tehm@uk.ac.ukc
upl@puff.UUCP (06/20/87)
In article <3119@eagle.ukc.ac.uk> tehm@ukc.ac.uk (Tris 'Mad' Mabbs) writes: > > The Atari ST range of computers can be genlocked: Ask Atari and >I'm sure they'll be glad to tell you..... > How?????? The ST uses a non NTSC (70 hz) video siginal. If they ARE genlocking, I can't figure out how the trick is down. (The main reason, well okay one of three or do main reasons) I eventually bought an Amiga was becuase it gave me an NTSC out to use with my video equiptment. By the way, a good professional studio should be able to genlock itself to the NTSC out from yor computer, thus you could use the studio's chroma key to build the images you want. Using decent studio equiptment has some real advantages in terms of control and flexability, if you can afford it. Jeff Kesselman upl@puff.cs.wisc.edu
mdoerr@uklirb.UUCP (06/23/87)
|In article <3119@eagle.ukc.ac.uk> tehm@ukc.ac.uk (Tris 'Mad' Mabbs) writes: |> |> The Atari ST range of computers can be genlocked: Ask Atari and |>I'm sure they'll be glad to tell you..... |> |How?????? The ST uses a non NTSC (70 hz) video siginal. If they ARE genlocking, |I can't figure out how the trick is down. (The main reason, well okay one of |three or do main reasons) I eventually bought an Amiga was becuase it gave me |an NTSC out to use with my video equiptment. As far as I know it can't be done in hires mode (monochrome, 71 Hz), but it can be done in lowres and medres mode (color, 50/60 Hz). There are several German companies which advertise genlock interfaces for the ST. Michael Doerr (...!seismo!unido!uklirb!mdoerr)
dave@onfcanim.UUCP (Dave Martindale) (06/24/87)
In article <804@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: > >By the way, a good professional studio should be able to genlock itself to >the NTSC out from yor computer, thus you could use the studio's chroma >key to build the images you want. Using decent studio equiptment has some >real advantages in terms of control and flexability, if you can afford it. > >Jeff Kesselman This is *not* true in general (in fact, I don't know of any frame buffer/ workstation for which it is true). The problem is that, though your frame buffer may generate video that matches the NTSC timing parameters, it is RGB video, not NTSC. A studio's sync generator will indeed lock its own sync to the computer's sync, but there is no colour subcarrier coming out of the computer for the studio's sync generator to lock to. Thus colour subcarrier phase will wander randomly with respect to sync. (I know of no sync generator that will lock its *subcarrier* output to a video input that contains only sync.) This produces a signal which is good enough to record on some recorders, but it does not meet broadcast standards, and can't be used for single-frame recording on 1 inch machines. The only way to get broadcast-quality video is to have the subcarrier and sync generated within the same piece of equipment, generally divided down from the same oscillator. The normal way of doing this is to use a studio sync generator as the master timing source, and slave the computer's video to sync from the sync generator (this is what the genlock option of the computer does). It could also be done by having the computer generate a subcarrier signal, but I've never seen it done that way.
cmcmanis%pepper@Sun.COM (Chuck McManis) (07/01/87)
In article <15342@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: .>In article <804@puff.WISC.EDU> upl@puff.WISC.EDU (Future Unix Gurus) writes: .>>By the way, a good professional studio should be able to genlock itself to .>>the NTSC out from your computer, thus you could use the studio's chroma .>>key to build the images you want. Using decent studio equiptment has some .>>real advantages in terms of control and flexability, if you can afford it. .>> .>>Jeff Kesselman .> .>This is *not* true in general (in fact, I don't know of any frame buffer/ .>workstation for which it is true). .> .>The problem is that, though your frame buffer may generate video that .>matches the NTSC timing parameters, it is RGB video, not NTSC. .>A studio's sync generator will indeed lock its own sync to the computer's .>sync, but there is no colour subcarrier coming out of the computer for .>the studio's sync generator to lock to. Thus colour subcarrier phase .>will wander randomly with respect to sync. (I know of no sync generator .>that will lock its *subcarrier* output to a video input that contains .>only sync.) Well in Jeff's case it *IS* true, because the Amiga generates NTSC video on its composite video output connector. Color subcarrier and everything. It is however, in the case of the Amiga, easier to sync the Amiga to the studio than vice versa, you just feed in external sync to the RGB connector. That is how the Amiga 1300 GenLock works, it syncs the Amiga to the incoming video rather than trying to go the other way around. A side effect of this is that the Genlock converts NTSC video into separate RGB and sync, which I find kinda neat since I can watch TV on my RGB monitor if I want to. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
dave@onfcanim.UUCP (07/03/87)
In article <22455@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > >Well in Jeff's case it *IS* true, because the Amiga generates NTSC video >on its composite video output connector. Color subcarrier and everything. >It is however, in the case of the Amiga, easier to sync the Amiga to >the studio than vice versa, you just feed in external sync to the RGB >connector. I stand corrected about the Amiga. There is an additional reason to want to lock the Amiga to the studio's sync generator rather than vice versa: To meet NTSC specs, the oscillator in the studio's master generator has to be extremely stable - about 3 parts per million absolute frequency accuracy, and very low drift rate over time. To achieve this, either a crystal in a temperature-regulated oven or a temperature-compensated crystal oscillator are used. If the Amiga is locked to the studio's generator, the Amiga's output video will also be this stable. If you lock the studio's generator to the Amiga's composite output, then the studio's sync generator stability will be degraded to whatever standard the Amiga's presumably simpler oscillator provides. Since the sync generator also drives any VTRs, switchers, etc. that are in use, the entire editing studio is now locked to the Amiga. If you have a choice, it's best to pick the most stable sync source available.