Comments (4)
So at least the CT8 plugin can already use external eye locations, but what
I would like is for all COTS plugins to have the ability to use external
eye locations (could be ground truth, could be the output of another
detector) if available, and to do that in a standardized way.
I don't necessarily know the right way to standardize it--there are
currently two ways to store points, as either anonymous points in a list,
or as a separate key/value pair for each point (named points). The CT8
plugin assumes the eye locations are stored as the first two anonymous
points of a template and doesn't consider named points, which isn't
particularly explicit.
There has been some discussion on standardizing point names, and some
changes which I haven't really followed so maybe @jklontz can expand or
disagree, but what I would like is for the two eye locations to be
consistently stored as named points with some standard name, and for the
COTS plugins to use those if available. Another option would be for the
transforms to take key names of the eye locations as arguments (so you
could store both ground truth, and detected points as named points, and
selectively use either for enrollment).
Anyway in general I think it would be better to modify existing transforms
to optionally accept eye locations for enrollment (where feasible) rather
than making new transforms.
-Charles
On Sat, May 11, 2013 at 3:34 PM, Brendan K [email protected] wrote:
@jklontz https://github.com/jklontz @caotto https://github.com/caottoI am interested in using a COTS plugin to match face images in a modality
where face and eye detection generally fail. As such, I want to provide
ground truth eye locations in the sigsets, and use these values at the
enrollment stage for the COTS matcher.From examining the COTS plugin code, this operation does not seem to be
supported in openbr. Further, it would seem the fix would be to create a
new plugin for each corresponding COTS matcher, which uses the meta data
provided in the sigset (i.e., eye locations) to enroll the face image. Does
these two statements seem correct? If so, then I will likely create at
least one such plugin.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51
.
from openbr.
I agree with everything that's been said here, let me just fill in some details about how I think it should work.
Step 0 is that for a given COTS matcher, their face detector and template generator should be separated into two distinct transforms. CT8 does this already with CT8Detect and CT8Enroll. I'm not sure about the status of the other systems off the top of my head, but the only one where I know this is impossible is PP5.
As Charles suggested, the other step is to decide on standardized names for the landmarks returned by the detector so that they can be specified from a sigset. I think firstEye
, secondEye
, noseTip
, or something along those lines are good candidates for names. These standardized names should be added to the br::File documentation which maintains a list of standardized metadata fields. On a related note, I'd like to stop storing these points anonymously as we do now with both ASEFEyes and CT8Detect, and reserve the anonymous storage for points that truly have no meaningful label, like SIFT keypoints.
Sound good?
from openbr.
Thank you both for the detailed replies. Every point you all bring up makes
sense, and, from an experimental standpoint, it seems there would be value
to separating these stages.
Unfortunately, the one matcher I was concerned at this point is PP5. B/c it
is apparently not possible to do manual enrollment with PP5 (as Josh
noted), this is issue is a no longer a personal priority.
Would it make more sense to use the craniofacial landmark names instead of
firstEye, noseTip, etc? On the plus side this may help towards consistency
amongst different landmark extractors. On the down side, these are
difficult to learn.
On Sun, May 12, 2013 at 9:46 AM, jklontz [email protected] wrote:
I agree with everything that's been said here, let me just fill in some
details about how I think it should work.Step 0 is that for a given COTS matcher, their face detector and template
generator should be separated into two distinct transforms. CT8 does this
already with CT8Detect and CT8Enroll. I'm not sure about the status of the
other systems off the top of my head, but the only one where I know this is
impossible is PP5.As Charles suggested, the other step is to decide on standardized names
for the landmarks returned by the detector so that they can be specified
from a sigset. I think firstEye, secondEye, noseTip, or something along
those lines are good candidates for names. These standardized names should
be added to the br::File documentation which maintains a list of
standardized metadata fields. On a related note, I'd like to stop storing
these points anonymously as we do now with both ASEFEyes and CT8Detect, and
reserve the anonymous storage for points that truly have no meaningful
label, like SIFT keypoints.Sound good?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51#issuecomment-17778154
.
from openbr.
@bklare Yeah I'd certainly be willing to consider craniofacial landmark names, and I agree with the strengths and weaknesses you've stated. I'm going to close this ticket for the time being based on your response, we can re-open when someone renews interest in this area.
from openbr.
Related Issues (20)
- "cxmisc.h" header is missing HOT 2
- __BEGIN__ is undefined HOT 1
- __END__ is undefined
- Problem in the tests ? HOT 1
- New to this project - about the installation
- Conflict between openbr and dlib
- Build system -- missing QT5 test and opengl v1.1.0 HOT 7
- Clustering usage? understanding rank order neighborhood construction
- OpenCV 4 HOT 4
- Build fails in with VS_2017 and Eigen HOT 1
- Failed to load stasm cascade in FaceRecognition Algorithm
- openbr not working on ubuntu 18.04 HOT 2
- 'br' is not recognized as an internal or external command in windows 10
- Get Fatal Error when try to run "Nmake intall" for building OpenBr HOT 1
- failed to build on windows HOT 1
- Fails to build with OpenCV 3.2.0
- Operating points for ROC curves HOT 4
- CMake Error at openbr/CMakeLists.txt:31 (add_library): Cannot find source file: /usr/local/include/http_parser.c
- how to compute 1:1 face compare accuracy in %
- Missing header file "opencv2/core/core_c.h"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openbr.