tgl@g.gp.cs.cmu.edu (Tom Lane) (01/21/91)
Mike Castle (mcastle@mcs213f.cs.umr.edu) writes: > Maybe Tom should post an "official press-release" on how the project is > coming along. Something a little more detailed than his last, anyway :-> OK, here is a "press release" about the free JPEG effort. I have also included some responses to questions and complaints about JPEG in general. 1. What is the free JPEG group doing? Our goal is to produce a freely available, high-quality implementation of the JPEG image compression standard. "Free" means just that: we will give away source code, and you can use it for whatever purpose you like. (We have not quite decided whether to put X-Windows-style copyrights on the code or to make it straight public-domain, but in any case it will be free for both commercial and noncommercial use. We will *not* put GNU-like restrictions on it.) Our immediate plan is to create only format-conversion software: programs to convert images between JPEG-compressed format and other popular formats such as GIF, TIFF, PPM, etc. To view a JPEG image you'll need to convert it into whatever format you use now and then use an existing viewer program. If JPEG becomes widely accepted, we expect that other people will incorporate our code into viewers and so forth. One reason for not tackling viewers now is that it's very tough to build portable viewing software, and portability is an essential requirement for what we're doing. We intend to produce a generic Unix implementation, which will work with Jef Poskanzer's PBMPLUS package. We will also produce standalone programs that work on non-Unix machines; presently we have people committed to build MS-DOS, Macintosh, and Amiga versions of the software. (If your favorite machine isn't on this list, don't whine --- volunteer.) The standalone programs will probably not be able to read and write as many image formats as the full PBMPLUS package can handle, but they will be able to handle several popular formats. We hope to make our software sufficiently modular so that the guts of it can readily be incorporated into other programs. 2. Why are we doing this? Partly for fun (JPEG is a real technical challenge), but mostly as a service to the net. In particular, we can read the handwriting on the wall with respect to alt.sex.pictures: it is not going to last long unless its bandwidth usage is cut significantly. Widespread usage of JPEG for image posting will help a lot. We also hope that the availability of a compact image format will allow wider usage of pictures on the net. (See Dave Read's proposal for a general purpose rec.images newsgroup, which will come to a vote soon.) We recognize that the net is not going to adopt any new posting format unless free or very inexpensive software is available for a wide variety of machines. We hope that we can cover enough machines to let JPEG reach "critical mass" and become a de-facto standard on Usenet. Once that happens, people with unusual hardware can adapt our source code to run on their machines. Another reason for our work is to encourage compatibility. The draft JPEG standard is an extremely loose document: a large number of decisions are left up to the individual implementor. People working in isolation are likely to produce implementations that can't actually exchange JPEG-format files. (I hear that this has already happened with the first several commercial JPEG implementations for the Macintosh.) By making and giving away a high-quality implementation, we hope to establish a de-facto standard for JPEG file format and to provide a painless path for people to adhere to that particular interpretation of the JPEG standard. Incidentally, we are seeking to cooperate with commercial JPEG developers to ensure that a common format is established, even with people who don't want to use our code. If you are part of a company working on a JPEG project, *please* contact me so that we can keep in touch. 3. Who are these guys, anyway? I (Tom Lane) am just the instigator and organizer of the project. A number of fairly well-known computer graphics people have joined the group, including Jef Poskanzer (author of PBMPLUS) and Lee Crocker (Piclab). We have also got members from several commercial outfits including Pixar and Thinking Machines. (I think most of them are doing it on their own time, though.) 4. Isn't JPEG really slow? Well, it's not lightning-fast, but it's not that bad. The prototype implementation we have now, on my 25MHz 68030 Unix box, can decompress a typical 512x480 image in a little over one CPU minute (and a good fraction of this time is spent in the color quantization step, which is not needed if you convert to 24-bit-RGB formats). We have not paid much attention to performance optimization so far, so I'm confident that the final version will be faster. On typical PC-class hardware, a couple of minutes to decompress an image is probably a good ballpark estimate. Note that you do *not* have to pay this price every time you want to view an image; you can convert it once to some other format. We regard JPEG as a format for distribution and long-term storage of images, not for use with images that you are actively working on. For many people on the net, the savings of transmission time will more than make up for the conversion time. The 512x480 image I just checked is 168Kbytes in GIF format and 33Kbytes in JPEG format. Since I have to download posted images from my netnews server at 2400baud, it would take me about ten minutes less to download that image in JPEG format; I can convert it back to something displayable and still be eight or nine minutes ahead (not to mention the savings on my phone bill). 5. What about image quality? It is true that JPEG is inherently a "lossy" format; the output is generally not pixel-for-pixel the same as the input. However, with proper choices of the JPEG compression parameters, the differences will be extremely hard to detect with the naked eye. The standard is designed to take advantage of known limitations of the human eye and brain. Furthermore, the compression parameters can be adjusted to trade off compression ratio against image quality. I beg of you not to judge the JPEG standard solely by the recently posted Image Alchemy program. Image Alchemy is not a very good implementation of JPEG. For one thing, they do not do post-DCT smoothing of the output image, which we find to be essential for decent image quality. They also seem to have some outright bugs in color handling; in one test I ran, their output image "faded out" (lost color saturation) at *higher* values of their quality setting. This should not happen at any quality setting. A number of people have tested JPEG on the basis of GIF->JPEG->GIF conversions. This isn't really a fair comparison since JPEG is actually a 24-bit-color format. If you start with a GIF image you have already introduced color quantization artifacts by reducing the original scene to 256 or fewer colors. This process creates high-frequency color "noise" (particularly if color dithering is used), which JPEG isn't designed to reproduce real well. You get considerably better results if you do the color quantization only after decompressing the JPEG image. I have placed some companion postings in alt.sex.pictures (for lack of a better place) which show a fairer comparison. I started with a small section of a 24-bit-RGB image and converted it to JPEG and back, at two different quality/compression settings. I then converted both the original image and the two de-JPEGed images to GIF format for posting. (I would have posted the 24-bit images, but they're big and I get the impression that not many people on the net have 24-bit-RGB display hardware.) I believe these images give a fair comparison of JPEG's potential, assuming that (a) JPEG is used right off the bat for compressing images obtained from color scanners, and (b) the ultimate viewer has 8-bit-color display hardware, so that color quantization must be used at some point. Here are some stats about the sample images: Dimensions: 200x200 pixels Size in 24-bit-RGB format: 120000 bytes (3 bytes/pixel) Original image converted to GIF: 39162 bytes JPEG file at the higher quality: 9492 bytes (4x smaller than GIF) JPEG file at the lower quality: 5311 bytes (7x smaller than GIF) The particular compression parameter settings I've used are just examples; plenty of higher, lower, and in-between settings are possible. Incidentally, this was done with our prototype software, not with Image Alchemy. For equivalent compression parameter settings, I.A. produces a larger JPEG file and a poorer-quality output image than ours does. It's worth pointing out that the JPEG standard has an *enormous* parameter space (about 200 distinct 8-bit values), and there is no reason to think we've found the best parameter settings yet. Further experimentation may yield parameter values that give higher quality for the same compression ratio (or equivalently, more compression for the same quality). Since a JPEG file includes the parameter settings used to compress the file, older JPEG software will still be able to decompress images made with better parameter settings. 6. Why should the net convert to JPEG? Principally, to reduce bandwidth and storage requirements for posted images. JPEG images can be at least a factor of 4 smaller than GIF images with hardly any visible change in image quality; factors of 7 to 10 are achievable with not a lot of quality loss (the resulting images are still much better than many that I've seen posted). Secondly, because JPEG preserves full 24-bit-color image information at no extra cost. As more people get 24-bit-color display hardware, this will become an important consideration. 7. How soon will the free JPEG software be ready? We're not very far along yet. We have a quick-and-dirty prototype implementation, which is not very fast or portable. We intend to rewrite from scratch to produce the final version. We do not wish to release what we have now. At our present rate of progress, I would guess we will have releasable software sometime this spring. We could still use the help of some more folks; if you'd like to volunteer, contact me by e-mail. We'd prefer people who have internet FTP access. -- tom lane Internet: tgl@cs.cmu.edu UUCP: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/21/91)
Please do not interpret this as an attack on any of the people involved, or JPEG in general. I have been very unhappy with what I have seen so far, and do have some comments and questions. In article <11623@pt.cs.cmu.edu> tgl@g.gp.cs.cmu.edu (Tom Lane) writes: | 5. What about image quality? | | It is true that JPEG is inherently a "lossy" format; the output is | generally not pixel-for-pixel the same as the input. However, with proper | choices of the JPEG compression parameters, the differences will be | extremely hard to detect with the naked eye. The standard is designed to | take advantage of known limitations of the human eye and brain. | Furthermore, the compression parameters can be adjusted to trade off | compression ratio against image quality. The question (of opinion) is if the average image can stand the loss. To say that the photo is not the image, and the 24 bit scan is not the photo, and the GIF is not the 24 bit scan is all true, I question if all the losses inherent in the process justify a technique which introduces more, or rather justifies any effort not to lose more data than is already gone. | I beg of you not to judge the JPEG standard solely by the recently posted | Image Alchemy program. Image Alchemy is not a very good implementation of | JPEG. For one thing, they do not do post-DCT smoothing of the output | image, which we find to be essential for decent image quality. They also | seem to have some outright bugs in color handling; in one test I ran, their | output image "faded out" (lost color saturation) at *higher* values of | their quality setting. This should not happen at any quality setting. I certainly agree that the Alchemy program is not useful for anything other than producing seriously muddy images. I created images of a woman (face only) at quality levels 10, 32, 50, and 99, all of which lost the individual strands of her hair blowing in the wind. Even a 320x200 GIF image preserved at least some of the hair, and far better texture. This was done from an eight level scan. I was also unable to get the program to produce a viewable image on any VGA or 8514, including real IBM hardware. The screen turns blue, stays in text mode, and that's it. | A number of people have tested JPEG on the basis of GIF->JPEG->GIF | conversions. This isn't really a fair comparison since JPEG is actually a | 24-bit-color format. If you start with a GIF image you have already | introduced color quantization artifacts by reducing the original scene to | 256 or fewer colors. This process creates high-frequency color "noise" | (particularly if color dithering is used), which JPEG isn't designed to | reproduce real well. You get considerably better results if you do the | color quantization only after decompressing the JPEG image. I have the feeling that there are a lot more images created with an eight rather than 24 bit scanner, and that unless the noise generated by having the scanner do the reduction to 256 colors is handled better than the noise of having GIF conversion do it, then I question if JPEG is useful for anything which is eight bit data, however reduced. Yes, that's a question, not a statement of opinion. Would it be fair to say that the losses are so severe that you must start with a 24 bit image in order to get an acceptable eight bit image? Also, is there any 24 bit viewing hardware readily available for machines such as the Mac, PC, or Amiga? I am aware of some seriously pricy 24 bit display stuff for Mac, but it represents about half the cost of the machine, and is not likely to be in the budget of the average person, or even company unless they have an actual need. | It's worth pointing out that the JPEG standard has an *enormous* parameter | space (about 200 distinct 8-bit values), and there is no reason to think | we've found the best parameter settings yet. Further experimentation may | yield parameter values that give higher quality for the same compression | ratio (or equivalently, more compression for the same quality). Since a | JPEG file includes the parameter settings used to compress the file, older | JPEG software will still be able to decompress images made with better | parameter settings. The question arises if the parameters will have to be tuned on a "per image" basis to give satisfactory results. While this is possible, it certainly requires serious development of an algorithm better than "try it and see how it looks," or reversing the compression and testing the reconstituted image against the original to minimize damage. | 6. Why should the net convert to JPEG? | | Principally, to reduce bandwidth and storage requirements for posted | images. JPEG images can be at least a factor of 4 smaller than GIF images | with hardly any visible change in image quality; factors of 7 to 10 are | achievable with not a lot of quality loss (the resulting images are still | much better than many that I've seen posted). Unfortunately I don't believe that this will redsuce net bandwidth as much as you would believe. My feeling is that as long as there is any visible loss of resolution people will see something interesting in JPEG and then a posting in GIF format will appear. | Secondly, because JPEG preserves full 24-bit-color image information at no | extra cost. As more people get 24-bit-color display hardware, this will | become an important consideration. At this point I'm unsure of the place of JPEG. I personally find that I'm marginally satisfied with the detail I can get from a 600 dpi 24 bit scan, when compared to the original. While some of the images posted could certainly stand to lose some (or all) detail, I'm not sure there's enough information to make part of it acceptable. All of your points about 24 bit in the future are well taken, and I agree. More color will come a lot sooner than more resolution, unfortunately. What you read as a need for JPEG I read as a need for a better way to compress high resolution 24 bit color images. I am not giving up hope for a better non-lossy method yet. I hope that the people who are working with JPEG will continue sharing their results with us, but I wish that no effort would be made to convince people that it is the one true solution until the results are in from some of the people who have begin working on better compressors which preserve all data. I think that for the person who must store lots of data with fidelity not too important, that JPEG is probably the method of choice (barring some huge breakthrough in other methods). Examples of this are photos of houses for real estate, people for identification, and other places where the overall effect is more important than the tiny details. For other images, I think transmission with full detail is desirable, allowing the people who need to use a compression like JPEG to save space to make that compromise themselves. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
kevinc@cs.athabascau.ca (Kevin Crocker) (01/22/91)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > Also, is there any 24 bit viewing hardware readily available for >machines such as the Mac, PC, or Amiga? I am aware of some seriously >pricy 24 bit display stuff for Mac, but it represents about half the >cost of the machine, and is not likely to be in the budget of the >average person, or even company unless they have an actual need. I may not be the average person but I do have a 24 bit video board in my machine. It is a PixelWorks UltraClipper UA1280. It outputs 1280 by 1024 in 24 bits, ---- if you have something to show and the program to show it. Unfortunately, I have very little software that uses this capability. I have some commercial software (CADKEY) that does use it and it is wonderful. I am waiting for their drivers for Windows. It cost a lot -- about $3K for the board and the drivers are about $250 each but I get upgrades for free. They also have a new X board available. Their have boards that fit in 80x86 and 680x0 machines. I run this board in a 33MHz 80386 with 387 and use a Taxan 1150 UltraVision monitor (21"). I do have the MicroSoft C 5.1 Libraries for this board and can thus compile software using the board level calls that are provided. I guess that I would be more interested in all this except for one small problem. I haven't done any programming for about 10 years and have very little C experience or any other for that matter. I would be interested in keeping in touch or testing out stuff though. Sincerely, Kevin -- Kevin "auric" Crocker Athabasca University UUCP: ...!{alberta,ncc}!atha!kevinc Inet: kevinc@cs.AthabascaU.CA
flint@gistdev.gist.com (Flint Pellett) (01/22/91)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: >| 6. Why should the net convert to JPEG? >| >| Principally, to reduce bandwidth and storage requirements for posted >| images. JPEG images can be at least a factor of 4 smaller than GIF images >| with hardly any visible change in image quality; factors of 7 to 10 are >| achievable with not a lot of quality loss (the resulting images are still >| much better than many that I've seen posted). > Unfortunately I don't believe that this will redsuce net bandwidth as >much as you would believe. My feeling is that as long as there is any >visible loss of resolution people will see something interesting in >JPEG and then a posting in GIF format will appear. I also doubt very seriously if this effort is going to result in any reduction in net bandwidth. (But I DO hope you go ahead with the work: the other reasons are more than enough to justify it!) I tend to believe this is likely due to several temptations: 1. The temptation to post both a GIF and a JPEG version. 2. The temptation to post the same JPEG image 2 or 3 times, at 2 or 3 different quality levels. 3. The temptation for someone, after seeing an initial posting of an image at a low quality level, to create and post the same image at a higher quality level that is more satisfactory in their view. 4. The temptation to post more images, since each one is now smaller. (If you've got 100 images from the Hubble, for example, you might post the 10 best GIF images of 150K each. With JPEG, you will be tempted to post the best 40 JPEG images of 40K each. I won't argue which way is better, I only point out that the bandwidth used may turn out to be the same.) 5. The temptation to not be willing to accept ANY loss in quality. For some images (such as things like Hubble images, perhaps), any further loss in the quality of the image (that could be avoided) is unacceptable. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
tgl@g.gp.cs.cmu.edu (Tom Lane) (01/22/91)
(I shoulda put a Followup-To: on the original article. Please direct any further followups to alt.graphics.pixutils.) In article <2908@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > [a bunch of questions and complaints about JPEG performance] Bill has raised some good points that I didn't cover adequately in my original article. I'll try to reply to these. To begin with, I should remind everyone that the JPEG group has no power to impose anything on anybody. If the net finds what we do to be useful, it'll get used. If not, not. People who don't find JPEG to be appropriate for a particular application can always do something else. > | It is true that JPEG is inherently a "lossy" format; the output is > | generally not pixel-for-pixel the same as the input. > > The question (of opinion) is if the average image can stand the loss. > To say that the photo is not the image, and the 24 bit scan is not the > photo, and the GIF is not the 24 bit scan is all true, I question if all > the losses inherent in the process justify a technique which introduces > more, or rather justifies any effort not to lose more data than is > already gone. Certainly there are applications where exact pixel-for-pixel reproduction is essential, and for these applications JPEG is inappropriate. I submit, however, that "recreational" images such as are usually transmitted around the net do not fall into this category. I believe that most net users would gladly trade off barely-visible defects for an increase in the net's ability and willingness to support posting of images. I find it interesting that Bill makes no comment on whether he looked at my sample images, and if so what he thought of them. I thought of posting several alternatives "blind" (not labelled) and challenging people to rank them quality-wise. The results of such a survey might be relevant to this debate. > | A number of people have tested JPEG on the basis of GIF->JPEG->GIF > | conversions. This isn't really a fair comparison since JPEG is actually a > | 24-bit-color format. If you start with a GIF image you have already > | introduced color quantization artifacts by reducing the original scene to > | 256 or fewer colors. This process creates high-frequency color "noise" > | (particularly if color dithering is used), which JPEG isn't designed to > | reproduce real well. You get considerably better results if you do the > | color quantization only after decompressing the JPEG image. > > Would it be fair to say that the losses are so severe that you must > start with a 24 bit image in order to get an acceptable eight bit image? No, it would not. Most of the testing I've done has been with 8-bit GIFs as source images (I haven't the disk space to spare for 24-bit images). I find JPEG-processed versions to be quite acceptable. What I meant was that pixel-for-pixel reproduction of a color-dithered GIF image is a *more difficult* task for JPEG than pixel-for-pixel reproduction of a 24-bit image. Color dithering exploits the eye's lack of sensitivity to high-frequency color information, which is exactly the same information that JPEG throws away. (For those who are wondering what color dithering is: suppose you have an area of an image that doesn't match any of the colors available in your limited 256-color GIF colormap. If you pick the closest available color and set all the pixels to that color, you retain spatial resolution but lose color fidelity. The idea behind dithering is to take small groups of pixels, say 2x2 blocks, and color the pixels within a group differently, so that the *average* over the group is the desired color. As long as you don't look too closely, the eye averages out the different-colored pixels. You get better color fidelity at the price of giving up some resolution. The differences between adjacent pixels in a dithered image amount to a high-frequency color signal, which is exactly what JPEG "knows" it can throw away. To some extent, JPEG will do the same averaging that the eye does; so the compressed image is actually not a bad representation of the original scene, although it cannot regain the resolution lost to dithering. But when the image is decompressed and redithered, it's almost certainly not going to be pixel-for-pixel the same as the input image, if only because of differences in dithering algorithms --- there are lots of different ways to dither. Note that you are still going to have to look closely to notice the differences.) > I have the feeling that there are a lot more images created with an > eight rather than 24 bit scanner, and that unless the noise generated by > having the scanner do the reduction to 256 colors is handled better than > the noise of having GIF conversion do it, then I question if JPEG is > useful for anything which is eight bit data, however reduced. Yes, > that's a question, not a statement of opinion. I'm not very familiar with 8-bit scanners; do they have built-in color dithering? If so, a JPEG processor would have some difficulty in exactly reproducing the scanner's output. The exact results would depend largely on the details of the scanner's dithering algorithm and on how this interacts with the dithering that the JPEG decompressor uses to produce a colormapped output file. However, this still only means that the result is *different*; whether it is better or worse, and how closely you have to look to decide, is an experimental question. > Also, is there any 24 bit viewing hardware readily available for > machines such as the Mac, PC, or Amiga? I'm aware of expensive Mac stuff and more reasonably priced Amiga stuff. In any case, I made no claim that 24-bit color was a serious concern now, only that it would be in a few years. > | It's worth pointing out that the JPEG standard has an *enormous* parameter > | space (about 200 distinct 8-bit values)... > > The question arises if the parameters will have to be tuned on a "per > image" basis to give satisfactory results. While this is possible, it > certainly requires serious development of an algorithm better than "try > it and see how it looks," or reversing the compression and testing the > reconstituted image against the original to minimize damage. This is an interesting research problem (anybody out there need a thesis topic?) but it doesn't seem to me to be an immediate objection. For the moment I think that most people will be satisfied with choosing one of two or three "standard" parameter sets, depending on how picky they are and on how good the original image is. I might point out, incidentally, that I can think of quite a lot of cases where a very compressed, not-very-high-quality image is exactly what is wanted (for instance, an inessential illustration within a netnews article, or in a catalog of an image database). JPEG's ability to support both low and high quality strikes me as a strength, not a weakness. > At this point I'm unsure of the place of JPEG. I personally find that > I'm marginally satisfied with the detail I can get from a 600 dpi 24 bit > scan, when compared to the original. While some of the images posted > could certainly stand to lose some (or all) detail, I'm not sure there's > enough information to make part of it acceptable. > > I hope that the people who are working with JPEG will continue > sharing their results with us, but I wish that no effort would be made > to convince people that it is the one true solution until the results > are in from some of the people who have begin working on better > compressors which preserve all data. Far be it from me to claim that JPEG is the last word on image compression. However, we have a problem *now*, and waiting for hypothetical future research results does not seem like a reasonable solution. Those who find 600 dpi 24 bit color to be the minimum acceptable resolution are welcome to create and view such images in the privacy of their own homes. I doubt that the net will stand for shipping around large numbers of images of that size, especially not for purely recreational purposes. My personal objective is to make decent-quality images small enough so that the net can afford to support recreational usage. > ... I think transmission with full detail is desirable, > allowing the people who need to use a compression like JPEG to save > space to make that compromise themselves. The point is that we are concerned about saving transmission bandwidth (and netnews spool storage, which is essentially the same thing). What people do for long-term storage on their own disks is their own affair, but what they post on Usenet is everyone's burden. -- tom lane Internet: tgl@cs.cmu.edu UUCP: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (01/22/91)
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr) > Also, is there any 24 bit viewing hardware readily available for >machines such as the Mac, PC, or Amiga? I am aware of some seriously >pricy 24 bit display stuff for Mac, but it represents about half the >cost of the machine, and is not likely to be in the budget of the >average person, or even company unless they have an actual need. As for the Amiga, there are already 3 24 bit boards available and I know of at least 7 others that will be out within the month (I have one on order that is only $495 which offers full 24 bit RGB output at NTSC frequencies for video work) all less than $1500. Also be aware that ANY video card for the IBM can be used in a BridgeBoard equipped Amiga so that adds those to the list of boards available for this machine (although no price has even approached those for the Amiga proper). Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)
marmoset@mondo.engin.umich.edu (Dave Walker) (01/22/91)
In article <2908@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > > Also, is there any 24 bit viewing hardware readily available for >machines such as the Mac, PC, or Amiga? I am aware of some seriously >pricy 24 bit display stuff for Mac, but it represents about half the >cost of the machine, and is not likely to be in the budget of the >average person, or even company unless they have an actual need. > I'll only tackle this part of your posting; I'm sure other people will respond to other things in it. 24-bit color is close to dirt cheap (at least on the Mac) now. We recently purchased a RasterOps Colorboard 264 for about $350. It drives a standard Apple Color monitor (or compatible) at 640X480 X 24 bits. We're buying a color scanner RSN; the one we're looking at will cost us under $2000. 24-bit input & output is well within the financial grasp of many users now. On with JPEG! PS: I believe economical 24-bit boards exist for the Amiga now, too. | Dave Walker, Detroit Art Services (DAS) | | marmoset@ub.cc.umich.edu "I don't read, I just guess" | | marmoset@mondo.engin.umich.edu -Happy Mondays, "Wrote For Luck" |
src@scuzzy.in-berlin.de (Heiko Blume) (01/25/91)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > Also, is there any 24 bit viewing hardware readily available for >machines such as the Mac, PC, or Amiga? I am aware of some seriously >pricy 24 bit display stuff for Mac, but it represents about half the >cost of the machine, and is not likely to be in the budget of the >average person, or even company unless they have an actual need. well, for PC's there is the Hercules Graphics Station. it's a TIGA beast with a TMS34010 at 60MHz, and can do 24 bit color. unfortunately they (IMHO) fucked up, since you can only put 2MB on it. the consequence is, that you can't have 24 bit color at the highest resolution (1024x768), which would require 2.3MB :-( however, the 512x482x24 picture in BYTE was quite nice. the list price is $1024 with 1MB. see BYTE Oct. '90 for more i hope they'll eventually make one with 3MB. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
coy@ssc-vax (Stephen B Coy) (01/29/91)
In article <1991Jan24.212650.6543@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >well, for PC's there is the Hercules Graphics Station. >it's a TIGA beast with a TMS34010 at 60MHz, and can do 24 bit color. >unfortunately they (IMHO) fucked up, since you can only put 2MB >on it. the consequence is, that you can't have 24 bit color at >the highest resolution (1024x768), which would require 2.3MB :-( >however, the 512x482x24 picture in BYTE was quite nice. Actually it only uses less than a meg of image memory. The 2Mb upgrade is program memory for the TIGA chip. Adding it won't change the available resolutions. >-- > Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 > public source archive [HST V.42bis]: > scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp > uucp scuzzy!/src/README /your/home Stephen Coy uw-beaver!ssc-vax!coy aka coy@ssc-vax.UUCP