How to detect the camera models from a module (code sample please)?

Started by Marsu42, October 06, 2013, 06:42:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Marsu42

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...

https://bitbucket.org/Marsu42/ml-aiso/commits/2a3c70033184ebf9810f976462bfad55600f509e#chg-src/module-glue.c

... 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.

a1ex

1) Modules should be portable by design, so if these camera-specific tricks are avoided or abstracted in the core API, that's better IMO. For example, you could have a function to know whether your camera can do X, and if so, just use X. If not, fallback to some other method, disable that feature or whatever you think it's best.

Example: old cameras can't control shutter and ISO in LiveView for every single frame, and this can be exploited by ETTR to converge 2-3 times faster. So, if the core reports "this camera has these capabilities", ETTR uses them. If not, it uses a slower method, that still works, even if it takes 10 seconds instead of 3.

static void auto_ettr_step_lv()
{
    if (can_set_frame_iso() && can_set_frame_shutter_timer())
        auto_ettr_step_lv_fast();
    else
        auto_ettr_step_lv_slow();
}


Advantage: if you find a method to port this capability to a camera that doesn't have it yet, the module will just work without any effort from your side.

Weak functions are a possibility to implement this (if that function is not found in core, the call will do nothing and return 0).

So, the method for camera-specific behavior is clunky and part of the reason is to discourage its use. But yeah, sometimes you don't have a obvious way to do it better, so it's there.

2) dual_iso.c, adtg_gui.c

Marsu42

Quote from: a1ex on October 06, 2013, 07:04:49 PMModules should be portable by design, so if these camera-specific tricks are avoided or abstracted in the core API, that's better IMO.

I absolutely agree, but for some cases ... just now I wanted to add a warning that a specific feature doesn't work on the 6d, the core doesn't indicate it (the return value can be 0 because it's 0 or because the function is missing) - so I have to hardcode it into a module for the time being, or of course add another flag macro to the 6d const.h

a1ex

A weak function can return anything you want btw (you just provide a default implementation instead of ret_0).

Marsu42

Quote from: a1ex on October 06, 2013, 07:41:42 PM
A weak function can return anything you want btw (you just provide a default implementation instead of ret_0).

I've not circumvented the whole problem by adding another meta-#define to the platform code so I can detect if a feature is working or not - probably the cleaner solution other than platform branches in the modules anyway.

Btw: I suggest adding this meta-defines (#define FUNCTION 0 -> add #define FUNCTION_IS_NOT_ACTUALLY_WORKING) right away for new cameras when some addresses and so on aren't figured out yet.