Change Details

**Short description** This task is about defining the future raw video file format for apertus cameras. **Background** Right now apertus cameras are not able to record RAW videos directly onto a mass storage medium. Video stream are instead being transferred onto a computer and written to a file on disk there. The format being used is a raw 12 bit image sensor dump without focus on adding potentially important metadata for postprocessing. While this is absolutely adequate for the current development phase, it may sooner or later be not enough and demand for a post-processing oriented container format could raise. This task is not a "code-only" task, but has more a thesis character. Especially the first two subtasks are about examining the state of the art. **Subtasks** This is an example of how the Task could be performed. This list is not compulsive and can be changed if needed. . 1. __Current status analysis and requirement definition__ Before any decision or implementation can happen, it is important to depict the current state of how video data is being recorded and written to disk. This includes for example: - technical backgrounds of the current file format (i.e. "why is it as it is?") - examining the technical backgrounds of the signal processing path within the camera (i.e. "how does it work?") - technical possibilites and requirements of the signal processing path in terms of video container format (i.e. "what could we do with it and where are limits?") - defining requirements/recommendations for a container format Hint: When it comes to such requirements, they are often either "hard" and such out of question, or "soft" and a tradeoff between different aims. All the requirements are to handle with the assumption the camera will later be writing to mass storage directly. . 2. __Target container format__ Next step is to determine which free / open sourced options we are able to choose from and - together with the developers - decide for one. Characterizing those formats and checking against requirements from the previous subtask should happen here. Formats are e.g. Magic Lantern Video, OpenEXR, CinemaDNG, ... It should be noted that every format has it pro and cons. It may even be possible to decide for more than one format as options for various reasons. e.g. while CinemaDNG is widely known and well-defined, it will be hard to modify the specification to this projects needs, while e.g. MLV is easier to modify but not as widespread as the others. . 3. __Implementation__ When needed and if possible, here should happen the definition of what to change in the format(s) chosen in the previous subtask. This can be a mix of standardization work and implementation. If the camera will not be able to write video to a mass storage at this point in time, a proper implementation for a computer should be implemented. . 4. __Conclusion and Outlook__ Check the results and which room for optimization is left.

To apply for this task please complete this mandatory coding challenge together with your application: T872 Applications without matching coding challenge completed will not be considered. ___ **Short description** This task is about defining the future raw video file format for apertus cameras. **Background** Right now apertus cameras are not able to record RAW videos directly onto a mass storage medium. Video stream are instead being transferred onto a computer and written to a file on disk there. The format being used is a raw 12 bit image sensor dump without focus on adding potentially important metadata for postprocessing. While this is absolutely adequate for the current development phase, it may sooner or later be not enough and demand for a post-processing oriented container format could raise. This task is not a "code-only" task, but has more a thesis character. Especially the first two subtasks are about examining the state of the art. **Subtasks** This is an example of how the Task could be performed. This list is not compulsive and can be changed if needed. **1. __Current status analysis and requirement definition__** Before any decision or implementation can happen, it is important to depict the current state of how video data is being recorded and written to disk. This includes for example: - technical backgrounds of the current file format (i.e. "why is it as it is?") - examining the technical backgrounds of the signal processing path within the camera (i.e. "how does it work?") - technical possibilites and requirements of the signal processing path in terms of video container format (i.e. "what could we do with it and where are limits?") - defining requirements/recommendations for a container format Hint: When it comes to such requirements, they are often either "hard" and such out of question, or "soft" and a tradeoff between different aims. All the requirements are to handle with the assumption the camera will later be writing to mass storage directly. **2. __Target container format__** Next step is to determine which free / open sourced options we are able to choose from and - together with the developers - decide for one. Characterizing those formats and checking against requirements from the previous subtask should happen here. Formats are e.g. Magic Lantern Video, OpenEXR, CinemaDNG, ... It should be noted that every format has it pro and cons. It may even be possible to decide for more than one format as options for various reasons. e.g. while CinemaDNG is widely known and well-defined, it will be hard to modify the specification to this projects needs, while e.g. MLV is easier to modify but not as widespread as the others. **3. __Implementation__** When needed and if possible, here should happen the definition of what to change in the format(s) chosen in the previous subtask. This can be a mix of standardization work and implementation. If the camera will not be able to write video to a mass storage at this point in time, a proper implementation for a computer should be implemented. **4. __Conclusion and Outlook__** Check the results and which room for optimization is left.

To apply for this task please complete this mandatory coding challenge together with your application: T872 Applications without matching coding challenge completed will not be considered. ___ **Short description** This task is about defining the future raw video file format for apertus cameras. **Background** Right now apertus cameras are not able to record RAW videos directly onto a mass storage medium. Video stream are instead being transferred onto a computer and written to a file on disk there. The format being used is a raw 12 bit image sensor dump without focus on adding potentially important metadata for postprocessing. While this is absolutely adequate for the current development phase, it may sooner or later be not enough and demand for a post-processing oriented container format could raise. This task is not a "code-only" task, but has more a thesis character. Especially the first two subtasks are about examining the state of the art. **Subtasks** This is an example of how the Task could be performed. This list is not compulsive and can be changed if needed. . 1 **1. __Current status analysis and requirement definition__** Before any decision or implementation can happen, it is important to depict the current state of how video data is being recorded and written to disk. This includes for example: - technical backgrounds of the current file format (i.e. "why is it as it is?") - examining the technical backgrounds of the signal processing path within the camera (i.e. "how does it work?") - technical possibilites and requirements of the signal processing path in terms of video container format (i.e. "what could we do with it and where are limits?") - defining requirements/recommendations for a container format Hint: When it comes to such requirements, they are often either "hard" and such out of question, or "soft" and a tradeoff between different aims. All the requirements are to handle with the assumption the camera will later be writing to mass storage directly. . **2. __Target container format__** Next step is to determine which free / open sourced options we are able to choose from and - together with the developers - decide for one. Characterizing those formats and checking against requirements from the previous subtask should happen here. Formats are e.g. Magic Lantern Video, OpenEXR, CinemaDNG, ... It should be noted that every format has it pro and cons. It may even be possible to decide for more than one format as options for various reasons. e.g. while CinemaDNG is widely known and well-defined, it will be hard to modify the specification to this projects needs, while e.g. MLV is easier to modify but not as widespread as the others. . 3 **3. __Implementation__** When needed and if possible, here should happen the definition of what to change in the format(s) chosen in the previous subtask. This can be a mix of standardization work and implementation. If the camera will not be able to write video to a mass storage at this point in time, a proper implementation for a computer should be implemented. . 4 **4. __Conclusion and Outlook__** Check the results and which room for optimization is left.