For a look at some of the amazing output from an "ancient" EOS, you can look at Magic Lantern's Discord. It's rather shocking how far this little camera could be pushed. It is definitely a fun hobby project to fool around with these things. After awhile I stopped having the time and moved over to Sony APS-C with vintage lenses. I was able to maintain some of the aesthetic without getting frustrated by stuttering video. Still it's really a cool project.
joatmon-snoo 7 hours ago [-]
For folks who don't know what Magic Lantern is:
> Magic Lantern is a free software add-on that runs from the SD/CF card and adds a host of new features to Canon EOS cameras that weren't included from the factory by Canon.
It also backports new features to old Canon cameras that aren't supported anymore, and is generally just a really impressive feat of both (1) reverse engineering and (2) keeping old hardware relevant and useful.
bprater 33 minutes ago [-]
More backstory: before the modern generation of digital cameras - Magic Lantern was one of the early ways to "juice" more power out of early generations of Canon cameras, including RAW video recording.
Today, cameras like Blackmagic and editing platforms like DaVinci handle RAW seamlessly, but it wasn't like this even a few years ago.
nottorp 4 hours ago [-]
Funny, when i saw it uses a .fm TLD i thought it's some online radio.
names_r_hard 3 hours ago [-]
They were trendy at the time :D
I think possibly someone thought it sounded a bit like firmware?
xwowsersx 3 hours ago [-]
Same :) I had in mind Groove Salad from soma.fm
esafak 1 hours ago [-]
last.fm
t0bia_s 2 hours ago [-]
I wish there are similar projects for other camera brands like Fujifilm. With abilities of ML on old Canon cameras we know there is a lot of potential in those old machines across other brands. It is also "eco" friendly approach that should be supported.
bhickey 2 hours ago [-]
I just switched from Canon to Fujifilm due to enshitification. Canon started charging $5/mo to get clean video out of their cameras. We're plenty screwed if manufacturers decide that cameras are subscriptions and not glass.
hypercube33 4 hours ago [-]
it also has a scripting system and is damn fun to mess with.
IshKebab 5 hours ago [-]
> The main thing you need is knowledge of C, which is a small language that has good tutorials.
Heh, a little like saying "the main thing you need is to be able to play the violin, which is a small instrument with good tutorials".
names_r_hard 5 hours ago [-]
I stand by my statement! Compare the length of the C standard to JS / ECMAScript, or C++! :)
Maaaaybe I'm hiding a tradeoff around complexity vs built-in features, but volunteers can work that out themselves later on.
You honestly don't need much knowledge of C to get started in some areas. The ML GUI is easy to modify if you stay within the lines. Other areas, e.g., porting a complex feature to a new camera, are much harder. But that's the life of a reverse engineer.
Etheryte 4 hours ago [-]
Conversely, the terseness of the C standard also means there's many more footguns and undefined behaviors. There are many things C is, but being easy to pick up is not one of them. I loved C all the way up until I graduated uni, but it would be a very hard sell to get me to pick it for a project these days. To me, working with C is akin to working with assembly, you just feel that you're doing real programming, but realistically there's better options for most scenarios these days.
names_r_hard 4 hours ago [-]
I agree with some of what you're saying; some of the well known risks of working in C are because it's a small standard. But much of the undefined behaviour was deliberately made that way to support the hardware of the time - it's hard to be cross-platform on different architectures as a low-level language.
C genuinely is easy to pick up. It is harder to master. And you're right, for many domains, there are better options now, so it may not be worth while mastering it.
Because it's an old language, what it lacks in built-in safety features, is provided by decades of very good surrounding tooling. You do of course need to learn that tooling, and choose to use it!
In the context of Magic Lantern, C is the natural fit. We are working with very tight memory limitations, due to the OS. We support single core 200Mhz targets (ARMv5, no out-of-order or other fancy tricks). We don't include C stdlib, a small test binary can be < 1kB. Normal builds are around 400kB (this includes a full GUI, debug capabilities, all strings and assets, etc).
Canon code is probably mostly C, some C++. We have to call their code directly (casting reverse engineered addresses to function pointers, basically). We don't know what safety guarantees their code makes, or what the API is. Most of our work is interacting with OS or hardware. So we wouldn't gain much by using a safe language for our half.
C is considered easy to pick up for the average user posting HN comments because we have the benefit of years -- the average comp sci student, who has been exposed to Javascript and Python, who might not know what "pass by reference" even means... I'm not sure they're going to be considering C easy.
names_r_hard 3 hours ago [-]
I've taught several different languages to both 1st year uni students, and new joiners to a technical company, where they had no programming background.
Honestly, C seems to be one of the easier languages to teach the basics of. It's certainly easier than Java or C++, which have many more concepts.
C has some concepts that confuse the hell out of beginners, and it will let you shoot yourself in the foot very thoroughly with them (much more than say, Java). But you don't tend to encounter them till later on.
I have never said getting good at C is easy. Just that it's easy to pick up.
wkjagt 3 hours ago [-]
C made a lot more sense to me after having done assembly (6502 in my case, but it probably doesn't matter). Things like passing a reference suddenly just made sense.
37 minutes ago [-]
jibal 53 minutes ago [-]
Everything is passed by reference in Python. Everything is passed by value in C.
ptero 4 hours ago [-]
Undefined behaviors -- yes. But being able to trigger undefined behavior is not a huge foot gun by itself. Starting with good code examples means you are much less likely to trigger it.
Having a good, logical description of supported features, with a warning that if you do unsupported stuff things may break, is much more important than trying to define every possible action in a predictable way.
The latter approach often leads to explosion of spec volume and gives way more opportunities for writing bad code: predictable in execution, but instead with problems in design and logic which are harder to understand, maintain and fix. My 2c.
BiteCode_dev 2 hours ago [-]
I stand by my statement! Compare the number of strings a violin has to the keys on a piano! :)
chrisweekly 2 hours ago [-]
I know it's all at least semi- tongue-in-cheek, but IRL a piano's discrete, sequential keys are what make it almost inarguably the easiest instrument to learn.
IshKebab 2 hours ago [-]
That's exactly his point. Languages aren't easier to learn simply because their specification is short, any more than instruments are easier to play because they have fewer strings.
jibal 56 minutes ago [-]
The analogy is completely invalid. Languages with small specifications are easier to learn.
It's sad that the dev, who has done great work, has to spend time defending the C language from critters living under a bridge when it's a fixed element that isn't going to change.
thijson 39 minutes ago [-]
People don't argue with a carpenter over what tools were used to build a piece of furniture. It feels like a religious debate.
chrisweekly 52 minutes ago [-]
Accusing people who disagree w/ you of being trolls doesn't bolster your argument.
names_r_hard 5 hours ago [-]
Thanks to all who are sharing their appreciation for this niche but cool project.
I'm the current lead dev, so please ask questions.
Got a Canon DSLR or mirrorless and like a bit of software reverse engineering? Consider joining in; it's quite an approachable hardware target. No code obfuscation, just classic reversing. You can pick up a well supported cam for a little less than $100. Cams range from ARMv5te up to AArch64.
dylan604 41 minutes ago [-]
I still shoot a 5Dmkii solely due to the ML firmware. It's primarily a timelapse camera at this point. The ETTR functionality is one of my absolute favorites. The biggest drawback I have is trying to shoot with an interval less than 5 seconds. The ML software gets confused and shoots irregular interval shots. Anything over 5 seconds, and it's great. No external timers necessary for the majority of my shooting. I do still have an external for when <5s intervals are necessary. I'm just waiting for the shutter to die, but I'm confident I'll just have it replaced and continue using the body+ML rather than buy yet another body.
Thanks for your work keeping it going, and for those that have worked on it before.
names_r_hard 23 minutes ago [-]
Strange, it certainly can do sub 5s on some bodies. But I don't have a 5d2 to test with.
Could this be a conflict with long exposures? Conceivably AF, too. The intervalometer will attempt to trigger capture every 5s wall time. If the combined time to AF seek, expose, and finish saving to card (etc) is >5s, you will skip a shot.
When the time comes, compare the price of a used 5d3 vs a shutter replacement on the 5d2, maybe you'll get a "free" upgrade :) Thanks for the kind words!
dylan604 15 minutes ago [-]
> Could this be a conflict with long exposures?
I've done lots of 1/2 second exposures with 3s interval, and it shoots some at much shorter interval than 3 and some 3+??? At one point, the docs said 5s was a barrier. Maybe it was the 5dmkii specifically. All of my cards are rated higher than the 5D can write (but makes DIT much faster) so I doubt it is write speed interfering. What makes me think it is not the camera is that using a cheap external timer works without skipping a beat.
GranPC 5 hours ago [-]
What's the situation re: running on actual hardware these days? I was experimenting around with my 4000D but when it came to trying to actually run my code on the camera rather than the emulator, a1ex told me I needed some sort of key or similar. He told me he'd sign it for me or something but he got busy and I never heard back.
Is this situation still the same? (Apologies for the hazy details -- this was 5 years ago!)
names_r_hard 4 hours ago [-]
That must have been a few years back. I think you're talking about enabling "camera bootflag". We provide an automated way to do this for new installs on release builds, but don't like to make this too easy before we have stable builds ready. People do the weirdest stuff, including trying to flash firmware that's not for their cam, in order to run an ML build for that different cam...
Anyway, I can happily talk you through how to do it. Our discord is probably easiest, or you can ask on the forum. Discord is linked from the forum: https://www.magiclantern.fm/forum/
Whatever code you had back then won't build without some updates. 4000D is a good target for ML, lots of features that could be added.
GranPC 4 hours ago [-]
Yes, this was in September 2020 according to my records. All I remember is that I could run the ROM dumper just fine, then I could run my firmware in QEMU, and then I just had to locate a bunch of function pointers to make it do anything useful. Worked in QEMU but that's where I got stuck - no way to run it on hardware.
I'll definitely keep this in mind and hit you up whenever I have a buncha hours to spare. :)
names_r_hard 4 hours ago [-]
That would have been only a little before a1ex left. Getting code running on real hardware is easy, maybe I'll talk to you in discord in a few months when you find this fabled free time we are all looking for ;)
So it has hardware from 2008, but they did update the OS to a recent build. This is not what the ML code expects to find, so it's been a confusing test of our assumptions. Normally the OS stays in sync with the hardware changes, which means when we're reversing, it's hard to tell which changes are which.
That said, 4000D is probably a relatively easy port.
Vagantem 5 hours ago [-]
Just wanted to say thanks for keeping this alive! I used magic lantern in 2014 to unlock 4K video recording on my Canon. It was how students back then could start recording professional video without super expensive gear
CarVac 2 hours ago [-]
I would love to add it to my 1Ds3. I recall reading that once upon a time Canon wrote ML devs a strongly worded letter telling them not to touch a 1D, but a camera that old is long obsolete.
(I literally only want a raw histogram)
(I also have a 1Dx2 but that's probably a harder port)
dylan604 35 minutes ago [-]
I have been toying with the idea of picking up an old 1D. I can't remember the guy's name that I saw do this, but he had his 1D modified to use a PL mount instead of an EF mount. Something about the 1D body (being thicker I guess) allowed for the flange distances to work out. He then mounted a $35,000 17mm wide angle to it. That lens was huge and could just suck in photons. With that lens, he could expose the night sky in 1/3 second exposures what would take multiple seconds on my gear. He mounted the camera to the front of his boat floating down river using night vision goggles to see where he was going. The images were fantastic. I always wanted to do something crazy like that
names_r_hard 21 minutes ago [-]
Canon have never had any contact with ML project for any reason, to the best of my knowledge. The decision to stay away from 1D series was made by ML team, I would say out of an abundance of caution to try not to annoy them.
ASlave2Gravity 4 hours ago [-]
Hey just want to say a massive thank you for everything you've done with this project. I've shot so much (short films, music videos, even a TV pilot!) on my pair of 600Ds and ML has given these cams such an extended life.
It’s been a huge blessing!
archerx 5 hours ago [-]
I use magic lantern on my canon 650D to get a clean feed for my blackmagic ATEM. The installation was easy and everything works well.
Thank you and the magic lantern team!
aorth 9 hours ago [-]
> We're using Git now. We build on modern OSes with modern tooling. We compile clean, no warnings. This was a lot of work, and invisible to users, but very useful for devs. It's easier than ever to join as a dev.
Very impressive! Thankless work. A reminder to myself to chase down some warnings in projects I am a part of...
ChrisMarshallNY 5 hours ago [-]
It’s not too difficult, if you do it from the start, and by habit.
I have an xcconfig file[0], that I add to all my projects, that turns on treat warnings as errors, and enables all warnings. In C, I used to compile -wall.
I also use SwiftLint[1].
But these days, I almost never trigger any warnings, because I’ve developed the habit of good coding.
Since Magic Lantern is firmware, I’m surprised that this was not already the case. Firmware needs to be as close to perfect as possible (I used to write firmware. It’s one of the reasons I’m so anal about Quality).
It's not firmware :) We use what is probably engineering functionality, built into the OS, to load and execute a file from disk. We run as a (mostly) normal program on the cam's normal OS.
Warnings are treated as errors for release builds.
ChrisMarshallNY 5 hours ago [-]
Awesome!
Great work, and good luck!
names_r_hard 3 hours ago [-]
Thanks, and for what it's worth, I didn't downvote you (account is too new to even do so :D ), and I agree with your main point - it's not that hard to avoid all compiler warnings if you do it from the start, and make sure it's highly visible.
You only add one at a time, so you only need to fix one at a time, and you understand what you're trying to do.
It is, however, a real bitch to fix all compiler warnings in decade old code that targets a set of undocumented hardware platforms with which you are unfamiliar. And you just updated the toolchain from gcc 5 to 12.
ChrisMarshallNY 2 hours ago [-]
Oh, don't worry about the downvotes. Happens every time someone starts talking about improving software Quality around here.
Unpopular topic. I talk about it anyway, as it's one of my casus belli. I can afford the dings.
BTW: I used to work for Canon's main [photography] competitor, and Magic Lantern was an example of the kind of thing I wanted them to enable, but they were not particularly open to the idea -control freaks.
Also, it's a bit "nit-picky," I know, but I feel that any software that runs on-device is "firmware," and should be held to the same standards as the OS. I know that Magic Lantern has always been good. We used to hear customers telling us how good it was, and asking us to do similar.
I think RED had something like that, as well. I wonder how that's going?
pavel_lishin 18 minutes ago [-]
I should give this a shot. I used to use CHDK so I could use my old crappy Canon into something that would take good time-lapse videos by snapping a photo every X seconds; I miss doing that, though now it's harder because I live in the 'burbs, and there's no particularly spots for that nearby, and anywhere that is a good spot likely doesn't have a power outlet for me to use. I wonder how long I could power my camera from a portable charger?
heliographe 5 hours ago [-]
Yes! As a software developer in the photography space, we are deeply in need of projects like this.
The photography world is mired in proprietary software/ formats, and locked down hardware; and while it has always been true that a digital camera is “just” a computer, now more than ever it is painful just how limited and archaic on-board camera software is when compared to what we’ve grown accustomed to in the mobile phone era.
If I compare photography to another creative discipline I am somewhat familiar with, music production - the latter has way more open software/hardware initiatives, and freedom of not having to tether yourself to large, slow, user-abusing companies when choosing gear to work with.
Long live Magic Lantern!
waz0wski 49 minutes ago [-]
Agreed
cries in .x3f & Sigma Photo Pro
christiangenco 9 minutes ago [-]
Looks like there's still no support for the M50. I hope with the revitalized development it's on the roadmap!
privatelypublic 7 hours ago [-]
Unfortunately, they're not using a github organization- leaving it to fail again if that account disappears. Continuity is hard.
If it's github.com/magiclantern/magiclantern ownership can change hands via organizational user changes.
teamonkey 6 hours ago [-]
An alternative to Magic Lantern is CHDK. Unfortunately that also feels somewhat abandoned and at the best of times held together with string* so I’m glad ML is back.
*No judgement, maintaining a niche and complex reverse-engineering project must be a thankless task
Cool! Am i the only one who has a really hard time finding what models are supported? It says on the frontpage that it's on the downloads page, but I can't seem to find anything?
EDIT: It's on the builds page https://builds.magiclantern.fm
It is actually easier to get started now, as I spent several months updating the dev infrastructure so it all works on modern platforms with modern tooling.
Plus Ghidra exists now, which was a massive help for us.
We didn't really go on hiatus - the prior lead dev left the project, and the target hardware changed significantly. So everything slowed down. Now we are back to a more normal speed. Of course, we still need more devs; currently we have 3.
raffael_de 1 hours ago [-]
What would be something you can achieve using ML that you couldn't do with the stock firmware and postprocessing?
dylan604 24 minutes ago [-]
The list is so long. My favorite is the internal intervalometer + ETTR. Canon has always been laughed at for not having an internal intervalometer, and ML proves how lame it is to not have one. ETTR (Expose To The Right) is an auto metering mode that allows the camera to keep the histogram pushed as far to the right (better exposure) automagically by increasing shutter time and/or increasing ISO. This is essential for doing holy grail timelapse of sunset/sunrise where the exposure is constantly changing. This feature alone is worth it's weight in gold.
However, a lot of the features exposed are more video oriented. The Canon bodies were primarily photo cameras that could shoot video in a cumbersome way. ML brings features a video shooter would need without diving into the menus like audio metering. The older bodies also have hardware limitations on write speed, so people use the HDMI out to external recorders to record a larger framesize/bitrate/codec than natively possible. Also, that feed normally has the camera UI overlay which prevents clean recordings. ML allows turning that off.
There are just too many features that ML unlocks. You'd really just need to find the camera body you are interested in using on their site, and see what it does for that body. Different bodies have different features. So some effort is required on your part to know exactly what it can do for you.
mikepurvis 26 minutes ago [-]
I don't know if modern cameras are better for this, but a big one historically was getting a clean, realtime HDMI output so that high quality cameras can be used with a capture card for broadcast purposes as a replacement for a webcam. Manufacturers understand that that's a "pro" level need/feature and have intentionally segmented the market so that lower-tier devices can't do it even though the hardware is obviously all present.
dokimus 15 minutes ago [-]
The big one for me was always focus peaking when using vintage lenses or doing IR photography. The extended White Balance settings were nice to have for IR, as well.
ZiiS 6 hours ago [-]
This news is probably my excuse to buy my forth EOS; the first three were 100% only because of Magic Lantern.
Can't understand why manufacturers make this hard as it sells hardware.
Ballas 5 hours ago [-]
> Can't understand why manufacturers make this hard as it sells hardware.
Because a lot of features that cost a lot of money are only software limitations. With many of the cheaper cameras the max shutter speed and video capabilities are limited by software to make the distinction with the more expensive cameras bigger. So they do sell hardware - but opening up the software will make their higher-end offerings less compelling.
i_am_proteus 6 hours ago [-]
Magic Lantern is fantastic software that makes EOS cameras even better, but I understand why manufacturers make it hard:
Camera manufacturers live and die on their reputation for making tools that deliver for the professional users of those tools. On a modern camera, the firmware and software needs to 100% Just Work and completely get out of the photographer's way, and a photographer needs to be able to grab a (camera) body out of the locker and know exactly what it's going to do for given settings.
The more cameras out there running customized firmware, the more likely someone misses a shot because "shutter priority is different on this specific 5d4" or similar.
I'm sure Canon is quietly pleased that Magic Lantern has kept up the resale value of their older bodies. I'm happy that Magic Lantern exists-- I no longer need an external intervalometer! It does make sense, though, that camera manufacturers don't deliberately ship cameras as openly-programmable computational photography tools.
mcdeltat 5 hours ago [-]
You have an interesting point about consistency and I'd like to provide a counterargument. While control consistency is very important, the actual image you get from a camera varies significantly between models as the manufacturers change tone curves, colour models, etc. JPGs from the camera are basically arbitrary and RAWs are not much better. The manufacturers don't provide many guarantees, it's just up to you and downstream software to figure out what looks good.
Funny that so much thought goes into designing the feel of a camera yet the photo output is basically undefined...
Also another thing, Magic Lantern adds optional features which are arbitrarily(?) not present on some models. Perhaps Canon doesn't think you're "pro enough" (e.g. spent enough money) so they don't switch on focus peeking or whatever on your model.
i_am_proteus 5 hours ago [-]
If you want JPGs to look different, you can change them in the camera, and RAW files are just that: raw. They will vary between cameras slightly because the cameras have different sensors. Editing RAWs from 5d3 vs. 5d4 vs. 6d (my only experience) is not very different. Ultimately, the workflow that matters is a photographer capturing the image and getting the output to the studio quickly, in high quality. Event photographers often tether via ethernet or USB and the studio can post-process the RAW in minutes (or even seconds). The part of this that is most sensitive and hardest to recover from error is the photographer capturing the image, which is why consistency and usability of camera controls is so important.
IIRC none of the EOS DSLRs had focus peaking from the factory, you need Magic Lantern -- Canon didn't program it at all.
dannyfritz07 2 hours ago [-]
I just got my T2i out a few months ago and the first thing I did was check for new magic lantern versions. haha. Really cool to see this project is still living.
andy_ppp 5 hours ago [-]
Would love it if camera manufacturers were forced to open source their firmware after say 5 years of a camera’s release. The longevity of devices would be vastly improved.
In fact make this all devices with firmware, printers, streamers etc.
can16358p 4 hours ago [-]
I don't think forcing a company to open source their IP is a good move, but perhaps there might be some encouragement implemented for opening up their bootloader so the device is more hackable.
But forcing is never a right thing.
names_r_hard 3 hours ago [-]
The entire copyright and patent system is built on the principle of forcing the release of IP; it is time delayed in exchange for the legal protections you gain if you opt in to the system. That is the encouragement!
Extending this to enable software access by 3rd parties doesn't feel controversial to me. The core intent of copyright and patent seems to be "when the time limit expires, everyone should be able to use the IP". But in practice you often can't, where hardware with software is concerned.
dsmurrell 6 hours ago [-]
Magic Lantern is amazing... I used it with a custom C script to do auto ISO in Av mode (setting minimum shutter speed based on focal length) before that was built into the newer camera models. It's good to see it back!
leducw 8 hours ago [-]
This is such excellent news! I was extremely sad when progress was halted, lost hope my 80D would ever get cfw.
names_r_hard 6 hours ago [-]
The 80D has Magic Lantern code available. We haven't released a build to the public as it has such minimal features available there's no real point yet. But if you were thinking of doing dev work for it, it's in a good place to start: ML GUI works, debug logging works.
namibj 4 hours ago [-]
I have fond memories of squeezing so deep exposure stacking out of the auto/adaptive-HDR-bracketing script in CHDK on my old "IXUS 100IS", that the AFAIK still CCD had severe blooming around the window in the scene. Still great though!
shrx 7 hours ago [-]
Thanks to all contributors to the project, ML is an amazing feat of work. I've been running it on my Canon 6D since I got it in 2016, very useful for timelapses.
Brajeshwar 5 hours ago [-]
This is not about the key logging spyware Magic Lantern. I thought this would be an interesting read with whatever is happening around the world.
Are there modded firmware for Sony or Lumix cameras?
MartijnBraam 4 hours ago [-]
Magic lantern is amazing. I'm still hoping a project grows for the other camera brands since I only have Nikon and Panasonic cameras.
freeqaz 7 hours ago [-]
I was trying to understand what this project is. It's some sort of open firmware for Canon camera that you put on the flash card (SD). The home page has info: https://www.magiclantern.fm/
ioma8 6 hours ago [-]
Yes its truly noteworthy project. They exploited Canon cameras by first managing to blink red charging LED. Then they used the LED blinks to transmit the firmware out. Then they built custom firmware which boots right from SD (thus no posibility to break the camera). The Magic Lantern firmware for example allows many basic cameras to do RAW 4K video recording (with unlimited length) - feature which is not even in the high-end models. But it has much more features to tinker with.
names_r_hard 5 hours ago [-]
There's a fun step you're missing - it's not firmware. We toggle on (presumably) engineering functionality already present in Canon code, which allows for loading a file from card as an ARM binary.
We're a normal program, running on their OS, DryOS, a variant of uITRON.
This has the benefit that we never flash the OS, removing a source of risk.
names_r_hard 6 hours ago [-]
Hi - I'm the current lead dev.
It's not firmware, which is a nice bonus, no risk of a bad rom flash damaging your camera (only our software!).
> As of December 2024, the Magic Leap One is no longer supported or working, becoming end of life and abruptly losing functionality when cloud access was ended. This happened whilst encouraging users to buy a newer model.
Ah, that’s about how I thought that would end up.
Cthulhu_ 7 hours ago [-]
Its demise seems to have completely passed me by; I read about its enormous funding and unrealistic expectations, then a v1 came out which was mediocre/disappointing, then... nothing. Apple's thing overshadowed it, but that too has passed - unless they're going to announce a new model at a fraction of the price soon, supposedly their UI redesigns follow its concepts so it's not buried yet.
larodi 4 hours ago [-]
If I’m to get a secondhand camera to run MM which would your recommend? 200D or 600D?
names_r_hard 4 hours ago [-]
I wouldn't recommend the 600D if you want to do video. For stills it's perfectly acceptable. Auto-focus will feel slow compared to a modern cam. If you're going for an old / budget cam, try and reach to the 650D or 700D, those are a newer generation of hardware.
200D is much newer, but less well supported by ML. I own this cam and am actively working on improving it. 200D has DPAF, which means considerably improved auto-focus, especially for video. Also it can run Doom.
Are there any ML features in particular you're interested in?
thot_experiment 6 hours ago [-]
CHDK and Magic Lantern are fantastic, I really wish there was a Nikon equivalent.
names_r_hard 5 hours ago [-]
[dead]
miguehm 7 hours ago [-]
Magic Lantern Devs are GOAT < 3
bambax 8 hours ago [-]
Fantastic news! Congrats to the new team!
iLoveOncall 4 hours ago [-]
I've been waiting for Magic Lantern for my 6D Mark II for years now, checking the homepage every 6 months or so for an update, so this is great news!
syrgian 3 hours ago [-]
Same boat. I have a 6D Mark II since 7 years ago now, and I misguidedly was counting on ML to be released within 3 years of my purchase. But luckily, it's still a fantastic camera.
names_r_hard 3 hours ago [-]
6D2 is a nice cam, and one I happen to own. This cam is under active development. Locally I have ~FHD raw video working.
lofaszvanitt 4 hours ago [-]
The nifty thing would come from opening up the high end cameras, so why not go there? Of course Canon's legal team gonna crack down on the project, as they've previously said.
names_r_hard 4 hours ago [-]
Canon's legal team have never said anything about Magic Lantern in any context that I'm aware of.
The high end cams need ML less, they have more features stock, plus devs need access to the cam to make a good port. So higher end cams tend to be less attractive to developers.
andrewstuart 7 hours ago [-]
[flagged]
slacktivism123 6 hours ago [-]
The linked page explains:
Magic Lantern is a free software add-on that runs from the SD/CF card and adds a host of new features to Canon EOS cameras that weren't included from the factory by Canon.
I also found this concise, human-written readme on the project page. Since it's not AI slop churned out by a startup, it's worth reading! :-)))
Magic Lantern
=============
Magic Lantern (ML) is a software enhancement that offers increased
functionality to the excellent Canon DSLR cameras.
It's an open framework, licensed under GPL, for developing extensions to the
official firmware.
Magic Lantern is not a *hack*, or a modified firmware, **it is an
independent program that runs alongside Canon's own software**.
Each time you start your camera, Magic Lantern is loaded from your memory
card. Our only modification was to enable the ability to run software
from the memory card.
ML is being developed by photo and video enthusiasts, adding
functionality such as: HDR images and video, timelapse, motion
detection, focus assist tools, manual audio controls much more.
For more details on Magic Lantern please see [http://www.magiclantern.fm/](http://www.magiclantern.fm/)
There is a sibling repo for our patched version of Qemu that adds support
for emulating camera ROMs. This allows testing without access to a physical
camera, and automating tests across a suite of cameras.
https://github.com/reticulatedpines/qemu-eos
https://github.com/reticulatedpines/qemu-eos/tree/qemu-eos-v4.2.1 (current ML team supported branch)
But this is actually really cool because, as it turns out, I've got an old Canon Eos DSLR that I haven't used for a long time and didn't know this thing existed before.
keyle 5 hours ago [-]
Around 2020, our old lead dev, a1ex, after years of hard work, left the project. The documentation was fragmentary. Nobody understood the build system. A very small number of volunteers kept things alive, but nothing worked well. Nobody had deep knowledge of Magic Lantern code.
Sounds like a bit of a dick move. Part of being a lead dev is making sure you can get hit by a bus and the project continues. That means documentation, simple enough and standard build system (It's C after all), etc. As a lead dev you should ensure the people on the project get familiarity with other part than their niche too, so that one can succeed you.
bibabaloo 5 hours ago [-]
Uh, sure, maybe in a professional setting where you’re getting paid. But this was unpaid volunteer work. If, as a community, we start enforcing professional grade standards on people who are just contributing their free time to give us neat toys and tools, I kinda worry it makes the whole thing the whole thing less fun or sustainable. And if that happens, we probably stop getting these free toys altogether.
keyle 5 hours ago [-]
I heart-fully disagree. Being professional crosses the bounds of paid work and unpaid work.
It doesn't take much work to not leave a gigantic pile of trash behind you.
If anything, it's an even more a self-responsible thing to do in the OSS world, as there isn't a chain of command such as in the corporate world, enforcing this.
It's selfish to engage in group relation with other people building something without the conscious decision of continuity.
A job worth doing is a job worth doing well. Maybe I'm just a gray beard with unrealistic expectations, or maybe I care about quality.
teddyh 2 hours ago [-]
Think of it as a non-profit club. If you volunteer to be the treasurer, are you then free to ignore everything and do whatever you like, just because you aren’t paid? Of course not. It’s the same with being a software project maintainer; you have willingly taken on some obligations.
bux93 2 hours ago [-]
It's not like this kind of thing doesn't happen in the professional world - in fact, quite the opposite. The incentives to cut corners in a company are if anything greater than in open source, with pressure from management to meet the next deadline.
> Magic Lantern is a free software add-on that runs from the SD/CF card and adds a host of new features to Canon EOS cameras that weren't included from the factory by Canon.
It also backports new features to old Canon cameras that aren't supported anymore, and is generally just a really impressive feat of both (1) reverse engineering and (2) keeping old hardware relevant and useful.
Today, cameras like Blackmagic and editing platforms like DaVinci handle RAW seamlessly, but it wasn't like this even a few years ago.
I think possibly someone thought it sounded a bit like firmware?
Heh, a little like saying "the main thing you need is to be able to play the violin, which is a small instrument with good tutorials".
Maaaaybe I'm hiding a tradeoff around complexity vs built-in features, but volunteers can work that out themselves later on.
You honestly don't need much knowledge of C to get started in some areas. The ML GUI is easy to modify if you stay within the lines. Other areas, e.g., porting a complex feature to a new camera, are much harder. But that's the life of a reverse engineer.
C genuinely is easy to pick up. It is harder to master. And you're right, for many domains, there are better options now, so it may not be worth while mastering it.
Because it's an old language, what it lacks in built-in safety features, is provided by decades of very good surrounding tooling. You do of course need to learn that tooling, and choose to use it!
In the context of Magic Lantern, C is the natural fit. We are working with very tight memory limitations, due to the OS. We support single core 200Mhz targets (ARMv5, no out-of-order or other fancy tricks). We don't include C stdlib, a small test binary can be < 1kB. Normal builds are around 400kB (this includes a full GUI, debug capabilities, all strings and assets, etc).
Canon code is probably mostly C, some C++. We have to call their code directly (casting reverse engineered addresses to function pointers, basically). We don't know what safety guarantees their code makes, or what the API is. Most of our work is interacting with OS or hardware. So we wouldn't gain much by using a safe language for our half.
I feel like this is a bit of an https://xkcd.com/2501/ situation.
C is considered easy to pick up for the average user posting HN comments because we have the benefit of years -- the average comp sci student, who has been exposed to Javascript and Python, who might not know what "pass by reference" even means... I'm not sure they're going to be considering C easy.
Honestly, C seems to be one of the easier languages to teach the basics of. It's certainly easier than Java or C++, which have many more concepts.
C has some concepts that confuse the hell out of beginners, and it will let you shoot yourself in the foot very thoroughly with them (much more than say, Java). But you don't tend to encounter them till later on.
I have never said getting good at C is easy. Just that it's easy to pick up.
Having a good, logical description of supported features, with a warning that if you do unsupported stuff things may break, is much more important than trying to define every possible action in a predictable way.
The latter approach often leads to explosion of spec volume and gives way more opportunities for writing bad code: predictable in execution, but instead with problems in design and logic which are harder to understand, maintain and fix. My 2c.
It's sad that the dev, who has done great work, has to spend time defending the C language from critters living under a bridge when it's a fixed element that isn't going to change.
I'm the current lead dev, so please ask questions.
Got a Canon DSLR or mirrorless and like a bit of software reverse engineering? Consider joining in; it's quite an approachable hardware target. No code obfuscation, just classic reversing. You can pick up a well supported cam for a little less than $100. Cams range from ARMv5te up to AArch64.
Thanks for your work keeping it going, and for those that have worked on it before.
Could this be a conflict with long exposures? Conceivably AF, too. The intervalometer will attempt to trigger capture every 5s wall time. If the combined time to AF seek, expose, and finish saving to card (etc) is >5s, you will skip a shot.
When the time comes, compare the price of a used 5d3 vs a shutter replacement on the 5d2, maybe you'll get a "free" upgrade :) Thanks for the kind words!
I've done lots of 1/2 second exposures with 3s interval, and it shoots some at much shorter interval than 3 and some 3+??? At one point, the docs said 5s was a barrier. Maybe it was the 5dmkii specifically. All of my cards are rated higher than the 5D can write (but makes DIT much faster) so I doubt it is write speed interfering. What makes me think it is not the camera is that using a cheap external timer works without skipping a beat.
Is this situation still the same? (Apologies for the hazy details -- this was 5 years ago!)
Anyway, I can happily talk you through how to do it. Our discord is probably easiest, or you can ask on the forum. Discord is linked from the forum: https://www.magiclantern.fm/forum/
Whatever code you had back then won't build without some updates. 4000D is a good target for ML, lots of features that could be added.
I'll definitely keep this in mind and hit you up whenever I have a buncha hours to spare. :)
The 4000D is an interesting cam, we've had a few people start ports then give up. It has a mix of old and new parts in the software. Canon used an old CPU / ASIC: https://en.wikipedia.org/wiki/Template:Canon_EOS_digital_cam...
So it has hardware from 2008, but they did update the OS to a recent build. This is not what the ML code expects to find, so it's been a confusing test of our assumptions. Normally the OS stays in sync with the hardware changes, which means when we're reversing, it's hard to tell which changes are which.
That said, 4000D is probably a relatively easy port.
(I literally only want a raw histogram)
(I also have a 1Dx2 but that's probably a harder port)
It’s been a huge blessing!
Thank you and the magic lantern team!
Very impressive! Thankless work. A reminder to myself to chase down some warnings in projects I am a part of...
I have an xcconfig file[0], that I add to all my projects, that turns on treat warnings as errors, and enables all warnings. In C, I used to compile -wall.
I also use SwiftLint[1].
But these days, I almost never trigger any warnings, because I’ve developed the habit of good coding.
Since Magic Lantern is firmware, I’m surprised that this was not already the case. Firmware needs to be as close to perfect as possible (I used to write firmware. It’s one of the reasons I’m so anal about Quality).
[0] https://github.com/RiftValleySoftware/RVS_Checkbox/blob/main... (I need to switch the header to MIT license, to match the rest of the project. It’s been a long time, since I used GPL, but I’ve been using this file, forever).
[1] https://littlegreenviper.com/swiftlint/
We build with: -Wall -Wextra -Werror-implicit-function-declaration -Wdouble-promotion -Winline -Wundef -Wno-unused-parameter -Wno-unused-function -Wno-format
Warnings are treated as errors for release builds.
Great work, and good luck!
You only add one at a time, so you only need to fix one at a time, and you understand what you're trying to do.
It is, however, a real bitch to fix all compiler warnings in decade old code that targets a set of undocumented hardware platforms with which you are unfamiliar. And you just updated the toolchain from gcc 5 to 12.
Unpopular topic. I talk about it anyway, as it's one of my casus belli. I can afford the dings.
BTW: I used to work for Canon's main [photography] competitor, and Magic Lantern was an example of the kind of thing I wanted them to enable, but they were not particularly open to the idea -control freaks.
Also, it's a bit "nit-picky," I know, but I feel that any software that runs on-device is "firmware," and should be held to the same standards as the OS. I know that Magic Lantern has always been good. We used to hear customers telling us how good it was, and asking us to do similar.
I think RED had something like that, as well. I wonder how that's going?
The photography world is mired in proprietary software/ formats, and locked down hardware; and while it has always been true that a digital camera is “just” a computer, now more than ever it is painful just how limited and archaic on-board camera software is when compared to what we’ve grown accustomed to in the mobile phone era.
If I compare photography to another creative discipline I am somewhat familiar with, music production - the latter has way more open software/hardware initiatives, and freedom of not having to tether yourself to large, slow, user-abusing companies when choosing gear to work with.
Long live Magic Lantern!
cries in .x3f & Sigma Photo Pro
> git clone https://github.com/reticulatedpines/magiclantern_simplified
*No judgement, maintaining a niche and complex reverse-engineering project must be a thankless task
https://chdk.fandom.com/wiki/CHDK
One of those projects I wanted to take on but always back logged. Wild that they've been on a 5 year hiatus -- https://www.newsshooter.com/2025/06/21/the-genie-is-out-of-t... -- that's the not-so-happy side of cool free wares.
It is actually easier to get started now, as I spent several months updating the dev infrastructure so it all works on modern platforms with modern tooling.
Plus Ghidra exists now, which was a massive help for us.
We didn't really go on hiatus - the prior lead dev left the project, and the target hardware changed significantly. So everything slowed down. Now we are back to a more normal speed. Of course, we still need more devs; currently we have 3.
However, a lot of the features exposed are more video oriented. The Canon bodies were primarily photo cameras that could shoot video in a cumbersome way. ML brings features a video shooter would need without diving into the menus like audio metering. The older bodies also have hardware limitations on write speed, so people use the HDMI out to external recorders to record a larger framesize/bitrate/codec than natively possible. Also, that feed normally has the camera UI overlay which prevents clean recordings. ML allows turning that off.
There are just too many features that ML unlocks. You'd really just need to find the camera body you are interested in using on their site, and see what it does for that body. Different bodies have different features. So some effort is required on your part to know exactly what it can do for you.
Because a lot of features that cost a lot of money are only software limitations. With many of the cheaper cameras the max shutter speed and video capabilities are limited by software to make the distinction with the more expensive cameras bigger. So they do sell hardware - but opening up the software will make their higher-end offerings less compelling.
Camera manufacturers live and die on their reputation for making tools that deliver for the professional users of those tools. On a modern camera, the firmware and software needs to 100% Just Work and completely get out of the photographer's way, and a photographer needs to be able to grab a (camera) body out of the locker and know exactly what it's going to do for given settings.
The more cameras out there running customized firmware, the more likely someone misses a shot because "shutter priority is different on this specific 5d4" or similar.
I'm sure Canon is quietly pleased that Magic Lantern has kept up the resale value of their older bodies. I'm happy that Magic Lantern exists-- I no longer need an external intervalometer! It does make sense, though, that camera manufacturers don't deliberately ship cameras as openly-programmable computational photography tools.
Also another thing, Magic Lantern adds optional features which are arbitrarily(?) not present on some models. Perhaps Canon doesn't think you're "pro enough" (e.g. spent enough money) so they don't switch on focus peeking or whatever on your model.
IIRC none of the EOS DSLRs had focus peaking from the factory, you need Magic Lantern -- Canon didn't program it at all.
In fact make this all devices with firmware, printers, streamers etc.
But forcing is never a right thing.
Extending this to enable software access by 3rd parties doesn't feel controversial to me. The core intent of copyright and patent seems to be "when the time limit expires, everyone should be able to use the IP". But in practice you often can't, where hardware with software is concerned.
https://en.wikipedia.org/wiki/Magic_Lantern_(spyware)
We're a normal program, running on their OS, DryOS, a variant of uITRON.
This has the benefit that we never flash the OS, removing a source of risk.
It's not firmware, which is a nice bonus, no risk of a bad rom flash damaging your camera (only our software!).
We load as normal software from the SD card. The cam is running a variant of uITRON: https://en.wikipedia.org/wiki/ITRON_project
I was pleasantly surprised to find out this was something very different.
https://en.wikipedia.org/wiki/Magic_Leap
> As of December 2024, the Magic Leap One is no longer supported or working, becoming end of life and abruptly losing functionality when cloud access was ended. This happened whilst encouraging users to buy a newer model.
Ah, that’s about how I thought that would end up.
200D is much newer, but less well supported by ML. I own this cam and am actively working on improving it. 200D has DPAF, which means considerably improved auto-focus, especially for video. Also it can run Doom.
Are there any ML features in particular you're interested in?
The high end cams need ML less, they have more features stock, plus devs need access to the cam to make a good port. So higher end cams tend to be less attractive to developers.
https://github.com/reticulatedpines/magiclantern_simplified/...
But this is actually really cool because, as it turns out, I've got an old Canon Eos DSLR that I haven't used for a long time and didn't know this thing existed before.
It doesn't take much work to not leave a gigantic pile of trash behind you.
If anything, it's an even more a self-responsible thing to do in the OSS world, as there isn't a chain of command such as in the corporate world, enforcing this.
It's selfish to engage in group relation with other people building something without the conscious decision of continuity.
A job worth doing is a job worth doing well. Maybe I'm just a gray beard with unrealistic expectations, or maybe I care about quality.
https://en.wikipedia.org/wiki/Bus_factor