Developer-friendly / experimental branch (dataghost) - page 8 - CHDK Releases - CHDK Forum
« previous next »
Pages: 1 ... 3 4 5 6 7 [8] 9 10 11 12 13 ... 15   Go Down

Developer-friendly / experimental branch (dataghost)

  • 143 Replies
  • 85157 Views
*

Offline DataGhost

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

Offline daniel_reetz

  • *
  • 25
Re: Developer-friendly / experimental branch (dataghost)
« Reply #71 on: 27 / May / 2008, 16:49:02 »
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.


Logged
*

Offline cyril42e

  • ***
  • 111
  • SD1000/Ixus70 1.02a
    • CR-TEKnologies
Re: Developer-friendly / experimental branch (dataghost)
« Reply #72 on: 24 / June / 2008, 09:59:03 »
I am very interested in this point for dark-frames:

Quote from: DataGhost on 14 / May / 2008, 03:08:13
- 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?
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #73 on: 02 / July / 2008, 09:43:40 »
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...
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #74 on: 04 / July / 2008, 07:32:24 »
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...
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #75 on: 04 / July / 2008, 12:28:42 »
I've done some measurements on my A720's "Lens EVi" sensors reading.

To smooth out the numbers, I've integrated using the following code in do_show_is_raw():


static int EViAInt=0;
static int EViBInt=0;

...

EViAInt=(EViAInt*95+_GetISLensEViAaxis()*5)/100;
EViBInt=(EViBInt*95+_GetISLensEViBaxis()*5)/100;
sprintf(buf, "AvA %06d AvB %06d    ", EViAInt, EViBInt);
draw_string(0, 9*FONT_HEIGHT, buf, MAKE_COLOR(COLOR_BG, COLOR_FG));


So, I'm not adding or subtracting any 4096 here.

I've put the camera in the following orientations:
- "0", camera in its normal position, bottom side on the ground, lens pointing towards the horizon
- "180", camera flipped upside down, top side on the ground, lens towards the horizon
- "skywards", camera with the LCD side on the ground, lens pointing towards the sky
- "90", camera hand-held so that the left side (the one with sockets, not the one with the handgrip) sits on the ground, lens towards the horizon
- "270", camera hand-held so that the right side (handgrip) sits on the ground, lens towards the horizon

I've done more (and perhaps more reliable) measurements for the "0", "180" and "skywards" orientations, as they didn't require hand-holding.

During the first measurements, I've used a precision of 50, then seeing that some numbers seemed remarkably consistent (well, not quite always), I've switched to a precision of 5. Not very scientific, I know  :-X

The results are as follows (orientation, A axis, B axis):

0: 3650/3800/3900/3900/4080/3940/4130 (mean: 3914, stddev: 162), 2500/2550/2250/2500/2550/2550/2510 (mean: 2487, stddev: 107)
sky: -2800/-2250/-2200/-2325/-2345 (mean: -2384, stddev: 240), 1550/1550/1525/1550/1605 (mean: 1556, stddev: 29)
180: -9050/-8950/-8950/-9000/-8750 (mean: -8940, stddev: 114), 750/750/750/750/860 (mean: 772, stddev: 49)
90: -3040/-2810/-2795 (mean: -2882, stddev: 137), -4860/-4855/-4945 (mean: -4887, stddev: 51)
270: -1775/-1660/-1590 (mean: -1675, stddev: 93), 8350/8425/8425 (mean: 8400, stddev: 43)

Average of means (A axis): -2393
Average of means (B axis): 1666
Average of means (total): -1255
Average of standard deviations: 95

The following angles are not included in the averages:

30: 2530, -975
60: -100, -3600
120: -6630, -4290
150: -8735, -2055/-2285
210: -8040, 3835
240: -5400 6500
300: 1380, 7425
330: 3700, 5625

« Last Edit: 05 / July / 2008, 09:11:14 by LjL »
Logged
*

Offline Bg~

  • *
  • 27
Re: Developer-friendly / experimental branch (dataghost)
« Reply #76 on: 05 / July / 2008, 21:21:46 »
So if you had an (x) axis pointed out of the top of the camera and a (y) axis pointed out of the right side (looking at the LCD), the pink line is the x-axis acceleration measurement, and the blue is the y-axis measurement. Of course, they need separate bias corrections, but their scales look similar. The skyward measurement supports this, since this accelerometer configuration would measure around zero for both sensors with the camera pointing skyward (-2384 & 1556 are close to the average of -2393 & 1666)
« Last Edit: 05 / July / 2008, 21:23:58 by Bg~ »
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #77 on: 06 / July / 2008, 07:40:39 »
Yeah. Although I'm suspecting that the scales, too, are not identical, even though they look similar.

But there's another more annoying issue: we're assuming that the sensors are placed in the way you described (or at least, that they're measuring those angles), but that's either not the case, or I'm missing something.

Because basically, no matter what bias I subtract (and yes, I'm subtracting the bias that lets everything be "zero" when the camera is pointing to the sky/ground, which incidentally is the exact same thing), if I manage to get correct sin and cos readings for 0 degrees, then 180 degrees will be wrong, and same for 90 and 270 degrees.

In a sense, it's like the "positive" part of the sine/cosine goes up higher than the "negative" part (or vice versa).

In a spreadsheet, the best transformations of a sine and a cosine I could find (by trial and error) that would approximate our sensors readings as well as possible were shifted by around 9 and -5 degrees (which is which - I don't remember).

Another way to explain it: if I run the camera orientation demo (after modifying it to more or less fit that graph, that is) without making it clear the screen at each loop, and then I turn the camera 360 degrees on the lens axis, I end up with an ellipse on the screen, instead of a circle like I would expect.
See the attached picture.

EDIT: But wait, why are you saying the x axis is pointing out of the top of the camera? Wouldn't it be pointing out of the lens? At least if we're talking about "orientation sensors" (i.e. where-is-gravity), you can't measure rotation around such an axis...
« Last Edit: 06 / July / 2008, 07:49:01 by LjL »
Logged
*

Offline LjL

  • ****
  • 266
  • A720IS
Re: Developer-friendly / experimental branch (dataghost)
« Reply #78 on: 06 / July / 2008, 09:35:42 »
I'll publish what I've done so far, since it's also relevant to a feature request I've discussed.

The attached file includes the source and a DISKBOOT.BIN for the A720 (use at your own risk!).

The changes with respect to DataGhost's last SVN are:
- use my own method to turn sensor readings into sine and cosine (which kind of works on my camera)
- in the camera orientation demo, you can use the cursor keys to adjust sensor bias
- if Misc/"Use zoom buttons for MF" is active, and you make the camera face the ground, it will switch into macro mode, and back into landscape mode when it faces the horizon again
- if Misc/"Use zoom buttons for MF" is active, and you tilt the camera left/right in MF mode, it will throttle focus near/far

Bugs, or things I don't like in general, are:
- as I've been saying, the sensor readouts are still not correctly converted into sine and cosine
- the "macro" symbol doesn't show up when switching to macro mode (I change PropCase 6... is there a better method?)
- macro mode will kick in also if you point the camera up, as I don't think there is a way to tell apart "up" from "down" using the sensor (probably not a big deal, since the camera seems to focus to infinity even when it's in macro mode... it's likely just slower)
- focus throttling speed does not increase with tilt angle, since I'm simply simulating keypresses for "right" and "left" (using shooting_set_focus() resulted in in weird things, including my camera crashing with a "Lens error, restart camera"... ouch!). How can this be achieved?
- focus throttling can only be used with the camera in landscape orientation, not portrait
- for some reason, if the focus-by-tilting routine is called too early, my camera crashes, and the current workaround is merely to make it wait some hundred cycles after powerup before having the thing kick in


EDIT: Uhm, I can't attach it, it's about 700Kb but the forum complains that "the upload folder is full"...  :(
I'll attach the binary and a diff to DataGhost's SVN.
« Last Edit: 06 / July / 2008, 10:09:42 by LjL »
Logged
*

Offline Bg~

  • *
  • 27
Re: Developer-friendly / experimental branch (dataghost)
« Reply #79 on: 06 / July / 2008, 12:48:14 »
Quote
EDIT: But wait, why are you saying the x axis is pointing out of the top of the camera? Wouldn't it be pointing out of the lens? At least if we're talking about "orientation sensors" (i.e. where-is-gravity), you can't measure rotation around such an axis...

Well I should probably play with my camera (A720 as well) before making any more comments but I'll make one anyway. :) If the x-accelerometer measurement axis was pointing out along the lens, then your skyward measurement would not be centered around the mean measurement. But I'm a little confused, since I guess that the tilt sensor would be the way you describe (pointing out of the lens and side). I'll load up your work and see if I can figure anything out.
Logged
Pages: 1 ... 3 4 5 6 7 [8] 9 10 11 12 13 ... 15   Go Up
« previous next »
 

Related Topics