camera modes, dev feedback requested

reyalp

14118

camera modes, dev feedback requested

« on: 10 / August / 2008, 19:26:25 »

Advertisements

Related to the patch I posted here: the collaborative CHDK build

There are some issues with the current way camera modes are used and dealt with.
1) some cameras (s3is etc) allow the user to shoot still or video in any mode. This means another method is needed for checking whether video specific stuff should be done. video_status should work, except for where we are manipulating it on the fly. When doing that, we either need to find another value or check whether tMovieRec is active.
Maybe there's a better way to pause recording than diddling movie_status. Trying to just keep track of whether recording has been started, stopped or paused doesn't look very practical.
2) the modes enum is clumsy. There are at present 50+ values, and things like KIDS and SPORTS and all the MYCOLORS sub modes really aren't meaningful to most CHDK code. The most common checks seems to be
- is it a video mode (but this has problems, per above)
- is it a still mode
- is it a full manual mode
- is it Tv or Av mode
- is it a full automatic mode
3) the above leads to quick code rot, because someone adds a value to the enum, but doesn't change all the conditionals that use it.
The unused is_mode_photo in a540 suggests I'm not the only one to see room for improvement. Jucifer suggested this is something ewar did ?

My thought is
- there should be a way to get the characteristics above without checking all the mode values. It should be maintainable in one place, and require a minimum of per camera changes. The attributes of the mode (i.e. video, etc) should be defined along with shooting prop -> mode mapping, since anyone updating that will be in a position to know what the attributes of each mode are.
One way to do this would be to:
1) add a bitfield to mode, e.g. MASK_MODE_ATTR with bits MODE_ATTR_VIDEO MODE_ATTR_MANUAL etc. Probably no more than 5-8 are required.
2) add a third field to the mode_map array for each camera, which sets the relevant flags for each mode. This can be aided with some simple macros
3) optionally, add macros or platform independent functions to check for common combinations.

It's not entirely clear the best way to deal with cameras that do both video and still in this. It may work to just indicate whether the mode is video or still capable (so cameras like the s3is would just set both for every mode).

Another way would be just to make some functions (or macros) that check the various enum values, like my MODE_IS_VIDEO or is_mode_photo mentioned above.

I am willing to code this if people think it is a good approach, or consider alternate suggestions.

Apologies for the long post, feedback appreciated.

edit:
Attached preliminary implementation, patch against trunk. Only a540 and s3is are converted to the new system, but doing more cameras is easy. Comments in platform.h and platform/generic/main.c tell you everything you need to know.

Not entirely sure about which characteristics should have their own flags.

mode-attrs-1.patch (20.16 kB - downloaded 74 times.)

« Last Edit: 11 / August / 2008, 04:51:14 by reyalp »

Logged

Don't forget what the H stands for.

fudgey

1705
a570is

Re: camera modes, dev feedback requested

« Reply #1 on: 11 / August / 2008, 06:14:15 »

This is an important issue, currently it's a mess and AFAIK the modemap is not correct for all cameras. 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).

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.

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(?).

But I do believe there should be a modemap that has each and every mode the camera can be in. 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).

So your 2) is what my vote goes to I suppose, but it needs to be extendable.

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?

Logged

reyalp

14118

Re: camera modes, dev feedback requested

« Reply #2 on: 11 / August / 2008, 15:24:32 »

Quote from: fudgey on 11 / August / 2008, 06:14:15

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)

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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

Logged

Don't forget what the H stands for.

fudgey

1705
a570is

Re: camera modes, dev feedback requested

« Reply #3 on: 11 / August / 2008, 16:05:22 »

Quote from: reyalp on 11 / August / 2008, 15:24:32

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.

ubasic doesn't care which propcase you read/write with get/set_prop. There are several exposure related properties (probably others, but this is the example I remember) that are clearly signed so I guess this is why someone originally decided get/set_prop should be signed. The most important ones can of course be accessed to an extent with commands like get/set_tv, but probably not all and some of these commands still have the zero bug which makes them unusable for some scripts, and also some of the set_ commands use the "later" mechanism which without accurate documentation makes them harder to use (to me) than set_prop (actually I dug deeper into the practical workings of exposure properties a while back and wrote what I found down but never finished it... should probably post that one day).

I suppose some properties are better shown as signeds and others as unsigneds, but in my opinion ubasic must show properties as signed as it does. The problem here is that get_prop is the only way to access the modemap in trunk ubasic.

IMO, any property that's useful needs it's own script command to make scripts portable anyway and that command can then choose to represent the property in whatever manner best fits. And as you've found, doing this for the modemap is not simple with all these different camera models and their differing exposure parameters.

Logged