I was pleasantly surprised to find out this was something very different.

Firmwares should be open-source by law. Especially when products are discontinued.

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.

   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.

https://www.canonrumors.com/inside-the-canon-eos-1d-c

Quote:

I was told by someone at Canon that they would “bring the might of its legal team” to anyone that attempts to modify at the software level, the features of an EOS-1 camera body

/Quote

"Someone"'s name was never revealed.

ML was never mentioned directly.*

ML team was never contacted by any Canon official or anyone speaking in their regard.

* Of course it is logical to assume there is a connection to ML.

If I put some code out on the internet and some other people find it and start using it, they message me we talk and I start adding things they suggest and working with others to improve this code. Then one day I wake up and don't want to do it anymore. At what point did I become obligated? When I published the code? When I first started talking to others about it(building a community)? When I coded their suggestions? When I worked with other coders?

Who get to decide where the line is?

AF with 600D in liveview: Phase detection only. Focus hunting galore. 200D comes with usable DPAF.

I prefer 250D for streaming. Dual display support, no 30 minute limit for HDMI out (but cam display will go dark until some button action).

Visiting the Rift Valley in Southwest Uganda was one of the most awesome experiences of my childhood. My other company, Little Green Viper, riffs on that, too.

I was born in Africa, and spent the first eleven years of my life, there.

Had to leave Uganda in a hurry, though (1973).

I'll definitely keep this in mind and hit you up whenever I have a buncha hours to spare. :)

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.

IIRC none of the EOS DSLRs had focus peaking from the factory, you need Magic Lantern -- Canon didn't program it at all.

Independent of that: how dangerous is ML dev to the cameras themselves (in terms of brick potential)? Permanently bricking a camera in the price range of the 1DX is not exactly my idea of a good time. :-)

Hmm, that's a neat idea. The better language for it is 'auto guider'. Auto guiding is basically supplying correction information to the mount when it drifts off.

Most mounts support guiding input and virtually all astrophotographers set up a separate tiny camera, a small scope, and a laptop to auto guide the mount. It would be neat for the main camera to do it. The caveat is that this live view sampling would add extra noise to the main images (more heat, etc). But in my opinion, the huge boost in convenience would make that worth it, given that modern post processing is pretty good for mitigating noise.

The signals that have to be sent to the mount are pretty simple too, so I'll look at this at some point in future. The bottleneck for me is that I have ever got 'real' auto guiding to work reliably with my mount so if I run into issues it would be tricky as there's no baseline working version.

> Maybe an auto image upload service?

This sounds pretty useful, even uploading seamlessly to a phone or laptop would be a huge time saver for most people! I'll set up ML on my 6D and try out some of the demo stuff that use the network stack.

Is there a sorted list of things that people want and no one has got around to implementing yet?

Great work, and good luck!

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.

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.

Only if all other things are equal, which they never are.

I was assuming it would be possible to quite accurately model the drift over time, and adjust the model based on the last image. The model continuously guides the mount, and the lag in updates hopefully wouldn't matter - so you can use saved images, not LV. In fact, we can trigger actions to occur on the in memory image just before writing out.

I have done a stint in QA, as well as highly aggressive security testing against a big C codebase, so I too care a lot about quality. And you can do it in C, you just have to put in the effort.

I'd like to get Valgrind or ASAN working with our code, but that's quite a big task on an RTOS. It would be more practical in Qemu, but still a lot of effort. The OS has multiple allocators, and we don't include stdlib.

Re firmware / software, doesn't all software run on a device? So I suppose it depends what you mean by a device. Is a Windows exe on a desktop PC firmware? Is an app from your phones store firmware? We support cams that are much more powerful than low end Android devices. Here the cam OS, which is on flash ROM, brings the hardware up, then loads our code from removable storage, which can even be a spinning rust drive. It feels like they're firmware, and we're software, to me. It's not a clearly defined term.

The main reason I make the distinction is because we get a lot of users who think ML is like a phone rom flash, because that's what firmware is to most people. Thus they assume it's a risky process, and that the Canon menus etc will be gone. But we don't work that way.

We had to add software dust removal, because the shutter kicked dirt onto the sensor.

I’m assuming that, at some point, the sensor technology will progress to where mechanical shutters are no longer necessary.