@options "-i -s +zz" @author "Johan Klockars" @database "MGIF 5.10" @subject "MGIF v5" @$VER: MGIFv5.hyp 1.02 (960710) @node "Top" "MGIF 5.10 manual (root)" @image "logo.img" 22 @{B}Welcome to the 5.10 manual@{0} Copyright 1996 Johan Klockars Getting started The Graphical User Interface General overview The text interface MGIF startup Frequently Asked Questions MGIF menus Algorithms File handling Literature Display handling Using MGIF Distribution Configuration Registration Tutorials Bug report form Definitions Questionary What's new? Authors Special thanks The future All use of MGIF is at your own risk. This manual is still being extended and revised. All comments are very welcome. @endnode @node "Getting started" @{B}Getting started@{b} Running MGIF as a GEM program requires the program to have an extension of .PRG or .GTP (for newer TOS versions). For now don't worry about if there are any differences between those two. - Change to the directory where you unpacked the MGIF archive. - If your computer does not recognize .GTP as a program extension (the MGIF_5.GTP icon is of document type rather than program type), rename the program file from MGIF_5.GTP to MGIF_5.PRG. - Double click MGIF_5.GTP/PRG. - If MGIF is still a .GTP program, push the 'OK' button or press enter in the dialog that appears. After a short while MGIF is up and running and presents you with its startup dialog. For the time being, just click the 'OK' button or press enter here. MGIF will now present its @{"menu" LINK "MGIF menus"} line. @{"Load" link "File menu" "Load file"} under the File heading in the 'File' menu will give you the normal file selector, which can be used to find the image file you want to load. If you have done everything as described above, the image you select will be loaded, converted to greyscales and drawn on the screen. If the image was not drawn automatically, you must have done something to cause MGIF to load the wrong (or no) options file. In that case, select @{"Source" link "Image menu" "Draw source"} under the Draw heading in the 'Buffers' menu to tell MGIF to display the image. Press the left mouse button once or twice to return to the menu. Now, try some of the image processing operations in the menu. Documentation can be found under 'MGIF menus' in the ST-guide manual. One thing to note about the image processing operations is that they operate on a source and give a destination image. There are two separate draw selections in the menu that show either of the images. You can make source and destination the same by changing the setup in the 'Buffers' menu. @endnode @node "General overview" @{B}General overview@{0} History Ideas Differences from other image viewers/processors @{"What's new in MGIF v5.01?" link "What's new?"} @{B}Major changes since pre-v5 MGIF@{0} MGIF v5 is by far the most extensive update yet (and hopefully ever) of the program. Some of the image processing and low level stuff is about all that is left internally of the previous versions. The most obvious new feature is of course the GEM interface, but even if that took quite a long time to put together, it's a very small part of the new code. Handling of images in mapped and 24 bit colour is in my opinion the most important improvement, coupled with the ability to show these images with good quality, at least on the more advanced Atari computers. Other changes include GIF/Targa/PPM save and scrollable image view. One of the latest additions, 8 bit colour VDI support, is also quite significant, since it's a first step towards a completely GEMified MGIF. For a complete, but not very readable, account of the changes to MGIF from the beginning of time, refer to the enclosed file 'HISTORY.TXT'. @endnode @node "History" @{B}History@{0} William Rosenkranz The text below was given in answer to an email I (Johan) sent. Any incoherency is due entirely to my editing. I Initially wrote MGIF for the following reasons: - I was interested in learning about F-S dithering - I was also interested in image processing techniques - I was starting to collect .gif images and had no way to view them on a monochrome monitor (which is normally what I use, though I also had/have a color monitor) - It seemed like an interesting project as diversion and had a practical result I forget when it all started. It should be burried in the source code. probably about 1990 or so. [Version 1.0 was released in December 1990] The key was the screen switching scheme (flicker). I forget where I got that, but I cited the developer of the technique (also in the source). [The originator was Klaus Pedersen, unfortunately unavailable per email] Once I had that working, I had a crude .gif viewer. After that, it was a relatively simple matter to add some basic image processing techniques and expand the program to also read .pi* images. I stopped development when I was personally satisfied that I had a reasonably complete system for whatever needs I might have. I think the code was designed with enough flexibility to expand (which is clearly proven by your efforts). I suppose the main thing was simplicity. That and I could not get the flicker thing working well enough in a GEM window (ie, without line-A). A full GUI would have been nice, and I had some slick things like pop-up menus that I had developed earlier to plug in. But it never panned out for me. I would probably say that MGIF under my tenure was pretty much a hack, though I think I designed it and commented it well enough for continued development. I.e., it was pretty modular and easy to add functionality (image processing, new file formats, etc.). Johan Klockars My involvement in the MGIF project was quite unintentional from the beginning. I'd liked the program very much since it first appeared on the internet, but I thought it was a bit too slow. Since the sources were available, I set about making them compatible with GNU C, which was then, and still is, the very best C compiler that runs on an Atari (and just about everything else). Along the way I cleaned up the memory handling a bit and rewrote the GIF decoder, and suddenly I had a @{B}much@{0} faster MGIF. Hurray! Some time later there was a discussion of various compilers on the Usenet atari group. The TurboC compiler was claimed by several people to be the best, which I could not believe. To prove my point I ported MGIF version 3.5 to TurboC (very simple then since it was all text based) and posted a comparison of the original MGIF, compiled by Sozobon C, and my slightly modified version compiled by GNU C and TurboC. The results showed quite clearly that GNU C was/is a much better compiler than TurboC, but it also became clear that quite a few people liked MGIF as much as I did and wanted to have the new, faster, version. A short discussion with Bill ended with me taking over the development. What happened after that, you can see for yourself. @endnode @node "Ideas" @{B}Some of the ideas behind MGIF@{0} @{B}Image processing@{0} From the very beginning, MGIF has had its emphasis towards image processing, rather than the usual image display functionality. One of the more obvious artifacts of this is the relatively small number of image file formats supported. The source/destination concept is convenient for image processing, but it can be extremely wasteful for viewing only purposes. It is possible to use MGIF with a single image buffer, but then there will be some restrictions. @{B}Flicker for greyscales@{0} As William Rosenkranz says in his part of the 'History' section, one of the important reasons behind the first versions of MGIF was that there was no way to view GIF images in any reasonable quality on a monochrome Atari monitor. He, as well as many others, liked the paper whiteness and the high resolution, but still wanted to look at pictures sometimes. The idea of flickering several, specially drawn, images to give an appearence of greyscales (by Klaus Pedersen), worked very well and has been a corner stone of MGIF ever since. FreeWare This text got quite long and was put on a page of its own for easier multiple access. Just click on the title above to read it. It's perhaps a bit philosophical, but I'd appreciate if you read it. It won't take very long and it discusses a few points I feel quite strongly about. @endnode @node "Differences" @{B}How MGIF differs from some other software@{0} It might be useful to give a short overview of how MGIF differs from the more common (right now ;-) image processing/viewing programs, such as 'GEMView' and 'Speed of Light'. @{B}Positive@{0} - MGIF is free! Not only without cost, but you can also get hold of the complete source code for use in your own FreeWare (or similar) programs. - MGIF is fast. For many things MGIF is a lot faster than 'GEMView' and 'Speed of Light'. GIF loading and drawing are two major things. To be fair, there are things that MGIF is quite a bit slower at than for example 'Speed of Light'. JPEG loading is one thing. - MGIF is better suited to image processing. I know that some people (no names) have other opinions on this, but my main reason for saying this is: MGIF can store images internally in a format that means that no information is lost. If a 24 bit image is converted to 256 colours on loading, you can lose a @{B}lot@{0} of information. @{B}Negative@{0} - MGIFv5 will not work (see below) on any 16/24 bit graphics card. Neither will 'Speed of Light', but 'GEMView' is very good at it. (The new -vdi switch may work, but I have no way of testing it.) - MGIF uses no tricks to get better colour display 'Speed of Light' has its flickering, which can be quite good in a 16 colour mode and then there are programs like 'PhotoChrome' that changes @{"palette" link "Palette"} on the fly, giving marvelous output on a simple ST. @endnode @node "FreeWare" @{B}FreeWare@{0} @{B}Programming for fun@{0} A very important reason for writing FreeWare programs is in my opinion that you can do it only because it's fun. There are never any paying users to consider when you decide on what to implement and when (if ever) to release new versions. The amount of work that I've put into making MGIF what it is today, and on top of that the work of William Rosenkranz before me and a couple of other people along the way, could never be repayed by ShareWare fees. I myself for example have certainly worked more than half a year full time on this program (and I usually work very fast ;-). But why not even try? Well, I'm in no way one of those 'Information wants to be free!' guys. In fact I despise all that cyberspace nonsense. My first contact with the internet and especially Usenet made a great impression on me, though, with all these talented people sharing their software as well as their knowledge and time. The Free Software Foundation behind GNU C, C++, Emacs etc etc and many many others, really do a lot to forward the field of computing. MGIF and the rest of the software I've written is just my small contribution. A simple 'thanks' to the internet/Usenet society. Likely nothing I ever write will have any major impact, but at least I can feel that I did what I could, and it was great fun! @{B}Joint development@{0} A very nice thing about programming FreeWare software is that it's much easier to get other people involved in it. No money is being made, so everyone can contribute however much or little they like. Over the years, I've worked together on parts of the program with two or three other people and it has worked quite well, even if they lived in Germany or Finland. If you feel you'd like to get involved, please send an @{"email" link "Johan Klockars" "email"}. :-) @{B}Source code availability@{0} While any FreeWare software is nice, it's in my opinion when it's free to the degree that anyone can pick up the work and go on that the idea really shines. I'm sure you have used software that has not been supported for years and thought of lots of improvements that would be @{B}so@{0} great to have. If the sources were available you could add those things (or persuade someone else to do them, more frequently)! This will never happen to commercial software and is also very unlikely with regards to ShareWare. It's my hope that more FreeWare authors on the Atari computers give away their sources in the future. The wheel certainly has been reinvented enough times by now. If you retain your copyrights and give an 'eternally' valid contact address of some kind (or simply state very clearly in the documentation what your terms are for using the code) there should be no problem. @endnode @node "MGIF startup" @{B}MGIF startup@{0} Program modes The startup dialog Command line switches (also in file/environment and internal to MGIF). @endnode @node "Program modes" @{B}Program modes@{0} To take full advantage of MGIFv5 it should really be run as a GEM program, but it is also possible to run in a totally text based mode, for example if you are running MiNT with a shell. Installing MGIFv5 as an application for certain file types works fine, as does dragging image files onto the MGIF program icon in desktops with support for that. Normally when MGIF is run as a GEM program, a startup dialog will appear where you can decide how you want MGIF to use its memory. @endnode @node "MGIF menus" @{B}MGIF 5.00 menus & dialogs and their explanations@{0} Desk @{"File" link "File ms"} @{"Image" link "Image ms"} @{"Buffers" link "Buffers ms"} @{"Frame" link "Frame ms"} @{"Point" link "Point ms"} @{"Area" link "Area ms"} @{"Options" link "Options ms"} @endnode @node "File ms" "File menu selections" @{B}File@{0} -- Image -- @{"Load" link "File menu" "Load file"} @{"Save" link "File menu" "Save file"} - @{"Palette" ignore} - @{"Load" link "File menu" "Load palette"} @{"Save" link "File menu" "Save palette"} -- Conf. -- @{"Write" link "File menu" "Write configuration"} --- Bye --- @{"Quit" link "File menu" "Quit"} @endnode @node "Image ms" "Image menu selections" @{B}Image@{0} ---- Draw ----- @{"Source" link "Image menu" "Draw source"} @{"Destination" link "Image menu" "Draw destination"} ---- Show ----- @{"Drawn pic" link "Image menu" "Show drawn"} @{"Info" link "Image menu" "Information"} --- 24 bit ---- @{"Quantize" link "Image menu" "Quantize"} @{"Draw RGB" link "Image menu" "Draw RGB"} - Destination - @{"UNDO" link "Image menu" "Undo"} @{"Copy (save)" link "Image menu" "Copy"} @{"Paste(load)" link "Image menu" "Paste"} @endnode @node "Buffers ms" "Buffers menu selections" @{B}Buffer@{0} ----- Copy ----- @{"Dest -> src" link "Buffers menu" "Dest to src"} @{"Src -> dest" link "Buffers menu" "Src to dest"} -- Operations -- @{"Combine..." link "Buffers menu" "Combine"} @{"Change type" link "Buffers menu" "Change type"} ---- Source ---- @{"Buffer 0" link "Buffers menu" "Source select"} @{"Buffer 1" link "Buffers menu" "Source select"} @{"Buffer 2" link "Buffers menu" "Source select"} @{"Buffer 3" link "Buffers menu" "Source select"} - Destination -- @{"Buffer 0" link "Buffers menu" "Destination select"} @{"Buffer 1" link "Buffers menu" "Destination select"} @{"Buffer 2" link "Buffers menu" "Destination select"} @{"Buffer 3" link "Buffers menu" "Destination select"} - Create test -- @{"Linear shade" link "Buffers menu" "Linear shade"} @endnode @node "Frame ms" "Frame menu selections" @{B}Frame@{0} --- Mirror --- @{"Vertical" link "Frame menu" "Mirror"} @{"Horizontal" link "Frame menu" "Mirror"} ---- Misc ---- @{"Scale..." link "Frame menu" "Scale"} @{"Zoom" link "Frame menu" "Zoom"} @{"Cut" link "Frame menu" "Cut"} @{"Rotate" link "Frame menu" "Rotate"} @{"Border..." link "Frame menu" "Border"} @endnode @node "Point ms" "Point menu selections" @{B}Point@{0} @{"Hist. equal." link "Point menu" "Hist equal"} @{"Inversion" link "Point menu" "Inversion"} @{"Log scale" link "Point menu" "Log scale"} @{"Threshold" link "Point menu" "Threshold"} @{"Contr. expan." link "Point menu" "Contr expan"} @{"Brighten" link "Point menu" "Brighten"} @{"Darken" link "Point menu" "Darken"} @{"Gamma corr." link "Point menu" "Gamma corr"} @endnode @node "Area ms" "Area menu selections" @{B}Area@{0} ----- Linear ------ @{"Convolutions..." link "Area menu" "Convolution"} @{"Blur" link "Area menu" "Blur"} --- Non-linear ---- @{"Lmax" link "Area menu" "Lmax"} @{"Lmin" link "Area menu" "Lmin"} @{"Median" link "Area menu" "Median"} @{"Oil" link "Area menu" "Oil"} @{"Pixelize" link "Area menu" "Pixelize"} @endnode @node "Options ms" "Options menu selections" @{B}Options@{0} @{"Load..." link "Options menu" "Load"} @{"Display..." link "Options menu" "Display"} @{"F-S..." link "Options menu" "F-S"} @{"Quantize..." link "Options menu" "Quantize"} @{"Misc..." link "Options menu" "Misc"} -- ST-Guide --- @{"Help" link "Options menu" "Help"} @endnode @node "The startup dialog" @{B}The startup dialog@{0} When MGIF is started as a GEM program it will display a dialog (unless told not to by the @{"-dsu switch" link "Command line switches" "interface options"} that looks somewhat like: ------------------------------- | Max memory used: 1234 Kb | | | | Use alternate / ST ram | | | | Flicker mode 24 bit | | | | Single: buffer screen | ------------------------------- Here you can tell MGIF the amount of memory to use, where to allocate it and how to use it. The number given as maximum should not be increased, but can be decreased at will. The texts in single outlines are used as switch buttons. They are selected when black and will invert if clicked. Flicker mode: Allocate memory for three screens to enable flickering (mono). 24 bit: Use three buffers for images -> 24 bit processing possible. Single buffer: Do not allocate memory for a destination buffer. Source buffer is used as destination too. screen: Use normal system screen for image display. @{B}Hints on setup@{0} Don't select flicker mode unless you really want it. In a colour mode on a TT or Falcon030 it can use up large amounts of memory. Some image manipulations need more than one buffer, for example rotation. Single screen can save quite a lot of memory, particularly on a Falcon in high resolution colour modes. If you select both single buffer and single screen you'll have the largest possible buffer area, but you won't be able to load JPEGs. I will try to fix this for greyscale and 24 bit load (950726). @endnode @node "File menu" @label "Load file" @{B}Load file@{0} MGIF will present the normal file selector, giving as default directory and file type that of the most recently loaded file. Once a file has been selected MGIF will try to load and decode it into the first buffer (or buffers if in RGB mode). At present MGIF only looks to the file extension to decide what format is used, so if a file is refused it may be simply because it has been given an erroneous extension. While that is not common with image files from the internet or BBSes, it does happen. For more information on what image types can be loaded, load modes and options etc, go to the 'Loading' section. @line 5 64 0 @label "Save file" @{B}Save file@{0} This is used to save the image in the first buffer (or buffers if it's an RGB picture). Before you can give a file name, MGIF wants to know in what format you want to save the file. It therefore presents a dialog box with a popup menu for file types and some greyed out options. For now only the popup menu and source/destination selection is implemented. For most of the file types no extra information will be required, but the IMG save will give an extra dialog. When everything is set up, the normal file selector will be presented and you can give whatever file name you wish. For more information on file types etc, see 'Saving'. @line 5 64 0 @label "Load palette" @{B}Load palette@{0} MGIF will load the palette file, *.PAL, that you chose using the normal file selector, and use the colour definitions from it for the destination buffer. @line 5 64 0 @label "Save palette" @{B}Save palette@{0} MGIF will save the palette of the source buffer to the palette file, *.PAL, that you chose using the normal file selector. @line 5 64 0 @label "Write configuration" @{B}Write configuration@{0} This allows you to write a configuration permanently into the MGIF executable file. You can't do this for the currently set configuration, but rather an options file will be loaded and used. The normal file selector will be presented twice. First to select the options file, normally MGIF.OPT, and then to select the MGIF program file itself. There is a limited amount of space reserved for options in the MGIF executable, but since all comments are automatically stripped out this is not likely to be a problem. @line 5 64 0 @label "Quit" @{B}Quit MGIF@{0} This will decompress the ROM in your machine as if it was a JPEG file and display it automatically on the screen. The resulting image depends on the TOS version, but is usually one model of Lamborghini or another. On a Falcon with TOS 4.01 as mine, it's a white '82 Countach LP400S! Uh, or perhaps not... ;-) @endnode @node "IMG save" @{B}Save in monochrome IMG format@{0} MGIF will present a second dialog before you select the file name if you got for the IMG save. Here you can select the precise size you want for the image. Either in pixels or in cm/inches, though the latter requires that you set the DPI correctly for your printer. The image will be written to a file while it's being created, so the size of your memory is no hindrance. This is mainly intended for saving images to be included into word processors or DTP programs for printing, which means that the normal Floyd-Steinberg dithering used to great effect on the screen is not very useful. For details on why, see 'Halftone'. If the 'F-S dithering' switch is selected, MGIF will F-S dither the image in monochrome while saving, using the parameters set in the '@{"Options/F-S" link "Options menu" "F-S"}' dialog. Normally the current dither matrix will be used instead. @endnode @node "Loading" @{B}Loading files@{0} MGIF can load images stored in the following file formats: Type Extensions Comment GIF GIF Both GIF87 and GIF89 can be loaded. JPEG JPG, JPE The files must be of the JFIF type. Most are. Targa TGA PPM PPM AIM AIM Format used by program Atari Image Manager. PI? PI1, PI2 Atari Degas paintprogram format (unpacked). FL FL MGIF's flicker file format. (X)IMG IMG The normal GEM image format in colour or mono. There is also a special internal format which can be used for temporary image backups while doing extensive manipulations. MGIF can also load dither and palette files. An image is not necessarily loaded only into the source buffer. - If the 'No grey' option in 'Misc...' is not selected, a greyscale version is put in the destination buffer. - Loading of some file types, such as JPEG, requires so much temporary storage that the destination buffer and extra screen will be destroyed. If you use 24 bit mode, you have three source buffers. @{B}Errors while loading@{0} A number of errors can occur during a load, especially if you're loading a JPEG, but for the time being they are all reported with the same dialog. Out of buffer space - The image was too large for the buffers. Out of virtual memory - When loading JPEGs, MGIF will use the destination buffer and extra screen (if available) for some temporary information. If this space is not enough it'll create a temporary file in a directory named by the environment variable TMP or TEMP. The temporary file can be quite large. Unknown file type - The file didn't have a recognized extension. Bad file - The extension was incorrect. File read error - Bad data or end of file detected. @endnode @node "Saving" @{B}Saving files@{0} Images can be saved in the GIF, IMG, Targa, PPM and flicker formats. When you're manipulating images it can be useful to save and later restore your destination buffer. This can be accomplished by using the '@{"Copy (save)" link "Image menu" "Copy"}' and '@{"Paste(load)" link "Image menu" "Paste"}' functions in the file menu respectively. The saving can also be done automatically, see '@{"UNDO enable" link "Options menu" "Misc"}'. Copy/paste/undo is done in an internal, uncompressed, format. In 24 bit mode all the source buffers (3) are saved. @{B}Errors while writing@{0} A number of errors can occur during a write, but for the time being they are all reported with the same dialog. Out of virtual memory - When loading JPEGs, MGIF will use the destination buffer and extra screen (if available) for some temporary information. If this space is not enough it'll create a temporary file in a directory named by the environment variable TMP or TEMP. The temporary file can be quite large. File write error - Write error or disk full detected. @endnode @node "Image menu" @label "Draw source" @{B}Draw source buffer@{0} Draw image in the source buffer onto the screen. Options selected in the display and dither dialogs affect how the image is drawn. @line 5 64 0 @label "Draw destination" @{B}Draw destination buffer@{0} Draw image in the source buffer onto the screen. Options selected in the display and dither dialogs affect how the image is drawn. @line 5 64 0 @label "Show drawn" @{B}Show drawn picture@{0} Show the previously drawn image. This is not possible unless there are two screens, which is not the case if the single screen option in the startup dialog was selected. @line 5 64 0 @label "Information" @{B}Buffer information@{0} Use 'Buffer info' to get information on the sizes and types of images in the buffers as well as the sizes of the buffers themselves. @line 5 64 0 @label "Quantize" @{B}Colour quantize@{0} When an image has been loaded in, or converted to, 24 bit mode, it's possible create a mapped picture by reducing the number of colours. This can be done using 'quantize' with astounding results. The number of colours to use and some operational parameters can be set in the '@{"Options/quantize" link "Options menu" "Quantize"}' dialog. If zero is chosen as the number of colours, MGIF will use whatever the current screen mode is capable of. The destination buffer currently @{B}must@{0} be buffer 0. @line 5 64 0 @label "Draw RGB" @{B}Draw RGB@{0} If the first three buffers are of type Red, Green and Blue respectively, for example after having loaded an image in 24 bit mode, you can draw the image in full colour using 'Draw RGB'. If you're not in Falcon TC mode, the image will be displayed using an ordered dither. In Falcon TC, the image will first be drawn quickly and then improved using Floyd-Steinberg error diffusion dithering for each of the RGB components. @line 5 64 0 @label "Undo" @{B}Undo operation@{0} MGIF will reload the latest auto-saved destination buffer image. This is not selectable unless the undo functionality has been enabled from the '@{"Options/Misc" link "Options menu" "Misc"}' dialog. @line 5 64 0 @label "Copy" @{B}Copy (save)@{b} Dumps the destination buffer contents into a file. Can be used for backing up intermediate image manipulation results or to help in complex operations. @line 5 64 0 @label "Paste" @{B}Paste (load)@{b} Loads the previously @{"copied" link "Image menu" "Copy"} buffer into the destination buffer. @endnode @node "Buffers menu" @label "Dest to src" @{B}Copy dest -> src@{0} Copy image from the destination to the source buffer. The image type is not copied. @line 5 64 0 @label "Src to dest" @{B}Copy src -> dest@{0} Copy image from the source to the destination buffer. The image type is not copied. @line 5 64 0 @label "Combine" @{B}Combine source and destination images@{0} A wide range of effects that can be produced with some creative use of this. Apart from the obvious image blending, you can for example do @{"unsharp masking enhancement" link "Unsharp masking"} (together with filter operations), binary and diffuse masking and shading. A dialog is displayed where you can select for both source and dest - if they are to be involved at all - if they should be negated - what factor to multiply them by You can also select - what divisor to apply to the source/destination sum before storing - if source and destination should be multiplied rather than added - if a constant should be added to the source/destination sum/product (after the division) - if the result should be clipped to the 0-255 interval (recommended for normal use) With this dialog it is possible to set up calculations such as: dest = source / 2 dest = source * 10 - dest * 9 dest = (source * 2 + dest * 3) / 5 dest = -source * 17 / 23 - dest * 111 / 17 + 128 dest = (source * dest) / 255 @line 5 64 0 @label "Change type" @{B}Change buffer type@{0} A dialog box will be presented where you can select what type you want to change to. The source image will be converted and the result put in the destination buffer. @line 5 64 0 @label "Source select" @{B}Source buffer selection@{0} Select which buffer is to be used as the source for image processing operations. The current selection checked. @line 5 64 0 @label "Destination select" @{B}Destination buffer selection@{0} Select which buffer is to be used as the destination for image processing operations. The current selection checked. @line 5 64 0 @label "Linear shade" @{B}Create a test image@{0} The image in the source buffer is replaced by a vertical linear shading and the one in the destination buffer by a horizontal linear shading. While this is mostly intended for test purposes, it can also be used to great effect with the 'combine' function. @endnode @node "Frame menu" @label "Mirror" @{B}Mirror image@{0} Mirrors an image horizontally or vertically. @line 5 64 0 @label "Scale" @{B}Scale image@{0} Scales an image to an arbitrary size, with or without @{"smoothing" link "Smooth scale/rotate"}. A dialog box with many options is presented. Absolute values as well as percentages can be given for vertical and horizontal sizing. It's also possible to apply a given aspect correction (set in the 'Display options' dialog) or to size the image to fit the screen. Use the 'Percentages' and 'Absolutes' radio buttons to switch between the two representations. Note that, due to rounding errors, the numbers can change slightly if you cycle between the two. Before performing the scaling, MGIF will convert to absolute sizes. @line 5 64 0 @label "Zoom" @{B}Zoom into image@{0} Use the mouse or the cursor keys to move around a window covering one quarter of the image (if it fits on screen) to choose which part to enlarge two times. To increase mouse movement speed, hold down 'Shift' and/or 'Control'. For cursor key movement, 'Shift' slows down and 'Control' speeds up. 'Help', 'Tab' or 'Alternate' (needs another key or mouse movement) toggles showing of the coordinates of the upper left window corner. To select the current position, click the left mouse button or press 'Insert', 'Return', 'Enter' or 'Space'. To cancel the operation, click the right mouse button or press 'Undo', 'Esc' or 'Delete'. @line 5 64 0 @label "Cut" @{B}Cut out part of image@{0} Cuts out a rectangular area of the image. A crosshair can be moved around with the mouse or the cursor keys to select first the top left corner and then the bottom right corner. To increase mouse movement speed, hold down 'Shift' and/or 'Control'. For cursor key movement, 'Shift' slows down and 'Control' speeds up. 'Help', 'Tab' or 'Alternate' (needs another key or mouse movement) toggles showing of the coordinates of the upper left window corner. To select the current position, click the left mouse button or press 'Insert', 'Return', 'Enter' or 'Space'. To cancel the operation, click the right mouse button or press 'Clr/Home', 'Undo', 'Esc' or 'Delete'. @line 5 64 0 @label "Rotate" @{B}Rotate image@{0} Rotate an image to any integer angle, counter clockwise, with or without @{"smoothing" link "Smooth scale/rotate"}. If the source and destination buffers are the same, only +/- 45 degrees rotation is possible. @line 5 64 0 @label "Border" @{B}Add an image border@{0} A dialog box is presented where the amount of space to be added on every side of the image can be entered. The colour index used for the added area can be given. In mapped mode the colour will depend on the palette in use. For greyscales or RGB, 0 will be black and 255 will be maximum intensity. @endnode @node "Point menu" @label "Hist equal" @{B}Equalize the image histogram@{0} This operation attempts to smooth out images with skewed or narrow histograms. The intensity values are redistributed to match their frequency of occurence. @line 5 64 0 @label "Inversion" @{B}Invert image@{0} This is a bit more general than a simple digital negative. A threshold value is needed and this is used as follows: threshold == 0: new[i] = 255 - old[i] Invert pixel threshold < 0: if old[i] < -threshold Old intensity < -threshold? new[i] = 255 - old[i] yes, invert pixel else new[i] = old[i] no, don't change threshold > 0: if old[i] > threshold Old intensity > threshold? new[i] = 255 - old[i] yes, invert pixel else new[i] = old[i] no, don't change @line 5 64 0 @label "Log scale" @{B}Logarithmic scaling of image intensities@{0} Scale each pixel's value to the ratio of the logarithm of the pixel's intensity and the maximum intensity in the image. @line 5 64 0 @label "Threshold" @{B}Threshold image@{0} Change all pixels with an intensity above a given threshold intensity to white and all those below the threshold to black. @line 5 64 0 @label "Contr expan" @{B}Expand image contrast@{0} Attempts to expand the contrast of an image to cover the entire range of 256 allowable grey scales. A threshold value is used to remove intensity levels at the top and bottom of the histogram. The histogram is searched from the top and bottom for the first intensity level with more pixels than the threshold. The pixel intensities are then changed as follows: new[i] = 255 * (old[i] - low) / (high - low) where [low,high] is the new contrast range. @line 5 64 0 @label "Brighten" @{B}Brighten image@{0} A constant value is added to every pixel's intensity. Any new values outside the range 0-255 are limited to these values. @line 5 64 0 @label "Darken" @{B}Darken@{0} A constant value is subtracted from every pixel's intensity. Any new values outside the range 0-255 are limited to these values. @line 5 64 0 @label "Gamma corr" @{B}Gamma correction@{0} The given value is divided by ten and then used to brighten or darken an image. Pure black and white will stay the same, but the shades in between will be modified in a non-linear fashion. A value of ten will keep the image unchanged, while lower values darken and higher ones brighten it. @endnode @node "Area menu" @label "Convolution" @{B}Apply convolution filter to image@{0} Apply one of a number of 3x3 convolutions to an image. Choose one of the built-in filters or enter your own. DSP code now gives @{B}very@{0} much faster operation (10x) on a Falcon. Smoothing (low pass), edge detection (high pass), sharpening etc can all be done using these filters. For more information on the filters, see 'Convolutions'. Each pixel's intensity value is changed to a value calculated by multiplying the pixel intensities of the pixels in the surrounding 3x3 square by the corresponding factors in the convolution matrix and summing up. A multiplier or divisor can be applied to the sum before the result is used as the new intensity. @line 5 64 0 @label "Blur" @{B}Blur image@{0} Each pixel's intensity value is changed to the mean of the pixels in a surrounding square. The size of the square can be given. Although any odd number can be used as side length of the square, the 3x3 square is the most useful. Special code is used to optimize the speed of averaging such a square. The method used to calculate the averages for non-3x3 squares is such that the time it takes to process an image is proportional to the length of the side rather than the area of the square. An 11x11 square will take about twice as long as a 5x5 one, not four times longer as would normally be expected. @line 5 64 0 @label "Lmax" @{B}Local maximum@{0} Search a square of a given size for the highest intensity value and replace the center pixel with that. This is sometimes called erosion in other software. For black and white images this has the effect of enlarging the white areas. For greyscale images the effects are hard to describe, but generally highlights become more visible. @line 5 64 0 @label "Lmin" @{B}Local minimum@{0} Search a square of a given size for the lowest intensity value and replace the center pixel with that. This is sometimes called dilation in other software. For black and white images this has the effect of enlarging the black areas. For greyscale images the effects are hard to describe. @line 5 64 0 @label "Median" @{B}Median@{0} Determine the median intensity value in a 3x3 square and replace the center pixel with that. DSP code now gives @{B}very@{0} much faster operation (5x) on a Falcon. Useful for removing pixel noise and also for special effects. If it's applied several times, interesting results can be had. @line 5 64 0 @label "Oil" @{B}Oil@{0} Do an oilpaint alike 'smudging' of the picture. The size of the 'smudging' square can be set as can the number of 'buckets' to use. The second number should always be a power of two (it's rounded if needed) and is used to group together similar intensities. With the default, 64, the intensity 'resolution' is 4 and with 16 it would be 16. Far from all combinations of numbers work well. Experiment! The routine searches through the square around every pixel and counts how many there are of each intensity group. The value of the most common group is used as new pixel value. @line 5 64 0 @label "Pixelize" @{B}Pixelize@{0} Replace squares in the image with the mean value of the pixels in the square. The size of the square is selectable. This will give a nice looking 'mosaic' effect. @endnode @node "Options menu" @label "Load" @{B}Load options@{0} Here you can set how images should be loaded and if anything special should be done upon loading. @{B}Display@{0} Draw image directly after loading. @{B}No grey@{0} If this is not selected, every loaded image will be converted to greyscales and the result put in the destination buffer, when there is one. @{B}Fit to screen@{0} Size image to fit screen directly after loading. @{B}Correct aspect ratio@{0} Size image to correct aspect ratio directly after loading. Grey - Images stored and displayed in greyscales. Mapped - Images stored with their original number of colours and drawn as well as possible in the current screen mode. If the used graphics mode has fewer colours than the stored image, it may not look very good at all. JPEGs are automatically colour quantized at load time. 24 bit - The red, green and blue components of the image are stored in separate buffers and will normally be displayed separately. @line 5 64 0 @label "Display" @{B}Display options@{0} Under the display options you can select how the loaded images should be displayed. @{B}After processing@{0} Display image after every successful image processing operation. @{B}Flicker@{0} Display greyscale images with mono flickering. @{B}Ordered@{0} Enable the ordered dithering when a mapped picture is displayed in a 16 colour mode or when a 24 bit picture is displayed in 256 or 16 colours. @{B}Preview@{0} Do quick preview first when drawing. @{B}Center image@{0} Images are drawn centered on the screen instead of in the upper left corner. @{B}Scrollable view@{0} If a drawn image is larger than the screen, this will allow it all to be viewed by moving the mouse. @{B}Aspect ratio setting@{0} Using 'options/aspect' it is possible to tell MGIF that the pixels on your screen are not quadratic. The x/y ratio will be used when you rotate images or if you use the aspect scale function. You have to give the number of vertical pixels that corresponds to 100 horizontal. This number can easily be found by going into cut mode and measuring on the screen while you move the crosshair. @line 5 64 0 @label "F-S" @{B}Floyd-Steinberg dithering options@{0} The F-S error diffusion dithering can be improved by setting up and selecting a noise addition factor and a Laplace edge detection filter. These will not affect the image itself but the dithering process. The options will slow the F-S dithering down quite a bit. @{B}Laplace filter@{0} Helps to define hard edges in images by applying a Laplace filter. A quantity, Beta, is required. A value of one corresponds to a Beta of 0.25, a value of two corresponds to a Beta of 0.50 etc. The same effect can be had by giving a suitable matrix to the convolution function. @{B}Noise@{0} Adds noise. This can help in images which have artificial banding as a result of the dithering process. Input value is a percentage (0 to 100). @line 5 64 0 @label "Quantize" @{B}Colour quantize options@{0} The MGIF colour quantize routines (from the IJG libraries) uses two steps: - Select the n best colours, where n normally is the number available in the selected graphics mode. - Blend the colours with Floyd-Steinberg error diffusion dithering to make it look like a lot more of them are used. This does not use the same F-S code as the display algorithms, which is set up using another dialog. These steps can be selected individually using 'two pass' (If this is not selected, a default selection of colours is used.) and 'dither' options respectively. The colour selection is rather quick, but the F-S dithering is slow. Colour quantization is a very complex operation and it needs a lot of memory. The destination buffer and the extra screen will be used and destroyed. Read also about virtual memory and temporary files. @line 5 64 0 @label "Misc" @{B}Miscellaneous options@{0} @{B}RGB mode@{0} If this has been selected, all image manipulation functions will operate on all three RGB components (buffers). @{B}VDI colour order@{0} Some colour IMG files will get incorrect colours without this selected. @{B}UNDO enable@{0} Tell MGIF to start saving destination buffers before operations are performed. '@{"UNDO" link "Image menu" "Undo"}' can be used to restore the image. @line 5 64 0 @label "Help" @{B}Help@{0} Tell ST-Guide to display this manual. @endnode @node "Image processing operations" @{B}Image processing operations@{0} A rough split can be done between the operations that operate on the pixel level and those that operate on complete images. @{B}Pixel level operations@{0} A further split is in order here since some operations only depend on single pixels while others use several for each operation. I'll call the former mappings and the latter filters. @{B}Mappings@{0} When the change to a pixel only depends on itself and not on any of its neighbours a simple mapping, a table lookup, can be used to perform the operation. For all these functions MGIF does in fact calculate a table with entries for all 256 possible intensity values and then applies this table to all pixels in the image. The mapping operations in MGIF are found under the @{"point" link "Point menu selections"} menu. 'Combine' and 'Change type' from the @{"buffer" link "Buffer menu selections"} menu are also more or less mappings. @{B}Filters@{0} Filters depend on a surrounding of a pixel in some way. Many of the filters in MGIF use a 3x3 surrounding box, but some can use a box of any size you may wish. There is currently no support in MGIF for non-rectangular surroundings, but that's very seldom a problem. Unlike the mappings, the filter functions can not reasonably be calculated once and for all and then applied since they, as mentioned, depend on several pixels. For this reason these functions can often take a while to apply. Don't worry, though, you'll only have to wait more than a minute in extreme cases. Often ten seconds or less will suffice. Filters are often divided into linear and non-linear ones, depending on what kind of operation they do on the pixels involved. Normally you will have no reason to worry about that. The filter operations in MGIF are found under the @{"area" link "Area menu selections"} menu. @{B}Image level operations@{0} These operations do not bother themselves with the actual pixels at all, but rather with the image as a whole. The appearance of the image is changed while (almost) nothing is done to its content. The image level operations in MGIF are found under the @{"frame" link "Frame menu selections"} menu. 'Quantization' from the @{"image" link "Image menu selections"} should perhaps not be here, but I don't think it fits perfectly into any of my categories, so... @endnode @node "Configuration" @{B}Configuration@{0} Command line switches Environment Options file Shortcut file Startup files @endnode @node "Options file" @{B}Options file@{0} At startup MGIF normally reads the file MGIF.OPT from the current directory (this can be changed by the @{"-o switch" link "Command line switches" "options file"}). In this file, any @{"command line switches" link "Command line switches"} can be given. Everything in the options file will be interpreted as options, unless there is a leading '#' on a row, which signifies a comment. The position of a switch within a row is totally irrelevant. The supplied MGIF.OPT has a couple of default switches set and all the rest (that are useful in an auto-loaded options file) described but disabled by a leading '#'. Options given in a file like MGIF.OPT can be @{"written permanently" link "File menu" "Write configuration"} into the MGIF executable. @endnode @node "Shortcut file" @{B}Shortcut file@{0} All menu items in MGIF can be selected by keyboard shortcuts, if they are set up correctly. To make this feature as flexible as possible, all the definitions are read from the file MGIF.KEY at startup (this can be changed by the @{"-key switch" link "Command line switches" "key file"}). The supplied MGIF.KEY file defines a couple of default shortcuts and can easily be used as an example for customization. The important parts of a definition line in the file is as follows: - First 'word' to search for. - Second 'word' to search for (not needed). - Shift keys: c - Control s - Shift a - Alternate - Key A 'word' is either a single word or something between two double quotes. Normally only one search 'word' is needed. This would then be the text on the menu item in question. Sometimes that is not enough, since there can be multiple items with the same name in different menu positions. In those cases the second 'word' will be searched from where the first was found. The first should then be one found at such a place as to make the second one the correct. Any Control/Shift/Alternate combination can be given for a shortcut. An example: @{"Palette" ignore},Load csP It was not possible to give only 'Load' since that would have found the file load item first. By looking for '@{"Palette" ignore}' at the start of the search, the incorrect one is bypassed. The shortcut is set to Control-Shift-P. For the time being there is no way to use special keys such as 'ESC', 'F9', 'Help' etc as shortcut keys (950726). @endnode @node "Environment" @{B}Environment@{0} MGIF makes use of a couple of environment variables: MGIF_OPT - Options parsed as if given on the command line. TMP - A directory used for temporary storage. TEMP - If the above was not available. @endnode @node "Startup files" @{B}MGIF startup files@{0} When MGIF is run it normally tries to load the following files: 1 MGIFv5.RSC Normal GEM resource file 2 @{"MGIF.OPT" link "Options file"} Various setup values etc. 3 @{"MGIF.KEY" link "Shortcut file"} Keyboard shortcut setups. 4 MGIF.DTT Ordered dither matrices. 5 MGIF_FL.EXE Program code for self-running flicker files. The first one can be modified using any resource editor, with the same limitations as normally applies to such things. Number 2 and 3 can, and should, be modified to make MGIF behave in a way that pleases you. Number 4 can be modified, but I'd rather recommend creating a .DIT file (the kind used by 'GEMView' and 'Speed of Light') and load that instead. The 'GEMView' distribution contains (or at least used to) a FreeWare program for doing that. The last file should not be modified (unless you @{B}really@{0} know what you are doing). You can change where MGIF loads the last four files from using @{"switches" link "Command line switches" "Config files"}. @endnode @node "Definitions" @{B}Definitions@{0} Greyscale Mapped colour True colour (24 bit) Convolutions Unsharp masking Spatial frequency Histogram Palette Floyd-Steinberg Ordered dither Halftone @endnode @node "Greyscale" @{B}Greyscale@{0} Obviously an image that is represented in greyscales can have no colour whatsoever. For every pixel the intensity is stored as an eight bit value, 0-255. 0 is black and 255 is white. @endnode @node "Mapped colour" @{B}Mapped colour@{0} For an image that is stored in mapped colour mode, an eight bit value for each pixel is an index into a palette of colours. Nothing can be said from only the value. @endnode @node "True colour" @{B}True colour@{0} As the name suggests, this is the mode to use if you want to keep all the colour in an image. Normally eight bits per colour component (Red, Green and Blue) is deemed enough for lifelike reproduction, but that is not really true. Unfortunately, image file formats that can handle more than 24 bits per pixel are not very common. Since the three intensity values for every pixel use the same number of bits as for a greyscale one, true colour images are most often handled as three separate greyscale pictures. @endnode @node "Convolutions" @{B}Convolutions@{0} My Oxford Advanced Learners Dictionary suggests that a convolution is a twist or a coil, which is not much help, I guess. ;-) Fundamentals of digital image processing gives a formula, "the convolution of the input with the impulse response" for shift invariant systems, which probably won't help you any more.... Let's take a few examples instead: The blur function from the menu is rather simple to understand. Blur calculates the average value of, by default, the nine pixels closest to every point in the image and then replaces the middle pixel with that value. Part of the image: Average: 15 34 10 8 40 50 (15 + 34 + 10 + 8 + 40 + 50 + 4 + 20 + 80) / 9 = 29 4 20 80 The pixel value 40 is replaced with 29. The blur can be performed using a very simple convolution: 1 1 1 1 1 1 / 9 1 1 1 When a convolution of an image is done, every pixel and its eight neighbours are multiplied by the corresponding elements in the matrix and the results added up. The scaling factor (in this case 1/9) is then multiplied to the sum. Finally the result is written back as the new value for the middle pixel. If you try it, you'll see that doing the blur by using the convolution matrix will be @{B}much@{0} slower, but will give exactly the same result as the menu version. Exactly the same operation is performed, but the specialised blur can avoid all the multiplies, since they are all by the number 1. Now, if all that could be done with the convolution matrix was a slow version of blur, it would be quite useless. However, as you might have seen, there are a number of predefined convolution matrices that can be selected in the dialog. Some of these have almost understandable names, like high pass, while other have totally meaningless ones, like Sobel. There is a great deal of relatively difficult maths involved in creating some of these, but they can be used without any knowledge whatsoever, to create nice effects. The names like high pass and low pass refer to the same thing as they do in audio, namely filtering of frequences. In a picture these are called @{"spatial frequences" link "Spatial frequency"} and they are only slightly more complicated to handle than an audio signal. The complication is, of course, that pictures have two dimensions, while an audio signal has only one. Each line and each column in the picture can, however, be seen as a one dimensional signal. Now what does low pass mean in a picture? Well, a low pass filter removes high frequencies, which in an image is equivalent to hard edges. A black box on a white background is a typical hard edge situation. The edges of the box will be blurred if a low pass filter is applied to the image (Yes, blur is a low pass operation!). A high pass filter does exactly the opposite of the low pass, naturally. The hard edges will be preserved, but the soft ones will be suppressed. In the box case above, that would mean that only the exterior border of the box would be left! These filters are therefore used for edge detection. The blur filter was a simple example of a low pass filter, which can easily be adapted to be more useful. Consider the following filter: 1 1 1 1 12 1 / 20 1 1 1 The difference from the original blur is that the middle value, which is the one that will be multiplied by the pixel that is being checked (remember?) has been increased a lot and the scale factor reduced. Note that the sum of the original filter was nine and of this one is twenty, thus the scaling factor brings the total weight down to one. This is essential since a higher value would cause the whole image to become brighter and a lower one, darker. This new filter will still blur the image, but the increased weight of the middle pixel means that it will be more "important" than the surrounding ones. The result of this is a much more subtle blur, very useful for removing the dithering used in most GIF pictures for example. Experiment! Try all the filters on some image (with source and destination set to different buffers) and see for yourself what they do. Some of them blur, some enchance edges, some keeps only edges and some create nice effects (try the gradients). The total sum of the filters (nine and twenty above) can be interesting to change for effect. The easiest thing to do is to change the value of the middle matrix value. If a filter sum is zero, only a small portion of the image information (like the edges) will be kept. If you add one to the value in the middle, however, the complete original image will be added to that small part (think about it!) and conversely, sutracting one will remove the complete image data. The convolution is a very powerful function that can give very satisfying results without using anything other than the predefined matrixes from the dialog. An extra example, a Laplace convolution matrix: -1 -1 -1 -1 8 -1 -1 -1 -1 As you can see, the point being processed and the 8 points surrounding it cancel each other out if they have equal values (x) when added together: 8 * x + 8 * (-1 * x) = 0 The more the surrounding pixel values differ from the central one, the greater the result's difference from zero. The resulting image will have colors only where colors on the original change (test it!). 0 0 0 0 1 0 0 0 0 This is a matrix that won't change the image as the coefficients for the surrounding pixels are zero (test it!). Adding this matrix to the previous Laplace one will give you the original image plus the edge enhancement. -1 -1 -1 -1 9 -1 -1 -1 -1 With this your image will really get some edge. @endnode @node "Unsharp masking" @{B}Unsharp masking@{0} This is a general name for the process of subtracting a low-pass filtered image from its original, creating a sharpened image. In MGIF this currently has to be done in two steps: - Filter an image using whatever filter you like from the '@{"Area" link "Area ms"}' menu, for example a 5x5 blur. You'll often get interesting effects even from filters that are not in the least 'low-pass'. The destination buffer must not be the same as the source. - Use 'Combine' to subtract @{B}part@{0} of the filtered image from the original. Most of the time you want to make sure that the factors you multiply the source and destination image pixels by sum up to one. Otherwise the new image will be darker or brighter than the original. For example: Percent source dest dest = source * 2 - dest * 1 67 33 dest = source * 20 - dest * 19 51 49 dest = (source * 4 - dest * 1) / 3 80 20 If you're going to use non-integer factors it's a good idea to make the divisor separate, as in the last example. Otherwise you'll loose a lot of precision due to the way MGIF does the image combination. @endnode @node "Spatial frequency" @{B}Spatial frequencies in a picture@{0} Think about every line in the image as an intensity "wave". This is of course exactly what it is when the image is displayed on a monitor. Now, that intensity wave could look like the following: _______ _______ ______| |_______| |_______ (Should be a square wave) If the low value of that wave signified the lowest intensity level and the high level the brightest, that would show up on a perfect display as a number of clearly defined lines. Since no perfect display exists, they all have bandwidth limitations like audio equipment, the edges of the lines will be a bit softened. The images brightness "wave" has been low pass filtered! A normal monitor is quantized (scanlines) in the vertical direction, which means that there is no ordinary filtering taking place. Instead lines blend slightly with each other. This, however, does not stop us from looking at each column in the image as a brightness "wave" as well. @endnode @node "Histogram" @{B}Histogram@{0} The histogram of an image is a distribution curve showing how common the intensity values (or palette indeces) are in the given picture. This is unfortunately only available from the text interface in the current MGIF version. @endnode @node "Palette" @{B}Palette@{0} The palette is a kind of lookup table that holds the real colours of an image stored in mapped mode. For each colour index there are three eight bit intensity values. That is one each for the red, green and blue components of the colour. @endnode @node "Floyd-Steinberg" @{B}Floyd-Steinberg dithering@{0} This is the most common variant of error diffusion dithering. The idea behind error diffusion dithering is to calculate how large an error there is when a particular pixel is converted for display. That error is then distributed to neighbour pixels that have not yet been displayed. When the pixels are small enough (and packed close enough), the human eye will be tricked into seeing more different colours/greyscales. @endnode @node "Ordered dither" @{B}Ordered dithering@{0} A method for dithering where a pseudo-random matrix of values is matched with the the pixels' intensities in the image that is being displayed. This is a quick dithering method that is useful when the output media can display single pixels. A normal monitor is, such a device. @endnode @node "Halftone" @{B}Halftoning@{0} Halftoning of an image is done in exactly the same way as ordered dithering. The only difference is that the matrix used is not pseudo-random, but rather 'clustered' in a way. The reason for the clustering is that many hard-copy devices, such as printers and photo-setters are incapable of creating minimum size dots. @endnode @node "Algorithms" @{B}Algorithms@{0} Nothing here yet, unfortunately. The complex stuff from the manipulation tool descriptions will be moved here later. @endnode @node "Literature" @{B}Literature@{0} Gonzales and Wintz, Digital Image Processing. Lindley, Practical Image Processing In C. Burger and Gillies, Interactive Computer Graphics. Anil K Jain, Fundamentals of Digital Image Processing. Foley/Van Dam, Computer Graphics: principles and practice. Baxes, Digital Image Processing: principles and applications. @endnode @node "Authors" @{B}Authors@{0} Information about email addresses, other software written, favourite books and movies, life story etc is included when available. ;-) Current developer Johan Klockars Original author William Rosenkranz Minor contributors Howard Chu (original overscan support) Frank M"hle (original JPEG support) Klaus Pedersen (original flicker screen code) Eero Tamminen (various GEM stuff) @endnode @node "Special thanks" @{B}Special thanks@{0} To the Free Software Foundation, the Independent JPEG Group and Ron Reyner of Canada. @endnode @node "The future" @{B}The future@{0} This text describes some of the future plans for MGIF. They may all or none come true. Of the four things mentioned in priority order in the documentation for MGIF 4.2, only number two and number four were implemented in this version, more than two years later... If you have any ideas of your own, or feel strongly about some of those outlined below, please send @{"mail, email or phone" link "Johan Klockars" "email"}. @{B}Planned improvements to MGIF@{0} - The point menu will be completely replaced by a dialog where the user can change an images intensity values in a number of ways. A first version of the dialog is already in the resource, but there is quite a bit of code that remains to be written. - Some day MGIF will be able to draw images in windows. That will most likely be after the next point has been addressed, though. - MGIF is going to be somewhat rewritten to run as two or more tasks, side by side, under MultiTOS/MiNT/MagiC and communicating via pipes. - More Falcon030 DSP support will be added for operations where it's useful. These include GIF loading and dithering. - Batch processing of images will be implemented. - A programming language will be included for flexibility (and fun ;-). - A module concept will be implemented to enable simple extensions to the MGIF framework. Modules from the GIMP, an image manipulation program for UNIX, will most likely be supported. - Operations on individual bit planes will be supported. - A more flexible memory handling scheme, capable of any number of buffers, will be implemented. @{B}Other ideas@{0} - Since the largest part of MGIF is quite independent of the underlying operating system, a port to MiNT with X or perhaps Linux has been considered. @endnode @node "Bug report form" @{B}Bug report form@{0} If you find any bugs in MGIF I'd very much like to hear about them. There's of course no need to use this form, but it mentions a few points that might be useful to me when I try to eliminate the problem. MGIF version: MGIF mode used: MGIF switches: Computer type: Graphics card: Operating system: AUTO folder programs: Accessories: Other info: Type of bug: MGIF debug messages: @endnode @node "Questionary" @{B}Questionary@{0} I'm always looking for people's opinions on MGIF. A lot of the features in version 5 would never have been implemented if it weren't for the feedback I got from users (MGIFv5 would probably have been released a year earlier, though, but that's another matter ;-). First, it has been pointed out to me that the name MGIF has become very misleading. This is of course true, but I'm not so sure it's a good idea to change it anyway. What do you think? Any name suggestions? The person who submits the name I decide is best will receive the latest version of MGIF on a signed disk. ;-) Some things that it would be interesting to hear your views on are: - GEM interface - Text interface - Manual - Colour support - Graphics card support - Image processing features - File type support - OS support Any other ideas or thoughts? Also take a look at 'The future'. @endnode @node "The text interface" @{B}The text interface@{0} For MGIFv5 very few changes have been made, so far, to the old text interface. It does not even support some of the newer features. Since some people, however, want to run MGIF from a command line, for example when running MiNT without GEM, I have kept and slightly extended the text interface. The available short commands are given below. Where applicable the actual command that is executed is named. Those commands, and a few other that are otherwise only accessible through the GUI, can be used with the 'x' (extended) command. a all Operate on all three RGB components br brighten Brighten image bl blur Blur image cp copy Copy between source and destination buffers cu cut Cut out part of an image co contrast Contrast expand image d test Create a test image (linear shade) e enlarge Enlarge image two times f file Save flicker image g beta Set laplace beta for F-S draw hi histogram Draw the histogram of an image he equalize Equalize the histogram of an image i inverse Make a negative image j again Do last operation again k quantize Quantize an RGB image l log Logarithmic intensiy scaling of an image mi mirror Mirror an image me median Median filter an image n noise Set noise for F-S drawing o toggle Toggle source buffer p shtrue Draw RGB image q quit Exit this image r rotate Rotate image s shrink Shrink an image two times t threshold Threshold an image u dtoggle Toggle destination buffer v convolve Apply a convolution filter to an image w what Show some information about the buffers x extended Do extended operation, that is give command y size Scale image z zoom Zoom part of an image ? help Show help screens ESC exit Quit MGIF SPC draw Draw destination RET show Show a drawn image when possible Apart from the commands given above, the following are also available using 'x'. cnvspace (Internal MGIF operation) sourcen Set source buffer destn Set destination buffer drawn Draw given buffer oil Do oilpaint 'filtering' lmin Do local minimum 'filtering' lmax Do local maximum 'filtering' sub Subtract source image from destination border Add borders to an image chgtype Change the type of an image pixelize 'Pixelize' image gamma Do gamma correction shear Shear an image tile Tile an image to a given size tileize Make an image perfectly tileable @endnode @node "Frequently Asked Questions" @{B}Frequently asked questions@{0} (Last updated 960706) This text mentions a few things that are not covered in the rest of the documentation for MGIF or that have caused problems for beta testers earlier. If you can't find the answer to a question here, please contact the @{"author" link "Johan Klockars"}. Any questions of general interest will be added to later revisions of this text. 1. Why doesn't quantize work? Currently the destination buffer must be set to 0 for the quantize function to work. You must of course have three buffers (red, green and blue) as well. 2. Why doesn't the oil paint function work? I've not yet implemented the oil paint function for source == dest. This makes it impossible to use the automatic RGB processing, so for that you have to do: source = buffer 0, dest = buffer 3, do oil paint, copy dest->source source = buffer 1, - " - source = buffer 2, - " - 3. I've just loaded a 16 colour picture, but the image looks very bad in 16 colour mode. What am I doing wrong? Earlier versions of MGIF always used ordered dither when displaying images in 16 colour mode, even if the image only used 16 colours. In most cases that's not so anymore, but MGIF can still be fooled. The ordered dither display does not work very well with images that have few colours. If you turn off the dither using the 'ordered' switch under the 'options/display' menu, the picture will most likely look much better. 4. What mode should I use for image processing? The mapped colour mode is not very useful for image processing purposes. The scaling, median filter and oil paint functions work, but not much else. Greyscale and 24 bit mode are both fine, but all functions will be three times as fast in greyscales, naturally. If you're not planning on keeping the colour, use greyscales all the time. 5. Can MGIF do the nice relief (stone carving) effects I've seen in other programs? Yes, embossing (which is the normal name for that) can easily be done using the convolutions. Select any filter but those in the first two columns and put 128 as bias value. Take a look under 'Tutorials' for examples on use. 6. What are convolutions? Convolutions are general digital filters. The ones included in the dialog are low pass, edge enhancment and edge detection filters. Take a look under 'Tutorials' for examples of use. 7. What file format does copy/paste and UNDO use? It's an internal uncompressed format that can't be read by anything other than MGIFv5. 8. How do I save in the .FL format? You must have drawn the image in flicker mode. Then the normal save dialog can be used. For the text interface, refer to the 4.2 docs. 9. Can I change dither matrix after MGIF has started? Yes, simply load a new .DIT or .DTT file with 'load file'. 10. Can MGIF scale an image to fit the screen directly upon loading? Yes, take a look in the 'options/load' dialog. You can also have automatic scaling to fix the aspect ratio. 11. Is it possible to scroll around an image larger than the screen? MGIF will happily scroll around an image of any size by redrawing newly exposed areas. There is no real 'virtual screen' built in, but you can run MGIF together with any of the usual ones, such as BIGScreen or the one included in BlowUP030. 12. Why does my Falcon lock up when I try to use the convolution or median filter functions? The supplied MGIF.OPT file sets the -dsp switch to enable the use of the DSP chip in the Falcon and the -dhs switch to force hand- shaking to take place when the CPU and DSP exchanges data. The communication is faster without the -dhs switch but there may be problems, especially with accelerated machines. If you have not disabled -dhs, the last resort would be to disable -dsp to turn off DSP usage. That should never be necessary, though. @endnode @node "Tutorials" @{B}Tutorials@{0} There are some examples of image processing in the EXAMPLES directory which are well worth looking at (and trying out for yourself). The ideas below are just as useful. It has come to my attention that not many people use the convolution filters supported by MGIF. This is quite a pity, since they can be used for a lot of interesting effects. I've now included a small GIF file, INTEL.GIF, which can be used for experimenting. Not that you can't use your favourite GIF, but this one is small (thus fast loading and processing) and simple enough to make the filter effects very obvious most of the time. A few things to try out: Lmin/Lmax - Try with some values around 3-30. Nice, eh? What would this look like with a more normal image? Low pass - The low pass filters do very much the same thing as 'Blur' in the menu (in fact the first of the low pass filters is exactly the same as a 3x3 blur). These are not very useful on the INTEL.GIF image, but can look good on normal ones. If a GIF looks grainy due to previous dithering, try low pass. High pass - High pass filters used for contour extracting or emphasis. Laplace On a normal image it may not be very clear what's going on, Gradient but with INTEL.GIF it should be quite obvious. Sobel If you change the 'Bias' from 0 to 127, most of these ... filters will give very nice stone-carving look-alikes. Experiment with the directions. @endnode @node "William Rosenkranz" @{B}William Rosenkranz@{0} The text was written in answer to an email by me (Johan), so it might be a little incoherent. That is not Bill's fault in any way. The questions/suggestions are marked with a '-' at the beginning. - School and work experience. At 40 years old, I barely remember school... :-) I am employed as Senior Systems Engineer at Convex Computer Corp. Convex makes and sells supercomputers. I live in the Detroit, MI (USA) area. Basically, my job is to help sell these systems. I do product presentations, benchmarks, write proposals, etc. Actually very little programming on the job, other than tuning code (mostly Fortran) for vector supercomputers and more recently scalable parallel processors (MPPs) which Convex makes. The latter are based on HP PA-RISC processors. - Descriptions of any other programs etc you have written. On the Atari, mostly Unix-like tools (nroff, man, manpager, etc.). I rarely write much code from scratch these days since I have so little time. When I do, it is usually little utilities for work. All my other programming is porting/fixing/tuning customer Fortran codes. - Favourite books, movies and TV series. I read a lot of history. Mostly ancient history (like bronze-age Greece) and the Renaissance (planning a trip to Florence this summer). I am also attempting to write a book. Films are one of my main interests. I like just about anything, if it is well done or has some merit (in my eyes). I don't watch much TV outside of CNN for news. I.e., I am not a good sales target for 500-channel TV! I am also trying to write a screenplay, though this is going very slowly because of a hectic work schedule (I'll be on a plane to Chicago in a couple of hours, for example). @endnode @node "Johan Klockars" @{B}Johan Klockars@{0} Email, WWW, snail mail and telephone numbers can be found at the very end of this text. @{B}Other programs I've written and projects I'm involved in@{0} The major software mentioned here can be accessed from my WWW/ftp site. For other things, please contact me directly. Before I took over the development of MGIF, I worked for quite some time on a Sinclair QL emulator for the Atari ST series. There had been no development of that since '91, but after MGIF v5.00 was released, I picked it up again. The emulator, QLem, works rather nicely on the 68000 Ataris and, since the recent v1.45, Falcons. The latest version may actually work on TTs as well, but I have no way of testing that. QLem also works to some degree under STonX (an ST emulator for any machine running UNIX and X) v0.6.5, but there are major problems. Currently I'm involved in an internet project where we plan to, eventually, bring a DOOM(TM) compatible game to the Falcon030. The game will of course not be an exact copy of DOOM, but we intend to make it compatible with all the WAD files out there. Right now (960706), the latest publically released binary version is 2.14alpha (the released sources are at 2.06alpha). It allows you to run about in texture mapped 3D at a very reasonable frame rate even on a VGA monitor, if you lower the resolution a bit from the default 320x200. All walls, floors and ceilings are mapped with the correct textures, including transparent ones, and the light effects are nearly perfect. Running in Falcon TC mode, it looks a lot better than the original, IMHO. The working name of the project is 'BAD MOOD' for reasons that may not be entirely obvious. ;-) Further, I've of course written some small utilities when I needed them (for example a Falcon SCSI DMA tester) and fixed compatibility problems with programs I wanted to run on my Falcon. An example of the latter is my fix for running the Magnetic Scrolls adventures with the new graphics interface in any resolution on the Falcon. @{B}Education and work@{0} I spent almost five years at Chalmers University of Technology in Gothenburg and left with an MSc in Computer Science and Engineering. Currently I'm working on my PhD in what might perhaps be called something like 'VLSI clocking strategies and synchronization'. Technically I'm still at Chalmers, but the main part of my work is done at a very small university in Trollhattan, some 70-80km to the north of Gothenburg. Since my studies and research work are interleaved with tutoring (20%), I don't expect to have finished my thesis until the turn of the century (given that I'm allowed to continue, that is). @{B}Hobbies@{0} For the past 16 years programming has been my major hobby, but I also read quite a lot of fiction (see below), play the trumpet in a big band and cornet in a brass band. Last autumn ('95) I took up fencing, which is even more interesting than I thought it would be. Try it! @{B}Favourite movies and TV shows@{0} I've never had cable TV, so I've not had the 'opportunity' to watch much TV at all (we only have three channels on the air in Sweden). A couple of favourites I could mention would be: Twin Peaks Winds of War (?) and the sequel War and Remembrance Red Dwarf I do @{B}not@{0} like 'Hillstreet Blues', 'Baywatch' or 'Dallas', though I must admit I watched the latter for years. Regarding movies, I think I'm about average. I'm not one of those who look down on the Hollywood productions, in fact most of my favourite movies were indeed made there. Some favourites are: Dances with Wolves Last Action Hero Prince of Thieves Star Wars Willow Beauty and the Beast (Disney) Braveheart @{B}Favourite books@{0} I've always read quite a lot of fiction of various kinds. I'm no speed reader of any kind, though, but read purely for relaxation. Still, I normally end up at about fifteen thousand pages per year. The all time favourite authors/books are at the top in the categories below. The rest are in no specific order. Fantasy/Science fiction @label WoT Robert Jordan - The Wheel of Time This is without a doubt @{B}the@{0} best fantasy books ever. So far there are seven books in the series, totalling well over five thousand pages, and the story is not even getting close to the end. According to Mr Jordan himself: 'Some more books. Not many.' One of the more active newsgroups on Usenet is dedicated completely to the discussion of these books: rec.arts.sf.written.robert-jordan That there is still a lot to discuss after several years says a lot about the complexity and depth of the plot... By the way, the reason for the name of my WWW/ftp site is in here. ;-) Stephen Donaldson Really good author who writes both fantasy and science fiction. Most of his books are @{B}very@{0} dark, but 'Mordant's need' is good proof that he can write more cheerful stuff as well. Melanie Rawn - Dragon Prince/Star A very good six book tale. Quite a bit different from any other fantasy I've read. Tad Williams - Memory, Sorrow and Thorn A very good four book series. L E Modesitt I don't know what more he's written, but the first five books about the 'Recluse' world are very good. Techno thriller Tom Clancy Extremely good author. Everything he's written, apart from the recent 'Op-center' books (which I don't believe he has actually written), is very good. A couple of movies starring among other Harrison Ford have been made from the books. Horror Dean R Koontz Most of the books are very good, but should perhaps not really be called horror. Stephen King If I'd been able to come up with another category for the above, King would have been a clear first in horror. I've not read any of the earlier books (Carrie, Dead Zone etc), but most of the later ones are very good indeed. @label "email" @{B}Contact addresses@{0} The email addresses are in order of preference. If a letter to the first one bounces, try the second and so on. Email: rand@cd.chalmers.se johan@rand.thn.htu.se klockars@thn.htu.se johank@ce.chalmers.se WWW: http://rand.thn.htu.se (possibly with a /~johan at the end in the future) Snail: Johan Klockars Skaragatan 8d S-415 01 Gothenburg SWEDEN Telephone: +46 (0)31-844481 +46 (0)520-475056 (work) @endnode @node "Frank M”hle" @{B}Frank M”hle@{0} No text supplied yet. @endnode @node "Howard Chu" @{B}Howard Chu@{0} No text supplied yet. @endnode @node "Klaus Pedersen" @{B}Klaus Pedersen@{0} No answer to my email yet. @endnode @node "Eero Tamminen" @{B}Eero Tamminen@{b} Look at my WWW page 'http://proffa.cc.tut.fi/%7Et150315/' for information on what I have done besides help out a little with MGIF. A couple of examples of what I have done in C: PUNSSi Hi-rez two player game. A kind of a ball game ;-). GRAAVi -"-. Two space ships duelling. Wyrms -"-. The well-known worm game with bonuses etc. Clac A programmer's function calculator. Cli and GEM versions. Grafix A 'graphics made easy' library for GEM & X. XimgView XimgSnap Various Atari ports (mostly straight compilations) of unix stuff, among other Mutt Editor 3.5, X games... @{B}Education and work@{b} I'm at the Technical University of Tampere studying computers. At the moment I haven't got any work experience, but I have programmed two years in basic and two years in C. @{B}Hobbies and intrests@{b} My main hobbies are reading and programming. Occasionally I'll do sports (cycling, badminton, table tennis, throwing a boomerang ;). I'm also interested about cooking although I do it seldom. My favorite wheather is a summer drizzle (I got hayfever, so I'm a bit allergic to what sunshine cooks up on the fields ). I like Jazz, Bach, Progressive rock etc. Some could describe my character as a cynical romantic :-)))). @{B}Favourite books, movies and TV series@{b} Well, I don't look much TV but the list of my favorite authors / books is long. Mostly the books are science fiction, but I read a bit of Fantasy and mainstream too. Contrary to most of my friends I like short stories and poems too. IMHO a 'serious' (sci-fi) book that doesn't give a new view angle into some old, common or uncommon subject, isn't worth much. Good sci-fi should also have humor, suspence etc. ingredients that mark good literature. Here are some of the authors I like and, in case I remember it, the favorite book by them: (@{B}Ladies@{b} first) Ursula Le Guin 'The left hand of darkness' Doris Lessing 'A man and two women' (non Sci-Fi) Octavia Butler 'Xenogenesis'-trilogy Sheri S. Tepper Connie Willis James Tiptree Jr. Johanna Sinisalo Short stories Philip Farmer 'Strange relations' (short stories) Philip K. Dick Lots of books that makes you doubt reality... Frederik Pohl 'Space Merchants', lots of others John Sladek Biting satire Stanislaw Lem thoughful satire Harry Harrison Space opera (got me into Sci-Fi) Arthur C. Clarke Realistic, near future sci-fi Hal Clement, Fred Hoyle Realistic (hard) sci-fi John Varley 'The persistance of Vision' Douglas Adams Has his own style of humor... Bruce Sterling 'Globalhead' (short stories) Robert Holdstock Mythology Ian Watson David Brin Clifford Simak Alfred Bester Orson Scott Card John Brunner Brian Aldiss Kurt Vonnegut 'Slaughterhause 5' Anthony Burgess Terry Pratchet Humorous fantasy C. S. Lewis Christian allegories (eg. 'Narnia' for children) Isaac Asimov Some good ones, most are too content-less Ray Bradbury Short horror / sci-fi stories Roald Dahl Short horror stories + numerous other (not quite so well-known) sci-fi, techno-thriller, detective story (Sara Paretsky) etc. writers. And in case someone hasn't yet noticed that comics is an art form here's a short list of my favorite european comics authors (in no particular order): Fred, Hugo Pratt (especially 'indian Summer' made in colloboration with Milo Manara), Didier Comes (just look at the art), Joakim Pirinen, Mezieres & Christin (sci-fi), Charlier & Giraud (western, under alias 'Moebius' produces also sci-fi), Enki Bilal (sfi-fi & history), Neil Gaiman (Sandman), Tardi, Tove Jansson (Moomin Trolls ;-), Franquin. USA, Japan and South America also got some good ones... - Eero t150315@cc.tut.fi @endnode @node "The Graphical User Interface" @{B}The Graphical User Interface@{0} I have not yet decided what more should go here. Two short things regarding customization: - MGIF does not give you any flying or windowed dialogs. That is entirely on purpose since not everyone likes the same type of handling. Install for example 'Let'em Fly' and 'mdial' instead and configure them however you want. - Since there are, as far as I know, no external programs available that can give you menu shortcuts, MGIF uses a very simple to use scheme for that. Take a look at 'Shortcut file'. @endnode @node "File handling" @{B}File handling@{0} A file can be loaded into MGIF in two different ways. The first is by giving the name on the command line, or by moving a file onto the MGIF program icon. The second is to use the @{"'Load'" link "File menu" "Load file"} menu selection. Whatever the method, there are a couple of things that decide how MGIF loads the file and what it does with it afterwards. The image is currently always loaded into the first buffer and the rest of the buffers can be destroyed. If there is enough memory, the other buffers are normally safe, though. The @{"load dialog" link "Options menu" "Load"} handles all settings associated with image loading. The most important selection is the file load mode: Greyscale Images are converted to greyscales directly upon loading and are stored internally in that format only. Mapped colour Images are stored with their palette and original number of colours. If the loaded image was a 24 bit one, for example a JPEG, it will be quantized before it's stored. True colour (24 bit) The red, green and blue components of the loaded image are stored separately in the first three buffers. @endnode @node "Display handling" @{B}Display handling@{0} To draw the current source image, use 'Draw source', and for the current destination image, 'Draw destination'. Most drawings that take a while can be interrupted by a press on the left mouse button. The @{"display dialog" link "Options menu" "Display"} handles all settings directly concerned with the display. Parameters for the Floyd-Steinberg dithering are set in the @{"F-S dialog" link "Options menu" "F-S"}. Greyscale A greyscale image is normally first drawn quickly and then improved using Floyd-Steinberg error diffusion dithering. When flicker mode is selected, a greyscale image is first drawn very quickly using an @{"ordered dithering" link "Ordered dither"} algorithm and then redrawn using Floyd-Steinberg error diffusion dithering. Mapped colour If @{"ordered dither" link "Ordered dither"} is selected, MGIF will do what it can to make the image appear nicely on screen. When fewer colours are available for the screen than is used in the image and the resolution is low (as on an ST/E), this will normally not look good. If @{"ordered dither" link "Ordered dither"} is @{B}not@{0} selected, MGIF will not do anything special if there are fewer screen colours than image ones and the display is likely to look very bad indeed. True colour (24 bit) If you are in the Falcon true colour mode and have an image with red, green and blue components in the first three buffers (for example after having loaded an image in 24 bit mode), you can draw the image in full colour using 'Draw RGB'. The image will first be drawn quickly and then improved using Floyd-Steinberg error diffusion dithering for each of the RGB components. @endnode @node "Command line switches" @{B}Command line switches@{0} A lot of things can be set up using switches, short text commands, given on the command line when MGIF is started. The switches can be given in a number of other ways as well, as described under 'Configuration'. A good many things that can be set via the switches can also be controlled from within the GUI. A short summary of the most important switches All available switches are given below. Some are described in more than one place. @{B}Memory related@{0} -alt Use alternate memory for buffers. Alternate memory is normally TT RAM or virtual memory. This can be changed from the startup dialog. -l n Set the amount of memory that MGIF leaves to TOS on startup. This value (in kbyte) is simply subtracted from the available amount before showing the value in the startup dialog. -p0 n Set the amount of memory (in kbyte) used for the first buffer explicitly. -p1 n Same as above, but for the second buffer. -pm n Set the maximum amount of memory (in kbyte) to be used. This is the value that will be shown in the startup dialog. This can be changed from the startup dialog. @{B}Buffer related@{0} -CC Tell MGIF to reserve three source buffers. This is needed for 24 bit colour images. Also sets load mode to 24 bit colour. -px Tell MGIF to use a single buffer, or rather no destination buffer since three soure buffers will be allocated if 24 bit colour mode is selected. This can be changed from the startup dialog. @{B}Image load related@{0} -aco Tell MGIF to do aspect correction on load. This can be changed from the 'options/load...' dialog. -C Set load mode to mapped colour. This can be changed from the 'options/load...' dialog. -CC Set load mode to 24 bit colour. This can be changed from the 'options/load...' dialog. -dog Tell MGIF to put a greyscale version of a loaded image into the last buffer. This can be changed from the 'options/load...' dialog. -fit Tell MGIF to size images to fit on screen on load. This can be changed from the 'options/load...' dialog. -g Set load mode to greyscales. This can be changed from the 'options/load...' dialog. -gf2 Tell MGIF to always use the newer GIF decoder. This may improve loading speed 5-10%. Perhaps this should be the default, but that has not been decided yet (950226). -jpd Tell MGIF to use the DSP JPEG loader JPEGD from Brainstorm if it's available. Due to possible legal problems the code for this is not included in any distributed versions. -shw Tell MGIF to show an image directly after loading it. This can be changed from the 'options/load...' dialog. @{B}Screen related@{0} -asp Set aspect ratio in percent. This is the number of vertical pixels that are eqivalent in length to 100 horizontal ones. This can be changed from the 'options/display...' dialog. -ttg Tell MGIF to switch to TT grey mode. @label "interface options" @{B}Interface related@{0} -dsu Tell MGIF to skip the startup dialog. -s Tell MGIF to wait on a keypress before returning. -w Tell MGIF to wait on a keypress on startup. -bsy Tell MGIF to display the busy bee cursor when appropriate. @{B}Display related@{0} -f Turn on flicker display. This can be changed from the 'options/display...' dialog. -mfl Tell MGIF to try to achieve stable flicker draw even when running under multitasking. Currently uses supervisor mode. -mvx n Set the movement speed in percent of normal for scrolling -mvy n view. Values below 100 will not work correctly. X and Y axis movement can be controlled individually. -scr Turn on scrollable normal view. This can be changed from the 'options/display...' dialog. -sng Tell MGIF to use the normal system screen for drawing. If this is not selected another screen is allocated. This can be changed from the startup dialog. -vdi Tell MGIF to use only the VDI for drawing. Only works for an 8 bit graphics mode (256 colours/greys). Do @{B}not@{0} use this if you don't have a graphics card, it will be a @{B}lot@{0} slower. If -vdq works on your card, use it instead. It's much faster. -vdq Tell MGIF to use only the VDI for drawing, but cheat a bit. This may or may not work depending on the graphics card used. If you don't get a correct display, use -vdi instead. @label "Config files" @{B}Configuration file related@{0} -opt dir Load the configuration files from a specified directory. @label "options file" -o fname Load another options file than the default 'MGIF.OPT'. @label "key file" -key fname Load another shortcut file than the default MGIF.KEY. @label "undo file" -u fname Set the UNDO file. Without this, the UNDO switch below will not work. -d fname Load another dither file than the default MGIF.DTT. Both .DIT and .DTT files are possible. -exe fname Load another flicker code file than the default MGIF_FL.EXE. @label "startup options" @{B}Startup mode related@{0} -fl Just show the .FL files given on the command line. -gem Run MGIF as a GEM program. -m Do montage with .FL pictures. -fl must be used as well. -ss Tell MGIF to do a @{"slide-show" link "Slide-show"} of the images on the command line. The images are displayed once and at maximum speed. -ssf fname Use wildcards from the given file for slide-show. Separate timings may be used. -ssl Tell MGIF to loop a slide-show indefinitely. -ssr Tell MGIF to randomize the slide-show. -sst n Tell MGIF to do a timed slide-show as above, but with a given minimum time of n seconds between the displayed images. -tos Run MGIF as a TOS/TTP program. @{B}General setup@{0} -aft Tell MGIF to draw the destination image after successfully applying an image processing operation. This can be changed from the 'options/display...' dialog. -col n Set the number of colours used for JPEG load and quantize. This can be changed from the 'options/quantize...' dialog. @label "handshake" -dhs Tell MGIF to use handshaking for all communication with the DSP chip in the Falcon030. This is turned on in the supplied MGIF.OPT, but since the DSP operations are faster without it, try turning it off. For most machines everything should be fine without it. -dpi n Set the printer dpi used for the IMG save. This can be changed from the dialog that pops up when you save in IMG format. -dsp Tell MGIF to use the DSP in the Falcon030 whenever possible. -fss Turn on F-S dithering for IMG save. This can be changed from the dialog that pops up when you save in IMG format. -n Turn off dithering for colour quantize and JPEG load. This can be changed from the 'options/quantize...' dialog. -smt Turn on @{"smooth" link "Smooth scale/rotate"} scaling/rotation. This can be changed in the dialogs of affected operations. -svd Set default buffer to save to be the destination one. -udo Tell MGIF to save the destination buffer before each operation that may change it. 'UNDO' is enabled in the menu. The -u switch above must be used as well. This can be changed from the 'options/misc...' dialog. -x Turn off two pass colour quantize. This can be changed from the 'options/quantize...' dialog. -xx Turn on two pass colour quantize. This can be changed from the 'options/quantize...' dialog. @{B}Various of little use@{0} -c Tell MGIF to not copy from logical to physical screen. Very useful if MGIF is run in text mode from a window, such as under MiNT/toswin. -h Tell MGIF to show a help screen. -i Only inquire about file information. No loading is done. -pp Tell MGIF to optimize buffer allocations for image processsing. Does nothing much. -v Turn on verbose mode. Of some small use for text mode, possibly. -vers Tell MGIF to show version information only. @{B}Test related@{0} (only given for completeness) -aln Tell MGIF to do word alignment of buffers even on '030s. -dbg Tell MGIF to write debugging information to the screen. -ST Tell MGIF to use colours on a Falcon as if it were an ST. @{B}Unimplemented or out of use@{0} (only given for completeness) -b Tell MGIF to run in batch mode. This is not yet implemented. -N Tell MGIF to use NTSC colour equations. This is not used any longer. -p Use a MiNT pipe for command input instead of the usual text mdoe interaction. This is not yet implemented. @endnode @node "Distribution" @{B}Distribution@{0} MGIF is FreeWare, not PublicDomain, which means that the @{"author" link "Johan Klockars"} retains all copyrights. See the end of this text for main distribution channels. - No distribution for profit is allowed. Software distribution centers operating more or less without profit, like most PD libraries, are allowed to treat MGIF as they do any other FreeWare software they carry. For CDROM distribution, contact the @{"author" link "Johan Klockars"}. There is not likely to be any problem. - Modification of or use of MGIF code in other programs without the explicit permission of the @{"author" link "Johan Klockars"} is forbidden. Such permission @{B}will@{0} be given for other FreeWare (or similar) programs when asked for. Naturally the origin of the code should be mentioned in the program and documentation. - For inclusion of MGIF code in ShareWare or commercial software, something surely can be arranged. The parts of the code that were written by other people may pose a problem of course, but that will be handled if the need arises. - MGIF versions marked as beta releases in the 'About' dialog should not be distributed anywhere. New versions of MGIF will in the future appear more often. There will certainly not be another two and a half year gap. On the other hand there will never be another update as major as v5. From time to time the latest MGIF version will be uploaded to the most common ftp sites on the internet, from where it can be spread according to the rules above. There may be uploads to some BBSs as well. As has been the case for about a year now, the very latest versions of MGIF will always be available from the WWW/ftp site given below. If a release there is marked in the 'About MGIF' box as a beta version, it should not be widely distributed. There is most often a good reason for the beta status. The main MGIF ftp site is: rand.thn.htu.se (@{"The Dragon Reborn" link "Johan Klockars" "WoT"}) Since 950719 the preferred way to fetch MGIF is via the newly installed WWW site at the same address: http://rand.thn.htu.se If you can't find a pointer to MGIF on the top level HTML page (I might decide to change that), just append /~johan at the end of the address. If you don't have internet access, but still want to get hold of the very latest version, take a look at 'Registration'. @endnode @node "Slide-show" @{B}Slide-show@{0} Apart from a simple, wildcard driven, sequential display of images given from a command line (-ss), MGIF can also do the following. - Display all images for a given minimum time (-sst n) - Loop slide-show indefinitely (-ssl). - Show images in random order (-ssr). - Read wildcards with separate timing data from a file (-ssf fname). Most of the above are very straight forward, but some more information can be found where the @{"switches" link "Command line switches" "startup options"} are described. There are no restrictions on the combinations of switches other than that a random slide-show is always indefinite. Pressing 'q' or ESC will quit the slide show as soon as possible. Any other key will advance to the next image. @{B}Slide-show file@{0} A slide show file should consists of lines with a time (in seconds) and a wildcard, for example as below. 5 h:\gifs\p*.gif 2 c:\silvghst.tga 10 l:\pictures\bird*.* Note that when a slide-show file is used, no wildcards from the command line are processed. @endnode @node "Using MGIF" @{B}Using MGIF@{0} A hypertext manual like this can easily cover a lot of topics without making it apparent how to find the relevant texts. To help out with that this section was written. Feedback from the users will determine what goes here in the future. - Image processing operations - Slide-show - General tips @endnode @node "General tips" @{B}General tips@{0} Various - GIF images are often dithered. If you want to manipulate one in greyscales or 24 bit colour, it's almost always a good idea to apply some kind of smoothing to it first. The ordinary blur works rather well, but has a tendency to make the image look a bit too unfocused. A better idea is to use a @{"convolution" link "Convolutions"} filter such as: 1 1 1 1 8 1 (Blur has a '1' as the middle value) 1 1 1 / 16 This is still a kind of blur, but the middle pixel has been weighted so that it's relatively more important. Some useful switches -dsu If you never change anything in the startup dialog it can be skipped completely. -svd If you're doing image manipulation it's often a good idea to have MGIF default to saving the destination buffer. @endnode @node "Registration" @{B}Registering MGIF@{0} MGIFv5 represents a lot of work (well over half a year full time on my part alone) over several years, and many users have told me how much they appreciate the program. With the latest release MGIF is still FreeWare, but I would like you to register the program to give me an idea of how many people are actually using it. @{"Send me" link "Johan Klockars" "email"} your details on a postcard, in a letter/email, give me feedback, send candy, flowers, money (any currency), floppy disks, hardware... ;-) Please, register your details with me. Users in the UK can register with Denesh Bhabuta. A minimum contribution of 6 Pounds sterling is suggested, to register. Please, make cheques, Eurocheques and postal orders payable to Denesh Bhabuta and send to: CyberSTrider 203 Parr Lane Unsworth Bury Lancashire BL9 8JW UK Denesh will then send you a disk with the latest version of MGIF, along with a selection of other programs he supports. Upgrades are also available through Denesh, by sending him an SSAE and a blank formatted floppy disk. @{B}Do the right thing... Register.@{0} @endnode @node "What's new?" @{B}Changes/improvements in MGIF 5.10@{0} @{B}Changes/improvements in MGIF 5.01@{0} - Due to special code for the Falcon030 DSP, some operations have been speeded up @{B}very@{0} much: convolution filtering (10x) median filtering (5x) Please, read about @{"handshaking" link "Command line switches" "handshake"} for optimum performance. @endnode @node "Smooth scale/rotate" @{B}Smooth scaling and rotation@{0} For some image processing operations, MGIF is capable of producing much better results if you're prepared to wait a little. It does this by interpolating between and/or averaging over pixels. This process needs one or more multiplications per pixel, so it can be quite slow. The results are usually well worth it, though. @endnode