Lua Scripting (lua.mo)

[BBA]

To more experienced people.

I want to take a timelapse of the milky way in Switzerland (Alps, > 3000 meters) in a not so light pollution free area (according to light pollution map of darksitefinder), new moon. I would like to be able to best focus on stars. In the field, I'll focus manually and take test shots to be sure (till now, I've never done that).
I wonder: with such star pictures in low light with some (I don't know how much) light/other noise, am I realistic of thinking of a Lua script that could help compare the blurriness of a few pictures (lets say x10 screen shots) taken one step (lens stepper motor) away from each other and could help me decide which one is the best focused one (Living dream ?)
Any answer is much appreciated!

[dmilligan]

There is currently no Lua API for image analysis. It's one area that's probably impractical for Lua. Image processing is typically very demanding in terms of both memory and processor due to the huge sizes of images, and Lua is already a heavy memory hog.

The best way I've found to do focusing for AP (and the method I always use) is to use LiveView 10x zoom with FPS override. FPS override of about 2-4 fps ("low-light" mode) is usually enough to clearly see bright stars, and focus "live" manually. This is significantly faster and easier than the test shot trial and error method. Its also a method that will work with manual optics that lack autofocus, such as my telescope.

[Audionut]

Some display gain helps too if the stars are fainter.

[BBA]

I thank you very much for your messages.

I am very grateful to this community because you, high level people, with all the work you have, having to work in such uncertain environment (it's Canon software), help the members, even the low level ones.

Respect (in french) !.

It makes me want to help in one way or another, but my technical background tells me I first have to learn, learn and learn.

[dhepguler]

It is nice to have aLUA scripting module in ML.. I am not familiar with LUA but can program in C... I want to know if I can write a script to keep the mirror locked up as long as intervalometer takes a definite number of shots... It would be great for astrophotography with a telescope... as you know, MLU activates but never keeps locked up with intervalomater... I want it to be locked up to dampen vibrations...  Many thanks in advance for replies...

Dincer
http://borsaci06.com

[dmilligan]

You don't even need a script. Powersave in LiveView -> Always

[dfort]

How about something to keep the LCD active indefinitely? A user posted on the EOS-M topic that he wants to set up a wildlife camera trap but the camera won't fire with Audio RemoteShot when the LCD turns off. Maximum setting on the Canon menu is 30 minutes for the LCD to remain active.

http://www.magiclantern.fm/forum/index.php?topic=9741.msg173367#msg173367

Is there something that can be scripted to keep the LCD from going to sleep? Any hints where to start?

[a1ex]

Powersave in LiveView -> Always

Not sure what this has to do with MLU, and there's no "Always" setting at the time of writing.

I guess @dhepguler is looking for full-res silent pictures. Some cameras also keep the mirror locked if you take pictures in LiveView (I guess you were referring to that), but the shutter is still actuated.

How about something to keep the LCD active indefinitely?

powersave_prohibit() or powersave_prolong(), but these aren't exposed to Lua or menus (yet). They are currently used for raw recording, for full-res silent pics, and for various test routines (e.g. card benchmarks) that may take longer than default auto power off setting.

Faking half-shutter from a script every now and then will also reset the powersave timer.

[DeafEyeJedi]

Faking half-shutter from a script every now and then will also reset the powersave timer.

Excellent suggestion!

[dfort]

I don't see anything in the ML Lua API that could be used to trigger a half-shutter. The only thing related to half-shutter that I could find is a constant--DEPENDS_ON (Dependency for a menu item) Fields: CFN_AF_HALFSHUTTER: which I have no idea what it means or if this is even relevant to faking a half-shutter.

Any hints on how to script this?

[a1ex]

In the lua_fix branch, api_test.lua:

Code: [Select]

key.press(KEY.HALFSHUTTER)

(I know, I should merge it, but since I'm not really using it, it's very easy to forget...)

[dfort]

Thanks, I'll get started with this.

So if someone wants to use the module I create they will need the lua module from the lua_fix branch too, right? Anything else?

[a1ex]

Well, the fix for half-shutter pressing is in ML core, so you would need a custom build.

Anyway, if you help me with some testing feedback and some reminders of the current issues (in particular, those from garry23), I hope to be able to look at it this weekend (or, at least, I'll increase its priority).

[dfort]

I'll give it a try.

You know what my other issues are 

[garry23]

Although I'm busy with work at moment, I'll throw in as much support as I can to get the Lua module to the next release point. 

Cheers

Garry

[dfort]

@a1ex I'm getting a feeling we've been here before.

https://bitbucket.org/hudson/magic-lantern/pull-requests/748/focus-backend-updates-precise-focus/diff

Should I be testing with the unified branch, lua_fix or focus? I assume that the half-shutter press script needs at least the commits that are in lua_fix but there are a lot of tweaks in the focus branch. Maybe I need to merge the branches before testing?

For starters I'm running the api_test.lua script on both an EOSM and 700D with the lua_test branch. No surprises on the 700D, here's the log. The EOSM is causing some issues. The test hangs on the lv test so that had to go (déjà vu) but the lens test is taking a very long time, probably because we haven't figured out how to focus the EOSM yet. It is taking so long that I had to hook up the AC adapter and will try running it overnight to try and get through the lens focus test. I ran a test without the lens focus test and it looks good. Here's the log. Well at least half-shutter is working!

[dfort]

Figured out what was taking so long for the lens focus test to complete on the EOSM. It was because the camera was set to autofocus mode--more déjà vu. It got through the focus test but crashed on the take pics test. Here's that log. [EDIT--the camera needs to be set to autofocus mode but with continuous autofocus disabled to complete the test successfully.]

Set the EOSM on automatic focus and did another run. This time the console showed a message to put the lens on auto focus mode or remove the lens to skip test. Not wanting to wait hours for what will certainly end in a crash I twisted the lens on and off (like the shutter bug "fix") and the test completed successfully. For the record here is the entire log but the pertinent section is:

Code: [Select]

Testing lens focus functionality...
Please enable autofocus.
(or, remove the lens from the camera to skip this test)
Focus test skipped.

Of course all of this is expected behavior until a way to control the lens on the EOSM is figured out.

What would be an enhancement to api_test.lua is to determine what camera is being tested and skip test_lv if it is an EOSM.

[dfort]

Picking up where we left off, I wrote a patch for api_test.lua that skips test_lv when run on an EOSM. I submitted a pull request on the lua_fix branch. Hope that's the right procedure.

I did manage to get a successful api_test.lua run on the EOSM with the camera in "Focus Mode AF" mode and "Continuous AF Disable" set on the Canon menu. Here is the log to that test.

It takes a long time for the EOSM to complete the test and it will crash if the camera is not set to "Continuous shooting" on the Canon menu.



It looks like the main issues that I've found so far on the lua module have to do with focus. garry23 pointed this out:

One of the issues was that moving the lens had to be managed and I did it this way, my a loop delay:

function check_lens_ready()
   if scriptmenu.submenu["Focus bracketing?"].value ~= "no" then -- hang around until lens is ready to be moved
      repeat
      msleep(200)
      until lens.focus(0,1,false)
   end
end

That is a zero movement move!

There was also a recent discussion in the Programmatic focus control and absolute/relative focus position topic.

This pointed to the focus branch so I turned my attention to the Focus backend updates - precise focus position and other tweaks pull request. I tried to help find the missing property handler address for the EOSM a while ago but didn't quite get it. There is an issue compiling the EOSM platform and I think that the reason is because the lens data is missing prop_lv_lens.focus_pos information in the lens.h file causing a build error on that platform. The EOSM is handled differently than the other platforms so as a test I commented out the following block of code from lens.h and ran a test of the focus branch on the EOSM. Running api_test.lua completed successfully on it and created this log which looks to me pretty much like the lua_test branch.

Code: [Select]

#elif defined(CONFIG_EOSM)
struct prop_lv_lens
{
        uint32_t                lens_rotation; //
        uint32_t                lens_step; //
        uint32_t                off_0x08;  //
        uint32_t                off_0x0c;  //
        uint32_t                off_0x10;  //
        uint32_t                off_0x14;  //
        uint32_t                off_0x18;  //
        uint32_t                off_0x1c;  //
        uint32_t                off_0x20;  //
        uint32_t                off_0x24;  //
        uint32_t                off_0x28;  // L10  - names not accurate
        uint16_t                off_0x30;  //     
        uint16_t                focal_len; //
        uint16_t                focus_dist; // One FD
        uint16_t                focus_dist2;//       
        uint16_t                off_0x38;  //
        uint32_t                off_0x3c;  //
        uint8_t                 off_0x3D;  //
       
} __attribute__((packed));

SIZE_CHECK_STRUCT( prop_lv_lens, 59 );

There was another issue compiling the focus branch--the dual_iso module failed to build on all the platforms. The error seems to be this:

Code: [Select]

error:

cr2hdr.c:2574:21: error: function definition is not allowed here
                    {
                    ^

As if all this wasn't enough to chew on for a while I started thinking if the EOSM lens issue has to do with the camera or the EF-M lens so I put on the EF-EOS M adapter and an EF-S 17-55mm 2.8 lens on the camera and re-ran the tests. This time it didn't take nearly as long as with the EF-M lens and I could hear the focus mechanism churning during the tests. The logs show more activity on the EF-S lens than on the EF-M lens. Here's the log for the hacked focus branch and here's the log from the lua_fix branch. If I'm reading it right it appears that the lua_fix branch test may be communicating with the EF-S lens properly. Of course this brings up the question--why isn't it working with the EF-M lens?

[dmilligan]

The dual ISO issue is because cr2hdr won't compile, probably because you are using clang rather than gcc (clang doesn't support anonymous functions, which is the error you're seeing).

[dfort]

...probably because you are using clang rather than gcc...

You're right again. I made a new copy of the repository because I couldn't figure out how to bring in the new branches and forgot to copy over my Makefile.user. Yeah, I know, I should learn this stuff if I want to play with the big boys.

[dfort]

A few days ago a newcomer to the forum had an interesting problem. He wanted to use an EOSM as a wildlife trap camera using Audio RemoteShot to fire the camera. Problem was that this camera only works while the live view is active and the longest setting in the Canon Power saving menu is 30 min. A simple solution would be to keep the live view from going to sleep. This seemed like an ideal task for a lua script.

In the lua_fix branch, api_test.lua:

Code: [Select]

key.press(KEY.HALFSHUTTER)

(I know, I should merge it, but since I'm not really using it, it's very easy to forget...)

So at the risk of posting possibly the worst example of a lua script ever, here is what I came up with:

Code: [Select]

-- LV Alive
-- Don't let Live View go to sleep

while true do
    msleep(10000)
    key.press(KEY.HALFSHUTTER)
    key.press(KEY.UNPRESS_HALFSHUTTER)
end

As a1ex mentioned this only runs on the lua_fix branch. For the test I set the LCD auto off to 15 sec. and the script to trigger a half-shutter press and unpress (very important) every 10 sec. I'm sure it can be greatly improved but hey, it works.

At first I struggled with the menu, the examples wouldn't work for me. I kept stripping it down until I got to the bare essentials to appear in the Scripts menu. I'm not proud of the infinite loop but this is my first lua script so it is bound to have some rough edges.

Of course having a half-shutter press every 10 seconds is annoying when setting up the camera but I'll change that to every 20 minutes and instruct the user to set LCD auto off to 30 min. That should keep the LCD active as long as the battery has juice. Any suggestions?

[DeafEyeJedi]

Wonderful scripting even if it goes through an infinite loop -- to me I find this another giant step towards a small little EOSM and yet it feels so magnesium. Very exciting news!

The best hasn't even come yet and that's just scary good!

I've always wondered if we can trick the EOSM thinking the LiveView is active and keep the LCD display in dim or sleep mode similar to how the other DSLR's running ML can do via through advance settings -- wouldn't this help prolong the battery's juice especially for Audio RemoteShot type of work?

[dfort]

I've always wondered if we can trick the EOSM thinking the LiveView is active and keep the LCD display in dim or sleep mode similar to how the other DSLR's running ML can do via through advance settings -- wouldn't this help prolong the battery's juice especially for Audio RemoteShot type of work?

Yes, the best solution would be to have Audio RemoteShot trigger the EOSM even while the LCD off just like it can on the DSLR's. That would require taking a deep dive into the ML code. My hypothesis is that we'll run into a hardware limitation because when the LCD turns off it also shuts off the microphone input. Of course elaborating on this would take us off the lua topic.

[a1ex]

Right - playing with the functions called by mlv_snd might help. The audio side shouldn't depend on the display operation, but most likely, Canon's powersaving turns off both of them.

Another workaround would be to let audio remote shot work on top of Canon menu. That would reduce the power consumption a lot.

[dmilligan]

I've abandoned using LDT as an editor for Lua scripts. It has a lot of shortcoming and annoyances and appears to not be very well supported anymore. I started using http://code.visualstudio.com/ with the Lua extensions and it's a lot better (also cross platform and open source).