supplierdeeply

Converting APEX96 to human understandable units in scripts

  • 6 Replies
  • 1843 Views
Advertisements
I've been looking at quite a few scripts lately where the authors go to almost heroic lengths to convert between APEX96 values and "real world engineering units"  (i.e. f-stop or shutter speed in fractional seconds).

Yet in every camera port there is a shooting.c file with two mostly unused tables ( aperature_sized_tab[ ] and shutter_speeds_table[ ] ) that contains everything needed to do a really nice job of those conversions.

So I'm thinking that (at a minimum) we could add a couple of functions to uBASCIS & Lua to basically do a table lookup based on APEX96 values - something like :

Code: [Select]
-- convert apex96 value to string
string = apex96tvstring( apex96tv )
string = apex96avstring( apex96av )

-- convert fractional seconds to apex96 value
apex96tv = fraction_seconds_to_apex96( fract_seconds )
 
Obviously better function names would be needed.  And other conversions could be done with those tables - string to number type things.   It could also be pretty cool if the @param header allowed a "shutter speed" and "aperature setting" and "ISO value"  @camera function.

Did a miss a much easier way to do this?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1239
  • A720 IS, SX220 HS 1.01a
    • CHDK inside
Re: Converting APEX96 to human understandable units in scripts
« Reply #1 on: 11 / May / 2013, 13:59:41 »
Atm I use this method:

Code: (lua) [Select]
function print_av(val)
     local i = 1
     local av_str = {"n/a","2.0","2.2","2.5","2.8","3.2","3.5","4.0","4.5","5.0",
                     "5.6","6.3","7.1","8.0","9.0","10.0","11.0","13.0","14.0","16.0"}
     local av_ref = {176,208,240,272,304,336,368,400,432,
                     464,496,528,560,592,624,656,688,720,752}
     while (i <= #av_ref) and (val > av_ref[i]-1) do i=i+1 end
     return av_str[i]
end

'val' must be an av96 value. It works similarly for Tv. But the lookup table is bigger.

msl
German CHDK pages:  CHDK forum | CHDK inside | CHDK Twitter News by msl | Download CHDK-DE (Autobuild)
Note: SDM violates the GPL rules!

Re: Converting APEX96 to human understandable units in scripts
« Reply #2 on: 11 / May / 2013, 14:21:21 »
Atm I use this method:
Code: (lua) [Select]
function print_av(val)
     local i = 1
     local av_str = {"n/a","2.0","2.2","2.5","2.8","3.2","3.5","4.0","4.5","5.0",
                     "5.6","6.3","7.1","8.0","9.0","10.0","11.0","13.0","14.0","16.0"}
     local av_ref = {176,208,240,272,304,336,368,400,432,
                     464,496,528,560,592,624,656,688,720,752}
     while (i <= #av_ref) and (val > av_ref[i]-1) do i=i+1 end
     return av_str[i]
end
'val' must be an av96 value. It works similarly for Tv. But the lookup table is bigger.
msl
Thanks msl.  That's an great example of what I meant when I said "heroic lengths".  Lots of code for something that could be built-in - and its something that needs to change from camera to camera.  In theory,  the shooting.c tables  are already setup for each camera so scripts become more camera independent.

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1239
  • A720 IS, SX220 HS 1.01a
    • CHDK inside
Re: Converting APEX96 to human understandable units in scripts
« Reply #3 on: 11 / May / 2013, 15:01:59 »
In theory,  the shooting.c tables  are already setup for each camera so scripts become more camera independent.

The shooting.c tables have only the standard values. And what is with the extended override values? Another solution would be to create a lua library for such tasks.

msl
German CHDK pages:  CHDK forum | CHDK inside | CHDK Twitter News by msl | Download CHDK-DE (Autobuild)
Note: SDM violates the GPL rules!


Re: Converting APEX96 to human understandable units in scripts
« Reply #4 on: 11 / May / 2013, 15:12:33 »
The shooting.c tables have only the standard values. And what is with the extended override values?
That's what I like about them - they have only the values that the Canon firmware will be putting into the exif.  No "funny" shutter speeds like 1/43 sec.   And more important,  if they are setup correctly then the table should tell you the min & max values that each camera actually supports.

Quote
Another solution would be to create a lua library for such tasks.
That's a good solution too - other than it not knowing what the actual range is for the camera its running on.

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1239
  • A720 IS, SX220 HS 1.01a
    • CHDK inside
Re: Converting APEX96 to human understandable units in scripts
« Reply #5 on: 11 / May / 2013, 16:34:20 »
Need we really a min/max range? The technical description of each camera give us this information.

What we need is human readable standard value without calculated value like your example. We get an APEX96 value and need a standard readable unit.

When I override Tv, e.g. set_tv96(-480) for 32.0 s, I use a lookup table with this value. schooting.c will not help.

The minimal (override) Av value is limited by CHDK. In the case of the SX220 I can use f9.0 or f10.0 as override. Here I need also an extended table.

A special case is the ISO thing. We should first clarify whether we want to use the real or market values. There is also problem with the start value. Some cameras start with ISO80, other with  ​​ISO100 (and older cams with ISO50).

msl
German CHDK pages:  CHDK forum | CHDK inside | CHDK Twitter News by msl | Download CHDK-DE (Autobuild)
Note: SDM violates the GPL rules!

*

Offline reyalp

  • ******
  • 11541
Re: Converting APEX96 to human understandable units in scripts
« Reply #6 on: 11 / May / 2013, 18:23:53 »
This is an important topic.
Need we really a min/max range? The technical description of each camera give us this information.
For Av, the valid values depend on zoom setting too, so even the cameras total range is not really helpful in many situations.

For menu inputs, it's seems to me the right way to do it would be to have an @ parameter that lets you specify the type as tv, av or iso. This would display the same sort of UI used by overrides, and would set the variable to a APEX96 value. This would be particularly useful for Tv.

Most of the code for this should already exist, but wrangling it into the script code may be unpleasant.

A standard module for working converting APEX96 values would be a very good addition for lua.

For uBASIC, things are more complicated. Not only do we not have modules, we don't have string variables. I would be inclined to say that people who want this kind of capability should use Lua.

Real vs market ISO is another thing that would be great to resolve. One approach would be simply to require every port to have an empirically generated table (like the zoom tables etc). You could do simple interpolation for values that aren't in the table. This is not hard to generate for new ports, but creating it for all the existing ones would be difficult.

Alternatively, functions or tables to convert between the two must exist in the firmware. If they could be found automatically, that would make adding support much easier.
Don't forget what the H stands for.

 

Related Topics