Atari Image Manager

Search
Votes / Statistics
Rating 
N/A
Hits: 476
Downloads: 203
Votes: 0
My Atarimania
Bookmark and Share
Comments (0)

Screenshots - Atari Image Manager

Atari Image Manager atari screenshot
Atari Image Manager atari screenshot
Atari Image Manager atari screenshot
Atari Image Manager atari screenshot
Atari Image Manager atari screenshot
Atari Image Manager atari screenshot
Atari Image Manager atari screenshot

Information - Atari Image Manager

GenreGraphics - Picture EditingYear1988
LanguageCompiled CPublisher[no publisher]
DeveloperDelft University of TechnologyDistributor-
ControlsKeyboard, MouseCountryNetherlands
Box / InstructionsEnglishSoftwareEnglish
Programmer(s)

Verbeek, Pieter / Weber, Igor
de Vries, Robert / Groen, Frans

LicensePD / Freeware / Shareware
SerialST TypeST, STe / 1MB
ResolutionLow / HighNumber of Disks1 / Double-Sided / HD Installable
Dumpdownload atari Atari Image Manager Download / MSAMIDI
Protection

Instructions - Atari Image Manager











                     A I M   T U T O R I A L


                               by


                  Tom Hoeksma and Ad Herweijer



                 Delft University of Technology
                   Faculty of Applied Physics
                    Pattern Recognition Group
                          Lorentzweg 1
                         2628 CJ  DELFT
                         the Netherlands
Introduction

The  image processing software package AIM (Atari Image  Manager) 
has  been  developed at Delft University of Technology  by  Frans 
Groen  (the 'image processor') and was adapted for the  Atari  ST 
computer  in cooperation with Robert de Vries (the  GEM  program-
mer). Both were members of the Signal-/System-techniques Group in 
the  Faculty of Applied Physics,  Frans as a senior staff  member 
and Robert as a graduate student. Recently, Frans changed jobs to 
become  professor  of Applied Informatics in  the  University  of 
Amsterdam.

AIM  is designed to be an entry level 'appetizer' for the art  of 
image   processing.   It  gives  the  interested   layperson   an 
opportunity   to  acquaint  himself  with  the   techniques   and 
terminology  used  in  this   dynamic  field.   The   experiments 
described  may  be  regarded  as a lower bound  of  what  can  be 
accomplished  with  AIM,  the upper bound being  limited  by  the 
user's imagination only. 

This  tutorial is not a full course on digital image  processing. 
Such courses are frequently organized by the Pattern  Recognition 
Group.  For course information,  please contact the Secretary  of 
the  Pattern  Recognition  Group,  Faculty  of  Applied  Physics, 
Lorentzweg 1, 2628 CJ  Delft, the Netherlands, Phone 015-781416.

Note  that the operations used in the examples and demos cover  a 
minor part of AIM's capabilities only.  A comprehensive  descrip-
tion  of all the operations available is given in a  file  called 
AIMANUAL.DOC.  Like this tutorial it is contained in a compressed 
file (DOCS_IMS.ARC), which can be found in the folder COMPRESS on 
the distribution disk (together with a decompressing program).

Image processing is not particularly difficult;  many people will 
have   had  their  first  image  processing  experience  in   the 
photographic darkroom.  Note,  however, that AIM, being dedicated 
to  digital image processing,  requires some basic  knowledge  of 
digital systems.  So those of you who until now have successfully 
avoided  learning  about  bits,  bytes  and  binary  numbers,  be 
prepared to face the unavoidable!  The 15 minutes or so spent  on 
reading about these concepts will be richly rewarded by a  better 
understanding of AIM's operations,  if not by the deep admiration 
of your environment for the newly acquired vocabulary.

AIM is a result of many years of research and development in  the 
Pattern Recognition Group.  Many of the image processing routines 
were contributed by (a.o.) Gert van Antwerpen,  Frans Groen, Piet 
Verbeek,  Ben  Verwer,  Lucas  van Vliet  and  Igor  Weber.  This 
introduction was written (if not compiled from existing texts) by 
Tom Hoeksma and Ad Herweijer.

Previous versions of AIM have already extensively penetrated  the 
Atari ST community.  However,  as the documentation supplied with 
those  first  public  domain versions  was  rather  limited,  the 
exploration  of  the software has been a mere  'image  processing 
adventure'  to most of the 'early birds'.  The authors hope  that 
this introduction,  together with the related examples and  demos 
included  on the disk,  will enable all prospective users  (early 
birds and newcomers alike) to better understand what  was,  resp. 
is going on.

Feedback  plays an important role in the effective use  of  image 
processing  as well as in  software  development.  Therefore,  we 
invite you to send your eventual comments and suggestions to:

     Prof. dr. ir. F.C.A. Groen
     c/o Delft University of Technology
     Faculty of Applied Physics
     Pattern Recognition Group
     Lorentzweg 1, 2628 CJ  DELFT
     the Netherlands



WHAT CAN WE EXPECT OF IMAGE PROCESSING?

Maybe  you  have  already had some experience with  AIM  or  seen 
somebody  else work with it.  You may have  wondered,  then,  how 
image  processing could make features appear in the display  that 
weren't  there  before  the operation.  Text that  at  first  was 
unreadable,  suddenly could be read easily;  freckles in a girl's 
face,  that  didn't show in the original display,  could (to  her 
distress!) be counted after some appropriate keystrokes. You were 
perhaps convinced to have acquired a little magician,  hidden  in 
that tiny floppy disk.

Be warned, however! Image processing can never reproduce features 
of  the  original image,  that somehow have  been  lost.  So,  be 
prepared  for  surprises,   but  don't  expect  miracles!   Image 
processing  can  enhance  particular details  in  an  image,  but 
usually other details will have to be sacrificed.

If 'A picture is worth a thousand words', image processing allows 
you  to  arrange  those  words to make  the  picture  reveal  its 
(secret) 'stories'.  But remember:  one picture's thousand  words 
are  different  from  another's.  Every story  will  inherit  the 
characteristics of the picture it was extracted from.  The art of 
image  processing  is:  to make the picture tell  the  one  story 
that's useful to you.



STAGES IN AN IMAGE PROCESSING APPLICATION

In  almost  every image processing application we  can  recognize 
some stages, that eventually lead to the final result: recording, 
preprocessing,  segmentation, postprocessing, analysis and inter-
pretation. 

Probably  the  most  important  stage is  the  recording  of  the 
original picture.  As stated above, information that gets lost in 
the recording process can never be recovered. For the recording a 
video-camera  is  required,  capable  of  converting  the  light, 
reflected  from the object,  into an electrical  signal.  As  the 
video signal cannot be read directly by the computer, this signal 
must be sampled and digitized and the digital information must be 
transferred in an orderly manner to the computer's  memory.  This 
is  done  by  a special piece of  hardware,  a  so-called  'frame 
grabber'.  Various frame grabbers are available for the Atari ST. 
In  the  Pattern  Recognition Group monochrome  and  color  frame 
grabbers  have  been  developed  that  eventually  will  be  made 
commercially available.

After  the  image  is  stored in the computer  it  must  be  pre-
processed.   Here  the  user  tries  to  enhance  or  filter  out 
particular   wanted   resp.   unwanted   features,   to   satisfy 
requirements of further analysis.  Examples of preprocessing  are 
the  correction  for  changing  grey  values  in  the  background 
(shading),  suppressing  noise,  determination  of edges  in  the 
image, etc.

In order to be able to determine properties of single objects  in 
the image, these objects must first be made detectable. If a grey 
value  image  contains  dark  objects  on  a  light   background, 
segmentation  can,  for instance,  result in a binary image  with 
white objects in a black background.

Postprocessing  can  improve  the  result  of  the  segmentation. 
Examples  are  the morfological  (binary)  operations.  Holes  in 
objects can be closed, edges peeled off, etc.

In  the  analysis stage,  measurements can be  performed  on  the 
segmented objects. Examples: area, perimeter, curvature.

In  the interpretation stage the results of the measurements  are 
evaluated.

An 'intelligent robot' in a factory,  that has to make a decision 
on  whether he 'sees' a nut or a bolt,  must be programmed to  go 
through  all  stages mentioned here.  Programming  such  a  robot 
requires  much intuition on how computers 'think'.  An  important 
requirement for the programmer is to be able to forget the way he 
would  do  the job himself!  He must belong to the new  breed  of 
'computer psychologists'.



SOME TERMINOLOGY USED IN IMAGE PROCESSING


Images and displays

In  image  processing we must distinguish  between  'images'  and 
their  'displays'.  In  this context we define an  image  as  the 
information  that  has  been  stored (as  1's  and  0's)  with  a 
particular  filename  in the computer's memory or on  a  magnetic 
disk. A display is the representation of such an image on a video 
screen or -as a 'hardcopy'- on a piece of paper.

An important property of an image is its information content. The 
information  in  an  image depends on  the  presence  of  details 
(lines,   edges,   intensities,   colors,  etc.).  Moreover,  the 
information  content  determines the amount  of  computer  memory 
required to store the image.

Note that it's one thing to store an image accurately,  but  that 
it's another to display it with full conservation of information!    
The display hardware (video controller,  monitor,  printer, etc.) 
determines the degree to which the information in an image can be 
observed  exactly.  In image processing,  there is a tendency  to 
make  the  information content of stored images higher  than  can 
actually be displayed.  This reduces the chance that the  effects 
of  rounding errors in intermediate results will deteriorate  the 
final  display.  (Moreover,  RAM-chips and floppy disks are  much 
cheaper  than  display hardware!).  AIM,  for  example,  uses  64 
kilobytes  (kB)  of RAM for the storage of  images,  whereas  the 
Atari  hardware  can  only handle 32 kB for the  display  of  one 
screen (either monochrome or color).

The basic element of an image is a pixel (picture element). To be 
observable on a display,  a pixel must be attributed a grey value 
or color information.
 
As  an example,  consider the Atari ST.  In the monochrome  (high 
resolution)  mode  the Atari ST supports the display  of  2  grey 
values only.  Each pixel (the Atari screen has 640*400 =  256,000 
of  them!)  has  a number ('0' or '1') associated  with  it  that 
determines whether it is to be black or white:  there is  nothing 
in between. We will call this a 'binary display'.

Note  that terms like 'black',  'white' and 'grey value'  in  the 
context  of  monochrome  displays actually  refer  to  the  color 
emitted by the phosphor used in the Cathode Ray Tube (CRT) of the 
display device (amber, green, white, etc.).

Color  images generally consist of  three  sub-images,  displayed 
simultaneously. The sub-images represent the decomposition of the 
color  image into three monochrome images (red,  green and  blue, 
respectively).  The (visual) addition of the sub-images  restores 
the original colors for the observer.  Sub-images may be  binary, 
but  usually they have more than two grey values.  An  AIM  color 
image,  for example,  has 256 possible grey values for each  sub-
image.

In the color modes (medium-,  resp.  low-resolution),  the ST  is 
capable of displaying 8 grey values for all three primary colors. 
Consequently,  there are 8*8*8 = 512 different combinations, each 
combination representing another color. Such a group of available 
colors is called a palette.  The palette represents all  possible 
states that an individual pixel may have.

Each combination of red,  green and blue intensities is perceived 
with   a  particular   brightness,   the   luminance.   Luminance 
information  can  be used for the display of color  images  on  a 
monochrome monitor; AIM allocates an extra sub-image for it.

If  a pixel has equal intensities for red,  green and blue  ,  it 
will display the color 'grey'.  Thus,  in the palette of the med-
res and lo-res color modes there are 8 levels of grey,  extending 
from black (R=G=B=min=0) to white (R=G=B=max=7).  Very often  the 
property of a color monitor to display grey values (as opposed to 
just  black  or  white) is more important to the  user  than  its 
capability of displaying colors!

As  we have seen above,  in binary images each pixel can  have  2 
grey  values  only.  We say that each pixel has 1  'bit'  (binary 
digit) of information associated with it.  Equivalently, in color 
images the information per pixel is higher;  AIM uses 32 bits  of 
color and grey value information. We will return to this shortly.


Pixels and neighbors.

An  AIM image can be visualized as a 'checkerboard' with  256*256 
or  128*128  square  fields (for  monochrome  and  color  images, 
respectively).  Each field corresponds to a pixel carrying 8 bits 
(= 1 Byte) of grey value information or 32 bits (= 3+1 Bytes)  of 
color and luminance information.

Pixels,  being  neatly  arranged in a square raster of  rows  and 
columns,  have neighbors. The number of neighbors of a particular 
pixel  is  referred to as its  connectivity.  On  a  checkerboard 
neighbors can be defined as having either just sides, or sides as 
well as corners, in common with the reference pixel. Depending on 
these  definitions the connectivity of pixels on a square  raster 
is 4 or 8.  Pixels sometimes are arranged hexagonally.  In such a 
'honeycomb configuration' the connectivity is 6.

Image  processing  routines  can be divided  into  three  groups: 
point,  local  and global operations.

Point  operations use the information of one single pixel in  the 
input  image  to calculate the result for a  corresponding  pixel 
(not necessarily the same) in the output image. An example is the 
INVERT operation,  where the intensity bit for every pixel in the 
(binary) image is reversed.

In  a  local  operation the result for one single  pixel  of  the 
output  image  is  determined  by  the  original  pixel  and  its 
neighborhood.  An  example of such an operation is  Lmin  ('Local 
minimum'),  where the output pixel gets the minimum grey value of 
its  neighborhood  (including itself) in the  input  image.  This 
operation  extends dark parts in the image.  The neighborhood  of 
interest can often be specified (i.e.  1*3,  3*3,  5*5, etc.). In 
AIM the neighborhood can only be an odd number.

In  global operations the result for one single output  pixel  is 
derived  from the information of all pixels in the  input  image. 
One example of a global operation is the Fourier transform,  used 
to determine periodic features in the image.  Fourier  transforms 
are not supported in this version of AIM.

PROPERTIES OF THE ATARI ST VIDEO HARDWARE

Almost all of AIM's images will probably have to be displayed  on 
a video monitor (either monochrome or color).  However perfect an 
image may be,  it will eventually have to pass the bottleneck  of 
the  computer's  video display hardware.  Much of the  effort  of 
programming  AIM  has  been  devoted  to  overcoming   inevitable 
limitations  of  a computer's display  hardware.  For  a  correct 
interpretation of the results,  we will extend briefly into  some 
details  of the hardware used by the Atari ST for the control  of 
displays:  video display memory, video controller and monitors.


The video display memory.

The  central  part of the display hardware is the  video  display 
memory. Independent of the resolution chosen (lo-, med-, hi-res), 
the Atari ST allocates 32 kB (= 256,000 bits) of RAM for  storage 
of the information of one screen.

In  the  high  resolution mode 640*400 = 256,000  pixels  can  be 
displayed,  leaving just one bit/pixel for grey value definition. 
As  a result only binary images can be displayed on a  monochrome 
monitor.

As  explained above,  a color image requires more than 1  bit  of 
memory per pixel.  You may wonder how the ST manages to attribute 
more  than 1 bit to a pixel if in the hi-res mode  (1  bit/pixel) 
all the available 32 kB is used up already!

The  answer  to this question can be intuitively found  from  the 
terms  'medium-resolution'  and 'low-resolution'  for  the  color 
modes. In these modes, the spatial resolution of the hi-res mode, 
640*400  =  256,000 pixels,  is sacrificed in order to  give  the 
pixels more luminance (monochrome displays on color monitors)  or 
color  information.  By  reducing  the resolution  to  640*200  = 
128,000 (med-res) or 320*200 = 64,000 pixels (lo-res), the pixels 
can be attributed 2 or 4 bits for luminance or color  definition. 
This allows palettes of 4 or 16 colors to be defined in the  med-
res or lo-res mode, respectively.

Thus, the video display memory may be thought of as representing:

           1 binary image  of 640*400 pixels (hi-res)
           2 binary images of 640*200 pixels (med-res)
           4 binary images of 320*200 pixels (lo-res).

The  color of a particular pixel is determined by the  (weighted) 
bit-values of the 2/4 corresponding pixels in the binary images.

The video controller.

The next stop on our journey from the video display memory to the 
monitor screen is the video controller.  This chip takes care  of 
all the housekeeping, required for conversion of the bytes in the 
video  display memory to 'real world' voltages,  compatible  with 
the intensity input(s) of the monitors.

Since  in the hi-res mode the pixels contain just 1 bit  of  grey 
value  information,  the  video controller  incorporates  a  very 
simple 1 bit 'A/D converter' to generate the intensity signal for 
the monochrome monitor.

We have seen that, as a consequence of the limited 32 kB of video 
display  memory,  in the med-res and lo-res modes the pixels  can 
have  just 2/4 bits of color information.  This would  allow  for 
palettes of 4/16 colors.  Fortunately, Atari has made the ST much 
more versatile,  generously including three 3 bit A/D  converters 
in the video controller. Thus, for each primary color there are 8 
grey values available, allowing a palette of 8*8*8 = 512 colors.

If  the  pixels contain information for the  definition  of  4/16 
colors  only,  how does the video controller know what colors  to 
choose  from the palette of 512?  The answer is in the  operating 
system;  it  has  facilities to define a  'sub-palette'  of  4/16 
colors.  Each  color in the sub-palette represents  a  particular 
combination  of  grey values for red,  green  and  blue  .  These 
combinations are stored in a lookup table of 4/16  elements.  The 
2/4 bit color information for each pixel refers to a position  in 
this  lookup  table and the video controller  converts  the  RGB-
combination stored there into the corresponding intensity control 
voltages.

When  a color monitor is used to display a monochrome grey  value 
image,  the operating system automatically loads the lookup table 
with  4/8 (why not 16?) grey combinations for med-res  or  lo-res 
displays, respectively.


The monitors.

Basically, a video monitor consists of a CRT with some electronic 
circuitry  to  control the deflection and the  intensity  of  the 
electron  beam.  A monochrome monitor uses one electron  beam.  A 
color monitor requires three beams, one for each primary color.

For  intensity  control  the monitors have 1  or  3  inputs.  The 
voltage on these inputs determines the intensity of the lightspot 
on  the  screen.

Note,  that  in principle both monochrome and color monitors  are 
capable  of displaying grey values:  there is a continuous  range 
over which the intensities can be controlled. However, as we have 
seen,  the other display hardware reduces the number of  possible 
grey values and/or colors considerably.

The  deflection  of  the electron beam(s) is  controlled  by  the 
monitor itself;  for synchronization it needs a triggering signal 
('sync')  which  is produced by the video controller  and  simply 
added to the intensity signal(s).



AIM IMAGES AND THEIR DISPLAY ON THE ATARI ST MONTORS

The AIM workspace allows simultaneous storage of 4 images:  A, B, 
C  and  D.  Each image (monochrome or color) occupies  64  kB.  A 
monochrome image (stored on disk with the extension .IM) consists 
of 256*256 pixels,  having 8 bits of grey value information (i.e. 
256 grey values possible).  Color images (extension .COL) consist 
of  128*128 pixels,  having 24+8=32 bits of color  and  luminance 
information.  For  the display of color images AIM  supports  the 
ST's  lo-res  mode  only (320*200 pixels with  a  palette  of  16 
colors). 

You  may  have wondered why AIM uses 4 Bytes of  information  for 
pixels  of  .COL  images.  Wouldn't a color  image  be  perfectly 
defined by just using 1 Byte for each color sub-image? The answer 
is: yes, it would. For technical reasons, however, we have chosen 
to  add  en  extra byte for  luminance  definition.  This  format 
allows, for example, the monochrome display of .COL images.

We  will  discuss  the  display of AIM  images  in   4  different 
situations:

    Monochrome (.IM) images - monochrome display (hi-res)
    Color (.COL) images     - monochrome display (hi-res)
    Monochrome (.IM) images - color display (lo-res) 
    Color (.COL) images     - color display (lo-res)


Monochrome (.IM) images - monochrome display (hi-res).

As  an extension to our checkerboard model we might  introduce  a 
stack of 8 checkers placed on each field, representing the 8 grey 
value bits of the corresponding pixel. A white checker represents 
a '1',  a black one a '0'. Depending on its position in the stack 
the weight of a white checker (i.e.  the contribution to the grey 
value) is 128, 64, 32, 16, 8, 4, 2 or 1. Thus, if the lower three 
and  the  upper two checkers are white,  the  corresponding  grey 
value is (128+64+32+0+0+0+2+1=) 227.

In  our  model we have 8 horizontal planes of  256*256  checkers, 
each plane contributing its own weight to the total  image.  Note 
that  each plane itself actually corresponds to a  binary  image, 
hence  the name:  bitplanes.  The upper plane (b1) is  the  least 
significant   bitplane,   the  lower  plane  (b8)  is  the   most 
significant one. In AIM the 8 bitplanes of a grey value image can 
be processed as 8 separate binary images.  Bitplanes of one image 
can be copied (command:  BCOPY) to one or more arbitrarily chosen 
bitplane(s) of an other.  Using this facility, a grey value image 
can  be  used as a (temporary) storage for 8  independent  binary 
images.

As determined by the ST hardware,  in the hi-res mode only binary  
images can be displayed. AIM circumvents this limitation by using 
a  trick  called  sigma-delta  technique:  the  256  grey  values 
available in the image are represented as well as possible by dot 
densities  in the display.  This yields a 256*256*1  bit  display 
with a reasonable suggestion of grey values to the human eye.

A  special  situation  occurs if we want  to  process  monochrome 
pictures  from  the  drawing  package  DEGAS.   Monochrome  DEGAS 
pictures  (extension .PI3),  being binary 640*400  pixel  images, 
cannot be processed directly by AIM.  When read from a disk these 
images  are converted to a 320*200 pixel image with 5  levels  of 
grey information.  The 640*400 pixels are grouped in 320*200 non-
overlapping  2*2 fields.  Each pixel in the final  320*200  pixel 
image  is attributed the average grey value of the  corresponding 
2*2 field:

                0 pixels white  ->  grey value:   0
                1 pixels white  ->  grey value:  63
                2 pixels white  ->  grey value: 127
                3 pixels white  ->  grey value: 191
                4 pixels white  ->  grey value: 255

Subsequently, the converted DEGAS images get the same sigma-delta 
treatment  as  the  regular .IM images for the  display  of  grey 
values.  Note  that  in this process  information  is  lost;  the 
resulting  image  has  less  than 320*200*3  =  192,000  bits  of 
information (originally: 256,000 bits). Consequently, even though 
AIM can re-convert (loosing information again!) these images back 
to  DEGAS format,  the original pictures can never  be  recovered 
completely.


Color (.COL) images - monochrome display (hi-res).

For the display of a .COL image on a monochrome monitor, only the 
128*128  pixel  luminance  sub-image  is  used.  The  sigma-delta 
technique  again  converts  this  luminance  information  to  dot 
densities.


Monochrome (.IM) images - color display (lo-res).

Monochrome  (.IM) images have 8 bits (256 levels) of  grey  value 
information.  When an (.IM) image is read from disk in the lo-res 
mode,  AIM  will load the 16 color palette with the maximum of  8 
levels   of  grey  and  applies  the  sigma-delta  technique   to 
interpolate between these 8 levels.


Color (.COL) images - color display (lo-res).

For  the  display  of .COL images in the lo-res  mode  AIM  first 
determines  an optimum palette of 16 colors from the  palette  of 
256*256*256 colors available in the original image. The 8 bits of 
luminance information is not used.

The palette for a particular screen is derived from the image  in 
the active window only;  this may not be the optimum palette  for 
other images displayed simultaneously.

In this mode color pictures from the DEGAS and Neochrome  drawing 
packages  (extensions .PI1 and .NEO,  resp.) can be read  by  AIM 
also.  Again,  size  reduction (to 160*100  pixels),  grey  value 
attribution  and  the sigma-delta technique are applied  for  the 
processing and display of these images. 


IMAGE PROCESSING CAPABILITIES OF AIM

The image processing software package AIM has been written in the 
C  language,   using  the  Mark  Williams  C-compiler.  It  makes 
extensive use of the GEM window structure for the user  interface 
and the display of images.  AIM allows processing and display  of 
monochrome,  binary  and  grey value images as well as  of  color 
images.  It  has  an interface (via the Atari ST's  DMA  bus)  to 
monochrome  and color frame grabbers,  developed in  the  Pattern 
Recognition Group.


The user interface.

Image processing operations can be chosen from drop-down  menues, 
using dialog boxes,  as well as by typing the appropriate command 
in the command box.  In any case the commands are transferred  as 
strings   by  the  Window  Management  System  to   the   Command 
Interpreter.  Many  of  the AIM commands cannot be  invoked  from 
drop-down menues. They will be designated by an asterisk (*). 

The command interpreter starts the image processing  routine.  It 
is not necessary to type the complete command name; any number of 
characters that doesn't give ambiguities will do.

Sequences of commands may be combined in a command file or macro. 
Command files can be nested to 16 levels.  They are automatically 
created  by  activating the Logging feature;  any  operation  you 
perform after 'Logging' is checked, will be logged. Macros can be 
saved to disk for re-use. The extension for the filename is .AIM. 
A  macro  is  executed by typing the  name  (without  extension), 
preceded by the character '@'.  Clicking the menu-entry Macro and 
the  name  in  the  dialog box will  do  the  same.  Pausing  the 
execution  is possible by hitting the Esc-key.  Proceed with  the 
macro  by hitting Return or stop by clicking in  the  appropriate 
box.

The commands in the Command Window can be edited  simply.  Delete 
and backspace work like in most wordprocessors. Control-X deletes 
a whole line.

All  characters  typed after a star (*) will be  ignored  by  the 
command interpreter and thus can be used for comments.

Typing  a question mark (?) and  will display a  list  of 
available operations.  The syntax and a short explanation for the 
commands  can  be found in  Help-files.  Choose  HELP!!!  in  the 
Utilities menu. Note, however, that this version (2.5) of AIM has 
been  extensively revised.  Many operations have been  added  and 
some  of  the  existing operations allow more  parameters  to  be 
specified  than those given in the current Help-files and  dialog 
boxes.  Fortunately,  all operations are upward compatible.   The 
AIMANUAL.DOC   in  the  COMPRESS  folder  contains   an   updated 
description of all the available operations. 


EXAMPLES AND DEMOS

The  examples  on  the AIM disk  are  self-explaining.  The  only 
prerequisite  is  a  reasonable  understanding  of  the  previous 
chapters.  Because  the  disk space was limited,  we  could  only 
include  some of the most relevant  examples.  Consequently  they 
cover  just  a  few  of the  possible  operations;  most  of  the 
operations will have to be explored by yourself!

The  commented  command files EXAM1.AIM ->  EXAM5.AIM  have  been 
included so that you can check your manually entered exercises. 

Besides  the  prepared examples three extra demos  (macros)  have 
been  included  on  the  disk:   DEMOCER.AIM,   DEMOHFE.AIM   and 
DEMOSCH.AIM. They contain some operations and strategies that may 
be  of  interest  to  you after  having  completed  the  examples 
successfully.

Finally two exercises are added to (self-)test your abilities. If 
things go totally wrong,  don't feel embarrassed by peeping  into 
the  macros  PRAK1.AIM  and  PRAK2.AIM;   they  contain  possible 
solutions for these exercises. The exercises are compressed files 
and can be found in the folder COMPRESS.

In  case  you  missed a point:  in a  grey  value  image  'black' 
corresponds with a value 0, 'white' with a value 255. In a binary 
image  (or a bitplane of a grey value image) these values  are  0 
and 1, respectively.

All examples and exercises will work in both modes,  lo-res color 
and hi-res monochrome. For binary operations a monochrome monitor 
is recommended. Some demos are more impressive in color, though!


Example EXAM1.AIM

Operations used: Histogram, Equalize

First we will retrieve the image MOON.IM.  Click the entry  'Read 
Image'  under the 'File' menu.  The defaults in the selector  box 
that  pops up ('Window:  A' and 'STANDARD')  are  acceptable,  so 
click  'OK' (or hit the Return key).  Those of you who  prefer  a 
command  line interpreter might as well type in 'read A'  instead 
of using the mouse.

Next a GEM 'ITEM SELECTOR' appears.  Choose 'MOON.IM' and after a 
few seconds a picture appears in Window A,    that shows the foot 
of  moonlander  surounded  by  moondust.  You  will  agree  that, 
normally,  you  would  throw such a picture in the  trashcan  and 
probably declare the mission to the moon a flop. AIM can help you 
deal with such frustations!

Just  to get a feel of the power accumulated in that  tiny  3.5", 
try the operation 'Equalize' under the menu 'GreyOps'.  Choose  A 
as the input image and B as the output. Looks better, doesn't it? 
Remember,  the information was already in the image; even without 
AIM the mission to the moon wasn't in vain!  But the  application 
of AIM certainly adds to the succes.

To  understand what has happened to the original image,  try  the 
entry  'Histogram' under 'Utilities'.  This will show a graph  of 
the  frequency  of  occurrence of a  particular  grey  value  (or 
rather:  a  small  range of grey values) in  the  image,  plotted 
against the grey value.  Frequencies are plotted vertically, grey 
values (0 -> 255) horizontally.  The histogram indicates that the 
grey  values  in  the  original  image  were  concentrated  in  a 
relatively small range (centered around grey value 50).

From the histogram we can conclude that the grey scale from 0  to 
255 has not been used efficiently;  nearly all pixels have a grey 
value between,  say,  25 and 75. The result is that, in a way, we 
are looking at the printing on a toy balloon;  only if we inflate 
the balloon some of the smaller details will show.  If somehow we 
could  stretch the original grey value range,  so that  25  would 
shift to 0 and 75 to 255, the same effect might be imposed on our 
moon image. Throwing away the ranges 0 ->25 and 75 -> 255 doesn't 
do much harm, because little information will be lost.

Equalization  is the air pump that inflates a grey  value  range. 
Unlike   an  air  pump  (and  the  suggestion  in  the   previous 
paragraph!)  it does so intelligently.  That is,  the  stretching 
effect on a particular range of grey values depends on the height 
of the histogram for that range.  Ranges with high values in  the 
histogram will be expanded at the cost of the compression of less 
prominent  ranges.  Note,  that there may be multiple  peaks  and 
valleys  in the histogram.  To see what we  mean,  determine  the 
histogram  of image B and compare it with the original  one.  The 
frequencies  (vertical  lines) are divided more evenly  over  the 
available range of grey values.
Ranges  with  high  frequencies of  occurrence  in  the  original 
histogram  have  been stretched and those  with  low  frequencies 
compressed. If you are not completely satisfied, perform the same 
operations on the image TRUI.IM,  which has multiple peaks in the 
histogram.

Equalization  is a nice example of  image  processing:  important 
features  (in this case grey value ranges) are emphasized at  the 
cost  of  less  important  features.   Yet,  in  this  particular 
operation no information is lost;  a 'de-emphasis' procedure (not 
available in AIM) could restore the original image.

Hint:  if  you want to get rid of the histogram in  a  particular 
display, use 'Gdisplay' in the Utilities menu.


Example EXAM2.AIM

Operations: Gradx, Grady, Enhance

Read the image TRUI.IM in (the default) Window A.  This image has 
become  a  kind of reference for many groups  involved  in  image 
processing.

Perform the operation 'Gradx' in the GreyOps menu. Accept all the 
defaults proposed by AIM. Worry about the Multiply and Add values 
later, or better still, experiment with them.

The  Gradx ('gradient in x-direction') operation  determines  the 
rate  at  which  grey values change in  the  original  image  and 
attributes corresponding grey values to the pixels of the  output 
image.  An  output  pixel  gets a grey  value  according  to  the 
formula: 

       grey-out = (gradient-in) * Multiply/1024 + Add.

This  operation  shows  vertical edges  in  the  image.  An  edge 
corresponds to a step in grey value.  Note the effect on edges in 
the girl's hat.

Now perform Grady.  This time send the output to Window  C.  Note 
the result for horizontal edges (mouth, eyebrows, etc.).

A  related  operation,  which  is generally  used  to  sharpen-up 
pictures   is  the  Enhance-operation  (in  menu   GreyOps).   It 
determines  the  second derivative (in both  directions)  of  the 
grey-values in the input image.  Like Gradx/y it emphasizes  high 
frequencies in the image.  High frequencies occur at sharp edges. 
Try  the Enhance filter on the original TRUI.IM.  and  enjoy  the 
improvement. But what did we do to her eyes? Seems we created her 
contactlenses...


Example EXAM3.AIM

Operation: Median filter

Read image BNOISE.IM.  This image has intentionally been degraded 
by  'shot  noise'.  This  type  of  noise  occurs  often  in  the 
transmission of signals.  Some of the pixels differ very much  in 
grey  value from the surrounding pixels.  In this case  they  are 
white. We want to use filtering to remove the noise.

Usually  it  is difficult to predict the  effects  of  filtering. 
Various parameters must be specified,  requiring much  intuition. 
Try, for example the entry 'Filter' in the GreyOps menu!

A  good  filter for the problem of shot noise  is  the  so-called 
median filter.  In this operation AIM determines the grey  values 
in  3*3 neighborhoods for each pixel in the  input  image.  These 
values are sorted in tables with 9 entries. The 5th entry in each 
table (the 'median') becomes the grey value of the  corresponding 
output pixel.  The grey value of a shot noise speck is likely  to 
be in the extremes of the tables in which it appears, and thus it 
will be removed.

Perform  the operation 'Median' in the GreyOps menu.  Only a  few 
stubborn  noise  specks will survive.  They may be removed  by  a 
repeated application of this filter.


Example EXAM4.AIM

Operations: Copy, Lmin, Lmax, (*)mindev, Gdisplay

Once more we call on TRUI.IM;  read it from disk.  We will need a 
second copy of this image in Window B. There are two options:
a. Read the image again from disk and have AIM put it in Window B
b. Use 'Copy' in menu GreyOps to copy Window A in Window B.

Note  that there is a 'Copy' entry in the BinOps menu  too.  This 
binary  operation  copies only bitplanes,  as opposed to  a  grey 
value copy,  which copies all 8 bitplanes of an image at once.

If all went well, you now have the fabulous Trui twins on screen. 
The  first  operation to be performed is 'Lmin'  in  the  GreyOps 
menu.  This  operation looks for the lowest grey value in an  n*n 
neighborhood  (n to be specified by the user) of the input  pixel 
and attributes it to the corresponding output pixel.  This filter 
has  a tendency of expanding darker areas in the  image.  Try  it 
with n=9 and put the result in Window C. Experiment a little with 
different values for n. Observe the effects on nostrils and eyes! 
In  any case end with a 9*9 Lmin-ned TRUI.IM in  Window  C.

Next apply the 'Lmax' filter on Window A.  Choose n=9 and put the 
result  in Window D.  This filter expands lighter area's  in  the 
image. We hope that until now you acquired enough intuition to be 
able to predict the effect:  gone are those nostrils and gone  is 
that mouth in the 'lighter shade of pale' that surrounded them.

But now the real image processor arises.  We are going to use  an 
operation  that uses three input images:  (*)mindev  C,D,A.  This 
operation  compares corresponding pixels (i.e.  pixels  with  the 
same  coordinates)  in the original image (A) and the  two  other 
images  (C and D).  The output pixel gets the grey value  of  the 
corresponding pixel in C or D,  depending on which one of the two 
is  closest to the grey value in A.  Big deal,  but what  is  the 
effect?

Let's  try  it  first.    The  (*)mindev  ('minimal   deviation') 
operation cannot be invoked from the menu,  so we have to type it 
in de Command Window: type mindev C,D,A . The result will 
be shown in Window A.  Compare it with the original image,  which 
is  still luring in Window B.  Apparently the edges in the  image 
(cheeks,  hair) have been sharpened. The net effect of Lmin, Lmax 
and mindev is, that near edges there is a backlash in grey value. 
In  other  words,  grey  values are  reluctant  against  changes; 
changes occur suddenly as a function of position.
 

Example EXAM5.AIM

Operations:  (*)Clear,  Threshold, Invert, Propagation, Bdisplay, 
Reset, Exor and (*) Measure.

Read the image CERMET.IM from disk.

Our  purpose with this example is to do some measurements on  the 
objects  in this image.  The '(*)Measure' operation requires  the 
objects  of interest to be white in a black  background.  In  the 
menu  'BinOps' we have some useful operations at our disposal  to 
achieve that goal.

In  order to be able to apply binary  operations  ('BinOps'),  we 
first  will  make the grey value image in Window  A  binary.  The 
operation  'Threshold'  in the GreyOps menu makes pixels  with  a 
grey value below the threshold black and pixels with a grey value 
above  it white.  When the operation is invoked,  it  proposes  a 
threshold which is the average grey value in the image; it is not 
necessarily  the best guess,  but usually it yields  satisfactory 
results.

Stop! The Threshold operation will ask for the bitplane where the 
binary  image  is to be stored (it defaults to b1 in  Window  B). 
However, as our previous exercises will have left some garbage in 
the  other bitplanes of Window B,  we first have to clear  those. 
The operation '(*)Clear' is provided to clear all bitplanes of  a 
window  at once (clear = grey value 0 = black!).  Type:  clear  B 
.

Now we are ready for the Threshold operation;  click on it in the 
GreyOps menu and accept the defaults.

As  we need white objects in a black background,  the picture  in 
Window B must be inverted.  Click on 'Invert' in the BinOps  menu 
(accept the defaults).

Note  that some of the objects near the frame of the  window  are 
only  partially  displayed.   We  don't  want  the   '(*)Measure' 
operation to take these incomplete objects into account,  but how 
can  we  get  rid of them?  How can  we  distinghuish  them  from 
complete objects? The answer is: use the 'Propagation'  operation 
(in CelOps) .

The 'Propagation' operation allows us to isolate  objects.  White 
pixels  (called 'seeds) will 'grow' (expand) under the  condition 
that in a given reference bitplane (the 'mask') the corresponding 
pixels are white too.  We can visualize this operation as  taking 
place in a field with seeds (= white pixels that we want to  grow 
to  shapes  present in the mask).  The  reference  bitplane  (the 
'mask')  is  the culture medium;  it has  fertile  and  infertile 
regions.  If a region is fertile (i.e.  it has white pixels  that 
coincide  with  the  seed pixels),  the seed  can  grow.  In  one 
'iteration'  (propagation step) a pixel grows in accordance  with 
its  connectivity:  one  white pixel is added in  all  connecting 
directions.  In  AIM  the seed bitplane is called  CLP  (Cellular 
Logic Plane).

In the next iteration the seed bitplane (CLP) that resulted  from 
the first iteration is compared once more with the mask bitplane. 
Coinciding white pixels in CLP and mask will,  once  more,  grow. 
This will continue until all seeds have grown to the edges of the 
fields  in  the mask;  we have created an exact copy of  all  the 
fields  that in the first iteration coincided with at  least  one 
seed.  The trick of isolating particular fields in the mask is to 
create a CLP with seeds that coincide with those fields.

Let's  return  to our problem of isolating the  incomplete  white 
objects  at the borders of bitplane b1 in Window B.  It would  be 
nice if we had a bitplane available (to be used as the CLP)  with  
white  pixels  along the frame only.  The  Propagation  operation 
would  make those border-pixels grow to the exact shapes  of  the 
intersected  objects in the mask (in our case:  b1).  The  result 
would  be:  two  images having the unwanted  objects  in  common. 
Subsequent  application of the logical operation 'Exor'  (in  the 
BinOps menu) on these two images will finally remove the unwanted 
objects.   Exor   is  the  inequality   operator:   it   compares 
corresponding pixels in both (binary!) images and outputs a white 
pixel if (and only if) they are different. 

Now  that  we hopefully understand it we cannot wait to  put  our 
knowledge to the test.  The only image we need is bitplane b1  in 
Window B. Click on Propagation. We will have to change almost all 
of the defaults!  Our mask bitplane is b1 instead of the proposed 
b2.  Furthermore,  we will use b2 as our CLP instead of  b1.  The 
connectivity is not important,  but change it to 8. The necessary 
white edge for our CLP can be chosen with the entry 'Edge value'. 
Choose 1 (for white).  Make the number of iterations 100; that is 
too  many,  but AIM will stop automatically when all  growth  has 
stopped. 

Check all entries in the Dialog Box:  if something is wrong there 
is  a risk that you have to start all over again!  Your ST  won't 
complain,  but  we  don't  want to  frustrate  prospective  image 
processors in such an early stage.

Hit Return.  If all is well, you will see an image in bitplane b2 
of Window B that has the intersected objects only.  Wrong?  Don't 
worry,  just keep trying. Don't forget to clear bitplane b2 prior 
to every Propagation operation.

Next invoke operation Exor (in BinOps). Use b1 and b2 in Window B 
as inputs and b3 as output.

At  last our image is ready for the  (*)Measure  operation.  This 
operation assumes that the image is in b1 of Window B, so we must 
copy  b3  to  b1 first.  Click 'Copy' in BinOps  and  choose  the 
appropriate bitplanes.

(*)Measure  performs a number of measurements on the objects  and 
displays the results in the Command Window. It assigns numbers to 
the  objects (left -> right,  up -> down) and labels each  object 
with a grey value according to this number.  This can be observed 
in Window D.

Type  measure  (mea will do!) .  Note  that  the  Command 
Window can be sized to bring all measured data on screen. 


PRACTICAL EXERCISES

PRAK1.
Study the image PRAK1.IM. Your assignment is to separate the nuts 
from the bolts.  In other words:  use AIM to generate two images, 
one  containing  the nuts (including the one that  rests  on  its 
side!) and the other one the bolts. Count the objects afterwards.

PRAK2.
The image PRAK2.IM shows a handful of electronic components.  Try 
to separate them. Use your fantasy and surprise husbands, friends 
and neighbors!

About Us - Contact - Credits - Powered with Webdev - © Atarimania 2003-2022