hi, g3gg0 there, over from Magic Lantern.
after some trouble with antispam not allowing me to register, i finally could solve that using IE
MLV file format itself supports any bit depth between 1 and 16 bits, just by setting the right
bit depth in the field bits_per_pixel of raw_info in RAWI block. however, the ordering scheme
of the bits must stay the same.
the MLV RAW frame format is the unmodified stream the EDMAC is receiving from the ADCs.
as alex noted in raw.h, the 14 bit data is written there as 16 bit words like that:
(explanation: every letter is one bit. 'a' is the first pixel, 'b' the second, etc..)
MSB LSB
aaaaaaaaaaaaaabb (word 1)
bbbbbbbbbbbbcccc (word 2)
ccccccccccdddddd (word 3)
ddddddddeeeeeeee (word 4)
eeeeeeffffffffff (word 5)
ffffgggggggggggg (word 6)
gghhhhhhhhhhhhhh (word 7)
all these words are then written as little endian data into the file, swapping the bytes of the 16 bit words,
giving you bytes that contain this data:
aaaaabb aaaaaaaa bbbbcccc bbbbbbbb ccdddddd cccccccc eeeeeeee dddddddd ffffffff eeeeeeff ...
for example if you have a 10bpp RAW mode and the RAW pixel data is set up like this:
MSB LSB
aaaaaaaaaabbbbbb
bbbbccccccccccdd
ddddddddeeeeeeee
eeffffffffffgggg
and thus giving you raw data bytest that looks like that:
aabbbbbb aaaaaaaa ccccccdd bbbbcccc eeeeeeee dddddddd ffffgggg eeffffff ...
then by definition MLV format can handle your raw data without modification.
now depending on the tool, your footage can be read or must be converted to 14bpp prior use.
if a tool doesnt support depths different from 14 bits, you can convert your footage using mlv_dump:
./mlv_dump -b 14 -o <out_14bpp.mlv> <in_10bpp.mlv>
if the raw data is compatible and you decide to port MLV to CHDK, then people can make use of the
same toolchains for post processing of raw data plus you probably save the
processing time needed for conversion of RAW data to DNG, resulting in shorter frame saving time.
BR,
g3gg0
