Developer-friendly / experimental branch (dataghost) - page 7 - CHDK Releases - CHDK Forum  

Developer-friendly / experimental branch (dataghost)

  • 143 Replies
  • 98164 Views
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Developer-friendly / experimental branch (dataghost)
« Reply #60 on: 26 / May / 2008, 17:47:17 »
Advertisements
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.
« Last Edit: 26 / May / 2008, 18:04:06 by DataGhost »

*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #61 on: 26 / May / 2008, 18:08:12 »
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 ;)
« Last Edit: 26 / May / 2008, 18:11:13 by ewavr »

*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Developer-friendly / experimental branch (dataghost)
« Reply #62 on: 26 / May / 2008, 18:21:34 »
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.

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Developer-friendly / experimental branch (dataghost)
« Reply #63 on: 26 / May / 2008, 18:26:06 »
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 ;)


*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Developer-friendly / experimental branch (dataghost)
« Reply #64 on: 26 / May / 2008, 19:17:00 »
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 :P 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.

*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #65 on: 26 / May / 2008, 19:21:05 »
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 :(
« Last Edit: 26 / May / 2008, 20:37:16 by ewavr »

Re: Developer-friendly / experimental branch (dataghost)
« Reply #66 on: 27 / May / 2008, 13:33:52 »
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.

Re: Developer-friendly / experimental branch (dataghost)
« Reply #67 on: 27 / May / 2008, 13:34:58 »
Also: Find IS Lens Center does nothing.


*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: Developer-friendly / experimental branch (dataghost)
« Reply #68 on: 27 / May / 2008, 15:15:39 »
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.

Re: Developer-friendly / experimental branch (dataghost)
« Reply #69 on: 27 / May / 2008, 15:34:47 »
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?

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal