Messages

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:
https://www.ebay.com/itm/USB-3-1-Type-C-Female-Jack-to-Mini-USB-5Pin-Male-Right-Angle-Power-Adapter-Cable/283355816927?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

Best regards
tom

canon 5D Mark III firmware 1.2.3 with Canon Zoom 24-105 T4 II IS and Canon 16-35 T4 IS
magiclantern-crop_rec_4k.2018Jul22.5D3123

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,
Tom

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
Tom

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
tom

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 (1.7.0.60))
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
OR
- to unplug the cable MCC-miniUSB between the Ronin-S and the 5D Mark III

Looking forward to read you...
tom

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

[« Save Configs...Rec key pressed.Starting raw recording...Locking cacheCompression error -3 at frame 1BKT giving upML ASSERT:0«]

Hi,

Let me introduce my configuration:
canon 5D Mark III firmware 1.2.3 with Canon Zoom 24-105 T4 II
magiclantern-crop_rec_4k.2018Jul22.5D3123
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
ML ASSERT:
0
«
etc...

and I also find that file on my card:
ML ASSERT:
0
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!
tom




after all henry lawson

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

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

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
Tom

Hi,
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
Tom

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

Hi,
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:
https://www.wetransfer.com/downloads/1156b11ece9daa7a3990836db1c2884120140624090259/5eb218c97e6c13dc89ad9b897991175020140624090259/3855eb

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,
tom

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: http://we.tl/UAb7JQYQDb
one .DNG file: http://we.tl/wkt9Is7dTG

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

thanx
tom

Hi

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!

tom