Can ml set Canon variables like "Image Review"?

Started by Marsu42, September 29, 2012, 02:30:31 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Marsu42

If "Image Review" is set focus stacking is slowed considerably... I guess because there is this loop with get_out_of_play_mode() there is no direct way to set Canon variables, i.e. disable "Image Review" before starting the stack and re-enabling it afterwards?

1%

You can cache hack where it starts play mode and then change it back when you want image review.

a1ex

It can - with prop_request_change.

The problem of doing this is that those settings are permanent. So if you take the battery out in the middle of the operation, you end up with the setting changed.

This happens more often than you think - see the ton of issues regarding AF button assigned on *. ML uses this trick to disable autofocus on HDR/intervalometer shots.

Marsu42

Quote from: a1ex on September 29, 2012, 08:38:29 AM
It can - with prop_request_change. The problem of doing this is that those settings are permanent. So if you take the battery out in the middle of the operation, you end up with the setting changed.

Thank, sorry asking really basic things - is there a faq on these basic functions (if not, this question should go into it)?

* And the settings being changed by ml is really irritating when you don't know what's going on, I know this myself. Maybe a wrapper around prop_request_change would be a solution that saves it & sets a dirty flag on the card (drawback: many write operations). That would enable ml to restore the old setting after the battery was taken out. There could be an option for seasoned users to disable it like "write config file"), but for newbies it would be a good thing.

* I still think there should be a standard method to cancel whatever ml is doing, that would defeat the need to take the battery out and give the user more subjective control (like help! I've forgot to reset the hdr exposure shots from 7 to 0, and now my focus stack is taking 200 pictures instead of 50!).

a1ex

Thought at that. But also thought at something quite unlikely:

- Let's say user puts the card into another camera. ML will read from config file that it has to change something, and it will try to do that.
- Let's say the config file gets corrupted somehow, and as a result, ML will attempt to set an invalid value. Of course, most things have range checking in ML, but still, I don't like the solution.

For AF, my attempt is to restore it at shutdown, if it's marked as "dirty". I've tried it by setting ML to shoot in crazy mode - in 2.3 implementation, it was moving AF to back button before each shot, and moving it back to user setting after. If you shutdown the camera normally, the shutdown handler will restore this setting before telling to dryos "ready to shutdown". If you take the battery out, the AF remains moved to back button.

Marsu42

Quote from: a1ex on September 29, 2012, 11:26:48 AM
- Let's say user puts the card into another camera. ML will read from config file that it has to change something, and it will try to do that.
- Let's say the config file gets corrupted somehow, and as a result, ML will attempt to set an invalid value. Of course, most things have range checking in ML, but still, I don't like the solution.

You could tie the config file to some singular camera specific value (like the serial number if it can be read) or something ml-generated (like combination of camera type + shutter cycles) to prevent setting being shared between cameras. As for the corruption problem as you said a range check would solve the problem. Still, doesn't matter to me anymore since I now know what ml is doing.

Quote from: a1ex on September 29, 2012, 11:26:48 AM
If you shutdown the camera normally, the shutdown handler will restore this setting before telling to dryos "ready to shutdown". If you take the battery out, the AF remains moved to back button.

Ah, I didn't realize that yet, should be sufficient, too ... maybe it's a recent implementation - because I remember always ending up w/ the af setting changed :->

a1ex

I did it in one of the RC versions, so it's enabled in 2.3. There's even a retry mechanism, if Canon firmware doesn't accept the setting for the first try (it may happen if it's in the middle of taking a picture). Also, Screamer, who is a heavy user for HDR bracketing and stacking, confirmed that it's been fixed for him.

I have AF on back button anyway, so I never notice it in practice.

Marsu42

1. Um, to make extra-sure because I understand this can really screw up things (and I'll try it in C mode): Where do I get the correct "size_t len" for prop_request_change from? Since the range for image review seems to be "0, 2, 4, 8, ff" I guess the lenght might be "1" byte, but all other values in the source code are either 2 or 4 - argh...

int new_image_review_value = 0;
prop_request_change(PROP_IMAGE_REVIEW_TIME, &new_image_review_value, 2);

# --

2. _get_prop is disabled in property.c as "not reliable" ... but there is an exact duplicate function in prop-debug.c? So does this mean that I can save values like the old image review time and restore them after some time or isn't this safe?

a1ex

1. Most integer properties have len=4. Here you can find a list for 5D2: http://a1ex.magiclantern.fm/bleeding-edge/PROP-5D2.LOG

You can get one by calling prop_dump from don't click me, for example. It requires get_prop - it's OK for a quick inspection, but it doesn't behave well, sometimes it returns bogus values.

Or, you can setup a PROP_HANDLER and print the len value from there. Only be careful with delays, as this runs in a Canon task and it will slow it down and will probably cause timing errors too. You can use NotifyBox, as it returns right away.

2. Most property values are obtained in propvalues.c and visible as globals - so Canon value is available in image_review_time.