Date: 14 Mar 89 10:40:35-PST
From: Vision-List moderator Phil Kahn <Vision-List-Request@ADS.COM>
Errors-to: Vision-List-Request@ADS.COM
Reply-to: Vision-List@ADS.COM
Subject: Vision-List delayed redistribution
To: Vision-List@ADS.COM

Vision-List Digest	Tue Mar 14 10:40:36 PDT 89

 - Send submissions to Vision-List@ADS.COM
 - Send requests for list membership to Vision-List-Request@ADS.COM

Today's Topics:

 Intrinsic image routines?
 Research posts - parallel processing and vision
 Imaging software.
 Camcorder computer interface modification description

----------------------------------------------------------------------

Date: Mon, 13 Mar 89 19:47:07 EST
From: Sean Philip Engelson <engelson-sean@YALE.ARPA>
Subject: Intrinsic image routines?


I'm doing some work in cognitive mapping and robotics, and, naturally,
I need some vision.  I'm just getting to the thinking about hacking
stage, so I figured I'd ask if you had programs to compute any sort of
intrinsic images from input data, that I could get ahold of.  Things
like local shape-from-shading, or stereo depth maps, or motion fields,
etc, is what I'm looking for; not model or feature based stuff.  I
need source, of course, since I want to interface all this stuff
together, and thus commercial quality is not necessary, but
well-written code would be nice.

Thanks very much in advance,


------------------------------

Date: 13 Mar 89 17:30:55 GMT
From: Andrew Wallace <mcvax!cs.hw.ac.uk!andy@uunet.UU.NET>
Subject: Research posts - parallel processing and vision
Organization: Computer Science, Heriot-Watt U., Scotland


                              Heriot-Watt University

                          Department of Computer Science

              Research Associates in Parallel Processing and Vision

        Applications   are   invited   for   two   SERC-funded    Research
        Associateships  to  work  on  aspects  of  rapid  prototyping  and
        implementation of algorithms for high level  image  interpretation
        on   multiple  instruction  multiple  data  (MIMD)  architectures.
        Although  working  closely   together,   each   RA   will   assume
        responsibility   for   a   specific  programme.   The  first  will
        concentrate  primarily  on  the  software  methodology,  including
        functional  specification  of  algorithms and their transformation
        into a parallel imperative language,  OCCAM  2.   The  other  will
        undertake  the  development,  optimisation  and  implementation of
        algorithms for visual  recognition  and  location  on  a  suitable
        machine.   The persons appointed will join a lively research group
        working  on  several  aspects  of  computer  vision  and  software
        development.

        Applicants should have an honours degree in Computer Science or  a
        related    discipline,   together   with   relevant   postgraduate
        experience.  The posts are tenable for three years, commencing  as
        soon  as possible after the 1st June.  The starting salary will be
        in the range L=8,675 to L=13,365 depending on  age  and  
	experience.

        Enquiries  should  be  directed  initially  to  the Staff Officer,
        Heriot-Watt University, Riccarton, Edinburgh EH14 4AS,  from  whom
        further  information  and  application forms may be obtained.  The
        closing date for applications is 7th April 1989.

        Informal enquiries may be directed to Dr. Andrew Wallace   at  the
        Department   of   Computer   Science,   tel.   031-225-6465   x542
        (andy@uk.ac.hw.cs)

 Andrew Wallace			JANET : andy@cs.hw.ac.uk
				ARPA  : andy@uk.ac.hw.cs
				UUCP  : ..ukc!cs.hw.ac.uk!andy


------------------------------

Date: Wed, 8 Mar 89 14:59 N
From: THIERRY PUN <PUN%CGEUGE51.BITNET@CUNYVM.CUNY.EDU>
Subject: Imaging software.

(Following vision-list digest of Monday March 6, 89).

LABO IMAGE:

Computer Science Center, University of Geneva, Switzerland


GENERAL DESCRIPTION:

Labo Image is a window based software for image processing and analysis. It
contains a comprehensive set of operators as well as general utilities. It
is designed to be open-ended; new modules can easily be added. The software
is mostly written in C, and currently runs on Sun 3/xxx, Sun 4/xxx (OS3.5 and
4.0) under SunView. It has been extensively used by students as well as
researchers from various domains: computer science (image analysis), medicine,
biology, physics. It is freely distributed.

CAPABILITIES:

Labo Image is an interactive software, whose interface is menu, mouse and
windows based. It can work on monochrome (binary) or color workstations. Its
main features are:
    - input-output: file, screen, postscript;
    - display: mono, RGB, dithering;
    - color table manipulations;
    - elementary interactive operations: region outlining, statistics and
      histogram computation, etc;
    - elementary operations: histogramming, conversions, arithmetic, images
      and noise generation;
    - interpolation, rotation/scaling/translation;
    - preprocessing: background substraction, filters, etc;
    - convolution/correlation with masks, image; padding;
    - edge extractions: various operators, peak-following;
    - region segmentation: various methods (being implemented);
    - transforms: Fourier, Haar, etc;
    - binary mathematical morphology, plus some grey-level morphology;
    - expert-system for novice users;
    - macros definitions, save and replay;
    - etc.

IMAGE FORMATS:

Own format: descriptor file + data file (binary, byte, int, float, complex;
mono or RGB). Conversions to various other formats.
Constructs:
    - iconic (pixel-based), which each image having its own parameter list;
    - vectors (histograms, look-up tables);
    - graphs (for regions; being implemented);
    - strings (for macros).

STATUS:

Version 0 has been released in January 1988, version 1 in November 1988,
version 2 will be released before end of March 1989:
    - hosts: Sun 3/xxx, Sun 4/xxx;
    - OS: Sun OS 3.5, 4.0;
    - window system: SunView, View2 as soon as possible; X11 in preparation;
    - language: mostly C, plus some Fortran (SPIDER modules) and some
      Common-Lisp (expert-system);
    - approx. code size: source 1MB (25'000 lines), executable 1.5MB under
      SunView/OS3.5;
    - documentation: manuals (french), leaflets (english); english manual is
      being prepared.

DISTRIBUTION POLICY:

Most of the software has been developped by us, and source code is available.
A few modules are licensed (SPIDER), and of course cannot be distributed;
these are however routines that all imaging groups have, such as median or
Fourier transform.
Interested persons can be sent the software by providing us with a 1/4"
cartridge. Under special request, it can be e-mailed. A typical disclaimer
notice will also be sent. In essence:
    - the software is our property, and the copyright notice must appear;
    - results obtained with Labo Image should reference it;
    - no responsability is assumed;
    - no money can be made out of it;
    - no redistribution without our consent;
    - bugs will usually be corrected since we use intensively the software;
    - modifications should be communicated to us, with (normally) allowance
      for redistribution.

CONTACTS:

Thierry Pun (general design) or Alain Jacot-Descombes (general design and
principal writer of the software): Computer Science Center, Univ. of Geneva,
12 rue du Lac, CH-1207 Geneva SWITZERLAND.
Tel. +(4122) 87 65 82 (T. Pun), 87 65 84 (A. Jacot-Descombes).
E-mail: pun@cgeuge51.bitnet, pun@cui.unige.ch, or jacot@cuisun.unige.ch.


------------------------------

Date: Mon, 13 Mar 89 10:33:47 PST
From: Mark Noworolski <noworol@eecg.toronto.edu>
Subject: Camcorder computer interface modification description


[ I have omitted the compressed binary files.  If anyone has a need for
  them, please let me know, and I will mail the uuencoded, compressed, 
  tar'ed (and feathered) file to you.
			phil...		]


Here, as promised are the details of how to interface the
Fischer-Price Kiddie Camcorder to a computer- in my case an
IBM PC. The camera has 120 horiz, 90 vertical, and 16 grey scales.

Several notes are in order:

1. It may sound like part of a thesis. Well it is.
2. Figures are not enclosed, I figure that it's reasonably easy
to figure things out without them anyway (provided you have a unit
near you). Figure that, figure, figure. figure.
3. The interface is built with the premise that if it's possible to do
it in software, it'll be done that way. Improvements are most
DEFINITELY possible (and probably welcome). Some of the parts of it
are probably redundant, but make me much happier about the likelihood
of frying something in my PC.
The actual interface is enclosed in 3 formats:
ORCAD schematic file v3.11
HPGL file spit out by orcad 
Postscript file (untested) after running through an hpgl to ps converter.
epson format file.
4. The program is written for Turbo C 2.0. It uses the BGI routines and
is REALLY ugly. I mean that. It's one of those programs that you write in
2 minutes 'just to see if it works' and then never clean it up.
5. The following should only be attempted by people who have a vague idea
of what they're doing. Since you're interfacing to the IBM bus directly you
should be VERY careful.
6. The executable of the display program will be provided on request.
7. A question... Why does the damned program generate a parity error when 
starting up? It goes away after that.

Well, here's the goods.

          Reverse Engineering

          The Fisher  Price Kiddie  Camcorder was found to be a very useful
          image sensor priced  reasonably  (at  the  time  of  writing $180
          Canadian). What  follows is  a description of how to use the unit
          as an image sensor giving 16 levels of  grey scale  and requiring
          only  a  minimum  of  interface  circuitry.  Please note that all
          direction references (unless specified otherwise) are  related to
          those observed when actually using the unit as a camera.

          Disassembly  of  the  unit  is  fairly simple, screws are located
          underneath the rubber pegs located on the right hand of  the unit
          (see figure  1).   These must  be pried off with a pointed object
          such as a screwdriver,  revealing  the  screws  underneath. These
          four  screws  must  then  be  removed  along  with the two in the
          handle. The unit can  then be  easily separated  into two halves,
          revealing the electronics and the cassette mechanism.

          Next  the   cassette  mechanism   must  be   separated  from  the
          electronics. This can be accomplished by separating the two while
          using the  pushbutton side as a pivot point (most wires are to be
          found on  that side).  In order  to simplify  interfacing the two
          wires leading to the motor should be disconnected.

          The switch  labelled SW1 should next be pushed in permanently (it
          is found directly behind  the  vision  sensing  element  near the
          shield), this  can be accomplished by pulling the spring out from
          within it and then  manually pushing  it into  position. The unit
          can at  this point  be used  as a  vision sensor which plugs into
          your TV. In other words what it now does is  work like  normal in
          the record  mode; except  that no  recording actually takes place
          since the motor doesn't turn.

          Towards the back of the board  there are  two SMD's.  They are 24
          pin devices  mounted side by side. Both of them have similar part
          numbers- FP519550. To the  left of  these there  are 7 resistors,
          the top  one is labelled R155. The bottom four are the 4 bit data
          stream (see figure 2), thus giving 16 levels of grey scale (a TTL
          high level  indicates a  corresponding high light intensity). The
          bottom resistor is the most significant bit and the fourth one up
          is the  least significant;  the right side of each being the data
          line itself. These lines are shown in figure 3 together  with the
          associated control signals. The data lines and associated control
          signals are at standard TTL levels of 5 volts.

          The synchronising signals can be found on the  left FP519550 SMD.
          Each is named as follows: 

          Current Frame- pin 5
               This signal  is a  square wave of period 130 msec. It can be
               used as a synchronising signal to indicate start of frame.

          Data valid- pin 17
               This signal is  active  low  for  approximately  250nsec and
               occurs 600  nsec before  the end  of a data valid period. In
               addition it goes low for a short period at the beginning and
               end of each frame.

          Horizontal Sync- pin 23
               This  signal  is  active  low for approximately 50usec every
               0.7msec. This can be used as the horizontal sync signal.

          Numerous additional control-related signals can be found on these
          two SMD's.  However the  three described  above are sufficient to
          enable interfacing to a computer with minimal circuitry.



          Interfacing to the IBM PC bus

          Emphasis in the  interface  planning  and  design  was  placed on
          simplicity  as  opposed  to  elegance.  The reasoning behind this
          being that this was still the initial prototype development phase
          of the project. In the final design a microcontroller such as the
          8051 might be a good choice for image aquisition processing.

          The final circuit designed with this premise in mind is  shown in
          figure  1.  Although  simple  in  function  and design, a lack of
          reasonable care can damage  the PC  bus and  some I/O  cards (the
          author himself  has manged to destroy his hard disk controller in
          a puff of smoke).

          The simple precaution of removing all PC cards possible will lead
          to a  safer environment in which to debug this circuit. Note that
          the DMA3 channel  is  used  to  do  the  interfacing.  Once again
          caution should  be stressed as some PC cards use the same channel
          for their functions and  it is  important that  this circuit does
          not conflict with them.

          Circuit Description

          The '74  latch is used to generate DMA requests by using the Data
          Valid line as a clock. The DMA acknowledge line clears  the flip-
          flop  thereby  setting  it  up  for  the  next data word. The DMA
          acknowledge time is  significantly  less  than  the  6usec period
          during which data is valid.

          The Data Valid line is also used as the clock for the '374 latch,
          with the data lines, Current Frame bit, and Hsync bit used as its
          inputs. The  output enable line is controlled by both the IOR and
          the DMAK3 lines, thereby assuring  that  no  bus  conflicts occur
          when  another  I/O  device  is  accessed (unless it uses the DMA3
          channel).

          Finally the  '06 open  collector buffer  is used  to minimize the
          risk of blocking other devices from using the DMA3 channel. This,
          however, is  probably  unnecessary  since  DMA3  service attempts
          would cause bus conflicts anyway. Nevertheless it made the author
          feel  much  more  comfortable  about  the   likelihood  of  other
          components in his computer vanishing in puffs of smoke.





------------------------------

End of VISION-LIST
********************
