Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo)

[oddname]

Any chance someone can do a Mk2 version soon to play around with? =)
Considering it seems to work quite well on the Mk3.

[g3gg0]

it supports no audio recording yet.
SMPTE (LTC coded audio) is an experimental module that outputs a sound signal that can be read and processed (or not) with special equipment.

[Doyle4]

is there a mac conversion software? would love to test this out.

[RenatoPhoto]

is there a mac conversion software? would love to test this out.

Reply 420

[RenatoPhoto]

at g3ggo: 5D3 does not compile

error:
module.o: In function `module_shutdown':
module.c:(.text+0x2328): undefined reference to `module_save_configs'
collect2: error: ld returned 1 exit status
make[1]: *** [magiclantern] Error 1
make[1]: Leaving directory `/home/magiclantern/G3GGo/magic-lantern/platform/5D3.113'
make: *** [5D3] Error 2

[gerk.raisen]

It's possible to add the delta of exposure value (the value in XMP line crs:Exposure2012=) to 2.0 specs?
So that the converter can recreate other than DNG files also xmp file and you can obtain a perfect deflickered files.

I am often in similar situation of this: http://www.magiclantern.fm/forum/index.php?topic=7739.0 or with some little-than-normal-speed timelapse with sunset for example

but sorry I can't offer 100$ 

[a1ex]

That value has to be computed from raw data, and it's CPU-intensive, so what's the point of including it in the raw format?

[gerk.raisen]

For sunset (especially for the last part) I use often RAW videos because I need to use values under 1 second not available in intervalometer like 2-5fps
but I really miss a lot the deflicker possibility.
It's very important to achieve a good results because the luminosity change a lot in small time.

Maybe is possible to write the raw exposure data and compute it after in the converter?
So we can lighten the CPU.
After all If I understood correctly the frame exposure data used (aperture, iso and shutter value) are already present in 2.0 format.


Thank you much.

[a1ex]

That would be a feature in the converter, nothing to do with metadata. Not even exposure values.

[gerk.raisen]

Thank you,

I was think that ML compute the XMP exposure number with the difference between the exposure calculated and the exposure that camera apply.
So what raw data use ML to calculate XMP?
Can you calculate it in post without any additional data other than the standard exif?

[a1ex]

That's how post deflicker is working. Deflicker data is just the median of the green channel (simplest implementation). If you want all channels, you need to apply WB before median.

[gerk.raisen]

Ok, last thing.
For the median of green channel you mean the measured green channel value and not the green channel value of the taken photo, right?
So for an implementation of post deflicker in the converter you need to have (other than the frame exposed data used (aperture, iso and shutter value)) also the measured green channel value that normally you don't have, neither in exif of CR2's files right?

Thank you.

[a1ex]

No, you compute it in post from the pixels that you find in the video file. You can't do that in the camera...

[gerk.raisen]

Perfect , This time  I hope this time I understood correctly
With an implementation of post-deflicker in the converter (without add any values other than frame exposed data used) we can obtain the SAME results of the post-deflicker correction value calculated on-camera in case of intervalometer still photo, right?

[a1ex]

Yes, or better.

I'll actually move the post deflicker to a PC-based tool again (it will operate on raw photo sequences, no matter how you got them - even from Nikon).

[a1ex]

Added a small proposal for the OFFS block (black correction info), and specified the units for digital ISO field in EXPO block (0.001 EV).

[g3gg0]

ok, cool.
will the EXPO update change the format as it is now?
i.e. would the parsers have to update their code to match the changes?
(it is ok, we just have to bump the version then)

I cannot check the changes as google docs is proxy-filtered.

[a1ex]

I don't think any parser is using the digital ISO other than printing it. I've just updated the value from 1 to 1024 (so it's no longer limited to integer EV).

[g3gg0]

ok thanks

[sletts02]

Yes, or better.

I'll actually move the post deflicker to a PC-based tool again (it will operate on raw photo sequences, no matter how you got them - even from Nikon).

Exciting stuff a1ex! Is there a thread that I can follow regarding this?

Happy to still put the $100 down once you've got it implemented

Great work!

[dmk]

I'm a bit confused about the plan to implement LZMA compression (MLV_VIDEO_CLASS_FLAG_LZMA in mlv.h)

Will that be happening on the camera side in order to remove (or reduce) the CF card speed as a bottleneck? OR is it not really going to help CF card speed requirements, and it's just about storage?

[g3gg0]

it's just about storage?

this. its for archiving.

test footage can be compressed to 50% of the original size without any information loss.
do this on your computer and you save a lot of space for archiving.

you can also reduce bit depth to e.g. 10 bits and you get it down to 30%-40% of original size.

[dmk]

Oh... so it wouldn't help the CF Card speed limit to compress on the fly, i.e. time it takes to compress > time it takes to just write the data straight (or some other issue)?

[g3gg0]

Oh... so it wouldn't help the CF Card speed limit to compress on the fly, i.e. time it takes to compress > time it takes to just write the data straight (or some other issue)?

sure, just tell me how i can configure the EDMAC to compress data with LZMA..

[dariSSight]

sure, just tell me how i can configure the EDMAC to compress data with LZMA..

Thanks for everything Team Magic Lantern has accomplished for the Independent Film Industry Community, it has helped me in very advance ways. Also I was wondering is there a light in the tunnel for 5D Mark II to receive Magic Lantern (RAW) Video format v2.0?