Messages

I would suggest you use something like github pages for the webpage.  If I'm not mistaken, this essentially treats the webpage as a git repository, which means that multiple people editing things etc... works like you want it to. If someone notices a mistake, they make a pull-request with the correction, people can comment on it, and to merge it just requires the click of a button from an administrator.  I know that a number of developers prefer mercurial, but I think something like a mirror to github would also have some advantages such as the ease of setting up more of an "ecosystem" around the project.

That said, I think the current webpage is fine for 99% of users, i.e. those who just want to run magic lantern to get some of the standard features. However, the information for those interested in development or cutting-edge features is a different story. I'm not sure what the best way of doing this is. Most importantly, I think there should be a landing page for those who want to compile the project from source, together with detailed instructions on how to write a simple "Hello-World" program. Just figuring out how to run code on the camera isn't easy. Maybe this exists somewhere, but I'm having trouble finding it and I've compiled magic lantern from source before so am not a complete newbie.


Edit: https://www.magiclantern.fm/forum/index.php?topic=19232.0 looks like the kind of "Hello World" thing I mentioned, is it up to date?
I think a lot of magic lantern grew somewhat "organically", which means that there is little formal documentation. But documenting things in a wiki on a per-camera basis as opposed to random forum posts here and there is what I would vote for.   That said something like the "Issues" on Heptapod/github/gitlab are are also nice because it is easier to reference (a) other issues and (b) code that fixes things. Of course, this is a lot of work but just having a single place where people can contribute via pull-requests would be a nice Schelling point for people to add information that I feel currently doesn't exist.

I'm currently unable to get the source code from Heptapod. I have no experience with mercurial whatsovever, but I tried "hg clone https://foss.heptapod.net/magic-lantern/magic-lantern". This gave me some source code that is different to what I see on Heptapod. I also tried the mercurial to git approach suggested here, that gave me what seems like the same source code as before, here the last commit is one from 2011. It would be helpful to have a file that gives you instructions on how to install the source code somewhere.


Edit: it seems like doing "hg checkout unified" does the trick.

@Luther: That's an interesting idea I hadn't thought of. The downside is that I have to wait between taking pictures also, and doing it this way means every frame need several shutters openings when previously I only take 2 pictures when necessarily.

Note also that I'm not digitalising "normal" analog film but analog film slides (wikipedia says "reversal film") meaning I don't have any negatives. I only really do minimal processing with imagemagick in order to remove black edges, I'm not using something like Rawtherappe because (a) white balance is done in camera as using large raw files would add some more time when transferring the image via usb and (b) I'm using this for fairly large numbers of old film slides (probably more than 10K) where I want to as little manual processing as possible.

I've been working on a machine for digitalising slide film for a while, and it has reached a point where it is working very well, so I thought I would share

Here is a video of the machine in action https://drive.google.com/file/d/1HwVwULBRlTh9yDRKbw87FjLXRVLTpz3j/view


I'm using an EOS M, together with a modification of ML where I've mapped certain PTP commands to take a picture and adjust exposure times. Because slide film has such a high dynamic range, a single exposure time would not have worked well. I therefore look at the histogram and adjust exposure for each image. If the image is still too dark, I increase the exposure time, take another picture, and then combine both pictures with the enfuse utility. The lens is a 100mm Canon FD macro lens, together with some teleconverters.

I've digitalised several thousand pictures at this point, here is one https://drive.google.com/file/d/1cbxvvk_QhnVmxhfcxLwNyc8-gOdHBt_e/view?usp=sharing

What is slowing things down quite a bit is that setting the exposure time isn't instantaneous. A large chunk of time is spent waiting just to be sure that the exposure being set has been set. Nevertheless, the whole thing is still *much* faster than using a slide film scanner that scans the slide "line by line". The sharpness of the images is limited by the grain of the slides.

This project would not have been possible without ML, thanks a lot to everyone who has worked on ML over the years!

Since it seems like the focus doesn't really change between slides, I'd now like to implement something like the ettr module does. However, I don't want to be working in RAW mode (and I have no control over the aperture as I'm using manual focus lenses) so it seems easiest to just reimplement what I need.

I'm able to compute histograms and change exposure fine, via

prop_request_change( PROP_SHUTTER, &newshutter, 4);

However, it seems like it takes a while for these changes to propagate, while raw_shutter gets updated almost instantaneously, the histograms I see take around 0.1-0.3s to have the "correct" shutter value. This is despite calling "hist_build();". Is there some way to check whether or not the histogram is for the old shutter values? Alternatively, is there some other way to change the shutter/compute histograms? It seems like on the EOS M can_set_frame_shutter_timer() returns 0, the relevant line is :

    if (!RECORDING_H264) return 0;  /* EOS-M is stubborn, http://www.magiclantern.fm/forum/index.php?topic=5200.msg104816#msg104816 */

though the link doesn't seem to explain what is going on.

btw, is there some kind of "higher level" code documentation somewhere that provides a rough overview of how magic lantern works? If so, I should probably read something like that first.  I've been looking in the wiki, but can't seem to find anything.

Ok, makes sense. My lens doesn't have AF (or an AF chip), so maybe that is part of what is causing the issue. How are the "PROP_HANDLER_FOO_BAR" type functions actually "called"? does the PROP_HANDLER macro somehow register a function to the kernel to be automatically called at certain times, or does a user have to somehow call the property handler? It seems like this particular property handler is never called, as debugging code I put into it never gets run.

>I can probably figure it out if I had a couple of days to look into it (which I don't have atm).

That's perfectly understandable, I'll keep prodding around a bit maybe I'll find something.

> There is a "contrast" estimation computed by Canon firmware very quickly, for every single LiveView frame;

@a1ex: Is this the code in focus.c, or more specifically "PROP_HANDLER(PROP_LV_FOCUS_DATA)"? It seems like "update_focus_mag()" is never called, and focus_value_raw() is always zero.  I can't seem to be able to tell why exactly; what do I need to do to get focus_value_raw() to be called?

@names_are_hard: thanks, I will have to look into that!

>The MODULE_CBR code only works for modules; if you are modifying core code, it won't work. Do you have a repository with your changes?

I currently don't; all my code is currently very hacky (see https://gist.github.com/natschil/800920c9adbf30d375494c73a7676377) , so I haven't made a repository yet (also I have zero experience with mercurial)

>In any case, implementing a simple image processing algorithm directly in the camera, operating at reduced resolution or whatever, might be faster than transferring every single frame via USB.

I agree, my reasoning for transferring it via usb has mainly just been that the development pipeline on the pc is shorter, as I can use any toolkits etc, and don't need to recompile + transfer data to card every time I make a change (I wasn't able to get qemu to run successfully to emulate the eos m).

>So... what about interfacing with a RPi or some other development board with USB host support? Maybe you could drive the rail directly from there. What's your current hardware setup?

Yeah that makes sense. Currently my hardware setup consists of an arduino to move the rail + control image switching, but really all the arduino does is essentially map usb from my pc to digital out pins..

Thanks very much for the detailed response! Thanks also for the reference to lossless compression and full sensor readout presets!
Currently I'm only trying to get somewhat reliable transfer of live-view images, so that I have a proof of concept system working, which it now does. It currently is quite slow, so I will look at making it faster/better if need be (the end goal is to move the camera forwards and backwards on a rail based on the contrast of the live-view image (computed on an external computer), in order to have a rudimentary autofocus).

I tried registering a vsync hook using the code below, but that did not work:

MODULE_CBRS_START()
    MODULE_CBR(CBR_VSYNC, get_single_frame, 0)
MODULE_CBRS_END()

Then I put my callback into vsync_func() of state_object.c, and that worked. However, I feel like this isn't the cleanest way to do things. Is there something like aforemented macro that didn't work, but which works outside of modules?

I'm now able to capture live view and take pictures.

However, it turns out that after the first (live view captured) picture, the images generated are corrupted (visually very similar to the corruption seen in the noisiest images of https://www.magiclantern.fm/forum/index.php?topic=8190.0). Weirdly enough, if I restart the PTP session (i.e. run the python program I have that calls my ptp handler), the first image is again fine, and the others are corrupted.

I currently capture live view via:

    force_liveview();
    raw_lv_request();
    msleep(50);
    raw_lv_release();
    msleep(50);
    raw_update_params();
    return &raw_info;

And then call "create_dng_header(&raw_info);  create_thumbnail(&raw_info);", reverse the bytes in the frame,  after which I memcpy everything into a buffer that gets sent back via ptp.

Am I doing something obviously wrong? I've seen a number of posts in the forum regarding corrupted images, but it's not clear to me what the underlying cause is.

Does anyone know what is actually causing this kind of corruption? I'm trying to output the live view via ptp, and am seeing it on all frames except the first one in a ptp session This leads me to suspect that I should be calling something between frames.

Currently I get the live view via:

    force_liveview();
    raw_lv_request();
    raw_update_params();
    msleep(50);
    raw_lv_release();
    msleep(50);
    return &raw_info;

and am using the EOS M.

FYI: the magic lantern ptp code (in ptp.c and ptp.h) is fine, in fact I am using it to control my camera via usb (via some very hacky ptp handlers I wrote ) right now.

>-The simplest way to take a picture is: call("Release");

Yes, that worked! I've now also implied a command to return the raw live view, and apart from some minor issues that seems to work also. I'm note sure what the magic lantern philosophy to this kind of code is - it does seem to be in some sense reimplementing features that were potentially disabled for the EOS M. But if this is not a problem I'm happy to clean up and share my code.

I was quite surprised to find how well the ptp code worked. According to some old forum posts the ptp code should not work with new version of magic lantern (there was even a 200$ bounty posted in one thread) , but I had no problems using it whatsoever.

First of all: thank you for making magic lantern, it is incredibly useful and I couldn't imagine buying a camera that doesn't support it.

I'm trying to build a setup for digitalizing old slide film. I have an  EOS-M (original) running Magic Lantern, and  a slide projector that I've modified so that I can now easily step through slides. I've bought an old manual focus macro lens, for which I intend to build a mechanism for autofocussing via a computer and an electric motor. My only problem: it seems like the EOS-M does not work well with certain ptp commands. So I've decided to write my own ptp handler that does the things I need. I essentially need only (a) a way to trigger taking pictures from my laptop. (b) a way to get a small piece of the live view (for focussing) to the laptop.

I've successfully compiled the ptp code, and written a "Hello-World" handler with which I can communicate with the camera. This works. However, it seems like the camera goes into some kind of ptp-lockup-mode whenever it is plugged into usb, which means that lens_take_picture() doesn't work - the picture gets taken only once the usb cable is unplugged. This is kind of annoying. I am able to take pictures in bulb mode, but doing take_pulb_pic(1) results in a very long exposure, and takes so long that the ptp call times out.

Before I start trying to reverse-engineer the EOS-M firmware in the manner of https://research.checkpoint.com/say-cheese-ransomware-ing-a-dslr-camera/, I was wondering if anyone here could offer some suggestions/insight. I'm aware that I could work around (a) by audio remote shot/IR remote and (b) by doing some kind of focus-checking on-camera and filming the live-view with a  webcam, but both of those approaches are *very* hacky and I feel like there must be a more elegant way to do this via ptp.