Iso/iec jtc 1/sc 29 N
ReImgServer (Remote Image Recognition Registration Server)
Yüklə 1,86 Mb.
|
- Bu səhifədəki naviqasiya:
- BIFS Textual Description
- Functionality and semantics
ReImgServer (Remote Image Recognition Registration Server)MAREC provides a video source URL and one or multiple processing server URLs where image recognition (and tracking) libraries are available. A set of target resources (images or descriptors) and the associated augmentation resources are stored in remote databases, on the processing server or anywhere else on the Web. The ARAF Browser sends video frames or video frame descriptors to the processing server, considering the MAREC preferences (if applicable) and the processing server capabilities. The server performs the recognition (and tracking) process on the received video data, searching in the set of the target resources that are stored in the database(s). Depending on the format of the video frame, the server may need to extract the descriptors before performing the recognition (and tracking) process. One of the server’s responses is composed by one or multiple augmentation resource URLs that are associated with the recognized target resource and (optionally) the pose matrix of the recognized object within the video frame. The augmentation resource can be an URL to a media file (see table Augmentation media types) or a proprietary string. The proprietary string is not interpreted by the default prototype implementation therefore the MAREC has to update the default prototype implementation. The MAREC has the option to let the ARAF Browser do the tracking of the recognized target resource locally. In this case the processing server must be able to send the recognized target resource to the ARAF Browser which in turn must be able to perform the tracking. Detailes are presented below in the Functionality and Semantics. 
BIFS Textual DescriptionEXTERNPROTO ReImgServer [ exposedField SFString videoSource "" exposedField SFInt32 frameEncodingType 0 exposedField SFInt32 processingType 0 exposedField MFString processingServerURL [] exposedField SFBool enabled FALSE exposedField SFInt32 maximumDelay 200 #milliseconds exposedField SFInt32 optimalDelay 50 #milliseconds exposedField MFVec2f recognitionRegion [] eventOut MFString augmentationMediaURL eventOut MFInt32 augmentationMediaType eventOut MFString augmentationString eventOut MFVec3f onTranslation eventOut MFRotation onRotation eventOut SFInt32 onError ]”org:mpeg:remote_image_recognition_registration_server” Functionality and semanticsMAREC provides one or multiple processing server URLs where recognition (and tracking) libraries are available, along with a video source where the recognition process shall be performed and optionally the encoding code of the video frames that are sent to processing server. The ARAF Browser must use the provided processing server URLs as an external resource that is able to perform the recognition (and tracking) of the target resources that are stored in the external repositories. The recognition (and tracking) result of the processing server is an URL to an augmentation resource and the type of the media file that can be found at the given URL and optionally the pose matrix of the recognized object in the video frame. Another valid server's response is a proprietary string that is associated to the recognized object in the video frame. Considering that the processing server knows which was the last recognized target resource for a given client, a tracking algorithm can be performed remotely. In the case that the processing server is able to only perform image recognition, the ARAF Browser can choose to receive the target image descriptors from the processing server in order to perform the tracking locally. This case would be considered if only the MAREC sets the correct code in the processingType field (see Server Capabilities) and the ARAF Browser is capable of performing tracking of a target resource. The possible scenarious are described throughout the fields' descriptions below. A ARAF compliant processing server shall understand the HTTP requests presented in the following table:
Communication Workflow:
The server response must be in the following format: key=unique key 64-bit &frame_code=[video frame format codes]; &server_capability_code=[server capability codes] &image_descriptor_code=[the codes specifying supported imaget descriptor formats] E.g of a possible server response: key=2e45325f4f&frame_code=0&server_capability_code=1&image_descriptor_code=5
key=unique_key &frame_code=the chosen encoding format code &server_capability_code=one of the available server capabilities code 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 can be:
resource=url to an augmentation resource &descriptor=image descriptor in the previously specified format //optional &translation=x,y,z //optional &rotation=x,y,z,q //optional
If the processing server does not implement tracking capabilities then the response will be composed only by the augmentation resource URL, unless the MAREC specified that he prefers the ARAF Browser to perform the tracking locally (see the description of the processingType field). The case where the processing server returns a proprietary string is not covered by the standard. The MAREC should know how the string has to be interpreted, because he is the one providing the server URL. In this case the server response is transmitted to the MAR Scene exactly in the form as it comes.
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 processing server 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.
Target Image Formats
Target Image Descriptors Formats 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 recognition and tracking processing performed on the server. The MAREC can choose one of the codes that are specified in the table Server capabilities. The description of the codes is found in the given table. The MAREC can only suggest what type of processing the server should perform implicitly affecting the server's response. The ARAF Browser is in charge of informing the processing server what kind of job it should perform, based on the MAREC preferences and the server capabilities (Communication workflow explains how).
From the MAR scene point of view the second and the third cases are providing the same data with the difference that in one case the pose matrix is computed remotely while in the other case the pose matrix is computed locally by the ARAF Browser. The ARAF Browser informs the processing server about the MAREC preferences using a POST request as described in the Communication workflow presented above. If the ARAF Browser cannot perform the image tracking for any reason, an error code is sent to the MAR Scene. 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. 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. augmentationMediaURL is an output event of type MFString where augmentation media URLs associated to the recognized target resource are referenced. augmentationMediaTypes is an output event of type MFInt32 where the code of each augmentation media format referenced in the augmentationMediaURL field is specified. See the table Augmentation media types for the description of the supported types and their associated codes.
Augmentation media types augmentationMediaString is a MFString field where the processing server can add textual information (e.g. labels, descriptions, etc) associated to the recognized target resources. Because arbitrary data can be transmitted using this field, the MAREC should know the string format and therefore how to interpret the data. The server response is transmitted to the field exactly in the form as it comes. The proprietary string is not interpreted by the default prototype implementation. 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ş:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||