Full shutter press and event handler

[garry23]

@a1ex

Forgive me if this has been asked by someone before, especially by me 

When using the keypress event handler, I can’t seem to hijack the full shutter and unpress full shutter, ie even when I return false, the shutter still operates, both in LV and non LV mode.

Is there a way in Lua to hijack the Canon full shutter?

Cheers

Garry

[Danne]

Really good that you are intense with lua scripting. Could I give a word of advice here. Instead of creating a new forum post for each question to be asked I think it would benefit more people if you start out ONE single post. You could name it "LUA troubleshooting", "LUA shortcomings", "LUA help" or similar. I would love to have all these posts in one single place. Is this possible? No pun intended.

EDIT: I also think you could even change the title of subject from with the same post which means you could even rename the same post every time a new issue comes to mind. This would also collect all at one place.

[a1ex]

When using the keypress event handler, I can’t seem to hijack the full shutter and unpress full shutter, ie even when I return false, the shutter still operates, both in LV and non LV mode.

You want to prevent the camera from taking a picture when user fully presses the shutter button, right?

That is, no shutter/mirror movement should be done when user presses the shutter?

If that's the case, bad news - it can't be done easily from the main ARM CPU (the one where ML runs), because this button is handled by the MPU. The decision to actuate the shutter is made on the MPU. Afterwards, the MPU transmits the event to the main CPU, which is supposed to complete the image capture process - but it has no veto rights (it can't block the shutter movement - the MPU decides this on its own).

The only way - known to me - to block the shutter button is to put the camera into BUSY mode (with that message displayed by Canon firmware). The memory allocation backend (exmem) does this when allocating SRM memory (as the camera would crash if user tries to take a picture while ML uses SRM memory). The functionality is not yet available to Lua, but it can be done if there is a very good use case for it (as usual).

I would love to have all these posts in one single place. Is this possible?

CC @ moderators, they have the power to join threads (or split them).

[garry23]

@Danne

Good point and I’ll try and remember to do this in the future ;-)

Regarding my Lua scripting, as you know I script for myself, but freely share on this forum for others to use as they see fit.

I have no idea if others are using Lua like I do, ie to help with photography. I see a lot of video stuff, but not that much photography related discussion.

As I’ve said before, I think Lua scripting is the star in ML.

Cheers and stay away from the (mutating) pestilence and (increasing) stupidity in the world

Garry

[garry23]

@a1ex

If that's the case, bad news - it can't be done easily

I thought you might say that 

As for the use case it is being able to use Lua to moderate normal shutter action outside of LV. That is the feature would allow the user to intercept the ‘normal’ shutter and use Lua to then control image capture, eg bracketing etc.

There are many times I wish to handhold bracketing, but looking through the optical viewfinder, ie not LV, especially on a 5D3 in bright sunlight.

[a1ex]

I've considered that as well. If you were wondering why ML uses the first picture (captured by the user) in order to start a bracketing sequence, or a half-shutter press in order to capture a full-res silent picture, rather than full-shutter press, the above answer still applies

For hand-held bracketing, I'd recommend some automation around the full-res LiveView functionality from crop_rec_4k and derived builds, as that would minimize the delay between two captures. Unfortunately, it's not something Lua can help with...

[garry23]

@a1ex

I’m content I can hand hold bracket from LV, ie my MUSIC script does this for me.  That is the image to image delay is not an issue.

BTW I’m just about to uplift MUSIC with a new use case, ie zero noise bracketing, which I find a great strategy, ie base shutter & base shutter + 4Ev.

Cheers

Garry

[Walter Schulz]

@Garry: What happens outside the forum:
Devs have realtime chats on ML's (inofficial ... sort of) discord server and some channels dedicated to different cams and things like debug tools, QEMU. Pinning messages is not used that often. Until recently "bigger" findings where posted in this ML forum for posterity. But this is going to change. Last weekend coon created a wiki structure for different cameras and you will find latest dev knowledge there.

Suggestions:
Drop your questions there, maybe even ask for a channel dedicated to scripting issues. Then consolidate your findings in a new wiki. Single or tree, nobody really cares ATM.

Nothing is written in stone ATM and it is not that easy to track everything everywhere. Have your say and do your thing!

[Audionut]

I'd prefer these LUA questions to remain on the forum, so they are easy to find.

Trying to join all of the threads will be problematic, as they will be sorted by date, resulting in a mixed jumble of a thread with no logical structure.

I also actually prefer the questions to all remain separate, as I think it's easier to search for thread titles, and being able to keep the (strictly related) questions contained in one thread for easy reading. Just my 2c.

[Danne]

Fully possible to change Subject:(check my title above) while posting another lua dilemma within the same post, but of course. If a lua issue were to be handled over time and "fixed" and worked upon, single posts would be great, but that´s not really what´s going on here. More like lua urges on a strictly personal level and only person with answers is a1ex atm.
Keeping all at one place would be easier for others looking for lua answers, and in this case, mostly still image related.

Don´t get me wrong. I also have a lot of trouble understanding how buttons acts and what works and not so all info is valid. Also seems more community friendly if the author owns a deepened post and then he can pass answers to future lua "noobs" and contribute himself pointing to the coming mega lua post .

On the other hand Walters suggestion seems more logical asking direct questions over at discord.

Just my 5 cents...

[garry23]

All the above potentially suggests the need for a 'new' taxonomy ?

We have those that focus on: Video; those on photography; those on Lua; and the cross-interest ML core developers.

Beyond my pay grade to sort out ;-) :-)

[Walter Schulz]

Yeah, we are building the bridge while crossing it.

[garry23]

Yeah, we are building the bridge while crossing it.

 

[Danne]

What about focus confirmation? That setting blocks full shutter until camera nails focus. Could we trigger some registry here while pushing shutter?

[a1ex]

This one is easy: set AF on the back button, and the shutter will fire as soon as it's pressed, without waiting for focus confirmation.

That's how camera.shoot() works - by default, it doesn't autofocus and shoudn't wait for any kind of confirmation. You can optionally ask for autofocus, and in that case, it will wait.

https://builds.magiclantern.fm/lua_api/modules/camera.html#shoot

You can also autofocus without taking a picture, with lens.autofocus():
https://builds.magiclantern.fm/lua_api/modules/lens.html#autofocus

[Audionut]

Fully possible to change Subject:(check my title above) while posting another lua dilemma within the same post,

That will end messy.

If a lua issue were to be handled over time and "fixed" and worked upon, single posts would be great, but that´s not really what´s going on here. More like lua urges on a strictly personal level and only person with answers is a1ex atm.

Which is why the questions should stay on the forum, and not somewhere in among a potentially endless chat log.

Keeping all at one place would be easier for others looking for lua answers, and in this case, mostly still image related.

I'm not entirely sure how browsing through a multi-page thread is easier. Try and find something specific in the ADTG/CMOS thread for example.

There's a difference between keeping a specific script relegated to a specific thread (questions/examples/etc/etc), and keeping all manner of random questions, loosely tied together because "LUA", in a single thread. Not always do questions get answered. How far through a thread should someone check, before they realise a question was not answered?

Also seems more community friendly if the author owns a deepened post and then he can pass answers to future lua "noobs" and contribute himself pointing to the coming mega lua post .

Until one of a potentially one hundred and million one things happen that cause a member of the community to no longer be able to participate. Agreed fully with a "mega post", but that is something I could do, when specifics are easy to reach. I would not dig through a 50 page thread to determine where the questions are, and where the resulting answers are.

Anyway, the entire LUA section is practically Garry's section. I'm not going to merge threads, nor archive the the Q&A section on the expectation that single contributors, need to relegate their discussion to a single thread. As far as I'm concerned, Garry can keep on doing what Garry does best, however he sees fit.

[Danne]

No need for regulating anything. This is supposed to be a friendly discussion. I might have used the forum post function wrong or differently here. I suppose streaming forum posts in this case will get summoned just nicely under lua section. I actually never thought of those sections as summarizing categories but this will work better than my suggestion actually.

Gonna check a1ex into A1ex lens.autofocus(); tip now.
Cheers!

[Audionut]

No need for regulating anything.

Relegate vs regulate, while those who regulate could possibly be called regulators.

Someone who relegates is possibly something like this.

[Danne]

Sorry, misread. Thanks for pointing out.