Proposed changes to script parameters - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 [3] 4 5 6   Go Down

Proposed changes to script parameters

  • 52 Replies
  • 17302 Views
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Proposed changes to script parameters
« Reply #20 on: 21 / December / 2014, 23:45:04 »
Advertisements
Quote from: philmoz on 21 / December / 2014, 23:27:57
I think this works well. It reduces the initial section of the llibtst.lua script from (scroll to see entire code section):
Very nice.

Is the trailing bool keyword still optional or did you delete that part ? (or is it just ignored at the end of the line maybe?)

edit  : looked at the code - it's still there
« Last Edit: 21 / December / 2014, 23:47:49 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 13938
Re: Proposed changes to script parameters
« Reply #21 on: 25 / December / 2014, 17:57:36 »
Quote from: philmoz on 21 / December / 2014, 23:27:57
Quote from: waterwingz on 21 / December / 2014, 14:52:40
Quote from: philmoz on 21 / December / 2014, 13:47:01
Do you mean you want to be able to use 'true' and 'false' as the initialiser value?
Correct.  Seems consistent with how a Lua script should work?

Added in revision 3839.

I think this works well. It reduces the initial section of the llibtst.lua script from (scroll to see entire code section):
FWIW, I expected this to return an actual boolean value in lua if I put true/false in the initialization.

I think it's a bit confusing this way, since
Code: [Select]
#foo=false
if foo then
...
end
will always be true.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: Proposed changes to script parameters
« Reply #22 on: 25 / December / 2014, 19:57:43 »
Quote from: reyalp on 25 / December / 2014, 17:57:36
Quote from: philmoz on 21 / December / 2014, 23:27:57
Quote from: waterwingz on 21 / December / 2014, 14:52:40
Quote from: philmoz on 21 / December / 2014, 13:47:01
Do you mean you want to be able to use 'true' and 'false' as the initialiser value?
Correct.  Seems consistent with how a Lua script should work?

Added in revision 3839.

I think this works well. It reduces the initial section of the llibtst.lua script from (scroll to see entire code section):
FWIW, I expected this to return an actual boolean value in lua if I put true/false in the initialization.

I think it's a bit confusing this way, since
Code: [Select]
#foo=false
if foo then
...
end
will always be true.

Oops - I broke it in revision 3839.
Should be fixed in 3854.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline reyalp

  • ******
  • 13938
Re: Proposed changes to script parameters
« Reply #23 on: 28 / December / 2014, 16:29:58 »
A thought that occurred to me: In complicated scripts, I tend to have a bunch of menu options that get massaged into the a real value (e.g some input to APEX*96, seconds to ms etc.) and then never used again.

Having them as globals makes naming them more difficult, since you have foo from the menu and foo_real that for actual use in the code.

If we put all the menu options in a table (args, or menu or script_menu) they would be nicely namespaced, and it would be clear in the code when you referring to them. You could also free them if you wanted by setting the table to nil when you were done with them.

This isn't a big deal one way or the other to me, just a thought. A table might be more confusing to newbies.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Proposed changes to script parameters
« Reply #24 on: 28 / December / 2014, 16:48:22 »
Quote from: reyalp on 28 / December / 2014, 16:29:58
In complicated scripts, I tend to have a bunch of menu options that get massaged into the a real value (e.g some input to APEX*96, seconds to ms etc.) and then never used again.
A big chuck of that for me is renaming single character menu @parameter variables to more descriptive names.  At least that will be fixed in 1.4 !

Quote
Having them as globals makes naming them more difficult, since you have foo from the menu and foo_real that for actual use in the code.
Any reason you can't just use

Code: [Select]
foo = convert_function(foo) rather than

Code: [Select]
foo_new = convert_function(foo)I'm probably missing something here ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: Proposed changes to script parameters
« Reply #25 on: 28 / December / 2014, 17:02:07 »
waterwingz beat me to it - I was going to make the same comments :)

Having said that, putting the parameters into a table would be pretty easy and might have some benefit for readability. I would suggest making this optional (e.g. add a '#namespace name' control to the script header).

I also realised I haven't added these script parameter changes to SVN yet, so I'll do that soon.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline reyalp

  • ******
  • 13938
Re: Proposed changes to script parameters
« Reply #26 on: 28 / December / 2014, 17:07:17 »
Quote from: waterwingz on 28 / December / 2014, 16:48:22
A big chuck of that for me is renaming single character menu @parameter variables to more descriptive names.  At least that will be fixed in 1.4 !
Oh no doubt, it's a huge improvement. Thanks phil  :xmas

Quote
Any reason you can't just use
Code: [Select]
foo = convert_function(foo) rather than
Code: [Select]
foo_new = convert_function(foo)I'm probably missing something here ?
Not really, mostly just my OCD wanting them to be self contained by default  :-[
In my case the new value usually goes into a non-global like table member or function argument. I also sometimes have multiple things derived from the initial foo.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13938
Re: Proposed changes to script parameters
« Reply #27 on: 28 / December / 2014, 17:08:47 »
Quote from: philmoz on 28 / December / 2014, 17:02:07
I would suggest making this optional (e.g. add a '#namespace name' control to the script header).
Yeah, I thought about that too, but it may be over kill if I'm the only one who wants them in a table :P
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: Proposed changes to script parameters
« Reply #28 on: 28 / December / 2014, 22:17:54 »
Quote from: waterwingz on 21 / December / 2014, 10:58:59
With everything going on this week,  I'm thinking this may have been overlooked :

Quote from: waterwingz on 12 / December / 2014, 19:21:42
I've always thought that it would be nice if CHDK actually used the values in each camera's shooting.c file for  aperature_size_table[ ] , shutter_speeds_table[ ], and iso_table[ ]  for something more useful. 

One obvious thought would be to use the data there as the values available for custom Tv, Sv, and Av input fields in script parameters.

In theory,  these tables are tuned to the actual values each camera can use so that's even more powerful.  (Ignoring the possibility that many of them might have been C&P'd from other cameras).
While updating one of my scripts today,  I once again realized that user specified @param values (for Av in particular) allowed choices that the camera does not actually support.  And we have all the necessary information in each camera's shooting.c file to fix that.

There is probably a limit on how many specialized @param / #name things you might want to add but exposure values for a camera scripting system seem like they might be inside of that limit.

I guess I'll prototype something myself and see how it goes.

I initially thought using 'aperture_sizes_table', and 'shutter_speeds_table' from shooting.c to generate the '@values' list for a parameter would be pretty easy.

I started to do this then realised it gets complicated by the 'extended' ranges allowed in the menu overrides.
Aperture is extended by 2 stops beyond the smallest value (except for G1X where it is turned off).
Shutter speed is extended from very long to very short values.

So the question is should an Av or Tv parameter type be limited to the Canon values from shooting.c or the extended values from the override menu?

There is also at least one camera where the aperture table in shooting.c includes ND filter simulated values.

The next area that makes it more complicated is what values do you provide to the script via the parameter.
To be useful the script would probably need both the av96/tv96 value plus the string label for each entry - this is a bit more complicated than what I did for the 'table' options, haven't quite worked out the details yet.

Lastly - how do you specify the default value for the parameter in the script header (especially for Av)? The list of options available will be set at runtime on each camera, for example aperture[0] on the G12 is 2.8; but on the S100 it is 2.0.
So the default parameter value could select a different Tv or Av value. Unless we make it even more complex and set the default value in av96/tv96 units, then map it to the closest available entry when the script header is parsed.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Proposed changes to script parameters
« Reply #29 on: 29 / December / 2014, 09:50:05 »
Quote from: philmoz on 28 / December / 2014, 22:17:54
So the question is should an Av or Tv parameter type be limited to the Canon values from shooting.c or the extended values from the override menu?
As I see it,  this idea does a few useful things.

  • For Tv values, it let's you pick shutter speeds than match what the camera will store in the EXIF.  Right now on my A1200, if I select 1/35 of a second for shutter speed, the EXIF willl say 1/30 IIRC.
  • For Av values, you get a list of aperture sizes that can actually be set for the particular camera.  No point in trying for f1.8 on my A1200 for example.
  • For Sv values, your  range is limited to what the camera can do and the values are what you will expect to see in the exif.

I spent quite a bit of time getting those tables correct on my various ports, only to find out later that they are only used by a couple of obscure script functions ( get_user_Xv_id()  IIRC) ?   And I don't think I ever saw a formal description of what is supposed to be in there.  But it seems to me if you use this new script parameter type,  you should get what is in that table and that's it.   For Av & Sv value that should be adequate as you can't really extend either value much and when you do for Av the results look terrrible.    For Tv values, the existing range seems fine for most things.   

I'm thinking here in terms of CHDKplus.lua (for normal manual control photography) rather than meteor.lua (very long exposures).

One small additional wrinkle here for Av settings is that as zoom position changes,  the available f-stop range changes.  I think we will need to leave it up to the script to deal with that or not.

Incidentally,  it would be good to add an entry in that file for the ND filter density (in terms of stops).  It's usually 3.0 AFAIK but not always.

Quote
The next area that makes it more complicated is what values do you provide to the script via the parameter. To be useful the script would probably need both the av96/tv96 value plus the string label for each entry - this is a bit more complicated than what I did for the 'table' options, haven't quite worked out the details yet.
Returning just av96, sv96, & tv96 values gets most of it.  Being also able to get the associated string would be a bonus but you can add a list of string / apex96 pairs to the script and interpolate if necessary.  (That's what I do now).

Quote
Lastly - how do you specify the default value for the parameter in the script header (especially for Av)? The list of options available will be set at runtime on each camera, for example aperture[0] on the G12 is 2.8; but on the S100 it is 2.0.
Treat it as a zero based index into the table?  In the kind of applications where this functionality makes sense,  for any given camera you thereby get a semi-random but valid f-stop or shutter speed or ISO setting at startup.  The user can either change the default for their particular camera or reset the @param value by editing the script code.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 [3] 4 5 6   Go Up
« previous next »
 

Related Topics