MLU

[garry23]

@a1ex

I’m trying to understand how ML’s MLU work, eg on my 5D3, using the latest Lua fix build.

Seems to work ok in single shooting.

What I’m wondering is, would it be possible, from a Lua call, to enable it and activate it, ie move the mirror, then call shoot() as many times as needed, then switch off MLU, ie lower the mirror.

I appreciate this ‘request’ will need to be added to others and only enabled in the future when priorities allow. Just asking if you think it is possible.

[a1ex]

Mirror actuation is decided by the MPU, so... the only ways to achieve this would be:

1) regular pictures in LiveView, with Canon's silent shooting mode enabled (this won't move the mirror while taking pictures)
2) full-res silent pictures (which won't move the shutter either)

I'd rather make full-res silent pictures usable at short exposure times

[garry23]

@a1ex

Thumbs up for the FRSP vision 

My use case is when I’m handholding, eg super resolution bracketing or exposure bracketing, where I’m not in LV, ie using the VF.

But fully understand what you say and recognise ML priorities at the moment.

BTW I’m personally keeping a wish list of possible Lua API enhancements, I wonder if we should have a sticky link for capturing such API thoughts?

[a1ex]

In that case, you may enter LiveView from Lua, take the pictures, then return to regular photo mode. On some models (5D3 included), this actually approximates MLU behavior very well - the only side effects being possible delays from LiveView processing. If you capture the images in burst mode, these additional delays should be minimal.

A sticky topic with Lua API suggestions can be helpful, yes.

[garry23]

@a1ex

Thanks for the LV suggestion, I’ll look into that approach.

@Audionut

How about a new sticky link under scripting

A sticky topic with Lua API suggestions can be helpful, yes.

from a1ex

[a1ex]

The usual way is to create the topic first, with relevant contents, of course.

Once that topic is useful enough to become sticky, it can be made sticky by a moderator.

[garry23]

I’ll post something soon, ie to get things going.

Cheers

Garry

[garry23]

@a1ex

Just a few more thoughts on MLU.

The current ML MLU seems to ‘just’ switch the Canon MLU feature on or off on my 5D3.

This means that for my shutter triggered, hand held bracketing use case, this means I get a shutter-up, image shutter-down, then I enter LV and get a shutter-up, then script runs bracket capture, then exit LV for a mirror down. Works, and I’ve coded it as an option in my script.

As long as we can’t hijack the full shutter press, the above will have to do.

At the back of my mind is another weakness of the current ML-Canon set up: not being able to access focus info in non LV mode. The use case being using the VF and getting ML, ie a script, give you focus feedback.

Do you think it could be possible to remain in LV but do a mirror-down, so you can get the benefits of both modes, ie use the VF and keep getting focus info fed to Lua?

[a1ex]

Not sure I understand. What kind of focus info is not available outside LiveView?

Focus distance and DOF info were available in lua_fix builds since early 2018. ML asks the MPU for a refresh, once every second.

[garry23]

Shock/horror. 

Focus distance and DOF info were available in lua_fix builds since early 2018. ML asks the MPU for a refresh, once every second.

vs

focus_distance
Get the current focus distance (in mm). Only updated in LiveView.
focus_distance int readonly

[a1ex]

Right; maybe somebody could volunteer to keep the documentation up to date. I'm not actively using Lua, and the documentation itself is not covered by the test suite, so... outdated docs are not always obvious to me.

[garry23]

@a1ex

I am more than willing to support updating words, as I have been doing on the wiki terminology piece.

The issue is, I don’t know what I don’t know 

I’m embarrassed to say I hadn’t spotted the focus uplift. 

I guess a point for the future is, that whenever code gets changed and uploaded to all, the code creator/changer should also look to changing any documentation. Easy to say, but not easy to impose.

Cheers

Garry

[Walter Schulz]

In a perfect world it would fit.
But it is not: Some years back a new build introduced unlimited recording durations for raw video. But no dev knew about it!

[garry23]

Dream, Pray, Hope then Do 

[Danne]

@a1ex
I guess a point for the future is, that whenever code gets changed and uploaded to all, the code creator/changer should also look to changing any documentation. Easy to say, but not easy to impose.

Following commits is the best way to stay updated. Don´t think A1ex missed publishing a commit ever.
I also believe the one that codes should not always be the person updating documentation. Coding takes by far the most time and energy and then most stuff needs testing, feedback etc as well. Collaboration including users here is probably a better path a lot of the time.
Just an open source "gpl" opinion from me.

[garry23]

All

I’m embarrassed to admit that the focus info outside of LV missed me, reinforced by me continuing to read the old/current Lua documentation.

Agree with you about coders not being necessarily accountable for doc updates.

Not a straightforward thing to sort out when ML is a volunteer based community.