[Digikam-devel] GPU Implementation of image processing algorithms

[Aditya Bhatt]

PS: Google for H-Eigenfaces (aka Hybrid-Eigenfaces). It is a nifty tweak to
the original method. A professor in my university just showed me a paper
that proposes this method, and it greatly solves the problem of pose
variation.

On Sun, Apr 18, 2010 at 10:20 AM, Aditya Bhatt <adityabhatt1991 at gmail.com>wrote:

> Hi Kunal,
>
>
>> Actually, there is a small interpretation error, the conditions regarding
>> publishable usage is only for the adopters (ie. NVIDIA or ATI etc
>> http://www.khronos.org/members/conformant/ ) who come up with OpenCL
>> compliant drivers / API implementation. As mentioned in the link "main
>> adopters page <http://www.khronos.org/adopters>" we as implementers
>> should not have any problems. (Quoting from the site:
>> http://www.khronos.org/adopters)
>>
>> "*  Implementers - for no cost or license fees you may:*
>>
>>    - *Create and deliver a product using the publicly released
>>    specifications and technologies*
>>    - *But you may *not* claim that it is "compliant" unless they enter
>>    and pass conformance testing*
>>    - *And if the product is a software or hardware engine, you may not
>>    advertise it using the Khronos API technology logos or trademarks*
>>    "
>>
>> Regarding the second and the third point , that's ok from an OpenSource
>> project perspective . As it provides us, both the freedoms
>> of free speech & free beer , but asks us not to publicize it :) (without
>> conformance testing).
>>
>
> Ok then. But what I'm not sure about is : if we incorporate this in libface
> and consequently digiKam, doesn't that amount to publicizing it? If not,
> then that's great with me. But please ask the others about their opinions
> too - we'd want as less dependencies as possible.
>
>
>> Actually, freely available implementations of EBGM are available (as i had
>> pointed out , in a reply to Marcel's mail sometime back the implementations
>> can be found at  http://malic.sourceforge.net/ and also at
>> http://www.cs.colostate.edu/evalfacerec/algorithms5.html ). Also i would
>> like to interact with you'll on IRC,on which IRC do you'll (Alex and you)
>> usually meetup.
>>
>>
> Yes, the CSU project was also my first choice for EBGM.
>
>
>> Now let us look at *how many* training images we would need (of a single
>> person) for satisfactory recognition results.
>>
>> Assuming a person looking straight at the camera, a 1 degree variation in
>> pose from 0 degree ( face towards left) to 180 degree (face towards right)
>> would result in 180 images.
>>
>> Now if the person looks upwards 1 degree (again we would have 180 images
>> from left to right) and if we keep varying poses we would get approximately
>> 180 x 180 images of the same person.
>>
>> Also for each successive pose varied image added to the training set the
>> training time would increase exponentially.
>>
>>
> Actually, no - we can assume about 10-20 degrees tolerance. What I think
> is, ~4 to 5 representative images per person should be okay for a photo
> management suite. What is required for a person is : A frontal face, a
> profile face, and a sideways face. And then more faces can be added on the
> fly as more variations are encountered. This way, we get a denser sampling
> over pose as time proceeds.
> And as I already said, the average number of friends/acquaintances that
> people would tag in photos is not so large as to noticeably slow down the
> re-training.
> And compared to eigenfaces, the PCA + LDA approach is, to some extent, able
> to accomodate pose variations (20-30 degrees) and therefore fisherfaces
> should be fine for digiKam if the above method is followed.
>
> I would love to add the implementation to libface. But looking at the
>> similarity between Eigenfaces and Fisherfaces IMHO the
>> effort should be to get as many different algorithms implemented as
>> possible.
>>
>>
> Very true. But for now, the priority is to get fisherfaces up-and-running.
> It's sort of like an insurance of sorts - fisherfaces should be quite easy
> to implement and although less accurate than EBGM, it is okay enough to be
> incorporated into digiKam. So we'll definitely have at least one working
> algorithm. Meanwhile, we might want EBGM at some point, so jump in :)
>
> And I and Alex (and the rest of the digiKam team, for that matter) doesn't
> communicate much via IRC, we use the ML more.
> Get yourself subscribed to the libface ML. As for me, I usually idle in
> #digikam, #kde, and #kde-in. I think I've talked to you before on #kde-in :)
>
> Cheers,
> --
> Aditya Bhatt
> Blog : http://adityabhatt.wordpress.com
> Face Recognition Library : http://libface.sourceforge.net
>



-- 
Aditya Bhatt
Blog : http://adityabhatt.wordpress.com
Face Recognition Library : http://libface.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20100418/c4d60b64/attachment.html>