:-------------------------------------------------------------------------: : Black Belt Systems JFIF spec JPEG public interface load & save document : : Original Release: October 1st, 1991 : : Last Update: January 24th, 1992 : : Revision Level: 1.07/030 : : Author: Ben Williams, AA7AS : :-------------------------------------------------------------------------: : : :Revision History : :================ : :- 1.07/030 - Locks buffer, fixes New As Current, adds ability to place : : commands in any location using a global data file in the : : REXX: assignment. : : * requires level 6.16 of the image processor : :- 1.06/030 A few more messages appear on the main image processor panels : :- 1.05/030 is compiled ONLY for the 68020/68030 processor, uses new bars : :- 1.05 Accepts 1.0 & 1.1 level JFIF files. (can read Oct "PD jpeg" files): : + can write files to root:dir/file.ext containing spaces : : + can read files from root:dir/file.ext containing spaces : : + Reports errors on main IP/IM panels : : + Provides progress indication for load and save operations : : * Now requires revision level 11 minimum to operate : :- 1.04 Fixes bug where reading max compress under new parser would fail : :- 1.03 Adds better parser in REXX for other JFIF/JPEG implementations : :- 1.02 Adds smarter clip naming inside Imagemaster : :- 1.01 Automatically configs port for Imagemaster or Image Professional : :- 1.00 Initial Release: 1st commercial JPEG for the Amiga! (Oct 1st 1991): : : :Brief Description : :================= : :This is a JFIF format JPEG image decode/load and encode/save package for : :the following image processing packages from Black Belt Systems: : : : : Image Professional (IP) : : Imagemaster F/c (IMFC) : : Imagemaster (IM) : : : :If you have one of these packages, but have an earlier revision than is : :specified as required in the changes list above, you'll need to obtain : :an update to the software. Contact Black Belt Systems for details. : : : :In this document, all of these programs will be referred to as : :the "image processor" to remain general. : :-------------------------------------------------------------------------: Contents: ========= The JFIF/JPEG package consists of three portions; first, an ARexx script called "jpeg.rexx", a CLI command called "rdjpg" and another CLI command called "wrjpg". Installation: ============= This package is automatically installed by the install-pi script System Requirements: ==================== The JPEG/030 PI Module set requires that you have at least a 68020 microprocessor and preferably a 68030 or 68040 microprocessor. There is no requirement for a math co-processor; the JPEG PI module uses only integer math in the execution-critical path. Image load times will decrease by as much as 200% when using the 68030 microprocessor and this special version, as opposed to the 68030 and the "normal" JPEG PI Module. WARNING! >--------+-------------------------------------------------------------+ | Attempting to use this PI Module on a 68000 or 68010 based | | Amiga will result in a system crash! | +-------------------------------------------------------------+ Use: ==== Done ---- If you choose Done, the PI module will return immediately to the image processor without performing any operation. If there was an image in the primary buffer, it will still be intact. Load ---- If you choose Load, a file requester will open (initially set to RAM: as a path). Use the file requester to locate and choose the JPEG file, which (most likely) will have an extension of ".jpg", which is preset in the file requester. If your JPEG files do not have the extension ".jpg", then you should clear the field in the file requester that is preset to that; otherwise, you won't see any of your files in the filelist. If you cancel the file requester, any image in the primary buffer will still be intact. During decompression, the WorkBench screen is displayed. This is done so that those of you who are using a high-resolution 16 color screen for display will not suffer speed penalties during decompression. A progress bar indicates the degree to which the load has completed. When the image has been loaded, the image processor display will return to the front, and the image will be drawn. Save ---- If you choose Save, you are presented with a control which you can set from zero to one hundred. This controls the amount of JPEG compression that is applied to the image. When this control is at zero, the resulting file will be of the highest quality, and the largest size. This is the default. When the control is at one hundred, the resulting file will be of the lowest quality and the smallest size. Once you have set this control, you'll be asked if you want the "best" compression, or "good" compression. The difference is mainly that "best" compression takes a small amount off of a file, given any particular image, and also takes a great deal more memory to actually do the compression. "Good" compression works almost as well, and uses less memory to get the job done. This is a good choice for low memory systems. Once you make the choice here, You are presented with a file requester. Choose the output file you wish written. Press Save JPEG; If you press CANCEL, the operation will abort immediately. If you press Save JPEG, image compression begins. During compression, the WorkBench screen is displayed instead of the image. This is done so that those of you who are using a high- resolution 16 color screen for display will not suffer speed penalties during compression. A progress indicator appears on the image processor control panel showing the degree to which the save has completed. When compression is complete, you will be returned to the main image processor display. Short JPEG Discussion ===================== JPEG is great for some things... and absolutely the worst thing to use for others. Consider: JPEG loses some quality when it compresses an image. Not a lot, if you use minimum compression, but still, some loss of quality occurs. If you're a scientist or a doctor, don't think "loses quality", instead think "loses and changes data"! Consider what happens if you're working on this image over a number of sessions. Each time you save and load the image in JPEG format, it deteriorates a little more (or a lot, if you compress it a great deal). The lesson, and the rule that comes from it, is obvious: Don't EVER use JPEG as a storage format for an image you're working on, or for an image that will be used in another image (unless you positively KNOW that the loss of quality won't matter, for whatever reason). JPEG is really good for archival storage of images you like, but aren't "serious" about. On minimum compression, a single use of the JPEG technique on an image will not seriously degrade it. And that's what you'd normally do with an archived image. Store it once, then load it as you please to view it, as many times as you like. Alternative Savers ------------------ The ideal saver would compress an image the maximum possible amount, and not damage it at all. This way, you can save and load the image as much as required while working on it, and you won't be using an uneccesary amount of storage to accomplish this. The Amiga IFF24 file format uses "run length", or RL, coding as it's primary compression method. This is a moderate to poor way to do things. But, it's all there has been to date. However... ---------- Look for Black Belt's new PI Module for PMBC format images. PMBC stands for "Plane Minimizing Block Compression", a technique invented at Black Belt Systems specifically to address the need for higher (lossless) compression of 24 bit images. PMBC doesn't get anywhere near the compression levels of JPEG; but it almost always does quite a bit better than IFF24, and especially so on images that are "real" 24 bit, such as images of a face. PMBC does it's best work on images with complex gradients; it does it's poorest work on images with a high order of embedded dither, such as a 256 color GIF image might contain. Space savings of as much as 200% over IFF24 have been seen on some fairly typical images; savings of 16% over IFF are more typical, but think what that means... if an IFF takes 300k, then the same image coded in PMBC would be 252k. And this is a fair average of the savings we've seen over hundreds of test images. If you have 100mb of images on your HD, then you may save as much as 15mb without losing a single bit of image information! The PMBC PI Module is available for Imagemaster, Image Professional and Imagemaster F/c. PMBC is a proprietary method developed by Black Belt Systems. PMBC is not available using any other image processing package on any platform. It one of many unique advantages only Black Belt Systems customers have. Possible Problems: ================== Messages: --------- If there are problems encountered by the JPEG module, messages will indicate what the problem is. These messages normally appear in the image processor control panel. Image Quality: -------------- If the decompressed images aren't as good as you'd like, then there are two paths you could follow. First, if you have access to the compression, reduce the amount of compression/quantitization. Second, you can elect not to use JPEG. JPEG is inherently a "lossy" format, which essentially means that it damages your images in the process of storing them. We suggest you do NOT use 24 bit IFF, which is the standard Amiga non- lossy high-color storage process. Use PMBC; it will retain every bit of information in your image, and will save you considerable disk storage in the process over IFF24. Loaded images are all Black: ---------------------------- The JPEG decompression failed (usually due to a memory shortage). Reduce memory usage, or get more memory. Memory: ------- If the decompressed JPEG file will be too large for the remaining amount of memory, then it will not be decompressed. Instead, your main control panel will re-appear. You will get an error saying... size is discontinuous (X:Y), N ...which indicates that the primary buffer in the image processor isn't the same size as the image to be decompressed; which is correct, since the primary buffer wasn't created. X and Y will show the size of the image, and "N" the approximate amount of memory needed in the image processor. Not JFIF: --------- If the JPEG file is not a JFIF encoded file, then it will not be decompressed. (JFIF is the type of JPEG file that Black Belt Systems has elected to support as of this writing). If you think the file type is JFIF, but the PI Module won't read it, provide us with a copy of the file. We'll either fix it, or explain what's happening to you. Mac "JFIF" ---------- Files from the Apple Mac computer have additional information in the beginning of the file that cannot be read by this PI Module at this time; there are other differences as well. Known JFIF/JPEG sources at this date (Early January 1992) --------------------------------------------------------------------------- Program | Source | Platform | Status --------------------------------------------------------------------------- Imagemaster - Black Belt Systems - Standard Amigas - (commerical) Imagemaster F/c - Black Belt Systems - Amigas + FC24 h/w - (commercial) Image Professional - Black Belt Systems - Amigas + HAM-E h/w - (commercial) ADPro release 2 - ASDG - Standard Amigas - (commercial) PD JPEG Utilities - Tom Krehbiel - Standard Amigas - (PD) JPEG source code - Free JPEG group - Machine independant - (PD, C Src) Image Alchemy - ?? - IBM PC Clones - (shareware) --------------------------------------------------------------------------- ARexx: ------ If you do not have ARexx installed, this loader cannot function at all. The obvious solution is to get ARexx. ARexx comes standard with the 2.0 operating system; since the 1.3 operating system is now out of date, you should purchase an 2.0 Enhancer package for your Amiga. You'll get ARexx in that package. We no longer support, nor recommend the use of, the 1.3 operating system in any form.