Live data from Hacker News

Magic Lantern Is Back

magiclantern.fm

61–70 of 170 posts

Re: Magic Lantern Is Back

#61

Earlier quoted context omitted.

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 muc…

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 r…

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 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.

Re: Magic Lantern Is Back

#62
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!

Re: Magic Lantern Is Back

#64
post #53

Earlier quoted context omitted.

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 t…

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. :)

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 ;)

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.

Re: Magic Lantern Is Back

#65

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 relevan…

Funny, when i saw it uses a .fm TLD i thought it's some online radio.

Re: Magic Lantern Is Back

#66
post #60

If I’m to get a secondhand camera to run MM which would your recommend? 200D or 600D?

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?

Re: Magic Lantern Is Back

#67

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.

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.

Re: Magic Lantern Is Back

#68
post #65

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 relevan…

Funny, when i saw it uses a .fm TLD i thought it's some online radio.

They were trendy at the time :D

I think possibly someone thought it sounded a bit like firmware?

Re: Magic Lantern Is Back

#69

Earlier quoted context omitted.

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 r…

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 op…

> C genuinely is easy to pick up.

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.

Re: Magic Lantern Is Back

#70

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.

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.

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.

Post reply on HN