--- title: Key concepts slug: api-guide/key-concepts docTags: createdAt: 2024-12-06T09:40:33.613Z --- :::hint{type="info"} ### Do I need to read this page? If you have already gone through the [Quickstart](docId\:b6im5U-kiWn9UkybzJX6D) 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. ![](https://api.archbee.com/api/optimize/wLEz_RbWP6nIMpY-prjlm/guYBL24DaGlpRRXIe28C9_kognic-domain.png) ## 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 Requests. 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 | | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Cameras](docId\:hKMLpeIBxzCP4SpBBjnjX) | A single frame consisting of image(s) from 1-20 cameras | | [Lidars and cameras](docId\:zyoDx_rb8sn5uByMpjoAc) | A single frame consisting of 1-20 lidar point clouds and image(s) from 1-20 cameras | | [Cameras sequence](docId\:Hy8jVLTuESA41AmlMNL0O) | A sequence of frames, each frame consisting of image(s) from 1-20 cameras | | [Lidars and Cameras Sequence](docId\:ySVc-B_Xr0KmxGT92B6pv) | A sequence of frames, each frame consisting of 1-20 lidar point clouds and image(s) from 1-20 cameras | | [Aggregated Lidars and Cameras Sequence](docId\:Wk30FzM6vJvDcTDkX-Mgh) | A sequence of frames, each frame consisting of 1-20 lidar point clouds and image(s) from 1-20 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 [Coordinate Systems](docId\:XqF6UaQSoFwvAVmtePdEC) 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 [Working with Scenes & Inputs](docId\:utysHj-BNg1V85n2e6_eh). ## Annotation An **annotation** is produced when inputs are successfully annotated in a request. Annotations are provided by `kognic-io` API as json objects in [OpenLABEL Format](docId\:AWHHsRojM96zOWLirYW7D). More information on how to download these annotations along with some examples of how to work with them is available in the [Download Annotations](docId:5J-McgJYo5xFFxqkKrQGo) chapter. Apart from `kognic-io` API, Kognic also provides a library called [kognic-openlabel](docId\:s0nQG6DB56u4sIhk3jTlx), which makes it easy to parse and work with the OpenLABEL json objects.