orovner@sdcc13.ucsd.edu (Oleg Rovner) (01/12/91)
According to the manufacturer, DCTV will be shipping January 14th. (yes, of THIS year :-) OR PS This was told to me by digital creations during a phone call last week, so I don't think that the date could be REALLY off. -- "Nobody in this city would get shot if they just did what the cops told them to." San Diego Police Department Officer Shane Martin (in SD Union, December 23, 1990)
hyy94@campus.swarthmore.edu (03/05/91)
Does anybody out there have DCTV for their Amiga? I was just wondering... How does the output look on NTSC? Fuzzy? Clear? Sharp? How good are the results from its digitizing feature? What about conversion of DCTV file to HAM? Can a normal Amiga screen bet output through DCTV? Would you want to do this? Is it really worth $399? Thanks, -Ho Yang
barry@netcom.COM (Kenn Barry) (03/06/91)
In article <DSWYJ7T@cs.swarthmore.edu> hyy94@campus.swarthmore.edu writes: >Does anybody out there have DCTV for their Amiga? I was just wondering... Yep. Bought it a little over a week ago. >How does the output look on NTSC? Fuzzy? Clear? Sharp? I'd say it looks excellent. Of course, it is a composite image, not RGB, but within the constraints imposed by NTSC, yes, it looks very fine. >How good are the results from its digitizing feature? It seems to work superbly. I've been surprised how easy it is to digitize. I would have anticipated that lighting and such would be much more critical than they appear to be. I even get very good results digitizing from my (cheap) VCR using freeze-frame, if the tape is a clean tape, and if I advance frames until I get one that looks steady on the display. The digitizing module also gives you some image processing functions, to modify things like color balance, brightness, contrast, etc. The main limitation of DCTV's digitizing feature is that it takes 6-10 seconds to capture a frame. You can't simply take a "snapshot" of a video signal that's in motion. >What about conversion of DCTV file to HAM? This is, in my opinion, the weakest module in the DCTV package. Overall, I've preferred the results I've gotten by using The Art Department to perform this conversion. DCTV can save out a 24-bit IFF file that TAD can read and convert. >Can a normal Amiga screen bet output through DCTV? Would you want to do >this? I'm unclear what you're asking. DCTV will read most any IFF graphics file and convert it to a DCTV image. However, you wouldn't want to run all your Amiga's output to a composite monitor, given a choice, since composite lacks the sharpness of an RGB image. This is not a problem, however, because you don't lose your normal output when you attach DCTV. I use my 1080 monitor to display both normal output and DCTV output. Switching over is simply a matter of flipping the monitor's switch between RGB and composite display. For pictures, though, esp. digitized photos, it can be advantageous to convert and view them through DCTV. Most images I've done this with, esp. HAM images, look better as DCTV images than they do as HAMs. >Is it really worth $399? I hope so - I paid more than that :-). So far I'm quite happy with it. I want to also mention the 'paint' program that's included in the package. As some others have indicated, this is the nicest paint program I've seen on the Amiga, really loaded with useful features, and generally easy to use. This is, for example, the first program I've found that makes colorizing of images reasonably easy, and gives satisfactory results. Partly that's due to its not having to deal with the color complexities of HAM mode, but it's also that the operation is easier to do than with HAM paint programs I've used (Photon Paint, DigiPaint). Summary: Plusses: high-quality color digitizing, excellent paint program, pictures displayable on normal Amiga monitor (switched to composite mode) using any standard 'show' utility, attaches to any Amiga (I have an A1000), easy to use, affordable. Minuses: composite output, slow digitizing, takes away the parallel port. - From the Crow's Nest - Kenn Barry ---------------------------------------------------------------- ELECTRIC AVENUE: barry@netcom.com OR apple!netcom!barry
ceej@mole.ai.mit.edu (Chris Hillery) (03/06/91)
In article <27019@netcom.COM> barry@netcom.COM (Kenn Barry) writes: >In article <DSWYJ7T@cs.swarthmore.edu> hyy94@campus.swarthmore.edu writes: >>Does anybody out there have DCTV for their Amiga? I was just wondering... > > Yep. Bought it a little over a week ago. > Ok, then, I'd like to ask a few questions too.. (= First and foremost, this box uses the Amiga's CHIP mem for picture storage, correct? So can you really use the full features and so forth with only 512K of chip mem? Secondly, how exactly does this equipment? I assume you plug it into the parallel port, and then what do you do to show a picture? I'm really trying to decide between going for this or a ColorBurst and could really use any info on either... Thanks in advance!... > > >- From the Crow's Nest - Kenn Barry >---------------------------------------------------------------- >ELECTRIC AVENUE: barry@netcom.com OR apple!netcom!barry Ceej aka Chris Hillery ceej@rpi.edu
anderson@mrcnext.uiuc.edu (Brent James Anderson) (03/06/91)
I have a NEC-3D and flickerFixer board. I also use a switch box and a cable I purchased from Redmond Cable to choose between sending the flickerFixed output to the NEC or good 'ol 23pin Amiga RGB. The NEC does not have composite in. Just the 9 (or 15 w/o converter) pin RGB type input. My question: Is DCTV totally out of the picture for a setup like this? With the NEC-3D is there any way of using DCTV? I'm guessing a big yes. Next question: Have you seen Firecracker? If so, would it be usable on my system described above? I'd appreciate if anyone could list the (major) differences between the two and also welcome opinions. BTW: I'm pretty confused by the recent deluge of "high color" add on boards for the Amiga. 1) Are they all 24bit color? 2) What are all of them? :-) 3) What are their resolutions? 4) If not 24bit color then how many colors at a time out of how many? 5) Can I use any of them on the above equipment configuration. 6) Other main features, like digitization etc... Whew :-) -Beej
tbissett@nstar.rn.com (Travis Bissett) (03/06/91)
hyy94@campus.swarthmore.edu writes: > > Does anybody out there have DCTV for their Amiga? I was just wondering... > > How does the output look on NTSC? Fuzzy? Clear? Sharp? > > How good are the results from its digitizing feature? What about > conversion of DCTV file to HAM? > > Can a normal Amiga screen bet output through DCTV? Would you want to do > this? > > Is it really worth $399? > > > Thanks, > > -Ho Yang > I saw DCTV recently at a user group meeting. IMHO, the output was clear and no color banding was evident -- without having a side-by-side comparison or a video technician's eye for such differences I'd guess that it stood up very well in output against a Targa board. And, when oyu especially consider the cost it looks even more impressive! I didn't see a didigitizing feature -- does it really have one? No, the Amiga screen output will not pass thru the DCTV. In effect, you switch from Amiga RGB to DCTV video. If the 1084 or 1950 didn't let you have two monitors in one (rgb & composite) then you'd have to have two separate monitors. Hope this helps -- Travis Bissett NSTAR conferencing site 219-289-0287 internet: tbissett@nstar.rn.com 1300 newsgroups - 8 inbound lines uucp: ..!uunet!nstar.rn.com!tbissett 99 file areas - 4300 megabytes --- backbone news & mail feeds available - contact larry@nstar.rn.com ---
jason@cbmami.UUCP (Jason Goldberg) (03/07/91)
In article <13749@life.ai.mit.edu>, Chris Hillery writes: > First and foremost, this box uses the Amiga's CHIP mem for picture storage, > correct? So can you really use the full features and so forth with only > 512K of chip mem? > > Secondly, how exactly does this equipment? I assume you plug it into the > parallel port, and then what do you do to show a picture? I'm really trying > to decide between going for this or a ColorBurst and could really use any > info on either... > I can't remember the exact memory requirement, I think that in order to run the Paint program you need to 1 MEG (of which only 512K need be chip RAM). As for the ports: 1. It plugs into the Parallel port to send the picures it digitizes. 2. It plugs into the RGB port to get its graphics info (provides a pass-through) 3. Has a composite input for its digitizer. 4. Has a composite output for its output. The software comes with the digitizer (an 8 second slow scan, 24 bit digitizer), which allows quite a bit of image manipulation. A very full featured paint program. A conversion module for handling various IFF 24-bit, DCTV-24bit, and all the normal Amiga modes. The Paint module can load and save both IFF 24-BIT and DCTV format pictures with out the need for a conversion utility. The way that DCTV works is that it compresses the 24bit composit image into a compressed format which is stored as a 640x400 16 color IFF image. So when it is stored in DCTV format, any IFF picture view can display the image, on your RGB screen it will look like a 16 color greyscale abstract picture, but through the magic of DCTV it shows up as 16 million colors. What this means is that I am able to take a series of 24 bit IFF frames from Imagine or ProVista, convert them to DCTV format and then use CombineAnim to create a 24 bit animation, that can display as fast as a 16 color Anim. Another side benifit of these system is that a typical IFF 24-BIT image can take 500,000 bytes while the DCTV format of the same image can often be smaller than 100,000 bytes. -Jason- --------------------------------------------------------------------------- Jason Goldberg UUCP: ucsd!serene!cbmami!jason Del Mar, CA
barry@netcom.COM (Kenn Barry) (03/08/91)
In article <13749@life.ai.mit.edu> ceej@mole.ai.mit.edu (Chris Hillery) writes: >First and foremost, this box uses the Amiga's CHIP mem for picture storage, >correct? So can you really use the full features and so forth with only >512K of chip mem? Well, I have only 512K of chip mem, and haven't yet found it a limitation. The display format of a DCTV picture is similar in concept to the HAM-E format. It encodes additional information along the top and left edges of the picture to provide full-color output, but the picture appears to the standard Amiga hardware as a 4-plane, hires picture, and requires no more chip mem than you'd expect such a picture to require. You can actually view DCTV pics in RGB, though of course they look like junk that way. Extra fast memory is desirable, however. DCTV will work on a one-meg Amiga, but with some limitations. I have experienced no limitations on my own machine, which has 3 meg of fast mem. >Secondly, how exactly does this equipment? I assume you plug it into the >parallel port, and then what do you do to show a picture? I'm really trying >to decide between going for this or a ColorBurst and could really use any >info on either... DCTV has two completely separate connections to your Amiga. The parallel port connection is only for input to the digitizer, and need not even be connected when you're not digitizing. The display connection is an interceptor on the RGB output port, similar to HAM-E - it plugs into the RGB out, and your RGB monitor plugs into the DCTV plug. There are also two other connectors for DCTV, on the DCTV box, itself (a 1"x4"x4" external box). One is a composite-in, RCA plug which receives a composite signal (e.g., camcorder, VCR) for digitizing; the other is a composite-out which goes to the composite monitor you are using to view DCTV. - From the Crow's Nest - Kenn Barry ---------------------------------------------------------------- ELECTRIC AVENUE: barry@netcom.com OR apple!netcom!barry
barry@netcom.COM (Kenn Barry) (03/08/91)
In article <anderson.668252965@mrcnext> anderson@mrcnext.cso.uiuc.edu writes: >I have a NEC-3D and flickerFixer board. I also use a switch box and a cable >I purchased from Redmond Cable to choose between sending the flickerFixed >output to the NEC or good 'ol 23pin Amiga RGB. > >The NEC does not have composite in. Just the 9 (or 15 w/o converter) pin >RGB type input. > >Is DCTV totally out of the picture for a setup like this? >With the NEC-3D is there any way of using DCTV? I think you could use DCTV with your Amiga, but you couldn't send the output to your NEC. You'd need a separate, composite monitor for DCTV's output. An ordinary TV would probably do, long as it had an RCA-type, composite-in jack. >Next question: > >Have you seen Firecracker? Sorry, no. Kayembee
Scott_Busse@mindlink.UUCP (Scott Busse) (03/12/91)
* Person: Neil Richmond
* Org. : Rhythm & Hues, Inc., Hollywood
writes: If you want a good test for color banding. Try something
: like interpolating a dark blue to a darker blue or a dark red
: to a darker red or...
I did such a test with DCTV, using its paint program, saved the image in IFF24,
and took it home to view on my Mimetics board. Now, the Mimetics board is not
the greatest NTSC output I have seen, but when I displayed the image, the color
banding was terrible. But the fact is, it looked pretty good on the DCTV. I
think that's the bottom line, for the market they're attacking.
I certainly agree about the NTSC problem though. I'm going to get a
FireCracker or something that outputs RGB in true 24bit color. I have a
reasonably good RGB-NTSC converter that can take it from there. You folks over
at Rhythm & Hues don't have to worry much about DCTV's NTSC output though, I
don't suppose :)
* Scott Busse email: O O O_ _ ___ .....
* CIS 73040,2114 ||| /|\ /\ O/\_ / O )=|
* a763@mindlink.UUCP l | | |\ / \ /\ _\
* uunet!van-bc!rsoft!mindlink!Scott_Busse Live Long and Animate... \neil@celia.UUCP (Neil Richmond) (03/12/91)
In article <uZXDy5w161w@nstar.rn.com> tbissett@nstar.rn.com (Travis Bissett) writes: >I saw DCTV recently at a user group meeting. IMHO, the output was clear and >no color banding was evident -- without having a side-by-side comparison or >a video technician's eye for such differences I'd guess that it stood up >very well in output against a Targa board. And, when oyu especially consider If you want a good test for color banding. Try something like interpolating a dark blue to a darker blue or a dark red to a darker red or a light green to a slightly darker green. Got the idea? With NTSC you will always get banding when you interpolate shades that are close in hue and value. Why? Because NTSC is not very good a resolving small changes, because NTSC color is a kludge. As long as there is a wide range of values, you will get a good picture. This goes for whatever output device you use ie DCTV, Targa, Video Toaster etc. If you want good looking color use RGB. You can always run the signal through an encoder to get NTSC. This is a bit more expensive than composite output, but it has more flexibility. neil -- Only 3218 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
neil@celia.UUCP (Neil Richmond) (03/16/91)
In article <5110@mindlink.UUCP> Scott_Busse@mindlink.UUCP (Scott Busse) writes: > I certainly agree about the NTSC problem though. I'm going to get a >FireCracker or something that outputs RGB in true 24bit color. I have a >reasonably good RGB-NTSC converter that can take it from there. You folks over For my money it is RGB. I'll be looking at something like a FireCracker for my system. Of course, there is a lot to be said for a good paint system, as I have heard that the one that comes with DCTV is very good. >at Rhythm & Hues don't have to worry much about DCTV's NTSC output though, I >don't suppose :) True, we don't use Amigas, but not one is safe from the dreaded ... " NTSC Banding Problem ":-) neil -- Only 3214 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
kcampbel@uafhp.uark.edu (Keith Alan Campbell) (03/18/91)
One issue that seems to have been effectively bypassed during the recent discussions on DCTV has been the effective resolution of the screen images. I understand that DCTV probably should not be thought of in terms of pixels, but what would the equivalent screen resolution be on the Amiga? Hi-res overscan? 320x200? Don Kennedy Vision Quest Systems
bobl@graphics.rent.com (Bob Lindabury - SysAdm) (03/19/91)
neil@celia.UUCP (Neil Richmond) writes: > In article <5110@mindlink.UUCP> Scott_Busse@mindlink.UUCP (Scott Busse) write > > > I certainly agree about the NTSC problem though. I'm going to get a > >FireCracker or something that outputs RGB in true 24bit color. I have a > >reasonably good RGB-NTSC converter that can take it from there. You folks ov > > For my money it is RGB. I'll be looking at something like a FireCracker for > my system. Of course, there is a lot to be said for a good paint system, as > I have heard that the one that comes with DCTV is very good. > > >at Rhythm & Hues don't have to worry much about DCTV's NTSC output though, I > >don't suppose :) Actually, I believe they do. I'm sure Neil will correct me if I'm wrong but I believe that R&H's money products are TV Spots. Final output is probably 1" tape or D2 (D1, whatever). At any rate, the final product that is broadcast is NTSC so steps have to be taken even if they are outputing RGB to what-have-you because the final NTSC product *MUST* have saturation levels reduced to fit into NTSC color bandwidth. On the other hand, I imagine that all output could be recorded to film and then a film to tape transfer done. I believe this would be more costly and I don't think this is the norm. > True, we don't use Amigas, but not one is safe from the dreaded ... " NTSC > Banding Problem ":-) > > neil Maybe Neil can tell us the typical path of one of thier animations... -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
neil@celia.UUCP (Neil Richmond) (03/26/91)
In article <0Xa3y4w164w@graphics.rent.com> bobl@graphics.rent.com (Bob Lindabury - SysAdm) writes: >> >at Rhythm & Hues don't have to worry much about DCTV's NTSC output though, I >> >don't suppose :) >Actually, I believe they do. I'm sure Neil will correct me if I'm >wrong but I believe that R&H's money products are TV Spots. Final >output is probably 1" tape or D2 (D1, whatever). At any rate, the >final product that is broadcast is NTSC so steps have to be taken >even if they are outputing RGB to what-have-you because the final >NTSC product *MUST* have saturation levels reduced to fit into NTSC >color bandwidth. Well, it is true. We don't have to worry about DCTV's NTSC output:-). But we do worry about our NTSC output. We have strict FCC regulations as to what the signal looks like. Mostly, in the area of maximums, but sometimes minimums as well. The FCC doesn't want too much black either. Our bread and butter is TV spots. Not so much broadcast these days, flying logos, station IDs. We do a lot of commercial work. Our output these days is usually D1 or D2. We seldom do output to 1" anymore. >On the other hand, I imagine that all output could be recorded to >film and then a film to tape transfer done. I believe this would be >more costly and I don't think this is the norm. This is more costly in time and money. Film has to be wedged, bracketted, carefully. Film requires higher resolution frames, 2k-4k, which means longer rendering times. We do this only at a clients request. Sometimes we do features. >Maybe Neil can tell us the typical path of one of thier animations... I am not sure what you mean by this, Bob. Do you mean our production process? If you want I'll try to prepare a document outlining the process. neil -- Only 3203 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
bobl@graphics.rent.com (Bob Lindabury - SysAdm) (03/28/91)
neil@celia.UUCP (Neil Richmond) writes: > >Maybe Neil can tell us the typical path of one of thier animations... > > I am not sure what you mean by this, Bob. Do you mean our production process? > If you want I'll try to prepare a document outlining the process. What I meant was the actual hardware path. From (Alias/whatever) RGB to scan converter to D2 to whatever, whatever. It would be interesting for us to know the basic hardware and adjustments that are done to a typical 3D piece to get to the final product. Not the full production process as that would be quite a paper! B^) -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
ACPS1072@RYERSON <ACPS1072@Ryerson.CA> (03/30/91)
>>> Maybe Neil can tell us the typical path of one of thier animations... >> >>I am not sure what you mean by this, Bob. Do you mean our production process? >>If you want I'll try to prepare a document outlining the process. > What I meant was the actual hardware path. From (Alias/whatever) > RGB to scan converter to D2 to whatever, whatever. It would be > interesting for us to know the basic hardware and adjustments that > are done to a typical 3D piece to get to the final product. Not the > full production process as that would be quite a paper! B^) Actually some of us (namely me) would be interested in the "full production process". So if it is not to much of a hassle (and as long as it doesn't give away any trade secerets) by all means post some info. What kind of equipment do you use (both computer and video hardware), what software do you use? (ie. is it Alias? homemade?? :-> ). How long does it usually take to get a creative idea onto the screen as a finished version? Derek Lang<<<<< | ACPS1072@Ryerson | "Get this clown trained. I want him in the games Toronto, ON | until he dies playing. Acknowledge." Canada | - MCP
neil@celia.UUCP (Neil Richmond) (04/05/91)
In article <N54HZ3w164w@graphics.rent.com> bobl@graphics.rent.com (Bob Lindabury - SysAdm) writes: >What I meant was the actual hardware path. From (Alias/whatever) >RGB to scan converter to D2 to whatever, whatever. It would be >interesting for us to know the basic hardware and adjustments that >are done to a typical 3D piece to get to the final product. Not the >full production process as that would be quite a paper! B^) > The hardware path is not very complex or interesting, really. We use SGI devices for modelling, choreography and rendering. Finished frames are usually dumped to an Abekas Digital Frame storage Device. The Abekas can hold from 25-60 secs worth of frames. From the Abekas, we usually go to D1 or D2, occasionally going right to 1". We do not use any package software like Wavefront or Alias, although I believe we still have a Wavefront license or two from the old days. We use our own software. We also have a flat art scanner which can scan up to 18" square piece of art. We are in the process of buliding a digital film scanning device for when we do film effects or if someone sends us film to match to. neil -- Only 3194 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
neil@celia.UUCP (Neil Richmond) (04/19/91)
Well, I have had DCTV for two nights and already I can see some room for
improvement. I was a little disappointed that the flood fill only worked
with a stencil. What I fear is, that this is because it is not a " true "
24 bit image that we are dealing with. I hope my fears are groundless. I
am also concerned that RGB add on device that is coming out soon uses to
composite signal and converts it to RGB. This sounds like a kludge. Does
anyone have any more info on this?
neil
--
Only 3179 shopping days left till the next millenium!
Neil F. Richmond INTERNET: celia!neil@usc.edu
Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) (04/20/91)
>Well, I have had DCTV for two nights and already I can see some room for >improvement. I was a little disappointed that the flood fill only worked >with a stencil. What I fear is, that this is because it is not a " true " >24 bit image that we are dealing with. I hope my fears are groundless. I >am also concerned that RGB add on device that is coming out soon uses to >composite signal and converts it to RGB. This sounds like a kludge. Does >anyone have any more info on this? What does having a 'TRUE' 24 bit image have to do with floodfills? If DCTV didn't have true 24 bit then I shouldn't be able to toss Toaster pics back and forth between it and DCTV without loss of image quality. Even if I save off the 700k+ toaster file as a DCTV Display file (300k), then reload the 300k file and save as 24bit IFF, I get the same crisp clear image on the toaster that I had originally. --------------------------------------- | patrick_meloy@outbound.wimsey.bc.ca | | 'The Outbound' BBS Vancouver BC | ---------------------------------------
patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) (04/20/91)
>Well, I have had DCTV for two nights and already I can see some room for >improvement. I was a little disappointed that the flood fill only worked >with a stencil. What I fear is, that this is because it is not a " true " >24 bit image that we are dealing with. I hope my fears are groundless. I >am also concerned that RGB add on device that is coming out soon uses to >composite signal and converts it to RGB. This sounds like a kludge. Does >anyone have any more info on this? Oops, I forgot. If you take a better look you will see that you can use the continuous line tool with a fill. Outline the area you want filled and presto! A straight floodfill would be near impossible since a flood fill requires a continuous single color border around the area to be filled. You may be looking at a seemingly 'all same colour' area and try to flood fill it, then have it bleed all over the picture. Then you'd be yelling about a buggy flood fill :) Two days is not enough to really get into DCTV, It took me a week to really get a feel for the program. Being biased by 'normal' paint programs doesn't help as DCTV paint takes a somewhat different approach. For instance, in DPaint and other paint programs I use the continuous line tool almost exclusively, yet in DCTV I use the 'spotted' brush (I forget what the actual name is). As a matter of fact, I have never used the floodfill on a stencil, I find the fill gadget/line tool combo quicker and just as accurate. hmmm, maybe they should just drop the flood fill completely as I see no use for it.. --------------------------------------- | patrick_meloy@outbound.wimsey.bc.ca | | 'The Outbound' BBS Vancouver BC | ---------------------------------------
patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) (04/20/91)
> You're dreaming. The 300K file contains nowhere NEAR the >resolution as the 24 bit Toaster image. The catch is that the >NTSC display is only slightly better than the DCTV image so the >difference is hardly noticable. HOWEVER, if you compared the DCTV >conversion of the 24 bit Toaster file with the output from an RGB >24 bit frame-buffer, you would notice the difference. > Be sure that DCTV is slightly worse than NTSC, I belive >mainly in vertical resolution. Although I'm not certain what is >in that 300K and what is in that 700K file, there is no way that >NOTHING is lost when you remove 4/7 of the file. Well, consider this. The toaster output I work with is the 768x482 (non full size image). That gives a total maximum number of colours of 370,176 on screen. What is to keep them from just saving THAT data to the 300k file and tossing the rest of the information that is not used? Or, could they be doing something sneaky and actually do a compression on the file? I can Lharc up files and save as much as 95% on space. Couldn't that be done with a 24 bit pic too? Find a Toaster, Render a pic, load it into DCTV and save as display file. Then reverse the process and look at the pic on the same toaster and compare it to the original file. THEN tell me I'm dreaming :) --------------------------------------- | patrick_meloy@outbound.wimsey.bc.ca | | 'The Outbound' BBS Vancouver BC | ---------------------------------------
patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) (04/20/91)
>Huh? "crisp clear image" doesn't apply to NTSC video. <grin> > >-- Bob > > The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" > ============================================================================ > InterNet: bobl@graphics.rent.com | Raven Enterprises > UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue > BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 > Home #: 908/560-7353 | 908/271-8878 Okokok, the same muddy glop that I had on the toaster in the first place :) --------------------------------------- | patrick_meloy@outbound.wimsey.bc.ca | | 'The Outbound' BBS Vancouver BC | ---------------------------------------
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/20/91)
In article <patrick_meloy.5461@outbound.wimsey.bc.ca> patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: > >What does having a 'TRUE' 24 bit image have to do with floodfills? If DCTV >didn't have true 24 bit then I shouldn't be able to toss Toaster pics back >and forth between it and DCTV without loss of image quality. Even if I save >off the 700k+ toaster file as a DCTV Display file (300k), then reload the >300k file and save as 24bit IFF, I get the same crisp clear image on the >toaster that I had originally. > You're dreaming. The 300K file contains nowhere NEAR the resolution as the 24 bit Toaster image. The catch is that the NTSC display is only slightly better than the DCTV image so the difference is hardly noticable. HOWEVER, if you compared the DCTV conversion of the 24 bit Toaster file with the output from an RGB 24 bit frame-buffer, you would notice the difference. Be sure that DCTV is slightly worse than NTSC, I belive mainly in vertical resolution. Although I'm not certain what is in that 300K and what is in that 700K file, there is no way that NOTHING is lost when you remove 4/7 of the file. >--------------------------------------- >| patrick_meloy@outbound.wimsey.bc.ca | >| 'The Outbound' BBS Vancouver BC | >--------------------------------------- -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
bobl@graphics.rent.com (Bob Lindabury - SysAdm) (04/20/91)
neil@celia.UUCP (Neil Richmond) writes: > Well, I have had DCTV for two nights and already I can see some room for > improvement. I was a little disappointed that the flood fill only worked > with a stencil. What I fear is, that this is because it is not a " true " > 24 bit image that we are dealing with. I hope my fears are groundless. I > am also concerned that RGB add on device that is coming out soon uses to > composite signal and converts it to RGB. This sounds like a kludge. Does > anyone have any more info on this? I don't have any specific information on the above problem but what I was told by one of the reps at AmiExpo in NY a few weeks back was that the current DCTV was just a cheap consumer version. They plan a complete rack-mountable professional unit that will address all the concerns we are having now with the product (ie: lack of RGB, resolution, etc.). Also they are suppose to be coming out with a true 4:2:2 or 4:4:2 system. Can someone tell us all what these numbers mean? I know they have something to do with chroma and luminance channels but I am unsure as to the "official" meaning of these figures. Sounds like they have some good plans ahead. They also said that if there was enough interest, they might just port the DCTV paint software over for the Toaster. That would be great! -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
bobl@graphics.rent.com (Bob Lindabury - SysAdm) (04/20/91)
patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: > What does having a 'TRUE' 24 bit image have to do with floodfills? If DCTV > didn't have true 24 bit then I shouldn't be able to toss Toaster pics back > and forth between it and DCTV without loss of image quality. Even if I save > off the 700k+ toaster file as a DCTV Display file (300k), then reload the > 300k file and save as 24bit IFF, I get the same crisp clear image on the > toaster that I had originally. Huh? "crisp clear image" doesn't apply to NTSC video. <grin> -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
bobl@graphics.rent.com (Bob Lindabury - SysAdm) (04/20/91)
patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: > >Well, I have had DCTV for two nights and already I can see some room for > >improvement. I was a little disappointed that the flood fill only worked > >with a stencil. What I fear is, that this is because it is not a " true " > >24 bit image that we are dealing with. I hope my fears are groundless. I > >am also concerned that RGB add on device that is coming out soon uses to > >composite signal and converts it to RGB. This sounds like a kludge. Does > >anyone have any more info on this? > > Oops, I forgot. If you take a better look you will see that you can use the > continuous line tool with a fill. Outline the area you want filled and > presto! A straight floodfill would be near impossible since a flood fill > requires a continuous single color border around the area to be filled. You > may be looking at a seemingly 'all same colour' area and try to flood fill > it, then have it bleed all over the picture. Then you'd be yelling about a > buggy flood fill :) Right! Most people get so use to Dpaint III and only 16 colors that they lose touch with the ideas behind 24-bit images. I'm not saying that's what happened to Neil <grin> but you can't just fill what seems to be a solid color. There may not be a solid color available in a digitized image of any consequence. Hence, you have to create a boundry line and fill inside of this boundry or as you said above, spill over. I find that it becomes more difficult to paint when you have such a large pallette. You have to actually be a reasonable artist to get the desired effect and you don't have the "Well, I only had 16 colors to work with" excuse for lousy shading, blending etc. -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/21/91)
In article <patrick_meloy.5615@outbound.wimsey.bc.ca> patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: > >Well, consider this. The toaster output I work with is the 768x482 (non full >size image). That gives a total maximum number of colours of 370,176 on >screen. What is to keep them from just saving THAT data to the 300k file and >tossing the rest of the information that is not used? Or, could they be doing >something sneaky and actually do a compression on the file? I can Lharc up >files and save as much as 95% on space. Couldn't that be done with a 24 bit >pic too? > 370K colors is about 18 bit, so you save 1/4 space if that was done. Also, try lharcing an IFF. You save very little space, on the order of 10%. It is text files that really compress well. >Find a Toaster, Render a pic, load it into DCTV and save as display file. Then >reverse the process and look at the pic on the same toaster and compare it to >the original file. THEN tell me I'm dreaming :) > Yes, because the Toaster is outputting NTSC and the DCTV is outputting almost NTSC. Compare the DCTV image to an RGB 24 bit framebuffer and you'll see the difference. DCTV is very good for video work, but comparing it to a 24 bit frame buffer just isn't accurate. >--------------------------------------- >| patrick_meloy@outbound.wimsey.bc.ca | >| 'The Outbound' BBS Vancouver BC | >--------------------------------------- -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (04/21/91)
bobl@graphics.rent.com (Bob Lindabury - SysAdm) writes: > neil@celia.UUCP (Neil Richmond) writes: >> I am also concerned that RGB add on device that is coming out soon uses to >> composite signal and converts it to RGB. This sounds like a kludge. Does >> anyone have any more info on this? > > I don't have any specific information on the above problem but what I was > told by one of the reps at AmiExpo in NY a few weeks back was that the > current DCTV was just a cheap consumer version. They plan a complete > rack-mountable professional unit that will address all the concerns we > are having now with the product (ie: lack of RGB, resolution, etc.). > Also they are suppose to be coming out with a true 4:2:2 or 4:4:2 system. > Can someone tell us all what these numbers mean? I know they have something > to do with chroma and luminance channels That would be 4:2:2 YUV. It defines the ratio of sampling of Y (luminance), versus the U:V (color diffs R-Y, B-Y) data. Older systems use 4:1:1. For example, to sample 720 dots/line, you might sample Y at 13.5MHz, while U and V are each sampled at 6.7MHz (4:2:2). Thus the luminance can change for _every_ dot, but the color changes every two dots (altho you can interpolate). Using only 4:1:1 would halve that color change frequency. As there are YUV->RGB encoder chips, the answer to the original question is that they'd most likely tap into the stored YUV data, not the composite signal. PS: To save memory space, YUV can be encoded as Delta values (DYUV). In CD-I, for example, 4:2:2 DYUV is used. Each word defines two pixels: 4-bits delta for each pixel of Y, allowing each pixel to change luminance. The other dual 4-bits are used for the DU and DY for both pixels (interpolated linearly). Because the eye is more sensitive to luminance than color, a DYUV device is preferable to DRGB (Amiga HAM). best - kevin <kdarling@catt.ncsu.edu> PPS: Pick up a Signetics Video Handbook... has the encode/decode chips.
kholland@hydra.unm.edu (Kiernan Holland) (04/22/91)
Everyone listen: Copy protection. IMAGINE it. Hint: it is the first thing you see. Gotta zapppppppppper The Riddler.
neil@celia.UUCP (Neil Richmond) (04/22/91)
In article <patrick_meloy.5461@outbound.wimsey.bc.ca> patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: >What does having a 'TRUE' 24 bit image have to do with floodfills? If DCTV >didn't have true 24 bit then I shouldn't be able to toss Toaster pics back >and forth between it and DCTV without loss of image quality. Even if I save >off the 700k+ toaster file as a DCTV Display file (300k), then reload the >300k file and save as 24bit IFF, I get the same crisp clear image on the >toaster that I had originally. Whoa My OverZealous Friend! To begin with DCTV is not true 24 bit display. Anything using NTSC as a final output is not 24 bit. DCTV is a very clever encoding scheme toward producing 24 bit graphics. What concerned me, was, how they were going to turn a composite NTSC signal into RGB. It is easy to make a good signal bad, but it is not easy to make a bad signal look good. You aren't going to sell me on NTSC. I have worked with it too long to have any respect for it. It is a necessary EVIL. My complaint about floodfills is another issue. There are many different fill algorithms. You can fill an antialiased bounded shape very successfully. I have written such a routine many years ago. It was based on a Siggraph paper about as old. Why did they chose to use the stencil to contain the filling algorithm? Their stencil is only 1 bit! This makes for some ugly looking filled areas. Whovever said I couldn't learn a paint program in two days knows very little about my experience. I wouldn't underestimate yours. Everytime I get on the program I learn more about its limitations. It is about as good as DPaint III, only more bits of color resolution. I was hoping for more out of the paint program. Initially, my use is not to use rendered images, but to use the paint program to do higher quality animations than I can turn out with DPaint. The fill routines are essential to what I am trying to do. Thus my lament. Hope- fully, their next version of the software will be better. Hopefully, what I fear about the hardware is unfounded. If it is, I will have to try a Fire- Cracker. What I want to know is how come there is a 24 bit RGB board for the Mac for under $500 and the firecracker is $1400? neil >--------------------------------------- >| patrick_meloy@outbound.wimsey.bc.ca | >| 'The Outbound' BBS Vancouver BC | >--------------------------------------- -- Only 3176 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
neil@celia.UUCP (Neil Richmond) (04/23/91)
In article <patrick_meloy.5471@outbound.wimsey.bc.ca> patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: >Oops, I forgot. If you take a better look you will see that you can use the >continuous line tool with a fill. Outline the area you want filled and >presto! A straight floodfill would be near impossible since a flood fill >requires a continuous single color border around the area to be filled. You >may be looking at a seemingly 'all same colour' area and try to flood fill >it, then have it bleed all over the picture. Then you'd be yelling about a >buggy flood fill :) Look, since I didn't explain what I am doing I will forgive this paragraph. Not everyone wants filled in areas as they work. If you are doing animation, you work with line drawings and fill them in later. You want your lines clean, otherwise it looks like it was done on a computer. As I mentioned earlier, there are algorithms for filling antialiased bounded areas. An the least they could have done is given me more bits for the stencil. Running a filter over a line blurs it and this is not the look I want. neil -- Only 3176 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
mark@masscomp.westford.ccur.com (Mark Thompson) (04/23/91)
In article <patrick_meloy.5615@outbound.wimsey.bc.ca>, patrick_meloy@outbound.wimsey.bc.ca (Patrick Meloy) writes: > Well, consider this. The toaster output I work with is the 768x482 (non full > size image). That gives a total maximum number of colours of 370,176 on > screen. What is to keep them from just saving THAT data to the 300k file and > tossing the rest of the information that is not used? Or, could they be doing Many people make this mistake. It would require a 19bit lookup table with 24 bit entries which works out to be 1.5M just for the lookup table. > Find a Toaster, Render a pic, load it into DCTV and save as display file. Then > reverse the process and look at the pic on the same toaster and compare it to > the original file. THEN tell me I'm dreaming :) This sequence does in fact alter the image but not noticeably on a composite display. Colors bleed a little bit more. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson CONCURRENT COMPUTER % % --==* RADIANT *==-- mark@westford.ccur.com Principal Graphics % % ' Image ` ...!uunet!masscomp!mark Hardware Architect % % Productions (508)392-2480 (603)424-1829 & General Nuisance % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mark@masscomp.westford.ccur.com (Mark Thompson) (04/23/91)
In article <iNcP16w164w@graphics.rent.com>, bobl@graphics.rent.com (Bob Lindabury - SysAdm) writes: > that the current DCTV was just a cheap consumer version. They plan a > complete rack-mountable professional unit that will address all the > concerns we are having now with the product (ie: lack of RGB, > resolution, etc.). Also they are suppose to be coming out with a > true 4:2:2 or 4:4:2 system. Can someone tell us all what these > numbers mean? I know they have something to do with chroma and > luminance channels but I am unsure as to the "official" meaning of > these figures. These refer to the sampling rates in a digital component video system. The numbers are actually ratios. 4:2:2 is the sample ratio for Y, Cb, Cr respectively and is the ratio used in all D1 systems. The luminance (Y) is sampled twice as much as the chrominance components because of the eye's decreased sensitivity to color bandwidth. 4:4:4:4 is the digital sampling ratio used in many professional video graphics systems. It also refers to the sample rate on Y, Cb, and Cr and the extra 4 refers to the sampling of a key signal (like an alpha plane for compositing/transparency). If I remember correctly, Digital Creations has plans for a 4:4:4:4 version of DCTV. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson CONCURRENT COMPUTER % % --==* RADIANT *==-- mark@westford.ccur.com Principal Graphics % % ' Image ` ...!uunet!masscomp!mark Hardware Architect % % Productions (508)392-2480 (603)424-1829 & General Nuisance % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
moonhawk@bluemoon.uucp (David Culberson) (04/24/91)
> > > IMAGINE it. > > Hint: it is the first thing you see. > > Gotta zapppppppppper Would it have something to do with un-copy protecting IMAGINE? David This is from moonhawk@bluemoon.uucp moonhawk%bluemoon@nstar.rn.com who doesn't have their own obnoxious signature yet
bobl@graphics.rent.com (Bob Lindabury - SysAdm) (04/24/91)
moonhawk@bluemoon.uucp (David Culberson) writes: > > IMAGINE it. > > > > Hint: it is the first thing you see. > > > > Gotta zapppppppppper > > Would it have something to do with un-copy protecting IMAGINE? > David > > This is from > moonhawk@bluemoon.uucp > moonhawk%bluemoon@nstar.rn.com > who doesn't have their own obnoxious signature yet What is this childish crap? First of all, Imagine is NOT copy protected. So all this innuendo is stupid. We all know that they have that lame startup screen and we all know that you just zap the Imagine program to get rid if it. I think it's more a productivity issue than a copy-protection thing. It takes too bloody long for that lame startup screen to load and I cringe everytime it comes up. A patch was posted previously for 1.0 that got rid of it. I would like it if someone could just post the patch for 1.1 as well because the startup screen is just an annoyance especially when you purchased the program to begin with. Almost as much of an annoyance as the above foolish posts. -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (04/25/91)
In a message From: bobl@graphics.rent.com (Bob Lindabury - SysAdm) >moonhawk@bluemoon.uucp (David Culberson) writes: > >> > IMAGINE it. >> > >> > Hint: it is the first thing you see. >> > >> > Gotta zapppppppppper >> >> Would it have something to do with un-copy protecting IMAGINE? >> David >> >> This is from >> moonhawk@bluemoon.uucp >> moonhawk%bluemoon@nstar.rn.com >> who doesn't have their own obnoxious signature yet > >What is this childish crap? First of all, Imagine is NOT copy >protected. So all this innuendo is stupid. We all know that they >have that lame startup screen and we all know that you just zap the >Imagine program to get rid if it. I think it's more a productivity >issue than a copy-protection thing. It takes too bloody long for >that lame startup screen to load and I cringe everytime it comes up. >A patch was posted previously for 1.0 that got rid of it. I would >like it if someone could just post the patch for 1.1 as well because >the startup screen is just an annoyance especially when you purchased >the program to begin with. I'm the guy who figured out the fix for 1.0. Unfortunately, the folks at Impulse did something clever to 1.1, so I can't use the same technique to defeat it in the update. Sorry. I feel like such a failure.... :-( Rick Tillery (drtiller@uokmax.ecn.uoknor.edu) Almost as much of an annoyance as the above foolish posts. -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/25/91)
In article <997@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: > >To begin with DCTV is not true 24 bit display. Anything using NTSC as a final >output is not 24 bit. Now this is false. I know of a very good board from Germany/Austria (the Videomaster VD2001) that provides true 24-bit graphics plus necessarily NTSC output, because it's thought for use in a professional video environment. And there you don't have a different choice. > What concerned me, was, how they were going to turn a composite >NTSC signal into RGB. It is easy to make a good signal bad, but it is not easy >to make a bad signal look good. You aren't going to sell me on NTSC. I have >worked with it too long to have any respect for it. It is a necessary EVIL. You must have gotten something wrong. They do it exactly the other way round, the easier way: they produce NTSC out of RGB. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/26/91)
In article <1161@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <997@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >> >>To begin with DCTV is not true 24 bit display. Anything using NTSC as a final >>output is not 24 bit. > >Now this is false. I know of a very good board from Germany/Austria >(the Videomaster VD2001) that provides true 24-bit graphics plus >necessarily NTSC output, because it's thought for use in a professional >video environment. And there you don't have a different choice. > Peter, the data may be STORED as a 24 bit image, and all computations may be 24 bit, but the output is NOT 24 bit. -- Ethan "Brain? What is Brain?"
seanc@pro-party.cts.com (Sean Cunningham) (04/27/91)
In-Reply-To: message from bobl@graphics.rent.com
IMAGINE is copy protected...
It apparently does some kind of snap shot of your system. Try to run it on
another machine after you've installed it, and it'll crash.
It'll stick wierd control characters in your GLOBALS timeline...insert
ACTORS that aren't there. And if you get as far as a RENDER, it LOCKS
after the initialization phase.
The protection has been verified by IMPULSE!
Sean
BTW> I'm not a pirate...I was trying to demonstrate the local dealer's copy
at a TV station. After an hour's work, I decided to call Impulse, and
their tech support (such as it is) told me about the protection.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham
ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810
INET: seanc@pro-party.cts.com ____________________________________
// | * All opinions expressed herein |
HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS |
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<bobl@graphics.rent.com (Bob Lindabury - SysAdm) (04/27/91)
seanc@pro-party.cts.com (Sean Cunningham) writes: > In-Reply-To: message from bobl@graphics.rent.com > > IMAGINE is copy protected... > > It apparently does some kind of snap shot of your system. Try to run it on > another machine after you've installed it, and it'll crash. > > It'll stick wierd control characters in your GLOBALS timeline...insert > ACTORS that aren't there. And if you get as far as a RENDER, it LOCKS > after the initialization phase. > > The protection has been verified by IMPULSE! > > Sean > > BTW> I'm not a pirate...I was trying to demonstrate the local dealer's copy > at a TV station. After an hour's work, I decided to call Impulse, and > their tech support (such as it is) told me about the protection. Sorry. Last I heard it wasn't. Since I purchased the software and have only RE-Installed it when I needed another copy, I guess I never had a chance to find out. My apologies to those who are trying to de-protect it. However, since the original disk is copyable prior to installation, why is there a need to deprotect it? The only change I would like to see is to get rid of the loading of the startup screen. -- Bob The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!" ============================================================================ InterNet: bobl@graphics.rent.com | Raven Enterprises UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854 Home #: 908/560-7353 | 908/271-8878
neil@celia.UUCP (Neil Richmond) (04/28/91)
In article <1161@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >Now this is false. I know of a very good board from Germany/Austria >(the Videomaster VD2001) that provides true 24-bit graphics plus >necessarily NTSC output, because it's thought for use in a professional >video environment. And there you don't have a different choice. Peter, NTSC is not 24 bits of display. I could not tell you what happens inside the DCTV, but I suspect it is a decoder and somehow they are able to encode 24 bit information in the header of the image. But the display is NTSC and NTSC is not 24 bits. NTSC color is a kludge to put color in a signal that was never designed to contain color information. If I remember correctly NTSC can only resolve something like 300,000 colors. That is not 24 bits. I am looking for a crad, which will come out some day, that will do RGB for under $500. The Mac has one, why not Amiga. Converting RGB to NTSC is no big deal. >You must have gotten something wrong. They do it exactly the other way >round, the easier way: they produce NTSC out of RGB. You have misunderstood me here. It is true that they convert an RGB signal to NTSC. However, it is some kind of clever encoding scheme. What I was saying is, that in the manual they are advertising a device that will take the output of the DCTV and turn it into RGB again, only decoded. How they will do this is a complete mystery to me, because they will be taking an inferior quality signal, NTSC and turning it into RGB. neil -- Only 3171 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
menzies@CAM.ORG (Stephen Menzies) (04/28/91)
seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from bobl@graphics.rent.com >IMAGINE is copy protected... > >It apparently does some kind of snap shot of your system. Try to run it on >another machine after you've installed it, and it'll crash. I'm not so sure, sean. I have two machines and have moved the program from one to the other after it was installed. I've had no problems other than what I would consider *real* bugs in the software, many of which I have verified with other registered users who are running it on the original machine it was installed on. > >It'll stick wierd control characters in your GLOBALS timeline...insert >ACTORS that aren't there. And if you get as far as a RENDER, it LOCKS >after the initialization phase. > I haven't had any problems with those. The problems I have had are: 1> System often crashes on an Undo (after heavy editing); 2> System crashes after entering unreasonable numbers in the Action editor; 3> Cycle editor refuses to load a "cycle" object that has been saved and reloaded 8 times (I had this verified, reported it to Impulse(1.0) and they haven't fixed it(1.1); 4> Grouped objects often "fly" away from their own axis(!) in the Stage editor during rotations. (can't figure this one out but it seems that if you add an increment of .0001 to the position bar on 1,2 and sometimes 3 axis, from the original position it loaded in, the object is ok again); 5> the accuracy of 1/1000 is not always maintained. (things move around aliittle). 6> their are others I can't think of right now and I suppose many more to come:( but the point being, maybe you got a "bum" copy or you have found some *new* bugs.) >The protection has been verified by IMPULSE! > Sounds pretty strange to me inlight of the above. >Sean > >BTW> I'm not a pirate...I was trying to demonstrate the local dealer's copy > at a TV station. After an hour's work, I decided to call Impulse, and > their tech support (such as it is) told me about the protection. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham > ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 > INET: seanc@pro-party.cts.com ____________________________________ > // | * All opinions expressed herein | > HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -- Stephen Menzies Email: S.Menzies@CAM.ORG
seanc@pro-party.cts.com (Sean Cunningham) (04/29/91)
In-Reply-To: message from es1@cunixb.cc.columbia.edu The output from the DCTV device is not 24bits, it's 22bits. However, it uses a pallette of 24bits. A 24bit image may be manipulated without any degradation to the color information stored in the file, and then saved as a full 24bit IFF-ILBM. You just work on a 22bit display, the device doesn't truncate or remap the information in the file. And besides, there is NO difference onscreen anyway. 22bits equals out to 4.2 million possible colors simultaneously (from a 24bit pallette remember). At 736x482 pixels, you have 354,752 USEABLE colors. An extra two bitplanes would give your image NO better display. If DCTV only displayed 19bits out of 24, there would still be NO difference in image quality. Since we are dealing with video, and its relatively low resolution, argueing over what is considered a "true" 24bit device is pointless, because in this context there is no difference (so long as all of the color information in the file remains intact). Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
mark@calvin..westford.ccur.com (Mark Thompson) (04/29/91)
seanc@pro-party.cts.com (Sean Cunningham) writes: >The output from the DCTV device is not 24bits, it's 22bits. However, it >uses a pallette of 24bits. >And besides, there is NO difference onscreen anyway. 22bits equals out to >4.2 million possible colors simultaneously (from a 24bit pallette >remember). At 736x482 pixels, you have 354,752 USEABLE colors. An extra >two bitplanes would give your image NO better display. Well regrettably there is a difference. I own both DCTV and a Toaster and DCTV exhibits some fairly obvious banding on images that the Toaster displays just fine. Since both are NTSC devices, DCTV is obviously not doing the best that NTSC can handle, let alone coming close to a 24bit RGB output. %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~% % ` ' Mark Thompson CONCURRENT COMPUTER % % --==* RADIANT *==-- mark@westford.ccur.com Principal Graphics % % ' Image ` ...!uunet!masscomp!mark Hardware Architect % % Productions (508)392-2480 (603)424-1829 & General Nuisance % % % ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
seanc@pro-party.cts.com (Sean Cunningham) (04/30/91)
In-Reply-To: message from bobl@graphics.rent.com As long as they're not trying to install Imagine onto another machine, there really is no reason to even try and break this protection. The software, like most, has a one machine liscence (sp), so it's really illegal to have it installed on more than one machine. You can make backups all you want, and as long as you're just installing it on the very first machine you installed it on, there will be no hassles. :) I feel sorry for anyone who couldn't wait to see what the package was like, and decided to run it on a dealers Amiga :) Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
sschaem@starnet.uucp (Stephan Schaem) (04/30/91)
If you are use to 24RGB output you coulndt say DCTV is close to it. A good example is text and windows... Pretty much blury. And you can get the old HAM effect visible when you import images from sculpt for example... That's from personal experience, *I* think DCTV is to 24bit has HAM is to 12 bit... But for what DCTV is intented for it perform right! And how could expect more with 4bit/pixel, simply amazing...
peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/30/91)
In article <1002@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >In article <1161@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >>Now this is false. I know of a very good board from Germany/Austria >>(the Videomaster VD2001) that provides true 24-bit graphics plus >>necessarily NTSC output, because it's thought for use in a professional ^^^^ (Sorry, this is really PAL, but not principle difference.) >>video environment. And there you don't have a different choice. > >Peter, NTSC is not 24 bits of display. ..... >...... If I remember correctly NTSC can >only resolve something like 300,000 colors. That is not 24 bits. Ok, ok, NTSC (or the same with PAL) can't take *full* advantage of those 24 bits, but they can give much more colors than the normal 4096 colors display. >You have misunderstood me here. It is true that they convert an RGB signal to >NTSC. However, it is some kind of clever encoding scheme. As far as I understand the problem with NTSC (and PAL) coding is that under these schemes you cannot use full saturated colors and must limit the saturation (depending on which color) to a level NTSC can take up with. This indeed can be done by such a clever encoding scheme. > What I was saying >is, that in the manual they are advertising a device that will take the output >of the DCTV and turn it into RGB again, only decoded. How they will do this is >a complete mystery to me, because they will be taking an inferior quality >signal, NTSC and turning it into RGB. I guess there's no magic at all. They sure don't take the analog NTSC signal as source, but the digital RGB data available one step earlier in their box. Then they perhaps need a little adaptor board to make these signal lines available. But this is all pure speculation. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
hrlaser@crash.cts.com (Harv Laser) (05/01/91)
In article <8909@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from es1@cunixb.cc.columbia.edu > > >The output from the DCTV device is not 24bits, it's 22bits. However, it >uses a pallette of 24bits. > >A 24bit image may be manipulated without any degradation to the color >information stored in the file, and then saved as a full 24bit IFF-ILBM. >You just work on a 22bit display, the device doesn't truncate or remap the >information in the file. Hi, Sean. I was hoping what you said in that paragraph above was true, but up till now I was unable to verify it. Now I am able to verify it, and it's NOT true, unfortunately. DCTV *does* induce artifacts into files, at times, depending on what the original file looked like and it's relatively easy to prove providing you have some OTHER extended or "deep color" hardware device on the same Amiga as your DCTV. In this case, I have a HAM-E box and DCTV hooked up at the same time. I can create (via many methods - Vista Pro, Imagine, ES300C scanner, whatever) a clean 24-bit IFF file. Depending on what's in that file, when it is brought into DCTV it will often develop a case of "color crawl" - false rainbows on various small detail areas, like close parallel lines, metallic clothing, very fine human hair, and etc. I'm sure you've seen this artifacting. Now if I save that file OUT of DCTV as an IFF24-bit save, and look at both the original save, and the DCTV save when loaded into HAM-E the latter is most *definitely* not identical to the former. The color crawl that DCTV displayed in its NTSC mode gets saved back into the file when is saved out of DCTV as IFF24. Since HAM-E isn't NTSC it doesn't induce any color crawl of its own (although it does have some other problems) and it's very easy to see what DCTV has done to the file while saving it. A FireCracker would be a better testbed for the same two files and I hope to be able to do it that way soon, although something tells me I won't be able to have an FC, a DCTV and a HAM-E all hooked up to my 2500 simultaneously. So far, the latter two are working together okay and aren't having a slug-fest on my desk :-) >Sean > "Half of me wants to knock you out. Harv Laser Half of me wants to tell you that {anywhere}!crash!hrlaser I'm sorry..." American People/Link: CBM*HARV
seanc@pro-party.cts.com (Sean Cunningham) (05/01/91)
In-Reply-To: message from menzies@CAM.ORG Those bugs are deffinately there in v1.0 of Imagine. But Jesus Christ, I talked with an EMPLOYEE of the company that makes the bleedin' program, and it IS COPY PROTECTED. What more do you want? A transcript of our conversation??? While I'll admit that their tech support really stinks...and it could have been the janitor who answered the phone, this is highly unlikely. If you've been able to move it from machine to machine, then this only proves that is a less than effective method on certain machines. But try and move it from an A3000 to an A2500, and you're just asking for grief! Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
colin_fox@icecave.wimsey.bc.ca (Colin Fox) (05/01/91)
sschaem@starnet.uucp writes: > I have to object 100% to that! come on... > On the personal Iris you just add you video ram to get 24bit has you > add memory to a A3000. He wasn't saying that you CAN'T expand the Iris, just that that's what it comes with - it was for explanitory purposes, not competitive. > DCTV -> 4 bit per pixel, 640x400 (+Overscan). Are you out of your mind? 4 bits/pixel? 16 colours? HA! > You can display the full 24bit palette for having 24bit without 24bit > is 'not' trully possible or you impose limitation of color choices. > And the amiga has only 5 true planes. Yeah, well DCTV has it's own NTSC output, and therefore isn't restricted by the Amiga's video circuitry. And what does the first sentence in the last group mean? > With true 24bit display you can display DCTV images, but DCTV cant > display corectly all 'true' 24bit display... What are you talking about? Have you tried? > Has I laready said, try line drawing, text, windows etc... on DCTV. Since DCTV uses a separate frame buffer, you would have to write your own graphics library to use it. But you'd have to expect that unless Commodore included it on-board. > If you compare DCTV vs Colorburst you will see little diference with > 'TV' images (DCTV will look a little more blury), but with anything > else DCTV will go short. Again - have you tried? And what do you mean 'but with anything else DCTV will go short"? 24 bits is 24 bits. Or in the apparent case of DCTV, 22 bits. Still better than 16 bits. +-------------------------------------+----------------------------------+ | Colin_Fox@icecave.wimsey.bc.ca | "...heavy!" | +-------------------------------------+ "There's that word again! Is | | Informal home of SIGGRAPH Vancouver,| there a problem with gravity in | | and proud of it! | the future?" -- Doc | +-------------------------------------+----------------------------------+
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (05/02/91)
>> What I was saying is, that in the manual they are advertising a device >> that will take the output of the DCTV and turn it into RGB again, > >I guess there's no magic at all. They sure don't take the analog NTSC >signal as source, but the digital RGB data available one step earlier Could someone here with a DCTV, open it up and post the chip numbers they find? If so, then I suspect that we could come to some sound conclusions. Or better guesses, at least :-). thx - kevin <kdarling@catt.ncsu.edu>
seanc@pro-party.cts.com (Sean Cunningham) (05/02/91)
In-Reply-To: message from mark@calvin..westford.ccur.com You have to pick your colors carefully with DCTV, that I'll agree. However, most instances of banding can be resolved with a quick pass of the NTSC FILTER fill/wipe... Also, you aren't taking into account DCTV's strong point. Try animating with your Toaster's display :) You won't do it without alot more expensive gear. DCTV isn't the end-all, be-all device some people may be looking for, but what it does it does well. The next display adapter I buy is going to have to have RGB out, non-interlaced, and preferably support a moniter larger than 13". But even after I have such a device, DCTV will still be most helpful... Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
sschaem@starnet.uucp (Stephan Schaem) (05/02/91)
Have I tried? Of course I tried stuff on the DCTV!! And people you laught when I say 4 bit/pixel but think one second! DCTV use the amiga video chip to output its 'compacted' data, than what resolution amiga has at 60frame second? 640x400x4... and DCTV dont flip pages to get more data. (I show DCTV images with my ushow program..). Hame is '12bit' but only use 6 bit, that make you laught too? DCTV not only rely on the previews color output but also on its position on screen (Just an idea!). For example drawind a yellow line will not only change data on 1 bit aray but many... It need transition colors before geeting to 'true color'. That will make a blury effect eliminating some detail, and could cause a ham like effect ig color chnage is to sudden. Anyway, DCTV is 4bit or 3bit per pixel, and Colorburst is 8bit or 24bit.Take DCTV out of its desing enviroment and it will not perform has a 24bit display. Stephan.
neil@celia.UUCP (Neil Richmond) (05/03/91)
In article <1179@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >I guess there's no magic at all. They sure don't take the analog NTSC >signal as source, but the digital RGB data available one step earlier >in their box. Then they perhaps need a little adaptor board to make >these signal lines available. But this is all pure speculation. Well..., I spoke to someone at Digital Creations the other day. He was not very specific, but he mentioned that he thought the RGB device would go between the DCTV and the Amiga RGB port. My reaction is that this does not make much sense. I don't know that much about the RGB output, except what I see in the manual and it does not look bi-directional. If you put a device of some kind between the DCTV and the Amiga, it seems to me that you are bypassing the DCTV altogether. The person I spoke to said that he thought it would RGBize the composite signal to give RGB which confirms my concerns. He said it was to be done mostly for those who want to apply a genlock. He said their main customer base was video oriented. And that you still get more colors than ham. I saw in the manual where they were going to be aiming at the Desktop Publishing market as well. My reaction is still that painting in NTSC will give you an inferior quality image to painting in RGB even if the DCTV can create 24 bit ILBM files, because you are not really painting with 24bits. I spoke to Progressive Peripherals, who actually make the DCTV box. They had no comment until June when this RGB device is supposed to be released. Well, it looks like I will have to get a Firecracker, which is too bad, because it is very expensive and you can buy a similar device for a Mac for under $500. Of course, in order to put a 68040 in the Mac LC you have to invest $3000. YOW!!! neil -- Only 3166 shopping days left till the next millenium! Neil F. Richmond INTERNET: celia!neil@usc.edu Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
menzies@CAM.ORG (Stephen Menzies) (05/03/91)
seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from menzies@CAM.ORG > >Those bugs are deffinately there in v1.0 of Imagine. I believe I was describing the bugs in v1.1 > >But Jesus Christ, I talked with an EMPLOYEE of the company that makes the >bleedin' program, and it IS COPY PROTECTED. > >What more do you want? A transcript of our conversation??? No, because I believe you. > >While I'll admit that their tech support really stinks...and it could have >been the janitor who answered the phone, this is highly unlikely. > >If you've been able to move it from machine to machine, then this only >proves that is a less than effective method on certain machines. But try >and move it from an A3000 to an A2500, and you're just asking for grief! > Sean, I just moved Imagine1.1 from my 030/2000HD to my A3000 (right behind me). I opened a project, made a small scene, checked out the Action editor (everything fine, no strange charcters) and then rendered the pic in scanline (52secs) and viewed it. Infact, I moved 1.1 from the 2000 to the 3000 awhile ago and have been working on both machines to the tune of 40,000ploygons that have been taking upwards of 60hr/frame to render (film resolution ) and have not had any problems other than the bugs I mentioned earlier. If there is copy protection , then we're missing a point or a factor somewhere here. >Sean > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham > ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 > INET: seanc@pro-party.cts.com ____________________________________ > // | * All opinions expressed herein | > HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -Stephen -- Stephen Menzies Email: S.Menzies@CAM.ORG
hrlaser@crash.cts.com (Harv Laser) (05/04/91)
To avoid utter chaos, confusion, and the end of the universe as we
know it, DCTV is made for Digital Creations by "Progressive Image
Technology", a company in the Sacramento, CA area, not by "Progressive
Peripherals", a company in the Denver, CO area.
"Half of me wants to knock you out. Harv Laser
Half of me wants to tell you that {anywhere}!crash!hrlaser
I'm sorry..." American People/Link: CBM*HARVseanc@pro-party.cts.com (Sean Cunningham) (05/05/91)
In-Reply-To: message from hrlaser@crash.cts.com That's very curious...I've done some color spreads, and added backgrounds to some 3D files, saved the image as an IFF24 (without ever converting it to a DCTV display file...this WILL cause artifacting), and then taken them up to the local dealer's Toaster. Worked without a hitch...without a glitch. If others are experiencing problems with their DCTV, I'm sorry. I do notice the artifacting that occurs when you use very oversaturated colors. Typically, this can be solved quite easily by running the NTSC filter across the image. When broadcast, the artifacts are unnoticable to the average viewer (they don't view the pictures a foot and a half from the screen typically), and I'm careful on my color choice. It's not perfect. But if you don't have $2K for a SFC, and $7K for a GOOD industrial deck, it's the best solution currently IMHO. Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
seanc@pro-party.cts.com (Sean Cunningham) (05/05/91)
In-Reply-To: message from kdarling@hobbes.catt.ncsu.edu I've been thinking about doing just that... I've always been curious as to just what IS inside the DCTV box. However, I haven't wanted to do it because their are no screws. You could pry open the bottom, but I wouldn't guarantee you'd be able to put it back together. Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
seanc@pro-party.cts.com (Sean Cunningham) (05/05/91)
In-Reply-To: message from sschaem@starnet.uucp 60fps really isn't possible on a 640x400x4 screen. In ANY interlaced mode, you're only going to be doing 30fps, because the FIELDS are doing 60fps. 640x200 mode will do 60fps fine, because the screen's drawn at that speed. As for DCTV images, they're stored in 4 and 3 bit images, but the "goobers and twinkies" perform the necessary magic to unpack the extended information. Position, at least to maintain your screen, is critical. If anything trashes the upper left corner, and the left edge of the screen, your image is trashed. Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
seanc@pro-party.cts.com (Sean Cunningham) (05/06/91)
In-Reply-To: message from menzies@CAM.ORG Perhaps they took the protection out of v1.1 My partner received it alittle while after I posted that message to you, but we haven't tried moving it to any machine but his. It probubly would make no difference anyhow, considering we both are running A3000s. So far, from what I've been able to gather from working with this version, the only bug I've found personally is that IMAGINE screws up images that are mapped onto flat surfaces. It takes whatever the background color (of the image) is and mixes it all up into the image itself, making it look really BAD. It really ticks me off too, because we needed to do some images with a logo mapped onto the ground, and onto a vertical plane...both look pretty screwed up. Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
menzies@CAM.ORG (Stephen Menzies) (05/06/91)
seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from menzies@CAM.ORG >Perhaps they took the protection out of v1.1 > >My partner received it alittle while after I posted that message to you, >but we haven't tried moving it to any machine but his. It probubly would >make no difference anyhow, considering we both are running A3000s. > >So far, from what I've been able to gather from working with this version, >the only bug I've found personally is that IMAGINE screws up images that >are mapped onto flat surfaces. It takes whatever the background color (of >the image) is and mixes it all up into the image itself, making it look >really BAD. > >It really ticks me off too, because we needed to do some images with a logo >mapped onto the ground, and onto a vertical plane...both look pretty >screwed up. > >Sean > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham > ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 > INET: seanc@pro-party.cts.com ____________________________________ > // | * All opinions expressed herein | > HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1991 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Thats really strange, Sean. I don't have the problem you're describing at all. My flat maps are A-OK. But I have problems that others apparently don't and others are having problems that probably you nor I have. It's almost like we all are working with different versions of the software. This gives a different meaning to the word "unstable". Personally I find Imagine VERY unpredicable. The only thing I can suggest re: flat mapping , is to make sure your brush axis is not flush with the surface of the flat object. This will often give that "digital bounce" I'm sure you've heard of before. Other than that (and I suspect you already were aware of that) I can't imagine what's causing the problem. cya -steve e -- Stephen Menzies Email: S.Menzies@CAM.ORG
baxter_a@wehi.dn.mu.oz (05/07/91)
In article <1991May6.084353.12871@CAM.ORG>, menzies@CAM.ORG (Stephen Menzies) writes: > > Thats really strange, Sean. I don't have the problem you're describing at > all. My flat maps are A-OK. But I have problems that others apparently > don't and others are having problems that probably you nor I have. It's > almost like we all are working with different versions of the software. > This gives a different meaning to the word "unstable". Personally I > find Imagine VERY unpredicable. Much more likely is it is written in C and has an array overwrite somewhere (or other similar, simple, but hard to find) error in the code which affects different parts of the code/os depending on how the code has been scatter loaded at execution. A very common problem in large system programming. Regards Alan