mindtct appears to completely ignore the pixels-per-mm input parameter
(ippmm). When processing AES4000 images, the binarized image is
completely mangled and a lot of ridge information is lost.
Resizing the AES4000's small images results in a huge imaging performance
gain.
We use imagemagick for the resizing, as it's resizing code resamples the
image too (smoothing it out), which further improves performance.
The windows driver takes one sample at the previous register settings
and then changes some registers before resamping (and getting much better
images). The exact changes that it makes seem to vary, perhaps based on
the histogram.
Anyway, this is an approximation of the settings used for the 2nd sample
which should help matching results.
My UareU4000 device isn't working properly -- only seeing an all-white
image and no finger-on detection, however I think this code should work
for working devices.
When we include the await_finger_off procedure (i.e. set mode 12), the
current power-up code is unreliable - no 56aa interrupt arrives sometimes.
Comparing the F0 data and hwstat at this point between a working and a
non-working run yields no differences.
Work around this issue by retrying power-on 3 times.
While testing the new code on my MS keyboard, I found some strange
conditions where occasionally, the device will stop providing images
headers until it is replugged.
Detect and work around this when it happens.
This should improve driver stability somewhat. Powerup problems seem to
happen when we receive 3 unrelated interrupts while waiting for the
power-on interrupt, so let's assume that the device can only buffer 3
interrupts, and when the buffer is full, it discards new ones.
When we detect a possible buffer overflow, ask the caller to retry the
operation.
Also, saw the interrupt of death a few times, so add in a warning when
this happens. Haven't seen it since handling interrupt overflows though.
Drivers now have an ID number. These will be assigned by me and documented
on the wiki. 0 cannot be used.
Drivers now define a devtype for each device they initialise. This is to
cope with the situation where a driver can support varying devices where
their print data is incompatible (i.e. image scaling is totally changed).
This doesn't apply to any existing supported devices.
Print data no longer includes driver name, and includes driver ID instead.
Paths to saved print data now include driver ID and devtype, and no longer
include driver name.
APIs exposed for converting a print_data into a blob which can then
be loaded back again later. Useful for systems who don't want to use
my simple storage system (which is only aimed at a single user).
File format is now defined and will be documented on the wiki. The header
is larger as we can no longer rely on directory paths in all scenarios.
Print data compat check now checks devtype and driver ID.
The basic model is that image drivers declare a fp_img_driver structure
rather than a fp_driver struct. fp_img_driver will contain primitive imaging
operations such as 'scan finger and return image'. The imgdev layer will
generically implement the primitive fp_driver operations, and the imgdev
layer will fix up the enroll/verify/etc pointers at driver registration
time.
Removed const from all fp_driver declarations, as these are now modified
dynamically in the case of imaging drivers.
Convert enrollment function to return a signed integer, which is negative
on error or corresponds into fp_enroll_result otherwise.
Now we can treat a 'FAIL' condition differently from an actual error: fail
means that enrollment didn't complete because the data was nonsense or
whatever (e.g. scanned a different finger for each stage?).
Updated upekts accordingly.
This completes an enrollment implementation for the upekts driver.
It's based on code from libthinkfinger, but as there seemed to be many
unknown details there, I spent some time analysing the bus messages in
more detail and have effectively rewritten almost all of the borrowed code.
Note that libthinkfinger is GPL licensed, so that reflects on this code too.
At release time I will ask them if they are OK for me to relicense it.
