libface-general — This is a general mailing list for libface library.

[Libface-general] Thanks for your help

[Mr.G <jit...@ho...>]

I am a new learner for libface,i think it is amazing; So i spend serval weeks to study it ,and now i have a problem with it ,i just still couldn't open it successful; 
The problem :
when I run libfaceGUI, it does recognize faces.  Yeah!  But each time it
recognizes a face, it prints several lines like this:


ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.


And i don't know why,If anyone has any friendly advice to help ease my learning curve, I will appreciate your comments.
Thank you very much!!!

[Libface-general] Getting started issue

[Martitza M. <mar...@gm...>]

Hi.  I just started reading the OpenCV book, so my questions are simple.

My computer is running Ubuntu Lucid x64 and has OpenCV 2.1 (2.1.0-3ubuntu1
packages) installed.

I built libface-0.1 on Ubuntu Karmic, including -DBUILD_EXAMPLES,
-DBUILD_EXAMPLES_GUI and -DBUILD_DOCUMENTATION.  No errors.  Yeah!

So I launched the GUI and loaded an image.  When I clicked "Detect Faces" I
get an error (in my shell):

Cascade directory located as : /usr/share/opencv/haarcascades
opened
ERROR: Could not load classifier cascade.

I discovered that /usr/share/opencv was almost completely empty!  (Actually,
it has one file: OpenCVConfig.cmake.)  So I went looking for the Haar
filters and found them gzip'ed in
/usr/share/doc/opencv-doc/examples/haarcascades/haarcascades.  SO I copied
and unzipped all of them into /usr/share/opencv/haarcascades (where the
libfaceGUI expects to find them).

Now when I run libfaceGUI, it does recognize faces.  Yeah!  But each time it
recognizes a face, it prints several lines like this:

ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.
ERROR: Could not load classifier cascade.

These appear to come in blocks of 5, i.e. 5 or 10 or 15 at a time.  I've
just started looking in the source code.

If anyone has any friendly advice to help ease my learning curve, I will
appreciate your comments.

Thanks!
~M

[Libface-general] Web service based on libface

[Aditya B. <adi...@gm...>]

Hi Alex,

I've created a web service using libface : http://faceoff.adityabhatt.org/.
I wrote a PHP wrapper to libface with the help of SWIG, so anyone can easily
use it in their web applications serverside - say face detection in a
web-based photo gallery. It's kept here : https://github.com/adityab/faceoff

This might be a good way to show off libface. Let me know what you think.

Thanks!
-- 
Adi

Re: [Libface-general] CMake and DESTDIR

[Leif M. <lei...@gm...>]

Hi Alex,

thanks for your reply.

2011/8/6 Alex Jironkin <ale...@gm...>:
> Hi there Leif,
>
>
> DESTDIR. Is this environment variable set by CMake or system?

Let me cite http://cmake.org/Wiki/CMake_Useful_Variables:
"DESTDIR
If this environment variable is set it will be prefixed to
CMAKE_INSTALL_PREFIX in places where it is used to access files during
installation. This allows the files to be installed in an intermediate
directory tree without changing the final installation path name.
Since the value of CMAKE_INSTALL_PREFIX may be included in installed
files it is important to use DESTDIR rather than changing
CMAKE_INSTALL_PREFIX when it is necessary to install to a intermediate
staging directory."

>
>
> Alex
>
>
> -----Original Message-----
> From: Leif Middelschulte [mailto:lei...@gm...]
> Sent: 05 August 2011 01:02
> To: lib...@li...
> Subject: [Libface-general] CMake and DESTDIR
>
> Hello all,
>
> this is actually more dedicated to developers than users in general.
>
> libface sadly ignores DESTDIR environment variable, when installing files.
> That's a very bad behavior wrt to packaging it.
>
> I there any chance on seeing this fixed by you guys, or will packagers have
> to keep patching it to work properly?
>
> Regards,
>
> --
> Leif
>
> P.S.: Please keep me CCed, as I am not subscribed to this list.
>
> ----------------------------------------------------------------------------
> --
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA The
> must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Libface-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libface-general
>
>



-- 
Leif

Re: [Libface-general] CMake and DESTDIR

[Hub F. <hu...@fi...>]

On 11-08-06 8:47 AM, Alex Jironkin wrote:
> Hi there Leif,
>
>
> DESTDIR. Is this environment variable set by CMake or system?

It is a standard environment variable used, amongst other things, by 
packaging tools (dpkg, rpm, etc.) to stage the installation in a 
different location.

GNU autotools supports it out of the box when doing make install.

And to remove any doubts, this is not the same as the prefix.

Hub

Re: [Libface-general] CMake and DESTDIR

[Alex J. <ale...@gm...>]

Hi there Leif,


DESTDIR. Is this environment variable set by CMake or system?


Alex


-----Original Message-----
From: Leif Middelschulte [mailto:lei...@gm...] 
Sent: 05 August 2011 01:02
To: lib...@li...
Subject: [Libface-general] CMake and DESTDIR

Hello all,

this is actually more dedicated to developers than users in general.

libface sadly ignores DESTDIR environment variable, when installing files.
That's a very bad behavior wrt to packaging it.

I there any chance on seeing this fixed by you guys, or will packagers have
to keep patching it to work properly?

Regards,

--
Leif

P.S.: Please keep me CCed, as I am not subscribed to this list.

----------------------------------------------------------------------------
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Libface-general mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libface-general

[Libface-general] CMake and DESTDIR

[Leif M. <lei...@gm...>]

Hello all,

this is actually more dedicated to developers than users in general.

libface sadly ignores DESTDIR environment variable, when installing
files. That's a very bad behavior wrt to packaging it.

I there any chance on seeing this fixed by you guys, or will packagers
have to keep patching it to work properly?

Regards,

-- 
Leif

P.S.: Please keep me CCed, as I am not subscribed to this list.

[Libface-general] Various patches

[Hubert F. <hu...@fi...>]

Hi,

I couldn't find the bug tracker to post these.

Here are 4 patches. In order:


1. Don't force 32-bits on MacOS X. This does not make sense. Even my 
opencv is in 64 bits.

2. Log.h cause a warning on uninitialized struct field.

3. opencv include isn't different on Mac

4. the .pc should also indicate a dependency on opencv.

Cheers,

Hub

[Libface-general] debian package for ubuntu

[Richard U. <ri...@pa...>]

Hi Guys,

I started packaging libface for ubuntu. Now, the lib64 directory caused
some troubles. Thus I asked at mentors.debian how to handle it. They
suggested not to use lib64, but always installing to lib.
http://groups.google.com/group/linux.debian.devel.mentors/browse_thread/thread/aff5ee918960e4f3#

Now is there a good reason for libface to install to lib64, or could you
change the CMake file to always use lib?

Rgds
Richard

[Libface-general] New branch

[Alex J. <ale...@gm...>]

Hi all,

I have just moved repository around to trunk and created braches and tags folders. There is a 0.2 branch for people to play around with new things to be tried. 

Only bug fixes should be submitted to trunk now until Christmas. 


Alex


If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein

[Libface-general] Future Updates

[Alex J. <ale...@gm...>]

Hi everyone,

I don't mean to be pissy and annoying about this, but the recent changes to the face detection in particular have been really poor and almost undone the progress I made in making it better. 

Sensitivity vs specificity simply doesn't work and speed is even slower. Moreover we are still utilising old functions like finalFaces. The problem with that is this: We use 1 cascade and the purpose of fine tuning the parameters is so we don't have duplicates in an image. This renders finalFaces completely useless and it will be deleted.

Now I really appreciate everyones work especially on the memory leaks and making interface better, but we are bloating library already with unnecessary stuff and its not even complete yet.


So if you have improvements in terms of fixing bugs or tidying things up, thats great and please do submit them, it will really help the library. But please leave detection and recognition alone. Or at least for now so I can stabilise it. If you have a really burning idea, create a branch edit things there and we can discuss the changes then merge.



Thanks

Alex


If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein

[Libface-general] compilation of the examples failed

[Tobias B. <Tob...@we...>]

Hi,
I am interested in your work and tried to compile your code on my machine.
Unfortunately, the examples do not compile. This is what I did:

1) installed the OpenCV-2.1.0
2) svn co URL: https://libface.svn.sourceforge.net/svnroot/libface (Revision
232)
3) cd libface;
    mkdir build; cd build;
    cmake -DCMAKE_INSTALL_PREFIX=/usr .. -DBUILD_EXAMPLES=1
-DBUILD_DOCUMENTATION=1 -DCMAKE_BUILD_TYPE=Debug
4) make; sudo make install

To my understanding, the examples should have been build, since I did an
-DBUILD_EXAMPLES=1 in my cmake configuration. But, they are not.


However, manually compiling the examples, by

g++ -I /usr/local/include/libface -o FaceDetectionExample FaceDetection.cpp
-L /usr/local/lib -lface -lhighgui -lcv -lcxcore -lcvaux

works. Note, that I had to extend the include path by libface.


Another question. Is the config file libface-config.xml missing in the
repository? The 'Train' and the 'Test' example both exit with an
segmentation fault. (see below)

Thanks in advance, Tobias



[tobias@leederville:libface/examples]$ ./Train ~/Pictures/maradonna.jpg
Cascade directory located as : /usr/local/share/opencv/haarcascades
Config location: ./libface-config.xml
libface config file does not exist.
Loading image /home/tobias/Pictures/maradonna.jpg
Input area : 170496
Total time taken : 0.27seconds
 detected
Will train with 1 faces...
Update with faces.
Id is: -1
[1]    30946 segmentation fault  ./Train ~/Pictures/maradonna.jpg

[tobias@leederville:libface/examples]$ ./Test ~/Pictures/maradonna.jpg
~/Pictures/maradonna.jpg
Cascade directory located as : /usr/local/share/opencv/haarcascades
Config location: ./libface-config.xml
libface config file does not exist.
Loading image /home/tobias/Pictures/maradonna.jpg
Input area : 170496
Total time taken : 0.27seconds
 detected
Drawing
Loading image /home/tobias/Pictures/maradonna.jpg
Input area : 170496
Total time taken : 0.26seconds
 detected
Drawing
Will recognize 2 faces...
Recognizing.
Id is: -1
[1]    31017 segmentation fault  ./Test ~/Pictures/maradonna.jpg
~/Pictures/maradonna.jpg

Re: [Libface-general] Some questions

[Aditya B. <adi...@gm...>]

Hi Richard,

I think I fixed that single face updating problem in the last commit.

- Face recognition is implemented - it used to work fine, but a few (2-3)
commits back there some design changes, it is still in the transitional
phase till we change the design. What we're trying to do is, if a face with
the same ID as an existing one in the DB is trained, then that face is
averaged with the existing one, instead of training it as a new face,

- Fisherfaces is not used at the moment. Once we polish the Eigenfaces
implementation, I plan to concentrate solely on digiKam work for my GSoC.
After that, I'll come back to libface to implement a new, better recognition
algorithm. If you want to implement another algorithm, it's awesome!

- I'm not particularly opposed to using Boost, because I think KDE/digiKam
use boost anyway. But could you mention what are the benefits of boost if
used here instead of the standard STL...

- We're a bit short of manpower at the moment, so any help is welcome :)
Alex can give you commit rights.

- If you get write permissions, all you have to keep in mind is not to
change the interface (of course :) ). And if you implement a new recognition
algorithm, just make sure that it complies with the necessary abstractions.

- OpenCV has a C++ interface, but IMHO it is in some ways C-like too. For
ex, when the OpenCV folk say "C++ interface", it usually translates to
having default arguments in some functions. I wouldn't say it's entirely OO
yet.

Thanks for the help, meanwhile it'd be cool if you could send some diffs
while you wait for Alex to give you rights :)

Regards,
Aditya

On Wed, Jun 2, 2010 at 1:01 AM, Richard Ulrich <ri...@pa...> wrote:

> Hi there,
>
> I want to use libface in a new project
> http://sourceforge.net/projects/receptiongreet/
>
> I understand that libface is not quite finished.
> Thus I would be happy to participate a bit in the development.
> So, I have a few questions:
> - Face Recognition doesn't seem to be implemented in the main interface
> class (libface::LibFace).
> - If I use the Eigenfaces class directly I run into some problems:
>  - Training a person with only one face (image) fails. This seems to be
> by design, but why is it necessary? -> Eigenfaces::doPCA() -> nEigens =
> nTrainFaces - 1;
>  - Finding a face in an already cropped image gives me a face with no
> coordinates, which leads to problems later on in FaceDetect::finalFaces
> in cvCopy near the end.
> - FisherCore.cpp misses some includes, but it doesn't seem to be used
> anyway.
> - would you generally be opposed to using boost in some areas. I find it
> to help a lot.
> - LibFace.cpp line 110 -> filename.c_str() would be better than
> filename.data().
> - If I have fixes, shoudl I send diffs, or would you give me write
> permission on the repository?
> - If I get write permissions, what do I have to look for not to
> interfere with the GSOC project?
> - I saw that opencv has also a C++ interface. I don't know the status of
> that. Is it incomplete? If it is usable enough, it might contribute to
> readability and quality of the libface code.
>
>
> Rgds
> Richard
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Libface-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libface-general
>



-- 
Aditya Bhatt
Blog : http://adityabhatt.wordpress.com
Bitbucket: http://bitbucket.org/aditya_bhatt
Face Recognition Library : http://libface.sourceforge.net

[Libface-general] Some questions

[Richard U. <ri...@pa...>]

Hi there,

I want to use libface in a new project 
http://sourceforge.net/projects/receptiongreet/

I understand that libface is not quite finished. 
Thus I would be happy to participate a bit in the development.
So, I have a few questions:
- Face Recognition doesn't seem to be implemented in the main interface
class (libface::LibFace).
- If I use the Eigenfaces class directly I run into some problems:
  - Training a person with only one face (image) fails. This seems to be
by design, but why is it necessary? -> Eigenfaces::doPCA() -> nEigens =
nTrainFaces - 1;
  - Finding a face in an already cropped image gives me a face with no
coordinates, which leads to problems later on in FaceDetect::finalFaces
in cvCopy near the end.
- FisherCore.cpp misses some includes, but it doesn't seem to be used
anyway.
- would you generally be opposed to using boost in some areas. I find it
to help a lot.
- LibFace.cpp line 110 -> filename.c_str() would be better than
filename.data().
- If I have fixes, shoudl I send diffs, or would you give me write
permission on the repository?
- If I get write permissions, what do I have to look for not to
interfere with the GSOC project?
- I saw that opencv has also a C++ interface. I don't know the status of
that. Is it incomplete? If it is usable enough, it might contribute to
readability and quality of the libface code.


Rgds
Richard 

Re: [Libface-general] Eigenfaces :D

[Aditya B. <adi...@gm...>]

Oh, and I installed Windows and checked the performance of Picasa for face
detection. It's speed is approximately the same as libface. ~6 seconds for
large images, and when there are a lot of faces, Picasa is actually slower
than libface :)



On Sat, May 15, 2010 at 11:25 PM, Aditya Bhatt <adi...@gm...>wrote:

> Hi Alex,
>
> I committed the code. As of now, I've kept the max size of a DB as 10
> faces. This is just so that you can test the training, how new faces fall
> into new DB's etc. Anyway, I fixed all the bugs and committed it. In usage,
> the DB size should be something like 50-100.
>
> For the sake of ease in coding, I've used multiple DB files. I'll change
> this at some point of time into a single DB, but that should not change how
> programs use libface :)
>
> As you said, we should remove the _default cascade and use the tree
> cascade's detections. That will bring the detection speed up to a usable
> value. And do send me a screencast comparing iPhoto and libface detection.
> After the cascade is removed, that is :D
>
> PS: Some of the code is ugly ATM, I'm fixing that. And doxygenising.
>
> Cheers!
> --
> Aditya Bhatt
> Blog : http://adityabhatt.wordpress.com
> Bitbucket: http://bitbucket.org/aditya_bhatt
> Face Recognition Library : http://libface.sourceforge.net
>



-- 
Aditya Bhatt
Blog : http://adityabhatt.wordpress.com
Bitbucket: http://bitbucket.org/aditya_bhatt
Face Recognition Library : http://libface.sourceforge.net

[Libface-general] Eigenfaces :D

[Aditya B. <adi...@gm...>]

Hi Alex,

I committed the code. As of now, I've kept the max size of a DB as 10 faces.
This is just so that you can test the training, how new faces fall into new
DB's etc. Anyway, I fixed all the bugs and committed it. In usage, the DB
size should be something like 50-100.

For the sake of ease in coding, I've used multiple DB files. I'll change
this at some point of time into a single DB, but that should not change how
programs use libface :)

As you said, we should remove the _default cascade and use the tree
cascade's detections. That will bring the detection speed up to a usable
value. And do send me a screencast comparing iPhoto and libface detection.
After the cascade is removed, that is :D

PS: Some of the code is ugly ATM, I'm fixing that. And doxygenising.

Cheers!
-- 
Aditya Bhatt
Blog : http://adityabhatt.wordpress.com
Bitbucket: http://bitbucket.org/aditya_bhatt
Face Recognition Library : http://libface.sourceforge.net

[Libface-general] A possible TODO addition

[Aditya B. <adi...@gm...>]

Hi Alex,

If you've been following the libface-related thread on digikam-devel, you
already know this, but I'd like to mention this anyway.
A professor in my university recently showed me a paper which proposes a
tweak to the eigenfaces algorithm. The idea is to use Global Linear
Regression (GLR) training to "imagine" a virtual frontal face from a single
input profile/side face. The authors claim that recognition accuracy becomes
pretty high after using this.

Do a google for H-Eigenfaces or Hybrid Eigenfaces. You might also like to
search for a paper entitled "Local Linear Regression (LLR) for Pose
Invariant Face Recognition". If explains nicely how to use GLR and LLR for
constructing a virtual frontal face. If you don't have a subscription to one
of the websites for downloading, I'll send you a copy of the papers.

I think this should go into our TODO list. If we go for GLR, we don't have
to change the eigenfaces code (which I'll commit after about a week and a
half, my final exams are next week). The GLR can be implemented as a
separate module. The detector module can feed the detected faces ( without
knowing the orientation ) to the GLR rotator module, which will then feed
the virtual frontal face to the eigen/fisherfaces module. That way, our
eigenfaces database shall only consist of frontal faces, i.e. no separate
databases for profile faces, etc.

Coupled with fisherfaces, this should achieve a good degree of both pose and
illumination invariance.
And the main advantage is that we only need to implement a single module
between the detector and recognizer, while keeping the face database
extremely simple, i.e. only frontal faces.

What do you think?
-- 
Aditya Bhatt
Blog : http://adityabhatt.wordpress.com
Face Recognition Library : http://libface.sourceforge.net

[Libface-general] ALGLIB for LDA

[Aditya B. <adi...@gm...>]

Hi,

@Alex : Check out this open-source cross-platform algebra library :
http://www.alglib.net/

Looks like it has built-in support for PCA and LDA. I was looking for such a
library as GSL doesn't run natively on windows (needs Cygwin).
So should we look at it instead of GSL?
If so, I'll need to change my GSoC proposal :).

-- 
Aditya Bhatt
My Blog : http://komplexadi.blogspot.com

[Libface-general] Eigenfaces, GSoC

[Aditya B. <adi...@gm...>]

Hi Alex,

I've finally started working on libface again (exams over) - and I'm
implementing the openCV-optimized code we talked about previously. Will
commit soon.
Also, I've uploaded a draft of my GSoC proposal on socghop :
http://socghop.appspot.com/document/show/user/aditya_bhatt/kde_digikam_face_proposal

So what do you say? Anything I should add/remove/change ?
-- 
Aditya Bhatt
My Blog : http://adityabhatt.wordpress.com

[Libface-general] Faster face recognition

[Aditya B. <adi...@gm...>]

Hi

@Alex : Ok, I tested the eigenface performance a lot... there are a few bugs
that can be ironed out, for example updating the eigenface database with the
exact same face image as before causes a segfault. Also, currently it is
very slow. I can get working on that soon, but I think we can do this
faster.

Have a look at my bitbucket repo "facestalker" :
http://bitbucket.org/aditya_bhatt/facestalker/

In the funcs.h file ( very dirtily coded, sorry ;) ) , I have used some
built-in openCV functions like cvCalcEigenObjects and cvEigenDecomposite
that will calculate eigenvalues, eigenvectors, projections and more.

Using these functions, my facestalker implementation is insanely fast... it
takes about ~5 seconds to train a set of 400 images of size 92x112.

So, what do you say? Should I incorporate some of that code into libface?

-- 
Aditya Bhatt
My Blog : http://adityabhatt.wordpress.com

[Libface-general] Eigenfaces Testing

[Aditya B. <adi...@gm...>]

Hi Alex,

Since you've been testing the recognition part, you would have the new
example for recognition too ( current one doesn't compile ). Looks like you
forgot to commit it:)

-- 
Aditya Bhatt
My Blog : http://adityabhatt.wordpress.com

[Libface-general] Project homepage

[Aditya B. <adi...@gm...>]

Hi,

@Alex Just a minor suggestion - could you update the
libface.sourceforge.netpage? People who google for libface end up on
this page and don't know what
to do - as it's quite old.

-- 
Aditya Bhatt
My Blog : http://komplexadi.blogspot.com

[Libface-general] Progress

[Alex J. <ale...@gm...>]

Hi everyone,

I have been looking at recent changes and the changes Aditya made. Face detection works lovely. I am very happy with the way it works at the moment, as far as classifier is concerned. Also good job on that example app. I will add CMakeList to that file this weekend so it can be built with options. I would also suggest installing OpenCV with cmake if it isn't already. This makes checks by the builder fairly straight forward. So I will move to that at some point next week after more testing. 


Now I think we can leave complex voting system for the the face detection and work with what we have now on face recognition part. Lets get the Eigenfaces to work before we get to play around with new things. Just so there is a working library that people can use. :) 

Well done everyone :)

Alex


If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein

[Libface-general] GSoC 2010

[Aditya B. <adi...@gm...>]

Hi Alex,

KDE has again been selected as a mentoring org in GSoC 2010. I've read on
KDE's GSoC Project ideas page that digiKam has the face recognition and
detection part.
I'd also like to continue working on libface and start hacking on digiKam as
part of GSoC. I'm quite familiar with Qt and am working on the people
tagging widget too ( actually trying to make something of my own ;) ... but
as soon as I'll get svn:// port unblocked in my campus, I'll grab it from
KDE's svn repo - currently I commit to libface via https:// ).

Anyways, so, can you mentor me for GSoC this year? It'd be nice to get this
merged into digiKam before the end of the summer, and I'd like to work on
digiKam too in the future - so I consider this a stepping stone.

Regards,
Aditya

Re: [Libface-general] Threads?

[Alex J. <ale...@gm...>]

@Aditya Threads require platform specific headers and work ever so slightly on different platforms. I wouldn't worry about threads for the time being I would rather have better face detection algorithm, as opposed to speeding up using clever engineering.


Alex

On 18 Mar 2010, at 17:00, Aditya Bhatt wrote:

> Hi.
> 
> I'll be committing the code that implements a set of "weighted cascades" soon. Now since face detection is a slow operation, I think that we should use threads to speed up the processing, by running each cascade in a different thread. Does standard C++ have threading? Does pthreads work on windows?
> 
> Regards,
> Aditya
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> Libface-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libface-general

If we knew what we were doing, it wouldn't be called research, would it?
-- Albert Einstein