1.3 development proposal - exposure conversion functions - page 6 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 4 5 [6]   Go Down

1.3 development proposal - exposure conversion functions

  • 58 Replies
  • 28374 Views
*

Offline lapser

  • *****
  • 1093
Re: Apex96 to string functions
« Reply #50 on: 09 / October / 2013, 01:24:22 »
Advertisements
Quote from: waterwingz on 09 / October / 2013, 00:07:08
I think I may understand your fascination with three decimal accuracy for Tv, Av, & Sv values,  but I'm pretty sure most people don't really care that much.  And I'm almost certain you won't tell the difference in the images you shoot.
What's important to me is that each tv96 value converts to a unique shutter time value, with the minimum # of digits. That's what the last column in the log file shows. I'm not talking about setting exposure or what the pictures look like. I'm talking about displaying the exposure accurately enough that you can tell when it changed. If the consensus is that this isn't important enough to have in the trunk, then I'll just leave it in my custom build.

Quote from: philmoz on 09 / October / 2013, 00:03:00
Hard to review without the source code?
Before getting into how they're implemented, I'd like you to look at what the functions do, and  decide if you want this capability in the trunk. I've documented the function input and output options, and demonstrated that they work, with the test script and log file.

waterwingz seems to think that nobody but me would use the functions, and that they're not worth putting in the trunk. If that's the consensus, then there's no point in wasting all our time looking at source code.

Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Apex96 to string functions
« Reply #51 on: 09 / October / 2013, 05:12:57 »
Quote from: lapser on 09 / October / 2013, 01:24:22
waterwingz seems to think that nobody but me would use the functions, and that they're not worth putting in the trunk. If that's the consensus, then there's no point in wasting all our time looking at source code.

I am certainly interested in the practical results of your day-to-night timelapse but as I mentioned, if I implemented the feature I would just display the Tv96 number.

That tells me it is changing by the smallest possible increment.


David
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Apex96 to string functions
« Reply #52 on: 09 / October / 2013, 06:32:29 »
Quote from: lapser on 08 / October / 2013, 22:55:48
I've finished writing 3 new CHDK functions for Lua to convert and display tv96, av96, and sv96 to human readable strings. Please take a look at them and let me know if you want to add them to the trunk as is. If so, I'll add them for uBasic and post a patch. Here's a description of the functions, a test Lua script that uses them, and the log produced by the script (attached):

tv96_to_string(tv96 [,ndig] [,scale])
  ndig: 0..9  precision (digits after decimal point) 1/x format starts at 1/4 second
          10..19 no 1/x format  precision is last digit (%10)
          -1: (default) automatic ndig   Change of 1 tv96 unit always gives unique result (see log)
          -2: automatic ndig   No 1/x format
  scale: (default 1) Result multiplier. I.E. 1000 for msec

av96_to_string(av96 [,ndig] [,scale])
  ndig: 0..9  precision (digits after decimal point)
          -1: (default) automatic ndig   Change of 1 av96 unit always gives unique result
  scale: (default 1) Result multiplier

sv96_to_string(sv96 [,ndig] [,scale])
  ndig: 0..9  precision (digits after decimal point)   MARKET ISO result
          10..19 REAL ISO result    precision is last digit (%10)
          -1: (default) automatic ndig   MARKET ISO
          -2: automatic ndig   REAL ISO
  scale: (default 1) Result multiplier

Code: [Select]
--[[
@title ApexStr 1
@param d Dummy
@default d 1
--]]
print_screen(1)
print("Apex to String Test")
set_console_autoredraw(-1)
print()
av=aperture_to_av96(1000)
avlast=aperture_to_av96(40000)
print("av96 from",av,"to",avlast)
av=0
avlast=1000 -- aperture_to_av96 overflows
print("av96 | aperture_to_av96 | to_aperture | to_string 3 | to_string -1")
repeat
  f0=av96_to_aperture(av)
  print(string.format("%d | %d | %d | %s | %s",av,aperture_to_av96(f0),f0,av96_to_string(av,3),av96_to_string(av,-1)))
  av=av+1
until av>avlast

print()
sv=iso_to_sv96(25);
svlast=iso_to_sv96(6400);
print("sv96 from",sv,"to",svlast)
print("sv96 | to_iso | to_string 10 | to_string -2 | to_string -1")
repeat
  print(string.format("%d | %s | %s | %s | %s",sv,sv96_to_iso(sv),sv96_to_string(sv,10),sv96_to_string(sv,-2),sv96_to_string(sv)))
  sv=sv+1
until sv>svlast

print()
tv=seconds_to_tv96(256,1)
tvlast=seconds_to_tv96(1,8192)
print("tv96 from",tv,"to",tvlast)
print("tv96 | to_usec | to_string 10,1000000 | to_string -2,1000 | to_string -1")
repeat
  print(string.format("%d | %s | %s | %s | %s",tv,tv96_to_usec(tv),tv96_to_string(tv,10,1000000),tv96_to_string(tv,-2,1000),tv96_to_string(tv)))
  tv=tv+1
until tv>tvlast
set_console_autoredraw(1)

I think the basic concept is worthwhile; but:
- there are far too many 'magic' numbers in the implementation.
- I don't understand the need for the scale parameters.

If I were implementing something like this I would pass the C style format string to the function instead of 'ndig', i.e.:
- "%f" = generic floating point format
- "%.2f" =  2 decimal places
- "%6.2f" = total width of 6 with 2 decimal places, right justified
- "%-6.2f" = total width of 6 with 2 decimal places, left justified

If you want to make the 1/X format optional in the Tv function, add another boolean parameter to control it - overloading parameters (ndig) with special meanings is a poor design practice.

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 lapser

  • *****
  • 1093
Re: Apex96 to string functions
« Reply #53 on: 09 / October / 2013, 13:59:46 »
Quote from: philmoz on 09 / October / 2013, 06:32:29
I think the basic concept is worthwhile; but:
- there are far too many 'magic' numbers in the implementation.
- I don't understand the need for the scale parameters.

If you want to make the 1/X format optional in the Tv function, add another boolean parameter to control it - overloading parameters (ndig) with special meanings is a poor design practice.
Thanks for the suggestions. I agree that it's good to avoid "magic numbers", but not at the expense of losing capability, like accuracy. One capability that you didn't mention is the variable precision of the output, based on the difference between the results for tv96 and tv96+1 (or sv, av). This "auto-ndig" capability is the main reason I wrote these functions.

The scale factor is important for choosing the units for the output, i.e. msec instead of usec. I would much rather output "1 usec" or "0.001 msec" than "0.000001" sec.  And "128 sec" is a lot easier to read than "128000000 usec".

tv96_to_usec(tv96) is fine, if all you want to output is usec within a limited range. But then we need a more flexible string output function, including a scale option.
Quote
If I were implementing something like this I would pass the C style format string to the function instead of 'ndig', i.e.:
- "%f" = generic floating point format
- "%.2f" =  2 decimal places
- "%6.2f" = total width of 6 with 2 decimal places, right justified
- "%-6.2f" = total width of 6 with 2 decimal places, left justified
I don't think implementing generic floating point is worth the effort. The width and justification can be done in the script with string.format(%s).

For tv96, 1/x format starts automatically at 1/4 seconds, like the camera displays. If we're adding another parameter, it would be nice to be able to change the crossover value.

So how about this definition?

tv96_to_string(tv96 [, ndig, inverse, scale])
optional paramters with default (optnumber)
ndig: 0..9: precision
      <0 or >9: automatic (default)
inverse: true: 1/x starting at 1/4 second (192 tv96)  (default)
         false: no 1/x
         number: tv96 value where 1/x starts. i.e. 96 to start at 1/2 second
scale:  multiplier (default 1)

For ubasic, I'd be happy with just 1 parameter, tv96, and the rest would use the default values. Lua would only require one parameter, so it would work the same way, but with more options.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: 1.3 development proposal - exposure conversion functions
« Reply #54 on: 10 / October / 2013, 07:13:59 »
An alternative approach to think about.

It seems to me the goal here is to convert an APEX96 value to a human readable string.

Why not use a single 'apex_to_string' function defined as:
    char* apex_to_string(int apex96, char* format)

Where:
- apex96 is the value to convert
- format is a control string to determine how the output is generated.

The format parameter takes the form:
    "[[-]w][.d]x"
where:
- w = pad output to 'w' width right justified unless the '-' is included, default is no padding
- .d = # of decimal digits to output, if not included then defaults to 0
- x = format control, one of the following
    - s = ISO conversion
    - S = ISO conversion, mapped to nearest Canon value
    - a = Aperture conversion
    - A = Aperture conversion, mapped to nearest Canon value
    - t or u = Shutter speed conversion
    - T or U = Shutter speed conversion, mapped to nearest Canon value

For shutter speed the following conversion rules would apply:
- t or T
    - > 1/4 second - output in seconds
    - <= 1/4 second - output as 1/X seconds
- u or U
    - >= 1 second - output in seconds
    - < 1 second, >= 1 millisecond, output in milliseconds
    - < 1 millisecond - output in microseconds

The 'u' or 'U' conversion would also need to append the units to the output (secs, msec or usec).

The 'S', 'A', 'T', and 'U' variations find the nearest Canon allowed value as defined in shooting.c. For values less than the minimum it could add a leading '<', and for greater than the max, add a '>'.

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 Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: 1.3 development proposal - exposure conversion functions
« Reply #55 on: 10 / October / 2013, 07:44:59 »
Quote from: philmoz on 10 / October / 2013, 07:13:59

It seems to me the goal here is to convert an APEX96 value to a human readable string.

I still do not get it, what is unreadable about APEX96 values ?

They are just a number, the user simply needs to detect they are changing by a unit increment (as far as the shot histogram application is concerned).
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: 1.3 development proposal - exposure conversion functions
« Reply #56 on: 10 / October / 2013, 09:25:13 »
Quote from: philmoz on 10 / October / 2013, 07:13:59
An alternative approach to think about.

....

The 'S', 'A', 'T', and 'U' variations find the nearest Canon allowed value as defined in shooting.c. For values less than the minimum it could add a leading '<', and for greater than the max, add a '>'.
Two thumbs up from me on this one.  Exactly what I was looking for.

Quote from: Microfunguy on 10 / October / 2013, 07:44:59
I still do not get it, what is unreadable about APEX96 values ?
I'd like to remind you that you frequently enjoy pointing out the difference between programmers and photographers.   Until one of the camera manufacturers starts selling cameras that display APEX96 values,  its would seem most photographers expect to see fractional seconds, f-stops and ISO sensitivity values in the UI.

Quote
They are just a number, the user simply needs to detect they are changing by a unit increment (as far as the shot histogram application is concerned).
Shot histograms is just one use case.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: 1.3 development proposal - exposure conversion functions
« Reply #57 on: 10 / October / 2013, 14:14:45 »
Quote from: waterwingz on 10 / October / 2013, 09:25:13
I'd like to remind you

As a matter of interest, does your present employment (if not retired) or previous employment involve the supervision of small groups of people ?

Logged
*

Offline lapser

  • *****
  • 1093
Re: 1.3 development proposal - exposure conversion functions
« Reply #58 on: 10 / October / 2013, 20:40:08 »
Quote from: philmoz on 10 / October / 2013, 07:13:59
An alternative approach to think about.
Those are some very good ideas, but it wouldn't do what my current functions do, in that it doesn't provide for a scale factor and automatic number of digits of precision based on (apex96+1). It would also take more work and code to implement. It seems like there are a lot of "magic letters" to learn too.

I'm leaning towards unifying all the conversion functions into two functions:

apex96_from(type, val, mult)
  type: "shutter", "iso", "aperture"
  val: value for shutter, iso, or aperture
  mult: multiplier (negative means use 1/val)
      (double) dval = val*mult or 1/(-mult*val)
      default if mult isn't present: 1
  returns: integer apex96 value
example: 1/3200 shutter  tv96=apex96_from("shutter",3200,-1)

apex96_to( type, apex96, mult, ndig)
  type: same as above, plus "*shutter","*iso", "*aperture" for string output
  apex96: tv96, sv96, or av96 based on type
  mult:: multiplier for result, negative means 1/x
            default if mult isn't present is 1
  ndig: for string types only
           #digits of precision 0 to 9, or -1 for auto.
          Default, if ndig isn't present is -1 auto
  returns: integer or string

For waterwingz request of returning only camera valid values, you could start the type with "=" instead of "*"

apex96_to("=shutter",apex96)
  would return a string with the nearest valid camera value. ndig and scale determined by valid value format
========
Before jumping on me for suggesting new things that have already been decided, what I'm considering doing is a separate patch for my own builds that I'll provide independently to those that want to use it, instead of trying to get it in the trunk. This will eliminate all the arguing, and free me up to think more creatively.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
Pages: 1 2 3 4 5 [6]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal