FAQ

The system operates by utilizing a series of photograph images from a high-speed video camera. A face is found (detected) within each image frame using our very own and unique in-house developed and patented algorithm for facial detection. The system then traps, extracts and frames (geometrically) the portion of the face from the outer edges of the eyes and then divides it into zones, and then mathematically coverts each zone into computational data. The combined data zones are then referred to as a template. At present, each template amounts in size to roughly 300 Kb of data. When the system is asked to perform a database search against the request of an incoming image, a new template is created for that new image and then a comparison search is performed for the new template against all the templates in the database. This yields a number of match coefficients that are collected from the performed search en masse. These are then categorically separated and bundled (clustered), analyzed, and the system runs the result coefficients against a preset threshold of identification and identifies which coefficients share the most similarities, or in other words, which of them correspond (match) to one-another the most.

Pretty much any scenario where a camera is utilized is also a scenario that facial recognition technology (FRT) can be applicable. The applications are vast, which is why listing them all is nearly impossible. We offer solutions by function, specifically detection, identification and verification. These functions operate in one of two possible major group scenarios known as cooperative and uncooperative. Cooperative refers to a scenario where the subject being captured on the camera image is interested in cooperating with the system; for example, to enter his place of work or residence. This means he or she will stop, face the camera if necessary, and so forth. Uncooperative refers to the opposite. The subject is not interested in being captured, whether through unawareness of the intention to capture him or her on camera or a deliberate intention not to be captured in spite of awareness, but still allowing that the subject is not taking any active countermeasures.

This wholly depends on the operating conditions. In cooperative scenarios Smilart’s platform operates at just about 100% effectiveness and the probability of false positives is close to zero. Reason being, our system sensitivity threshold is adjustable and can be greatly increased or decreased depending on setup, environment, etc. This is one of Smilart’s advantages and thus it is clear that our figures surpass any other competitive platforms on the market today. In uncooperative scenarios however, the probability of identification has to be considered as “passing through a properly designed environment” or in other words, through some kind of a correctly lit access point and hardware system (cameras, frames, etc.). In this case identification probability is once again adjustable depending on sensitivity threshold, but when preconfigured to the specified task works with virtually flawless accuracy!

This question is of particular importance and requires some much needed attention.

These are for better or for worse, a myth, especially when we are talking about camera images. Most FAR/FRR statistics are based upon so-called passport photos and not real life scenarios where the head of the subject has been prepositioned, proper lighting has been preset, and essentially the photos themselves are in no way related to real life conditions. Most of the data drawn from these types of images is based on photos that were taken by low quality industrial cameras with sensor noise and relatively cheap optics. The predictive analytics in such cases can be whatever you like them to be. It all depends on the input data and environment. Be wary of anyone claiming otherwise!

When considering real life scenarios instead, this question is like asking the blanket question, "What is the likelihood of an automobile accident?" You may notice there is not enough data in that question to answer it properly. For instance, where, when, how, what type of vehicle or conditions, and who is driving, are all missing.

In reality the input data determines the outcome. In order to get real results the test scenario for information such as this has to be preplanned and set up in advance and then tested, but then the results are based solely on that particular setup. Change this scenario by a fraction of a degree in any way whatsoever and those results change drastically. For example, a person at a distance walking fast and not looking into the camera under uncooperative conditions is not going to generate the same recognition rate data as someone looking directly into a camera while attempting to access a secured area. Another example would be to set up absolutely ideal conditions (hardware, lighting, distances, subject scenarios, and so on) and perform the test with the intention of getting optimal results, i.e. design the experiment to fit the conclusion, and then publish those results with the intention of confusing the customer into believing these results to be somehow universal. We feel this is wrong and believe it to be unethical, because the moment that test is performed again under different conditions those initial results become statistical noise.

To put it another way, to get near perfect results you need a highly controlled, properly planned, well designed and expertly installed environment. In that case our system beats out anything else on the market today. It is all about planning.

Cooperative and uncooperative scenarios have different minimal requirements; however, those too depend upon the function, customer need (what are you trying to accomplish?), application and environment. There is no one universal answer. For more information, please contact one of our specialists at sales@smilart.com and we will be happy to take our personal approach in helping you understand these requirements based upon your individual circumstance and goals.

As with lighting (see above), this all depends on your environment and requirement. Cameras can range in price and quality and so can lenses. Frame rate necessities and angles all come into play. For instance, we often recommend that for a very generic, uncooperative scenario through one access point, that two medium quality cameras be installed or one with an exceptionally high frame-per-second rate (fps). This is necessary in order to generate high quality images that are not blurred under conditions where the subject is passing the image capture point rather quickly. This raises the probability of image capture exponentially. Using two cameras allows capturing images from different angles and in different geometric perspectives, thus again raising the identification probability. With that said, every situation is different.

Any scenario is workable and a proper configuration can be developed for just about any purpose at all, so in order to understand what the optimal setup is for you, please contact us at sales@smilart.com.

It all depends on the setup. If we take generic conditions then with the use of a very cheap video gaming card images can be processed in as little as 20 to 24 milliseconds. This rate is by far the fastest in the world. A generic scenario assumes that a graphics coprocessor (GPU) can handle up to 110 fps (each about the size of 2 megapixels) on a single card. In that case a cooperative identification scenario on a single video card can handle up to 5 cameras and in an uncooperative scenario, one camera. The performance of the system is therefore a function of the number of video cards. The type of processor does not play any significant role. Basic i5 or i7 as well as industrial grade (XEON) processors all do the trick equally well.

If your required (or desired) number of video cards exceeds the allowable space on a single server then you may need to add hardware. Additionally, opting to add servers and thus more video card capacity will improve system reliability through load distribution as well as by adding longevity and reducing or eliminating system failures. Ultimately your purpose will dictate hardware requirements so the answer is that it all depends on what you hope to achieve. Server clusters are only necessary if your objective requires it. Planning is key.

Important note: we do not charge extra for additional hardware!

In contrast to our competitors, the Smilart system conducts what’s called “automated enrollment”. In other words, our software platform is smart. Syncing with our own in-house tailored operating system the technology works through our algorithm to autonomously select the best images and angles of the object within the group of incoming images to produce an optimal template against which the enrolled subject will later be identified or verified. Simply put, push a button and leave it alone. Our software does all the thinking on its own.

By comparison to how FRT software is generally sold by our competitors our pricing is very straightforward. We license our technology based on two primary factors: database size and power. Database size refers to the number of enrolled individuals your organization will have and the power refers to the number of GPU video cards you require. That’s it!

Since we do not have any complicated pricing plans that touch on every microelement, and because our software works with generic gaming GPUs, when compared, we are competitively priced to any other vendor.

A very important point to note is that we are the vendor.  Many products claiming to be original FRT platforms on the market today are actually products that have been developed on top of a third party vendor platform. This adds to customer’s pricing for such products due to outside vendor costs. Not with us!

Equally important to note is the difference between academic level (or backyard-built if you will) original platforms and what we call an “industrial grade” FRT platform. Many of the so-called original platforms out on the market are often designed for “corner store” use and are non-brand name algorithms that are fine for a one-camera, low processing application designed more for exceptionally simple use. They are often slow and unreliable as well as incapable of handling large amounts of data processing. In other words, they are unable to handle anything requiring high surety at the enterprise or large organization level and are made for the individual. In the case of industrial grade, to date there are only a small handful of real vendors with their own patented platform.

Support is included for as long as you use our solutions. We do offer professional services and consulting in order to help you design and construct the proper hardware infrastructure if you so desire, as well as any other partnership related services that may be contracted in case you are interested in developing or co-developing products based on our platform, and those are per quote.

Yes. We have a large and dedicated staff of some of the brightest minds in the world on staff full-time; however, depending on each customer’s geographic location and the applicable laws and standards within each region and country, we are always open to cooperation with your local IT professionals to accommodate our support services to fit your needs. Contact us with any additional questions regarding local support at marketing@smilart.com.

We have a dedicated staff of developers, testers and engineers actively working with our customers, as well as an entire department dedicated to expansion and creating new technologies. We offer professional services and further development to include modular adaptations, appending elements of application interface (API), creation of new interfaces with external, closed systems, support for new hardware, and other services. We not only offer our services, we welcome your ideas and can help you realize them and cut costs. Please contact us to discuss any potential partnerships or collaboration together at marketing@smilart.com.