On Dec 3, 2007, at 15:34 , Daniel Drake wrote:

> Andrei Tchijov wrote:
>> I think I know the answer now ( after our somewhat prolong  
>> discussion  about merits of fpusb ), but I want to ask the question  
>> anyhow.  Do  you not consider relines to glib ( and imageMagik to  
>> some degree  ) to  be bad thing?
>
> I chose to use glib at the very start for a mix of convenience and  
> portability, but after actually writing the code I've also realised  
> that I haven't used it a huge amount and I haven't really had to use  
> the parts of it that improve portability. So yes, that might go away.

If you indicate how exactly you want to handle "irradication" of glib,  
I am more then happy to help. I was going to do it by myself, but it  
is much better to have this kind of changes in the "official" sources.

>
>
> ImageMagick is only used as a workaround for a NBIS bug and will  
> hopefully go away in future. It is only used for AES4000.

What exactly wrong with NBIS? Am I correct (based on your statement  
below) that it has problems with small images? How small?  Is  
imageMagik used only to up-sample image?

>
>
>> Sort of along the same lines ... should fprint really use NIST code  
>> in  such a "intimate" way?  NIST is free/open source/good, but it  
>> is not  the only recognition package.
>
> It's the only one that works that I know about :)

Have you looked at this folks?

http://www.griaule.com

It is not open source, but you can get SDK.  They claim that they  
outperform NIST.

>
> If that were to change, I may consider adding a layer of abstraction  
> there. We may even end up including 2 engines at some point, if we  
> cannot fix NBIS to work well for images from small sensors.
>
> As for the other points, I'd accept reasonable patches for:
> - configure-time control for excluding all enroll/verify/identify
>   functionality, NBIS, etc
> - better defining relationships between drivers and dependencies.. for
>   example aes4000 is the only imagemagick user, and uru4000 will soon
>   grow a dependency on openssl's libcrypto
> - configure-time control over which drivers get included (hence
>   including the ability to exclude imagemagick/openssl deps)
>
> The reason these aren't in place already is because there is lots of  
> work to do all over the place and my priorities are elsewhere.  
> Patches or feature request bugs are welcome.
>
> Daniel

_______________________________________________
fprint mailing list
[email protected]
http://lists.reactivated.net/mailman/listinfo/fprint

Reply via email to