Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!ADS.ARPA!Info-Graphics-Request From: Info-Graphics-Request@ADS.ARPA.UUCP Newsgroups: mod.graphics Subject: Info-Graphics Digest Message-ID: <8703291143.AA09007@ucbvax.Berkeley.EDU> Date: Sun, 29-Mar-87 06:00:27 EST Article-I.D.: ucbvax.8703291143.AA09007 Posted: Sun Mar 29 06:00:27 1987 Date-Received: Sun, 29-Mar-87 23:40:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-Graphics@ADS.ARPA Distribution: world Organization: The ARPA Internet Lines: 404 Approved: info-graphics@ads.arpa Info-Graphics Digest Sun Mar 29 03:00:28 PST 1987 - Send submissions to Info-Graphics@ADS.ARPA - Send requests for list membership to Info-Graphics-Request@ADS.ARPA Today's Topics: PAINT-BOX equivalent Re: How do they do it on TV? Submission for mod-graphics Workshop Graphics Hardware fractal beauty symposium, Boston Submission for mod-graphics Please help me with Halo graphics ---------------------------------------------------------------------- Date: Sun, 22 Mar 87 12:09 EST From: (ANIL KHULLAR) Subject: PAINT-BOX equivalent X-Original-To: info-graphics@ads.arpa I saw a few weeks back the use of PAINTBOX in NBC (the T.V. guys). I was wondering if there is a similar software available for VAX/VMS or VAX/BSD 4.2 or any IBM-AT based machines ? The software should be able to directly take input from a Video-Camera and be able to manipulate the resultant image by changing the color or mask images. Please send me mail directly I shall collect and post it on the net. Anil Khullar {Ph.D. Program in Psychology City Univ. Graduate Center. New York NY 10036} INTERNET: ank%cunyvms1.BITNET@wiscvm.edu BITNET: ANK@CUNYVMS1 BELL-NET (212) 790 4360 ________________________________________________________________________ [DISCLAIMER: I, and I alone am responsible for my wisdom or follies. My employers, The Computer Center; are to be left out of any controversy] ------------------------------ Date: Thu, 26 Mar 87 13:06:22 cst From: watson@im4u.utexas.edu (William J. Watson) Posted-Date: Thu, 26 Mar 87 13:06:22 cst Subject: Re: How do they do it on TV? Organization: U. Texas CS Dept., Austin, Texas Back in about 1975 or so, a company called Vital Enterprises produced a product that they called "Squeezoom (tm)." This product digitized a video image and stored it in fast memory. It could then read the memory selectively to perform pan, rotate, zoom, and other modifications on the stored image. It did this by picking the pixels it wanted out of the stored image, and displaying them. Most of you are probably making gagging and choking noises out there, but try to remember that this was the early seventies, and even buying the RAM they needed was difficult and expensive. By about 1980, they had managed to work up to manipulating six images to produce one image on each face of a rotating cube. At any rate, the product was a success. ABC (I think) bought a big system for the broadcast of the Montreal winter Olympics, and after that, everyone who could afford it HAD to buy one. Time passed. Technology improved. Competitors fumed, and worked very hard in their labs. And so... In about 1981, several companies (Ampex, The Grass Valley Group, perhaps Sony and some others) came out with their ideas of what the market wanted. Only these companies had more capital to invest in development than little Vital Industries. They had been in the business longer, too. Also, they had been picking at Vital's box, and mumbling about the ragged edges on the images. So the new products were much fancier than Vital's original. They didn't really cost too much more, either, because the prices of the components had dropped while they were designing their systems. The could afford to build high-speed pipelined digital signal processors, or at least fast digital filters. They smoothed off the edges, and allowed new images to be read in to one bank of memory while the old one was being transformed. This allowed for real-time image manipulation. As they worked, they produced new products, such as NTSC to PAL and PAL to NTSC format converters based on the same technology. Business boomed. New, better products were designed. Parts became still cheaper. The newest systems became cheap enough that individual stations could afford them, but only the biggest stations in the biggest markets. The smaller stations still worked with their small video switchers, which allowed them to insert a small imaged in the corner of their main feed. Usually this meant that they would set up a camera facing a monitor, to perform the zoom opration that they could not afford to do any other way. They could have the anchor speak to the field reporter to introduce the story, and then cut to the remote feed for the story itself. S what if they couldn't expand the image from the corner smoothly like the network could! Neither could their competetion. But they saved their money and waited for the prices to drop far enough. As it stands now, the prices are still falling, except for memory, due to the anti-dumping accord. Some stations can now afford what they previously only dreamed of owning. New products that can save the images away and play them back later in a random sequence have appeared. More images can be manipulated. More new images can be created with "paint boxes." More manufacturers sell more products to more buyers, and everyone is happy. William J. Watson P. S. Please correct any major blunders that have crept into the preceeding history. I have been a bit out of touch with the industry for the last several years. ------------------------------ From: mcvax!cwi.nl!fons@seismo.CSS.GOV (Fons Kuijk) Date: 27 Mar 87 14:48:53 GMT Subject: Submission for mod-graphics Responding-System: boring.mcvax.cwi.nl Path: mcvax!fons From: fons@mcvax.cwi.nl (Fons Kuijk) Subject: Workshop Graphics Hardware Date: 27 Mar 87 14:48:50 GMT Distribution: world Organization: CWI, Amsterdam Lines: 67 Call for Papers for the _S_e_c_o_n_d _E_U_R_O_G_R_A_P_H_I_C_S _W_o_r_k_s_h_o_p _o_n _G_r_a_h_i_c_s _H_a_r_d_w_a_r_e August 24-25, 1987 during Eurographics '87, Amsterdam, the Netherlands organised by Centre for Mathematics and Computer Science (CWI) sponsored by The Eurographics Association _S_c_o_p_e _a_n_d _p_u_r_p_o_s_e _o_f _t_h_e _W_o_r_k_s_h_o_p: The ongoing advances in micro-electronics and the avai- lability of VLSI-design systems offer graphics systems designers totally new options for graphics hardware solutions. The workshop brings together leading work- ers in the field to present the state-of-the-art, to discuss alternative architectures, to relate design styles to the different tasks in graphics systems and to foresee achievable progress in the next few years. _S_t_y_l_e _o_f _t_h_e _W_o_r_k_s_h_o_p: A mixture of invited and refereed papers will be presented. Ample time to discuss all interesting details and to summarise the results achieved in the workshop will be guarantied. The number of participants will be limited. Apply therefore as soon as possible by submitting a first draft of your contribution of about 10 a4 pages, before May 15. The workshop will be co-chaired by Prof. Dr. W. Strasser, Institut fur Informatik, Tubingen (FRG) and Drs. F. Kuijk, CWI, Amsterdam (NL). _I_n_f_o_r_m_a_t_i_o_n: All information about the workshop and submission of contributions should be done, using the following address: Ms. Marja Hegt CWI Dept. of Interactive Systems Postbus 4079 1009AB Amsterdam The Netherlands Telephone: +31-20-592 4058 Telex: 12571 mactr nl Usenet: marja@mcvax.UUCP ------------------------------- Fons Kuijk, CWI, Amsterdam. fons@cwi.nl ------------------------------ Date: Fri, 27 Mar 87 13:40:03 EST From: Michael Beeler Subject: fractal beauty symposium, Boston The M.I.T. Dept. of Mathematics and the Goethe Institute of Boston SYMPOSIUM The Beauty of Fractals: HISTORY, DYNAMICS ANE THE MODELING OF NATURAL PHENOMENA Introductory lectures by Michael Barnsley, Robert L. Devaney, Benoit B. Mandelbrot, Heinz-Otto Peitgen, and Richard Voss. Saturday, April 11, 1987 10 am - 5 pm MIT, Room 10-250 This symposium is being held during Mathematics Awareness Week and in conjunction with the exhibit on fractal geometry, "Frontiers of Chaos," at the Museum of Science, Boston. Free and open to the public. For further information, call the Goethe Institute, (617) 262-6050. ------------------------------ Date: Sat, 28 Mar 87 13:42:48 est From: tr@thumper.bellcore.com (Tom Reingold at thumper.bellcore.com) [] I am cross-posting this to comp.sys.ibm.pc, mod.graphics and comp.graphics. I am having a problem with the HALO graphics function package. My system includes: IBM PC/AT JRAM card with 2 MB memory; 512 KB is devoted to DOS Talltree's JRAM and JLASER device driver software, version 3.8 Canon LBP8 laser printer IBM EGA card with 256 KB memory Lattice C compiler version 3.1 using large memory model IBM DOS version 3.20 (the disk says version 3.21) Version 2.26b of the file HALOIBME.DEV Version 2.26 of the rest of Halo for Lattice C version 3. The problem is that I try to use two separate video pages of EGA memory and the package does not seem to support this, regardless of what the manual and the tech support person claim. Calls to display page 1 result in displaying the same old page. These pages are said to be numbered from 1 to 2 by the tech support person, not 0 to 1. I have tried using what the she said but the enclosed program uses 0 and 1. Calls to inqscreen and inqpage sometimes result in numbers such as 300. They don't seem to be reproducible. Yes, I know enough to pass addresses of values to Halo functions, not the values. Halo functions work this way. I want to be able to display something on the inactive page, then swap that page into the active screen memory. This would make for fast screen updates. Many commercial programs have succeeded in doing this. Is the Halo package at fault or is it my code or configuration? The code below displays two boxes on the screen at the same time! They should instead swap between keystrokes. #include main() { int color, x1, y1, x2, y2; int pri_scr = 0, alt_scr = 1, pri_dis = 0, alt_dis = 1; int c, i; tr_initgr(); /* This just calls the initgraphics routine. */ x1 = 10, y1 = 10, x2 = 100, y2 = 100; color = 2; setscreen(&pri_scr); display(&pri_dis); setcolor(&color); bar(&x1, &y1, &x2, &y2); setscreen(&alt_scr); color = 4; x1 = 100, y1 = 100, x2 = 300, y2 = 300; setcolor(&color); bar(&x1, &y1, &x2, &y2); display(&alt_dis); for (i = 0; i < 8; i++) { c = getch(); display(&pri_dis); c = getch(); display(&alt_dis); } tr_closegraphics(); /* This just calls the closegraphics routine. */ } Tom Reingold INTERNET: tr@bellcore.com -------- UUCP: ---- watmath!clyde!bellcore\ ucbvax\ \ lll-lcc\ ihnp4!mhuxt!ulysses!faline!flash!tr seismo!rutgers!mit-eddie!allegra/ -- Tom Reingold Internet: tr@bellcore.com Uucp: ..!allegra!ulysses!faline!flash!tr ------------------------------ From: root@cbosgd.mis.oh.att.com (Kunte Kinte) Date: 28 Mar 87 18:14:14 GMT Subject: Submission for mod-graphics Responding-System: cbosgd.ATT.COM Path: cbosgd!ulysses!faline!thumper!tr From: tr@thumper.UUCP (Tom Reingold) Subject: Please help me with Halo graphics Date: 28 Mar 87 17:11:57 GMT Lines: 81 [] I am cross-posting this to comp.sys.ibm.pc, mod.graphics and comp.graphics. I am having a problem with the HALO graphics function package. My system includes: IBM PC/AT JRAM card with 2 MB memory; 512 KB is devoted to DOS Talltree's JRAM and JLASER device driver software, version 3.8 Canon LBP8 laser printer IBM EGA card with 256 KB memory Lattice C compiler version 3.1 using large memory model IBM DOS version 3.20 (the disk says version 3.21) Version 2.26b of the file HALOIBME.DEV Version 2.26 of the rest of Halo for Lattice C version 3. The problem is that I try to use two separate video pages of EGA memory and the package does not seem to support this, regardless of what the manual and the tech support person claim. Calls to display page 1 result in displaying the same old page. These pages are said to be numbered from 1 to 2 by the tech support person, not 0 to 1. I have tried using what the she said but the enclosed program uses 0 and 1. Calls to inqscreen and inqpage sometimes result in numbers such as 300. They don't seem to be reproducible. Yes, I know enough to pass addresses of values to Halo functions, not the values. Halo functions work this way. I want to be able to display something on the inactive page, then swap that page into the active screen memory. This would make for fast screen updates. Many commercial programs have succeeded in doing this. Is the Halo package at fault or is it my code or configuration? The code below displays two boxes on the screen at the same time! They should instead swap between keystrokes. #include main() { int color, x1, y1, x2, y2; int pri_scr = 0, alt_scr = 1, pri_dis = 0, alt_dis = 1; int c, i; tr_initgr(); /* This just calls the initgraphics routine. */ x1 = 10, y1 = 10, x2 = 100, y2 = 100; color = 2; setscreen(&pri_scr); display(&pri_dis); setcolor(&color); bar(&x1, &y1, &x2, &y2); setscreen(&alt_scr); color = 4; x1 = 100, y1 = 100, x2 = 300, y2 = 300; setcolor(&color); bar(&x1, &y1, &x2, &y2); display(&alt_dis); for (i = 0; i < 8; i++) { c = getch(); display(&pri_dis); c = getch(); display(&alt_dis); } tr_closegraphics(); /* This just calls the closegraphics routine. */ } Tom Reingold INTERNET: tr@bellcore.com -------- UUCP: ---- watmath!clyde!bellcore\ ucbvax\ \ lll-lcc\ ihnp4!mhuxt!ulysses!faline!flash!tr seismo!rutgers!mit-eddie!allegra/ -- Tom Reingold Internet: tr@bellcore.com Uucp: ..!allegra!ulysses!faline!flash!tr ------------------------------ End of INFO-GRAPHICS ********************