Posted under Biometrics, Identification on May 24th, 2013 by Alex
Most people who work in the field of Artificial Intelligence come away with a healthy respect for the miracle of human intelligence. Humans are wonderful at certain kinds of tasks, and trying to make computers do them well is extremely frustrating. I would like to talk today about the ability of humans to recognize faces. We are genetically wired to recognize faces, so it is no real surprise that we can do it well. Recognizing mom’s face leads to better survival.
When I work with computer face matching, people will come to me with two pictures that the computer says don’t match and ask me “Why don’t these match?” I look at them and they are an obvious match. But I am seeing them with human eyes, not computer eyes. Computers don’t recognize face even remotely the same way we do. To a computer, a face is just an square array of pixels (dots) of different colors. Let’s look at some examples:
These two pictures are reduced to about the size of a driver’s license photo. I am sure that 100% of the people out there will recognize that this is the same person, and the same pose. If you are discriminating, you might be able to tell which picture is higher quality. But if you just glance, you may see them about the same. However, they are not really the same at all.
Let’s enlarge them.
Now you can probably see some differences between the pictures. Look at the finer strands of hair at her scalp. You can probably tell which image is more compressed. But overall, they really look pretty close to being the same. No human would ever have a problem being able to tell that there the same person and same photo.
However, I am going to give you a glimpse into what the computer sees. Let’s zoom in to just her eye:
In these images you can see the individual pixels of color. These images are the same resolution, but one image clearly contains a lot more information that can be used by the computer than the other one. The higher quality image is 1.2 MB and the lower quality image is 150 KB, a factor about 10X. (not that a bigger file necessarily contains more information)
Your brain kind glosses over this lack of information. You see eyes in both pictures, and one is lower quality than the other one, but your brain knows it is an eye and fills in the detail for you. You are not really conscious of it. But to a computer, these images are very, very different, and will not match.
Let’s look at one final example. The “high resolution” picture I used in this blog post was actually compressed in order to make it palatable for the Web. The original image was about 10 MB. Here is the same eye from the original image:
You can see that this image has a lot more detail, and more information usable by the computer for face matching.
This is why we say you can’t trust your eyes when evaluating whether a picture is good for face matching. Your brain lies to you. You have to zoom in to the pixel level to see what the computer sees.
Posted under Biometrics on May 3rd, 2013 by Alex
I sometimes get asked to show someone how big a graphic is “at full size” and this request always confuses me because fundamentally, images don’t really have a size, per se. An image is an array of pixels, which don’t have sizes. Let’s look at the Beehive Logo, which is 899 pixels wide by 153 pixels high.
It looks like a complete picture, but it is actually composed of individual pixels, which are the smallest possible element of the picture. Here is a zoom view of some pixels around the ‘b’ with a single pixel colored black.
As an aside, if you notice the weird patterns of different shades of gold, that is anti-aliasing. It is designed to fool your eyes into seeing a jagged thing like this as a smooth curve. Anyhow, I know exactly how many pixels our logo has, but I can’t tell you how big it will be on your screen, or if you print it out. I am currently on a laptop that is very dense – 1920×1280 pixels, but it is a small (13”) screen. The logo is small on my screen. On yours, it is likely to be different. That’s because it doesn’t have an actual size, it just have pixels.
However, all is not lost. There is a property of an image called dpi – dots per inch. You can think of this as a “suggestion” of how the image should be sized. This is available as a file property in Windows 7, but they dropped it in Windows 8. You can see it in an image editor, though. Here it is in the “Image Adjustment” dialog in Photoshop.
This shows the image is 72 dpi, which is typical for the vast majority of images. 72 dpi is a typical screen resolution. That means on a typical screen (not every screen), this image will be 899 pixels / 72 dpi = 12.5 inches, as shown here. However, when I look at the logo in 1:1 zoom on my computer, it isn’t that big. That’s because my monitor isn’t 72 dpi, it is 108 dpi So, this logo is closer to 8 inches. As you can see, there is no absolute size to this image. There are pixels, and dpi, which provide an idea on size, but not an absolute size.
So what does this have to do with biometrics? A lot, actually. When we compare fingerprints, we are looking at the X and Y locations of minutiae points – ridge endings, splits, etc. In order to compare them, we need to know absolutely where they are, none of this “dpi suggestion” stuff like in the previous example. We need to know exactly where each point is. Luckily, the FBI solved this problem a long time ago, because they have a selfish interest in trying to make it easy to collect and compare fingerprints. They (along with NIST), established a standard that says all fingerprints are collected at 500 dpi. That is a different kind of measurement that in our logo example, because it is an indication of something collected from a scanner. So, we know for sure that 500 pixels is 1 inch. So, if a particular point is at the location (250,250), we know that point is at the location 1/2”, 1/2” on the finger. So, we can compare all fingers along the same scale.
You can see this in the following illustration of matched points. We still have to deal with rotation, but that is not too hard.
Face matching and iris matching are totally different, though. They do not rely on X,Y positions of points, so dpi is not important, just pixels. Additionally, faces and irises have easily locatable marker points that provide a basis for positional information. For faces, it is the eyes, and for iris it is the pupil. This allows faces and irises to be compared on the same scale without requiring precise DPI for collection.
In short, pixels have no absolute size, nor do images. The only thing that establishes a relationship between an image and anything approaching a real size is to know the dpi of the sensor that acquired a particular image.
Posted under Programming, Start up on April 19th, 2013 by Alex
As a CTO, I try to focus more on the technology than the latest craze in entrepreneurship, but one of the things that has really resonated with me is the notion of the Minimum Viable Product. You can read more about it at that link, but here is the key part – “The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
I think most software developers hear this and think “Oh, they want me to make a crappy slapped-together product”. That’s not really the case.
I just now realized this is a play on “You go”. Much better than Nova.
This hits a nerve with devs because they are almost always under some time pressure and often feel like they are being forced to cut corners in order to get the product out the door. However, I would make the case that the MVP is not software in the conventional sense that we are used to thinking about software.
I’m going to try an analogy. Let’s say you are hired to build a set for a 50’s era sitcom, set in bland, boring suburbia. The company wants you to build the house that will be used in the opening credits – showing the kids coming home from school, etc. This house is just shown in an exterior shot; all the real stuff will be done on a sound stage.
I’m so glad I don’t have to wear a tie to dinner.
In this case, what is your objective? Is your goal to build a house to code? Do you want this house to be able to last for 50 years? Should it be waterproof? Should it have a 200 AMP circuit installed?
The thing to realize here is that you aren’t building a house. You are building a “house”. In other words, you are building something that looks house-ish for a very specific purpose – to look like a house on camera. All of the requirement for a real house (code, longevity, etc.) are irrelevant. The only thing that is relevant is whether it looks like a house on camera. Now, there are some real house things you may want to do. For example, you may need to build the front steps to code because we are going to be doing a lot of shots of the kids bounding up the front steps. But that doesn’t translate to the rest of the house needing to be up to any code at all.
Now put yourself in the role of the studio hiring someone to build this facade. Which would you rather hire – a professional home builder, or someone who builds sets? Which one is more likely to be able to build the minimum thing I need?
The important thing to understand for devs building MVPs is that you are not building a house. You are building a set. The point of an MVP is not to be good software or elegant – it is to learn something quickly. You have to throw a lot of what you know about building software out the window, just like a professional home builder would have to ignore a lot of his training in order to build a movie set. Your software will be ugly behind the scenes, and that’s OK. In fact, it is wonderful. You will incur a lot of technical debt building the MVP, but that is fine. You won’t have to pay it back. This is what the “back” of your software should look like:
And don’t use those good 2x4s either. Do you think I’m made of money?
Here are some guideline I use when building MVPs:
If there is an existing library that does 90% of what you need to do for a particular function, figure out a way to adapt your product to use it.
1. Avoid writing libraries at all costs.
2. It is better to cut-and-paste code than get sucked into building a general purpose library.
3. Use the technology you are most familiar with. The people trying your software don’t care what language you use. You would be amazed by their lack of caring on this point.
4. You won’t need dependency injection. That helps with modularity and maintenance. You won’t be doing much of either of those things.
5. If you start to think “Wouldn’t it be cool if..” or “I bet the users would love to…”, then hit yourself in the head with a trout. The M is for minimum. You can do those things later once the users actually tell you they want those things.
6. Don’t create any kind of admin functionality for your software (unless that is what the users are going to use) Configure it with XML files or even just text files.
7. Don’t worry about documentation or comments. You aren’t passing this software on to someone else to maintain.
8. If you have extra time, spend it on metrics and data gathering, built into your MVP. Don’t spend it on making your software elegant.
9. Within reason, make sure your software works reliably. It is better to have something that is a little ugly that works, than something beautiful that crashes all the time.
10. Use iconfinder.com to find graphics. Don’t hire a designer, and for the love of God don’t do the artwork yourself.
But this leads me to a final guideline for any suits who happen to read this. Understand that the MVP is not a product, even though it looks like one. You might be able to convince people that a home on a movie set is real, but they won’t be happy living there. Plan to throw away your MVP and start over, building “real” software. On the plus side, all the stuff you learned will make this go a lot faster.
This is what happens if you try to move your MVP into production.
In software, we are very fortunate to be able to easily build MVPs. Imagine if the car industry could build a prototype car in a few weeks and let people try it out. They would love to be able to do that. An MVP is a fantastic tool for learning about your users, what they want and what they don’t. Just don’t mistake it for actual software, no matter how much it may look like it.
Posted under Identification on April 5th, 2013 by Alex
My business partner and I are going to be in Seattle as part of the Microsoft Accelerator for Windows Azure powered by Tech Stars program – for three months. Being an unfunded start-up means we need to find a reasonably-priced, short-term, furnished apartment because three months in a hotel is not in our budget. So, of course we turned to the Internet for help. Eventually, we found a good place on a “vacation rental by owner” website, and contacted the owner via email. We worked out an amenable price, and as we were figuring out the next step, he mentioned he was in Austin for SXSW, and that we should meet. Great! I’ll call him Bob.
Not really Bob.
Bob was really nice and seemed totally normal. We had a nice discussion about work, family, all that polite stuff. We talked about the apartment, about Seattle, about the terms of the agreement and all seemed totally normal.
And then we gave him a check for several thousand dollars.
So here is what we really know about Bob:
1. He can enter text and pictures into a Website
2. He is charismatic in person
I’m an engineer who often works in the security arena, so I can’t help but think of paranoid, worst-case scenarios.
Here is where I imagine our money ended up.
I started thinking about all of the things that we were inferring about Bob:
1. He actually lives in Seattle
2. He actually works for the respectable place he said he worked for
3. He owns the apartment he rented out to us
4. He doesn’t have secret cameras installed all over the house to record our private activities for www.buttscratching.com
We used our human intuition to infer these things, and many others. That works really well a lot of the time. However, people who want to rip you off know how human intuition works, and they know how to take advantage of that. I was thinking of how I would explain this to my father, if it turns out Bob ripped us off:
“See, Dad, there is this thing called the Internet. A bunch of people communicate with each other via their computers. No, they don’t know each other. Anyhow, we met a guy on the Internet who had an apartment for rent and then we gave him some money. No, we didn’t know him. No, we didn’t know anyone who knew him. But he had an ad on a website. A website is kind of like an electronic flyer…”
Now, if Bob had come recommended by an actual trusted friend, I wouldn’t have any concerns at all. Trust weakens somewhat via transition: If trust Adam 100% and he trusts Bob 100%, I might trust Bob 80%. But it is still a pretty high level of trust.
I’m not actually worried about getting ripped off by Bob. But my reason for not worrying seems to be more laziness than actual trust. It would be nice if we had some way of really identifying who we were dealing with in this Internet world.
The Value of Getting Stuck
Posted under Programming on March 12th, 2013 by Alex
I have been working on learning Microsoft Azure lately. Generally, the way I work with any new technology is to go through online or book examples, and then try to diverge from them in order to learn my way around. One of the challenges with debugging an unknown technology is knowing which things cause other things. If something isn’t working with an unknown technology, you don’t always know the cause, and often it is not obvious at all. To that end, I will try to intentionally screw things up in order to cause problems. That helps build up my internal “library” of cause and effect, which I know will be valuable later. Generally, if you change one thing and your system breaks, it is because of that last thing you changed, no matter how improbable. That’s an important part of the of the learning process.
Azure is a very developer-friendly technology. It does a great job of mimicking the desktop environment, and I was actually having trouble causing “interesting” problems. All of the examples I worked through were very straightforward and the errors I got/caused were very clear.
And then I got stuck. Really stuck.
I had a problem with the Azure service bus. It was dropping about 2/3 of the messages that I was sending. That was very odd. I could debug 0 messages, or 100% of the messages, but I couldn’t figure out what in the world would cause it to drop 2/3 of the messages. This forced me to explore way off the “garden path” that I had been exploring before, to try to figure out the cause. I spent around 4-5 hours on this, trying all kinds of things, none of which worked, but the process got me into all the dark corners of the technology that I had been able to ignore previously. The actual cause ended up being some wonky thing with the service bus itself – I just created a new bus an everything worked.
In the past, I would have seen this as a very frustrating experience. But after learning dozens of new technologies over the years, I have realized that this is a necessary part of the process. You only learn the breadth of the technology when you go through the pain of getting really stuck.