Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - tom2

Pages: [1]
hi everyone,

for those interested...
my ML-canon 5D Mark III behaves as well on a ronin SC as on a ronin S
For heavy lenses (like my 24-105 T4 mark II), a litte counterweight needs to be attached on the back of the camera (to avoid the weight is too much on the front).
For the cable, I use this short adapter:

Best regards

canon 5D Mark III firmware 1.2.3 with Canon Zoom 24-105 T4 II IS and Canon 16-35 T4 IS

thank you for your answer! Tom

Hi Dmytro,
If one day you tests your Canon Mark III Magic-Lanterned on a RONIN SC, let me know the results of your tests!
I wish the Ronin SC could be as efficient as the Ronin S, but lighter!
best regards,

Hi Dmytro…

Maybe you made me discover a trick to avoid the bug when the 5D mark III is on the Ronin-S
As I was facing the bug almost EACH time I was recording, I chose to try your method of switching from PHOTO to VIDEO mode when rebooting the camera (method which is much more convenient than mine which consisted in taking the battery off and on).
I noticed a difference in the behaviour of the camera and the bug was more rare.
And I’m not sure but I have the feeling that if you use this rule, there is no more bug:
When you switch on your camera, be sure you are in the PHOTO mode, and when the boot of the camera and Magic Lantern are finished, now you can switch to the VIDEO mode, and shoot 14bit Lossless as long as you can.
This has to be tested more than I did. Tell me what you think about this trick.
In this case, I have the feeling that the bug comes back only when I’m too fast for start recording, just after a clip is finished.

Thanks again for your help
best regards

PS: by the way, I noticed also that what is reliable is to « double tap » the RoninS REC button to start recording. Same thing to stop recording.

Hi Dmytro!

Did you have time checking if you face the same ML-bug as me when recording 14bit lossless Raw with your 5D Mark III remoted by your Ronin-S, through the miniUSB cable?

Sorry to insist, but you're the only person I know who uses very similar settings
If you don't face any bug, you're lucky! Maybe it's because I'm using a genuine MCC-miniUSB cable (bought on DJI website) and not a cable+a micro-to-mini adaptator, like you?...
best regards

Hi Dmytro,
Thanks for your answer.
Unfortunatly I'm facing this bug even if I use 1.1.3 canon firmare like you.
(And by the way, we have the same ronin-s firmware (
I also try different ratios (16/9 or 2.35): same bug.
with or without sound: same bug.
with or without crop mode module: same bug.

The only way to make the bug dissapear is:
- to give up with 14bit LOSSLESS and come back to classic 14bit
- to unplug the cable MCC-miniUSB between the Ronin-S and the 5D Mark III

Looking forward to read you...

canon 5D Mark III firmware 1.2.3 with Canon Zoom 24-105 T4 II
Ronin S gimbal firmware v1.7.0.60


Let me introduce my configuration:
canon 5D Mark III firmware 1.2.3 with Canon Zoom 24-105 T4 II
Ronin S gimbal firmware v1.6.0.50

I love 14bit Lossless so much that I can’t imagine using Magic Lantern without it… It makes things so light and simple.
My Ronin S and my Canon 5D Mark III seem to be friends (thanks to a MCC-MiniUSB cable) as long as I don’t use « 14bit lossless » Data Format. If I do so and if I start recording, It ends up with this kind of disturbing message on the canon monitor:
« Save Configs…
Rec key pressed.
Starting raw recording…
Locking cache
Compression error -3 at frame 1
BKT giving up


and I also find that file on my card:
at mlv_lite.c:2695 (compress_task), task compress_task
lv:1 mode:3

compress_task stack: 1b0538 [1b05c8-1af5c8]
0x00069FA0 @ ac2edc:1b0568
0x00069878 @ 6a008:1b0538

Magic Lantern version : crop_rec_4k.2018Jul22.5D3123
Mercurial changeset   : c1e44b8e0183 (crop_rec_4k_mlv_snd) tip
Built on 2018-07-22 13:10:52 UTC by jenkins@nightly.
Free Memory  : 214K + 3523K

Anyone have an idea of how I can fix this bug?… One way to achieve this is to unplug the mCC-miniUSB cable, but that’s a pitty because the focus wheel doesn’t work anymore….

Best whishes for 2019!


after all henry lawson

by request I send 3 pictures of the vertical stripes, which shows that MLRawviewer seems much more efficient than MLVFS and Rawmagic...
I wish the fast MLVFS could be as efficient as MLRAWviewer for the vertical stripes!

never heard of "darkframe substraction"...
To "develop" my files, I use DaVinciResolve, maybe there is an equivalent in it?
see u

thanks a lot!
I did refresh the page, but in the end I couldn't see any difference between the "on" and "off" versions of the  "Vertical Stripes Fix" , on the exported clips of my 5D Mark III
When using MLRawviewer as a DNG converter, the "Vertical Stripes fix" seems to be much more efficient!...
It's strange...
best regards

I love MLVFS because it is so fast. I use MLVFS on my macbook pro.
But can anyone tell me how can I fix the vertical stripes on my 5D mark III footage?
The "Vertical Stripes Fix" option appears on the webpage, but for me it seems to be too late because the "virtual" cndg file has already been mounted... Should I use the "Fix pattern noise" option?...
So far the only app which gives a true "vertical stripes fix" on my 5D Mark III footage is MLRAwViewer. I wish I could do the same with MLVFS
best regards

With Resolve Lite 11.0.0, the pink banding in the highlights has desappeared!
best regards

my raw/mlv footage suffers from pink banding in the highlight when using "highlight recovery" in Resolve LIte 10.1.5.
You can see it in the sky here:

Is it normal? Is there an easy solution to avoid this pink banding? unfortunatly the advices given above in the discussion ( desaturation nodes) are a little bit complex to me, I'm not an expert in Da Vinci Resolve...

best regards,

If you had the time to do the whole process from the mlv file I uploaded, maybe you will meet my bug (and solve it maybe?).
The issue may not be noticeable on one single frame, but on the whole video file.
Maybe there is something wrong in the fps metadata? (As I said, I meet this problem only with 50i videos)
thanks a lot!

I'm glad to read that for you it seems to be only a color temperature issue with my clip (I was aware of that light shift).
What was your conversion method to go to this conclusion?
Unfortunatly, for me, it's much more than this: the mlv files are ok when read in MLRawviewer, but when I convert them to DNG, they appear to be dramaticaly green in Resolve  (debayer problem) and they make Resolve bug, and each time I'm forced to quit Resolve beacause it doesn't want to run these 50i clips!!!
Usually there is no problem, but with 25P clips.

one .MLV file:
one .DNG file:

I suspect a bug due to the fact that these clips were shot at 1280 50i...



I shoot .MLV clips with magiclantern-Nightly.2014May31.5D3113 on my 5D Mark III. I convert them to DNG with MLRAWviewer 1.1.6 on my Macbook Pro, to make color timing in Da Vinci Resolve Lite.
Last week, suddenly some of my clips had randomly the « green cast » issue. But thanks to this forum I could save my clips by using the "mlv_dump --black-fix=2048 »  method. It worked fine!

Unfortunatly since yesterday this method is useless!

Yesterday I’ve been shooting two types of clip:
- in 1920 25P mode: the mlv clips are fine, no green cast problem
- in 1280 50i mode (to get a slow motion effect) in 1928x606: the .mlv files seem to be ok when I read them in the FILE MANAGER or in MLRAWviewer, but the DNG files have the green cast problem in Resolve (and Resolve starts to bug). Unfortunalty the "mlv_dump --black-fix=2048 » doesn’t fix the problem, and neither does the "exiftool -BlackLevel=2048 input.dng » method.

What can I do to save my corrupted clips? I really need to make color timing in Resolve, which is much better that the MLRAWviewer APPLE PRoRes conversion.
How can I avoid this issue in the future?
(I have to specify that in order to avoid this issue, yesterday i switched ON  Memory hack, Extra hacks and Fix black level.)

Maybe it’s not a « black level" problem, but another metadata issue specific to the "1280 50i" mode?

thanks for your help!


Pages: [1]