Developer-friendly / experimental branch (dataghost)

[DataGhost]

Read carefully and do not use any of these functions if you do not know what they do. Some could crash the camera, others could even damage it. Use extra caution when your camera isn't listed as (fully) supported in the list near the bottom of this post, undefined behaviour is to be expected and there are little to no safety checks.
As you might expect, I am not responsible for any damage done to your camera. Use this software at your own risk, you have been warned.

Since I completed the S5IS port, I've mainly been busy (whenever I had the time) with finding new features. I ended up with a cluttered heap of junk which would basically allow just one feature to be compiled-in at a time. It also wasn't a very friendly way to share my findings with others so they could comment on them, so I decided to put these changes nicely together in a branch, with an extra menu and everything. It's currently still a bit disorganized but good enough for non-mainstream stuff

Anyway, let's share a few ideas, some of which are already features in the branch:
- Control over the shutter, to quickly make a dark frame or do other cool stuff with it. (barely implemented)
- Control over the display, to conserve battery life and allow more brightness settings (reasonably implemented, needs fixing)
- IS Lens adjustments. On my S5IS, the lens is offset a bit and after quite some research I came up with a way to properly center it. The camera has a built-in 'center IS lens' function, but that centers the IS lens at the IS lens center point, which is not the camera lens center point (or so it seems). It's possible to manually adjust the IS lens (implemented) and to automatically center it (not implemented in this branch yet).
- Also in the category IS Lens adjustments: Using the camera as an input device. Two demos are implemented, a simple one which draws a line that's always more or less horizontal (with respect to the horizon, not the camera) and a very simple and basic racing game.
- A sophisticated hex viewer with a lot of features. Barely implemented, though, it'll probably take a lot of time.
- Alternate keymaps (not implemented)
- Dual LCD (not implemented)
- Realtime camera log (displays to screen and to file)
- Simple profiler
- Probably a lot of other features which are not important enough to list here. The document with notes in shorthand is about 6 kB large.

I'll be using this build to test new features and get feedback on them, so I can improve them and see how people like them... they might make it into the main trunk some time Please feel free to suggest new things but try to keep them slightly on-topic (as far as possible), since there's also a 'feature request' board, which is more suitable for generic feature requests.

Anyway, please keep in mind that I only have a S5IS 1.01b, so that's the only camera on which the majority (if not all) of these functions work (sorry, folks). A 1.01a port should be easily possible, it might be trickier for other cameras. Feel free to submit your changes/proposals and I'll merge them if they're any good.
I might be able to come up with signature files to automatically add support for other cameras, but still a few of these experimental functions might behave quite differently on other cameras, so it's best if a developer actually checks them out and tests them.

No binary version available yet, source is available in SVN:
svn co https://tools.assembla.com/svn/chdk/branches/dataghost
Commit log: /branches/dataghost (log) - chdk - Trac

Out-of-the-box supported platforms:
S5IS 1.01b
A620 1.00f *

* Compiles, no IS functions, no LED messages, no display on/off controls, no brightness options (these are likely to crash the camera or do other bad things, do not use unless you know what you are doing)


Sample videos:
Camera orientation demo
Camera default IS lens centering function
My improved IS lens centering function
Adjusting the display brightness
Viewing the camera log
Simple racing game, using the same input as the 'camera orientation demo'
LED disco


I hope you like it

[fingalo]

So cool ,
really creative use of the camera features in the racing game! This would trigger even more new ideas!

[PhyrePhoX]

you just made my day.
if i had 10 hands, i would put all their thumbs up right now.
too bad i own an s3is

[Microfunguy]

Very interesting.

Too bad I do not have an s5is.

Is the orientation sensor fairly accurate if you want to level your camera ?


With a pair of cameras for stereo, sensor offset causes vertical errors that have to be corrected in post-processing.

I will look at your code .. presumably with IS cameras it should be possible to adjust one camera so that they both point to exactly the same point in a vertical direction  ?


David

[PhyrePhoX]

wait a second, did you use the orientation sensor for the two demo videos (game & orientation demo) or the IS mechanism (well, maybe the IS mechanism does use the orientation sensor).
the IS mechanism can only measure "relative movements", right? while the orientation sensor measures "absolute" things. did you manage to to readout more states than "0,90,180... degrees"? again, great stuff.

[Microfunguy]

did you manage to to readout more states than "0,90,180... degrees"?

On my A620, the property case for 0 and 180 degrees is different.

On some cameras they are  identical.


David

[DataGhost]

No, it isn't that accurate. Sometimes it's angled a bit even when it's on my desk. Also, when you shake the camera and place it back, it might be offset a bit. I think it uses gravity and isn't friction-free, since I haven't been able to influence it with strong magnets. That's why I'm using such a 'large' dead zone in the game thing.

Also, after reading PhyrePhoX' post, I had a quick peek inside the S3IS firmware. It seems to have quite a few of the GetIS functions but not the ones I'm using to read the orientation sensor, so it may not be possible on (many) other cameras than the S5IS. On the S5IS, most of the IS functions all seem to talk to the same (two, one returns short and the other returns char) function with a different argument. On the S3IS they appear to all have the necessary functionality embedded or they just look very different. The lens unit is the same so it should be possible, but it'll take a while before I can identify the code responsible for reading this value (especially without S3IS).

PhyrePhoX: the value of _GetISEViAaxis() looks like a fixed-point sine function ranging from -180 to 180 degrees, corresponding with the camera angle relative to the ground. _GetISEViBaxis() looks the same but this time it's a cosine. That's how I'm getting the orientation. As I said above, it's not very accurate. I'll quickly hack together the orientation demo and the EVi axis things from the IS sensor and create a short movie to show you what I mean and also to show the inaccuracy.

[Microfunguy]

This is slightly off-topic so I will either send you a personal message sometime or post a new thread for a detailed reply.

For now, I will just ask, how do you work-out how to pass parameters to and from firmware functions ?



David

[DataGhost]

Generally, the compiler passes on function arguments as R0, R1, R2 and R3. If more arguments are required, they're first pushed onto the stack. The function return value is stored in R0. Determining the argument/return value type is done by examining the operations done on them... i.e. R0 LSL 16 immediately followed by R0 LSR 16 would indicate that R0 is (supposed to be) a short, so potential noise is filtered out. Dereferencing one of the function arguments indicates that it's a pointer and so on.... You'll recognize it over time.
Oh, probably the easiest one is a function which accepts no arguments, in that case R0 is discarded / ignored / overwritten (usually right at the beginning) so you know sending an argument makes no sense.

To figure out what arguments I can send to a function is just a matter of reading the code to see if bounds checking is done somewhere (with assertions possibly), what it does, where it's written (deduct from the current memory address?) and, of course, how it's called from other subroutines.

[DataGhost]

About the orientation... maybe it's reasonably accurate after all, but just still a bit offset. I already applied a 4096 offset to these values, maybe that offset is wrong because the angle of the line seems to be fairly constant when I put down the camera on my desk before and after shaking it a bit.

Clip showing the values (with 4096 offset) from EVi (A looks like a sine, B looks like a cosine) and a line from those values

[Microfunguy]

Interesting.


What is the 'Converter'  and 'Custom Display'  ?

[PhyrePhoX]

wow, this really does look accurate, besides the offset problem (it really looks like its "just" the offset). this could be used for LOTS of stuff. but if i understand you correctly this feature in particular is very hard to implement on other platforms. if you need betatesters for this and the IS functions, count me in

[DataGhost]

Interesting.


What is the 'Converter'  and 'Custom Display'  ?

Oh, standard S5 menu functions. I tried turning off IS to see if that made a difference. Converter is for the IS mechanism to know which converter I attached to my camera, so it can adjust for them (i.e. teleconverter is likely to need more compensation with the same amount of movement). In Custom Display, I can enable/disable a live histogram (luminance only), 3x3 gridlines, shooting information and a 3:2 guide, for 4 display presets (2 LCD, 2 EVF).

but if i understand you correctly this feature in particular is very hard to implement on other platforms.

Well, I'd need to find these functions (or ones with similar functionality) on other platforms I'm pretty sure all platforms (with orientation sensor / IS) use something similar to the one in my S5, since it doesn't appear to be used for anything else. It's probably a cheap, generic sensor which they dumbed down to an accuracy of '0, 90 and 180'. I'm guessing DryOS developers had some fun with it or decided to implement this for debugging purposes, because the S3 hardware should be the same.

[PhyrePhoX]

offtopic: the "converter menu" not also influences IS stuff but of course the calculation of focal length and zoom and subsequently this will end in the image exif data, so that later you can see what pictures were shot with or without a particular converter. maybe this can be "hacked" to allow the use of more and custom converters (i know chdk already has the converter factor settings somewhere, but that doesnt influence the image data, just the OSD afaik).

ok, so there is a chance i can fix my s3is to my car and drive around and later will be able to calculate a track profile (when camera is aligned with its "Long side" to the "long side" of the car) - if some kind of logging is enabled AND the values are more finegrained than 0 & 180
this is just a stupid example, i dont even own a car. 

[Microfunguy]

4 display presets (2 LCD, 2 EVF).

I think we need more information on that