Developer-friendly / experimental branch (dataghost)

[DataGhost]

Yeah, well... my camera occasionally crashes because the flash isn't charged enough, but I managed to document how it works a bit. I wanted to get my external flash to do the same (and maybe allowing me to figure out the external flasher protocol) but it wouldn't. This lead me to bypassing printf so I could log even more (I even got the dry shell running but I can't talk to it and it's not really useful anyway... oh, and I can run the commands from C code anyway). Currently I'm trying to get the display to magnify a bit, I found out that suspending ImageSensorTask stops the live view (and makes some assertions fail if I don't resume it within a second) and seeing that it's a challenging task, I'm now looking into bypassing exception handlers so I can scan the memory. Not much so far, the camera locks and crashes like never before but at least I managed to keep my camera awake, rather than turning off, when accessing i.e. 0x20000000 in the memory viewer. I can't even properly return, though, so the CHDK GUI is disfunctional after doing that. Still occasionally it locks up or shuts down the camera completely and I have no idea why, it shouldn't be this random.
I also found Canon's exception handler for memory access errors but it doesn't call any of the function I rerouted (or which are easy to reroute) and it's stuffed with IRQ enable/disable and in/out-exception-handler-jumping so it's probably hard to route this into a file.

Also telling you this because people might notice I didn't commit in a couple of days.

Oh yes, maybe someone might find this useful... output from all commands (except for a few which don't report status information) accessible through drysh. http://dataghost.com/chdk/drysh.txt

By the way, disabling preflash might be possible but it's still going to be difficult. I suspect it's being executed through ExecuteEventProcedure, which wants a string (function name) as argument and I'm nowhere near close to figuring out how that's done (most of the functions don't even have an XREF to ExecuteEventProcedure at all) or where the used strings come from.

[ewavr]

does this eventually mean you can disable preflash (in non manual mode)?

I don't know exactly. But why is this needed?
Maybe more flash power levels in manual mode (>3) is possible, I will try discover this.
I would use a series of small-power flashes to send some information to self-made slave flash using this (EF.StartInternalPreFlash) function. But it does not allow too frequent flashes 

my camera occasionally crashes because the flash isn't charged enough,

And my camera also crashes after 10-20 small (power=5) flashes

[DataGhost]

Oh yes, I forgot to mention that I too don't really see the use of disabling preflash in a non-manual mode, unless the flash strength is set through CHDK.

Anyway, ewavr... what do you have to feed to that function? Mine wants a struct { long type; long bright1; long bright2 }. Maybe it's a new DryOS or S-series thing.

type:
0 = camera locks
1 = one flash
2 = two flashes
3 = normal (at least, it appears to be normal preflash + flash. bright1 and bright2 are ignored)
4 = I forgot (probably manual low)
5 = I forgot (probably manual mid)
6 = manual normal (appears to be, one flash as would be in manual mode, max strength)
7 and up = not tested

bright1 and bright2 control the strength of the first and second flash, respectively, only if they are supposed to fire and only with type 1 and 2. Values seem to be in 0-255 range though I did very limited testing.

[PhyrePhoX]

well, disabling preflash would be for those rare occasions i'm out and about with my slave flash and want to disable preflash in ALL modes, without having to think about it. but you are right, this is not really an important feature to have. more power would be nice though

[DataGhost]

Hm yeah, slave flash... good point. I guess the internal main flash strength does not matter much, then? Although I have the feeling that it'll fire it at full strength, since it didn't measure any light from the preflash

Anyway, http://stack.dataghost.com/S5-DiscoPlusFlash.mp4 I made it a bit faster, ewavr SleepTask is called (100ms delay) *before* flashing, I changed it to 25ms and it'll probably be fine with low flash strengths. Depending on *something*, it'll delay longer, though.. I first thought because of my batteries, they were just below 5V so nearing emptyness, but it also happened with fresh batteries. I now suspect low lighting to be the cause but I don't really feel like spending too much time on that now.

[ewavr]

Anyway, ewavr... what do you have to feed to that function? Mine wants a struct { long type; long bright1; long bright2 }. Maybe it's a new DryOS or S-series thing.

type:
0 = camera locks
1 = one flash
2 = two flashes

The same on A710.

3 = normal (at least, it appears to be normal preflash + flash. bright1 and bright2 are ignored)
4 = I forgot (probably manual low)
5 = I forgot (probably manual mid)
6 = manual normal (appears to be, one flash as would be in manual mode, max strength)
7 and up = not tested

Different behavior - two preflashes (first with out power) and main flash (with some power), but different timings (between 1 & 2 preflash and main flash). Too complex for my limited mind  

bright1 and bright2 control the strength of the first and second flash, respectively, only if they are supposed to fire and only with type 1 and 2. Values seem to be in 0-255 range though I did very limited testing.

Maybe the same for A710.

edit: When I remove SleepTask call from EF.StartInternalPreFlash, my camera can shoot with flashes like machine gun (with short bursts of fire). But only in good light conditions - maybe flash shooting task  (or our SpyTask) have too low priority (lower than live image displaying). BTW, if display is off this function don't work

[daniel_reetz]

Hi DataGhost,

I bought an A570 IS to test out your code. It took me quite a while to get it to compile, as I'm not a developer. Contrary to the previous discussion, I had some problems.

Canon Powershot A570 IS, FW 101a.

Under IS menu:

Adjust IS lens position works -- but the steps are very small compared to your S5, even at size 100.
Show IS Internals causes the camera to turn off but not retract the lens.
Show IS intern, Ontop (non-ALT) causes the camera to turn off but not retract the lens.
Show IS intern2 Ontop (non-ALT) causes the camera to turn off but not retract the lens.
Camera Orientation demo works, but exhibits substantial hysteresis.

I compiled from 406. If you have a newer/different CHDK version compiled, I would like to try it before I return the camera to the store.

I was pleased to see that I could shift the image left and right, so it looks like I might be able to do the imaging techniques I'd like to do with just a simple script. I am going to return my A570 to the store -- it looks like it has a sensor flaw (spots in the upper left corner of every image). Thanks for all your hard work.

[daniel_reetz]

Also: Find IS Lens Center does nothing.

[DataGhost]

Uh... how do you know what the IS adjustment step size on my S5 is? I didn't demonstrate that particular feature in any movie clip, as far as I remember. Anyway, at step size 100, it takes me 6 clicks to go from left to right. The range, as determined by moving the IS lens to the sides with the internal camera functions, is 0xD4 - 0x32C (212 - 812), which works out to 600 steps.

Other functions could crash the camera, indeed. They're probably not, partially or differently implemented on the A570 and mostly useless anyway. Orientation might be off by a certain angle but it should be reasonably 'accurate'.

Sensor flaw: is that with CHDK? Like... RAW (or JPEG) without noise reduction and long exposures? I guess every Powershot camera has that issue. If it even happens without CHDK on your camera, indeed you'll probably have to return it

Oh and 'Find IS Lens center' doesn't do anything indeed... I didn't implement that in this build yet. It's the thing I made a movie of and only works when you add enough vignetting (in my case, a teleconverter) centered over the lens.

[daniel_reetz]

When I watch "S5-CenterISImproved.avi" I can see what I assume is the IS adjustment moving left-to-right. My camera does not move so far left-to-right. In fact, it moves about half as much as yours does. I checked how many steps at size 100 -- and from center, I get two steps left and two steps right, from 0x14C to 0x2B4. The same is true for up and down.

The sensor flaw is really a flaw in the sensor. In the top left corner of my sensor there is some weird problem that shows up in every image. Here are two examples:

http://danreetz.com/chdk/Sensor_Flaw_IMG_0050.JPG
http://danreetz.com/chdk/Sensor_Flaw_IMG_0051.JPG

Look at the weird mottling in the top left side of each image. It doesn't change with zoom, so it must be something on the sensor itself.

Would you suspect that the A720 would have a more complete/similar implementation, or be better for the task?

[DataGhost]

Ah, I remember. I moved the IS lens completely to the side instead of a 100-step.

Sensor flaw: probably a bad case of dust. I have some dust spots on my sensor, they are more visible with a smaller diaphragm. Try Av mode (or similar) and set it to F/8 or the smallest one you can get... (the images you showed are F/4) and you'll see they're probably more noticable.

A720: 'more complete/similar implementation, or be better for the task?'... what? I don't really know what you mean... if it's about the IS stuff... on my S5 most of the values never change, even when changing settings, therefore they are useless (or at least I don't want to change them). I'd say it depends on what you want to achieve but then I still don't know what the A720 is capable of.

[daniel_reetz]

Yeah, it looks like dust/lint to me. Unlike the DSLR I use in my professional work, it is impossible to clean the sensor on these little cameras.

I must not have communicated my plans very well. I'm sorry about that. I'll try again:

I want to do a couple of specialized photographic techniques. What they are is not really important -- though they all share some common characteristics. All of them involve moving the image on the sensor and taking multiple shots. The ideal scenario is as follows:

Turn on the camera. Shoot the first shot with the sensor in the central position. Shift the image on the sensor by 1 pixel using IS. Take another picture. Shift the image on the sensor left one pixel. Take another picture. Shift the image on the sensor down and right 2 pixels. Take the final picture.

The same procedure could be repeated at different distances. 1 pixel is just an example.

I'd do that four times and then use those images as the input to some custom image processing software. So what I am looking for is control over the IS system, such that I can script the movement of the image on the sensor and repeatedly take photographs. Because I'd like as much flexibility in image movement as possible, I would like a fairly complete camera implementation of IS -- and one that moves as far left, right, up, and down as I can get. That's my application and why I'm asking these questions. It looks to me like I could do that using your branch and a little scripting, and now I am looking for the ideal camera.

[cyril42e]

I am very interested in this point for dark-frames:

- Control over the shutter, to quickly make a dark frame or do other cool stuff with it. (barely implemented)

So I had a look at the branche, and saw that _OpenMShutter and _CloseMShutter were declared in stub_entry_ida.S. So I got the addresses for my SD1000/Ixus70, and included them in stub_entry_2.S :

Code: [Select]

platform/ixus70_sd1000/sub/102a/stubs_entry_2.S
+NSTUB(CloseMechaShutter, 0xffade8f8)
+NSTUB(OpenMechaShutter, 0xffade928)

Then I added all the necessary declarations to add a "shooting_set_shutter_state" function and "set_shutter_state" ubasic command, and wrote a small script:

Code: [Select]

@title Dark frame

r=get_raw
n=get_raw_nr

set_raw 1
set_raw_nr 1
set_shutter_state 1

shoot

:restore
set_shutter_state 0
set_raw r
set_raw_nr n

end

And it works great! So my questions:

Is it that easy? What are the risks? If I want to add support for all cameras, how can I tell the makefile to automatically generate these addresses with the findsig tool?

[LjL]

The camera orientation demo doesn't work properly on my A720.

It works "in reverse", sort of... when the camera is placed horizontally, the line is vertical (actually, it's slightly diagonal, apparently by always the same angle).
When the camera is vertical, the bar is horizontal (i.e. in the same oritentation, relative to the screen itself, as when the camera is horizontal - except the diagonal skew is more pronounced).

But it's not just a matter of the line being 90 degrees off, because in intermediate orientations between horizontal and vertical, the line rotates in the wrong direction.

I'm very new to CHDK (and my camera is new, too), so I'm exploring and I haven't really understood what the available sensors are and what they do, and how I should interpret the debug values in your build... but I surely can provide them to you with the camera in any orientation you request.

The one thing I noticed is that the camera does seem to also have a "gravitational sensor" (for lack of a better term) in the other direction... i.e. when I tilt the camera upwards or downwards (not rotate it), values change (one of the last two displayed values, specifically) and the length of the demo line changes too. Is that really the case? If so, I wonder why it's there, since my camera doesn't seem to care about that sort of tilting...

[LjL]

DataGhost, please have a look at this feature request, too.

If the orientation sensor can never be accurate enough as a levelling tool... well, I think it can still be quite useful for other things!

It would be lovely, besides, if you could implement uBASIC commands to read these sensors in your build, so we can play around easily, as well perhaps as letting offsets be user-adjustable...