This task is about defining the future raw video file format for apertus cameras.
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 about defining the future raw video file format for apertus camerasnot a "code-only" task, but has more a thesis character. Especially the first two subtasks are about examining the state of the art.
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__.
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, Hint: When it comes to such requirementsit will be hard to modify the specification to this projects needs, they are often either "hard" and such out of question,while e.g. or "soft" and a tradeoff between different aimsMLV is easier to modify but not as widespread as the others.
23. __Available container formats____Implementation__
When needed and if possible, Next step is to determine which free / open sourced options we are able to choose fromhere 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,4. Characterizing those formats and c__Conclusion and Outlook__
Checking against requirements from the previous subtask is expected to happen here the results and which room for optimization is left.