Proposed refactoring to Landmark and ROI storage in template metadata about openbr

[sklum]

Sounds good to me.

[bklare-zz]

This does sound like a much simpler approach.

On Thu, Mar 7, 2013 at 5:03 PM, jklontz [email protected] wrote:

We currently store template metadata in a QMap<QString,QVariant> table.
This generic approach has proven quite successful for associating a wide
variety of values with the enrolled template. Having said that, the current
convention for storing landmarks and regions of interest is suboptimal. The
current convention is as follows:

Template t;
QRectF face = ...; // calculate face location
t.file.insert("Face_X", face.x());
t.file.insert("Face_Y", face.y());
t.file.insert("Face_Width", face.width());
t.file.insert("Face_Height", face.height());
QPointF leftEye = ...; // calculate left eye location
t.file.insert("Left_Eye_X", leftEye.x());
t.file.insert("Left_Eye_Y", leftEye.y());

This convention dates back to when the metadata table was
QMap<QString,float>. Since QVariant can store QPointF and _QRectF_directly, I suggest we switch to the following convention:

Template t;
QRectF face = ...; // calculate face location
t.file.insert("Face", face);
QPointF leftEye = ...; // calculate left eye location
t.file.insert("Left_Eye", leftEye);

In addition to reducing the number of keys in the table, this makes it
much easier to implement File::landmarks() and File::ROIs() which
return lists of the available landmarks and ROIs respectively.

We will still use File::anonymousLandmarks() and _File::anonymousROIs()_for scenarios where it is convenient
not to associate a name with each landmark/ROI (and instead store lists
of landmarks/ROIs in the keys "_Landmarks" / "_ROIs").

One other consideration is how circles will be stored. Since there is no *
QCircle* class, I propose we store them as _QRectF) where rect.x = rect.y
= radius.

Provided the proposed change is agreeable to everyone, I'll follow up with
a patch that changes the convention throughout the code base. After that we
can have the discussion about what metadata keys to standardize, thus
formalizing how to write interoperable object detectors and landmarkers. I
know at least @caotto https://github.com/caotto and @mburgehttps://github.com/mburgehave expressed interest in seeing this happen.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22
.

[jklontz]

@biometrics/openbr A few notes regarding these changes.

1. Do a clean rebuild after your next pull. For some reason when changes are made to openbr_plugin.h not all the files that should be recompiled get recompiled causing segfaults.

2. I didn't update the wrappers for the commercial matchers as I didn't have the SDKs handy. This change shouldn't have a semantic impact on their current usage, though they don't take advantage of the new sytax for inserting metadata. However, if you experience compile errors in these non-default plugins, it's almost certainly due to one of the following API changes (or something equally trivial):

   file.getString("Key") ==> file.get<QString>("Key")
   file.getBool("Key") ==> file.get<bool>("Key", false)
   file.insert("Key", value) ==> file.set("Key", value)
   

3. Hopefully you'll find the updates to the br::File API improve usability. I'm pleased/embarrassed to report the changes also lead to a 5-10% speed improvement in template enrollment -.-