CHDKPTP - PC Remote Control Performance Analysis - page 39 - RAW Shooting and Processing - CHDK Forum
« previous next »
Pages: 1 ... 34 35 36 37 38 [39] 40 41 42 43 44 ... 47   Go Down

CHDKPTP - PC Remote Control Performance Analysis

  • 465 Replies
  • 101809 Views
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #380 on: 05 / October / 2012, 15:12:48 »
Advertisements
THE S90 ISO DROP to 100 AFTER {shoot -sv > 100} LIVEVIEW BRIGHTNESS PROBLEM in M MODE

@reyalp

OK I understand // thanks.  From your clarifications and my experiments I think I have been able to synthesize some ideas. 

DESCRIPTION
So we can say that in general for all cameras, after a {shoot -tv -av -sv} the internal parameter states are undefined, and, in modes other than M, are typically recomputed by the camera after a shoot half.  Hence specific to S90 M mode I have been able to determine thus that the original Canon preset Tv and Av are preserved after a {shoot -tv -av}.  But after a {shoot -tv -av -sv} Canon preset Sv is not preserved in the same way Tv and Sv are.  Furthermore, when one specifies -sv>100 in the shoot command, the Canon Sv always drops to 100 internally (even though Canon ISO icon remains at original value), and stays that way until manually reset, even though images are always exposed at the desired -sv (i.e. the -sv override works correctly for the JPG despite the internal  Canon Sv and dark liveview states of ISO100).

MY POOR WORKAROUND
Here is the workaround code that recovers the preset Canon ISO that existed before shoot -sv>100 by simulating a manual reset in script.  Because of Canon's lethargic OSD operations, this is a *very poor* workaround because it adds a precious 1.2 sec after every shoot essentially contradicting in part srsa's hopeful solution to reduce overall shoot processing time with his post-shoot write-detection attempt (eliminating the dependency on the hard-coded worst-case SD write stall overkill sys.sleep(2400) below, for more than 99% of shots).

Code: [Select]
-- usage: >!remote_shoot(1/8, 2.8, 400, "C:\\CANON_S90\\")
function remote_shoot(tv, av, canon_sv, destdir)  -- shoots from CHDKPTP and transfers the image to PC deleting SD card DCIM subdirectories after every shot.
sv = canon_sv / 1.6461 -- ISO correction for S90 so that CHDK EXIF data is the same as Canon.
cli:execute('shoot -tv='..tv..' -av='..av..' -sv='..sv..'')
sys.sleep(2400)
con:execwait('click "set"')
sys.sleep(400)
con:execwait('click "left"')
sys.sleep(200)
con:execwait('click "right"')
sys.sleep(200)
con:execwait('click "set"')
sys.sleep(400)
local l,r=con:execwait('return get_meminfo().free_size')
print(" free", r)   
printf(" free: %s\n",r)   
dcimdl(destdir, true, false)
end
HELP?
Because you are saying that you have not yet characterized this behavior, in the meantime could you help me replace the four calls to click into one say expedient call that does the same thing?  A much better workaround?  There are a few set ISO calls in your library.  I did not know which and how to parametrize, but nonetheless I basically tried some variations of this:

  > shoot
  > set_sv96(some arbitrary value)

.. but they didn't seem to work.

So I think the C-like psuedocode that probably might work on all cameras in M mode ... if possible to do? ...

   remote_shoot(tv, av, sv, destdir)
     {
     save_tv = get_tv() from camera
     save_av = get_av() from camera
     save_sv = get_sv() from camera
     shoot(tv av sv)          <<== the S90 Sv problem
     set_tv(save_tv)
     set_av(save_av)
     set_sv(save_sv)         <<== the much faster S90 Sv workaround solution ?? ==> hope liveview goes bright again.
     dcimdl(destdir)
     }

Could you help?  Some new solution ideas?  A workable code snippet that I could explore?
Logged
*

Offline reyalp

  • ******
  • 13878
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #381 on: 05 / October / 2012, 17:11:30 »
Quote from: SticK on 05 / October / 2012, 15:12:48
So we can say that in general for all cameras, after a {shoot -tv -av -sv} the internal parameter states are undefined, and, in modes other than M, are typically recomputed by the camera after a shoot half.
First of all, this is behavior of chdk overrides, nothing specific to chdkptp "shoot" command. Secondly, it's actually more complicated than that.

If you want to actually understand what is going on, you need to break it down to the simplest test case and observe what actually happens on the camera, particularly with the propcases. Reference to the override code (core/shooting.c) may also be required, since the ISO override is more complicated than just setting a value in one propcase.
Quote
So I think the C-like psuedocode that probably might work on all cameras in M mode ... if possible to do? ...

   remote_shoot(tv, av, sv, destdir)
     {
     save_tv = get_tv() from camera
     save_av = get_av() from camera
     save_sv = get_sv() from camera
     shoot(tv av sv)          <<== the S90 Sv problem
     set_tv(save_tv)
     set_av(save_av)
     set_sv(save_sv)         <<== the much faster S90 Sv workaround solution ?? ==> hope liveview goes bright again.
     dcimdl(destdir)
     }

Could you help?  Some new solution ideas?  A workable code snippet that I could explore?
I don't think this approach is likely to work, my feeling is that the problem is the cameras state getting confused in a way that simply saving/restoring the values modified by overrides isn't going to fix. If you do want to try it, basically all you have to do to turn your pseudocode into code is use the right function names. Note that you can do this all in camera side code. Assuming you are are using the CLI shoot command, you can just modify rliblua rlib_shoot.

As an alternative, what if you just set your ISO using the canon UI, and didn't send an -sv in your shoot command ?
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #382 on: 05 / October / 2012, 17:49:45 »
Quote "As an alternative, what if you just set your ISO using the canon UI, and didn't send an -sv in your shoot command ?"

Of course one can.  However ... the whole driving force behind my suggestions to implement the new shoot was exactly not to have to manipulate the (lethargic) Canon menus to set the shooting parameters.  Naturally, one can manipulate the Canon values through scripting click functions as I just demonstrated in my script, but that's defeating the purpose of the new shoot: to be able to do it numerically at random.  Because I'd be manipulating a jog dial or scale positions, the prior parameter state cannot be ever guaranteed if I want to do all that programmatically and get predictable behavior.  On top of it all, going from ISO 1600 to ISO 400 for example is a lot of clicks first to shoot, and then an equivalent lot of clicks to get back the bright liveview -- many seconds.  As you can see, there are significant opponents to scripting clicks to do this. Hence I *really* like the new shoot function, but this -sv ISO 100 dark liveview thing is giving it a stumbling block.

Quote "I don't think this approach is likely to work"

I agree in principle, but would like to give a stab.

Quote "If you do want to try it, basically all you have to do to turn your pseudocode into code is use the right function names."

Obviously yes, but I don't know how to do it and is why I asked you for help, some examples, e.g. getting and saving values.  I think there is a chance it might work.

Quote "you can just modify rliblua rlib_shoot"

Sure.  Before I approached you, I did go through the shoot command too and did see rlib_shoot in there thinking that could be one place to go further, but likewise, it was as far as I got because I don't know what to do next.  I am still in the same position.  Can you offer some snippet examples?
Logged
*

Offline reyalp

  • ******
  • 13878
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #383 on: 05 / October / 2012, 22:13:18 »
Quote from: SticK on 05 / October / 2012, 17:49:45
Of course one can.  However ... the whole driving force behind my suggestions to implement the new shoot was exactly not to have to manipulate the (lethargic) Canon menus to set the shooting parameters.
Look, I understand that the current behavior is a problem for you, there's no need to keep trying to explain why it's a problem. The fact is I don't have a solution right now, so I'm offering you other less optimal ideas.
Quote
Can you offer some snippet examples?
The set_* functions usually have a corresponding get_* function.
http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page
Getting the values before the existing set_* calls and calling set_* to restore them at the end should be trivial.
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #384 on: 05 / October / 2012, 23:44:25 »
Quote "Getting the values before the existing set_* calls and calling set_* to restore them at the end should be trivial"

As I mentioned earlier, there are a few varieties of these and I did not which ones to use.  So put in another way, which two are the fully complementary ones and the ones I should use to attempt this?
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #385 on: 06 / October / 2012, 13:46:17 »
CHDKPTP ADJUSTABLE 2-pixel-thick PRECISION CROSSHAIR RETICLE  Post 1 of 2

This is full-featured black|white reticle that you can position anywhere in your liveview, with a variable size and aperture.  It demonstrates extensibility and user-customizable Lua scripting capabilities of CHDKPTP.  A simple code editor (such as Notepad++) was the only development tool needed.  No compilation is necessary.

Procedure to align reticle in the center of your camera live viewport:
  > Set x and y position spin control to 0,0.
  > Shoot JPG of a small round subject that fits inside your reticle aperture.
  > In your image tool find the center of the JPG (use largest size format in your camera).  See Fig 2 for an example.
  > Correct reticle position by hard-coding h_cntr_ofs and v_cntr_ofs in gui_live.lua so that the reticle is centered on the small round object and matches JPG image center.
  > Iterate.

Figures 1 and 2 demonstrate the final result for an S90 using a correction vector of [1,0].  Fig 1 uses a superposed on-screen pixel magnifier to aid in alignment.  With the S90's amazing 720x540 liveview, centering precision is truly extraordinary.  The core function is draw_crosshair().

Notes: My additions to gui_live.lua are bracketed between SticK and ~SticK for easy search.  CD canvas operations are in the mathematical (x,y) graph coordinate system, that is, the y value reference is inverted relative to the usual screen coordinate system.  Spin control values are in absolute pixel values, that is, reticle characteristics remain the same whether you select a large or small view. There is no warning if you position your reticle outside your liveview.

Caveats: AFAIK, IUP dose not appear to allow direct entry of a minus sign in its spin control.  If you want to enter a negative value, spin to an arbitrary negative value and enter the digits.  However, if you hold down the spin button the control accelerates the value automatically: in Windows the increment is multiplied by 5 after 2 seconds and multiplied by 20 after 5 seconds of a spin button held down.  Thus you can change the size and place the reticle very quickly anywhere on your liveview just by using the spin buttons. 

Code is in Post 2 of 2.

@reyalp
This is supposed to be a generic solution.  If you can validate on another camera satisfactorily, you may wish to add this feature to your standard release.  Note that I increased the default fps to 22 and the default viewport size to 360x270 in Version 2 here.  BTW, CHDK+CHDKPTP is very powerful // this kind of performance is impossible to achieve with Canon software.

~SticK~

edit: Fig 1 was done before the position controls were inserted // the code does have position controls.
« Last Edit: 06 / October / 2012, 14:25:36 by SticK »
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #386 on: 06 / October / 2012, 13:47:55 »
CHDKPTP ADJUSTABLE 2-pixel-thick PRECISION RETICLE  Post 2 of 2

Replace gui_live.lua in your CHDKPTP lua\ directory with the attached version.
« Last Edit: 06 / October / 2012, 15:27:59 by SticK »
Logged
*

Offline reyalp

  • ******
  • 13878
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #387 on: 06 / October / 2012, 16:12:36 »
Quote from: SticK on 05 / October / 2012, 23:44:25
As I mentioned earlier, there are a few varieties of these and I did not which ones to use.  So put in another way, which two are the fully complementary ones and the ones I should use to attempt this?
The obvious place to start would be the ones with exactly matching names, e.g
sv_save=get_sv96()
...
set_sv96(sv_save)
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #388 on: 07 / October / 2012, 18:29:31 »
NEW: ISO Override compound Problem -- I hope my efforts here will give you more clues ... After two days of chasing the liveview dimming issue, I discovered the ISO problem to be deeper than originally believed.  It's because I've been looking at EXIF all this time and not the actual photos.

I exhausted all the possibilities and minimized the steps to:
  #1) shoot_half is enough to reproduce the dimming problem.  Example:
       > manually set camera to ISO 1600
       > save_sv = get_sv96()  (get_sv* do *seem* to return reasonable values)
       > set_sv96(save_sv)    <<== culprit in my opinion
       > shoot_half
       > liveview dims to ISO 100           
  #2) In rlib_shoot, set_sv96() does change EXIF correctly ... but ... camera takes shot using the presently set camera ISO value,
       and then drops the camera ISO value to 100, as noted in earlier posts.  Example, all via CHDKPTP ...
          > manually set camera to M mode, Tv to 1/4, Av to 2, ISO to 1600
          > Icon displays ISO1600 // OK.
          > shoot -tv=1/4 -av=2 -sv=400
          > JPG: EXIF ISO=400 Ok ....
          > ... **but** real photo exposure is at ISO 1600 -- bright photo -- override did not work, but I did not notice this until now
          > camera then gets set "internally" to ISO 100 (the liveview dimming nastiness I've been reporting)
          > Icon still displays ISO1600
          ------- next shoot -------
          > shoot -tv=1/4 -av=2 -sv=800
          > JPG:  EXIF ISO=800, Ok ...
          > ... **but** real photo is now exposed at ISO 100, the dimmed "internal" value from previous shoot (override did not work again)
          > camera stays at ISO 100 "internally"
          > Icon still displays ISO1600
          -------- subsequent shoots are exposed at ISO 100 regardless of shoot -sv setting, until I jog the ISO value manually --------------
  #3) set_sv96_direct() does not appear to do anything.  For example. if I modify rlib_shoot
        from set_sv96() to set_sv96_direct() (the preference in your docs) then when I shoot
        nothing happens at all, the camera is silent, as though shoot is entirely skipped over.

CONCLUSION

The ISO override problem definition: EXIF responds correctly to set_sv96() in rlib_shoot,
       but the camera does not take the shot at the override value.  That means the override only
       affects the EXIF ISO value but not the real exposure: the two don't match.  Overall, none of
       the set_sv* calls appear to work as expected, to me, AFAICT.  The problem is not
       exclusive to M mode.  I tried P mode and basically same.  I understand yours is Digic IV, so
       you should be able to reproduce my #2 very easily.

From the user's view, it is as though set_sv96() attempts the override but is only partially successful.  It seems ISO override, likely somewhere in CHDK->camera, is in the ballpark but not quite there.  So I think this "liveview dimming nastiness" that has been bothering me (and me bugging you too!) all along might be a side-effect of partially-functional ISO override.  Maybe that when you fix the ISO override the dimming problem will go away too, and end up working as well as Tv and Av overrides, I hope.

Just as programmatic Tv override (which works perfectly) is mission-critical, programmatic ISO override is too.  Could you please have a serious look at this?  I am very much looking forward to your examination of these new clues and your help.  This looks like the last major obstacle for Phase II acceptance // I see light at end of tunnel!  If you need something more from me, please do ask.

       
Logged
*

Offline reyalp

  • ******
  • 13878
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #389 on: 07 / October / 2012, 19:55:47 »
Quote from: SticK on 07 / October / 2012, 18:29:31
  #3) set_sv96_direct() does not appear to do anything.  For example. if I modify rlib_shoot
        from set_sv96() to set_sv96_direct() (the preference in your docs) then when I shoot
        nothing happens at all, the camera is silent, as though shoot is entirely skipped over.
That's because there is no such function, only tv and av have _direct variants. If you did error checking, you'd know this. Please don't waste my time with nonsense like this.
Quote
Could you please have a serious look at this?
If ISO overrides don't work at all on this camera, that's definitely a problem. Can you please test this using ISO override from the CHDK menu ?

I'm not sure which build you are using at this point, the following instructions apply to 1.1 builds. If you are using 1.2, the menus will be slightly different
0) Power on the camera, not plugged into usb.
1) In the canon menu, set ISO 100 and a select a Tv and Av that give you reasonable exposure
2) Take a shot
3) In the chdk "Extra photo operations" menu
3a) make sure "disable overrides" is "off"
3b) In "Override ISO Value", select 8
3c) in "Value factor" below "Override ISO value" select 100
4) leave the chdk menu and take a shot
5) Compare the exposure of the two shots. The second shot should be over exposed significantly.

edit:
Quote
So I think this "liveview dimming nastiness" that has been bothering me (and me bugging you too!) all along might be a side-effect of partially-functional ISO override
This is most likely wrong, since I see the live view effect on my a540, which has working ISO override.
« Last Edit: 07 / October / 2012, 20:03:02 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 ... 34 35 36 37 38 [39] 40 41 42 43 44 ... 47   Go Up
« previous next »
 

Related Topics