OpenFace: Free and open source face recognition with deep neural networks

Free and open source face recognition with
deep neural networks.

OpenFace is a Python and Torch implementation of
face recognition with deep neural networks and is based on
the CVPR 2015 paper
FaceNet: A Unified Embedding for Face Recognition and Clustering
by Florian Schroff, Dmitry Kalenichenko, and James Philbin at Google.
Torch allows the network to be executed on a CPU or with CUDA.

Crafted by Brandon Amos in the
Elijah research group at
Carnegie Mellon University.

This research was supported by the National Science Foundation (NSF)
under grant number CNS-1518865. Additional support
was provided by the Intel Corporation, Google, Vodafone, NVIDIA, and the
Conklin Kistler family fund. Any opinions, findings, conclusions or
recommendations expressed in this material are those of the authors
and should not be attributed to their employers or funding sources.

Isn’t face recognition a solved problem?

No! Accuracies from research papers have just begun to surpass
human accuracies on some benchmarks.
The accuracies of open source face recognition systems lag
behind the state-of-the-art.
See our accuracy comparisons
on the famous LFW benchmark.

Please use responsibly!

We do not support the use of this project in applications
that violate privacy and security.
We are using this to help cognitively impaired users to
sense and understand the world around them.

The following overview shows the workflow for a single input
image of Sylvestor Stallone from the publicly available
LFW dataset.

  1. Detect faces with a pre-trained models from
  2. Transform the face for the neural network.
    This repository uses dlib’s
    real-time pose estimation
    with OpenCV’s
    affine transformation
    to try to make the eyes and bottom lip appear in
    the same location on each image.
  3. Use a deep neural network to represent (or embed) the face on
    a 128-dimensional unit hypersphere.
    The embedding is a generic representation for anybody’s face.
    Unlike other face representations, this embedding has the nice property
    that a larger distance between two face embeddings means
    that the faces are likely not of the same person.
    This property makes clustering, similarity detection,
    and classification tasks easier than other face recognition
    techniques where the Euclidean distance between
    features is not meaningful.
  4. Apply your favorite clustering or classification techniques
    to the features to complete your recognition task.
    See below for our examples for classification and
    similarity detection, including an online web demo.

The following is a BibTeX
and plaintext reference
for the OpenFace GitHub repository.
The reference may change in the future.
The BibTeX entry requires the url LaTeX package.

    title        = {{OpenFace: Face Recognition with Deep Neural Networks}},
    author       = {Amos, Brandon and Ludwiczuk, Bartosz and Harkes, Jan and
                    Pillai, Padmanabhan and Elgazzar, Khalid and Satyanarayanan, Mahadev},
    howpublished = {url{}},
    note         = {Accessed: 2016-01-11}

Brandon Amos, Bartosz Ludwiczuk, Jan Harkes, Padmanabhan Pillai,
Khalid Elgazzar, and Mahadev Satyanarayanan.
OpenFace: Face Recognition with Deep Neural Networks.
Accessed: 2016-01-11

Unless otherwise stated, the source code and trained models
nn4.v*.t7 and celeb-classifier.nn4.v*.t7 are copyright
Carnegie Mellon University and licensed under the
Apache 2.0 License.
Portions from the following third party sources have
been modified and are included in this repository.
These portions are noted in the source files and are
copyright their respective authors with
the licenses listed.

Original URL:  

Original article

Trello Launches Developer Platform

Trello-Zendesk A few months ago, project management tool Trello launched third-party integrations with tools like Slack, GitHub and Salesforce for its paying users. Now, it is opening this platform to more developers with the launch of its so-called “Power-Ups Platform” for developers who want to integrate their services with Trello.
The company also today said it now has “12 million… Read More

Original URL:  

Original article

Org-Mode for Writing: Structure and Focus

Org-mode is a structured editor that combines the best features of a powerful outliner and a powerful editor in one package. I’ve been fooling with org-mode a lot lately, digging into capabilities, solving issues and fine tuning, always asking the question — is org-mode the best environment for my writing? The answer is an unqualified yes.

Emerald Ring Outline — click to enlarge

The illustration above is a screenshot showing the outline I used to write “An Emerald Ring,” a short story I wrote at the end of last year. Org-mode uses stars to distinguish heading levels, one star for the top level, two for the next and so on. You create a new headline by pressing either the Ctrl or Alt key together with the enter key. You cycle headline visibility using the Tab key.

As I progressed, I created a new top level heading for each new draft of my story with the latest draft at the top. The first four lines in this outline are structural markups that begin with #+. The markups don’t print. They tell org-mode what to do when the file or part of the file is exported to LaTeX, html or plain text. I put the latest draft at the top of the outline so that when I highlight the structural markups and the first headline, only the latest draft will be exported.

When you’re deep into writing a story, an article or even a book, and you have ideas, where do you keep the ideas so they don’t get lost? Well, I created headings for Story outline, characters and notes lower in the outline. I didn’t lose anything and my notes are right there when I need them.

The screenshot shows the outline partially expanded. Org-mode shows three periods after any headline that has subheads or text below. Yeah you say, all this is lovely but doesn’t it get kind of messy when you want to concentrate on writing a passage of plain text in the middle of an outline? Glad you asked because org-mode has a neat trick.

Focused headline — click to enlarge

I put the cursor on the headline for the 8th draft and told org-mode to narrow the focus with a simple shortcut command. Here’s the screenshot. Try that one with your word processor. Now I have an uncluttered screen where I can write with no distractions. I wrote this post with org-mode using this trick. I created a new headline, told org-mode to narrow the focus and had a clean screen with the subject line at the top. Works for me.

There’s lots more to come. I figured out how to get the old DOS MaxThink and org-mode to cooperate but that’s another subject for another time.

Like this:

Like Loading…


Original URL:  

Original article

Announcing sshexport

I struck a small blow for better security today.

It started last night on an IRC channel with A&D regular Susan Sons admonishing the regulars to rotate their ssh keys regularly – that is, generate and export new key pairs so that is someone cracks the crypto on one out of your sight it won’t be replayable forever.

This is one of those security tasks that doesn’t get done often enough because it’s a fiddly pain in the ass. But (I thought to myself) I have a tool that reduces the pain. Maybe I should try to eliminate it? And started hacking.

The tool was, until yesterday, named ssh-installkeys. It’s a script wrapper written in Python that uses a Python expect engine to login into remote sites and install (or remove) ssh keys. What makes it useful is that it remembers a lot of annoying details like fixing file and directory permissions so your ssh server won’t see a potential vulnerability and complain. Also, unlike some competing tools, it only requires you to enter your password once per update.

Some time ago I taught this code to log its installations in a config file so you have a record of where you have remote-installed keys. I realized that with a little work this meant I could support a rotate option – mass-install new keys on every site you have recorded. And did that.

I’ve been meaning for some time to change the tool’s name; ssh-installkeys is too long and clumsy. So it’s now sshexport. I also updated it to know about, and generate, ed25519 keys (that being the new hotness in ssh crypto).

In order to reduce the pain, sshexport can now now store your passwords in its list of recorded sites, so you only have to enter the password the first time you install keys and all later rotations are no-hands operations. This doesn’t actually pose much additional security risk because by hypothesis anyone who can read this file has read access to your current private ssh keys already. The correct security measure is whatever you already do to protect other sensitive data in your dot directories, like GPG directories and web passwords stored by your browser. I use drive encryption.

The result is pretty good. Not perfect; the big missing feature is that it doesn’t know how to update your keys on sites like GitLab. That would take a custom method for each such site, probably implemented with curl. Perhaps in a future release.

Original URL:  

Original article

JQuery 3 beta released

The time has come. On this day, the 10th anniversary of jQuery, jQuery 3.0 has reached beta status. Last week, we announced the last minor releases to the 1.x and 2.x branches. Those branches will continue to receive patches for a limited time (i.e. only major regressions or bugs); jQuery 3.0 is the future. If you need IE6-8 support, you can continue to use the latest 1.12 release.

The Death of jQuery Compat


If you read the jQuery 3.0 alpha blog post, you might remember that we announced something we called “jQuery Compat”. You can forget that. On January 12, Microsoft dropped support for IE8, IE9, and IE10. We’re not going to go that far just yet, but we are dropping support for IE8. And with IE8, so goes jQuery Compat, gone before we even released a final version. There will only be one jQuery from now on!

Despite the 3.0 version number, we anticipate that these releases shouldn’t be too much trouble when it comes to upgrading existing code. Yes, there are a few “breaking changes” that justified the major version bump, but we’re hopeful the breakage doesn’t actually affect that many people. The jQuery Migrate 3.0 plugin, when released, will help you to identify compatibility issues in your code as well. Your feedback on the changes will help us greatly, so please try it out on your existing code and plugins!

You can get the files from the jQuery CDN, or link to them directly:

You can also get the beta version from npm:

npm install [email protected]

Major changes

Below are just the highlights of the major new features, improvements, and bug fixes in these releases. A complete list of changes is available on our GitHub bug tracker.

.show() and .hide() methods

In jQuery 3.0 alpha, we experimented with the idea of treating these methods like an inline-display-none-remover (.show()) and inline-display-none-adder (.hide()). This had the advantage of simplifying these methods greatly and improving performance (it required much fewer calculations). However, this proved to be problematic for our users. Removing inline display:none did not always show the element (if the element was hidden from the stylesheet, for example), and that is far too common. We realized we couldn’t provide a simple way for jQuery plugins, especially, to ensure that an element was shown.

We’ve since reverted that change, and the changes that we’ve kept for the show and hide methods should have much less of an impact on your code. In fact, even with the reversion, we’ve greatly improved performance for the case of hiding many elements.

Special case with `.data()` names

We have updated our .data() implementation to closer match the HTML5 dataset specification. All keys are now converted from kebab-case to camelCase, regardless of access method, and digits no longer participate in the conversion. For example, we will no longer differentiate between “foo-bar” and “fooBar”, but will differentiate between “foo-42” and “foo42”. These changes will mainly come into play when retrieving all data by calling .data() with no arguments, or when trying to access the data using a converted key (.data(“foo42”)) instead of the original (.data(“foo-42”)).

jQuery.Deferred is now Promises/A+ compatible

jQuery.Deferred objects have been updated for compatibility with Promises/A+ and ES2015 Promises, verified with the Promises/A+ Compliance Test Suite. This meant we need some major changes to the .then() method:

  • An exception thrown in a .then() callback now becomes a rejection value. Previously, exceptions bubbled all the way up, aborting callback execution and irreversibly locking both the parent and child Deferred objects.
  • The resolution state of a Deferred created by .then() is now controlled by its callbacks—exceptions become rejection values and non-thenable returns become fulfillment values. Previously, returns from rejection handlers became rejection values.
  • Callbacks are always invoked asynchronously. Previously, they would be called immediately upon binding or resolution, whichever came last.
  • Progress callbacks can no longer resolve Deferred objects to which they are bound.

Consider the following, in which a parent Deferred is rejected and a child callback generates an exception:

var parent = jQuery.Deferred();
var child = parent.then( null, function() {
  return "bar";
var callback = function( state ) {
  return function( value ) {
    console.log( state, value );
    throw new Error( "baz" );
var grandchildren = [
  child.then( callback( "fulfilled" ), callback( "rejected" ) ),
  child.then( callback( "fulfilled" ), callback( "rejected" ) )
parent.reject( "foo" );
console.log( "parent resolved" );

As of jQuery 3.0, this will log “parent resolved” before invoking any callback, each child callback will then log “fulfilled bar”, and the grandchildren will be rejected with Error “baz”. In previous versions, this would log “rejected bar” (the child Deferred having been rejected instead of fulfilled) once and then immediately terminate with uncaught Error “baz” (“parent resolved” not being logged and the grandchildren remaining unresolved).

While caught exceptions had advantages for in-browser debugging, it is far more declarative (i.e. explicit) to handle them with rejection callbacks. Keep in mind that this places the responsibility on you to always add at least one rejection callback when working with promises. Otherwise, any errors will go unnoticed.

Legacy behavior can be recovered by replacing use of .then() with the now-deprecated .pipe() method (which has an identical signature).

We’ve also built a plugin to help make debugging Promises/A+ compatible Deferreds. If you figure out that there’s some phantom error getting eaten, check out the jQuery Deferred Reporter Plugin.

jQuery.when has also been updated to accept any thenable object, which includes native Promise objects.

Added .catch() to Deferreds

The catch() method was added to promise objects as an alias for .then(null, fn).

Removed special-case Deferred methods in jQuery.ajax

jqXHR object is a Promise, but also has extra methods like .abort() so that you can stop a request after it has been made.

As users increasingly embrace the Promise pattern for asynchronous work like AJAX, the idea of having special cases for the Promise returned by jQuery.ajax is an increasingly bad idea.

success, error, complete
done, fail, always

Note that this does not have any impact at all on the callbacks of the same name, which continue to exist and are not deprecated. This only affects the Promise methods!

Error cases don’t silently fail

Perhaps in a profound moment you’ve wondered, “What is the offset of a window?” Then you probably realized that is a crazy question – how can a window even have an offset?

In the past, jQuery has sometimes tried to make cases like this return something rather than having them throw errors. In this particular case of asking for the offset of a window, the answer up to now has been { top: 0, left: 0 } With this beta of jQuery 3.0 we’re experimenting with the idea of having such cases throw errors so that crazy requests aren’t silently ignored. Please try the beta and see if there is any code out there depending on jQuery to mask problems with invalid inputs.

.width(), .height(), .css(“width”), and .css(“height”) to return decimal values (whenever the browser does)

Previously, jQuery rounded values when retrieving width and height. Some browsers return subpixel values – such as IE and Firefox – and sometimes users need this precision when relying on these values for layout. We don’t expect this change to have a big impact on your code, but let us know if it does.

Removed deprecated event aliases

.load, .unload, and .error, deprecated since jQuery 1.8, are no more. Use .on() to register listeners.

Animations now use requestAnimationFrame

On platforms that support the requestAnimationFrame API, which is pretty much everywhere but IE9 and Android<4.4, jQuery will now use that API when performing animations. This should result in animations that are smoother and use less CPU time – and save battery as well on mobile devices.

jQuery tried using requestAnimationFrame a few years back but there were serious compatibility issues with existing code so we had to back it out. We think we’ve beaten most of those issues by suspending animations while a browser tab is out of view. Still, any code that depends on animations to always run in nearly real-time is making an unrealistic assumption.

.unwrap( selector )

Before jQuery 3.0, the .unwrap() method did not take any arguments. The selector parameter offers a way to be specific about which wrappers to remove.

jQuery.fn.domManip no longer accessible

jQuery.dir, jQuery.sibling, jQuery.buildFragment, jQuery.access, and jQuery.swap were all privatized in jQuery 1.12 and 2.2. These methods, along with jQuery.fn.domManip, were always intended for internal use only and were never documented. We are finally making them private to avoid confusion.

Massive speedups for some jQuery custom selectors

Thanks to some detective work by Paul Irish at Google, we identified some cases where we could skip a bunch of extra work when custom selectors like :visible are used many times in the same document. That particular case is up to 17 times faster now!

Keep in mind that even with this improvement, selectors like :visible and :hidden can be expensive because they depend on the browser to determine whether elements are actually displaying on the page. That may require, in the worst case, a complete recalculation of CSS styles and page layout! While we don’t discourage their use in most cases, we recommend testing your pages to determine if these selectors are causing performance issues.

This change actually made it into 1.12/2.2, but we wanted to reiterate it for jQuery 3.0.

Original URL:  

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: