Messages

MLinstall v1.1.0 released: https://github.com/petabyt/mlinstall/releases/tag/1.1.0

Main improvements:
- MacOS port
- Added shutter counter
- Shows the camera's firmware build version
- Switched to native UI (Winforms/GTK3/Cocoa)
- Wording improvements
- misc bug fixes over the past year

Looked around a little bit, also found this: https://www.youtube.com/@thegospelwithezekiel/

For anybody wanting to take up development for this port:
Critix's current repository for v1.1.0 is here: https://github.com/ccritix/magic-lantern
My v1.2.0 fork of his code is here: https://github.com/petabyt/magiclantern

It's been a long time since I worked on the v1.2.0 port, and I believe I lost some of my bug fixes I had worked on after wiping my old laptop. Since then I've been busy with many other things, and no longer can work on ML ports. I'll continue to maintain mlinstall and the PTP library it uses. I've been using my port for light photography and haven't had any crashes, but it still is mostly untested. The current build fails a self test because of cache issues. I think I remember fixing it, but I still have the issue on the last backup I had made.

Had put it up on Google play a while ago: https://play.google.com/store/apps/details?id=dev.petabyt.camcontrol
I had intended to add a lot more features (WiFi support, Nikon/Sony/Fuji support, more ML features),
but development ended up taking way too long (over 6 months). 70% of the app was written in HTML/CSS/JS, so
I ended up having to write a ton of boilerplate code to manage things like hardware communication, background tasks, and UI.

Sony cameras run a stripped down Android, and are very easy to hack: https://github.com/ma1co/OpenMemories-Tweak

I don't need it very often, but it comes in very handy when I need it  Great tool 

Thanks. I think for now the entire tool is stable and won't get any more major changes. Next updates will probably be a MacOS port, and maybe localization.
MacOS should be pretty easy, camlib is fairly stable and has been tested on Macs, so it should just be a matter of some makefile tweaks.

[This means you won't install Zadig or libusb if you're on Windows.]

mlinstall 1.0.0 is finally released.
Github release: https://github.com/petabyt/mlinstall/releases/tag/1.0.0

I knew from the start how painful all the libusb nonsense was, but there was no other option at the time. This release deletes all the PTP/USB backend and replaces it with a library I wrote from scratch.
Native Windows support is now available without any modification to the system drivers. This means you won't install Zadig or libusb if you're on Windows.

This is potentially dangerous advice.

Enabling the feature will cause ML to write to registers.  If these addresses have changed it could permanently damage the camera.

Do not enable this feature unless you have verified the register values still hold for the new cam.

E.g. here in lv-img-engio.c, EngDrvOutLV() triggers writes:

Code Select Expand


  25 #define SHAD_GAIN      0xc0f08030       // controls clipping point (digital ISO)
  26 #define SHAD_PRESETUP  0xc0f08034       // controls black point? as in "dcraw -k"
  27 #define ISO_PUSH_REGISTER 0xc0f0e0f8    // like display gain, 0x100 = 1 stop, 0x700 = max of 7 stops
...
827 #ifdef FEATURE_EXPO_ISO_DIGIC
828     if (mv)
829     {
830         if (digic_iso_gain_movie_for_gradual_expo == 0) digic_iso_gain_movie_for_gradual_expo = 1024;
831         int total_movie_gain = DIGIC_ISO_GAIN_MOVIE * digic_iso_gain_movie_for_gradual_expo / 1024;
832         if (total_movie_gain != 1024)
833         {
834             autodetect_default_white_level();
835             int boost_stops = 0;
836             int new_gain = get_new_white_level(total_movie_gain, &boost_stops);
837             EngDrvOutLV(SHAD_GAIN, new_gain);
838             shad_gain_last_written = new_gain;
839             #ifndef CONFIG_DIGIC_V
840             EngDrvOutLV(ISO_PUSH_REGISTER, boost_stops << 8);
841             #endif
842         }


Didn't know that. Thanks for letting me know.

Any chance to enable it and create a test build? I'll take the risk and will test it.

You can remove that line and compile it yourself. In the future I might look into it.

[ISO]

Just installed ML 1300D 1.2.0. It works, but there is no ISO setting/submenu under the Expo menu:

ISO feature was disabled, probably several years ago during development: https://github.com/petabyt/magiclantern_simplified/blob/a661de1242e4b892697c6abb665f88380d7c75da/platform/1300D.120/features.h#L38
I don't know if it works or why it's disabled.

does it make sense to you?

Yes, that makes sense.

Do GH orgs work for the repos that aren't already in github?  I'm assuming it doesn't, is that right?

No reason why it wouldn't. Are you referring to mercurial repositories?

It looks like you need an org admin as a minimum, and that admin can delete repos.  So how would that work if we have multiple repos, previously owned and controlled by one person?  There's an additional layer of responsibility and we'd need to have a plan.

GitHub permissions are customizable. I suggest creating a test organization to try it out if you haven't already. Other than that I'm not sure what youre asking.

I've used it for several projects, it's very useful for keeping development organized. Admins can create and modify existing repos, and you can allow certain people to modify certain repos. Not sure what you know and dont know about this stuff. Honestly don't see how it would mean more responsibility over a single repo.

I think having an org is more about making a project look like less of a personal fork and more of an official fork. Gives people a nice overview of the project info, people who participate, and the repos in development. But that's just how I see it.

I think having an 'official' github organization containing the active forks would be useful. Could add your repo and maybe the 1300d repository too. I think that would make the most sense to new devs approaching the project.

Also need to post more updates, especially to the site. I remember thinking the project was dead back when I first saw it.

1.2.0 version has no new features.
As for RAW, I wasn't able to get anything that good, only a few seconds of decent footage at a time on my 80mbs SansDisk ultra.

Also, as an update to this thread, I've recently modified mlinstall to work with my camlib/libwpd libraries, which work on Windows natively. No more libusb nonsense soon. Works great on my end, I'll release it once I've done more testing.

First ML on ML, then my Fuji DOOM port, and now this. Too many amazing things happening today

Finished porting mlinstall to camlib/WPD. It's a very early test, still needs some work. It only reads the first device found, so it might try and open a phone or USB drive.
https://github.com/petabyt/mlinstall/releases/tag/0.9.4
This means that eventually there should be no more libusb/zadig/filter nonsense on Windows. Everything should work out of the box. On Linux, it should function the same.

For the 1.0.0 release, hoping to implement shutter count reading, and the ability to update to any firmware version over USB.

Agreed. A configure script would be very useful. I had made a half-finished PR to do that a while ago: https://github.com/reticulatedpines/magiclantern_simplified/pull/75

I gave it some decompiled functions straight from Ghidra, and it was able to perfectly describe what each function did most of the time. Good for identifying functions like memcpy/strcpy/strncpy, math operation functions, etc. Helped a good bit with my Fujifilm reverse engineering since there aren't any debug strings in the RTOS. Success rate is maybe 80% (also considering that Ghidra can mess up sometimes)

Thanks. Hopefully will have WiFi support for the next release. I know how to do it, but it would be tedious. iOS support is also theoretically possible, just need to get my hands on a mac and iphone.

2023 Update:
I'm currently slowly working on a DLL that will help me interface with PTP devices on Windows natively.
I spent a lot of time writing code that will interface with the ancient WIA driver, but I had to scrap it because it was too slow.
This time, I'm interfacing with WPD (Windows Portable Devices). Like Wia, the driver is completely different compared to something like libusb.
WPD requires sending the command opcode, parameters, and data separately, letting Windows handle transaction IDs, and determining whether the response will have a data phase or not before sending the command.

And finally, after 4 months... I'm still not finished yet.

I've finished most of the features I planned for v0.1.0. ML + EOS Liveview, remote capture/bulb, get/set WB, ISO, shutter speed, aperture, focus lens, basic file manager, etc. I've also got about a dozen other small things I need to implement and test.

I decided to build a new app on top of my existing camlib/camcontrol code. It's a very basic intervalometer app, with a section for JS scripting, standard and bulb capture.
This is mainly a basic tech demo to test my current implementation of PTP, and my understanding of Android USB communication. I've tested it as much as I can, but I haven't fuzz/stress tested it yet, so there's a slight chance it may have some bugs. After stress testing, I will upload it to the play store.

APK Download: https://github.com/petabyt/camlib/releases/tag/caminterv-1

Magic Lantern 1300D 1.2.0: I've been testing this for a while to make sure there aren't any random crashes, and it's worked okay so far.
I updated every single address I could find (and checked all the ifdefs). The code is copied directly from critix's 0.1.0 repository.
Passed self test. I went ahead and deleted a few modules I wasn't confident with, but left mlvlite in. I've recorded a good bit of raw (maybe 10-20 minutes) and I haven't had any issues so far, but I should still warn you, it might break your camera. No guarantees.

EDIT: The 1.2.0 port has been removed. Newer and more stable version will be released in the future.

I've made a few attempts to port the 1300D port to the names_are_hard magiclantern_simplified fork, but the camera crashes after trying to register some property handlers. I probably won't continue trying (no point in doing so), but if anybody else wants to give it a shot: https://github.com/petabyt/magiclantern_simplified/tree/1300d

There was somebody on Youtube who beat Minecraft with a steering wheel, I'd say the next logical step should be beating Minecraft with a DSLR.

Yep, you would have to poll. It's fast enough for grabbing things like ISO and shutter speed from the camera. No idea on how slow it would feel as a controller. I'd say it should be possible to poll maybe 200 per second from the camera, maybe more.