gest_ss@uhura.cc.rochester.edu (Gavin Stark) (11/27/90)
Ok... In the newest Amiga World (Dec 1990, which is a very nice issue,, almost makes me want to resubscribe) there are two relatively low priced 24bit color boards advertised: DCTV by Digital Creations which can be found at an incredible price of $399 from Creative Computers, and the apperantly unreleased Colorburst board from M.A.S.T. advertised by them for $495. Has anyone had any experience with either of these boards? A 24 bit board for $399 is quite a temptation, and sounds a bit too good to be true. The DCTV board also says that it already has a paint program (which the MAST board is supposed to have as well) and can capture video. Any help/comparision between the two systems would be great. (also, does anyone have any horror/success stories about either Digital Creations and or MAST?) Gavin Stark gest_ss@uhura.cc.rochester.edu -- Gavin Stark gest_ss@uhura.cc.rochester.edu Member, society to promote the non-gender specific nature of the word "dude" "Knowledge is the ability to forget things." Arnold Pizer (Math Professor) Gavin: (person) Reported to be the largest waste of carbon in the universe.
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (11/29/90)
Well for comparison's sake, here's what I know (and think I know). Please
correct me if I'm wrong (do I really have to ask that on THIS Net?):
DCTV ColorBurst
---- ----------
24 bits 24 bits
384x480 max res.(???) 768x580 max res
NTSC only NTSC and PAL
Composite output RGB output
Frame capture No frame capture
Works with any Amiga Works with any Amiga
Uses Amiga's CHIP memory Has own 1.5Megs (Upgradable to 8)
Supports real time animation Does not support animation
Paint and convert s/w incl. Paint and conver s/w incl.
??? "Genlock" Amiga video over 24 bit
picture
$495 $495
You be the judge...neither is shipping yet, but I have contacted MAST
and should be getting a prototype Colorburst in a week or so. Production
starts in 2 weeks and they'll ship when the paint program is done.
Rick Tillery
(drtiller@uokmax.ecn.uoknor.edu)xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/29/90)
gest_ss@uhura.cc.rochester.edu (Gavin Stark) writes: > Ok... In the newest Amiga World (Dec 1990, which is a very nice > issue,, almost makes me want to resubscribe) there are two relatively > low priced 24bit color boards advertised: DCTV by Digital Creations > which can be found at an incredible price of $399 from Creative > Computers, and the apperantly unreleased Colorburst board from > M.A.S.T. advertised by them for $495. > Has anyone had any experience with either of these boards? A 24 bit > board for $399 is quite a temptation, and sounds a bit too good to be > true. Sigh. As indeed it is. These manufacturers are abusing standard terminology to lure in the gullible. I have no personal experience with either, but from previous postings about these products, they are not giving you three byte deep pixels, but merely three byte wide color output, from a color look up table driven by one byte deep pixels; roughly the same as the IBM-PC VGA display technology -- sixteen million-odd color _choices_, but only 256 colors at once. No big deal; save your money for the real thing. My personal feeling is that "24bit color" is sufficiently standard technology for a 24 bit deep frame buffer that a successful suit could be brought against these folks for false advertising and mail fraud, if anyone making a true 24 bit deep frame buffer wanted to bother. Then again, check them out, I could have misunderstood what I read; but check out anything that seems too good to be true; it usually is. Count the folks here who have been burned dealing with Montgomery Grant. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? -- Convener, ongoing comp.sys.amiga grand reorganization.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (11/29/90)
In article <1990Nov28.230731.29008@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >gest_ss@uhura.cc.rochester.edu (Gavin Stark) writes: > >> Ok... In the newest Amiga World (Dec 1990, which is a very nice >> issue,, almost makes me want to resubscribe) there are two relatively >> low priced 24bit color boards advertised: DCTV by Digital Creations >> which can be found at an incredible price of $399 from Creative >> Computers, and the apperantly unreleased Colorburst board from >> M.A.S.T. advertised by them for $495. > >> Has anyone had any experience with either of these boards? A 24 bit >> board for $399 is quite a temptation, and sounds a bit too good to be >> true. > >Sigh. As indeed it is. These manufacturers are abusing standard >terminology to lure in the gullible. I have no personal experience with >either, but from previous postings about these products, they are not >giving you three byte deep pixels, but merely three byte wide color >output, from a color look up table driven by one byte deep pixels; >roughly the same as the IBM-PC VGA display technology -- sixteen >million-odd color _choices_, but only 256 colors at once. No big deal; >save your money for the real thing. > I know nothing about the MAST product (I have strong fears of anything that company puts out) but you are absolutely wrong about DCTV. It doesn't use a standard bitmap method of display. I have seen its results and it has more than enough colors that I can't tell there is a limit. I have no reason to doubt the 16.7M color number listed. They are attempting to convert the NTSC signal into digital. I don't contend to understand how or what it does. However I've seen the result at trade shows (way back in April to be exact). They say the vertical resolution is 300 lines. The result is really hard to tell from NTSC TV images, although they have that characteristic NTSC flicker. >My personal feeling is that "24bit color" is sufficiently standard >technology for a 24 bit deep frame buffer that a successful suit could >be brought against these folks for false advertising and mail fraud, if >anyone making a true 24 bit deep frame buffer wanted to bother. > Or maybe someone else could be sued for libeling a product! 8-) >Then again, check them out, I could have misunderstood what I read; but >check out anything that seems too good to be true; it usually is. Count >the folks here who have been burned dealing with Montgomery Grant. > > > /// It's Amiga > /// for me: why >Kent, the man from xanth. \\\/// settle for ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? >-- >Convener, ongoing comp.sys.amiga grand reorganization. -- Ethan Woody Allen on Los Angeles: "I mean, who would want to live in a place where the only cultural advantage is that you can turn right on a red light?"
seanc@pro-party.cts.com (Sean Cunningham) (11/30/90)
In-Reply-To: message from drtiller@uokmax.ecn.uoknor.edu The only thing that I saw that was questionable in your comparison was the resolution of the DCTV, and its color output. It stores its extra information in what would look like a 4bit high-res (640x400+) image. Since its images cover the whole screen, and you're supposed to be able to animate with its images in DPaint, this would suggest a screen resolution of 704 x 480 pixels. It displays 22bits of information (4.2M) out of a 24bit pallette. But since you have a maximum of about 338,000 possible colors if every single pixel was different from every other, there's no difference in quality. I called Digital yesterday, and they said shipment to distributors the first week of December. 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 1990 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/30/90)
I think I'll stand by my previous statement, thanks. If a product doesn't provide the ability to assign any of 2^24 colors to each pixel independently, then the manufacturer should not be advertising it with the term "24 bit color", however gaudy and nice the color might actually be. A frame buffer is a frame buffer; anything else is just an attempt to skimp on quality or quantity of video ram and video ram interface chips to pass off a poorer quality job as the real thing. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) (12/01/90)
In-Reply-To: message from xanthian@zorch.SF-Bay.ORG
Kent is correct. The Ham-E and DCTV are =NOT= 24 bit frame buffers or boards.
They get thier color information from lookup tables or some such thing.
Animation with Ham-E can only be done by page flipping full pages, unless you
count writing your own software to create animations and such.
Don't be fooled by crafty advertising.
If you want true 24-bit, you'd best get a Toaster or Firecracker.
-- Bob
______ Pro-Graphics BBS "It's better than a sharp stick in the eye!" ________
UUCP: crash!pro-graphics!bobl | Pro-Graphics: 908/469-0049
ARPA/DDN: pro-graphics!bobl@nosc.mil | America Online: Graphics3d
Internet: bobl@pro-graphics.cts.com | CompuServe: RIP
_________ ___________
Raven Enterprises 25 Raven Avenue Piscataway, NJ 08854 mark@calvin..westford.ccur.com (Mark Thompson) (12/01/90)
In article <1990Nov29.091646.30595@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >In article <1990Nov28.230731.29008@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>gest_ss@uhura.cc.rochester.edu (Gavin Stark) writes: >>> Has anyone had any experience with either of these boards? A 24 bit >>> board for $399 is quite a temptation, and sounds a bit too good to be >>> true. >>Sigh. As indeed it is. These manufacturers are abusing standard >>terminology to lure in the gullible. They are not >>giving you three byte deep pixels, but merely three byte wide color >>output, from a color look up table driven by one byte deep pixels. >>No big deal; save your money for the real thing. >I know nothing about the MAST product (I have strong >fears of anything that company puts out) but you are absolutely >wrong about DCTV. The result is really hard to >tell from NTSC TV images, although they have that characteristic >NTSC flicker. He is NOT wrong. DCTV is NOT a true color 24bit frame buffer!!!!!!! They do some fancy image compression and they may get images that look like NTSC but they are NOT 24bit true color. You can see the difference plainly when you compare a 640x480 RGB 24bit color image with a lot of color detail to that of DCTV. What you get with DCTV is an image that looks like a TV image, unlike a 24bit RGB image on a monitor. This is all well and fine for video applications where luma and chroma bandwidth are strictly limited anyway. +--------------------------------------------------------------------------+ | Mark Thompson | | mark@westford.ccur.com | | ...!{decvax,uunet}!masscomp!mark Designing high performance graphics | | (508)392-2480 engines today for a better tomorrow. | +------------------------------------------------------------------------- +
rblewitt@sdcc6.ucsd.edu (Richard Blewitt) (12/02/90)
In article <6015@crash.cts.com> bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: >In-Reply-To: message from xanthian@zorch.SF-Bay.ORG > >Kent is correct. The Ham-E and DCTV are =NOT= 24 bit frame buffers or boards. > >Don't be fooled by crafty advertising. > >If you want true 24-bit, you'd best get a Toaster or Firecracker. What about the baord from Progressive Peripherals? The specs list it as 32-bit double buffering, based on the TI chips. Is it out yet? Does anyone know any more details? Rick Blewitt rblewitt@ucsd.edu
jsivier@ux1.cso.uiuc.edu (Jonathon Sivier ) (12/02/90)
In article <1990Nov30.043035.28769@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >I think I'll stand by my previous statement, thanks. If a product >doesn't provide the ability to assign any of 2^24 colors to each pixel > >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> I concur. What I would be most interested in would be a 24-bitplane board which could be configured as two 12-bitplane buffers. This would require a 4096 color lookup table but would allow doublebuffered rendering with a 4096 color palette from 16 million. I've done this for years on the older IRISs we have here at work and it is very good for interactive animation. Jonathan -- ------------------------------------------------------------------- | Jonathan Sivier | Ballo ergo sum. | | jsivier@ux1.cso.uiuc.edu | (I dance therefore I am.) | | Flight Simulation Lab | - des Cartwright |
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (12/02/90)
In an article from: bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) > >Kent is correct. The Ham-E and DCTV are =NOT= 24 bit frame buffers or boards. > >They get thier color information from lookup tables or some such thing. >Animation with Ham-E can only be done by page flipping full pages, unless you >count writing your own software to create animations and such. > >Don't be fooled by crafty advertising. > >If you want true 24-bit, you'd best get a Toaster or Firecracker. > Or the ColorBurst by MAST (fingers crossed for end of the week) :-) Rick Tillery
her@compel.UUCP (Helge Egelund Rasmussen) (12/02/90)
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: > >Animation with Ham-E can only be done by page flipping full pages, unless you > >count writing your own software to create animations and such. This is WRONG, I've used Imagine to create a 40 frame animation of a walking man. The output was in ILBM 24 bit, and was converted to 40 HAM-E pictures using the conversion program supplied by Black-Belt. These was then concatenated to a normal anim file by a standard anim creation utility. Each delta created had a size of about 6 K, so to final animation file had a size of about 240 K. The resulting anim could then be displayed by a normal anim file viewer. I've seen a HAM-E animations being manipulated by AnimationStation, which is an utility written to manipulate standard anim files. The only thing you cannot do is manipulate the colors. None of the existing anim packages understand 24 bit color, so that is not strange. >Don't be fooled by crafty advertising. And please don't make statements about something that you haven't tried to do yourself :-) Helge --- Helge E. Rasmussen . PHONE + 45 31 37 11 00 . E-mail: her@compel.dk Compel A/S . FAX + 45 31 37 06 44 . Copenhagen, Denmark
seanc@pro-party.cts.com (Sean Cunningham) (12/03/90)
In-Reply-To: message from mark@calvin..westford.ccur.com "This is all well and fine for video applications where luma and chroma bandwidth are strictly limited anyway." (refering to DCTV) I believe that is is the purpose for which DCTV was designed. It has no RGB outputs, strictly video just like the Mimetics FrameBuffer. NTSC can never look as sharp as RGB. 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 1990 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/04/90)
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: > Kent is correct. The HAM-E and DCTV are =NOT= 24 bit frame buffers > or boards. They get their color information from lookup tables or > some such thing. Animation with the HAM-E can only be done by flipping > full pages, unless you count writing your own software to create > animations and such. Don't be fooled by crafty advertising. If you > want true 24-bit, you'd best get a toaster or Firecracker. --Bob Well now. Normally, I try to be reasonable when people make honest mistakes. When, on the other hand, someone acts like they know it all, when they clearly know nothing (or perhaps slightly less, as in this case), I tend to get a little sweaty. Not in any particular order, but: The Firecracker, as stated, is a true 24 bit board. At least you got _one_ thing right. The toaster, in sharp contrast to the publicity, is not a 24 bit board, as NTSC composite won't modulate to 24 bits precision in any case. As soon as you go composite (which the toaster always is) you don't have 24 bits. Likewise for DCTV - technically. The HAM-E offers two modes; one is 256 colors with a 24 bit palette; this is 256 grey level accurate RGB but is not "true 24 bit" in the sense that any pixel can be any 24 bit value independant of another pixel. The other mode is an 18 bit mode, with 24 bit pixels mixed in here and there. We use dither to achieve full 24 bit representation of images in a color space that is always at least 18 bits (1/4 million colors) and sometimes more, depending on where the registers are used. The HAM-E is fully capable of full screen animation as noted above, however, it is ALSO capable of standard ANIM type animation, blitter "BOB" type animation, color cycle animation, and glow range animation. This is because these are, underneath, simply hi res Amiga screens. You don't need to write your own software, in fact you can use the brush anims in DPaint, of all things, to make path animations. Blitter animation is clearly demonstrated by the use of fully stenciled brushes in our paint software (You can look at this by DL'ing the paint from our BBS at (406) 367-ABBS) I'd like to close by pointing out an interesting contrast. Bob signs himself as (apparently) representing the "Pro-Graphics" BBS. Personally, I'd be a little cautious of dealing with a BBS where those who run or handle it prove, in silly messages on the nets, that they don't know what 24 bit graphics means, expound upon devices they _obviously_ have not taken the time to find out about (or, if they did, didn't understand what they were told), and give advice that tells the reader to, without question, get a $1500.00 device over a $300.00 device when he's not clear on the facts he bases his recomendation upon. In short, Bob, shut up, eh? Or else learn the subject. Oh yeah - please note that the HAM-E has not been advertised in print as of yet - the ads are being placed now, since we've been shipping for about 60 days - company policy not to go to print ads until things are ready, FCC approved, etc. Just so you're clear that your remark about "crafty advertising" could not have possibly applied to us... though if you're as accurate about your evaluation of ads as you are about 24 bit gfx, perhaps you're not sure who you ARE talking about. Ben Williams, for Black Belt Systems <76004.1771@compuserve.com> December 2nd, 1990, in response to a quote forwarded from comp.sys.amiga [ Please email replies to Ben, not me! - kev]
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (12/04/90)
In an article by: bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: >> Kent is correct. The HAM-E and DCTV are =NOT= 24 bit frame buffers >> or boards. They get their color information from lookup tables or >> some such thing. Animation with the HAM-E can only be done by flipping >> full pages, unless you count writing your own software to create >> animations and such. Don't be fooled by crafty advertising. If you >> want true 24-bit, you'd best get a toaster or Firecracker. --Bob > >Well now. Normally, I try to be reasonable when people make honest >mistakes. When, on the other hand, someone acts like they know >it all, when they clearly know nothing (or perhaps slightly less, >as in this case), I tend to get a little sweaty. > >Not in any particular order, but: The Firecracker, as stated, >is a true 24 bit board. At least you got _one_ thing right. The >toaster, in sharp contrast to the publicity, is not a 24 bit >board, as NTSC composite won't modulate to 24 bits precision >in any case. As soon as you go composite (which the toaster always >is) you don't have 24 bits. Likewise for DCTV - technically. I think the point is that internally the image is represented by 24 bits. Whether or not composite can do this image justice is not debatable (it can't). The thing is that the image presented for video recording (which is what the composite is for and what even an RGB signal must become to be recorded) is the best it can be when it comes from a 24 bit source. Anyone who goes composite (from RGB or directly) knows this. I have to agree with Kent that that means that DCTV is indeed 24 bits (albeit an unorthodox output method may further degrade the quality-I haven't seen it yet so I can't vouch for that) because it creates such a signal. The composite conversion is where the information is lost and this is in no way reflecitve of DCTV or it's image resolution. It is indicative of a poor video method. [More about HAM-E deleted] >Ben Williams, for Black Belt Systems <76004.1771@compuserve.com> >December 2nd, 1990, in response to a quote forwarded from comp.sys.amiga >[ Please email replies to Ben, not me! - kev] > In all this discussion of 24 bit boards and the HAM-E, I'd just like to comment by saying that in spite of the fact that the HAM-E board has an RGB output, it CANNOT COMPARE to the quality of the Toaster's video. Further, the Toaster's output is _slightlty_ worse than the Firecracker. I had the opportunity to view all three side-by-side on several of my own 24 bit RGB ray-traces and if HAM is a 5, HAM-E is a 6, the Toaster is an 8 and the Firecracker is a 9 (still want 24 bit non-interlace display). The lack of colors and lower resolution meant the picture was not even in the same ballpark as the Toaster and the Firecracker (and judging by the RGB 24 bit specs, the ColorBurst). The dithering was not bad but it didn't help to overcome the VERY evident fringing. I'll spend the extra hundred for ColorBurst when it comes out. Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) (12/04/90)
In-Reply-To: message from her@compel.UUCP bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: > >Animation with Ham-E can only be done by page flipping full pages, unless you > >count writing your own software to create animations and such. This is WRONG, I've used Imagine to create a 40 frame animation of a walking man. The output was in ILBM 24 bit, and was converted to 40 HAM-E pictures using the conversion program supplied by Black-Belt. These was then concatenated to a normal anim file by a standard anim creation utility. Each delta created had a size of about 6 K, so to final animation file had a size of about 240 K. The resulting anim could then be displayed by a normal anim file viewer. I've seen a HAM-E animations being manipulated by AnimationStation, which is an utility written to manipulate standard anim files. The only thing you cannot do is manipulate the colors. None of the existing anim packages understand 24 bit color, so that is not strange. >Don't be fooled by crafty advertising. And please don't make statements about something that you haven't tried to do yourself :-) Helge ----------------- Maybe I should have been more specific. Yes, you can animate 3D animations and such rendered from various 3D programs and then converted to the HAM-E format. This involves rendering each frame as a file and then converting them to HAM-E specifications (with TAD or included converter program). What I was referring to was 2D animation using moving brushes and such as are possible with Dpaint III. It will not work. You must page flip entire pages to get 2D animations to work. -- Bob ______ Pro-Graphics BBS "It's better than a sharp stick in the eye!" ________ UUCP: crash!pro-graphics!bobl | Pro-Graphics: 908/469-0049 ARPA/DDN: pro-graphics!bobl@nosc.mil | America Online: Graphics3d Internet: bobl@pro-graphics.cts.com | CompuServe: RIP _________ ___________ Raven Enterprises 25 Raven Avenue Piscataway, NJ 08854
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/04/90)
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes: >In an article by: bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: [attribution for this part missing:] >>> Kent is correct. The HAM-E and DCTV are =NOT= 24 bit frame buffers >>> or boards. They get their color information from lookup tables or >>> some such thing. Animation with the HAM-E can only be done by flipping >>> full pages, unless you count writing your own software to create >>> animations and such. Don't be fooled by crafty advertising. If you >>> want true 24-bit, you'd best get a toaster or Firecracker. --Bob >>Not in any particular order, but: The Firecracker, as stated, >>is a true 24 bit board. At least you got _one_ thing right. The >>toaster, in sharp contrast to the publicity, is not a 24 bit >>board, as NTSC composite won't modulate to 24 bits precision >>in any case. As soon as you go composite (which the toaster always >>is) you don't have 24 bits. Likewise for DCTV - technically. >I think the point is that internally the image is represented by 24 bits. >I have to agree with Kent that that means that DCTV is indeed 24 bits (albeit >an unorthodox output method may further degrade the quality-I haven't seen it >yet so I can't vouch for that) because it creates such a signal. The composite >conversion is where the information is lost and this is in no way reflecitve >of DCTV or it's image resolution. It is indicative of a poor video method. Except that I made exactly the opposite point: just because you can output 8 each red, green, and blue bits to the D to A gun intensity controls doesn't mean you have the right to call your system "24 bit color", since that is a term of art that means that you _store_, not _emit_, three bytes of color data per pixel. Let's take this to ridiculous extremes to make a point. Imagine a board that supplies 3 bits of information per pixel - that means it can display any one of eight colors (or give away resolution to get more color, a separate issue); now take that three bits and decode it into an index in a color look up table. That table will have just eight entries, one for each possible bit pattern among the pixels. Now that doesn't put any limit on how big one of those eight entries can be, so, since there are so few of them, they won't impact the hardware price much, we can be real generous and supply 48 bits, 16 per gun. So we can get, what, 256 quadrillion odd colors out of this system, so obviously we can advertise it as a "48 bit color system", right? Except that we haven't told the customer this is still just an eight color system, and you aren't going to be able to display a picture without horrible stairstepping, no matter which eight of those 256 quadrillion colors are assigned to the eight color lookup table entries. A "24 bit color" system is a system that provides 24 separate bits for each separate screen pixel. Anything less is maliciously false advertising, because the stairstepping three byte deep pixels are designed to avoid will still be there, and the customer will (correctly) feel cheated. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
es1@cunixb.cc.columbia.edu (Ethan Solomita) (12/04/90)
In article <1990Dec4.115219.15680@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >Except that I made exactly the opposite point: just because you can output >8 each red, green, and blue bits to the D to A gun intensity controls doesn't >mean you have the right to call your system "24 bit color", since that is a >term of art that means that you _store_, not _emit_, three bytes of color data >per pixel. Kent, take out a calculator and do a little math. The resolution of DCTV is somewhere around 600x300, or 180,000 pixels. Therefore, if you get 18 bits worth of distinct colors out of a 24 bit palette, you essentially have a 24 bit frame-buffer within the given resolution limit. ie there are only enough pixels to display 18 bits worth of color. I believe that someone said that DCTV was the equivalent of 22 bit planes, which exceeds that. Of course, that doesn't justify them calling it true 24 bit, but if we are discussing usability and quality of the product (as opposed to the advertising), it is an excellent product. As to the quality of the ouutput signal, however, I have no idea. -- Ethan Woody Allen on Los Angeles: "I mean, who would want to live in a place where the only cultural advantage is that you can turn right on a red light?"
torrie@Neon.Stanford.EDU (Evan James Torrie) (12/05/90)
es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: >In article <1990Dec4.115219.15680@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>Except that I made exactly the opposite point: just because you can output >>8 each red, green, and blue bits to the D to A gun intensity controls doesn't >>mean you have the right to call your system "24 bit color", since that is a >>term of art that means that you _store_, not _emit_, three bytes of color data >>per pixel. > Kent, take out a calculator and do a little math. The >resolution of DCTV is somewhere around 600x300, or 180,000 >pixels. Therefore, if you get 18 bits worth of distinct colors >out of a 24 bit palette, you essentially have a 24 bit >frame-buffer within the given resolution limit. ie there are only >enough pixels to display 18 bits worth of color. I believe that This is only true if the 18 bits of color are used to index into a lookup table (which in turn has 24 bits of information). For example, if I have a graduated shade of pure red to black, then an 18-bit system (with 6 bits for each component) WITHOUT a lookup table (i.e. direct mapping of 18 bits to the screen) will only give me 2^6 = 64 different colors. A true 24-bit system will give me 256 different colors. A 48-bit system would give 65536 different colors. For a standard sized screen (say 640 across), ONLY the 48-bit system would give more colors than could be used by the screen (the 18-bit would have bands of 10 pixels across, the 24-bit system would have bands of 2 and a bit pixels). If you have a color lookup table though, you can set the entries in your table to be equal to whatever colors you want on the screen... If you have an 18-bit lookup table containing 24-bit entries, and your screen has <2^18 pixels, only then does your system have exactly the same picture quality as a 24-bit system. So do any of these "24-bit" systems have lookup tables? Or are they just direct color devices? [One would suspect the latter, since an 18-bit lookup table containing 24-bit entries => you need 3*2^18 > 700K just for storing the lookup table!]. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "I didn't get where I am today without knowing a good deal when I see one, Reggie." "Yes, C.J."
es1@cunixb.cc.columbia.edu (Ethan Solomita) (12/05/90)
In article <1990Dec4.214546.7091@Neon.Stanford.EDU> torrie@Neon.Stanford.EDU (Evan James Torrie) writes: >es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > >> Kent, take out a calculator and do a little math. The >>resolution of DCTV is somewhere around 600x300, or 180,000 >>pixels. Therefore, if you get 18 bits worth of distinct colors >>out of a 24 bit palette, you essentially have a 24 bit >>frame-buffer within the given resolution limit. ie there are only >>enough pixels to display 18 bits worth of color. I believe that > > This is only true if the 18 bits of color are used to index >into a lookup table (which in turn has 24 bits of >information). The one thing that seems apparent from what Digital Creations has been saying is that you get an NTSC TV quality pictue, in terms of color, and slightly less in terms of resolution (300 instead of 330 lines or some such). These images can also be animated in pretty-much real time because all it is is just a high-res-interlace screen. Pageflipping works just fine. -- Ethan Woody Allen on Los Angeles: "I mean, who would want to live in a place where the only cultural advantage is that you can turn right on a red light?"
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) (12/05/90)
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: > > Kent is correct. The HAM-E and DCTV are =NOT= 24 bit frame buffers > > or boards. They get their color information from lookup tables or > > some such thing. Animation with the HAM-E can only be done by flipping > > full pages, unless you count writing your own software to create > > animations and such. Don't be fooled by crafty advertising. If you > > want true 24-bit, you'd best get a toaster or Firecracker. --Bob > > Well now. Normally, I try to be reasonable when people make honest > mistakes. When, on the other hand, someone acts like they know > it all, when they clearly know nothing (or perhaps slightly less, > as in this case), I tend to get a little sweaty. > > Not in any particular order, but: The Firecracker, as stated, > is a true 24 bit board. At least you got _one_ thing right. The > toaster, in sharp contrast to the publicity, is not a 24 bit > board, as NTSC composite won't modulate to 24 bits precision > in any case. As soon as you go composite (which the toaster always > is) you don't have 24 bits. Likewise for DCTV - technically. Correction. The Toaster IS a 24 bit board. It saves 24 bit IFF images and will also save 24 bit RGB files. It doesn't, however, OUTPUT 24 bit video because of the above stated reason. It does all it's work in 24 bits. > The HAM-E offers two modes; one is 256 colors with a 24 bit palette; > this is 256 grey level accurate RGB but is not "true 24 bit" > in the sense that any pixel can be any 24 bit value independant > of another pixel. The other mode is an 18 bit mode, with 24 bit > pixels mixed in here and there. We use dither to achieve full > 24 bit representation of images in a color space that is always > at least 18 bits (1/4 million colors) and sometimes more, depending > on where the registers are used. So HAM-E offers 256 on-screen colors out of a palette of 16 million in one mode and a <24 bit dithered mode with color registers in the other. > The HAM-E is fully capable of full screen animation as noted > above, however, it is ALSO capable of standard ANIM type animation, > blitter "BOB" type animation, color cycle animation, and glow > range animation. This is because these are, underneath, simply > hi res Amiga screens. > > You don't need to write your own software, in fact you can use > the brush anims in DPaint, of all things, to make path animations. > Blitter animation is clearly demonstrated by the use of fully > stenciled brushes in our paint software (You can look at this > by DL'ing the paint from our BBS at (406) 367-ABBS) I'm very sorry to say that brush anims in Dpaint do NOT work. We've tried to animate Dpaint brushes as we normally do (and we do this ALOT) and the HAM-E would not maintain it's color values as the image moved. Unless you have some special method of animating dpaint brushes that we are unaware of. We do alot of animations for several clients in the tri-state area and we KNOW how to animate in Dpaint III. Typical Dpaint III techniques do NOT work with the HAM-E unless you do not use the Move requestor. The only way I can see it working is to move outlined b/w brushes around to get the movement down and then fill in the colors for each frame. Quite pains-taking I assure you. > I'd like to close by pointing out an interesting contrast. Bob > signs himself as (apparently) representing the "Pro-Graphics" No apparently about it, I run the system. > BBS. Personally, I'd be a little cautious of dealing with a BBS > where those who run or handle it prove, in silly messages on > the nets, that they don't know what 24 bit graphics means, expound > upon devices they _obviously_ have not taken the time to find > out about (or, if they did, didn't understand what they were > told), and give advice that tells the reader to, without question, > get a $1500.00 device over a $300.00 device when he's not clear > on the facts he bases his recomendation upon. You have a wonderful way of putting words in people's mouths, don't you. Whether or not I know what 24 bits are all about is irrelevant, I know what I see and your device sir, does not stand up to true 24 bit framebuffer output be it composite or 24 bit output, period. Besides, I didn't unequivocally tell readers to purchase a $1500.00 device over yours. I suggested they do so if they were looking for 24 bit output quality. > In short, Bob, shut up, eh? Or else learn the subject. Thanks for the advice. > Oh yeah - please note that the HAM-E has not been advertised > in print as of yet - the ads are being placed now, since we've > been shipping for about 60 days - company policy not to go to > print ads until things are ready, FCC approved, etc. Just so > you're clear that your remark about "crafty advertising" could > not have possibly applied to us... though if you're as accurate > about your evaluation of ads as you are about 24 bit gfx, perhaps > you're not sure who you ARE talking about. Crafty advertising applied to DCTV and not your company. > Ben Williams, for Black Belt Systems <76004.1771@compuserve.com> > December 2nd, 1990, in response to a quote forwarded from comp.sys.amiga The above public attacks on myself, my BBS and my company were uncalled for. I do not know everything there is to know about 24-bit boards or color registers, lookup tables and the like. I was stating some personal observations from my first experiences with your product. I am an end-user and not a programmer or hardware expert. I can tell you, however, that my first impressions of the product for 2D animation were unfavorable. I can see application for 3D work if you don't mind the low output quality compared to the "real" 24 bit devices available. I will go on to state that the documentation supplied with the HAM-E device is quite possibly the worst documentation I have ever seen. The manual was poorly layed out, unorganized and incomplete. Additional information had to be either printed or viewed from text files on disk that were poorly formatted for output to a printer. The upgrade policy for the HAM-E states that no upgrade or update disks will be mailed and that all updates MUST be obtained by dialing the Black-Belt Systems BBS. They suggest in the documentation that if you don't have a modem that you'd best purchase one. Add that to the cost of your HAM-E device! Also add to that the cost of long-distance phone calls to this BBS for your bug-fixes and updates. In addition to this, my associate who runs a complete broadcast production company has informed me that the HAM-E will not output through the genlock to our record decks. We have a full A/B roll edit suite with TBC's, frame synchronizers, GVG Model 100 switcher and broadcast VTR's with which we output all our animations to complete video productions. Every item we've ever used has output through our genlocking device for our Amiga to tape except this one. -- Bob ______ Pro-Graphics BBS "It's better than a sharp stick in the eye!" ________ UUCP: crash!pro-graphics!bobl | Pro-Graphics: 908/469-0049 ARPA/DDN: pro-graphics!bobl@nosc.mil | America Online: Graphics3d Internet: bobl@pro-graphics.cts.com | CompuServe: RIP _________ ___________ Raven Enterprises 25 Raven Avenue Piscataway, NJ 08854
her@compel.UUCP (Helge Egelund Rasmussen) (12/05/90)
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) writes: >What I was referring to was 2D animation using moving brushes and such as are >possible with Dpaint III. It will not work. You must page flip entire pages >to get 2D animations to work. Well, I haven't tried this, but I see two scenarios (using HAM-E): 1: You are using the 262144 color HAM mode: In this case you're out of luck with DPaint because the color of a pixel depends of its neighbours. So moving a brush in this mode will at least give strange "fringes" at the edge of the brush. So here you're right. 2: You are using the 256 colors from 2^24 color-pallette mode: This should work fine if the color table for the brush and the color table for the picture is the same. (The same rule applies to normal IFF pictures in DPaint). I'm not sure that 'hame' (the 24 bit to HAM-E converter from Black-Belt) supports 'locking' of the color table between pictures, but as the source code is available, it should be possible to make this change. Helge --- Helge E. Rasmussen . PHONE + 45 31 37 11 00 . E-mail: her@compel.dk Compel A/S . FAX + 45 31 37 06 44 . Copenhagen, Denmark
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/05/90)
es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> Except that I made exactly the opposite point: just because you can >> output 8 each red, green, and blue bits to the D to A gun intensity >> controls doesn't mean you have the right to call your system "24 bit >> color", since that is a term of art that means that you _store_, not >> _emit_, three bytes of color data per pixel. > Kent, take out a calculator and do a little math. The resolution of > DCTV is somewhere around 600x300, or 180,000 pixels. Give me a little credit, OK? I helped write two of the international computer graphics standards, GKS and CGM. > Therefore, if you get 18 bits worth of distinct colors out of a 24 bit > palette, you essentially have a 24 bit frame-buffer within the given > resolution limit. It's been a little while, but the last time I looked, the length limit of a color look up table was between 2^11 and 2^12 bits, not 2^18. A color lookup table is an associative memory, and 2^12 bits is about as deep a fanout as you can search before you've run out of time to paint that pixel. Moreover, if you're going to have "18 bits of color" in that table, i.e., 2^18 simultaneously displayable colors, you're going to have 2^18, 24 bit entries. Might as well just use 2^18 24 bit pixels instead, it's a lot cheaper and faster. > Ie there are only enough pixels to display 18 bits worth of color. I > believe that someone said that DCTV was the equivalent of 22 bit > planes, which exceeds that. There are only 2^18 pixels, but you still need 2^24 possible colors for them to avoid Mach bands being perceived by the more sensitive half of the population. Since you can't afford a lookup table to get those bits, you need to store one set with each pixel. You're confusing simultaneous colors with possible colors; the visual artifacts are related to possible colors, not to simultaneous colors. Said another way, to how close two colors can be (in tone) to one another, not to how many are seen on the screen. > Of course, that doesn't justify them calling it true 24 bit, but if we > are discussing usability and quality of the product (as opposed to the > advertising), it is an excellent product. As to the quality of the > ouutput signal, however, I have no idea. Nor I, nor anyone else who's not seen it. My original, and continuing, objection is to co-opting a computer graphics term with a specific technical meaning and using it in an advertisement where it is technically false to fact, and therefore misleading to the customers, and to do it with malice aforethought, since anyone doing a board design in the industry has long ago learned what the term means. It's roughly the equivalent of quoting disk drive speeds in megaBITS and abbreviating it MB for the ad, when the potential customers reading the add have long ago learned to measure data volume, and use that abbreviation, to mean megaBYTES: deliberately false and misleading advertising. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
huebner@aero.aero.org (Robert E. Huebner) (12/06/90)
Okay, since it seems we have a lot of graphics-terms experts on the net, perhaps you can clear up some abiguities regarding a recent press release for the Progressive 32-bit board. All text is quotes is directly taken from the literature. All brakets are my own comments: "Video Master 32 offers dual frame buffers, each with resolutions of up to 1024x1024 in 24 bits with 8 bit overlay [apparently this, not alhpa channel, is where the 32-bit figure comes from?]. The frame buffer can display out in resolutions up to 800x600 and 1024x512 in over 16 million colors" So what good is a 1024x1024 frame buffer is its maximum output resolution is 1024x512? I find this very misleading. "Video Canvas 24, a real-time 16 million color paint program is included. The Video Canvas updates the display instantaneously as the user paints. Video artists may use the Video Canvas 24 to create graphics in a scrollable area 1024X2048 pixels." So if this is a frame buffer, how can it provide real-time feedback when painting and scrolling. Unless the scrolling is handled by the internal processors (TI 34082 and 34020). "The Video Master 32 offers optional real-time 24-bit video digitizing in all Amiga video resolutions up to 752x525 [I suppose this is PAL interlaced overscan], including overscan." A frame buffer that digitizes video. Seems rather toaster-ish. "The Video Master 32's design includes a programming and data RAM storage area of 1 Megabyte, expandable to 8 megabytes. This area may be used to run blindingly fast custom 34020 applications, such as 3-D rendering, animation, ray-tracing, image processing, and ADO effects generation software." What isn't explained is- how much RAM is needed for features and resolutions mentioned elsewhere. Later it states that the 1 Megabyte model can only handle 1 frame buffer instead of two. Also, what are these "custom 34020 applications". Do they exist? Will PP&S develop them, or are they included (doubt it). "The Video Master's 8-bit overlay allows for operating system windows and menu displays in up to 256 colors, overlaying the 24-bit video image. This design eliminates palette selection problems and allows for easy editing and painting in 24 bits" This is interesting. So this means the mouse pointer and workbench screen can appear over the 24-bit graphics? Will this allow for directing painting on the frambuffer screen? "All configurations available in NTSC of PAL" Overall, I begin to think that the claim of 1024x1024x32 bits is a bit misleading, since the rest of the article stresses its ability to output to video using a 1024x512 (Which is nice, but is only half what they claim earlier on) screen. Overall, this sounded like an exciting product, second only to the Video Toaster in terms of "drool-factor". No price mentioned, and availability listed as first quarter 91. My basic question is- is this a true 24-bit framebuffer like the Firecracker board? How does this differ from the toaster? I don't believe the toaster uses any on-board RAM, but I could be wrong. If anyone can clarify these points, I'd appreciate it ----- Robert Huebner huebner@aerospace.aero.org The Aerospace Corporation Computer Security El Segundo, CA -----
seanc@pro-party.cts.com (Sean Cunningham) (12/07/90)
In-Reply-To: message from es1@cunixb.cc.columbia.edu The 300-330 lines of resolution for video does NOT equal pixel resolution. It's very hard to pin-point a "video" resolution in pixel resolution. Consider that 480 pixels of horizontal resolution is about equal to NTSC's 525 scanlines. Broadcast television is about 330 lines of vertical "video" resolution...some prosumer camcorders and video decks have much higher (SVHS= 425, EDBeta= 520). As someone wrote in a message to me, the PIXEL resolution of DCTV is 736x482. 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 1990 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/07/90)
huebner@aero.aero.org (Robert E. Huebner) writes: > Okay, since it seems we have a lot of graphics-terms experts on the net, Or at least one terminology freak. ;-) > perhaps you can clear up some abiguities regarding a recent press > release for the Progressive 32-bit board. All text is quotes is > directly taken from the literature. All brackets are my own comments: Okay, I'll try to translate, but take into account I never even _heard_ of this system. > "Video Master 32 offers dual frame buffers, each with resolutions of > up to 1024x1024 in 24 bits with 8 bit overlay [apparently this, not > alpha channel, is where the 32-bit figure comes from?]. The frame > buffer can display out in resolutions up to 800x600 and 1024x512 in > over 16 million colors" Right. "Alpha channel" is a software use for some hardware bits, used especially for encoding "opacity" or "coverage" information on a per pixel basis, for accomplishing transparent/translucent objects, or for antialiasing. Another possible software use for the same eight bits would be "z buffer" depth information, to "make hidden surface calculations much cheaper". (That's not exactly what it does, but that's the effect; what it really does is allow a modified painter's algorithm for all surfaces that don't hit the same depth bin, and only require hidden surface calculations when they do.) It sounds like this design's aren't 32 equal weight bits, but instead are two sets, the 8 bits having priority over the 24 bits. What I would expect from this limited information is that when the overlay bits have the "background" value (probably 0), then the color stored in the other 24 bits would show through. This takes hardware intervention, so unless the hardware is switchable to other modes, the alpha channel or z buffer uses for these eight bits wouldn't be available (without a lot of extra work; I can think of half a dozen ways to do it, but they all make my teeth itch.) >So what good is a 1024x1024 frame buffer is its maximum output resolution >is 1024x512? I find this very misleading. Well, unless you have a square screen, or stubby pixels, you won't normally display stuff at 1K x 1K on a home system (commercial systems can do this; they cost a lot). However, the 1K by 1K data storage capability is still very valuable; you can make a roamable structure bigger than the display; there are lots of uses for pictures you have to scroll to get to, but don't have to recompute to get to. If you are using one of the desktop publishing systems, you can store a bigger piece of a page, and look it over in the previewer without having to recompute until you go off the larger frame buffer surface. You can also make a game or other application in which the extra space is used to store 24 bit images to be quickly swapped into the visible area without recomputation. As a graphics programmer, I'd have no trouble putting this extra space to lots of good uses that would make it worth your money as a customer. > "Video Canvas 24, a real-time 16 million color paint program is > included. The Video Canvas updates the display instantaneously as the > user paints. Video artists may use the Video Canvas 24 to create > graphics in a scrollable area 1024X2048 pixels." [I'm sort of hoping they meant 2048x1024 here, and I'll write as if that were so. What you typed would give a four screen high vertical only scroll; a two screen by two screen scroll would be much more expected.] OK, here they have taken the double buffer and used it instead as a double width screen as well as double height. [If I were designing this hardware, I'd have been sure to put in a software switchable mode that would display every other pixel horizontally and vertically, so that an artist could draw at full resolution, but pop back to see the whole picture to make sure stuff matches up and is shaped right. (I'd also do some really clever stuff to allow painting in overview mode, and cleanup in full resolution mode.) No knowing without more information, but it would be worth asking about, and it is cheap enough to implement.] Now you have the ability to paint a really large picture. On an 8 by ten sheet of printer paper, this gives you 128 pixels per inch by 205 pixels per inch in landscape mode, pretty good for a color inkjet printer. It would also be excellent for a color film recorder, etc. > So if this is a frame buffer, how can it provide real-time feedback > when painting and scrolling. Unless the scrolling is handled by the > internal processors (TI 34082 and 34020). Well, the Amiga does this stuff now; all you have to do is give the video drawing chips new starting upper left hand corner addresses within the frame buffer memory. Since all you have to change is one x,y pair, you can draw _any_ 1024 x 512 rectangular subset of the total 2048x1024 frame buffer every screen refresh time. > "The Video Master 32 offers optional real-time 24-bit video digitizing > in all Amiga video resolutions up to 752x525 [I suppose this is PAL > interlaced overscan], including overscan." > A frame buffer that digitizes video. Seems rather toaster-ish. Sure, and the limited resolution is probably camera derived. > "The Video Master 32's design includes a programming and data RAM > storage area of 1 Megabyte, expandable to 8 megabytes. This area may > be used to run blindingly fast custom 34020 applications, such as 3-D > rendering, animation, ray-tracing, image processing, and ADO effects > generation software." Nice; you can dump a program tailored for the 34020 into its address space, and let the 34020 execute it while your 680x0 is doing other good stuff for you. This is like a blitter on power pills. > What isn't explained is- how much RAM is needed for features and > resolutions mentioned elsewhere. Later it states that the 1 Megabyte > model can only handle 1 frame buffer instead of two. Also, what are > these "custom 34020 applications". Do they exist? Will PP&S develop > them, or are they included (doubt it). Well, two frame buffers 1024x1024x32 is eight megabytes, which wouldn't leave any room for software if that were the same memory being used for the video storage, and one megabyte is nowhere close to a frame buffer. This is a bit confusing, especially with the quote about "one frame buffer instead of two"; is there 8 megabytes for the buffers, plus 1 to 8 megabytes user ram, or do you fight for space in a single eight megabyte space? This needs clarification. You _never_ expect spiffy software with new hardware, though there's always something sold to make it at least minimally usable, like that paint program. If the product builds a good base with its startup software, and is as nice as it sounds, software will follow. That's the way the biz works. > "The Video Master's 8-bit overlay allows for operating system windows > and menu displays in up to 256 colors, overlaying the 24-bit video > image. This design eliminates palette selection problems and allows > for easy editing and painting in 24 bits" This is nice, and was one of the first ways 32bit frame buffers were implemented, but it would be nicer if this could be switched off and on by the software, to allow alternate use for z buffer, alpha channel, or other needs, without interfering with the 24 bit display. This may well be part of the design, but I don't see it here. >This is interesting. So this means the mouse pointer and workbench screen >can appear over the 24-bit graphics? Will this allow for directing painting >on the frambuffer screen? Given the software, you could build an eight bit picture that completely covered the 24 bit picture, clear it to zero, and have the original picture intact. That's what makes this an attractive technique: you can overlay any type of trash on top of the "background" picture, and still not have to recompute/redraw the background picture as the stuff in front is modified, moved, or removed. > "All configurations available in NTSC or PAL" > Overall, I begin to think that the claim of 1024x1024x32 bits is a bit > misleading, since the rest of the article stresses its ability to > output to video using a 1024x512 (Which is nice, but is only half what > they claim earlier on) screen. No, this time it's OK; having a writable area bigger than your displayable area is a well known trick; the Amiga superbitmap mode already supports a 1024x1024 writable picture area with a ( first implementation ) 640x400 window into it shown on the display. Not meant to mislead; they really put all those pixel bits in there for all those pixels, your disply just doesn't let you look at all of them at once. > Overall, this sounded like an exciting product, second only to the > Video Toaster in terms of "drool-factor". No price mentioned, and > availability listed as first quarter 91. Wish I were rich! ;-) > My basic question is- is this a true 24-bit framebuffer like the > Firecracker board? How does this differ from the toaster? I don't > believe the toaster uses any on-board RAM, but I could be wrong. No experience with any of them (poverty), but it sure sounds like a true 24 bit buffer from what you quoted. >If anyone can clarify these points, I'd appreciate it I did my best; I hope that helped. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
seanc@pro-party.cts.com (Sean Cunningham) (12/08/90)
In-Reply-To: message from huebner@aero.aero.org On the VideoMaster 32, the 8bits of overlay IS alpha channel. You'd use it for menus, mouse pointer, and overlays. This is what most videoboards for the Mac feature. A framebuffer doesn't necessarily have to be passive...they aren't on Suns, Apollos, etc. With the TMS34020, very fast interaction is possible. The resolution is another question. The 1024x512 could have been a typo, but I'd doubt it. Since it IS dual framebuffer, the two put together would equal 1024 x 1024...definately creative advertising. 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 1990 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/09/90)
[ Forwarded from Ben Williams @BlackBelt <76004.1771@compuserve.com> ]: [ He notes that the tried to reply to Bob at ProGraphics BBS, but that he was told the mail never showed up. - kev] Bob - I was steamed when I read your message. Sorry I got so personal. I'll attempt to stay to the technical points here. The HAM-E will animate in DPaint, in register mode. Turn on the grid, set it to "2" horizontally, and that ensures that the brush will maintain the registration required to operate properly under DPaints manipulations. So, it does work. Next, neither the toaster nor DCTV are 24 bit _output_. What you see is the issue here, not what is going on where you can't see. The HAM-E also represents it's data in 24 bits internally; output images in the HAM-E mode are mixtures of 18 and 24 bit data. I don't think that makes the HAM-E 24 bit; although it does give it the ability to have a better image than any composite signal. I've had the opportunity to sit next to a Toaster for 3 days, running lightwave, just generally mucking about with it. Output images occasionally approached the HAM-E's quality, but ONLY when they were lightly colored - the monochrome rez of the Toaster is reasonably high. DCTV does not modulate the signal with 24 bits of data. So, even taking into account the damage done by NTSC encoding, it never _was_ 24 bits. I don't know if this applies to the Toaster. If saving images in 24 bit was the point upon which they all turned, as your message seems to imply, then the HAM-E would be a 24 bit system, because we do all our manipulations in 24 bits. I am NOT saying this is so; I'm just putting it this way to show you that your conclusion isn't clearly indicated. - Ben Email replies should go to Ben Williams at <76004.1771@compuserve.com>
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/09/90)
[ Forwarded from Ben Williams @BlackBelt <76004.1771@compuserve.com> ]: A general remark for those talking about the percieved quality of HAM-E images here... No device can do any better than what you feed into it. The images on the release disk are normal DigiView or GIF files, for the most part. They went thru our software just like anything you can do. If people are not getting good images on their own, then this is a matter of technique - the images on the release disk, and for that matter the ones on our BBS, make perfectly clear that you can get truly beautiful images on the HAM-E. We stand behind the product - and if anyone has any doubts, we suggest that they go to a dealer who is handling the HAM-E or to one of the AmiExpos, which we attend, and LOOK at the image quality. We've never had someone come up to the booth and say that it produces a low quality picture. I don't recall who numbered the units, but although I totally disagree with the system they used, I've seen all of them so far, and would number them thus: FireCracker 9 ColorBurst 9 HAM-E 7/8, depending on the mode reg/hame Toaster 4-5, depending on how much color is in the image DCTV 4-5, same as toaster. These are given good images to feed all of the above. These are _opinions_. Ben Amateur Radio Callsign is A A 7 A S Email replies should go to Ben Williams at <76004.1771@compuserve.com>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/10/90)
kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >[ Forwarded from Ben Williams @BlackBelt <76004.1771@compuserve.com> ]: >If saving images in 24 bit was the point upon which they all turned, >as your message seems to imply, then the HAM-E would be a 24 >bit system, because we do all our manipulations in 24 bits. >I am NOT saying this is so; I'm just putting it this way to show >you that your conclusion isn't clearly indicated. - Ben This is such utter garbage! Ham-E, according to Mr. Williams own writeup in the December issue of Faughorn, is a 368 by 480 maximum resolution system with _8_, _not_ _24_ bits per pixel. Doing "manipulations" in 24 bits is not "saving images in 24 bit". It might do wonderful things with those eight bits, including using them as indices into a 24 bit color lookup table, but it doesn't come close to the quality available from a 24 bit, 736 by 480 pixel frame buffer, and this kind of junk is exactly the misrepresentation I've been complaining about: it makes an excellent example of vendors doing their damnedest to mislead customers. His utterly viscious attacks on the competitive DCTV product in the same article shows a little too much hunger and too little ethics to suit me, and is confirmed postings here by the European customer who ordered HamE from Black Belt Systems from an ad stating that the system included a power supply, and receiving instead (for full price) a piece of paper saying the US power supply wouldn't work in Europe, so he was on his own to buy one for himself. Now there's a shop not 30 miles from me, in San Francisco, that specializes in selling 50Hz, 220 volt power supplies, so it isn't like they aren't available in the US. Most places I've been we call this "customer ripoff mail fraud". Think _real_ hard before buying a HamE system. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/10/90)
| <xanthian@Zorch.SF-Bay.ORG> (Kent Paul Dolan) writes: | | > Ben Williams @BlackBelt <76004.1771@compuserve.com> writes: | >If saving images in 24 bit was the point upon which they all turned, | >as your message seems to imply, then the HAM-E would be a 24 | >bit system, because we do all our manipulations in 24 bits. | >I am NOT saying this is so; I'm just putting it this way to show | >you that your conclusion isn't clearly indicated. - Ben | | This is such utter garbage! Ham-E, according to Mr. Williams own | writeup in the December issue of Faughorn, is a 368 by 480 maximum | resolution system with _8_, _not_ _24_ bits per pixel. | Doing "manipulations" in 24 bits is not "saving images in 24 bit". Kent! Knock-knock. Anyone home? :-) Read his message again. He's in _agreement_ with you. He even said that manipulating data in 24 bits before display still means "I don't think that makes the HAM-E 24 bit". | [...] and this kind of junk is exactly the misrepresentation I've been | complaining about: it makes an excellent example of vendors doing their | damnedest to mislead customers. Again, he's agreeing. I think you're letting your good intentions blind you. You're correct. You're right. We all _agree_. :-) | His utterly viscious attacks on the competitive DCTV product in the same | article shows a little too much hunger and too little ethics to suit me, Huh? This is all that he calmly wrote (readers decide for themselves): > DCTV does not modulate the signal with 24 bits of data. So, even > taking into account the damage done by NTSC encoding, it never > was 24 bits. I don't know if this applies to the Toaster. And as for the European customer with the power supply, I believe that Black Belt is attempting to correct the situation. In the first enthusiasm of product shipments, this kind of thing often occurs. Companies have to be informed of complaints first tho, before they can take corrective action. Seems to their credit that they're trying. | Most places I've been we call this "customer ripoff mail fraud". And most places would call your messages a "vendetta" ;-). But I don't think they are. I think you're just on a roll about the definition of "24-bit color", and more power to you! best - kevin (for myself). PS: As one of the instrumental parties creating the several new OS-9/68K machines, I find it amusing that Amigans love so much to rip into their third party suppliers. Y'all make us glad we chose a different route. No need for NeXT people to destroy you... you're doing it to yourselves. | Kevin Darling | Internet: kdarling@catt.ncsu.edu | all | 919-872-7986 anytime | CIS: 76703,4227 Delphi:OS9ugpres | 680x(x)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/10/90)
kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >| <xanthian@Zorch.SF-Bay.ORG> (Kent Paul Dolan) writes: >Again, he's agreeing. I think you're letting your good intentions blind >you. You're correct. You're right. We all _agree_. :-) >| His utterly viscious attacks on the competitive DCTV product in the same >| article shows a little too much hunger and too little ethics to suit me, >Huh? This is all that he calmly wrote (readers decide for themselves): > >> DCTV does not modulate the signal with 24 bits of data. So, even >> taking into account the damage done by NTSC encoding, it never >> was 24 bits. I don't know if this applies to the Toaster. Sorry, you picked one paragraph out of a two page diatribe comparing HamE to DCTV: Perhaps this one will refresh your memory: Ahem. The HAM-E can display a quarter of a million colors, and do them as a MUCH sharper image than the DCTV can. Whereupon he goes on the slam the DCTV for needing a $100 option to output RGB, and slides right past the extra cost for the "encoder" required to make the HamE output composite color. With the $100 option, one assumes the DCTV would have an equally sharp image; without the "encoder" option, I'd guess the HamE can't go to videotape at all. >And as for the European customer with the power supply, I believe that >Black Belt is attempting to correct the situation. In the first >enthusiasm of product shipments, this kind of thing often occurs. >Companies have to be informed of complaints first tho, before they can >take corrective action. Seems to their credit that they're trying. I didn't see any such offer in your followup article on this very point. >| Most places I've been we call this "customer ripoff mail fraud". >And most places would call your messages a "vendetta" ;-). But I don't >think they are. I think you're just on a roll about the definition of >"24-bit color", and more power to you! best - kevin (for myself). A vendetta needs a specific target; I began this discussion as a general slam against sleazeballs advertising lesser trash as 24-bit systems, and your excerpts provided the perfect example. > PS: As one of the instrumental parties creating the several new > OS-9/68K machines, I find it amusing that Amigans love so much to rip > into their third party suppliers. Y'all make us glad we chose a > different route. No need for NeXT people to destroy you... you're > doing it to yourselves. To the contrary, part of the strength of the Amiga market (one of the few it has) is that we harry and worry the folks who take money and give little or no value in return out of the Amiga market. I've personally led USENet fights that closed two rip-off outfits, and if I could maintain my net access long enough, Montgomery Grant, the Amiga Magazines carrying their ads, the Post Office Postal Investigator Service Mail Fraud Unit, the angry customers and I would have our day together; when and if I get back, that's the next Amiga Politics Project on my list after the reorganization is complete. There are tens of thousands of businesses founded in this country every year; the Amiga can get by with just the ethical ones, thank you. The rest just lower the _Amiga's_ reputation. We'll gladly send them your way, if you consider them so valuable. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? -- Convener, ongoing comp.sys.amiga grand reorganization.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (12/10/90)
Kent, this IS a vendetta. The truth lies somewhere between Ben Williams is an angel and your position: In article <1990Dec10.070806.14519@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >>| <xanthian@Zorch.SF-Bay.ORG> (Kent Paul Dolan) writes: > >Sorry, you picked one paragraph out of a two page diatribe comparing HamE >to DCTV: Perhaps this one will refresh your memory: > > Ahem. The HAM-E can display a quarter of a million colors, > and do them as a MUCH sharper image than the DCTV can. > How is that slamming? That sounds pretty mild. It is true. RGB differentiates color better than composite. It sounds relatively factual. No one likes NTSC standards, which is what DCTV does. >Whereupon he goes on the slam the DCTV for needing a $100 option to >output RGB, and slides right past the extra cost for the "encoder" >required to make the HamE output composite color. With the $100 option, >one assumes the DCTV would have an equally sharp image; without the >"encoder" option, I'd guess the HamE can't go to videotape at all. > HAM-E isn't intended to go to videotape. Ben Williams would be the first to tell you to buy DCTV if that were your need. HAM-E is meant as a graphics booster for Amiga users. And I doubt that the DCTVs NTSC signal can be brought back from NTSC color hell with a $100 option. >A vendetta needs a specific target; I began this discussion as a general >slam against sleazeballs advertising lesser trash as 24-bit systems, and >your excerpts provided the perfect example. > It sounds like you should be trashing DCTV, not HAM-E. Ben Williams has not advertised yet, and has never claimed HAM-E to be more than an 18-bit HAM mode, which it is depending on whether you use number of bits or equivalent number of bits. DCTV, on the other hand, calls itself 24 bit, and there have already been numerous articles saying that NTSC isn't close to 24 bit. -- Ethan Woody Allen on Los Angeles: "I mean, who would want to live in a place where the only cultural advantage is that you can turn right on a red light?"
etxtomp@eos.ericsson.se (Tommy Petersson) (12/11/90)
In article <1990Dec10.031722.16926@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes:
-And as for the European customer with the power supply, I believe that
-Black Belt is attempting to correct the situation. In the first
-enthusiasm of product shipments, this kind of thing often occurs.
-Companies have to be informed of complaints first tho, before they can
-take corrective action. Seems to their credit that they're trying.
-
I'm the European customer WITHOUT the power supply... I don't know if
Black Belt is attempting to correct it, the posting You forwarded didn't
indicate so. I'll wait and see...
The postings from Black Belt are written in such a way, that it is easy
to mis-read them. The product ratings with HAM-E 7/8 and Toaster/DCTV at
4/5 are not product ratings but subjective picture quality ratings, and
doesn't deserve the flames people might want to burn with.
For me, HAM-E supports PAL, so it wasn't much of a choice...
As stated in postings and email to mee, 200V/50Hz supplies are not hard to
get by in US, so if they want to correct it it's a money issue for them.
I hope this will be solved, so I can use it. The Paint program supplied
seems to be heading in a good direction.
Tommy Peterssonetxtomp@eos.ericsson.se (Tommy Petersson) (12/11/90)
In article <1990Dec10.120431.23963@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: - - Kent, this IS a vendetta. The truth lies somewhere -between Ben Williams is an angel and your position: - -In article <1990Dec10.070806.14519@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: ->kdarling@hobbes.ncsu.edu (Kevin Darling) writes: ->>| <xanthian@Zorch.SF-Bay.ORG> (Kent Paul Dolan) writes: -> ->Sorry, you picked one paragraph out of a two page diatribe comparing HamE ->to DCTV: Perhaps this one will refresh your memory: -> -> Ahem. The HAM-E can display a quarter of a million colors, -> and do them as a MUCH sharper image than the DCTV can. -> - How is that slamming? That sounds pretty mild. It is -true. RGB differentiates color better than composite. It sounds -relatively factual. No one likes NTSC standards, which is what -DCTV does. - Mostly agree with that, they really don't "slam" anyone. The articles may/may not agree with reality, but are at most exaggerations, not lies. They should also be seen in the light of a series of articles a few months ago reviewing DCTV and giving mis-information about the HAM-E. They were, however, not written by the makers of DCTV (not officially anyway). ->Whereupon he goes on the slam the DCTV for needing a $100 option to ->output RGB, and slides right past the extra cost for the "encoder" ->required to make the HamE output composite color. With the $100 option, ->one assumes the DCTV would have an equally sharp image; without the ->"encoder" option, I'd guess the HamE can't go to videotape at all. -> - HAM-E isn't intended to go to videotape. Ben Williams -would be the first to tell you to buy DCTV if that were your -need. HAM-E is meant as a graphics booster for Amiga users. And I -doubt that the DCTVs NTSC signal can be brought back from NTSC -color hell with a $100 option. - "For use in all your video applications, the HAM-E is designed to operate with most external NTSC or PAL encoders, as well as external genlocks." ->A vendetta needs a specific target; I began this discussion as a general ->slam against sleazeballs advertising lesser trash as 24-bit systems, and ->your excerpts provided the perfect example. -> - It sounds like you should be trashing DCTV, not HAM-E. -Ben Williams has not advertised yet, and has never claimed HAM-E -to be more than an 18-bit HAM mode, which it is depending on -whether you use number of bits or equivalent number of bits. -DCTV, on the other hand, calls itself 24 bit, and there have -already been numerous articles saying that NTSC isn't close to 24 -bit. - -- Ethan - "The first mode is one where you can have up to 256 registered colors out of a palette of 16 million colors (24 bit!)." This is from Black Belt's colour flyer, and is the only place where they mention 24 bit. You have to be rather stupid to mis-interpret that, so I can't say that they have lied about that. - Woody Allen on Los Angeles: - - "I mean, who would want to live in a place where the only -cultural advantage is that you can turn right on a red light?" Tommy Petersson
kdarling@hobbes.ncsu.edu (Kevin Darling) (12/11/90)
etxtomp@eos.ericsson.se (Tommy Petersson) writes: > I'm the European customer WITHOUT the power supply... I don't know if > Black Belt is attempting to correct it, the posting You forwarded didn't > indicate so. I'll wait and see... In an email exchange they indicated they were figuring something out. While I'm working on my end, I'd suggest that you email them also. Hmmm. Drat, I can't find Ben Williams' address. If you still have one of the previous postings, it'll be like <xxxxx.xxxx@compuserve.com> At the least, you should probably email him your desires/plug needs, etc. > As stated in postings and email to me, 200V/50Hz supplies are not hard to > get by in US, so if they want to correct it it's a money issue for them. Perhaps they can help, then. Yo! Can someone point out a place from which to obtain a small (what was it? 12vdc?) 220v/50Hz supply suitable for computer equipment? The ones I asked about were around $35/each, compared to the $1 or so a US "wall-wart" is in quantity. This may be tough to resolve. > I hope this will be solved, so I can use it. So do I. That's part of what nets are for... to help resolve problems. And you've been decent about it all. On my end, I'll try my best to help. The flamers sure won't :-( Best - kev <kdarling@catt.ncsu.edu>
siri@otc.otca.oz (Siri Hewa) (12/11/90)
In article <6142@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >The 300-330 lines of resolution for video does NOT equal pixel resolution. > This is not true.Out of 525 NTSC st lines there are about 50 lines not used for active video.So you have about 475 active video lines.So that is broadcast standard.Out of that you must have proper relationship between the sub-carrier and horizontal frequency.(sc-h).To do this you need expensive decoder ccts.Consumer electronics do not give this sc-h relation due to cost.You need this relation because when you decode the composite signal if you use comb filters (analogue or digital) it is easier to separate chroma and luminance signal. In PAL domain whole thing is very complicated by the switching burst.Thats why PAL digital comb filters are expensive. Iam one of the hardware designers that design AVS ADAC DIGITAL STANDARD CONVERTER. This is the best one at the moment.It cost about $US200,000.00 This can handle any broadcast video in either way.Including Digital Video CCIR 601(4:2:2). Most people do not know about broadcast standards.I will be willing to give some info regarding any world tv standards.(May be I might post this to the net). By the way there are 60 Hz PAL and 525 PAL as well.These standars are called PAL-M,and Pal-N.(South American countries got this). Dont ask what Iam doing in Australia.(I haven't figure that out my self).I thought I can take a break here.Iam thinking going back to UK,to my old place.I missed all my fellow engineers there. Sorry for the long BW. >Consider that 480 pixels of horizontal resolution is about equal to NTSC's 525 >Broadcast television is about 330 lines of vertical "video" resolution...some >prosumer camcorders and video decks have much higher (SVHS= 425, EDBeta= 520). This is wrong information. >As someone wrote in a message to me, the PIXEL resolution of DCTV is 736x482. > >Sean > Siri Hewa. ||||OTC|| R&D Visual Communications. Australia.
jnmoyne@lbl.gov (Jean-Noel MOYNE) (12/11/90)
All right, so let's summarize this:
The HAM-E is a 8 bit-planes device, the same way the Amiga is a 6
bit-planes machine (even a little better, since you can't choose all your
colors in half-brite).
The Amiga has a 4 bits/gun color resolution (4096 colors)
The HAM-E has 8bits/gun of color resolution (16.4 Millions)
The company and the product are young, and they did a mistake thinking
they could sell the unit in Europe without supplying a power supply. They
allready have the luck to have a product which is compatible with PAL and
NTSC (means ony one production, and reduced costs) they should make the
effort to give the good power supply with it, it'll be a winning move for
them.
You can make animations on the HAM-E device by page flipping AND
using the standard ANIM format, and the standard ANIM players.
You can use DPaint III's animation capabilities under certain
conditions (like, you have to set the grid to 2, which is normal since DP
is working in 640, but your display is 320). You are limitted to some
brush moves (I don't believe it'll a good idea to try to rotate the brush
for example).
And then again you have the price of the device. (i.e. don't dream
too much, you won't get the toaster for the price of the HAM-E (-:)
Does this look like a fair description ? If so, could someone
knowlegable about the DCTV do the same sort of description ? (I've only
had interest in the HAM-E since the DCTV is only NTSC for the moment, but
maybe the DCTV is better?)
In anycase, none of these systems (at least HAM-E and DCTV)
shouldn't be qualified as 24 bit-planes devices, the HAM-E has a 24 bits
color resolution .. that's it, and it's not enough to be a true 24
bitplanes device.
JNM
--
These are my own ideas (not LBL's)
" Just make it!", BO in 'BO knows Unix'cs472119@umbc5.umbc.edu (cs472119) (12/11/90)
This is a little off the main thread, but if there's anyone out there who wants to develop a video board, 24 bits isn't really necessary. I'd be really happy with 800x600 in 8-bits with amiga native video pass through. I'd even buy a 2000 or 3000 to have a slot for it. Would it be difficult to build a card with a blitter and everything that are register and command compatible with the original video modes, eliminating the endless wait for a device independednt library? -Larry
seanc@pro-party.cts.com (Sean Cunningham) (12/12/90)
In-Reply-To: message from siri@otc.otca.oz In that second quote...what was wrong information? That broadcast TV is about 330 lines, or that prosumer video equipment is higher? If 480pixels doesn't equal 525 scanlines, then that's fine...I wasn't aware of the 50 unused lines. But vertical video resolution isn't equated equally to pixel resolution. And the 330 lines figure for broadcast is a figure I've read more than once, and will be on my TV-I final exam on Wed :') 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 1990 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
bobl@pro-graphics.cts.com (Bob Lindabury, SysAdmin) (12/15/90)
76004.1771@compuserve.com (Ben Williams) writes: > Next, neither the toaster nor DCTV are 24 bit _output_. What you see > is the issue here, not what is going on where you can't see. > The HAM-E also represents it's data in 24 bits internally; > output images in the HAM-E mode are mixtures of 18 and 24 bit data. > I don't think that makes the HAM-E 24 bit; although it does give it > the ability to have a better image than any composite signal. The 24 bit output debate is mute if you are going to video as a final product as we do. We do all our work for video productions so I have a biased opinion. I also have no need for 24-bit output. Others do I'm sure. I have a need to manipulate up to 24-bit deep images in real-time (as in painting on) in a frame buffer for output to video. I currently use the TrueVision TARGA products to do this. The TARGA and VISTA products represent true 24-bit frame buffer devices to me. > I've had the opportunity to sit next to a Toaster for 3 days, running > lightwave, just generally mucking about with it. Output images > occasionally approached the HAM-E's quality, but ONLY when they were > lightly colored - the monochrome rez of the Toaster is reasonably high. Again, not an issue if your output is designed for and going to videotape anyway, as mine is. As a sidenote, I found that ToasterPaint was less than acceptable to my needs also. I find it annoying to have to work on an image in HAM mode (yech!) and then send it to the buffer to see what I had done. I think this is rediculous even if it is required by the Toaster. I'm use to painting in something like TIPS or Lumina where you work right on the 24-bit canvas like you would in any normal paint program. This is a requirement for an artist as far as I am concerned. > DCTV does not modulate the signal with 24 bits of data. So, even > taking into account the damage done by NTSC encoding, it never > _was_ 24 bits. I don't know if this applies to the Toaster. I am unfamiliar with DCTV as it hasn't been released yet. The only contact I've had with it is at shows and it doesn't conform to my idea of what a 24-bit board/frame-buffer is. > If saving images in 24 bit was the point upon which they all turned, > as your message seems to imply, then the HAM-E would be a 24 > bit system, because we do all our manipulations in 24 bits. Actually, it's not just saving or reading 24-bit images. I feel that it has to do with manipulating and displaying as well as saving and reading 24-bit deep images be the output in RGB or NTSC. Just because I output composite video (NTSC) from my TARGA 16 doesn't mean that it's not a 16-bit frame-buffer. > I am NOT saying this is so; I'm just putting it this way to show > you that your conclusion isn't clearly indicated. - Ben Yes, I've made a few mistakes and I would like to retract the statement about the DpaintIII brushes. While they do work with the grid on, there are still some pretty major limitations that affect the way I would use the device and Dpaint. The limitations outweigh the advantages (in my opinion <grin>) for using the HAM_E device for 2D work. I find that the HAM_E may well be worth 5 times it's cost when working with images rendered from a 3D appliaction however. I think that the ability to animate in real-time a full 8-bit (256 color) ray-traced image makes the HAM_E a valuable device as long as we can get it to lock up to our edit suite. We will be connecting it to a Magni today to find out what the story is as far as genlocking goes. -- Bob ______ Pro-Graphics BBS "It's better than a sharp stick in the eye!" ________ UUCP: crash!pro-graphics!bobl | Pro-Graphics: 908/469-0049 ARPA/DDN: pro-graphics!bobl@nosc.mil | America Online: Graphics3d Internet: bobl@pro-graphics.cts.com | CompuServe: RIP _________ ___________ Raven Enterprises 25 Raven Avenue Piscataway, NJ 08854