DoF values and other related items - page 4 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5 6   Go Down

DoF values and other related items

  • 50 Replies
  • 27133 Views
*

Offline barberofcivil

  • ****
  • 268
    • deviantART Gallery
Re: DoF values and other related items
« Reply #30 on: 26 / November / 2009, 14:29:46 »
Advertisements
Quote from: barberofcivil on 26 / November / 2009, 13:02:19
However it does report 4 other locations (which have the same structure).  Not sure what these ones are for, but the one selected is the one referenced in GetFocusLensSubjectDistanceFromLens.
I suppose that this is where not limiting the signature length can help in differentiating the correct one.

Actually, in this particular example, extending the signature length fails.  In all the reference builds (and even the SX10 dump) the GetFocusLensSubjectDistance function is followed immediately by another function instruction (either a STM or LDR then STM instruction set), but in the 200 dump, it is followed by a literal pool.  So allowing the reference function to extend beyond the initial 10 instructions actually disqualifies the correct function.  (and I am assuming that I have the right one by the manual logic method I used, and I had somewhat verification from microfunguy that it works).

One question about the sig finder.  This function ends in a non-returning branch instruction (ie.  the function is continued elsewhere).  Does/can the sig finder be made to follow this branch instruction to build and compare function signatures?  If so, this would help immensely, at least in this case, as all the alternate suggestions would then fail, only the correct one as the same structure in the continuing branch (SX200 vs A720, also same for SX10)
Logged
*

Offline reyalp

  • ******
  • 14125
Re: DoF values and other related items
« Reply #31 on: 26 / November / 2009, 18:38:54 »
Quote from: barberofcivil on 26 / November / 2009, 14:29:46
Quote from: barberofcivil on 26 / November / 2009, 13:02:19
However it does report 4 other locations (which have the same structure).  Not sure what these ones are for, but the one selected is the one referenced in GetFocusLensSubjectDistanceFromLens.
I suppose that this is where not limiting the signature length can help in differentiating the correct one.

Actually, in this particular example, extending the signature length fails.  In all the reference builds (and even the SX10 dump) the GetFocusLensSubjectDistance function is followed immediately by another function instruction (either a STM or LDR then STM instruction set), but in the 200 dump, it is followed by a literal pool.  So allowing the reference function to extend beyond the initial 10 instructions actually disqualifies the correct function.
Right, but in this case I decided that 1 bad match is better than 17 (and many more sub-versions) with 4+ partial matches. If I remember right, the 10 instruction limit meant that actually only 3 instructions were actually used (because as mentioned earlier, the sig finder ignores some instructions).
Quote
One question about the sig finder.  This function ends in a non-returning branch instruction (ie.  the function is continued elsewhere).  Does/can the sig finder be made to follow this branch instruction to build and compare function signatures?
No, it doesn't follow branches at all. Updating it means re-working the whole system, because it will affect all existing files.  The ability to branches has long been on my list of things for a "next generation" sig finder. Really, we shouldn't use the automatically generated files directly. Once a function is found and known correct, it should be "frozen" and only updated if needed (but somehow, we should maintain the information of how it was found in the first place). The whole thing is a hack and doesn't really scale to the number of cameras variants we have. It is also horribly inefficient, meaning that a full build of all the platforms, with sig matching takes well over an hour on my windows system.

Re-working this is major undertaking, but the more I try to do these updates to all the cameras, the more convinced I am of the need. As it is, it's extremely tedious, time consuming and error prone. Changes that are trivial for one camera become a multi-day project </rant>  :D
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14125
Re: DoF values and other related items
« Reply #32 on: 26 / November / 2009, 19:55:50 »
Ok, I've checked this in, changeset 842

Did not make the functions generic because of the old vxworks cams. I also made GetCurrentTargetDistance a wrapper for GetFocusLensSubjectDistance, rather than having both point to identical sigs. The reasoning is it keeps the noise in the stubs files down, and only one entry point needs to be found if the sigs don't work. The wrapper is weak, so a manually found GetCurrentTargetDistance will override.

Also renamed lens_get_focus_pos_from_lense -> lens_get_focus_pos_from_lens

Edit:
The GetFocusLensSubjectDistanceFromLens update is only applied to MF cams for now. The others continue to use GetCurrentTargetDistance.
Logged
Don't forget what the H stands for.
*

Offline barberofcivil

  • ****
  • 268
    • deviantART Gallery
Re: DoF values and other related items
« Reply #33 on: 26 / November / 2009, 20:04:29 »
Quote
Quote
Actually, in this particular example, extending the signature length fails.  In all the reference builds (and even the SX10 dump) the GetFocusLensSubjectDistance function is followed immediately by another function instruction (either a STM or LDR then STM instruction set), but in the 200 dump, it is followed by a literal pool.  So allowing the reference function to extend beyond the initial 10 instructions actually disqualifies the correct function.
Right, but in this case I decided that 1 bad match is better than 17 (and many more sub-versions) with 4+ partial matches. If I remember right, the 10 instruction limit meant that actually only 3 instructions were actually used (because as mentioned earlier, the sig finder ignores some instructions).
How can you tell how many instructions it uses?  In the signatures_dryos.h file, the signature carries 8 of the 10 instructions (looks like it always ignores STM/LDM instructions)


Quote
No, it doesn't follow branches at all. Updating it means re-working the whole system, because it will affect all existing files.  The ability to branches has long been on my list of things for a "next generation" sig finder. Really, we shouldn't use the automatically generated files directly. Once a function is found and known correct, it should be "frozen" and only updated if needed (but somehow, we should maintain the information of how it was found in the first place). The whole thing is a hack and doesn't really scale to the number of cameras variants we have. It is also horribly inefficient, meaning that a full build of all the platforms, with sig matching takes well over an hour on my windows system.

I agree that manually verified and inserted functions are best, but at least the sig generator helps a little.  Especially in a case like this where I'm trying to correct/add some functions and there aren't necessarily people active and working on all the particular models anymore to do searching and testing.  At least there is a chance that the signature builder will help find them in some cases.
I think if it could extend to direct branch instructions as suggested it may help a little too, at least for functions that get shortened in this manner.  The difficulty would be in deciding what branches to follow.  One suggestion is that it uses the user input length (in this case 10).  If a branch is detected, it continues and follows that branch as if no length is present.  If it isn't a branch, it acts as usual.
Logged
*

Offline reyalp

  • ******
  • 14125
Re: DoF values and other related items
« Reply #34 on: 26 / November / 2009, 20:20:59 »
Quote from: barberofcivil on 26 / November / 2009, 20:04:29
How can you tell how many instructions it uses?  In the signatures_dryos.h file, the signature carries 8 of the 10 instructions (looks like it always ignores STM/LDM instructions)
Looking in the .h file. I guess I misread or misremembered. Basically, I looked at a couple cameras, saw it spewed out a bunch of alts, and realized that the old version had unlimited length and worked fine. Additionally, leaving the sig unchanged meant I didn't actually have to verify verify camera, since it was already known working.
Quote
I agree that manually verified and inserted functions are best, but at least the sig generator helps a little.  Especially in a case like this where I'm trying to correct/add some functions and there aren't necessarily people active and working on all the particular models anymore to do searching and testing. 
I'm not saying ditch the sig finder. Automatic function finding is great. Even the primitive system we have now saves a huge amount of work. What I'm saying is that we shouldn't be in the situation where fixing/improving the sig finder breaks existing, known working functions.

How exactly to accomplish this in a way that preserves the convenience of the sig finder isn't clear to me yet. You could simply migrate known working functions to stubs_entry_2, but if you ever want to rename/update you have a big hassle (for simple things you can use multi-file search/replace, but it can easily get out of hand). The other thing is you lose the information of how the function was found in the first place. You wouldn't notice that the sig finder could no longer find a particular function until you had a new sub or port.
Quote
At least there is a chance that the signature builder will help find them in some cases.
I think if it could extend to direct branch instructions as suggested it may help a little too, at least for functions that get shortened in this manner.  The difficulty would be in deciding what branches to follow.  One suggestion is that it uses the user input length (in this case 10).  If a branch is detected, it continues and follows that branch as if no length is present.  If it isn't a branch, it acts as usual.
If I'm going to dig into that mess, it's not going to be for some minor tweaks ;)
Logged
Don't forget what the H stands for.
*

Offline barberofcivil

  • ****
  • 268
    • deviantART Gallery
Re: DoF values and other related items
« Reply #35 on: 26 / November / 2009, 20:38:07 »
Quote from: reyalp on 26 / November / 2009, 20:20:59
The other thing is you lose the information of how the function was found in the first place.
Perhaps we could have a thread for adding function finding documentation for future reference?  I could add the info for these functions as I have already basically outlined it here in this thread, but this thread could easily become buried down the road.
Logged
*

Offline reyalp

  • ******
  • 14125
Re: DoF values and other related items
« Reply #36 on: 26 / November / 2009, 20:54:31 »
Quote from: barberofcivil on 26 / November / 2009, 20:38:07
Quote from: reyalp on 26 / November / 2009, 20:20:59
The other thing is you lose the information of how the function was found in the first place.
Perhaps we could have a thread for adding function finding documentation for future reference?  I could add the info for these functions as I have already basically outlined it here in this thread, but this thread could easily become buried down the road.
Umm, that comment was in reference to improving the sig finder, and automatically found functions. If you make it so that known functions are frozen (rather than re-generating every time you build) then you can potentially lose the ability to find old functions automatically. I guess I'm not communicating this clearly but it doesn't matter unless one of us is going to re-write the thing.

For how to manually find the functions in the mentioned in the current discussion, the function names appear in the thread which should be good enough to find with forum search.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14125
Re: DoF values and other related items
« Reply #37 on: 26 / November / 2009, 21:49:27 »
Oops, I forgot to check stubs_entry_2.S for GetFocusLensSubjectDistanceFromLens so a number of cameras will be using nullsub for that.

edit:
should be corrected in changeset 844. If you downloaded any of the builds in between, you should update!
« Last Edit: 26 / November / 2009, 22:38:31 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline Hamster.78

  • *
  • 3
Re: DoF values and other related items
« Reply #38 on: 27 / November / 2009, 13:00:37 »
Hi barberofcivil and reyalp,

i have install the build 844, but i can't find the Option in DOF Calculator "Stacked"
My Camera are SX100 100c

many thanks
Hamster
Logged
SX100 100c
*

Offline barberofcivil

  • ****
  • 268
    • deviantART Gallery
Re: DoF values and other related items
« Reply #39 on: 27 / November / 2009, 13:05:24 »
Quote from: Hamster.78 on 27 / November / 2009, 13:00:37
Hi barberofcivil and reyalp,
i have install the build 844, but i can't find the Option in DOF Calculator "Stacked"
My Camera are SX100 100c
many thanks
Hamster

This hasn't been added yet, it is part of my test builds for a bit of overhaul of the DoF calculator.  All that was added to the trunk so far was the signature and entry points for the GetFocusLensSubjectDistanceFromLens and GetFocusLensSubjectDistance functions.

Once I have finished and tested my DoF calculator work, I can present it for testing/addition to the autobuild trunk.
Logged
Pages: 1 2 3 [4] 5 6   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal