Magic Lantern is an enhancement atop of Canon's firmware that frees your Canon DSLR, allowing you to use many useful features. It is an open (GPL) framework for developing extensions to the official software.
No. Magic Lantern runs from the card, as an add-on over standard firmware. You will still be able to access all Canon functionality.
To go back to Canon firmware, you may:
SETat startup to bypass ML only once (for the current session).
Firmware Upgradeand follow the instructions).
No. First versions were developed by independent filmmakers and tailored for video production on 5D Mark II. Things changed when Magic Lantern was ported to smaller (APS-C) cameras, like 550D, 60D, 600D and 500D, which attracted developers interested in both still photography and DSLR video.
This is a
clean room /
black box reverse engineering effort and as such should be OK. Frequently asked questions about reverse engineering addresses the legality question; producing an interoperable product is one of the explicit allowances enshrined in law.
Magic Lantern does not contain any Canon code. Also, we do not distribute any copyrighted code or cryptographic secrets, neither from Canon nor from any other third party. All the knowledge used for development was obtained by analyzing ARM code, by experimenting, and from lawfully obtained documentation.
No. Magic Lantern was created by reverse engineering an undocumented system that controls hardware. Therefore, we can't be certain that it's 100% safe.
Magic Lantern does not replace Canon code (which is stored in ROM), but it does change the settings (which are saved to a non-volatile memory). If Magic Lantern would set incorrect values for certain settings, this may cause the camera not to boot (even without ML).
The same risk is present if you use third party software for USB remote control. These programs use the same API for changing camera settings (properties), and Canon code does not always check the validity of the settings before saving them to NVRAM. Here's a proof. Even developers of USB control software, who use Canon's own SDK, agree with this.
Imagine that your config file gets corrupted and you can't just delete it and start from scratch. We consider this a design flaw in Canon software. We did encounter such problems during development, but we were able to recover from them. For technical details, see Unbricking.
Probably the safest way to run Magic Lantern (or any third party camera control software) is to use custom modes - in these modes, Canon code does not save user settings to NVRAM.
In practice, we are doing our best to prevent these situations, and thousands of users are enjoying it without problems. However, this does not represent a guarantee - use it at your own risk.
Actually, using Magic Lantern we have successfully unbricked a 5D Mark II damaged by a USB remote controller app.
A Magic Lantern user posted this on dpreview:
I've spoken to canon Cps (pro service in UK) and they've advised me that it's quite possible to downgrade firmware from new version to older version BUT they advised me to send it in to Canon for them to do it and test. Small service charge would be involved but could be done while I wait.
Interestingly enough, they also advised me that Magic Lantern firmware would not invalidate my Canon Warranty as it's not a hardware modification. Though I'm reluctant to find out for sure
And another user posted this on t2iforum:
I contacted Canon Support Portugal about using ML, the answer was the following:
(…) the use of custom firmware or any other third party acessory with our equpment will void the warranty of the product IF PROVEN that the malfunction of the device was caused by the use of those.
Canon respects the rights that their customers have to decide what accessories or firmware to use, although we do not recommended their use, and we are not responsible for any damage to the equipment.
The Magic Lantern firmware is distributed with NO WARRANTY and NO GUARANTEES are provided. It might work. It might not. It hasn't destroyed any cameras yet, but who knows.
We have updated it to work with the latest version of Canon firmware on all supported cameras. This is a manual process to find the symbols in each new version, although tools like patchdiff2, Gensig/Finsig and GPL Tools/match.py make it much easier. Each new version must be statically linked against addresses in the firmware ROM as if it were a library, which requires locating the entire set of symbols.
Despite this tight integration, Magic Lantern software does not contain any Canon code. It is entirely a clean-room implementation that runs along side the official Canon firmware as a separate DryOS task.
Magic Lantern Overlays are only displayed when the Canon overlays are disabled. Turn GlobalDraw on. Then, while in Liveview or Movie mode, press the DISP or INFO button until the Canon overlays are turned off.
Delete the config file (
MAGIC.CFG) and restart the camera.
Canon menu → Format → Format card, keep Magic Lantern.
Clear Overlaysfeature to hide the focus box and the 16:9 bars, and make the half-shutter button sticky to prevent the camera from turning off LiveView after 30 minutes.
Technically, there's no 12 minute limit. There's a 30 minute limit and a 4 GB limit, whichever comes first. With default bitrate settings, the 4 GB limit is reached after around 12 minutes (more or less).
You may use:
Look in `Debug`_ menu.
Yes. Increase display gain, use a low FPS (with FPS override), or both.
Also check out the dark color schemes optimized for night shooting, or try disabling exposure simulation.
You have a couple of options:
Yes. Check out these features:
In LiveView it draws 3-5% more power (measured on 60D and 5D Mark II with zebra and focus peaking active). You can do your own tests if you have a 60D.
Magic Lantern can reduce power consumption by dimming or turning off the LCD screen, or by pausing LiveView without moving the mirror. See `Power saving`_ for details.
In plain photo mode with display off, the power draw is a bit higher, because Magic Lantern disables CPU powersaving features (otherwise, intervalometer and other ML functions would stop running). We have measured 6% / hour on 60D (compared with 4% / hour with Canon firmware), and 10% / hour on 5D Mark II (compared with 5% / hour with Canon firmware).
You will have to adjust the volume manually; use the audio meters to determine the proper level.
Best audio is obtained by use of a preamp system fed to the camera. As a general rule, the use of a quiet preamp to send the signal to the camera will result in better the sound recorded in camera. Use of a preamped XLR adapter like the JuicedLink CX231 or a field mixer will give superior results. You may also use a recorder like Zoom H1, H2 or H4n, but since the line out level is much higher than the mic level, you will have to turn the output down from your recorder or use a pad cable.
For more info, check out the Canon DSLR Audio thread on dvxuser and AGC Disable - Magic Lantern vs. Juicedlink? on dvinfo.
From Canon menu.
Follow the install guide. You will have to copy Magic Lantern files on your card and run Update firmware from the menu. The running firmware shuts down, loads the file into RAM and starts it running. Rather than reflashing the ROMs, this new program starts the DryOS boot process to install itself.
Simply format the card. The bootflag will be still there, but it will not affect normal operation (except for EyeFi cards).
To remove the bootflag (for using EyeFi cards), run Firmware Update from a ML card and follow the instructions.
It will not boot. Magic Lantern checks firmware version before attempting to run - if it doesn't match, the card LED will start blinking and you'll have to take the battery out.
Sometimes you have the right version number, but a different sub-version number (there are 3 more version digits, which are not displayed on the screen). If it happens, simply upgrade Canon firmware from the links mentioned in the install guide.
Yes. Besides the bootflag (which is required for auto-boot), there are a couple of other changes which are saved into NVRAM. These are:
*) button whenever ML has to take a picture without autofocusing. This includes HDR bracketing and bulb exposures.
With few exceptions, these settings can also be changed from Canon menus or controls.
A few settings are changed temporarily during certain operations (for example, autofocus for bracketed shots), but these settings are saved by Canon firmware in NVRAM. If you take the battery out in the middle of the operation (for example, in the middle of taking a picture), ML won't be able to restore these settings back to your initial values, and you'll have to change them back from Canon menus.
To the best of our knowledge, all these settings are restored to default values when you run
Clear camera settings and
Clear custom functions from Canon menu.
All persistent changes can be seen in ML source code by examining the calls to
prop_request_change. Some of the changes are not persistent (for example, LiveView zoom level), and they were not included in the above list.
We had serious problems with it, so it was disabled. The problems were confirmed with a minimal example code, so the issue is either in Canon firmware (which was probably not designed for dynamic mode remapping) or in the way we request the mode remapping procedure.
The only way to get it back is to show us a safe way to change the shooting mode. For this you need to point out what's wrong with this call:
prop_request_change(PROP_SHOOTING_MODE, &new_mode, 4), and suggest a different method - which can only be done by examining Canon code and understanding how mode switching works.
Testing will not help - the probability of things going wrong is very low, but nonzero.
`Trap focus`_ may be active.
Mirror Lockup (MLU) is active.
It was probably moved to back button (
AF-ON). Check your custom functions. It may happen if you take the battery out in the middle of photo shooting.
Anyway… any serious DSLR user should set AF to back button ;)
You may need to register it from Canon menu. This is not related to ML, but people tend to blame ML for Canon quirks.
This problem is not related to (or caused by) Magic Lantern.
You will get this error when your shutter mechanism no longer works properly. Contact your Canon service center.
Consider entering your shutter count in the Camera Shutter Life Database.
We have used some of the CHDK tools to learn about Canon firmware files, but this is all new code. They have done an amazing job of supporting hundreds of different camera models across multiple architectures and operating systems. At some point in the future chdk might be ported to the 5D Mark 2, but this project is much more focused on just the 5D Mark II and the needs of film makers. CHDK is a great project for Canon's Point-and-Shoot cameras. Without their initial effort in understanding DryOS, Canon's firmware files and the boot process, I wouldn't have been able to make as much progress as quickly as I did. While I was able to use modern tools to analyze dump files of ROM images thanks to their efforts, they got started bitbanging a UART via the status LED on a camera body. That's truly hardcore.
Originally the project was called just
5D Mark Free, but out of an abundance of caution it seemed best to avoid Canon's trademarks.
The firmware hack is in C, with some inline assembly for boot strapping. The firmware build tools are in Perl and use Makefiles for dependency tracking. You need an arm-linux-elf build of gcc and binutils. Most of the code analysis has been done with objdump, strings and the IDA demo. No tech support will be provided. If it breaks you get to keep both pieces. If you know what all of these terms mean and aren't scared of the possibility of breaking your camera, you can download the Magic Lantern firmware source code.
We do not distribute ROM images, nor IDA .idb files, since they are verbatim copies of Canon's copyrighted code. You can generate the ROM images from your own camera by compiling with
CONFIG_DEBUGMSG=1 and then selecting
Dump ROM from Debug menu.
These are the addresses in the official ROM firmware for different functions and names that we have given to functions. If you load the ROM0.bin image into IDA or use objdump you can trace through the instructions to determine how the software works. If you are just using the camera, they don't need to mean anything to you, but they give other developers a place to look in the firmware image.
The function names are unlikely to be the same as the ones in Canon's source code, which we have never seen. We name functions based on what they seem to do, or debugging / diagnostic strings embedded in the function. It isn't perfect, but it is sufficient to locate the important things for task creation, file I/O and GUI operation.
No one at Canon has contacted us regarding Magic Lantern or software development for their DSLR cameras. We are very eager to discuss the project with them, however, so if you have any technical contacts inside of Canon's software team, please put them in touch with us.
Ask one of those and you may get banned from our forum ;)
When you buy this camera and slap a Canon sticker on it.
Because the 650D isn't your Sony camera.
What's that got to do with the price of rice in China?
Knowing where to tweak which register values to get other resolutions is as simple as translating a pile of Egyptian glyphs.
How exactly did you reach this conclusion?
If you can't find anything about it in the relevant forum thread, it's safe to assume there was none.
If you are interested in XYZ and have the skills to improve it, feel free to do so and submit a pull request.
If you don't have the right skills, asking this question will only serve to annoy those who might have them. Doing some research about XYZ and sharing your findings would be much better - this may encourage others to take a look at it.
When it's ready.
Not only that, but the nature of development, especially the kind of reverse-engineering that goes on in the case of something like ML, is unpredictable. A single issue might be fixed in five minutes, or it may take six months to solve.
Chasing the devs for ideas about timescales, feature implementations and so on is a little pushy. They will get to it in their own time and announce what they are working on and so on here. So feel free to ask about upcoming features, but the “when” question only really serves to slightly irritate devs.
As soon as some new feature / bug fix becomes good enough for us, it will be included in the nightly builds.
As soon as you will provide us with clear and concise testing and bug reports for all ML features from the nightly builds.
Since this did not happen for the past few years, and we no longer have the time and resources to do the testing ourselves, there are currently no plans for a new stable release.
However, the nightly builds can now be considered somewhat stable, and if something important breaks, it's usually fixed quickly if you report the issue.