Iso/iec jtc 1/sc 29 N
ReImgProxy (Remote Image Recognition Registration Proxy)
Yüklə 1,86 Mb.
|
- Bu səhifədəki naviqasiya:
- BIFS Textual Description
- Functionality and semantics
ReImgProxy (Remote Image Recognition Registration Proxy)The MAREC provides a set of target resources, a video source URL and one or multiple ARAF compliant processing server URLs where recognition (and tracking) libraries are available. The ARAF Browser communicates with any of the processing servers provided by the MAREC, sends the target resources and the video frames and receives the recognition (and tracking) result. The ARAF Browser composes the server result in the expected format before sending it to the ARAF scene, as described in the Functionality and Semantics below. Even though in the presented schema (below) the augmentation media is presented as input along other data provided by the MAREC, the augmentation media is not used by the PROTO implementation, meaning that it is not part of any of the PROTO fields. The augmentation resources are of course required for the scene augmentation but they do not influence the recognition process. 
BIFS Textual DescriptionEXTERNPROTO ReImgProxy [ exposedField SFString videoSource "" exposedField MFString processingServerURL [] exposedField SFInt32 frameEncodingType 0 exposedField SFInt32 processingType 0 exposedField MFString targetResources [] exposedField MFString targetResourcesTypes [] exposedField SFBool enabled FALSE exposedField SFInt32 maximumDelay 200 #milliseconds exposedField SFInt32 optimalDelay 50 #milliseconds exposedField MFVec2f recognitionRegion [] eventOut MFInt32 onRecognition [] eventOut MFVec3f onTranslation [] eventOut MFRotation onRotation [] eventOut SFInt32 onError ]”org:mpeg:remote_image_recognition_registration” Functionality and semanticsThe MAREC provides one or multiple processing server URLs where recognition (and tracking) libraries are available, along with the target resources to be recognized and the video source where the recognition process shall be performed on. The ARAF Browser uses the provided processing servers as an external resource that is able to perform the recognition (and tracking) of the target resources. The video frames are sent to the processing server in a format that is specified by the MAREC, otherwise the best suitable format is chosen by the ARAF Browser. The recognition (and tracking) result received by the ARAF scene is an array of integers representing the indexes of the recognized target resources and optionally their pose matrixes as described in the description of the fields below. A ARAF compliant processing server shall understand the HTTP requests presented in the following table:
ARAF Browser – Processing Server Communication Workflow Communication Workflow:
The server response must be in the following format: key=unique key 64-bit &resource_code=[target resource format codes]; &frame_code=[video frame format codes]; &server_capability_code=[server capability codes] E.g of a possible server response: key=2e45325f4f&resource_code=0,1&frame_code=0&server_capability_code=0,5
The second type of request contains the target resources provided by the MAREC (one request per each target resource). Each resource must have associated a unique ID, the one to be returned by the processing server when it is recognized, and the file format of the resource. The POST requests are as follows:
key=unique_key &frame_code=the chosen encoding format code &server_capability_code=one of the available server capabilities code
key=unique_key &target_resource=the target resource data &type_code=the target resource encoding type &id=the id of the target resource uniquely identifying the target resource in the MAR scene The processing server returns TRUE if the data is correctly received or FALSE otherwise.
key=unique_key &frame_data=the camera frame The processing server's response is a list of IDs of the recognized target resources and optionally their corresponding pose matrixes or FALSE if no target resource is recognized. identified=comma separated ids of the recognized target resources &translation=[x,y,z]; //optional &rotation=[x,y,z,q]; //optional Where
If the processing server does not have tracking capabilities then the response will be composed only from the list of the recognized target resources (identified).
videoSource is a SFString specifying the URI/URL of the video where the recognition (and tracking) process shall be performed on. The videoSource can be one of the following:
Based on the MAREC preferences, the video frames are sent to the recognition (and tracking) library every X milliseconds (the ARAF Browser is in charge of computing the frequency), as long as the recognition (and tracking) process is enabled. The video frames are sent as compressed images or raw data (see table Target Image Formats for the supported image file formats), or as descriptor files (see table Target Image Descriptors Formats) depending on the processing server capabilities. The ARAF Browser is in charge of deciding the encoding type of the video frames that shall be sent to the processing server, considering the MAREC preferences and the capabilities of the server. The accepted video formats are specified in table Video formats. The accepted communication protocols are specified in table Communication Protocols.
Camera URIs
Video formats
Communication Protocols
Server Capabilities processingServerURL is a MFString used by the MAREC to specify one or multiple web addresses where ARAF compliant processing servers are available. A valid URL is one that points to a processing server that handles at least one target resource type and is able to understand ARAF Browser requests, as defined in table ARAF Browser – Processing Server Communication Workflow. Because a processing server can handle requests from multiple clients in the same time, a unique key is generated by the server and transmitted to the ARAF Browser. The ARAF Browser sends the unique generated key in each request to the processing server. This way the processing server knows the source of the request and therefore it can perform the recognition (and tracking) process on the correct set of the target resources. frameEncodingType field is an MFInt32 containing an array of video frame type codes. The MAREC has the possibility to specify the desired encoding type of the video frames that are sent to the processing server. If multiple keywords are specified by the MAREC, the ARAF Browser chooses the first encoding type that matches the server capabilities. The possible pre-defined codes of the frame encoding types and their meaning are listed in tables Target Image Formats and Target Image Descriptors Formats. If the MAREC does not specify any encoding type code the ARAF Browser uses a default one. The MAREC should not specify an encoding type unless he knows that the processing server gives better results with one or another. The ARAF Browser in any case interrogates the server (see the first step of the Communication Protocol) to retrieve the supported encoding type codes and then it decides on one encoding type considering the MAREC preferences. The field is optional. The processingType field is a SFInt32 value where the MAREC can specify his preferences related to the tracking capabilities of the server as follows: if the field is 1 the ARAF Browser will request the processing server to provide the pose matrix of the recognized target resource. If the processing server is not capable of computing the pose matrix then the related fields (onTranslation and onRotation) will be empty, disregarding the MAREC request. By setting a 0 value on the tracking field the MAREC suggests that the processing should not perform image tracking at all, because the result it's not going to be used in the MAR Scene. The ARAF Browser informs the processing server about the MAREC preferences using a POST request as described in the Communication workflow above. targetResources is an MFString where the target resources to be recognized (and tracked) within the MAR experience are specified. A URI can point to a local or remote resource file. The accepted communication protocols for the remote resources are the ones specified in table Communication Protocols. Any of the below combinations describes a valid targetResources assignment:
Target Image Formats
Target Image Descriptors Formats The targetResourcesTypes field is an MFString containing an array which specifies the type of each target resource defined in the targetResources field. Each target resource must have associated a type in order for the ARAF Browser to know how to interpret the data. The possible pre-defined keywords of the targetResourcesTypes and their meaning are listed in tables Target Image Formats and Target Image Descriptors Formats. If the target resource is a proprietary descriptor file and in addition to the actual image descriptors data the proprietary recognition (and tracking) library needs some other data (for e.g. an XML file), the related content should be stored in a directory that has the same name as the resource type (for e.g. target_resource_type_keywod/) in order for the ARAF Browser to know where the required files can be found. The names of the files within the directory have to be the same name as the corresponding descriptor file name. enabled is a SFInt32 value indicating if the recognition (and tracking) process is enabled (running). MAREC can control the status of the recognition (and tracking) process or he can let the ARAF Browser to decide whether the recognition (tracking) process should be running or not. The following table specifies the supported integer values of the enabled field.
The recognition (and tracking) process is inactive while enabled is 0 While enabled is 1, we differentiate the following cases, based on the video source:
MAREC must have the possibility to choose the quality of his MAR experience and in the same time, indirectly, the processing power consumed by the recognition (and tracking) process. MAREC can control this by setting a maximum acceptable delay. As described in the below graph a response time higher than the maximum delay indicates an unacceptable quality of the MAR experience therefore an ARAF Browser must not present it. Any response time with a delay lower than the specified maximum delay produces a MAR experience that is at least acceptable from the point of view of the MAREC, therefore an ARAF Browser should present the MAR experience. The MAREC can also specify an optimal delay constraint informing an ARAF Browser that there is no need in trying to provide recognition (and tracking) response with a higher frequency (lower delay) becuase the MAR experience has already reached the targeted quality. 
Further, the two fields implementing this functionality are presented. maximumDelay is a SFInt32 value measured in milliseconds specifying which is the maximum acceptable delay of the recognition (and tracking) process in order for the MAR experience to be presented by an ARAF Browser. The MAREC expects an answer from the recognition (and tracking) process every, at most, maximumDelay milliseconds. optimalDelay is a SFInt32 value measured in milliseconds specifying which is the optimal delay of the recognition (and tracking) process. By setting this field, the MAREC suggests that there is no need in trying to provide a recognition (and tracking) response with a higher frequency (lower delay) because the MAR experience quality is the desired one. recognitionRegion a MFVec2f field specifying two 2D points that are relative to the center of the video frame on which the recognition (and tracking) algorithm is performed. The first point indicates the lower left coordinate and the second one the upper right coordinate of a rectangle. By using this field, the MAREC suggests that only the inside area given by the rectangle has to be used in the recognition (and tracking) process, not the entire video frame. The recognition (and tracking) process can be improved by using a video frame region rather than the whole video frame but on the other hand the way how the original video frame is pre-preprocessed (e.g. cropped) may introduce delays. The ARAF Browser cannot ensure that by using a recognition region the overall processing speed is improved. onRecognition is an output event of type MFInt32 specifying the indexes of the target resources that have been recognized. An index is an integer value representing the position of a target resource in the targetResources array (0 indexed). The index of the first target resource is 0 and it is incremented by one for each next target resource. If a target resource is a file containing descriptors for several images, each target image descriptor within the descriptor file is assigned the next index as they were separately specified. The following two fields are used to describe the pose matrix of a recognized resource. A pose matrix describes the relative position to the camera viewpoint of a recognized target resource. The pose matrix is described by one rotation and one translation vector, fields which are described below. These two fields are optional, meaning that the functionality of the prototype can be limited to only recognizing target resources, without computing their associated pose matrixes. If onTranslation is not used then implicitly onRotation is not used and vice-versa. If a translation is computed then implicitly the corresponding rotation should be computed by the processing server. In other words, if the processing server is capable of computing the pose matrix, the MAREC expects that both of the fields (onTranslation and onRotation) are set. onTranslation is an exposed MFVec3f field where the translations of the recognized target resources are stored. A SFVec3f vector specifies where the corresponding recognized target resource is relative to the camera position within the video frame where the recognition process has been performed on. The default value of a translation vector is <0,0,0>. MAREC expects a SFVec3f translation for each recognized target resource or a default value if the translation could not be computed. The MAREC considers that the nth value of onTranslation corresponds to the target resource given by the value found on the nth index of onRecognition. The field is optional. onRotation is a exposed MFRotation field where the rotations of the recognized target resources are stored. A SFRotation vector specifies how the corresponding recognized target resource is rotated with respect to the camera plane within the video frame. The default value of a rotation vector is <0,0,0,0>. The MAREC expects a SFRotation vector for each recognized target resource or a default value if the rotation could not be computed. The nth value of onRotation corresponds to the target resource given by the value found on the nth index of onRecognition. The field is optional. onRotation, onTranslation and onRecognition must have the same lengths. onError is an output event of type SFInt32. Table Error codes presented below specifies onError possible values and their meaning.
Error codes Yüklə 1,86 Mb. Dostları ilə paylaş:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||