CHDK Forum
CHDK Development => General Discussion and Assistance => Topic started by: srsa_4c on 01 / September / 2013, 13:16:09
-
While I was trying to find a solution to SticK's ISO problem, I started to notice magic constants in the 0x80xx range. They always seemed to appear in UI related functions. I started tracing them, and found out that there are event procedures which work with these 0x80xx IDs.
I was a bit surprised to see that these event procedures were never discussed before.
PTM stands for "Property Table Manager" as indicated by debug strings. Two of these functions are already in use by CHDK:
PTM_BackupUIProperty: SetParameterData (CHDK name)
PTM_RestoreUIProperty: conditionally calls GetParameterData (CHDK name)
The above two functions work with IDs in the 0x40xx range, and manage the "flash params" - settings which are stored in flash.
A different subset of the PTM functions works with 0x80xx IDs. They are camera dependent, and I don't know what most of them do.
In cases I have seen, the IDs are connected to certain UI elements (Canon calls these "controllers").
For example, on the a3200 (DryOS r47):
0x8021: focus mode (0 = normal, 1 = macro, 3 = "infinity")
0x800a: ISO setting (0 = auto, 1 = 80, 2 = 100, 5 = 200, ..., 14 = 1600)
On the a410 (yes, many of these event procedures are available even on the first DIGIC II models):
0x8005: ISO setting (0 = auto, 1 = 50, 2 = 100, 3 = 200)
sx100 (DryOS r23):
0x8005: ISO setting (0 = auto, 1 = hi ISO, 2 = 80, 3 = 100, 4 = 200, ..., 7 = 1600)
The current value of these UI properties can always be read (PTM_GetCurrentItem). Setting them is also possible (PTM_SetCurrentItem), but one must take care when doing so.
- values not supported in the current mode are either rejected (bit0 of the return value is set), or can even cause assert
- reading and writing unsupported IDs results in an assert
- although they seem to be well protected, it's unknown whether it's possible to enter invalid values which end up in a flash setting
- all UI properties are short integers (16bit)
- writing to these properties has an immediate effect on the UI and the underlying setting
Usually almost every setting found in the Canon shooting menu can be connected to some ID. Other settings (which are not in the shooting menu, but are available on keypress) are also have an ID - usually. A certain user interface element (like the ISO control) is always tied to the same ID.
Not all settings are part of the UI properties. The a3200 has a long shutter mode, in which one can specify the exposure time. This setting appears in a UI element that is found in the regular Canon menu, and I haven't been able to find it among the UI properties. The regular Canon menu (the one you enter with the Menu button) is not connected to this property system.
The UI flash setting appears to influence at least 3 UI properties.
The most important event procedures:
PTM_GetCurrentItem(<ID>): returns the current value of the specified UI property
PTM_SetCurrentItem(<ID>, <value>): sets the specified UI property, returns 0 when the setting is accepted
I haven't tried the following functions, but their name is descriptive:
PTM_PrevItem
PTM_NextItem
There are even more related event procedures, but I haven't done much research on them.
The PTM functions are registered with
UI_RegistDebugEventProc on old VxWorks cameras
UI.CreatePublic on newer models
Some details on usage can be found here: http://chdk.setepontos.com/index.php?topic=8801.msg104253#msg104253 (http://chdk.setepontos.com/index.php?topic=8801.msg104253#msg104253) and the followup posts.
tl;dr:
Keypress-based manipulation of the UI can be replaced by this method in some cases.
Attached patch adds another "debug data display" page to CHDK, called UIProp. It can be used to discover the IDs of UI elements. The patch is not suitable for inclusion into the official source in this - incomplete - form.
To use the patch:
- you need PRIMARY.BIN for your camera to allow the sigfinder to find the functions
- put get_uiprop_count() found in stubs_entry.S into platform/<camera>/lib.c
- on VxWorks, you need to locate PTM_GetCurrentItem, and the number of UI properties inside the PTM_SetCurrentItem firmware function (it's possible to locate them automatically of course)
Observations and corrections are welcome.
-
Excellent work :)
FWIW, the "long shutter" option uses the same USER_TV propcase as M and TV modes. I don't know if this is relevant.
If someone does manage to corrupt the flash params, some posts in this thread may be useful: http://chdk.setepontos.com/index.php?topic=5660.msg55221#msg55221 (http://chdk.setepontos.com/index.php?topic=5660.msg55221#msg55221)
-
Using chdkptp, diff and bash scripts. I mapped some properties for A810 and SX160. File in attachment.
I have not seen any option to control flash power in A810 using Canon interface, but it is possible using PTM commands.
-
Using chdkptp, diff and bash scripts. I mapped some properties for A810 and SX160. File in attachment.
I have not seen any option to control flash power in A810 using Canon interface, but it is possible using PTM commands.
Really interesting. Your findings mean that
- some settings found in the regular menu can have UI prop IDs (mute, is that the main mute switch in the Canon menu?)
- some invisible controls can be effective (flash power, I suppose that's the flash exposure compensation?)
There are separate PTM functions for mode change related purposes, but I usually ended up with a confused shooting menu after using PTM_SetCurrentCaptureMode.
I can confirm that the manual flash exposure compensation(?) does work on the a3200 in P mode (no such setting on this cam either). The ID for me is 0x8013.
edit: this setting does not get saved, camera starts with the default value next time.
-
- some settings found in the regular menu can have UI prop IDs (mute, is that the main mute switch in the Canon menu?)
Yes, it is the main mute switch in the Canon menu.
Some UI properties found in A495 (DryOS r43). Mute works here too.
-
Updated patch attached. Complete sigfinder support (Vx, DryOS), the new feature is available on all ports.
I have added a new macro named "FW_CONST" to stubs_asm.h, which enables the sigfinder to output a ready-to-use constant (so no per-camera edits are needed). The particular constant in this case is the number of UI properties, which only appears as immediate constant in the firmware (impossible to use the DEF macro).
The current goal of the patch is to add the new debug display as mentioned in the opening post.
Further possibilities include (after camera-specific research):
- switching between drive modes (single, continuous, etc)
- correctly enabling/disabling native RAW ( ;) (http://chdk.setepontos.com/index.php?topic=11819.0))
This method won't enable getting/setting native Tv, Av, subject distance, (...) values, unfortunately.
I'm thinking about committing this unless somebody convinces me not to :)
I'm also open to suggestions.
-
I'm thinking about committing this unless somebody convinces me not to.
Would it make more sense to add this to 1.4.0 when 1.3.0 finally rolls over to being called stable ? It's so close to stable now we might want to consider a "code freeze" ?
-
I'm thinking about committing this unless somebody convinces me not to.
Would it make more sense to add this to 1.4.0 when 1.3.0 finally rolls over to being called stable ? It's so close to stable now we might want to consider a "code freeze" ?
There's a huge pile of changes/features scheduled for 1.3 (see http://chdk.setepontos.com/index.php?topic=10459.msg113546#msg113546 (http://chdk.setepontos.com/index.php?topic=10459.msg113546#msg113546) and the followup posts), this one is really simple compared to those. But I noted your objection.
-
But I noted your objection.
It was more of a suggestion than an objection. And maybe a little nudge towards reyalp (who I know has been working on that list).
-
Would it make more sense to add this to 1.4.0 when 1.3.0 finally rolls over to being called stable? It's so close to stable now we might want to consider a "code freeze" ?
I read this thread and know to little about the internal workings of things to judge the suggestion of WWZ but I figured a suggestion / question might still be helpful.
The current goal of the patch is to add the new debug display as mentioned in the opening post.
Further possibilities include (after camera-specific research)
I suppose the main purpose is the aquisition of information that isn't yet available by using the new debug display on various cameras. Well, the question is do you know what information you'd like? Can you give a sound step by step of what to collect / can the information be collected by a script. If I know what I'm getting into by suggesting this I might suggest to just execute the data gathering on the 80 camera models I currently own. That I could do by compiling a patched trunk for all cameras in question so you might get the data you're interested in even though this isn't commited yet. If you do commit it I might still do what I outlined but like I said I'd like to know what I'm getting myself into first :D
Edit: I have no camera capable of a native RAW at this point so I'll be no help on that...
-
And maybe a little nudge towards reyalp (who I know has been working on that list).
As far as I understand it should have no affect on stability unless you turn on the debug display, so I have no objection.
This definitely seems like useful work.
-
And maybe a little nudge towards reyalp (who I know has been working on that list).
As far as I understand it should have no affect on stability unless you turn on the debug display,
It gets worse. I decided to add another debug tool by re-using the routine that is responsible for the "CmpProp" debug feature. That should speed up finding the IDs.
New patch attached.
-
The current goal of the patch is to add the new debug display as mentioned in the opening post.
Further possibilities include (after camera-specific research)
I suppose the main purpose is the aquisition of information that isn't yet available by using the new debug display on various cameras. Well, the question is do you know what information you'd like?
There are several camera settings that can't currently be set by CHDK. For example, there's a function (http://chdk.wikia.com/wiki/Script_commands#get_drive_mode) for querying the "drive mode", but (AFAIK) the only way to change the setting is to use the Canon controls (by hand or by scripted keypresses).
Can you give a sound step by step of what to collect / can the information be collected by a script.
Considering the above and the fact that the UI of various cameras is different, automated scripts are not feasible.
What to collect: per the above example, the ID of the Canon drive mode and the values corresponding to its settings.
On the a3200: ID is 12, 1 for continuous drive, 0 for single shot
Due to the nature of these IDs (camera model dependency), new CHDK features building upon PTM functions will be enabled only for tested models.
You can start collecting this kind of information if you want, but there's no hurry as the info won't be used right now.
-
Due to the nature of these IDs (camera model dependency), new CHDK features building upon PTM functions will be enabled only for tested models
These features are the kind of things I was thinking about when I suggested pushing this off to be part of 1.4.0
-
Due to the nature of these IDs (camera model dependency), new CHDK features building upon PTM functions will be enabled only for tested models
These features are the kind of things I was thinking about when I suggested pushing this off to be part of 1.4.0
There aren't any such features planned at the moment.
What the patch does is:
- identifies a few functions that will be useful later
- determines the UI property count
- adds debug facilities that help future research
I'm not pushing this, if its impact feels too big, it will be added after 1.4.
Here's a poor howto on usage:
Miscellaneous stuff -> Debug parameters -> ALT +/- debug action -> [CmpUIPr]
The UI properties will be sampled when the "debug shortcut" button is pressed in ALT mode.
The debug shortcut is usually one of the following buttons:
- "erase" (if it's not one of the directional buttons)
- DISP (if there is a separate DISP button)
- a button which is not a directional button, not SET, not MENU; for example the video (aka movie) button
In some cases there is no button assigned for this.
From the second sampling on, differences to the previous sample will be listed on screen.
This listing may conflict with CHDK on-screen elements, you may want to switch those off.
If you're hunting a specific setting: make sure you only change the desired setting.
For example, the vertical cursor position in the shooting menu has its own ID, but it is obviously not much of interest.
The IDs and values will be printed in decimal.
If somebody wants to use the IDs with the PTM_SetCurrentItem eventproc:
Add 0x8000 to the ID (you need to convert the decimal ID to hex). Only 2 exception is the ixus30 and 40 which use native IDs starting from 0.
-
Good work. I vote for a fast integration in version 1.3. It's a small debug function. But it's helps to make UI function easier for scripts (depends of the camera). So we can also collect informations about the different cameras for future tasks.
msl
-
I'm not pushing this, if its impact feels too big, it will be added after 1.4.
Good work. I vote for a fast integration in version 1.3. It's a small debug function. But it's helps to make UI function easier for scripts (depends of the camera). So we can also collect informations about the different cameras for future tasks.
To clarify, I agree with everyone else that the patch be added to 1.3.0
What I was trying to say (badly) was that the follow-on new features / script function / UI changes etc that may use this new capability should be part of 1.4.0
Which is what I think you are saying too?
-
the follow-on new features / script function / UI changes etc that may use this new capability should be part of 1.4.0
Which is what I think you are saying too?
Yes.
-
See UI properties for Ixus 160 in attachment (tab separated file)
But I didn't find properties for:
Tools: Lens Retraction
Tools: Power Saving: Display Off
Tools: LCD Brightness
Tools: Start-up Image
Tools: Create Folder
Tools: Video System
Tools: Language
Probably, c6 is not latest property for Ixus 160 ?
-
Here's a poor howto on usage:
Not sure it is so poor...anyway, I spent a little time building from srsa_4c's patch above but, based on msl's kind pointer here http://chdk.setepontos.com/index.php?topic=12428.msg123114#msg123114 (http://chdk.setepontos.com/index.php?topic=12428.msg123114#msg123114), still wasn't able to do / discover anything useful on my sx150is (I haven't had much time to dwell on investigation though).
If a slightly more comprehensive "howto" were to appear that would be a welcome hand up - getting away from some key-presses might be nice/useful.
-
But I didn't find properties for:
Tools: Lens Retraction
Tools: Power Saving: Display Off
Tools: LCD Brightness
Tools: Start-up Image
Tools: Create Folder
Tools: Video System
Tools: Language
A significant amount of UI settings seem not to be covered by these properties.
Probably, c6 is not latest property for Ixus 160 ?
I did not check this, I don't know. I have however seen cases where one of the firmware's property-like systems had "special cases", IDs in an unusual range. I don't remember if those were "UI properties" or not.
Why not to create standard Lua functions for UI properties, like http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page (http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page) ?
That would be the plan sometime later...
But note that the nature of these properties makes their use difficult (they tend to be different in each camera model). The ideal solution would be an abstraction layer, but I don't see the huge amount of contributors that would make it possible...
I spent a little time building from srsa_4c's patch above but, based on msl's kind pointer here http://chdk.setepontos.com/index.php?topic=12428.msg123114#msg123114 (http://chdk.setepontos.com/index.php?topic=12428.msg123114#msg123114), still wasn't able to do / discover anything useful on my sx150is
Both current "stable" (1.3) and development (1.4) releases have the UI property research tool, the patch is no longer needed...
If a slightly more comprehensive "howto" were to appear that would be a welcome hand up
My poor English skills usually fail when I try to explain something in detail. So, indeed, an improved howto would be really useful.
-
But note that the nature of these properties makes their use difficult (they tend to be different in each camera model). The ideal solution would be an abstraction layer, but I don't see the huge amount of contributors that would make it possible...
I don't think abstraction level is possible at all, since different models contain a little bit different set of settings, and modes. But these properties will be very usable for individual cameras. If we will have good tool for values investigation, it can be useful.
2andrew: I can send my own tool for UIProperties values investigation. It uses USB connection to camera. Theoretically, this very simple code can be included into chdkptp.
-
Some fixes in properties list in the attachment(800d and defaults)
BTW, shouldn't we create some place in wiki/svn/git for upload such files ?
-
2andrew: I can send my own tool for UIProperties values investigation. It uses USB connection to camera. Theoretically, this very simple code can be included into chdkptp.
alex73, i'd really appreciate that :)
-
So, for run my test utility you need:
1. Download chdkptpJ-0.1.zip from https://github.com/alex73/chdkptpJ/releases (https://github.com/alex73/chdkptpJ/releases)
2. See http://usb4java.org/faq.html (http://usb4java.org/faq.html) for setup your Windows/Linux box for using usb4java/libusb
3. Run from command line by command java -cp * TestUIProperties
It should work, but you know - this library is too young. Feel free to ask if something will be wrong.
-
Downloaded (&bookmarked).
Will report back when I get a chance.
Thanks.
-
But note that the nature of these properties makes their use difficult (they tend to be different in each camera model). The ideal solution would be an abstraction layer, but I don't see the huge amount of contributors that would make it possible...
BTW, even without identify all UI properties for specific camera, we could implement something like "save full state". That means, some software will just read all properties values into file, then wil "restore state", i.e. will read file and set all properties.
-
BTW, even without identify all UI properties for specific camera, we could implement something like "save full state". That means, some software will just read all properties values into file, then wil "restore state", i.e. will read file and set all properties.
Did you try doing this? I'm not 100% certain that setting so many unknown properties (or even just the known ones) at once is safe. The success might depend on the camera's current settings/state.
About abstraction: due to differences between camera generations, these properties should probably be manipulated by separate script functions. For camera-specific use, we could introduce generic functions like set_uiprop() and get_uiprop().
-
Did you try doing this? I'm not 100% certain that setting so many unknown properties (or even just the known ones) at once is safe. The success might depend on the camera's current settings/state.
Not for unknown. But I changed almost all properties in camera, then run settings from file that contains all known properties - works good. As second option, we could have some user-friendly interface for investigation.
-
As second option, we could have some user-friendly interface for investigation.
Do you have a suggestion?
-
As second option, we could have some user-friendly interface for investigation.
Do you have a suggestion?
For example, my command-line java utility. Some GUI could be added. Or, I can implement it for chdkptp.
Edit: IMHO, it shouldn't be so hard to implement some interface on the camera side: just remember options on startup, then display difference after some button will be pressed.
-
alex73, here's what I tried to get the java utility working...
I already have libusb-win32-1.2.6.0 installed on this Win7 machine.
I therefore assumed that no action was necessary when http://usb4java.org/faq.html (http://usb4java.org/faq.html) says "How to use libusb on Windows" (with link to https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows (https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows))
Do you know if that is correct?
Java 7 update 60 (build 1.7.0_b60-19) is installed on this machine. When I double click "chdkptpJ-0.1.jar" nothing happens (operator error ?)
File structure attached.
-
For example, my command-line java utility.
Did not try it yet.
it shouldn't be so hard to implement some interface on the camera side: just remember options on startup, then display difference after some button will be pressed.
Such interface already exists. It needs 'paper and pencil' though and stops being user friendly when the number of changes exceeds the amount that fits on one screen. Hint: Miscellaneous stuff -> Debug parameters -> ALT +/- debug action -> CmpUIP.
@andrew.stephens.754365
alex73 mentioned that the utility is a command line one (it has no GUI), you need to start it from a command line window.
-
...you need to start it from a command line window.
:-[
I just tried this in Win "Run":
C:\chdk-PTM-utility\chdkptpJ-0.1.jar java -cp * TestUIProperties
No joy yet...stackoverflow next stop.
-
Sorry, I missed these messages.
I updated util for GUI show.
You just need to download https://github.com/alex73/chdkptpJ/releases/download/v0.2/ui-properties-check.zip, then unpack all files from it, then run ui-properties-check.jar(double click in Windows)
A495/100f properties list attached (tab-separated file).
-
no worries alex73...will try to try again asap. Thanks.
-
Is there any way to know min/max UI property index for specific camera ? By call some function or analyze CHDK code ?
-
Is there any way to know min/max UI property index for specific camera ? By call some function or analyze CHDK code ?
stubs_entry.S, uiprop_count
Note that it's called _count, so the max index will be one less.
This does not include extra properties which some cameras seem to have.
-
no worries alex73...will try to try again asap. Thanks.
Apologies for the long delay - I ran this very recently and get a "no cameras connected" message.
It's probably better I understand the process a bit better anyway.
To that end, I reverted to this http://chdk.setepontos.com/index.php?topic=8801.msg104253#msg104253, (http://chdk.setepontos.com/index.php?topic=8801.msg104253#msg104253,) and using chdkptp determined sx150is properties as follows:
CurrentItem 0x800a (ISO)
Current_Item_Value Parameter_Value Test_Mode
0 Auto Av
1 80 M
2 100 M
5 200 M
8 400 M
11 800 M
14 1600 M
I'd prefer to control at least the shutter period in a similar manner but wasn't really sure how to proceed. So, for "Current_Item" from 0x8000 to 0x8081 I ran the hastily scribed & very blunt attached script (as an addition to multicam.lua).
Here is the result:
Current_Item|Current_Item_Value
0x800a|11
0x800b|0
0x800c|0
0x800d|0
0x800e|0
0x800f|0
0x8010|0
0x8011|12
0x8012|12
0x8013|6
0x8014|9
0x8015|2
0x8016|0
0x8017|0
0x8018|0
0x8019|1
0x801a|0
0x801b|1
0x801c|3
0x801d|1
0x801e|2
0x801f|0
0x8020|1
0x8021|0
0x8022|0
0x8023|65535
0x8024|0
0x8025|65535
0x8026|1
0x8027|4
0x8028|0
0x8029|0
0x802a|0
0x802b|0
0x802c|1
0x802d|0
0x802e|0
0x802f|1
0x8030|1
0x8031|0
0x8032|0
0x8033|1
0x8034|0
0x8035|0
0x8036|0
0x8037|0
0x8038|1
0x8039|1
0x803a|0
0x803b|1
0x803c|1
0x803d|0
0x803e|1
0x803f|0
0x8040|1
0x8041|1
0x8042|0
0x8043|0
0x8044|0
0x8045|0
0x8046|1
0x8047|0
0x8048|1
0x8049|0
0x804a|0
0x804b|1
0x804c|0
0x804d|1
0x804e|1
0x804f|0
0x8050|1
0x8051|65535
0x8052|1
0x8053|65535
0x8054|0
0x8055|0
0x8056|0
0x8057|1
0x8058|1
0x8059|1
0x805a|1
0x805b|0
0x805c|0
0x805d|0
0x805e|1
0x805f|1
0x8060|0
0x8061|2
0x8062|3
0x8063|1
0x8064|1
0x8065|1
0x8066|1
0x8067|0
0x8068|0
0x8069|1
0x806a|1
0x806b|1
0x806c|0
0x806d|0
0x806e|65535
0x806f|0
0x8070|65535
0x8071|65535
0x8072|1
0x8073|1
0x8074|0
0x8075|65535
0x8076|65535
0x8077|1
0x8078|0
0x8079|18
0x807a|2
0x807b|2
0x807c|2
0x807d|2
0x807e|1
0x807f|1
0x8080|1
0x8081|0
(a) Should it be safe to run script:
call_event_proc("PTM_SetCurrentItem",Current_Item,Current_Item_Value) against all non zero "Current_Item_Value" values in this list?
Is a reasonable method to attempt identification of the "Current_Item" related to shutter period:
(b) manually change the existing shutter period (from that reported in the table above - assuming it is an item in the list)
(c) sequentially run each non zero "call_event_proc("PTM_SetCurrentItem",Current_Item,Current_Item_Value" until I visually see the shutter period change in the Canon display?
and
(d) is there special significance to the "65536" Current_Item_Value entries?
-
So,
I ran my script then changed the camera to continuous mode and reran the script.
After comparing the 2 output files (in Excel) it transpires that 0x800c Current_Item_Value changes from 0 to 1 & call_event_proc("PTM_SetCurrentItem",0x800c,0) / call_event_proc("PTM_SetCurrentItem",0x800c,1) work as expected.
Using the same approach for shutter period (changing shutter between one tenth & one thirteenth) and for zoom (chaning zoom by one step) results in no change.
My script was written to include 0x8000 to 0x8081
Can I try to expand that range in order to identify the relevant CurrentItem for shutter period / zoom (or is it likely they just don't exist for this camera)?
-
Can I try to expand that range in order to identify the relevant CurrentItem for shutter period / zoom (or is it likely they just don't exist for this camera)?
No need to expand the search. To quote myself (http://chdk.wikia.com/wiki/User:Srsa_4c/UI_properties):
Not all UI elements have properties (examples of these: zoom, focus, Av, Tv values)
Oh, and setting unknown properties blindly can lead to camera crash due to asserts.
-
Useful link.
Thanks.
-
srsa_4c,
have you ever tried setting continuous mode on a VxWorks?
Just tried id 0x8007 on an A620 and it crashes the cam.
Edit: However, the IXUS850is does work.
-
srsa_4c,
have you ever tried setting continuous mode on a VxWorks?
Just tried id 0x8007 on an A620 and it crashes the cam.
Edit: However, the IXUS850is does work.
Tried 3 Vx cameras, works on all 3 (and the ID is 0x8007 on all 3).
Did you make sure it's the correct ID on the a620? Can you get a romlog (http://chdk.wikia.com/wiki/Debugging#Camera_crash_logs_.28romlog.29)?
-
The problem seems to have been caused by temporarily not having the usual amount of memory available. Once that was fixed, everything works fine.
Thanks.
-
srsa_4C,
registering procedures seems to consume a large amount of memory - have you any idea what could be involved?
-
registering procedures seems to consume a large amount of memory - have you any idea what could be involved?
It's normal for some of the registration calls to consume a significant amount of memory. You can make your script call get_meminfo('system') after each registration call to see how much.
You may be able to call the ones you want directly by address instead, using call_func_ptr(). However, in some cases the arguments need to be passed differently, because the eventproc system does some auto-magic translation.
-
Ok...thanks for that.
-
For years I've been using set_prop to configure the aspect ratio in my scripts like this:
--SX60 Props 304 & 399 Aspect Ratio (0=4:3, 1=16:9, 2=3:2, 3=1:1, 4=4:5)
set_prop(require("propcase").ASPECT_RATIO, 0)
Unfortunately the camera's UI does not reflect this change, so the viewfinder crops the display differently to the images captured. Worse, switching to Play and back to Record loses the change completely. Looking for a better way I tried your excellent CmpUIP feature, which uncovered this UIProp:
--SX60 UIProp 26 Aspect Ratio (0=16:9, 1=3:2, 2=4:3, 3=1:1, 4=4:5)
Interestingly those values do not match the Prop values but they do align with their order in the Canon menu. So I thought great, I'll just set that in my script:
set_uiprop(26, 2)
But the function does not exist! I couldn't understand why the Debug menu let me discover UIProps that I can't get or set. Searching for this obvious function name lead me to this thread, where after reading all 5 pages and digging through several more wiki articles, I finally got it working like this:
--register PTM_* functions
call_event_proc("UI.Create")
--set UIProp 26 to 2
call_event_proc("PTM_SetCurrentItem", 0x8000 + 26, 2)
Upon running that code, the camera's UI instantly updates to 4:3 and sets Props 304 & 399 to 0. Better yet, it survives switching modes and even restarting the camera, which I guess is the reason you guys are scared to implement it. To that end, I tried passing an invalid value of 5 and the camera crashed immediately. It came back up fine though, so I believe such fears are exaggerated.
About abstraction: due to differences between camera generations, these properties should probably be manipulated by separate script functions. For camera-specific use, we could introduce generic functions like set_uiprop() and get_uiprop().
So my question is, can you guys please introduce the scripting functions get_uiprop and set_uiprop that srsa_4c suggested over 1 year and 4 months ago? You've already done all the hard work, it's time to make it official. This technology will eliminate the need for all sorts of slow and unreliable button-pushing scripts, as well as allowing scripts to read UIProps that do not have a corresponding Prop (eg AF Frame Size) :D
-
To that end, I tried passing an invalid value of 5 and the camera crashed immediately. It came back up fine though, so I believe such fears are exaggerated.
Interesting test. Although it's hardly exhaustive. Different values than 5 or different function codes could still cause permanent problems?
So my question is, can you guys please introduce the scripting functions get_uiprop and set_uiprop that srsa_4c suggested over 1 year and 4 months ago? You've already done all the hard work, it's time to make it official. This technology will eliminate the need for all sorts of slow and unreliable button-pushing scripts, as well as allowing scripts to read UIProps that do not have a corresponding Prop (eg AF Frame Size) :D
I guess the short answer might be that you already have the ability to use this functionality - as your post shows. Making it a built-in function really thus just provides a typing convenience. But maybe it also opens the door for a naive person learning to script getting themselves into trouble?