This is an important issue, currently it's a mess and AFAIK the modemap is not correct for all cameras.
Correct, quite a few have 1-N or whatever. These are:
a610, a620, a630, ixus_40, ixus_50, ixus_55, ixus_65, sd_500, ixus_750, s2_is, and a540 (until my patch gets merged)
Also, get_prop in ubasic gives different values for the modes compared to the modemaps (it returns negative numbers correctly unlike whatever memory browser that's used to get the modemap when porting).
I just turned on the propcase viewer and went through all the modes.
ubasic should expose the chdk numbers (and attributes flags if my system is adopted), rather than making scripters depend on figuring out the propcases. Of course, the propcases would still be available. I'm not sure why ubasic would return negative numbers, unless it's treating them as signed shorts.
But we can't just group the modes this easily, because the features in those modes are not the same for each camera model. For example, I hear TX1 has a very automatic M mode. Similarly the automatic modes differ a lot from each other, from a570is I know P/AUTO/SCN/others are very different from each other when it comes to availability of ISO, Ev compensation, white balance and focus settings etc.
This will always be a problem to some extent. However, most of the current code doesn't seem to care too much. If it does, we may have to figure out how to query the actual settings, or manually figure out each mode.
I agree that the mode names or enumeration is not a good way for portability, especially since the same name may not offer the same features on all models. The good news is that AFAIK pretty much no code in CHDK uses the modemap, so nothing should break if it's changed(?).
There's quite a bit of code that looks at it, and more in the collab build. AFAIK, the things checked are:
1) video or still (used to pick various OSD things, video specific over-rides, and a few other things)
2) manual, Av, Tv: for bracketing and a couple other things
3) stitch mode. I'm not completely clear why this is special cased, but my guess is that it's due to the different display layout not working with things that read the display.
But I do believe there should be a modemap that has each and every mode the camera can be in.
Agreed, and all my suggestions would preserve the existing mode system completely. It would just provide an easier to maintain way of checking for common attributes.
But for use in CHDK code and script code there should be a set of parameters that describe these modes in a portable way, among them information which settings can be altered (at least Av, Tv, Sv, WB, Ev comp, flash mode, metering mode, color mode, focus, video).
True, but a bit beyond the scope of what I've done so far.
So your 2) is what my vote goes to I suppose, but it needs to be extendable.
1-3 are all part of what I've done. Thus far, all I've dealt with is the actual PROPCASE_SHOOTING_MODE values.
One thing that might be worth investigating is that the cannon values seem to follow a pretty clear patter:
Most regular mode dial modes start at 32768, and the numbering is at least fairly consistent:
32768+
0 = Auto
1 = Manual
2 = Av
3 = Tv
4 = P
If one is missing on a camera, there is just a gap in the numbers.
SCN modes start around 16400
Video modes start around 2590
Stitch around 33290
Some of the other special submodes also seem to be in 33****, on the propset2 cameras.
Given that the basic modes seem to be consistent (from a quick look, I don't see any that are different for the basic modes), we could actually make a default mode map that gets most of the common ones correctly.
As for video modes, I don't know. We mustn't lose the video submode information of the A series, but I really don't know how the S series and TX1 video settings work. Maybe a framerate resolution fields and an "available in still shooting mode" bit?
From what I understand (from reading dpreview
) the "video" setting on the S cameras just makes the func menu go to your video settings. Otherwise, every mode is both video and still. I'm not clear which still settings would be used if you shoot a still in video mode.
Another issue is that changing the mode to say "compact" using left/right changes the resolution, but I can also change the resolution using the func menu in standard mode, and this doesn't change the mode number.
Whew, another obscenely long post
