SX 10 - Extended AV!!! - General Discussion and Assistance

barberofcivil

268

SX 10 - Extended AV!!!

« on: 20 / October / 2009, 12:24:15 »

Advertisements

In addition to poking around the TV limitations, I found the aperture was getting limited to 2.8-11.0.
I tracked through the code and found that the firmware was clipping the set values between these ranges (oddly enough, the FW limits it 2.8-11.0 even though the camera gui only allows 2.8-8.0).
I was able to successfully extend the aperture range by overriding some of the values. With the overrides, the aperture is still limited at 2.8 for the lower AV, but I am able to get up to 16.0 now on the upper AV (tried and tested exposures).

I found that the firmware is converting the AV value to another related number (similar to TV to microseconds), however, I'm not sure what this value represents (possibly just a value representing the iris mechanical setting). The values seem to get looked up on a table within the FW and are semi-linear (slighty scattered along the linear progression):

Code: [Select]

AV	apex96	value
11.31	672	1903
10.08	640	1791
 8.98	608	1671
 8.00	576	1541
 7.13	544	1400
 6.35	512	1277
 5.66	480	1128
 5.04	448	993
 4.49	416	852
 4.00	384	731
 3.56	352	599
 3.17	320	488
 2.87	292	340

For AV values within this range, I use the lookup value. Outside this range, I calculate it using the approximate linear progression (passing through the upper and lower values): x=(av*4.1132)-(861.0421)

I have added the followwing function to generic/wrappers.c:

Code: [Select]

int  av_ext(int av_cam_x, int av_cam){
  short av_set_x;
  short av_set;
  av_set= shooting_get_av96();
  av_set_x=(av_set*4.1132)-(861.0421);
  if (av_set_x < 0) av_set_x=0;
  if (av_cam!=av_set) return av_set_x;
  else return av_cam_x;
}

I have also made modifications to platform/SX10/sub/103a/capt_seq.c (attached).
This modification is only valid for SX10 103a so far as that is the model I have. When I get a chance, I will look into the other version to see if it works directly or needs to modified.

Logged

smartkiller

139

Re: SX 10 - Extended AV!!!

« Reply #1 on: 20 / October / 2009, 14:11:38 »

Quote from: barberofcivil on 20 / October / 2009, 12:24:15

In addition to poking around the TV limitations, I found the aperture was getting limited to 2.8-11.0.
I tracked through the code and found that the firmware was clipping the set values between these ranges (oddly enough, the FW limits it 2.8-11.0 even though the camera gui only allows 2.8-8.0).
I was able to successfully extend the aperture range by overriding some of the values. With the overrides, the aperture is still limited at 2.8 for the lower AV, but I am able to get up to 16.0 now on the upper AV (tried and tested exposures).

I found that the firmware is converting the AV value to another related number (similar to TV to microseconds), however, I'm not sure what this value represents (possibly just a value representing the iris mechanical setting). The values seem to get looked up on a table within the FW and are semi-linear (slighty scattered along the linear progression):

Code: [Select]
AV apex96 value 11.31 672 1903 10.08 640 1791 8.98 608 1671 8.00 576 1541 7.13 544 1400 6.35 512 1277 5.66 480 1128 5.04 448 993 4.49 416 852 4.00 384 731 3.56 352 599 3.17 320 488 2.87 292 340
For AV values within this range, I use the lookup value. Outside this range, I calculate it using the approximate linear progression (passing through the upper and lower values): x=(av*4.1132)-(861.0421)

I have added the followwing function to generic/wrappers.c:
Code: [Select]
int av_ext(int av_cam_x, int av_cam){ short av_set_x; short av_set; av_set= shooting_get_av96(); av_set_x=(av_set*4.1132)-(861.0421); if (av_set_x < 0) av_set_x=0; if (av_cam!=av_set) return av_set_x; else return av_cam_x; }
I have also made modifications to platform/SX10/sub/103a/capt_seq.c (attached).
This modification is only valid for SX10 103a so far as that is the model I have. When I get a chance, I will look into the other version to see if it works directly or needs to modified.

Hallo
Please take a look at the SX1 Firmware (201a) so we can test it on the SX1.

Smartkiller

Logged

SX200 IS Firm. 100c
SX1 IS Firm. 201a

reyalp

14080

Re: SX 10 - Extended AV!!!

« Reply #2 on: 20 / October / 2009, 19:00:44 »

I would be very cautious with this. It is possible that the limit exists to prevent the hardware from damaging itself.

Logged

Don't forget what the H stands for.

barberofcivil

268

Re: SX 10 - Extended AV!!!

« Reply #3 on: 20 / October / 2009, 19:18:59 »

Quote from: reyalp on 20 / October / 2009, 19:00:44

I would be very cautious with this. It is possible that the limit exists to prevent the hardware from damaging itself.

Yes, I'm aware of this. Thus far, I've had no feedback that there is an issue, it just caps out the exposure at F16 and F2.8, so there may be another limitation within the iris mechanism itself or elsewhere in the code. I would imagine that if there was any possibilty of the hardware going too far, it would be relative to larger apertures (i.e. <F2.

rather than smaller, so seeing as how it does seem to be limited, it may be worthwhile to at least code limits to the 2.8 and 16.0 values.

The conversion function bottoms out to a 0 value just above a 2.0 aperture value, which I have put in as a limitation.

Any idea what the av apex value is getting converted to? It seems odd that it would grab the values off a stored table rather than converting them using a function (mind you, they are not exactly linear but exhibit a slight scatter around the assumed linear progression I've used). if they are related directly to the iris mechanism, then there would be a possibility that they differ from model to model (I would expect them to be the same within a model series but different firmware versions).

reyalp, also would you have any idea if I could see the table. It is giving me referral addresses within the code (FFF6B4DC-FFF6B6E4) but my conversion of the code (i used GCC 4 with the perl scripts from the wiki) has these all with "ffffffff undefined instruction 0xffffffff" values.

Logged

reyalp

14080

Re: SX 10 - Extended AV!!!

« Reply #4 on: 20 / October / 2009, 20:09:47 »

There must be some reason they impose this limit. Maybe it's because the very small apertures affect visual quality too much. I'm not trying to discourage you from trying it out, but I want to be sure that others stumbling on this thread that there is some possible risk.

I don't see offhand what is happening in those functions. My suggestion would be to record the values the APEX96 value gets converted to, stuff them in a table and see if some obvious pattern appears.

Quote

It is giving me referral addresses within the code (FFF6B4DC-FFF6B6E4)

Where exactly are you seeing these references ?

A couple other random thoughts:
One thing I notice is that sub_FF93B440 is referenced in a lot of places, so you may find your override is intermittent (or perhaps the camera will just be confused about what was used in some other calculation) You've also broken it up into two functions, which is slightly confusing. The BEQ just a branch, not a function call.

It appears to take 3 parameters. The first is a signed short, the second is a pointer to a function, and the third appears to be the number 2 in all cases. It returns a signed short.

Logged

Don't forget what the H stands for.

barberofcivil

268

Re: SX 10 - Extended AV!!!

« Reply #5 on: 20 / October / 2009, 22:38:01 »

Quote

I don't see offhand what is happening in those functions. My suggestion would be to record the values the APEX96 value gets converted to, stuff them in a table and see if some obvious pattern appears.

I already did step through the functions, the branch "BL FFA568A8" is the one that converts the value. It seems to be basically an iterative function that that steps through av apex96 values and the referral addresses below until it reaches the appropriate one then pulls the conversion value from it. The values actually pulled from the process are the ones I listed. As I said, they are linear to a degree, but are somewhat scattered off the linear line (and not in a consistent way). Perhaps they were preset as optimized values for the camera hardware.

Quote

Quote
It is giving me referral addresses within the code (FFF6B4DC-FFF6B6E4)
Where exactly are you seeing these references ?

I set up a monitor of the function and pulled the values out (rather tediously I may add...)

Quote

A couple other random thoughts:
One thing I notice is that sub_FF93B440 is referenced in a lot of places, so you may find your override is intermittent (or perhaps the camera will just be confused about what was used in some other calculation)

This is possible and I can't be certain (however the same seems to be true of the shutter functions used). This function is actually only called out of the capt_seq_task when the camera (screen) Av value and the set value don't match (i.e., set using the overrides or scripting)

Quote

You've also broken it up into two functions, which is slightly confusing. The BEQ just a branch, not a function call.

True. This is how I broke it out, so I just left it without thinking of combining. I used the first function first to see where I wanted to go, then went into the second function. Wouldn't take too much to combine them into a single one.

Logged

reyalp

14080

Re: SX 10 - Extended AV!!!

« Reply #6 on: 20 / October / 2009, 23:35:11 »

Quote from: barberofcivil on 20 / October / 2009, 22:38:01

I set up a monitor of the function and pulled the values out (rather tediously I may add...)

Huh ? I don't understand what you are trying to say here at all. You believe FFF6B4DC-FFF6B6E4 are the addresses of something (which they aren't BTW, for the reason you suggested).

What is the address of the instruction that you believe refers to these addresses ? If you don't have such an address, where do the above values come from ? Be specific.

Logged

Don't forget what the H stands for.

yvesson

209
A540 SX10IS

Re: SX 10 - Extended AV!!!

« Reply #7 on: 21 / October / 2009, 04:40:50 »

Quote from: reyalp on 20 / October / 2009, 20:09:47

There must be some reason they impose this limit. Maybe it's because the very small apertures affect visual quality too much. I'm not trying to discourage you from trying it out, but I want to be sure that others stumbling on this thread that

Hej,
Yes, diffraction is already very high at F8 on a small sensor with a lot of Mpixels. Some even say that the sweet spot on newer camera is the lower F-number.
There arn't much reasons to use F8 on a compact cam, except for DOF in macro mode.

Logged

barberofcivil

268

Re: SX 10 - Extended AV!!!

« Reply #8 on: 21 / October / 2009, 09:44:41 »

Quote from: reyalp on 20 / October / 2009, 23:35:11

Huh ? I don't understand what you are trying to say here at all. You believe FFF6B4DC-FFF6B6E4 are the addresses of something (which they aren't BTW, for the reason you suggested).
What is the address of the instruction that you believe refers to these addresses ? If you don't have such an address, where do the above values come from ? Be specific.

When I enter the branch "BL sub_FFA568A8\n" the first 3 register values are:
r0=FFD29730
r1=(av apex96)
r2= 672 (672 is apex96 value corresponding with F11)

The r0 address does not seem important to this branch as it gets stored away to r5 and overwritten:

Code: [Select]

ffa568b0: 	e59f0150 	ldr	r0, [pc, #336]	; ffa56a08: (0000d100)
ffa568b4: 	e1a04001 	mov	r4, r1
ffa568b8: 	e5900004 	ldr	r0, [r0, #4]

This is the point where the addresses I am referring to appear:
r0=FFF6B6E4

also note that our apex96 value gets moved out to r4 for future use

Jumping ahead:

Code: [Select]

ffa568c0: 	e1a0c000 	mov	ip, r0

move r0 to ip

Code: [Select]

ffa568c4: 	e08c1102 	add	r1, ip, r2, lsl #2

this is an important step as this is where the iterative loop is placed.
at first run, r2=0 so r1=ip=r0

Code: [Select]

ffa568c8: 	e1d130f0 	ldrsh	r3, [r1]
ffa568cc: 	e1530004 	cmp	r3, r4

at first run, r3=292 (apex96 for F2.8 )
and r3 is compared to r4 (which is our set AV)

Code: [Select]

ffa568d0: 	aa000003 	bge	ffa568e4

if r3>=r4 we branch forward to continue our function
if r3<r4, we continue here which is the iterative part

Code: [Select]

ffa568d4: 	e2822001 	add	r2, r2, #1	; 0x1

increase r2 by 1

Code: [Select]

ffa568d8: 	e3520084 	cmp	r2, #132	; 0x84

check the iteration progression against 132 (this it what actually limits us to F11.0)

Code: [Select]

ffa568dc: 	e1a00001 	mov	r0, r1
ffa568e0: 	3afffff7 	bcc	ffa568c4

go back to FFA568C4 if r2<132

At this point, it continues to itereate through the function until either the APEX96 value retrieved equals the set value, or we reach the iteration limit (=F11.0). Each time we iterate through, the address gets decreased by 4, this is where the address range:
FFF6B4DC-FFF6B6E4 comes from (its actually reverse, but FFF6B6E4:F2.8, FFF6B4DC:F11)

If the apex96 value started out less than 292 (AV<F2.8 ), then at address ffa568cc, the compare comes out <0 and the address is left at the initial value FFF6B6E4 corresponding to F2.8.

Code: [Select]

ffa568e4: 	e1510000 	cmp	r1, r0
ffa568e8: 	11d120f0 	ldrshne	r2, [r1]
ffa568ec: 	11520004 	cmpne	r2, r4

This appears to be just an error check as R1 should always equal R0 as it was set at ffa568dc.

Code: [Select]

ffa568f0: 	01d100f2 	ldrsheq	r0, [r1, #2]
ffa568f4: 	01d110b0 	ldrheq	r1, [r1]
ffa568f8: 	01c510b0 	strheq	r1, [r5]
ffa568fc: 	08bd8070 	popeq	{r4, r5, r6, pc}

This where our conversion value gets loaded from and then we return from our branch. It is the second halfword of the referenced address (first halfword is the APEX96 value). The values pulled out here are the ones I referred to previously:

AV   apex96   value
11.31   672   1903
10.08   640   1791
8.98   608   1671
8.00   576   1541
7.13   544   1400
6.35   512   1277
5.66   480   1128
5.04   448   993
4.49   416   852
4.00   384   731
3.56   352   599
3.17   320   488
2.87   292   340

The address iteration goes through steps of 4, however the addresses corresponding to the camera settable values are at increments of 44 (except F2.8-F3.2 which isn't a full 1/3EV step, the increment is 36) so there are additional intermediate values between the 1/3EV steps which I haven't tried to pull out yet. Oddly, they aren't even increments with respect to the AV apex96 increment (difference of 44(11 increments) vs 32 = steps of 2.9?). I have done a quick exposure test on a 1/6EV increment with a positive result, I just didn't bother checking the conversion value yet.

It also seems that once we return from the branch, only the conversion number is used. I have done tests where I hardcode in a conversion value, and the camera exposure gets fixed at whatever aperture it corresponds to. Hardcoding the AV or address after this branch has no effect on the exposure.

I hope all this is understandable. One thing I am not certain of if the addresses I am referring to (maybe they aren't what they appear, or are a literal pool that gets built elsewhere). The apex96 values are straightforward and the conversion numbers pulled out seem right (as I can hardcode values and they work as expected).

Do you see anything wrong with how I am understanding the branch? The changes I have made to the code seem to work, I just don't know how it is reaching the original conversion values.

Logged

barberofcivil

268

Re: SX 10 - Extended AV!!!

« Reply #9 on: 21 / October / 2009, 11:43:48 »

Quote from: smartkiller on 20 / October / 2009, 14:11:38

Hallo
Please take a look at the SX1 Firmware (201a) so we can test it on the SX1.

Smartkiller

I had a quick check in the capt_seq.c for SX1 (200h & 201a) and they both appear to have similar structures, but different address locations of the functions.

In SX10 103a, the function I'm calling to is located at FF93B440, in both the SX1 FWs, what appears to be in the same call location is at FF94EAF0.

The branches called may be similar in structure, but will likely also have differing address references throughout. To do a test build, I will need to DL the fw and dissassemble to verify the structure and update the addresses. I'll see if I can get to this in the next few days if you'd like (vers 201a I'm assuming).

Be warned as pointed out by reyalp, that there may be reasons for this limit, however I haven't encountered any problems that I've noticed on my SX10 with the workaround. Also note that I would have to assume that the conversion values I've been mentioning would have to be assumed to be the same as I have no way of tracking them withou having the actual camera.

-tgq

Logged