Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Marsu42

One thing I've never quite understood about the inner workings of the camera: How is it that we need these awful keypress simulations to get some things done? Isn't there some way to *directly* access whatever-that-key does, there has to be some entry point in the Canon fw we can simply call like for "metering and af start" - or am I getting this entirely wrong?

The current annoyance is that I'd like to engage *H (expo lock hold) with ML, but no button it is available has a gui event on the 6d - thus I cannot simulate it. Harrrrrrgnnn ...

... (background): this would be the solution to the braindead 6d af-pt-biased eval metering, the idea is to auto-expo-lock whenever engaging the af with halfshutter. The "dual button method" with simple hold on halfshutter and backbutton af is too slow and cumbersome for quick shooting.
Just to spare all you good people some trouble and b/c it might be the natural inclination of the hardware hacker to use bleeding edge software, too...

... the latest gcc 4.9.3 (from launchpad) breaks my 60d build, the led activates on boot and that's that. It's working just fine though with gcc 4.8.4, so some new optimizations don't like the ml source or there are some bugs in 4.9.

Strangely, compiling the very same source with 4.9.3 for *6d* works just fine. Go figure :-p
Yo, after managing to set my 6d to m-raw for some important shots (I didn't notice the warning, even though it was enabled) I'd like to add the option to *lock* the camera to raw mode, i.e. extent the feature in tweaks.c

Problem is: setting PROP_PIC_QUALITY seems like a premiere way to brick the camera, I guess thus the feature name "FEATURE_PICQ_DANGEROUS". I don't know if a "C" mode is a foolproof safeguard at least for testing:

The ML code contains the function to read the prop and figure out if raw is enabled, but how do I *set* raw - or is this not possible in a reliable way at all? Did anyone succeed at least on the current gen bodies (6d,5d3), how did you do it?
It would be nice if the (well, 6d for now) would add [edit: the usual suspect lens/camera exif data inc.] the current gps information to silent dng pictures so you can skip adding the geo tags from the tracklog later on. Currently, chdk-dng says: "Code stripped down a bit, since we don't care about GPS and advanced exif stuff (at least for now)"

Not a very pressing issue, but I'd like to add a feature request here as a reminder if someone works on gps or dng anyway.
I guess you know the issue as it affects various modules: How do you detect if a user changed a property when the ML code also changes it?

Example: In auto_iso, I want to disable the module when the user changes/overrides the iso value. But since there is a lag between setting a prop and it being actually changed I cannot really tell if it was the code or the user that changed it:
1. current iso: 400 -> code sets it to 200
2. next shoot_task cycle: code detects "still 400" -> is it not yet changed to 200 or has the user set it back to 400?

Question: I recently saw some time detection (I guess it was alex' code?), but I don't quite remember where. Is there some rtos-like max. delay when I can say that the prop should have been changed by then?
I'd like to add some c.fn toggling to my hotkey module (esp. switch to different af tracking "scenarios" on 6d by modifying the 3 relevant c.fn settings).

I'd currently hardcode this for my 6d, but I could also add a gui for "set c.fn (enter value).(enter value) to (enter value)." Alas, I certainly won't read all Canon manuals what c.fn settings are valid on what model, thus the question: Can users brick cameras by setting c.fn to out of bounds values - or does Canon code simply ignore wrong settings?
Is there anything in the works concerning an abstraction layer to tie specific settings to the lens that is on the camera?

Currently, I'm (nearly :-)) about to hardcode my 3 lenses into my auto_iso module so I get lens-specific min. shutter settings in av mode - but I can imagine lots of other options (Canon and ML) that I always switch based on the lens I'm using as they indicate different "shooting scenarios".

If the core would provide some framework for this, other modules might also profit from this ... but alas, as always it probably needs some time-consuming gui work next to the backend.
The latest versions of Helicon remote have a feature called "Burst Bracketing" - after pre-setting the max. fps of the attached camera it does this:

QuoteNew feature - burst bracketing (combining continuous Stackshot movement with burst shooting to shoot focus stacks rapidly - in a matter of seconds)

Obviously, if this is possible this should go into ML asap :-) as it fixes the main shortcoming of focus stacking - the crawling speed which leaves you with broken stacks when the (natural) light changes.
Could beep_custom() please be amended with an option to set the volume of the beep sound? Currently it's only global, but an added volume setting relative to that, i.e. producing quieter sounds (maybe in steps 1-10 or whatever) would be very welcome. Reason: I want to have quieter "notification" sounds and louder warnings.
I'd like to add a small function that resets the af point to center if I turn on the camera. Where do I hook this function w/o executing it all the time in shoot task as I usually do? Thanks!
I'm curious, but don't understand how ML interfaces with Canon and how much original memory management is in ML... gcc 4.9 now includes the address sanitizer for arm, is this useful for ML?
I cannot make my README.rst show the description text in camera - and I also don't see it from any other module *except* but that source code is unavailable atm :-\ ... where do I get a working README.rst sample? Thanks!
I'd like to preview ettr'ed or (deliberately of course :-)) underexposed shots with the built-in exposure preview in qr/play mode via the cursor keys or set+wheel.

Would it be feasible and probably a minor code addition to add an option for a non-linear preview, i.e. some gamma-ish curve that keeps the black and white point where it is - or even does a contrast optimization to fill the histogram? This would be a nice preview for later postprocessing and would help me to decide if the shot is ok or I need to modify something to save work later.
The Canon overlay in play/qr modes is cluttering the view - the font is larger than necessary, and they display information at least I don't care about. At the same time, switching the overlay off completely isn't an option since I require *some* pieces of information.

Would it be possible to print a customizable ML info line instead of Canon - or is some of the information Canon has (like Av/Tv) inaccessible to ML in play mode? Having this feature would also be useful when (and if) ML file tagging is added.

Edit: Marked this as impossible unless someone is willing to to the re alex described below.
In the core, I can tell fake keypresses from real ones with an IS_FAKE(event) check & only then look at event->param keycode - but modules only get the button code. So how do I check for fake keypresses in a module? Thanks!
If anyone manages to figure out the gps props for the 6d, I'd like to include this in a module:

1. Adapt the satellite fix time according to the camera idle time, i.e. get new positions fast when the user is obviously doing something with the camera, but lengthen the intervals when the camera is doing nothing to reduce battery drain.

2. Auto-disable on shutdown, (re-)enable on startup to prevent battery drain when forgetting to switch gps off.

Any other ideas on what to do with gps are welcome.
Inspired by the discussion here:

I'd like to suggest two functions (via lookup tables if needed) that cast Canon's 8-step internal shutter/aperture values to the very same human readable "f/xyz" and "1/abcd s" that Canon uses for the given exposure level increments, no matter how accurate they are. Imho the discrepancy between ML menu and Canon menu/lcd/vf doesn't help usability, I stumble upon this all the time.
Is there a table somewhere stating which keypress (and unpress) event works where, in and outside live view?

This would be very useful when trying to code a module that works cross-platform, if it doesn't exist how about creating one - maybe with an automated tool that collects the required feedback from owners of these cameras?
One problem with ettr shots is that they look horrible on the lcd and any newbie wouldn't suspect this is actually an excellent exposure if treated correctly in postprocessing. Personally, I often have a hard time figuring out if the shot is ok in other ways than the exposure so I use the exposure correction via set+wheel or left/right cursor keys.

My idea: Automatically determine what exposure correction is needed for ettr shots, and sticky this to the preview of this shot so apart from the histogram the shots looks "normal" like non-ettr. As a side effect, it's usually also easier to see where blown whites might be.
I recently requested a backend for tagging to xmp files here, alex says it can be done:

So the question is: How do we implement it on the frontend side? To start the discussion, I'll write what *I* want to do with tagging and what approach would be sufficient for me. Feel free to write what you want to do with keywords & tagging so we can start coding.

I'd like to have more than one dimension than just 0-5 rating stars, at least *two* more tags (usually "dupe" and "todo", but let's call them "tag1" and tag2" so I can kickstart postprocessing when back at home.

I'd implement them using the current SET+Wheel code which I just modified to also work with cursor/joystick left-right. 1x Left would add "tag1", 2x Left "tag1+tag2", 1x Right "tag2", 2x Right also "tag1+tag" ... and the thing would wrap around with no tag1/tag2 at all when back.

In theory, tagging could be extended to whatnot, with unlimited custom tags entered in a text field and whatnot - I'd like to get a simple & realistic version that can be implemented by little devs like me, or somebody else also has to pick up coding the frontend.
Feature Requests / Mode switch in C modes?
February 17, 2014, 07:15:50 PM
I know mode switching is dangerous and alex bricked his 60d with this method... but I have to ask again: Is this also the case in C modes, as these don't save any settings permanently?

For wildlife/action switching modes by a button like on 1dx would be a god-send, anything else can be set by ml, just the mode itself (av/tv/m) switching is missing.
We have already got the option to add post-deflicker and dual_iso tag information to xmp sidecar files.

What I'd like to have is the option to add or remove arbitrary keywords to this file, complete with the option to create the sidecar it if it doesn't already exist - like in CheckKeyword("tag"), AddKeyword("tag") and RemoveKeyword("tag").

The front-end (which buttons to press where in what mode with what feedback) isn't the problem - but have no clue about the file r/w stuff, so it'd be great if some other dev could help out with creating these backend functions :-o

Imho it's well worth the work, the 5d3 even got the (in)famous rate button because for pj work tagging in-camera is important - so I'm sure adding the ability for more than one dimension (rating) would be widely appreciated.
Using Bitbucket, when I try to sync my ML fork with the master I'm getting the error message "Unable to merge - conflicts during merge". Problem is: even after resolving all issues with files marked with "conflict" in the diff, it still fails w/o any file marked as a problem - unlike the promised "View the conflicts".

I have encountered this problem multiple times by now and the only solution I found is to completely reset, i.e. delete the repo, re-fork and re-patch in all my changes. Is there any way to find out what the problem is - probably by running hg directly w/o BitBucket? Thanks!
I know we cannot access the top lcd information directly - but maybe we can fool it into displaying what we want? My idea is to hack/modify the free card space information so we can get any number we want in the "remaining shots" display area.

This would be invaluable for photo mode when feedback is required or information could be given like set/remaining # of ml backets/focus stacks and whatnot. As my previous feature request about a back LCD notify box I think more feedback in photo mode would be a huge usability boost, just letting the camera beep sounds like C64 age again :-p
Adding to my all-time favorite requests (submenus (nearly done) and array variables in modules) here's a new one:

For the auto_iso module and other features, I'd like to give non-audio feedback. The latter is limited to max. 2 beeps with varying frequencies and the audio on 6d is also very quit so it's often no good.

What I have in mind is about what Canon does on the newer Cameras with the subitems in the Q menu -  some large-print text and probably scale on the LCD w/o entering the ML or Canon menu.

One example would be to print the selected min. shutter/aperture from the auto_iso module, but I'm sure there are tons of other applications for visual back lcd feedback ... unfortunately, we cannot control the vf or top lcd, so that's the only option left.
Yo 6d users (and esp. 1%), your help is needed to get the new mini_iso module working on the 6d:

Alex has now support for it and raw_diag also works on the 6d, problem is that for well known reasons he's currently not too enthusiastic about the whole 6d thing unless some TL back-merging is done. But if someone wants to give it a try and calibrate for the 6d, I'm sure he'll pm you the link to the dev binary.

This needs to be done (again), I did only part of it and haven't got time to continue:

This is what I found:

* the module works, mini_iso @ neutral with 0ev gain settings is identical to Canon & I calibrated it. It does show the desired effect to gain dynamic range - so far, so good.

* problem is: the module refuses to force the values into to the desired white level range set in the options (acr, dcraw, ...). The question is if I did something wrong, or there's something different on 6d than 5d3/60d where it works just fine.

* todo for you: repeat the series so that we can see if my measurements were wrong or the module really isn't working on the 6d as expected.

# --

Here's my 6d calibration:
# Config file for module mini_iso (MINI_ISO.MO)
black.opt = 0
calibrated.gain.100 = -29
calibrated.gain.200 = -32
calibrated.gain.400 = -37
calibrated.gain.800 = -39
calibrated.gain.1600 = -42
calibrated.gain.3200 = -51
calibrated.gain.6400 = -53
calibrated.gain.12800 = -153

Here's the sheet (I didn't do the last row of f0.0), black was always 2047 or 2048, white sometimes changed by a minor amount on multiple tests:

100 Canon;15331;11,458;15498;11,470;-0,29;82
100 ML@0;15331;11,455;15498;11,470;;
100 ML@-1;;;10485;11,802;;
200 Canon;15331;11,450;15498;11,459;-0,32;160
200 ML@0;15331;11,446;15498;11,460;;
200 ML@-1;;;10312;11,768;;
400 Canon;15331;11,304;15498;11,316;-0,37;310
400 ML@0;15331;11,282;15498;11,302;;
400 ML@-1;;;10727;11,649;;
800 Canon;15331;11,072;15498;11,087;-0,39;610
800 ML@0;15331;11,030;15498;11,083;;
800 ML@-1;;;10846;11,403;;
1600 Canon;15331;10,644;15498;10,668;-0,42;1195
1600 ML@0;15331;10,544;15498;10,560;;
1600 ML@-1;;;11025;10,965;;
3200 Canon;15331;10,022;15498;9,858;-0,51;2247
3200 ML@0;15331;9,868;15498;9,867;;
3200 ML@-1;;;11635;10,366;;
6400 Canon;15331;9,280;15500;9,032;-0,53;4432
6400 ML@0;15333;9,040;15500;9,030;;
6400 ML@-1;;;11836;9,555;;
12800 Canon;15331;8,283;15502;8,030;-1,53;4432
12800 ML@0;15334;8,037;15502;8,017;;
12800 ML@-1;;;15500;9,003;;
Both my auto_iso module (in M mode for EC) and the autoexpo module work by calculating the Bv from reading the AE value.

Unfortunately, this doesn't seem to be immensely reliable, at least on my cameras (60d, 6d is even worse) the AE reading can overflow and also very often returns values completely off the scale, causing a metering lag since ML has to wait for a correct reading and potentially causing mis-exposure when the lighting changes quickly... currently I couldn't really recommend this mode for critical shooting, while auto_iso in Av/Tv naturally always falls back to a correct Canon exposure setting.

Pravdomil mentioned a potential possibility of directly reading the metering w/o the AE problems, is this an actual possibility? Sorry if this is a dupe, is there has been any further discussion on this I'd be grateful for a link to it.
The ML Wiki says only the ML version of iso160 multiples have an advantage, while with Canon the raw file is the same.

I repeated this theory in the CR forum, and another poster wrote that this is wrong bases on DxO data - now I am really confused, is the wiki outdated and are at least newer cameras different even when shooting raw? Here's the discussion link w/ the diagrams:

If iso100 multiples don't prove to be "best" after all, I'll modify the auto_iso module accordingly with an option to use iso160 multiples instead.
This is a long-standing idea of mine, but I never came around to do it (yet):

When doing a focus stack, it could be useful to do the last shot behind the object with a wider aperture resulting in more background blur. You can then combine the stacked object with the blurred background in post, potentially resulting in a nicer result and keeping the number of frames down because you can use f8-f13 on your macro lens which would result in a less pleasant background w/o this modification.

I think it's easily implemented, just add a menu option with the requested "final" aperture, then add this difference to the shutter on the final shot, done. What do you think, does it make sense?
The "External Speedlite Control"->"Flash function settings" is basically just like the Q menu, but for many vital flash features - it's a really nice new menu vs. 60D and nearly vital if you don't own a big flash with its own lcd panel.

Problem is: This menu is tiresome to reach, and it cannot be pinned to "My Menu" directly. I would like to have this menu on the Q key, either as a replacement for the shooting menu or as double-click Q.

Question 1: The current way to do this (w/o scripting) would be to write a module that intercepts the Q key. Is there any way to get this flash menu on screen *directly* through a Canon api call, or do I have to simulate the long keychain MENU->R->R->D->D->SET->U->Up->SET ?

Question 2: If there's no direct way, how do I detect that the Canon menu is currently active, so that I know that I have to exit and re-enter it to make the keychain work?
I'm on a 6D with 2 C modes, and I still feel limited by it, Canon is very crafty as making this a distinction between cameras as the 5D3 as graced with 3 C modes...

... so here's a request for our pro ML hackers, I would have no idea how to do it:

Canon has to save all the setting data for their C modes *somewhere*, correct? If ML could find these data blocks, they could be saved and restored, resulting in an unlimited number of Cx "sets" to chose from for different situations. If this data is written if the camera is *not* in that particular C mode I see no danger from this approach (unlike the old ML mode switch), because modifying the actual camera settings is done by the Canon fw and if the data came from the camera, so it has to be valid.

Does this idea sound interesting? Any thoughts on how to find, save & restore these Cx mode setting data blocks?
It seems the Canon fw can read the focal length and adjust the min. shutter speed in full auto mode, so there has to be a way to read this value somehow even if it hasn't been found yet ... this would be invaluable for example for the auto_iso module and so on which set a min. shutter speed in Av.
Feature Requests / Silent pics delayed trigger
November 16, 2013, 03:56:29 PM
This is one of Alex' own ideas, but I think it should be promoted to an official request to remind him once he's back :-) ...

... the idea is to continuously capture silent pics into the buffer, but *only* to save them after pressing halfshutter. This fixes the main problem with burst pics and fast action and the reason I don't use it for this - if the action starts, at least part of it be over once you managed to press the button.

The UI should show how much time at what fps is currently in the buffer so you can estimate when to save it - and/or there could be a menu option to save a fixed amount of xyz frames/time backlog after pressing halfshutter and from there on as much as the buffer holds.
The current display of 1/xyz shutter values or f/xyz aperture values in ML is not "correct" as it doesn't correspond to the Canon steps with 1/3ev and 1/2ev  exposure level increments, but is simply calculated by dividing the 8-step av/tv values.

This seems a bit strange and hackish (it's one of the first things I noticed when installing ml back than), and for display in the core and in modules (like autoexpo and auto_iso) there could be ...

* a fixed lens_format_shutter() with SYM_1_SLASH that adheres to Canon
* a new and correct lens_format_aperture() function with SYM_F_SLASH

I know this is not exactly essential, but if someone comes around to it, it would be very nice to have :-)
One question that has always been puzzling me: Why are the numerical values of Canon's shutter like this? We've got nice conversion macros now for APEX (thanks, pravdomil!) , but I don't understand the reason why Canon chose their values in the first place.

#define APEX_TV(raw) ((int)(raw) - 56)
#define APEX_SV(raw) ((int)(raw) - 32)

How do I add the code from a pull request to the main repo to my own repo fork (for example, if I want to try the adv_int module)?

All I can see is a possibility to get a diff for individual commits, but not for the whole pull request - and I am not able to divert a pull request via fork or compare to my own repo either.
Sorry if you feel bombarded with "this would be a good idea" threads, but here's another one that I feel should be addressed when using different models in parallel and swapping cards between cameras (yes-i-know-this-is-not-recommended, but large-gb-cards-do-not-grow-on-trees):

1. Make settings model-specific, for example by moving them to sub-directories. This esp. would prevent reading wrong props from the config file - the code is supposed to double-check this, but I wouldn't bet on it, esp. if I wrote it :-p so imho completely avoiding bricking would be safer. Also, the config file isn't really compatible anyway because different cameras use different features (or need different settings) - so why not simply separate the configs altogether?

2. Continue boot on incompatible autoexec.bin - this is a minor annoyance, but anyway: If I switch cards (I have different sizes) between 6d & 60d and a single-model autoexec.bin is on them, the cameras simply fail to boot. This not only gives me a near heart attack each time, but also prevents me using them in case even without ml. Would it be possible to simply continue booting the camera without ml instead of halting it?

Thanks for taking the time to evaluate these :-)
Since nightly is the new stable, it could be that new module pull requests are delayed if they aren't production quality. Imho this hinders testing & feedback, and that's what a trunk source code is for - not to provide daily updated production builds. To enhance the process, I propose two additions to the module's README.rst fields:

1. Code Quality: Staging or Production. This should go along with an option in the module debug section to load only modules that are production quality, so no development modules hamper a stable ml experience - on the other hand new modules could get merged faster since they are now marked as work in progress.

2. Model compatibility: Tested / Untested / Not working . Currently, modules are implicitly expected to work with all cameras. For some modules this is difficult or impossible to achieve, so these flags (like ::Compatibiltiy:: +60d +6d -100d -eosm) would help to filter modules. Rationale:

* Some modules won't work on some models at all, like dot_tune w/o camera afma - currently they only show horrible debug messages about some strange core functions not being found. The new flag would enable ml disable loading this module if it's known not to work.

* Newer models are sometimes quite different - I just painfully discovered this for button management and iso setting when moving from 60d->6d. So the modules' authors can only code for one or two platform, and hope for the best for the rest, if they are willing to make the effort to support all cameras at all. The new flag would make clear what camera the module is tested or intended for.
The new "Junke Mode" is really nice and all, but I find myself never using it. Instead I suggest an option to get close the ml menu(s) and get to the Canon menu asap when pressing BGMT_MENU (menu.c), Q is already there to close submenus as well as open them.

I could submit a pull request for this, but only if there is a chance of getting this option merged, otherwise I'll just use it locally. Opinions, please?
Are there any hooks at all to set information in the viewfinder, line the ! symbol next to the battery that the 6D has?

If so, it would be very useful for other purposes than Canon intended but as a signal from ml w/o needing to take the eye off the vf.
This might be considered over the top by some(?), but it'd be nice if a dev could clean up the warnings the core ml code has when compiled with -Wall ... it's mostly -Wformat stuff that can be cleaned up with an explicit cast.

Yes, I could simply disable this warning, but if adding code to the ml core I want to see all warnings in case I break something - so if anyone volunteers who has write access to the repo and doesn't have to go through a lengthy pull process - go ahead :-)
If trying to do anything model-specific in a module, you need to know the camera model (or write a #ifdef branch in a core file). I added a simple function to do this...

... but word is camera_model_short would be better suited since it doesn't need to be extended: char camera_model_short[8] = CAMERA_MODEL; ... Now, here's are my problems:

1. I don't know the names that are returned, there has to be a list so the modules can check what for example the CONFIG_5D3 equivalent is for a module

2. I never really understood how to handle strings, please give a code sample how to funnel this information from a core getter function to a module, and how to check it there. Yes, sorry, I'm not a hardcore coder, but imho this functionality should be there for the modules.

I hope someone is willing to help with this, I just invested 2 days into re-writing auto_iso as a module and figuring out a quick non-gui way to switch it, despite that the Canon fw seems to be determined the prevent any reasonable idea ... but for the heavy stuff I need help from the real devs.
I just have to ask again, sorry if it's been answered 1000x: Is there any way to speed up cropmarks rendering? With the current speed, it's too slow for me to use all the time, and esp. cycling through multiple composition overlays (thirds, golden cut, ...) takes ages.

Feel free to [WONTFIX] if this has gone into and there's no way to do it.
Problem: With the 6D, apart from multicontroller up/down (which cannot replace the 7d/5d joystick) you need to use *both* wheels to get to the af point you want to select. For me, both methods aren't very quick, I rather liked the 60D method with the wheel simply rotating through all available af points (it's only 11/9+1 after all), in practice this is quicker than using multiple buttons or wheels.

Suggestion: Forward-port the 60D selection method to the wheels (or any other method of selection that is quicker than the current 6d method, I'm open to suggestions :-)).

Edit: I solved it myself, at least partially, by enabling the af pattern point selection... single-wheel navigation is still to be done:
Currently you can +1 rate by pressing the lv button (which I cannot get to work on the 6d outside lv, though 1% says it should). Anyway:

Problem: You can only +1 rate, for decreasing the rating you have to +5 rate by clicking 5x. Plus moving the finger from the back dial/multicontroller left/right to the lv button takes a little time which does accumulate if rating 1000+ shots.

Suggestion: In addition to lv button, rate +1 with multicontroller UP, rate -1 with DOWN

Edit: ok, ok, I've done it myself :-p ...
Problem: When doing Canon or ML bracketing in M mode (like you're supposed to :-)), the files don't contain the ev spacing tag like Av/Tv files do ("AEB Bracket Value" in exiftool). This is a pity since this is very useful to display/sort hdr source images (like in Lightroom) or to use hdr software that use this value, if it's missing you have to specify it manually (like in Photomatrix).

Suggestion: Add an xmp sidecar to the cr2 that specifies the bracketing value used.
I've written something like this before (sorry for the dupe) In the mega-thread, but here it's goes again as a dedicated feature request:

Problem: With the current "dumb" +/- ev options, you're quickly running into high iso values that don't make any sense, and specifiying absolute isos makes (to me) even less sense when shooting in changing light.

Suggestions (a few more advanced options for dual_iso won't matter :-p):

1. Add a "Min. EV gain" option ... if the ev gained drops below this, do a shot w/o dual_iso

2. Additionally add a "Min. EV delta" option ... if each of the higher iso values don't add more than this ev gain, use a lower iso value instead ... this will prevent dual_iso from choosing too high values that don't add any useful dr gain

Btw there was a declined pull request about somehting like this, and I agree hardcoding iso values is not the way to do it:

Edit: deleted off-topic item about high iso differences help.
Feature Requests / dual_iso: base +/- ev option
October 01, 2013, 12:04:12 PM
I'm putting this into feature requests since I'm not such a big fan of mega threads and mixing discussion with requests:

Problem: With dual_iso being designed to lift shadows, using the original Canon metering doesn't make sense because in a high dr scene the metering will tend to the middle, i.e. clipping both blacks and whites. So with "just" turning on dual_iso you'll get blown highlights unless adding a - ec ... but that will underexpose "alternate frames only".

Suggestion: Add a "Base EC" option (like +/-1/2/3ev) that is only applied for dual_iso shots, thus you can quickly enable it and have "bracketing in one shot" for high dr scenes. The ec would modify aperture/shutter in the usual way just like bracketing does.

General Development / Button management core/modules
September 28, 2013, 10:17:56 AM
Well, I'm not much of a C coder, but I can offer some ideas - "Those who can't do, teach", you know :-p ...

Problem: With more features and modules, assignment of buttons to functions gets confusing. I'm currently writing a hotkey module for use outside lv, but keeping up do date in which situations another functions for example does something with SET is a pita.

Currently: Currently modules have CBR_KEYPRESS, and then, nobody knows what keys they intercept or what they do with them - in the core it's even worse, you can hook into the shoot task everywhere and use keys.

Suggestion: Modules (and also the core itsself, for that matter) should explicitly register keys with the core as either blocking (only they want to tie a function to it) or non-blocking (everybody else also can afterwards). For blocking functions, the core could then issue an "ok, nobody else is using it" return code or fail with a hint which other function was quicker - so if the user cannot use function 1 which wants to use SET, he/she knows what to disable. Also the "register" function should have a "override Canon" switch for taking away buttons from Canon like SET. The core could also then easily print a list of keys that do something with ml in a help menu.

What do you think - is this useful or overengineering (and anybody else wondering what his SET currently does - Canon function, ettr, af, ...)? Anybody with good C coding ability volunteering :-p ?
I think the values for shutter/apertrue/iso around the code, even if sometimes ammended with a comment, are hard to read and prone to error. I suggest replacing them with #define - there are not *that* much values after all, and if they are buried in some .h file they won't get in the way while the code will get easier to read... comments on this idea?

Edit: Also, instead of adding a numerical 8 it should be RAW_FULL_STOP or something like this... this would change this line from auto_iso

int ref_tv = 88 + 8*(aiso_av_shutter-1);

into this:

int ref_tv = RAW_SHUTTER_30S + RAW_FULL_STOP*(aiso_av_shutter-1);