Gifmod

TAKING A SECOND LOOK... AT VERSION 2 (Menu Driven Cinemascope)

By Dr. Allen Jacobs

In TRSTImes 2.6, I reviewed a sophisticated, valuable, and unique graphics program for the TRS-80 Model 4 entitled GIF4M0D4, by G.F.R "Frank" Slinkman. In this issue, I have the pleasure of reviewing a totally new GIF graphic file conversion utility entitled GIF4MOD4 Version 2. Why do I say it is totally new? Because virtually every aspect of Version 2 has been improved or is a new feature, compared to Version 1. Why compare a program only to an earlier version of itself? Because, previous to Version 2, the only utility of its kind for the TRS-80 was Version 1.

Some information about what this program does, and what GIF files are, can be found In the references at the end of this article. In case you do not have access to these references, I will try to explain the program's overall function.

GIF4MOD4 converts GIF graphics files into displayable images, on either the Radio Shack or Microlabs hl-rez graphics boards. "GIF" stands for the "Graphics Interchange Format" developed by Compuserve for storing hi-rez graphics in a form that enables computer systems normally incompatible with each other to exchange graphics images. GIF graphics files are available from a number of sources in addition to Compuserve itself. Almost every other computer system in the world can create, edit, transfer, and store graphics image files in GIF. Many bulletin board systems and public domain software houses store libraries of GIF graphics image files.

Within my expectations, rudimentary GIF file image recovery should have been enough of a task for any self respecting TRS-80 utility. This is because, from the point at which a hi-rez graphics image is produced, It can be edited by any TRS-80 hi-rez paint/draw program. It can be stored in any format supported by the editing program (/HR, /HRG, /CHR, /BLK, etc. formats), and it can also printed. PRO-DRAW, REMBRANT, and TRS-DRAW are the names of programs that immediately come to mind for performing these functions.

The problems of shading and color

If shading is a rather easy task for a black-and-white television receiving standard color composite video broadcast signals, it would seem that there should be no problem for a program processing a GIF file to one of our monochrome hi-rez boards to achieve a perfect monochrome rendering. Such is not the case.

All television broadcasts are designed to a single minimum standard that was adopted before the first commercial television receiver was ever made. Therefore, a black-and-white television receiving standard color composite video broadcast signals requires no image reconstruction processing because the format of the signals it receives are transmitted with the luminance information for the image separate from the chrominance information. The luminance information is the brightness of each area in the image while the chrominance information is the actual color for that area.

All the monochrome television set has to do is to ignore the color information as it processes the video signal and you have a perfectly respectable "black-and-white" (monochrome) image. In the case of composite video (normal television), color is "add-on" information to an originally monochrome signal.

This broadcast standard was established, by the FCC, with the requirement that future enhancements to the original monochrome standard would not require additional processing or equipment by existing, older receivers. For this reason, a standard for high resolution television broadcasts has not, as yet, been adopted. The bad news is that it may be years until such a standard is agreed upon. The good news is that when it is finally established, all receivers will be able to receive the same quality of images that they received before adoption of the new standard.

In the case of computer graphics, numerous display systems, incompatible with each other, were in existence before any graphics display standard was established. None of these systems are under any regulatory requirement to comply to any standard display format. In this case, an interchange format, such as GIF, has to accommodate for all the existing incompatibilities and provide for others that have not, as yet, been developed. It has to do all this and still have a manageable file size. This after the fact format has only one factor working in its favor. It is a computer format. The processing necessary to tailor a file adhering to the format can be performed by the receiving computer itself, without the addition of any hardware, as long as there is software capable of accomplishing the task.

Since the GIF file format was developed in 1987, long after the advent of color and digitally encoded imaging techniques, it has become more efficient to encode only the color information for each discrete area of a graphics image. The name for a discrete area in a digitally encoded image is called a pixel. The GIF format allows the computer to select a color for each pixel, which automatically assigns the inherent brightness of the selected color, to that pixel.

While the current version of GIF (V87a) format allows images to contain as many as 256 different colors, what do you do if you have only two "colors" available to you (black and white) and no way of varying the brightness of a pixel on the screen? You are able to produce only high contrast images or line drawings. This is the case with our hi-rez monochrome boards. While this level of control is acceptable for some cartoons, it is not adequate for working with pictures originally created in color.

What makes GIF4MOD4 so sophisticated is that it automatically shades the monochrome image It produces on our hi-rez boards with different dot patterns according to the color indicated for a given area in the GIF image file. The name of the general technique used for creating the appropriate pixel pattern for each area of the image is called "dithering".

Dithering is defined as trembling. It is the way an artist blends colors with the tip of his brush to soften or smooth out the border between adjacent areas. On a hi-rez board, the brightness of each individual pixel in a given area can not be altered, but the proportion of lighted pixels to dark pixels can be controlled. The method of determining pixel area shading in this manner is called the dithering algorithm. The manner by which different algorithms alter the image must be seen rather than be described. I tried to describe them in the first review and, from that, I contend that viewing a GIF image is literally worth over a thousand words. There are more problems to be overcome, however, as we shall see.

The problems of size and proportion

While a monochrome television has no problem dealing with color, there is one problem that the television industry has had to deal with that makes it sound like the computer industry. There is an apparent economic payoff if you can keep your customers locked into a medium where you, the producer in the medium, can control the distribution of your product. While product quality, and not medium exclusivity, has proved to drive the marketplace, being able to lock the market up through an engineered incompatibility has always been an economically attractive proposal. It used to be called cornering the market. It has never been successful but it will always be tried. Amazingly, the eventual winner is the consumer because most incompatibilities have had to be improvements to have been marketable.

Old movies fit on a television screen very nicely because television has the same aspect ratio (width to height ratio) as the old movie screen standard. Movies went to color just as television started out. I believe that they went to color partially because television started out. So, the movie industry saw no threat to the television viewing of movies because they could only be seen in monochrome, even If the movie was in color. After all, the television standard originally lacked a provision for color.

When that fact changed, the movie industry took steps to prevent movies from being shown on television without some degradation in quality. Hence, Cinemascope, a different aspect ratio for movies versus television was born.

Currently, high definition television promises to have a nearly Cinemascope aspect ratio. I wonder what is in store for the movies. Have they learned?

The relevance of the aspect ratio problem for the computer graphics industry Is slightly different in origin but the same in practice. Every manufacturer adopted its own graphics standard, hoping that ITS standard would be THE standard. Even in the MS-DOS world, there are differing graphics standards.

Without laboring the point any further, how does the television industry handle the aspect ratio incompatibility? There are basically only three ways to do It. We have seen them all on our television screens from time to time. The most common solution is to crop the ends off of the wider aspect ratio image. The second most common solution is to compress the image in the direction wider direction until it fits the narrower medium. Lastly, the least common method (but my favorite) is to reduce the size of the entire image until its widest dimension fits within the narrower format.

Television usually uses the first option because the editor "knows" in advance what is of interest in the image and decides how much of each end of the wider image to sacrifice. However, when the entire width of the image must be shown at once, as with the credits, the entire image is distorted so that the cowboy on his horse looks like a tall space creature riding a giraffe. This is the most objectional form of editing. The third form of editing is admittedly "hard on the hardware" but it provides the most undistorted view of the original image. It is not used often because parts of the screen would be noticeably blank or dark and the picture tube would become unevenly burned in.

Gratefully, the last option is the method that GIF4MOD4 uses to render square pixel images, under the optional control of the user. The d ifference between my television and my computer is that the computer allows me a creative capability that my television lacks, (unless I were to start to make my own home movies). In the case of differing aspect ratios, I understand the problem, the solutions available, and the limitations of each. I hope you do also, now. Where we may tolerate the editing decisions of others in their broadcast television presentations, I think we would all like to make our own graphics decisions on our computers.

There are also problems with the size differences between different graphics standards. They are similar to the incompatibilities we have between our own Model l/lll screen sizes and Model 4. Since we have all encountered these problems, I will not labor over them. Suffice it to say that GIF accommodates screen sizes up to 65535 by 65535 pixels. In my last review, I mistakenly stated that the limit for GIF (tm) was 640 by 480 pixels. That is simply the limit that GIF4MOD4 can accommodate due to our memory size limits.

Enter: GIF4MOD4 VERSION 2

Now that I have rambled on about the problems posed by computer graphics interchange, I have tried to relate them to similar problems in the television broadcast of feature films. This is because we have all seen, in broadcast television, what has to be done to perform image transfers between incompatible media. The only way to see these solutions and their results on our hi-rez boards is to see GIF4MOD4 in action. There is one other way to do it if you don't have a hi-rez board, but I will cover that option later.

In my earlier review of GIF4MOD4, I had stated that GIF4MOD4 Version 1 had solved these similar problems In computer graphics interchange, to the limits of our hardware. It does, in some respects. Then why is there a need for Version 2? Firstly, you may recall that I had a few criticisms about Version 1. Some were minor bugs which could be patched. Secondly, there were problems I had encountered that I thought, were unsolvable, (not so). Thirdly, there were apparently other problems that I didn't even encounter, which were solved in Version 2. Amazingly, virtually every criticism I made about Version 1 was addressed and every suggestion was implemented. Nobody can ask for more than everything. Yet, that is what we have in Version 2.

The installation instructions for a stock, single sided, two drive system appear very straight forward. If you do not have any other drive capacity, you will need to make a minimal system disk. Gratefully, I did not have to do this because I have external drives (and a hard disk). A standard memdisk, however, will provide you with all the speed you will need in most cases. Writing files of the processed image and/or for an interlaced image, to a disk file are exceptions. Disk capacity above the minimum requirement, however, is the most critical requirement. Otherwise the only concern is speed. A ramdisk would solve all questions of drive capacity and speed, immediately. It is a luxury but definitely not a requirement.

The most striking initial difference over Version 1 is the speed of Version 2.1 was quite amazed to see Version 1 put ANY graphics image on my previously unused hi-rez screen, even if it took between 4 to 4 1/2 minutes to complete the process. When that time is reduced by Version 2 to under 1 minute, it seems as though I put an XLR8er board into my computer, although I have not. I am beginning to wonder what would happen if I DID. It actually took as little as 39 seconds for BATMAN/GIF, a 3K, 300 x 200 x 4 levels of gray CGA file, on a Gate Array Green Screen Model 4 with a standard memdisk and the factory seal intact, to process.

This speed difference is of increased practical importance when it is magnified by the additional dithering options available in Version 2. There are now a total of 7, plus some other options, but I will get to them soon. If you choose to dither an image, you will want to try every available dithering option. Most images require dithering and I recommend that you do try each option. Assuming that you allow the image to completely process each time, you are looking at a minimum total experimental processing time of over 1 /2 hour per image.

With Version 2 and the GIF file of interest both in a standard memdisk, the same entire process can be completed in under ten minutes. That time can be reduced further if you quit processing before an image is complete and you are not satisfied with the way it looks, by hitting the < break > key. The program neatly allows this. You can reach your conclusion in seconds instead of minutes. However, your time increases again in Version 2 because a number of runtime options have been added which multiply your dithering menu choices by a factor of 4. You end up spending the same amount of time on an image you like. This is only because your viewing choices are greatly increased and you will want to take advantage of them all.

Color Controls

In Version 2, Mr. Slinkman has developed an error correction dithering algorithm that is adapted to the proper aspect ratio of our pixels. It uses a 1.2 aspect ratio rather than 1:1. This gives a result generally superior to algorithms designed for square pixels. Frank describes it better than I can since he created it. His descriptions of it can be found in the referenced articles at the end of this review. The dithering method is called the Slinkman Dither. I suspect that we will eventually see it in more places than on the TRS-80. Remember, we saw it in GIF4MOD4 Version 2 first.

Brightness, Contrast, Horizontal and Vertical

Other familiar processing options make GIF4MOD4 Version 2 seem more like a television set than a computer program. Actually, we can now control the processing of a graphics image as completely as we can control the image on a monochrome television. The options that effect image processing are: + b, +c, + r, and +s.

The + b option adds a noticeable amount of brightness to the processed image. Frank suggests that it be used when dumping graphics to the printer. I did not do any printer dumps because I could see the effect directly. It gives a pattern to a normally black appearing background but foreground images are brighter also.

The + c option increases the contrast of the entire image. Brighter areas become brighter still while darker areas will lose most or all patterning. An extreme case of this effect occurs if the "no dither" option is selected. All brightness values are divided right down the middle. This option, however, is less extreme and useful in conjunction with the other dithering options.

The + r option increases both the contrast and brightness of the entire image, effecting the brighter areas of the image most of all. The +r stands for exponential ramping of the colors. I have a qualitative idea of what it is doing from the terms but I am not sure what the process is actually doing. The effect is pleasant and useful. I know that an explanation like this is useless if you have not seen it, but it requires little explanation to detect if you are looking right at it.

The +s option is the opposite of the +c option. It decreases the contrast of the entire image. It is there if you need it.

The + d option, while simple to invoke and probably to program, is one of the most elegant parameters in the program. It allows you to process GIF files, even if you don't have a hi-rez board to see them on. Why would you want to do this? Because you can later output the /HR files to your printer! This option gives you graphics capability in the absence of graphics hardware. You will need a utility to dump the file, but they are available in both commercial programs and in the public domain, as mentioned earlier. If your hl-rez board is not installed or inoperable, you have print utilities right on the included disk.

Frank has also written a program to print out GIF images, in very high resolution, on a Radio Shack DMP-2100, a HP DeskJet, and a C. Itoh 8510 - also known as the Apple Imagewriter). If you have any of these three printers ONLY, he will include the appropriate printer driver programs.

The +d option also allows you to create a printable file without having to load the editor portion of your draw/paint program to extract the file from your hl-rez board, even if you are using it. If you do not invoke it and your hi-rez board is not operating or present, the program will ask if you want to process to a disk file anyway. If not, it will quit. That is safe, clean, and neat.

The other optional parameters available are drive directives. They are :s and :d. They allow you to direct the source, temporary interlace, and output files between any valid drive(s). These are very necessary conveniences/options because they save the renumbering and write protection of drives. I never processed an interlaced file under Version 1 because I didn't have one. Without drive specification capability I might not have been able to do so. But no matter, it's there now.

You may remember my earlier mention of incompatible aspect ratios and their effects on image processing. I did not mention, however, that in digital images, aspect ratio incompatibility can occur at two different levels. There can be different ratios between the number of pixels in height and width of an image. This is the obvious level of incompatibility. The level that is not so obvious is that the pixels themselves can have different aspect ratios.

It's like building a square or rectangular patio with SQUARE bricks or building the same shape patio with RECTANGULAR bricks. If I told you to make a patio 200 bricks high and 200 bricks wide using standard rectangular red bricks, all placed In the same orientation, you might be surprised to discover that the patio would not be square, until you thought about it.

The graphic standards for many computer systems are based on the broadcast television screen aspect ratio of 4:3, but not all. Many also use rectangular pixels with an aspect ratio of 1:2. But, others work with square pixels having an aspect ratio of 1:1. Thus, two graphics standards with the same width to height ratios in number of pixels may have different overall aspect ratios due to the differing aspect ratios of the pixels they use. This is the other level of incompatibility between graphics standards.

Version 2 deals with both levels. It automatically scales the number of pixels in the width and height of the source file to the nearest simple ratio between the source and our hi-rez screens. If it can not do this exactly, it informs the user to expect a small degree of distortion. GIF (V87a), itself however, apparently does not have a descriptor for the aspect ratio of the pixels that originally composed the image. Since this information is not in the file, we must manually decide whether the image was originally created using [FJull screen (the TRS-80 and most common standard) or [Sjquare pixels. When appropriate, a menu is displayed requesting a decision. This decision can best be made by inspecting a version of the file, processed each way. As I stated earlier, I like the fact that the image is not cropped. Rather, it is displayed smaller than the full screen but entirely.

GIF (V87a) supports two different image formats and, therefore, so does GIF4MOD4 Version 2. The two file formats are Normal files versus Interlaced files. Normal files process from left to right and from top to bottom. Interlaced files load in the same direction, but only every eighth line gets processed, starting from the top. Then, every eighth line starting from line 4 gets processed. Then, every fourth line starting from line 2 is processed. Finally, every other line starting at line 1 completes the image.

The process is interesting to watch and it requires the creation of a temporary file. The reasons that interlaced files exist is unclear to me except that most interlaced files are large. Video scanning is often interlaced to reduce the bandwidth (basically, the amount of information) that the video system must support on a frame by frame basis, per unit of time. Since an interlaced file usually requires more time to process than a normal file, I am guessing that interlacing somehow allows for a greater processing capacity. After processing some interlaced files, I can tell you that they are not interlaced to take less time to process.

Bells and Whistles

The program, as it stands, is as complete and faithful to its function as it can be. Therefore, the following programs and files are convenience and adjunctive bonuses. For its purpose, each is just what is needed.

True interchange means that you can send as well as receive. Therefore, HR2GIF/CMD performs just the function you would expect. Give it a file with a valid extension, a source drive, a destination drive, and the choice of format you want: [N] ormal or [I] nterlaced.

HR2GIF/CMD will process the image file into a 640 x 240 x 2, Normal or Interlaced GIFfile. That is: 640 pixels wide by 240 pixels high by two colors (black and white). The syntax is: HR2GIF/CMD fileid/ext :s :d

For files smaller than this, such as Model III 512 x 192 files and image blocks from (partial image files) from some draw/paint programs, HR2GIF/CMD will automatically center the image on the Model 4 standard 640x240x2 file with your choice: [B] lack [W] hite background.

Again, we have the most elegant solution to screen aspect ratio incompatibility. It allows anyone receiving the file the greatest opportunity to work further with it.

APENDGIF/BAS is the next logical bonus that seems to fit, only after you discover it. I never thought of combining files in this manner. I would have expected to combine files on-screen with an editing paint/draw program. Instead, files can apparently be processed on top of each other, in sequence, forming an animated "slide show". I don't see how this phenomenon can be transferred to paper but it is quite effective on screen. Do not expect to be overwhelmed by the speed of animation.

Of all the features in this package, APENDGIF/BAS appears to have the least apparent utility. I have learned, however, that just because I don't see an immediate use for this feature, that someone else will not find use for it every day. Admittedly, if I had seen ABULLY/GIF in action the day I bought my Model 4,1 would have bought it with a hi-rez graphics board right In it (/ did buy my Model 4, with the hi-rez graphics board right in it).

Five JCL files are included In GIF4MOD4 Version 2. Four of them patch the GIF description of an image file to permit automatic processing of the file in the future. One allows the default drive for storage of the temporary interlace image file. There are ample warnings in the documentation that some of these files are irreversible and should be used sparingly. Personally, I would only use them on a backup of any image file I would patch.

Most of the time I found the options menus sparse enough that I didn't mind the single keystroke to get through them. I found that temporarily renaming GIF4MOD4/CMD TO G/CMD and renaming the image file I was working with, to a single letter such as BATMAN/GIF to B/GIF, made running the process faster than using a shell. This is because after a file was renamed, the program and file required less keystrokes to invoke. I used SHELL 2.0 to rename the files. That includes adding the optional parameters.

The five JCL files are as follow:

CGA2TRS/JCL: Changes screen height from 200 (CGA height) to 240 (TRS-80 height) and forces GIF4MOD4/CMD to treat CGA pixels as "square" instead of 5:6.

EGA2VGA/JCL: Changes screen height from 350 (EGA) to 480 (VGA) and forces GIF4MOD4/CMD to treat EGA pixels as "square" instead of 35:48.

FORCEFUL/JCL: Changes screen height from 200 (CGA height) to 201 and forces GIF4MOD4/CMD to treat CGA image as "full screen".

PIKDRIVE/JCL: Patches GIF4MOD4 to change the default target drive for /TMP files.

VGA2EGA/JCL: Changes screen height from 480 (VGA) to 350 (EGA). Use this file ONLY to reverse changes made to a GIF file by EGA2VGA/JCL

Frank Slinkman did not have much to say about CHECK-GIF/BAS but it was something I was curious about. I wanted to be able to find out what information a GIF file contains. In Version 1, little information about the parameters of the file was available. Version 2 gives more information about the files, but not about how many colors are In the file at runtime. That turns out not to be critical in practice but I still wanted to know. Additionally, I have concluded that if you start collecting and cataloging a large volume of image files in their original formats, an edited form of this program would be useful. The information that CHECKGIF/BAS extracts, can be LPRINTed or saved to a database, along with other information about the image file. Such a method can ease the task of organizing a practical graphics data base. Therefore I still like the program.

One bug, one fix, one criticism, one retraction, not bad.

One very minor bug persisted in GIF4MOD4from Version 1 to Version 2. The [F] / [S] persisted on the screen during image processing. This had no effect on the processing of the program and was only a cosmetic bug. Frank didn't see it because he only has a Microlabs board and it shows up only on a Radio Shack board, which I have. He has already mailed out a patch to fix the bug, which I haven't applied yet, because it has not been that big a priority, if you know what I mean. I will do so after writing this review arid I am sure that it will work. That ten line patch will update Version 2 to Version 2.1.

I mentioned GIF4MOD4 to a club member at one of our user groups and told him what it can do. He wanted it to do one thing that it doesn't do. He wanted it to do color separations by thresholds. He asked me if it can be done and I decided that it already does this when it does not dither. He wanted it to separate out the primary colors (color groups) so that they can be printed separately, in different color overlays.

I thought about that and mentioned the proposal to him at another meeting. He said that he thought about it also and decided that even if it could be done, it would not be practical because there is no means of registering the different overlays in a color xerographic copier, anyway. I asked him how often he needed a feature like that and he said that he never has yet. I asked him if it was worth pursuing and he said "No". That is the closest thing to a suggestion for improvement that I have encountered or generated. I'm satisfied and I think you will be also.

One last word

If I have made this review sound more like a review of a television system than a computer program, it is not by mistake. That is what the program will remind you of. Increasingly, the two technologies are starting to interrelate. GIF4MOD4 Version 2 allows us to tune into this phenomenon, to the limits of our systems.

References:

TRSTimes 3.1. Jan/Feb 1990

GIF4MOD4 Version 2 Documentation

COMPUTER NEWS 80 November 1989

BYTE September, 1989

0 0

Post a comment