ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / GRAPHICS / MISC / GIF2JPG5.ZIP / GIF2JPG.DOC next >

Wrap

Text File | 1991-05-13 | 36.6 KB | 922 lines

GIF2JPG and JPG2GIF Version 1.5 May 13, 1991 Handmade Software, Inc. 15951 Los Gatos Blvd., Suite 7 Los Gatos, CA 95032 +1 408 356 4143 fax +1 408 358 1292 tel uucp: apple!netcom!hsi internet: hsi@netcom.com compuserve: 71330,3136 Copyright (c) 1990-1991 All Rights Reserved Introduction JPG2GIF and GIF2JPG are a set of shareware programs which convert GIF files to JPEG files and JPEG files back to GIF files. Why would you want to do this? Because typically JPEG files are several times smaller than GIF files. So, by converting images from GIF to JPEG you save on modeming time, long distance charges, and disk storage requirements. The disadvantage is that you can't view JPEG files directly; you have to convert them back to GIF files so that you can use your favorite GIF viewer. Using GIF2JPG & JPG2GIF To convert .GIF files to .JPG files: GIF2JPG [options] [files...] If any .JPG files with the same name already exist you will be asked whether to overwrite them. If any GIF89A files are encountered you will be asked whether or not to convert them. GIF89A files are not automatically converted since they can contain text and multiple images; this information will be lost when the image is converted to a JPEG file. To convert .JPG files to .GIF files: JPG2GIF [options] [files...] If any .GIF files already exist you will be asked whether or not to overwrite them. There are two options which are common to both programs: -a: automatically proceeds (overwriting any existing files and converting GIF89A files). -k: kill (removes) the original files after they are processed. The GIF2JPG program has two additional options: -q[n]: specify the JPEG quality factor which will be used when compressing GIF files. The default is 55. A lower number will result in a higher compression ratio, but a lower quality image. Specifying a very low quality factor (less than 15) will result in poor quality images. -j: force compatibility with JFIF standard (also versions of GIF2JPG v1.41 and before). Note that you may specify wild cards as part of the file name and that multiple file names may be specified. Examples: GIF2JPG -q30 *.gif Will convert all .GIF files in the current directory to .JPG files, using a quality factor of 30. JPG2GIF -k -a test.jpg madonna.jpg n?.jpg Will convert the specified files back to .GIF files, deleting the .JPG files and automatically overwriting the existing GIF files. Hardware Requirements An IBM PC or clone (at least an 80286 for any kind of performance). A hard drive (JPG2GIF needs to open temporary files while processing; you must have at least 3 times as much disk space available as the largest image you are converting (for example, a 640 by 480 file requires 1 Megabyte of free space]. MS-DOS or PC-DOS 3.1 or later. 380K of available RAM. Shareware GIF2JPG and JPG2GIF are shareware programs. Please feel free to distribute them by giving copies to your friends, uploading them to bulletin boards, and trading them at user clubs. You must distribute them unaltered, and as a set, including this document. You may not sell these files for more than a $7.00 media duplication cost. You may use GIF2JPG and JPG2GIF on a trial basis for two weeks; after that you must register by sending us $20 or stop using them. The last page of this document is an order form which you may use. When you register, you will be shipped a copy of the latest version of JPG2GIF and GIF2JPG (if, according to your order form, you already have the latest version, we will ship you the first update when it is available). Image Quality JPEG compression works best on images which are continuous tone images, such as those produced by a scanner or digitizer. Images which are drawn with paint programs typically do not JPEG compress very well. In addition, the best quality JPEG images result when you start with 24 bit, undithered images. Unfortunately GIF does not support 24 bit images; and most of the 8 bit GIF images are dithered. So, if you are using a scanner or digitizer to produce images, you can get better compression ratios, and better quality images, if you generate 24 bit Targa or TIFF files and then convert them to JPEG files. You can't do this with GIF2JPG, but you can with another Handmade product, Image Alchemy. See the blatant ad below. Answers to Frequently Asked Questions: Q: How do you pronounce JPG? A: Jay-peg. JPG is short for JPEG, which is short for Joint Photographic Experts Group. Note that we use JPEG and JPG to mean the same thing; JPG only exists because PC file names are restricted to having a three letter extension. By the way, we firmly believe that GIF should be pronounced with a hard G like the word gift. The primary justification for this is that GIF stands for Graphics Interchange Format, and the word Graphics starts with a hard G. So if you call us up for tech. support don't be surprised if we say GIF (with a hard G). Q: So what exactly is JPEG? A: JPEG is a lossy image file compression standard. It is lossy because the files you get out are not quite the same as the files you get in. JPEG compression achieves much higher compression ratios this way. Most of the time the changes to the image are not noticeable. The -q option allows you to control the amount of loss (and the compression ratios) of the images. If you would like more information on the JPEG standard please contact: X3 Secretariat Computer and Business Equipment Manufacturers Institute 311 First Street NW, Suite 500 Washington, DC 20001-2178 Q: Are GIF2JPG .JPG files compatible with anything else? A: Those files which are written using the -j option are compatible with the JPEG File Interchange Format standard (JFIF, pronounced Jay-fif). JFIF software will be available from a wide variety of software and hardware vendors including Radius and C-Cube. Files written out without the -j option are a custom format specific to Handmade Software (though for historical reasons they also have a .JPG extension). Q: Why can't I view a JPG file directly? A: JPEG files are always 24 bit images, which can't be viewed directly on VGA boards. So unless you have a Targa board or a XGA compatible IBM PS/2 you don't have the needed hardware to view a JPG file directly (and in fact there aren't enough of those boards currently in circulation to justify writing a JPG view). It is possible to convert a 24 bit image for display on an 8 bit display, that is after all what JPG2GIF does when it converts to a GIF file, but it is slow. Image Alchemy, another Handmade Software product, lets you view JPEG files directly, but it uses a uniform palette, which produces sub-optimal image quality (the viewing mode in Image Alchemy is intended as a preview only). Q: What is planned for future releases of GIF2JPG? A: Faster conversion time. We are currently re-coding the software from C into 80386 assembly language. This should allow 80386 users to decompress an image in less than half the time it currently takes (we are only writing 80386 code because the technique we are using requires 1 megabyte of continuous RAM, and because of the wonderful Intel segmented architecture, it's not really possible to do this on anything less than a 80386). The other major addition will be thumbnails in the JPG files. Thumbnails are a low-resolution copy of the original image (64 pixels by 48 pixels). Thumbnails are useful if you want to preview an image before downloading and/or converting it. In the not too distant future you will able to call up a BBS, look through a listing of JPG files, select some number of images for previewing, and have the BBS quickly download the thumbnails of those images. You then select which of those images you really want and the BBS will download them (by the way, if you are an author of BBS software and you want your BBS to support this please contact us). Explanation of why GIF files grew when using GIF2JPG v1.41 and why this doesn't happen anymore: First a few definitions: A continuous tone image is one where there aren't any sharp edges between objects in the image, instead there are lots of intermediate colours around the edges of objects. Images like this are created when you scan a photograph or use a video digitizer with a video camera. Another property of continuous tone images is that there aren't any large areas which are only one colour, instead there are many subtle different shades of colour. A drawn image is exactly that, an image drawn using a paint program. Drawn images look like they are out of comic books, they have sharp edges and large areas which are one solid colour. JPEG compression is an image compression technique which compresses continuous tone images. You can JPEG compress a drawn image, but you wouldn't want to (for reasons which are explained below). GIF is a compression technique which works on both continuous tone or drawn images. GIF compression works much better on drawn images, but most of the GIF images in the world are continuous tone images. So why do some images grow when going from GIF to JPEG and back to GIF? That has to do with the differences between continuous tone and a drawn images. Take for example a photograph of a dog standing in front of a uniform blue wall. Even if the original picture looked like the wall was one colour, when you scanned it the computer would see subtle shadows and highlights in the wall (not to mention the fact that scanning an image introduces sampling noise). There also wouldn't be any instantaneous transitions between two colours; even at the edge of the dog there would be several pixels of anti-aliasing. You don't see these things when looking at the photograph because you are used to small changes in colour and detail, this is way you can tell the difference between computer generated images and images of real things (though with enough computing power it is now possible to make the differences very small). Now in contrast to scanning, think about using a paint program to draw a picture of a dog standing in front of a blue wall. The first step is to take a nice shade of blue and fill the entire frame, this will be the wall. You then grab a suitable dog colour and draw the outline of the dog. Next you use variations of this colour and fill in the dog. When you were finished you would have an image of a dog standing in front of a blue wall. You now have two different image files. A continuous tone image of a dog against a blue wall and a drawn image of a dog against a blue wall. If you now take each of these files and convert them to a GIF file, the first file will be much larger than the second file (how much larger depends on how many different colours you used to fill in the dog, but a factor of 3 to 4 is likely). This difference in files sizes is caused by the compression technique that GIF uses. GIF compression works great on areas of solid colours and sharp transitions between colours. So the solid blue background in the drawn image would compress phenomenally well, as would the area where the blue touches the dog outline colour. The only part of the scene which wouldn't GIF compress really well is the actual dog. If instead of converting the scanned image and the drawn image to GIF files, you were to JPEG compress them, you would get different results; each file would be pretty much the same size. This is because JPEG compression was designed to compress continuous tone images. Therefore JPEG compression works equally well for areas that are a single colour as for areas with subtle shading (in fact, under certain circumstances, JPEG compression works better for areas which are shaded than for areas which are all a single colour). So the scanned image of the dog and the drawn images would be pretty much the same size if JPEG compressed. So far so good, we have shown that JPEG compression is better than GIF compression for scanned images and it doesn't matter for drawn images. What does this have to do with files growing in size when they are converted from GIF to JPEG and back to GIF? Well, if we were to convert the JPEG file of the drawn dog to a GIF file something interesting would happen. The solid blue wall the dog is standing in front of would no longer be one colour, it would consist of a large number of slightly different shades of blue. This occurs because JPEG compression is allowed to slightly alter the colours of individual pixels. This is why JPEG compression ratios are so good. Ordinarily these minor changes are not significant; usually they are not even visible to the human eye. So the blue wall would no longer be one identical blue colour. When humans look at this area they don't perceive it this way; as far as humans are concerned it is still solid blue. Unfortunately GIF compression is not so forgiving. When you try to GIF compression an area of image which is many different shades of one colour, all randomly intermixed, GIF compression does a terrible job. We have known about this problem with JPEG compression for a long time. In fact GIF2JPG has included code from the first version to detect when the image being converted to a JPEG file was a drawn image . If it was the image was left as a GIF file. Unfortunately there seem to be a large number of files which are half-scanned and half-drawn. These images tend to be of the following type (I tried to draw a dog in the right hand side of the screen to match the previous discussion, but it's real hard to draw with the ASCII charset): +----------------------------------------------------------+ | |..............**......./\.......| | This image downloaded |.............**......./XX\......| | from Smiling Joe's |............*.........\XX/......| | House of GIFs. |......../\.|.|.........\/.......| | |......./..\|.|..........|.......| | |....../....\.|........./........| | |...../......\|........|.........| | Call 1-900-JOESGIF |..../........\........|.........| | |...|..........|....../..........| | |...|..........|...O.|...........| | Commercial use or |...|..........|..-+-............| | distribution not |...|..........|...|.............| | permitted. |...|__________|../ \............| | |................................| +----------------------------------------------------------- Where the left half was drawn using a paint program and only contains two or three different colours (therefore there are lots of areas of just one colour and lots of sharp transitions between colours), and the right half of the image was scanned from a photograph and therefore contains lots of different colours (and different shades of those colours). The problem with this image is that the left side shouldn't be JPEG compressed. Unfortunately the previous versions of GIF2JPG weren't very smart, they would look at the image as a whole and, because a large portion of it was continuous tone, decide that it was okay to JPEG compress it. Unfortunately when the JPEG compressed file is converted back to a GIF file the left hand side of the image will grow, making the resultant GIF file much larger than the original GIF file. This new version of GIF2JPG fixes this problem. It looks at the image in a piece-by-piece manner, deciding independently if each piece should be JPEG compressed or not. All the pieces are then combined into one file. JPG2GIF takes this file and converts it back to a single GIF image. What does all this really mean? Assume that the original image was 640 x 480 with 256 colours. As a GIF image it was 150k. Converting it to a JPEG file using v1.41 or before caused it to shrink to 65k. Converting it back to a GIF file caused the resultant file to grown to 210k. Now using GIF2JPG v1.5 the JPEG file would still be 65k; and when the image is converted back to a GIF the size is 150k. So when you JPEG compress an image using this new version of GIF2JPG you will get a file which does not grow significantly when decompressed (the image can grow or shrink slightly, this is due to the way that the pseudo-randomness of JPEG compression and GIF compression inter-react). To test this we have taken a large number of GIF files (some sent in by users of previous versions GIF2JPG and some we had laying around) and JPEG compressed them and then converted them back to GIFs. The results are that we started out with 10,456,995 bytes of GIF files, when they were JPEG compressed they reduced to 4,969,851 bytes. And when the images were converted back to GIF they ended up at 9,972,594. The actual file sizes can be found in appendix A, below. Note that some of the files grew slightly and some shrunk slightly, but none changed an extreme amount. One problem with this new technique of only partially JPEG compressing an image is that the files produced are incompatible with older versions of GIF2JPG. Therefore we have included the -j option to generate the old style JPEG files. Note that JPG2GIF automatically reads old .JPG files, so any files you have already converted to JPEG do not need to be updated (though if any are half continuous tone and half drawn it would be a good idea to re-compress the original GIF file). Is JPEG compression too slow? Recently we have gotten some complaints that JPEG compression and decompression is too slow. We admit that it is slow, and we are working on speeding it up; but we disagree that it is too slow. If you are going to be sending GIF images over a modem, it is faster to JPEG compress and decompress them, than to send the GIF files. To illustrate this we have done some timing benchmarks. We took 81 GIF files at random from those that had been sent in for various reasons and off of disks of images we had laying around. The images were not selected because they JPEG compressed particularly well, we just kept copying files off of disks until we had 10 megabytes worth. The computer used for these tests is a 20MHz 80386, with 4 Megabytes of RAM, no RAM cache, and a really slow hard drive (an ST-225). The command line used to convert the files from GIF to JPEG was "GIF2JPG *.gif" and the command to convert them back was "JPG2GIF *.jpg" (we deleted the original GIF files by hand between to two steps). The actual number of bytes in the 81 GIF files was 10,456,995. When the files were JPEG compressed the total file size was 4,969,851 bytes, a savings of 5,487,144 bytes. The total time to convert the files from GIF to JPEG was just over 40 minutes, the time spent to convert them back was just over 1 hour and 15 minutes. If you send the JPEG files over a 2400 baud modem you save over 4 hours and 20 minutes, including the time needed to both compress and decompress the files. If you were just downloading them from a BBS, and you only had to convert them from JPEG to GIF, the time saved is over 5 hours. Even if you are fortunate enough to have a 9600 baud modem, and assuming 100% modem efficiency (960 characters/second), you still would save almost 20 minutes downloading and decompressing the images as JPEG files as compared to downloading GIF files. We realize that if you have an even faster modem or a slower computer it is possible for it to actually take more time to transmit the JPEG file and decompress it than to transmit the GIF files. But with a 20MHz 386 costing less than a 9600 baud modem it doesn't make much sense for that to be the case (unless you bought a faster modem to save on long-distance or BBS chargers, in which case the download time becomes much more important than the total time and it therefore makes even more sense to JPEG compress files before transmitting them). For those of you using a Telebit Trailblazer with an original 4.77 MHz IBM PC, we suggest you sell your modem and buy a faster computer. The actual details are: Size of original GIF files: 10,456,995 bytes Size of JPEG files: 4,969,851 bytes Difference: 5,487,144 bytes Total time to JPEG compress all images: 40:11 (2411 seconds) The total time to convert all JPEG images back to GIF images: 1:16:52 (4612 seconds). Theoretical time to transmit the GIF files (10,456,995 bytes) at 2400 baud (240 characters/second): 12:06:11 (43,571 seconds) Theoretical time to transmit the JPEG files (4,969,851 bytes) at 2400 baud (240 characters/second): 5:45:08 (20,708 seconds) Total transmission time saved: 6:21:03 (22,863 seconds) Net difference (transmission time-compression time- decompression time): 4:24:00 (15,840 seconds) The actual file sizes can be found in Appendix A. Change History: v1.5 05/13/91 Changed .JPG file format to solve problem which caused some .GIF files to grow when being converted back from .JPG files. Added support for reading interleaved GIFs. The background colour of GIFs is now set to the darkest colour in the palette. Added -j option. v1.41 04/24/91 Fixed bug in JPG2GIF which caused some colours to be wrong in certain images. v1.4 04/22/91 Added -q option. Speeded up conversion. v1.3 04/18/91 Changed error messages, prompts, and examples. v1.2 03/15/91 Added JFIF support. v1.1 03/06/91 First release. Blatant Ad for Image Alchemy If your interest in image files extends beyond GIF and JPEG you might be interested in Image Alchemy. In addition to converting between over 15 different image file formats, including GIF, JPEG, TIFF, Targa, PCX, Sun Raster, Silicon Graphics Image, IFF/ILBM, PBM, and Encapsulated Postscript, Alchemy will allow you to resize images, dither images, and view images on a VGA monitor. See the order form below for details on how to get a shareware version. Bugs and Support If you have a question or think you found a bug in GIF2JPG or JPG2GIF don't hesitate to contact us. We prefer to be reached by email at the addresses listed on the front page of this manual (we apologize for not having a BBS you can call; we will soon). You may also fax us or call us during normal business hours (we are on the West Coast). By the way, contact us even if you have not registered, because in addition to wanting to know about potential bugs, we figure the best way to encourage registrations is to demonstrate that we care about our customers. Trademarks GIF2JPG, JPG2GIF, and Image Alchemy are trademarks of Handmade Software, Inc. All other products or services mentioned are trademarks, registered trademarks, or service marks of their respective companies or organizations. Disclaimer Handmade Software, Inc. makes no warranty of any kind, either expressed or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose. In no event shall Handmade Software, Inc. be liable for any errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of the GIF2JPG or JPG2GIF products or documentation. Appendix A: Details of the test files referred to above: (The file names have been removed to obscure the fact that the images were all R or NC-17 rated). Original Duplicate GIF Size JPEG Size GIF Size 228352 128199 248055 81929 81929 81929 204800 113507 225832 195850 86071 195203 78099 31053 88188 133658 47816 72605 170774 71769 183633 42298 24735 51734 228992 93782 208251 16681 16681 16681 15780 15780 15780 18762 18762 18762 134760 77648 140563 166047 76972 178659 199651 75207 194445 131758 52555 137821 32772 20666 38948 32910 18426 54964 105220 37663 106165 115222 40980 111282 54272 28727 63358 875472 290903 892499 237568 66576 196817 62673 19247 61502 34816 17642 25287 272964 135371 286302 127710 45023 134910 160501 80655 177491 125952 34676 56130 150586 58252 159437 61641 61641 61641 97197 97197 97197 32768 17498 36573 144706 45095 166127 13109 13109 13109 29409 15100 31675 261120 81807 241612 264448 99122 265028 66905 23209 64457 149632 84716 148588 79718 27409 80401 113664 33992 64730 20480 14847 22415 101439 98575 147590 106657 106657 106657 78758 32079 75053 17134 17134 17134 18288 18288 18288 14630 14630 14630 187264 86234 175588 45566 45566 45566 107284 107284 107284 99620 99620 99620 18150 18150 18150 281858 100893 286064 223734 65099 191855 114733 114733 114733 63328 63328 63328 180395 180395 180395 269755 85543 223617 206593 84623 208314 200215 85709 203982 171903 61121 168577 28544 26261 33445 268629 119638 318371 53248 15785 31031 79872 24247 43045 63488 19721 34855 51200 36165 62308 503890 166076 279601 152935 51132 84908 126206 50525 126728 33792 33792 33792 113115 48050 101624 60829 60829 60829 91885 56562 97789 49333 49152 54835 35840 35840 35840 288316 58595 205519 66747 66747 66747 110196 43058 118116 10456995 4969851 9972594 If you would like copies of the actual images to verify these results just send us enough blank, formatted disks, to hold 10 megabytes (i.e. nine 1.2 meg disks, eight 1.4 meg disks, twenty-nine 360k disks, or fifteen 720k disks), and a self- addressed, stamped box. We will also need a signed note stating that you are over 18 and want to receive adult images (yes, the test images were almost all R or NC-17 rated). JPG2GIF and GIF2JPG 1.5 Order Form Send to: Handmade Software, Inc. 15951 Los Gatos Blvd., Suite 7 Los Gatos, CA 95032 Qty Description Price Total _____ JPG2GIF & GIF2JPG for IBM PC $20.00 __________ _____ Image Alchemy -- Shareware version $2.00 __________ Sub-Total: __________ California Residents add applicable sales tax __________ Total __________ Circle Disk size: 3 1/2" 5 1/4" Circle Payment form: Check MC Visa Amex Card #:______________________________________ Exp. Date: ____________ Signature: _____________________________________________________ Name: ___________________________________________________________ Address: ________________________________________________________ ________________________________________________________ City: ___________________________ State: _________ Zip: _________ Phone: (______) ________________ Fax: (______) ________________ Phone number of BBS you got this program from: __________________ Name of BBS: ____________________________________________________