Install.txt

Basic usage: copy the DLL file in the ImageJ directory. Copy the
CLASS files in a plugin's directory.
NOTE: scionfg.dll must be present in the ImageJ directory as well,
or somewhere the system can find it.

Upon restarting ImageJ, there will be a new plugin, called
GrabVideo, which will attempt to display live video from your LG-3
frame grabber. If you succeed, you will notice that the refresh
rate is less than real time, but it is decent.
From the live-display window, you may select a region of interest,
and adjust brightness-contrast (including the option to highlight
saturated pixels) before either launching the acquisition or
grabbing individual frames. In the acquisition window you will
select the number of frames and the delay between frames. Choose a
delay of 1 frame for real time video. Due to the limited speed of
memory copy between the LG-3 frame buffer memory and system
memory, your acquisition demands may not be satisfied. Acquisition
will stop if this happens.


The structure of the native interface is basically the same as the
original JNIAkiz. There are a few extra functions due to the
development of a more user friendly interface.
In porting to Windows, there are a few minor changes regarding
type definitions, and the implementation of a timer (millisecond)
using the Windows MultiMedia library (WINMM.LIB must be a part of
your project. This file lives around your windows/system
directory), besides the files from the Scion library.

The main structural change tries to achieve the desired realtime
video acquisition with the slow LG-3. Using Mac-OS and realtime
threads, Daerr managed to do that. However, it does not seem to be
possible to implement this under Windows with the standard tools.
I have messed with threads quite a bit unsuccessfully. But I am not
an expert, so it may be possible after all...

In principle, full frame real time acquisition can be achieved if
frames are stored in the LG-3 frame buffer memory. So, loading it
with 64MB or onboard RAM, one can store 128 buffers (or a bit more
than 5s for PAL video), such as you can do using the application
ScionImage under Windows. The modified version of JNIAkiz,
JNIAkizMT ("MT" stands for "Multi-tasking", a bit pretentious...)
does not attempt to transfer frame memory into system memory in
real time. Instead, it keeps filling frame buffers as required,
 transferring captured frames line by line, checking whether a
new frame has been detected between line transfers. If this
happens, line transfer is put on hold and the new frame is
processed as required (store its time, decide whether we want it
or not, etc.). This forces to keep extra FIFO stacks indexing the
frame-memory positions where a new frame can safely be stored and
when slow memory transfer must proceed. Because of this, the main
loop becomes something really messy, and hard to read (sorry) but
IT WORKS!. If the current transfer demands exceed about 4MB/s
(which is roughly 10 full PAL frames per second), memory transfer
cannot keep pace, and we will have to stop when a
still-not-transferred-frame is about to be ovewritten.
Nevertheless, using this method we gain about 50% more "virtual
frame space", allowing the "impossible" task to digitize about 200
full PAL frames in real time with a 64MB LG-3. This parameter does
not seem to depend much on system speed. My advice: load your LG-3
with RAM. That is cheap.