Remove all the headers already included through "fp_internal.h" such as
<libusb.h> and <errno.h>, include "assembling.h" and "driver_ids.h" there
as well to avoid doing it in (almost) every driver.
The code was indented, but only the first call was actually in the
conditional, which meant that initialisation carried on as normal on top
of a failed USB device. Exit early and remove the conditional to fix
this.
https://bugzilla.gnome.org/show_bug.cgi?id=98594
AES3500 and AES4000 are pretty similar devices, have same
command send, the only difference is in image size and init sequence.
Extract common routines from AES4K to be used later in AES3500 driver
https://bugs.freedesktop.org/show_bug.cgi?id=64351
ID is just a some magic number to make fingerprint from one scanner model
incompatible with another scanner model. Get rid of "magic", declare enum
and use it.
https://bugs.freedesktop.org/show_bug.cgi?id=56956
I want to offer the ability for an application to view a binarized
version of a scanned print. This lead onto a few changes:
1. Store minutiae and binarized data inside fp_img
2. Move resize code to the capture path, it previously happened much
later.
3. Add fp_img_binarize() to return a new image in binarized form.
4. Add a BINARIZED_FORM flag to prevent an image being binarized again.
In future, it would be nice to be able to binarize without detecting
minutiae, but this involves some work on the NBIS interaction.
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.
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.
