Skip to content

Sequence diagrams#

This chapter describes the general requests to LP and shows interactions between services during the request processing.

More information about the requests can be found in the "APIReferenceManual.html" document.

Samples creation diagrams#

Sample creation diagram#

The request enables detecting the faces in input photos. The photos can be sent in standard image formats (JPEG, PNG, etc.) or in the BASE64 format.

See the "detect faces" request in "APIReferenceManual.html" for details.

Request Description Type
detect faces The request enables to detect faces in incoming images, estimate face parameters, extract samples and save them in Image Store. POST

The request result contains the parameters of the detected faces and the IDs for all the created samples.

Detect faces request
Detect faces request

The general request processing scheme:

  1. The face detection request is sent to API;
  2. API receives the request, processes it and sends the task to the Handlers service;
  3. The Handler processes the task according to the specified parameters;
  4. The Handler sends received samples to Image Store;
  5. Image Store saves the samples to the storage;
  6. The storage returns the result of sample saving;
  7. Image Store returns the samples IDs and URLs;
  8. The Handler sends the samples IDs and the received face parameters to the API service;
  9. API generates and sends the response.

Get information about samples and save samples#

The following request adds external samples to Image Store.

See the "save samples" request in "APIReferenceManual.html" for details.

Request Description Type
save sample The external sample is saved in Image Store POST

The following requests enables to manage the already existing samples.

See the "samples" section in "APIReferenceManual.html" for details.

Request Description Type
get sample Receive a sample by its ID GET
remove sample Delete a sample by its ID DEL
check to exist sample Check existence of the sample with the specified ID HEAD

All the requests above are processed by the Image Store service.

Image Store request
Image Store request

The requests processing scheme:

  1. A request is sent to the API service;
  2. API sends the request to Image Store;
  3. Image Store performs the required actions with the storage;
  4. The storage returns the required data;
  5. Image Store returns the result to API;
  6. API generates and sends the response.

More information about the requests can be found in the "APIReferenceManual.html" document in the "Samples" section.

Attributes diagrams#

Temporary attributes extraction diagram#

Handler receives samples from Image Store and extracts information from them.

See the "extract attributes" request in "APIReferenceManual.html" for details.

You should specify the array of sample IDs.

Request Description TYPE
extract attributes Extracts the following attributes: descriptors and basic attributes (age, gender, ethnicity) POST
Temporary attributes extraction sequence diagram
Temporary attributes extraction sequence diagram

The general request processing scheme:

  1. The extraction request is sent to API;
  2. API receives the request, processes it and sends the request to the Handlers service;
  3. The Handlers service requests samples from Image Store;
  4. Image Store requests the samples from the storage;
  5. The storage sends samples;
  6. Image Store sends the samples to the Handlers service;
  7. The Handlers service processes the task according to the specified parameters;
  8. The Handlers service sends descriptors and basic attributes to the Faces service;
  9. The Faces service sends requests to store temporary attributes in the Redis database;
  10. Redis database sends the response to Faces;
  11. Faces sends the response to the Handlers service;
  12. The Handlers service sends received attribute IDs, basic attributes, attribute URLs, filtering results and GS score to the API service;
  13. API sends the response.

Diagram of attribute creation using external data#

The diagram shows attributes creation using data from an external database.

See the "attributes" section in "APIReferenceManual.html" for details.

Request Description TYPE
create temporary attribute New temporary attributes creation. POST
External temporary attributes saving sequence diagram
External temporary attributes saving sequence diagram

  1. The request for adding new attributes (descriptors and/or basic attributes) is sent to the API service. All the required data for attributes creation is sent with the request. Optional. The request to the Image Store service is sent when samples were provided with descriptors and/or attributes;

  2. The API service sends the request to the Image Store service to save the received samples;

  3. Image Store requests the samples from the storage;

  4. The storage sends samples;

  5. Image Store sends the samples to the API service;

  6. The API service sends descriptors and basic attributes to the Faces service;

  7. The Faces service sends requests to store temporary attributes in the Redis database;

  8. Redis database sends the response to Faces;

  9. Faces sends the response to the API service;

  10. The API service sends response.

Attributes information diagrams#

The following requests enable you to receive data about the already existing attributes or delete them.

Request Description Type
get temporary attributes Receive all attribute IDs and their creation time according to the targets GET
get temporary attribute Receive the temporary attribute information by ID GET
check temporary attribute Check existence of an attribute by its ID HEAD
delete attributes Delete the attribute with the specified ID DEL
get temporary attribute samples Get all the temporary attribute samples by the attribute ID GET
Get information about temporary attributes
Get information about temporary attributes

The general request processing scheme:

  1. A request is sent to the API service;

  2. API sends the request to the Faces service;

  3. Faces service sends the request to the Redis database to receive information about temporary attributes;

  4. The Redis database returns requested information;

  5. The Faces service returns the result;

  6. The API service returns the information to the user. If the TTL of the attribute has expired, an error is returned.

Faces and lists diagrams#

All the requests in this section are processed by the Faces service.

See the "faces" section in "APIReferenceManual.html" for details.

Face creation diagram#

Request Description Type
create face Create a new face with the specified attribute ID, user's data, avatar and lists POST
Create new face
Create new face

The general request processing scheme:

  1. A request is sent to the API service;

  2. API sends the request to the Faces service;

  3. Faces service sends the request to the Redis database to receive temporary attributes. Optional. The request to the Redis DB is not sent if there are external attributes specified for the face or when there are no attributes set for the face.;

  4. The Redis database returns requested information;

  5. The Faces service returns the result;

  6. The Faces service sends the request to the Faces database to create a new face using the specified data;

  7. The Faces database saves the data;

  8. The Faces service returns the information about the created face;

  9. The API service returns the information to the user.

Faces and Lists information and management#

All the following requests have similar sequence diagrams.

The following requests enable you to create faces, receive data about the already existing faces or delete them.

Request Description Type
get faces Get the array of all the existing faces and their data: face ID, external ID, user's data, create time, avatar, account ID, and lists to which the Face is attached GET
delete faces Delete several faces by IDs DEL
get face count Receive the number of existing faces according to the specified filter GET
get count of faces with attributes Count of faces with attributes GET
get face Receive data of the face (face ID, external ID, user's data, create time, avatar, account ID, and lists to which the face is attached) that corresponds to the specified ID GET
patch face Update a Face using the specified data: user's data, event ID, external ID, avatar PATCH
remove face Delete the specified face DEL
check to exist a face Check existence of the face by its ID HEAD
put face attribute Put face attribute, changing all the attribute data corresponding to the specified face PUT
get face attribute Receive attributes of the specified face: gender, age, ethnicity, create time GET
delete face attribute Remove face attribute by ID DEL
get face attribute samples Receive information about samples (sample ID) that correspond to the specified face GET

The following requests enable you to create lists and receive data about the already existing lists or delete them.

Request Description Type
create list Create a new empty list. You can specify user data for it POST
get lists Receive the array of all existing lists with the following data: list ID, user data, account ID, creation time, last update time GET
delete lists Delete several lists by IDs DEL
get list count Get number of the existing lists GET
get list Receive information (list ID, user data, account ID, creation time, last update time) about the list by the specified ID GET
check list existence Check existence of the list with the specified ID HEAD
update list Update the user_data field of the list PATCH
delete list Delete the list with the specified ID DEL
attach/detach faces to the list Update the list by attaching or detaching the specified faces from it PATCH

The following diagram represents workflow for all the listed above requests to Faces.

Faces request processing diagram
Faces request processing diagram

The general request processing scheme:

  1. A request is sent to the API service;
  2. API sends the request to the Faces service;
  3. The Faces service sends the request to the Faces database to receive information or manage the existing data;
  4. The Faces database returns requested information or information about database changes;
  5. The Faces service returns the result;
  6. The API service returns the result to the user.

Matching diagrams#

You should specify references and candidates for matching. You can limit the number of candidates with the highest similarity value.

Request Description Type
matcher/faces Matcher compares given references with the given candidates. As a result, matcher returns similarity level for each of the candidates and additional information about candidates POST
human body matching Allows to submit tasks to a service that searches for human bodies similar to a given reference(s) by matching them POST
raw matching Allows to do similarity calculations for input descriptors POST

See the "matching faces", "human body matching" and "raw matching" sections in "APIReferenceManual.html" for details.

Matching using Python Matcher#

Matching by DB#

The example of matching events (references) with faces (candidates) is given below.

Matching of events and faces
Matching of events and faces
  1. The matching request is sent to the API service;
  2. The API service sends the request to the Python Matcher service;
  3. The Python Matcher service requests references from the Events database;
  4. The Events database returns the data;
  5. The Python Matcher service sends the requests for matching by the Faces database;
  6. The matching is performed;
  7. The Faces database returns the matching results;
  8. The Python Matcher service requests additional data for candidates;
  9. The Faces database returns the data;
  10. The Python Matcher service returns results to the API service;
  11. The API service sends the response.

Matching by list#

The example of matching faces (references) with the list of faces (candidate) is given below.

Matching faces by list
Matching faces by list
  1. The matching request is sent to the API service;
  2. The API service sends the request to the Python Matcher service;
  3. The Python Matcher service requests references from the Faces database;
  4. The Faces database returns the data;
  5. The matching is performed in The Python Matcher service. The cached descriptors are used;
  6. The Python Matcher service requests additional data for candidates;
  7. The Faces database returns the data;
  8. The Python Matcher service returns results to the API service;
  9. The API service sends the response.

Handlers diagrams#

Handler management requests#

A handler defines the logic for input image processing. You should specify a handler when a new event is created.

The following requests are related to the handler.

Request Description Type
create handler Create handler POST
get handlers Get handlers according to the specified filters GET
get handler count Receive number of existing handlers GET
get handler Receive handler policies by the handler ID GET
replace handler Update fields of a handler. You should specify the handler ID. You should fill in all the required policies in the request body. Update of individual parameters of a handler is not allowed PUT
check to exist a handler Check if the handler with the specified ID exists HEAD
remove handler Remove a handler by ID DEL

The general scheme of handler creation is shown in the figure below. All the handler requests have similar sequence diagrams.

Handler creation diagram
Handler creation diagram
  1. A request for a new handler creation is sent from the API service to the Handlers service;
  2. The Handlers service processes the request and creates a handler;
  3. The Handlers service stores the handler to API database;
  4. The Handlers service database returns result;
  5. The Handlers service service returns the ID of the created handler.

The handler is used upon Event creation and its usage example is described in the "Events" section. All the results are stored in the Events database.

Events diagrams#

Event creation general diagram#

Event is created after an image is processed according to a handler.

Request Description Service
generate events Create an event. You should specify the required handler ID or set dynamiic handler policies and specify images for processing. You can set additional parameters and data for the created event. POST

The sequence diagram for a new event creation will differ depending on the specified handler policies.

The sequence diagram below shows the general process of new event creation and includes only general entry points for the execution of policies.

Event creation diagram
Event creation diagram
  1. The API service sends the request for new Event creation to the Handlers service;
  2. The Handlers service receives the corresponding handler from the Handlers database;
  3. The Handlers database sends the handler to the Handlers service. The handler is processed policy after policy;
  4. The "detect_policy" is processed by the Handlers service. The received samples are stored in RAM;
  5. The "extract_policy" is processed by the Handlers service. The received attributes are stored in RAM;

  6. The "match_policy" is processed according to the provided filters. Descriptors received during the "extract_policy" execution are provided as references for matching. There can be several ways for matching execution:

    • Faces are set as matching candidates. The matching will be performed using the Faces DB.
    • Events are set as matching candidates. The matching will be performed using the Events DB.
    • Faces are set as matching candidates and list of faces is set in filters. The matching will be performed using the Matcher service.

  7. The "storage_policy" is processed according to the specified data:

    • Samples are stored to the Image Store service;
    • Faces are created and stored in the Faces database by the Faces service. They also can be linked to lists;
    • Attributes are created and stored in the Redis database by the Faces service;
    • Events are stored to the Events database by the Events service;

  8. The "conditional_tags_policy" is processed by the Handler service;

  9. The Handlers service returns results to the API service;
  10. The Handlers service sends the results to Events;
  11. The Events service creates a new event and stores it in the Events database;
  12. The Events database sends response;
  13. The Events service sends response to the Handlers service.

Get statistics on events and events information#

Policy Description Service
get statistics on events Receive statistics on Events. The target group enables to aggregate events according to the specified aggregators: number of items, max or min value, average value, grouping. You can also apply filters and periods to select events that should be aggregated. Grouping by frequency or grouping by time intervals is available. POST
get events Receive all events that satisfy the specified filters. In the filters you can set values of one or several event fields. The target parameter enables to select fields that you want to receive in response. You can left the target field of the request empty. In this case all data about the events will be shown. You may also set sorting parameters, number of events on page and number of pages. If the create_time__gte is not set, it is set to one month by default GET
get event Receive all fields for the event. You should specify event_id for the request. GET
check event existence Check existence of the specified event. You should specify event_id for the request. HEAD

The sequence diagram describes the request processing.

Events information
Events information
  1. API receives request to Events;
  2. API sends the request to Events;
  3. Events receives the required data from the database;
  4. The database returns result;
  5. Events returns results;
  6. API returns results.

Tasks diagrams#

There are several requests for different long tasks creation.

Each of the requests begins with a new task creation in the database. API returns the created task ID and does not wait until the end of the task. You can use the task ID in the corresponding request to receive information about the task processing.

Task creation diagram is shown below.

Task creation diagram
Task creation diagram

  1. API service receives a task creation request;

  2. API service sends the request to Tasks service;

  3. Tasks service creates a new task, subtasks and stores them in the database;

  4. The result of the task creation and its ID is sent as a response. According to the task type, the following Tasks service actions may differ. In the general case, Tasks creates subtasks and sends them to the Tasks workers;

  5. Tasks sends subtasks to workers;

  6. Tasks workers send response.

You will receive a task ID as a response.

{
"task_id": 123
}

You should use the task ID to receive the report with the task result and perform other actions with the task. The corresponding requests are listed in "General information about Tasks" section.

Clustering task diagrams#

Request Description Method
clustering task Creates the task for clustering Faces or Events according to the specified filters. POST

Clustering task processing#

After a corresponding task was created (see Tasks Diagrams), Tasks worker starts its processing.

Only faces or events that have already created descriptors will be processed.

A single subtask is created for this task type. Subtask contains filters according to which faces or events are selected. The subtask is processed by a single worker.

Clustering task processing diagram
Clustering task processing diagram

Clustering task processing depends on the objects (faces or events) specified in the request.

  1. Faces: Tasks worker sends the request to Faces service. Tasks worker requests all the required attribute IDs according to the filters specified in the subtask;

  2. Faces sends the request to Faces database;

  3. Faces database returns IDs;

  4. Faces sends IDs to Tasks worker;

  5. Events: Tasks worker sends the request to Events service. Tasks worker requests all the required attribute IDs according to the filters specified in the subtask;

  6. Event service sends a request to the database to receive data;

  7. The database sends the required data;

  8. Events sends data to the Tasks worker;

  9. The Tasks worker matching request. The requests is processed according to one of the schemes described in section "Matching diagrams";

  10. The Python Matcher service sends the results.

End of clustering task#

After Tasks worker ends subtask processing, it performs the following actions.

End of clustering task
End of clustering task
  1. The Tasks service sends the created cluster to Image Store;
  2. Image store sends cluster to the storage;
  3. The storage returns result;
  4. Image Store sends the result to the Tasks service;
  5. The Tasks worker updates the status of the task in the Tasks database;
  6. The Tasks database sends the result to the Tasks worker.

Linker task diagrams#

Request Description Method
linker task The request enables you to create a linker task. POST

Linker task creation#

The linker task can be created for faces and events objects. Linker task creation process depends on the object type.

Attach faces to list

Creation of linking task for faces
Creation of linking task for faces
  1. API service receives the request for creation of a new linker task;
  2. Tasks service receives the request;
  3. Tasks service creates a new linker task in the Tasks database;
  4. Tasks database returns the task ID;
  5. The task ID is sent to the API service;
  6. API service sends the task ID as a response;
  7. Optional. If you have specified a list ID in the request, Tasks service checks the existence of the list;
  8. Optional. Faces service checks the list existence in the Faces database;
  9. Optional. The Faces database sends response;
  10. Optional. The Faces service sends response to the Tasks service;
  11. Optional. If the specified list does not exist or you have specified new list creation in the request, the Tasks service sends request for new list creation;
  12. Optional. Faces creates the list in the Faces database;
  13. Optional. The Faces database sends response;
  14. Optional. The Faces service sends the response to the Tasks service.
  15. The Tasks service creates subtasks for Tasks workers in the Tasks database;
  16. The database sends response on the subtasks creation;
  17. The Tasks service sends subtasks to Tasks workers;
  18. Tasks workers send responses.

Attach faces created from events to list

Creation of linking task for events
Creation of linking task for events

  1. API service receives the request to create a new linker task;

  2. Tasks service receives the request;

  3. Tasks service creates a new linker task in the Tasks database;

  4. Tasks database returns the task ID;

  5. The task ID is sent to API;

  6. API sends the task ID as a response;

  7. Optional. If you specified a list ID in the request, Tasks service checks the existence of the list;

  8. Optional. Faces service checks the list existence in the Faces database;

  9. Optional. Faces database sends response;

  10. Optional. Faces service sends the response to Tasks;

  11. Optional. If the list does not exist or you have specified to create a new list in the request, Tasks sends the request to create a new list;

  12. Optional. Faces creates the list in the Faces database;

  13. Optional. Faces database sends response;

  14. Optional. Faces service sends the response to Tasks;

  15. Tasks receives face IDs and attribute IDs from Events;

  16. Events receives the data from Events database;

  17. The database sends response;

  18. Faces sends the IDs to Tasks service;

  19. Tasks service checks the existence of faces in Faces;

  20. Faces service sends the request to the Faces database;

  21. Faces database sends information about faces existence;

  22. Faces service sends the data to Tasks service;

  23. Faces exist in Faces database If the face for an event exits, Tasks checks that the attribute ID of the face is similar to the attribute ID of the event;

  24. Faces sends a request to the Faces database;

  25. The Faces database send attribute IDs;

  26. Faces sends attribute IDs to Tasks service. If the attribute IDs for the existing face and event are not equal, the "28009: Attribute is not equal" error will be returned;

  27. Faces do not exist in Faces database If there are no faces with the specified IDs in Faces database, Tasks service sends the request to create new faces in Faces database;

  28. Faces sends the request to the Faces database;

  29. The Faces database sends results of face creation;

  30. Faces sends the response to Tasks service;

  31. Tasks creates subtasks for Tasks workers in the Tasks database;

  32. The database sends response on the subtasks creation;

  33. Tasks sends subtasks to Tasks workers;

  34. Tasks workers send responses.

Linker subtask processing#

Linker task processing is shown in the diagram below. There can be several workers used for task execution.

Linker task processing
Linker task processing
  1. The Tasks worker requests faces in Faces service according to the received face IDs;
  2. Faces service requests faces in the Faces database;
  3. The database sends faces to Faces;
  4. Faces sends faces to the Tasks worker;
  5. Tasks worker sends requests for attaching faces to the specified list;
  6. Faces service sends requests for attaching to the database;
  7. The database sends the result of attaching to Faces;
  8. Faces sends the result to the Tasks worker;
  9. The Tasks worker generates a report on the basis of the subtask results and stores it in Image Store;
  10. Image Store stores report in the storage;
  11. The storage sends result of storage. The result has its result ID;
  12. Image Store returns the result to the Tasks worker.

Linker task report generation#

Last worker
Last worker
  1. The Tasks worker combines all the reports corresponding to the same task into a single report and sends it to Image Store;
  2. Image Store sends the report to the storage;
  3. The storage sends the response;
  4. Image Store sends the result of the report saving to the Tasks worker;
  5. Tasks worker sends the request to update the task status in Tasks database;
  6. Tasks database sends the response.

Garbage collection task diagrams#

Request Description Method
garbage collection task A task for deleting attributes according to the specified creation time filter. Only attributes that are not attached to any face are deleted. The task allows to delete unused data from Faces database. POST

Garbage collection task creation#

The garbage collection task can be requested by a user using API or by the administrator using the Admin service.

Garbage collection task creation
Garbage collection task creation
  1. The administrator sends a request to the Admin service;
  2. Admin service sends a request to the Tasks service;
  3. Tasks creates a new task and subtasks in the Tasks database;
  4. Tasks database sends response;
  5. Tasks sends the created task ID to the Admin service;
  6. The Admin service returns the task ID to the administrator;
  7. The Tasks service sends subtasks to Tasks workers. Each subtask includes the range of attribute IDs and time filter;
  8. Tasks workers receive subtasks and send the response.

Garbage collection task processing#

After a corresponding task was created, Tasks worker starts its processing.

Several subtasks are created for this task type. Each of the subtasks contains the range of attribute IDs.

Garbage collection task processing
Garbage collection task processing
  1. Tasks worker has a range of the attribute IDs that should be deleted. Tasks worker requests deletion of temporary attributes and corresponding descriptors in Faces service;
  2. Faces service sends the request to Faces database to delete attributes with the specified IDs;
  3. The database sends results of deletion;
  4. Faces sends the response to the Tasks worker;
  5. The Tasks worker stores report in Image Store;
  6. Image Store sends report to the storage;
  7. The storage sends information about storage results to Image Store;
  8. Image Store sends the result to the Tasks worker;
  9. The Tasks worker updates status of the task in the Tasks database.

Reporter task diagram#

Request Description Method
reporter task Create a report for a complete clustering task. The report is in the CSV format. You can specify the columns that should be added to the report. The report is in a zip archive and includes avatar images for each of the objects in a cluster. POST

Reporter task processing#

After a corresponding task was created (see Tasks Diagrams), the Tasks Worker starts its processing. A single subtask is created for this task type. The subtask includes filters for the data that should be obtained for inclusion into the report.

Reporter task processing
Reporter task processing

Request processing depends on the data, stored in the clustering report. If the report was created for faces, face data will be requested from the Faces service and added to the report. If the report was created for events, event data will be requested from the Events service and added to the report.

  1. The Tasks worker requests a clustering report in Image Store;

  2. Image Store requests the report from the storage;

  3. The storage sends the report;

  4. Image Store sends the report;

  5. Report for faces. The Tasks worker receives all the face IDs from the cluster and requests additional face data from the Faces service. The requested data depends on the columns specified in the request;

  6. The Faces service requests data from the Faces database;

  7. The Faces database sends the required data;

  8. The Faces service sends the data to the Tasks worker;

  9. Report for events. The Tasks worker requests additional event data from the Events service. The requested data depends on the columns specified in the request;

  10. The Events service requests data from the Events database;

  11. The Events database sends the required data;

  12. The Events service sends the data to the Tasks worker;

  13. Tasks worker requests the avatar image for each of the faces or events. The image for a face is specified in the "avatar" field of the Faces database. It can be stored in the Image Store storage or any other storage. The image for the event is the corresponding sample from the Image Store storage;

  14. Image Store requests the image from the storage;

  15. The storage sends the image;

  16. Image Store sends the image;

  17. Tasks worker sends report to Image Store;

  18. Image Store saves the report in the storage;

  19. Storage sends response about saving;

  20. Image Store sends response to the Tasks worker;

  21. The Tasks worker updates task status in the Tasks database;

  22. The Tasks database sends response.

Exporter task diagram#

Request Description Method
exporter task Collects event/face data and exports them to a CSV file. The exported CSV file is in a zip archive and includes avatar images for each of the objects. POST

Exporter task processing#

After a corresponding task was created (see Tasks Diagrams), the Tasks Worker starts its processing.

Exporter task processing
Exporter task processing

  1. Export data for faces. The Tasks worker receives all the face IDs and requests additional face data from the Faces service. The requested data depends on the columns specified in the request;

  2. The Faces service requests data from the Faces database;

  3. The Faces database sends the required data;

  4. The Faces service sends the data to the Tasks worker;

  5. Export data for events. The Tasks worker requests additional event data from the Events service. The requested data depends on the columns specified in the request;

  6. The Events service requests data from the Events database;

  7. The Events database sends the required data;

  8. The Events service sends the data to the Tasks worker;

  9. Tasks worker requests the avatar image for each of the faces or events. The image for a face is specified in the "avatar" field of the Faces database. It can be stored in the Image Store storage or any other storage. The image for the event is the corresponding sample from the Image Store storage;

  10. Image Store requests the image from the storage;

  11. The storage sends the image;

  12. Image Store sends the image;

  13. Tasks worker sends exported data to Image Store;

  14. Image Store saves the exported data in the storage;

  15. Storage sends response about saving;

  16. Image Store sends response to the Tasks worker;

  17. The Tasks worker updates task status in the Tasks database;

  18. The Tasks database sends response.

Cross-matching task diagrams#

Request Description Method
cross-matching task The task enables to match events and faces according to the specified filters. Faces and events can be set as references and as candidates. Additional filters can be specified for both references and candidates. POST

Cross-matching subtask processing#

After a corresponding task was created (see Tasks Diagrams), the Tasks worker starts its processing.

A single subtask is created for this task type. The subtask includes all the required reference and candidate filters.

Cross-matching subtask execution may vary depending on the specified references and candidates.

They can be specified using faces and/or events. In the diagrams below, requests to Faces and Events services are marked as alternative. The requests to Faces service are used when faces are set as references or candidates. The requests to Events service are used when events are set as references or candidates.

Cross-matching task processing
Cross-matching task processing

Cross-matching task processing depends on the objects selected (events or faces).

  1. Faces are set as references or candidates. Tasks worker sends the request to the Faces service to receive attribute IDs for faces. Faces are selected according to the specified filters;

  2. Faces requests IDs in the Faces database;

  3. The Faces database sends attribute IDs;

  4. The Faces service sends the attribute IDs to the Tasks worker;

  5. Events are set as references or candidates. The Tasks worker sends the request to the Events service to receive attribute IDs for events. Events are selected according to the specified filters;

  6. Events requests event IDs in the Events database;

  7. The database sends the IDs;

  8. Events service sends the IDs to the Tasks worker;

  9. The Tasks worker matching request. The requests is processed according to one of the schemes described in section "Matching diagrams";

  10. The Python Matcher service sends the results.

Cross-matching task end#

Cross-matching task end
Cross-matching task end
  1. The Tasks worker generates a report based on the subtask results and stores it in Image Store;
  2. Image Store saves the report in the storage;
  3. The storage sends the result to Image Store;
  4. Image Store returns the result to the Tasks worker;
  5. The Tasks worker sends the request to update the task status in the Tasks database;
  6. The Tasks database sends the response.

Estimator task diagram#

Request Description Method
estimator task Create an Estimator task. With this task, you can perform batch image processing with the specified policies. POST

Estimator task processing#

After a corresponding task was created (see Tasks Diagrams), the Tasks worker starts its processing.

Estimator task diagram
Estimator task diagram

  1. The Tasks worker requests a batch of images from the following sources:

  2. from the Image Store service in a ZIP archive if the "zip" type is selected as the image source;

  3. from the S3 storage if the "s3" type is selected as the image source;
  4. from the FTP server if the "ftp" type is selected as the image source;
  5. from the Samba if the "samba" type is selected as the image source;

  6. from a directory on a network disk that is mounted on a local drive and synchronized with the directory in the containers of the Tasks and Tasks Worker service (see the detailed description in the "Estimator task" section).

  7. Processing the parameters specified in the request - authorization, use of prefixes, etc.

  8. Source (Image Store/S3/Network disk/FTP server/Samba) sends an images to the Tasks worker.
  9. handler_id exists. The Tasks worker sends a request to get the existing handler ID in the Handlers database.
  10. From the Handlers database, a response comes with handler_id to the Tasks worker.
  11. The Tasks worker sends a request to the Handlers service to process handler_id.
  12. The Handlers service processes the batch of images by the received handler_id in accordance with the specified policies (see the policy processing diagram).
  13. The received response is returned to the Tasks worker.
  14. no handler_id. The Tasks worker sends a request to process the policies specified directly in the request to the Handlers service.
  15. The Handlers service processes the batch of images in accordance with the specified policies (see the policy processing diagram).
  16. The received response is returned to the Tasks worker.

Additional extraction task diagrams#

Request Description Method
create additional extraction task Extract all the existing descriptors using the new NN version. POST

Task creation#

The request is sent using Admin service. Task creation is shown in the diagram below.

Additional extraction task creation
Additional extraction task creation
  1. The administrator sends a request to the Admin service using the Admin UI or any other application;
  2. Admin service sends a request to Tasks;
  3. Tasks sends a request to Faces to receive descriptor IDs that were not extracted using the new NN;
  4. Faces sends the request to the database;
  5. Database returns IDs;
  6. Faces sends IDs to Tasks;
  7. Tasks creates a new task and stores it in the database;
  8. The database sends the response and the created task ID;
  9. Tasks service sends task ID to Admin service;
  10. Admin service sends the created task ID back to the UI or application, which is used by the administrator;
  11. Tasks creates and sends subtasks to Tasks workers;
  12. Tasks workers send the response.

Additional extraction subtask processing#

Several subtasks are created for this task type. Each of the subtasks contains the range of attribute IDs.

The general workflow for each subtask processing is shown below.

Additional extraction task processing
Additional extraction task processing
  1. The Tasks worker sends the request to Faces to receive all the required descriptors according to their IDs;
  2. Faces sends the request to the DB;
  3. The DB sends back the required descriptors;
  4. Faces sends the descriptors to the Tasks worker;
  5. The Tasks worker sends the extraction task to the Handlers service;
  6. The Handlers service requests samples for extraction from Image Store;
  7. Image Store requests samples from the storage;
  8. Image Store receives samples from the storage;
  9. Image Store sends samples to the Handlers service;
  10. The Handlers service processes task according to the specified parameters;
  11. The Handlers service sends descriptors and basic attributes to Faces;
  12. Faces sends the request to store data in the database;
  13. The database returns the result of data storage;
  14. The Faces service returns the result of data storage;
  15. The Handlers service sends the result of the task execution to the Tasks service;
  16. The Tasks worker generates a report based on the subtask results and stores it in the Image Store;
  17. Image Store stores report in the storage;
  18. Storage sends the result of storage;
  19. Image Store returns the result to the Tasks worker.

The described sequence is performed for each of the Tasks workers.

The Tasks worker that completes the last subtask gathers all the task reports into a single report and changes the task status. The diagram is shown below.

Additional extraction task last worker
Additional extraction task last worker
  1. The Tasks worker gathers all the reports corresponding to the same task into a single report and sends it to Image Store;
  2. Image Store sends the report to the storage;
  3. The storage sends the response;
  4. Image Store sends the result of the report saving to the Tasks worker;
  5. The Tasks worker sends the request to update the task status in the Tasks database;
  6. Tasks database sends the response.

Tasks information diagrams#

The following requests provide information on the status of existing tasks.

Request Description Method
cancel task Cancel the tasks execution by its ID. PATCH
get tasks Receive tasks information. You can set filters for the tasks. GET
get tasks count Receive number of tasks according to the specified filters. GET
get task Receive information about a task by its ID. GET
get subtasks Receive information about all subtasks of the specified task. GET

The following requests provide information about errors occurred while processing tasks.

Request Description Method
get errors of task Receive all the errors of the specified task by the task ID. GET
get errors Receive all the errors according to the specified filters. GET
get errors count Receive the number of errors according to the specified filter. GET
get error Receive information about an error by the error ID. GET

The corresponding diagram is shown below.

Receive task information or cancel task
Receive task information or cancel task
  1. A request is sent to API;
  2. API service sends the request to Tasks to receive the required data or perform required actions;
  3. Tasks sends the request to the Tasks database to receive the required data or perform required actions;
  4. The database sends the response to Tasks;
  5. Tasks sends the response to API service;
  6. API service returns information.
Request Description Method
delete task Delete the specified task and its results. DEL
get task result Receive results of the specified task. GET
Delete task/get task result
Delete task/get task result
  1. The request is sent to API;
  2. API sends the request to Tasks to receive the required task data or delete a task;
  3. Tasks sends the request to the Tasks database to receive the required data or delete a task;
  4. The database sends the response to Tasks;
  5. Tasks sends the request to Image Store to receive or delete the results of the specified task;
  6. Image Store sends the request to the storage;
  7. The storage sends the response to Image Store;
  8. Image Store returns the result to Tasks;
  9. Tasks sends the response to API service.
  10. API service sends the response.