[comp.realtime] Infra-red imaging problems

garry@fang.dsto.oz (Garry White) (06/13/91)

The following letter is a summary of a letter I 
received from Michael Houston. Michael's letter
detailed a problem his group is facing and a request
for information/assistance from the "world".
The problem relates to the acquistion of Thermoelastic 
Scan Data.

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

The Applied Mechanics Group here at Aeronautical Research Lab
are using a technique where the change in temperature at many 
points within a dynamically loaded structure may be used to 
describe the stresses within the structure. A problem they
have encountered is that the changes in temp. range near the
the minimum resolvable temps of commercially available Infra-Red
camera. In order to improve the clarity of their measurements
they intend to do some averaging (either on line or off line)
over many (up to 10000) frames.

The problem they now encounter is a function of the fact that
they wish to capture the digital data stream before video 
processing and D/A translation. The problem being that they
now have very high rates of data transfer and enormous storage
requirements.

Michael outlined a set of specifications and information for
a "high-end" system. The objective of the group is
to obtain or build a system which will accommodate this set
of specs. Below is a summary of the proposed solution involves.

The camera is equipped with a 512 X 512 sensor array. The array
is scanned twice and the fields interlaced to produce one frame 
in 1/25th of a second, and the infra-red flux measurement taken
by each sensor is quantified in an 11-bit word (after A/D conv.)
(Note that this becomes and 8-bit word after transformation in
the LUT. This may be an acceptable alternative for some
applications). This signal is available after some corrective
processing at a GPIB interface which has sufficient onboard 
memory for one frame. The intention is to send the digital
info via the GPIB interface to some appropriate storage
device. This may be a set of parallel winchestor disks,
or RAM (very expensive) or some other alternative, each with
their own difficulties and costs. Such a proposal results
in a figure of 9.01M/sec incoming data rate and a total storage
requirement of some 3.6 Gigabytes (assuming 10000 frames
- 6 mins 40 secs of recording time. A solution based on
8-bit words results in 6.5M/sec and 2.6G. Options to
reduce these big numbers include discarding some of the
data (eg. every i-th frame) but ideally this would be 
avoided. Data compression may also be possible once
more is known about the incoming info.

Michael and his group would be most appreciative of any advice,
suggestions (including those which, at the time may have seemed
only remotely feasible), or expressions of interest. Any and
all questions concerning the info supplied here are most welcome.

Michael Houston can be contacted at

myh@dstos3.dsto.oz.au

if and only if this fails you can mail to 

kenjones@munmurra.cs.mu.oz.au