I am using microsoft cognitive service face API for my project for face recognision.
I want to add 1000+ faces in the single "FaceList" instead of creating 64 different face lists.
I will have more than 10,000+ users in a group. Then I want to use "Find Similar" API with all my photos in the same "FaceList" to find match faces.
Is there any way to achieve this functionality?
Unfortunately, A face list still can have a maximum of 1000 faces for now. Also, you can only specify one unique candidate face list in the Find Similar request API for now.
We realize that it's very important to customers and Face API is more popular today. Azure cognitive Team has paid attention to this . You can also upvote this idea in this UserVoice Page. If Cognitive Team has any process on this, you will be noticed.
Hope this helps!
Alternatively, you can create a personGroup then add the 1000+ face to the persons in this personGroup. And then use Identify to find the person matches with your input image.
The S0 tier subscriptions have these limits: 10,000 Persons per Person Group, 100M Persons total and 1M Person Groups per subscription.
Related
I recently started studying ADB2C.
Therefore, I would like to know the maximum number of users I can register with ADB2C.
You can create 50M+ users. You do not need to contact Microsoft. AAD B2C tenants auto scale for number of objects.
You are not charged for users. You are charged for unique authentications per month.
Microsoft will happily bill you for as many users as you want past the 50,000 free threshold. https://azure.microsoft.com/en-us/pricing/details/active-directory/external-identities/
I believe I am misunderstanding how this API works...
I understand that Person Groups contain Persons which contain Person Faces.
And to use Face - Verify, I compare the new image FaceId to the personGroupID and personID.
However, I don't seem to understand how/where the Person Groups are saved.
Are all Person Groups saved within one JSON and can be stored in blob storage or a DB?
Thanks in advance.
P.S. using Node.js
The PersonGroup Create API is a little different in that the caller specifies the ID. Regardless, this ID is stored in the Cognitive Services storage, along with all related information such as the people who comprise this group. The exact nature of the storage is intentionally opaque.
You can list the PersonGroup's associated with your API key with List API.
If you're looking for sample code in NodeJS, you can find some here.
In azure face api we create a person and add face to person and we can identify same person.
My question is when we add face to person does azure upload and save image on azure or just it stores mathematical attributes of person'a face.
Based off the documentation, it appears the image is stored on Azure - https://dev.projectoxford.ai/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f30395236
Azure Cognitive Terms of Service suggest they may also keep the file to improve service. See Part D, number 4 - https://azure.microsoft.com/en-us/support/legal/cognitive-services-terms/
It depends on what you are doing. If you are running the identify and detect APIs, it will delete after 24 hours:
"Will expire 24 hours after detection call." https://learn.microsoft.com/en-us/connectors/faceapi/
If you create a person group and add faces to the person, it adds it in a thing called persisted face ID. This is persistent and will not delete until you delete it
As at January 2020, "no image will be stored".
REF: https://westus.dev.cognitive.microsoft.com/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f30395236
Hash-keyed, irreversible vector representations of faces are stored, as follows:
Detection API: 24 hours
(Large)PersonGroup: persisted until deleted by client
BUT, Azure Cognitive Services reserves the right to use data for service improvements:
Ts&Cs are Section D of https://azure.microsoft.com/en-us/support/legal/cognitive-services-terms
Some technical details:
The vector representations should/will never be exposed or the models could be reverse-engineered - see e.g. https://blog.floydhub.com/inverting-facial-recognition-models
There is a HOWTO on vector-embedding creation at e.g. https://machinelearningmastery.com/how-to-develop-a-face-recognition-system-using-facenet-in-keras-and-an-svm-classifier
While using the Azure Portal website(portal.azure.com) to view Azure AD group members, the site only returns a list of the first 100 group members without any sort of prompt/button for a second page.
In my case the group contains 145 users, but as its only showing the first 100 it looks like there are people missing.
Is there a way to have it display the full list of members?
If not and this is a bug, is there a known bug tracking for this so that I can keep tabs on it?
It seems a disadvantage in Azure AD new portal(portal.azure.com) , but you could use Azure AD classic portal(https://manage.windowsazure.com) to manage the full list of members, it works well :
If you have any feedback about Azure , you could post to https://feedback.azure.com/forums/34192--general-feedback
Update
Now the new portal has the "Load more" button which could continuously load users.
I want to say that this is not a Bug but a designed behavior. Please review link and you'll see:
The following restrictions apply to paged requests:
The default page size is 100. The maximum page size is 999
The only way you can do this is via an actual REST API Call and use $top = 999 in your query. Also Azure Classical Portal is an option here, just like Nan answered as it's using pages.
We have a Salesforce app where we have some custom objects and want to expose the various custom object rcords to customers.
We need to ensure that customers can see only the records belonging to their Account. Because of the way these records are setup(owned by various system users at different levels of processing), we cannot use owner based sharing...and cannot use criteria based sharing since its not dynamic(I cant use criteria based sharing to say "Share this record with all customer portal users who belong to the same Account as the record" at runtime).
So I know I have to use Apex based sharing. I have read up on the sharing objects and the sharing table. But how would I approach this.
I can write a trigger which upon inserting will create a share object and get all userids who belong to the customer portal group and whose account equals the account of the record and associate them with the share object of the record.
But I feel this is overkill correct? Lets say there are 5 users from one of our customers and lets say there are 500 records created a day...that means 2500 share objects a day just for 1 customer...for 10 customers this can go upto 25000...and scale in this way...
Am I right here?
Another problem would be if a new person joined that customer team..unless another process updates the sharing on older records, he/she cannot see the older records.
So is there a better/elegant way to do this? I thought of adding a share object to the group...but there is just one group "Customer portal group" and how do I associate the group with the account of the users?
I will appreciate any thoughts about this.
You should take a look at high-volume customer portal users. They're much cheaper relative to standard customer portal users and should meet your needs. Unlike regular users they have a totally different sharing concept. In a nutshell if they own an object they can see, if not they can't. You can then extend this based on whether a contact or account lookup on the object matches the logged in user.
Read up on this documentation:
License Types (scan to High Volume Customer Portal)
Granting High-Volume Portal Users Access to Records (login required)
You can use groups for sharing to avoid creating so many sharing records. You would have one group per account and one sharing record per account. Instead of managing thousands of sharing records you would have to manage hundreds of groups.
I haven't tried this approach with this many groups, but I read some time ago that it should work (someone posted using a LOT of groups for sharing). If you do try this, please tell us if it worked OK.