the JAY page

Jay is the fastest JPEG rendering software we have ever seen. Written almost entirely in assembly language for speed, and using much better math in the complicated process of transforming the data, much like the FFT compared to the DFT, it outperforms packages such as QPEG, yet maintains FULL spatial and color resolution.
New version 2.01 incorporates the ability to decode progressive JPEG images. These files require more processing in order to decode them, so don't expect the same great speed as JAY can deliver for sequential files. Also, EMS is a must for any performance (in the absense of EMS JAY will use a swap file for progressive JPEGs). You may run JAY on machines with hardware EMS, or emulated by memory managers such as EMM386 or QEMM. Windows 95/98 users can execute JAY from a DOS box, as it emulates EMS, but exiting to DOS will require you to explicitly load a manager in either config.sys or config.dos
Also in release 2.01, as compared to version 1.x
Click here to download JAY version 2.01 (54,941 bytes)
--- or ---
Click here to download JAY version 1.01 (53,114 bytes)
both versions include a PIF file to aid in using JAY in WindowsTM

Caveats

JAY requires VGA or Super VGA to operate, and a 386 or better to run. Although VGA works, best results for both time and resolution will be obtained on a VESA compliant SVGA.

Feedback

I encourage comments, bug reports, and even suggestions for improving JAY. If you have observed something which doesn't seem right, or have an idea, send it to mpucoder@aol.com

README
Additional parameters for JAY
The instructions in the embedded JPEG are a little incomplete, there are more parameters you may use with JAY. One allows for a slideshow by activating a timer, it is FILE_DELAY, or, positionally, the parameter following the filename. Units for FILE_DELAY are seconds, from 0 (no delay) to 65535, and the default is 65535 - a very long time.

Six more parameters control what kinds of video card JAY will attempt to use, and color depth. But first, a description of the video mode selection process will help to understand the effect of these options.

Normally JAY assumes VGA mode 13 (320x200 display with 256 colors) is available, and it also tests for VESA functionality. The actual video mode is then determined by the size of the image as follows:

If the image is in color the smallest size video mode which can completely display the image is chosen. If DITHER=0 this mode must also be a HI-COLOR (32K colors) or TRUE COLOR (16M colors) mode. If no color mode can display the entire image, scaling is attempted from 7:8, to 1:8 in steps of 1.

If the image is monochrome, or MONO=TRUE, or scaling failed to allow complete display of the image, or DITHER=2, then the process is performed using only the 256 color modes.

When using the 256 color modes JAY will dither the colors using a preset palette unless MONO has been set true, in which case JAY uses a palette of 256 grey tones.

The parameters

MONOa boolean value which, if true, forces JAY to use monochromatic rendering.
The default for MONO is FALSE
DITHERa numerical value which determines when a 256 color palette may be used.
=0selects no dithering unless there is no HI-COLOR or TRUE-COLOR mode which can display the image.
=1allows dithering if the best fit video mode supports only 256 colors.
=2forces dithering on all color images.

In most cases it is better to allow some image reduction rather than use a dithered rendering since the reduction in color depth will almost always produce a "palettized" appearance, wheareas the method used to reduce image size eliminates aliasing, even at the 1:8 ratio.
The default for DITHER is 0 (only when no other method)
VGAa boolean value which, if false, disables video mode 13.
The default for VGA is TRUE
VESAa boolean value which, if false, disables the VESA modes.
The default for VESA is TRUE
MAXWIDESpecifies the maximum display width mode to use. This can be used to limit JAY to modes which, although supported by the video card, exceed the capability of the connected monitor.
default = 1024
ERASEa boolean value which, if FALSE, will not erase the previous image if the next image can be rendered in the same video mode.
default = TRUE
You may wish to use VGA or VESA if JAY is incorrectly sensing the presence of either interface, or if you wish to see what images look like on an old VGA card.

MONO can be used to force monochromatic displays, which can sometimes have higher resolution than the color counterpart due to video memory limitations, and, therefore, avoid the decimation process used in scaling.

Some answers to some common questions

Q. How does JAY achieve its speed?
A. Without divulging everything used to render images quickly, we can tell you the two most important factors are ASSEMBLY language procedures for the Inverse Discrete Cosine Transforms (IDCT) and YCbCr to RGB color space transforms, and scaled integer math.

Q. How accurate is the rendering of JAY?
A. As accurate as the video mode being used allows. There was no sacrifice in accuracy used to achieve the speed, only better math.

Q. Does JAY interpolate pixels during reduction or monochromatic rendering?
A. No, reduction is done by using a modification of the IDCT process to yield fewer pixels per coding block. This not only reduces errors, but is actually faster than interpolation. Monochrome images are rendered by simply discarding the color information, if any. JPEG images are stored in a color space called YCbCr, which stands for luminance (Y), chrominance-blue (Cb) and chrominance-red (Cr), by ignoring CbCr a monochrome image is obtained with less work.
Note: it is for these reasons that some programs can very rapidly produce monochromatic thumbnail images, usually at 1/8th the width and height, by discarding the color data and skipping the IDCT altogether.

Q. If you use only integer math, why does JAY require a 386 or better processor?
A. The answer to this one has nothing to do with integer vs floating point math, but the methods used in two areas required 32-bit registers or 386 instructions to perform well. One area is the process of extracting the Huffman encoded data from the file, and the other deals with the very large numbers at the end of the IDCT and beginning of color space conversion. An 8086 version could be written, but very few machines prior to the 386 are still in existance or outfitted with VGA or SVGA displays.

Q. What is this strange background on the JAY page?
A. It is a code fragment from JAY, in it you can see how the YCbCr information is changed into RGB information for the Green color element. (However, this is an older version than is currently used)

Back to MPUCoder Home
Background image: "Forming the green element" code fragment from JAY.