Key concepts

do i need to read this page? if you have already gone through the docid\ wym9o4uavbhveiojew8ze page then you usually don't have to read this page this is page covers more background information project project is the top most concept when interfacing with the kognic platform it is possible to have multiple ongoing projects, and they act as a container for other kognic resources project setup is usually performed by the kognic professional services team during the guideline agreement process (gap) of a new client engagement within the kognic apis, projects are identified using an external identifier batch input batches allow grouping of input data into smaller batches within a project by default, every project has at least one input batch ongoing projects can be benefited from having multiple batches in two ways group input data that are collected during a certain time interval perform guideline or task definition changes without the need for retroactive changes batch status status description pending batch has been created but is still not fully configured by kognic either during project setup or requested changes open batch is open for new inputs ready batch has been published and no longer open for new inputs in progress kognic has started annotation of inputs within the batch completed annotations has been completed request during gap, projects can have several annotation types as the end goal for example, a project consisting of images can be assigned for both lane detection and object annotation within kognic, a request represents a specific annotation goal for a given input we divide big and complex projects into several independent annotation types this makes it possible to reduce the cognitive load on the annotators more annotators can work on the same data in parallel simplify user interfaces all of these contribute to a high level of quality while also reducing the total time needed for producing an annotation guideline in order to produce annotations, one needs to know what to annotate and how this type of information is found in guideline a guideline defines what specific object to mark (e g vehicles and pedestrians), as well as how (e g bounding box) a guideline also includes detailed information about how to interpret the data, e g what it means by a vehicle is "heavily occluded" task definition & annotation instructions task definition describes what should/could be annotated how many object types? bounding box, semantic segmentation or lines/splines for each object type? what are the properties for each object type? task definitions are json files that the kognic professional services team generates from the guideline the task definition is then used by the kognic app to construct the appropriate drawing tool in other words, task definition can be understood as the machine readable quivalent of a guideline we are adopting annotation instructions as a more intuitive way to define the task definition through our platform, and you may hear this concept mentioned too from outside the platform, annotation instructions and task definitions amount to the same thing; annotation tool setup and hence content of the finished labels scene before setting up any annotation task, the raw data needs to be correctly uploaded to the kognic platform the scene specifies how data from different sources are combined together resources are images and point clouds, as well as metadata and calibrations (define sensors' properties) we support different types of setup, for example image(s) from a (multiple) camera(s) image(s) from camera(s) combined with lidar point clouds another concept related to scene is frame a frame is a discrete moment of a scene in time scenes can be either single frame or sequence (multiple frames) sequence should be used when temporal information is important for producing the annotation scene types type description docid\ kzidafhttugnpnv fiufy a single frame consisting of image(s) from 1 9 cameras docid\ t nzx0h 2ulge9sa h04r a single frame consisting of 1 20 lidar point clouds and image(s) from 1 9 cameras docid\ b7kvgrpe i2faquwu 6lm a sequence of frames, each frame consisting of image(s) from 1 9 cameras docid\ czk0xfupz8tlney2m6kx7 a sequence of frames, each frame consisting of 1 20 lidar point clouds and image(s) from 1 9 cameras docid\ l tirodksb1ih5y5cth9z a sequence of frames, each frame consisting of 1 20 lidar point clouds and image(s) from 1 9 cameras however, point clouds are aggregated over time, producing a unified point cloud pre annotations also called pre labels if annotations are labels coming out of the kognic platform, then pre annotations are labels going in these, in the form of openlabel json, are uploaded onto a scene after it has been created, and can capture any initial labelling for the scene, such as estimates for bounding boxes, or previously hand labelled data that needs to be revisited a scene has 0 or more pre annotations, and when an input is created from a scene, one of the pre annotations may be attached to it see pre annotations for details of how pre annotation data must be a valid openlabel (json) document kognic also validates that it is broadly 'sensible' e g that it uses the same sensor names as the scene and has the correct number of frames when a pre annotation is added to an input, we further validate that it is compatible with the task definition it is possible for a pre annotation to be a valid openlabel document but not valid for use in a particular request calibrations calibrations are essential to accurate multi sensor annotation they contain extrinsic properties for every sensor attached to the ego vehicle (where it is), and intrinsic properties of the specific sensor (e g field of view, resolution for cameras) calibrations allow us to transform positions between the different 3d and 2d co ordinate systems in a scene see docid 3jkwdhqcmvnvbuzbouzmr for technical detail input once a scene has been uploaded to the kognic platform, one can create annotation tasks as inputs where each input is associated to a request differenciate input from scene enables efficient reuse of the uploaded data for instance, multiple inputs can be created from the same scene enabling different kinds of annotation setups note that one can create an input simultaneously when creating a scene by providing the project/batch that it should be associated to, see examples in docid\ mf7 5gllqrkg to ev3yd annotation an annotation is produced when inputs are successfully annotated in a request annotations are provided by kognic io api as json objects in docid\ tfdiv3dlaafndehaklui more information on how to download these annotations along with some examples of how to work with them is available in the docid\ e49jxwmqee54hochctmex chapter apart from kognic io api, kognic also provides a library called docid\ ydr k4dp8deobobjato70 , which makes it easy to parse and work with the openlabel json objects