Kairos enroll API returns confidence in the response. What does it mean? - image-uploading

I am exploring Kairos Facial Recognition APIs. The API /enroll is used for uploading an image to Kairos for a subject_id. I noticed that the response of enroll API contains a confidence score. The image is treated as a new image. What does this confidence mean? When you verify an image, in that case the confidence score is important. But while uploading an image, why does the API return a confidence?
I assume, the API compares the image to the images uploaded before for that subject_id and returns the confidence. Is this the case or is it something else?
API Documentation: API_docs.
Here is a sample response for reference:
{
"face_id": "f2f0f8de43e545f8aff",
"images": [
{
"attributes": {
"age": 40,
"asian": 0.13225,
"black": 0.00103,
"gender": {
"femaleConfidence": 0.00028,
"maleConfidence": 0.99972,
"type": "M"
},
"glasses": "None",
"hispanic": 0.09578,
"lips": "Together",
"other": 0.27899,
"white": 0.49195
},
"transaction": {
"confidence": 0.99932,
"eyeDistance": 30,
"face_id": "f2f0f8de43e545f8aff",
"gallery_name": "ps-recognize",
"height": 70,
"image_id": 1,
"pitch": -14,
"quality": 0.10107,
"roll": -4,
"status": "success",
"subject_id": "vinod-khanna.&**#~`%$#_=+/",
"timestamp": "1526029231708",
"topLeftX": 124,
"topLeftY": 42,
"width": 70,
"yaw": 1
}
}
]
}

Yes, this isn't clear from the documentation.
For /recognize and /verify the confidence % represents how similar the face sent in with the request is to the the face being compared against.
For /detect and /enroll the confidence represents how confident the engine is that it found a face. Usually you will see 98-99 percent range for those values.
Disclosure: Kairos.com CTO

Related

Documentation on HERE api responses

I am using the Routing API v8 to get instructions on how to get from one point to the other. I want to provide the user with a time and distance estimate.
Still trying to figure out how to get the distance, but for the time, I have been adding the "duration" fields but the result is very different from what I experience in that route. Additionally, there are also other fields in the response that I am not very sure about their meaning. For example, in the below response:
...
"actions": [
{
"action": "depart",
"duration": 133,
"instruction": "Head northwest on Flint Close. Go for 124 m.",
"offset": 0
},
{
"action": "turn",
"duration": 168,
"instruction": "Turn right onto Vicarage Lane. Go for 158 m.",
"offset": 3,
"direction": "right",
"severity": "quite"
},
{
"action": "turn",
"duration": 234,
"instruction": "Turn left onto Deanery Road. Go for 233 m.",
"offset": 9,
"direction": "left",
"severity": "quite"
},
...
What does the offset property mean? Is there somewhere where I can find more information on these?
Regarding to the properties, you can find them in the OpenAPI specifition document here
E.g., for "offset", it is a property for a few actions (like TurnAction in the spec),
offset:
description: Offset of a coordinate in the section's polyline.
type: integer
Regarding to distance, it should be in the summary section.
For a route which duration is not expected, we will need a deeper analysis. Please provide the exact API call you used in the comment, and we can run a check on that.
Also, please feel free to try our refclient here for a quick feeling of our Routing APIs and varies parameters.

Uber API GET/estimates/price response surge_multiplier disappeared

today, I found GET/estimates/price end point have a change, surge_multiplier disappeared, is to say, price has been fixed, no more surge?
Surging is based on the particular location and product setup - so if you try following request for example:
https://sandbox-api.uber.com//v1.2/estimates/price?start_latitude=-33.865535736083984&start_longitude=151.1958770751953&end_latitude=-33.88345718383789&end_longitude=151.0906982421875
"prices": [
{
"localized_display_name": "uberX",
"distance": 7.76,
"display_name": "uberX",
"product_id": "2d1d002b-d4d0-4411-98e1-673b244878b2",
"high_estimate": 35,
"surge_multiplier": 1,
"minimum": 9,
"low_estimate": 26,
"duration": 1260,
"estimate": "A$26-35",
"currency_code": "AUD"
},
If you try it for different location:
start_latitude=37.7752315&start_longitude=-122.418075&end_latitude=37.7752415&end_longitude=-122.518075
You will get response without 'surge_multiplier' parameter:
{
"localized_display_name": "uberXL",
"distance": 6.62,
"display_name": "uberXL",
"product_id": "821415d8-3bd5-4e27-9604-194e4359a449",
"high_estimate": 28,
"low_estimate": 22,
"duration": 1380,
"estimate": "$22-28",
"currency_code": "USD"
},
For more info on surging please read our documetation
EDIT done on 02/15/2018:
If you are using v1.2 request - response we are getting is based on the product setup. If the product used in the estimate request is configured to have "upfront_fare_enabled": true then we will get one fare_id - instead of estimate. So this is expected as in v1.2 with upfront_fare_enabled: true there will never be surge information (as you get a real fare + fare_id).
Please check following sentence from our documentation on "POST /v1.2/requests/estimate" endpoint:
You should use this endpoint to get an upfront fare before requesting
a ride. In some products upfront fares are not enabled so you can use
this endpoint to determine if surge pricing is in effect for the
product/location. Do this before attempting to make a ride request so
that you can preemptively have a user confirm surge by sending them to
the surge_confirmation_href provided in the response. This endpoint
will either return an upfront fare (in the fare key) or a range
estimate (in the estimate key) depending on the configuration of the
product.
So the response you are getting back depends on product configuration specifically: "upfront_fare_enabled" field. If there is upfront fare setup (upfront_fare_enabled = true) then there will not be "surge_confirmation_href" available in the response - and response type will be one "fare": {} response - example of this is below:
{
"fare": {
"value": 5.73,
"fare_id": "d30e732b8bba22c9cdc10513ee86380087cb4a6f89e37ad21ba2a39f3a1ba960",
"expires_at": 1476953293,
"display": "$5.73",
"currency_code": "USD",
"breakdown": [
{
"type": "promotion",
"value": -2.00,
"name": "Promotion"
},
{
"type": "base_fare",
"notice": "Fares are slightly higher due to increased demand",
"value": 7.73,
"name": "Base Fare"
}
]
},
"trip": {
"distance_unit": "mile",
"duration_estimate": 540,
"distance_estimate": 2.39
},
"pickup_estimate": 2
}
As you can see there is no "surge_confirmation_href" available.
If your product has "upfront_fare_enabled": false you will get estimate response with surge_confirmation_id and surge_confirmation_href as shown below:
{
"estimate": {
"surge_confirmation_href": "https:\/\/api.uber.com\/v1\/surge-confirmations\/7d604f5e",
"high_estimate": 11,
"surge_confirmation_id": "7d604f5e",
"minimum": 5,
"low_estimate": 8,
"fare_breakdown": [
{
"low_amount": 1.25,
"high_amount": 1.25,
"display_amount": "1.25",
"display_name": "Base Fare"
},
{
"low_amount": 1.92,
"high_amount": 2.57,
"display_amount": "1.92-2.57",
"display_name": "Distance"
},
{
"low_amount": 2.50,
"high_amount": 3.50,
"display_amount": "2.50-3.50",
"display_name": "Surge x1.5"
},
{
"low_amount": 1.25,
"high_amount": 1.25,
"display_amount": "1.25",
"display_name": "Booking Fee"
},
{
"low_amount": 1.36,
"high_amount": 1.81,
"display_amount": "1.36-1.81",
"display_name": "Time"
}
],
"surge_multiplier": 1.5,
"display": "$8-11",
"currency_code": "USD"
},
"trip": {
"distance_unit": "mile",
"duration_estimate": 480,
"distance_estimate": 1.95
},
"pickup_estimate": 2
}
And finally, if you update the product to have "surge_multiplier" > 1 and product have "upfront_fare_enabled = true" you will get "fare" response - but you will not know that surging is in place - until you do ride request. In this case, you will get the response with: "status": 409 and "title": "Surge pricing is currently in effect for this product." and "surge_confirmation" info that contains "href": "https://sandbox-api.uber.com/surge-confirmations/ride_request_id". So in order to complete your ride request - you need to redirect your user to that URL - and user needs to confirm surging. After that, you will be able to create new ride request.
resposne->
{
"meta": {
"surge_confirmation": {
"href": "https://sandbox-api.uber.com/surge-confirmations/48165d0e-f2f4-457d-98d0-058a31b15cd7",
"expires_at": 1510684778,
"multiplier": 1.2,
"surge_confirmation_id": "48165d0e-f2f4-457d-98d0-058a31b15cd7"
}
},
"errors": [
{
"status": 409,
"code": "surge",
"title": "Surge pricing is currently in effect for this product."
}
]
}

Why do I get two UberPool products in the APIs?

I get two UberPool products in the following APIs:
api.uber.com/v1/estimates/time
api.uber.com/v1/estimates/price
api.uber.com/v1/products
Why do I get two products? How are they different?
Example response:
Url:
api.uber.com/v1/estimates/price
Response:
{
"prices": [
{
"localized_display_name": "uberPOOL",
"high_estimate": 33,
"minimum": null,
"duration": 0,
"estimate": "₹32.50",
"distance": 0,
"display_name": "uberPOOL",
"product_id": "e0178e76-b13f-4ae6-9f72-6acadbb450c5",
"low_estimate": 32,
"surge_multiplier": 1,
"currency_code": "INR"
},
{
"localized_display_name": "uberPOOL",
"high_estimate": 51,
"minimum": null,
"duration": 0,
"estimate": "Unavailable",
"distance": 0,
"display_name": "uberPOOL",
"product_id": "f855a84b-a0ec-40d8-a455-fb0d2db58089",
"low_estimate": 50,
"surge_multiplier": 1,
"currency_code": "INR"
},
{
"localized_display_name": "uberGO",
"high_estimate": 50,
"minimum": 50,
"duration": 0,
"estimate": "₹50",
"distance": 0,
"display_name": "uberGO",
"product_id": "18ba4578-b11b-49a6-a992-a132f540b027",
"low_estimate": 50,
"surge_multiplier": 1,
"currency_code": "INR"
}
....
]
}
Thank you for the report. This is a known issue and we're working on a fix. In the meantime, you can use either uberPOOL product that is surfaced.
TL;DR Uber sometimes offers many products in a given location, and they're all returned from those two endpoints.
To expound on that... according to the docs, this is normal:
The Products endpoint returns information about the Uber products
offered at a given location. The response includes the display name
and other details about each product, and lists the products in the
proper display order.
Some products, such as uberEATS, are not returned by this endpoint.
We'll soon be making uberPOOL available in this endpoint.
Particularly: We'll soon be making uberPOOL available in this endpoint. It seems that time has come.
The same goes for the estimates endpoint.
The Price Estimates endpoint returns an estimated price range for each
product offered at a given location.
How are they different?
Uber offers different types of services in different countries.
UberGo is a cheaper version of UberX that seems to be specific to India.
UberPool is fairly straight forward in that it's a carpooling service offered to those who wish to split the fare with others that are heading in the same destination.
Since services vary by location, it's best to research them individually when constructing a service that's consuming the Uber API.

Possible for Uber to add car count to /v1/products

I know Uber doesn't want to allow car coordinates for all available cars (not fully certain why though), however, could Uber please at least add the total available cars at any given request time, something like the following:
"products": [
{
"capacity": 2,
**"available": 7,** // add available cars available (or similar)
"description": "Ride for less with uberPOOL",
"price_details": {
"distance_unit": "mile",
"cost_per_minute": 0.26,
"service_fees": [
{
"fee": 1.0,
"name": "Safe Rides Fee"
}
],
"minimum": 5.0,
"cost_per_distance": 1.3,
"base": 2.2,
"cancellation_fee": 5.0,
"currency_code": "USD"
},
"image": "http://d1a3f4spazzrp4.cloudfront.net/car.jpg",
"display_name": "POOL",
"product_id": "26546650-e557-4a7b-86e7-6a3942445247",
"shared": true,
},
Showing that a car is available is great, but what if its only one car and someone else snags it before the user viewing it is able to do so? If it shows "Cars Available: 5" - then the user knows there is a pretty good chance they will get a driver close to the allotted ETA already provided.

Getting a High Resolution picture from Facebook API

Facebook FQL API for Photos states the maximum resolution for a photo returned from the API is 960x960:
The Photo object has an equivalent src connection. Using photo_src
FQL, you can retrieve images with the following dimensions: 960, 720,
480, 320, 180, 130, 75 pixels.
However, some images are uploaded at a higher resolution. Sometimes even much higher.
When browsing Facebook regularly, you can see these pictures and view their full size. However, I can't seem to find any way to get the original resolution in the API.
Is this possible and I have missed something? And if it's not - why?
Getting the max size of a picture
/USER_ID?fields=images
images gives back "an array of objects containing width, height, source each representing the various photo sizes". The result looks like this:
{
"data": [
{
"images": [
{
"height": 1536,
"width": 2048,
"source": "https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-prn1/s2048x2048/65169_XXXXXX_n.jpg"
},
{
"height": 720,
"width": 960,
"source": "https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-prn1/65169_44590146XXXXXXXXn.jpg"
},
{
"height": 540,
"width": 720,
"source": "https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-prn1/s720x720/65169_44XXXXXXX0984540_n.jpg"
},
{
...
},
{
"height": 97,
"width": 130,
"source": "https://fbcdn-photos-a.akamaihd.net/hphotos-ak-prn1/s75x225/65169_44XXXXX_s.jpg"
}
],
}
]
}
Getting the max size of a profile picture
Try with more than 960, i.e 961. You'll get the maximum size of the picture, if available!
/USER_ID?fields=picture.height(961)
Result:
{
"id": "PROFILE_ID",
"picture": {
"data": {
"url": "https://fbcdn-profile-a.akamaihd.net/hprofile-ak-prn1/615962_4486XXXXXXXXX3_601495975_o.jpg",
"width": 1536,
"height": 2048,
"is_silhouette": false
}
}
}