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 AXIOM cameras.
Background
Right now AXIOM Betas are not able to record RAW videos directly onto a mass storage medium, instead external HDMI recorders are used for this process.
In the near future the video stream will be transferred onto a computer via USB 3.0 and written to a file on disk there.
The likely format being used then is a raw 12 bit image sensor dump (RAW12: https://wiki.apertus.org/index.php/RAW12) with only small focus on adding potentially important metadata for post-processing.
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
If needed and if possible, define changes 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
Checking the results and evaluating what room for optimization is left.
Planned raw recording image data flow (USB3 module is in development):
Prerequisites:
- raw image encoding principles
- basic knowledge about the signal processing chain (CMOS, ADC, FPGA, ...)
- experience in C programming
- experience in unix environments (Linux, cygwin, WSL)
Language Skills:
- mostly C, but C++ may also help
Mentors: g3gg0
To get in touch with any mentor check the Mentor Contact List.