When Facebook asked Buddha to be Tagged

Facebook has this face recognition feature. It automatically recognizes faces in uploaded pics and then provided the option to tag the faces that its software has managed to recognize in those images. It is very successful most of the time. Face recognition is a very active field of research with many groups working on it. It is now part of security systems, the simplest example being laptops that have facial recognition feature for unlocking.

 Now, take a look at the image below. It shows two statues of Buddha at the 10,000 Buddha temple in Hong Kong.

 

When it was uploaded to FB, the software identified the two faces in this photograph and asked for tags! It was quite a surprise for me and it made me realize a limitation with existing facial recognition technology. Existing technology cannot differentiate between real human faces or faces which are part of a “non-human” element. This is one reason why facial recognition technology is known to be fooled using images. One can login to a system by showing an image of the person with authorized access. This was discussed by USA Today here. This is also the reason why high security establishments may go for multi-modal authorization in which facial recognition is just one part.

I guess for facial recognition technology to be truly a single point solution for authorization, it will have to learn to distinguish between human and non-human elements. The road ahead has a lot of interesting challenges!

Do you read User Guides?

I am a member of LinkedIn and like many of you am also a member of quite a few LinkedIn groups. The good thing about LinkedIn groups is that the discussions remain professional in tone and content. This is why I like them compared to discussions on other social media platforms where they can vary in tone and content from the most professional to the most ridiculous. In a discussion on such a LinkedIn forum meant for engineers, someone admitted that very few engineers or users of tech tools read the user guides. This is not far from reality. I have seen this when I interacted with practicing engineers on a more regular basis than now. I also see it in academic life.

Personally, I find user guides of development boards, software and hardware tools extremely useful. Reading them once gives me enough confidence in extracting the best out of these tools. For instance, user guides of FPGA vendor providers are very helpful and I am more confident about my design after having referred to the user guide at least once though often these guides can be voluminous. I guess the verbosity of these guides is one main reason why people don’t feel like reading them. The other reason, I think, is the propensity of many practicing engineers, graduate students and others to get  their hands dirty as soon as possible. They want to write code, design a circuit, run simulations etc. without getting bored reading these guides. While this enthusiasm to start working is worth appreciation, ignoring the “reading” part leads to problems later on in the product development process, research methods and has the potential to creep into the results. Basically, this haste leaves one vulnerable to questioning at a later stage. Sometimes this can prove very costly as well especially if it is related to product development. Of course one can always talk about pressure for results from managers, supervisors, customers etc.; this is not a very good excuse. Good managers etc. also understand the importance of being abreast with background information.

Is this issue observed more in the engineering industry than say banking or insurance sectors or for that matter safety critical engineering domains? Perhaps. Engineers take great pride in fixing things. They can use patches for software, make new releases, change components or simply replace the product.  However, bankers and insurers cannot do much once money is gone. The fear of losing money is too great to sustain the dislike for reading guides, whitepapers etc. Similarly those involved with safety critical engineering domains are more mindful about liability issues that aversion to poring over thick user guides is probably a non-issue.

One can also argue that  the presentation style of many user guides is quite boring. I agree when you compare with things that provide “instant thrill” thus leading to a desire to know more. User guides do not provide that thrill but writing code, experimenting with a development board etc. does give a lot of thrill to many engineers. Nevertheless, when it comes to getting a job done properly, there is no other choice but to sweat it out! 🙂