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

1.3 development proposal - exposure conversion functions

  • 58 Replies
  • 12495 Views
*

Offline waterwingz

  • ******
  • 12016
    • Waterwingz
1.3 development proposal - exposure conversion functions
« on: 10 / August / 2013, 12:12:54 »
Advertisements
As I work through lapser's patch file for his shot_histogram_request mods and remove things not related to that,  I stumbled on his "real world to APEX96" functions.

Code: [Select]
+    FUNC(shutter_to_tv96)
+    FUNC(tv96_to_shutter)
+    FUNC(iso_to_sv96)
+    FUNC(sv96_to_iso)
+    FUNC(aperture_to_av96)
+    FUNC(av96_to_aperture)
They are not really part of the shot_histogram & continuous shooting exposure adjust code so I guess I'll strip them out too.   

But is "somebody" going to add the equivalent as part of 1.3.0 (or as part of the real vs market ISO conversion) ?

I can do it but I'm assuming it needs to be tied to the fixes for ISO in 1.3.0?

UPDATE :  patch file of lapser's apex96 Lua conversion functions attached
 
« Last Edit: 24 / August / 2013, 14:51:48 by reyalp »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3155
    • Photos
Re: Re: 1.3 development planning thread
« Reply #1 on: 10 / August / 2013, 20:55:13 »
Quote from: waterwingz on 10 / August / 2013, 12:12:54
As I work through lapser's patch file for his shot_histogram_request mods and remove things not related to that,  I stumbled on his "real world to APEX96" functions.

Code: [Select]
+    FUNC(shutter_to_tv96)
+    FUNC(tv96_to_shutter)
+    FUNC(iso_to_sv96)
+    FUNC(sv96_to_iso)
+    FUNC(aperture_to_av96)
+    FUNC(av96_to_aperture)
They are not really part of the shot_histogram & continuous shooting exposure adjust code so I guess I'll strip them out too.   

But is "somebody" going to add the equivalent as part of 1.3.0 (or as part of the real vs market ISO conversion) ?

I can do it but I'm assuming it needs to be tied to the fixes for ISO in 1.3.0?

UPDATE :  patch file of lapser's apex96 Lua conversion functions attached

The ISO conversion is using the old CHDK equation for 'real' ISO. It needs to be updated to use the 1.3 conversion.

Not sure I see the need for the optional 'scale' parameter in all of the functions - the level of inaccuracy in the integer conversion means you're not going to get much better than using a default value of 1000.
This would also simplify the code.
Edit2: The other option here is to use the imath library fixed point type for shutter speed and aperture (instead of multiplying everything by 1000 / 'scale').

Personally I would also lose the convert96 function and move the conversion code into the calling functions.

Edit: I also don't like the way the 'shutter_to_tv96' treats negative numbers as a special case so that -2000 and 500 both mean 1/2 second shutter speed.

Phil.
« Last Edit: 10 / August / 2013, 21:02:25 by philmoz »
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)
*

Offline reyalp

  • ******
  • 12537
Re: Re: 1.3 development planning thread
« Reply #2 on: 10 / August / 2013, 22:10:54 »
Quote from: philmoz on 10 / August / 2013, 20:55:13
Edit2: The other option here is to use the imath library fixed point type for shutter speed and aperture (instead of multiplying everything by 1000 / 'scale').
Possibly an imath based standard Lua module would be sufficient, and these don't need to go into the core at all?
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12016
    • Waterwingz
Re: Re: 1.3 development planning thread
« Reply #3 on: 11 / August / 2013, 13:42:17 »
Quote from: reyalp on 10 / August / 2013, 22:10:54
Quote from: philmoz on 10 / August / 2013, 20:55:13
Edit2: The other option here is to use the imath library fixed point type for shutter speed and aperture (instead of multiplying everything by 1000 / 'scale').
Possibly an imath based standard Lua module would be sufficient, and these don't need to go into the core at all?
As long as we are okay with leaving the uBASIC user base farther and farther behind?

At some point,  I suppose we could just give the users a turing machine simulator and let them code from there  :haha

Seriously though,  it seems like these are pretty much core functionality for a package that is supposed to be about photography.   

I'm also in favor of a extending the @param pragma to allow user entry in ISO units,  Tv seconds, or Av f-stop numbers from the Script  menu,   returning the apex96 equivalent to the script itself. 
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 12537
Re: Re: 1.3 development planning thread
« Reply #4 on: 11 / August / 2013, 14:10:56 »
Quote from: waterwingz on 11 / August / 2013, 13:42:17
As long as we are okay with leaving the uBASIC user base farther and farther behind?
I'd be OK with that, though including it ubasic would be preferable.
Quote
Seriously though,  it seems like these are pretty much core functionality for a package that is supposed to be about photography.   
Agreed. I'm just saying if we can provide the equivalent functionality, a library may be an option. If the only difference from a user POV is they need require"explib" at the top of their script, that's not a good reason for putting it in C code. If using C code can provide better functionality, it's certainly worth doing in C.
Quote
I'm also in favor of a extending the @param pragma to allow user entry in ISO units,  Tv seconds, or Av f-stop numbers from the Script  menu,   returning the apex96 equivalent to the script itself.
This would be an excellent feature.
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: Re: 1.3 development planning thread
« Reply #5 on: 16 / August / 2013, 12:18:39 »
I just found this discussion, so let me add my thoughts.

I wrote up some documentation and posted it in the Histogram Request thread. Here's the part on the Apex96 functions:
Quote
==========
*** Apex Conversion Functions ***
==========

tv96=shutter_to_tv96(shutter_time[,scale]) (default scale is 1000 for msec)
  shutter_time>0 means msec (if scale=1000 default)
    For microseconds, set scale=1000000
  shutter_time<0 means function uses 1/-shutter_time
  Example:
  @param t Shutter Max (sec)
  @default t 10
  @param u Shutter Min (1/sec)
  @default u 3200
  tvmax=shutter_to_tv96(-u*1000)
  tvmin=shutter_to_tv96(t*1000)
  Note: You could also do this with
    tvmax=shutter_to_tv96(-u,1)
    tvmin=shutter_to_tv96(t,1)

shutter=tv96_to_shutter(tv96,scale)  note: default scale=1000
  converts tv96 to shutter time in msec
  if tv96>0, you can use a scale of 1000000 for microseconds or...
    you can use -tv96 and print out 1/seconds instead of msec
  Example: This Lua function returns a string with the time
    function seconds(tv) -- tv96 to time string i.e. print(seconds(tv))
      pre=""
      if(tv>0)then
        tv=-tv
        pre="1/"
      end
      tv=tv96_to_shutter(tv) -- tv96 to msec
      ti=tv/1000 -- integer part
      ts=string.format("%s%u.%03u",pre,ti,tv%1000) -- xx.xxx or 1/xx.xxx
      if(ti>1)then -- truncate digits to reflect decimal precision
        if(ti>149)then ti=-5
        elseif(ti>14)then ti=-3
        else ti=-2 end
        ts=string.sub(ts,1,ti)
      end
      return ts
    end

sv96=iso_to_sv96(iso[,scale])  note: default scale=1
  converts iso to sv96.
 
iso=sv96_to_iso(sv96[,scale])  note: default scale=1
  converts sv96 to iso

av96=aperture_to_av96(aperture[,scale]) default scale=1000
  converts aperture to av96. f/2.0 is aperture=2000

aperture=av96_to_aperture(av96[,scale]) default scale=1000
  converts av96 to aperture

Quote from: philmoz on 10 / August / 2013, 20:55:13
The ISO conversion is using the old CHDK equation for 'real' ISO. It needs to be updated to use the 1.3 conversion.
  I need to change the constant in the conversion, since I used the Wikipedia equation, but I don't think this function should be modified to include "Market" ISO. To do that, you would need a Real to Market conversion function.

I need to research this a little more, but in my Tlasper.lua script I just add a constant to the Real sv96 to get Market sv96. This is based on the assumption that adding 96 to real or market sv96 should double the ISO (Real or Market). This shows how I do it in my script so I can input Market ISO:
Code: [Select]
@param z ISO Max
@default z 400
@param s ISO Min
@default s 100

--(in half_shoot)
sv=get_sv96()
svdiff=iso_to_sv96(get_iso_market())-sv  -- real to market difference
svmin=iso_to_sv96(s)-svdiff -- min sv ISO 100 market default
svmax=iso_to_sv96(z)-svdiff

--Now, to print Market ISO you do this
print(sv96_to_iso(sv+svdiff))
This works perfectly up to Market ISO 800 on my cameras. Above that, I think Canon may be cheating a little by making Market ISO more sensitive than it really is. I need to test this some more.
Quote
Not sure I see the need for the optional 'scale' parameter in all of the functions - the level of inaccuracy in the integer conversion means you're not going to get much better than using a default value of 1000.
This would also simplify the code.
This is not true. As Tv96 gets larger, the shutter times go below 1/1000 second (0.001 second). You need a scale of 1000000 to
output in microseconds.

The idea is that within the normal range of shutter times, ISO, and Aperture values, a change of 1 tv96, sv96, and av96 should
always be able to show a change in the resulting Shutter Time, ISO or Aperture value. This is important when displaying
converted Shutter, ISO, and Aperture values so you can see that they are changing.

If you don't like the scale parameter, you don't have to use it since the default is a scale of 1000. But if you take it out, you won't be able to accurately input or output accurate fast shutter times in microseconds, and your other conversions may have less precision than desired for certain applications.
Quote
Edit2: The other option here is to use the imath library fixed point type for shutter speed and aperture (instead of multiplying everything by 1000 / 'scale').

Personally I would also lose the convert96 function and move the conversion code into the calling functions.

Edit: I also don't like the way the 'shutter_to_tv96' treats negative numbers as a special case so that -2000 and 500 both mean 1/2 second shutter speed.
The imath library doesn't have the capability to do microsecond precision, and it adds complexity to the scripts in that you have to do a lot of multiplying and dividing by 1000, plus rounding. My functions are much simpler to use, and will take up much less overall memory by reducing a lot of Lua code.

I originally had a single Lua function called "convert96", and I never moved the code to the new, multiple calling functions. That's on my to do list.

Again, if you don't like the negative shutter time feature, you don't have to use it. But for me, it's very useful for inputting and displaying fast shutter times in a standard, 1/t format instead of in microseconds (the only other option). I'd rather input my maximum shutter speed as -4000 (1/4000) than have to figure out that it's 250 microseconds (although you can do that if you want using a scale of 1000000).

I'm open to simplifying code and making it faster and more accurate, but please don't take out important and very useful features because you don't "like" them. Others will want to use them, and probably think of new, innovative ways to use them that we can't imagine right now.
« Last Edit: 16 / August / 2013, 13:22:41 by lapser »
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline philmoz

  • *****
  • 3155
    • Photos
Re: Re: 1.3 development planning thread
« Reply #6 on: 24 / August / 2013, 00:22:03 »
Quote from: waterwingz on 10 / August / 2013, 12:12:54
As I work through lapser's patch file for his shot_histogram_request mods and remove things not related to that,  I stumbled on his "real world to APEX96" functions.

Code: [Select]
+    FUNC(shutter_to_tv96)
+    FUNC(tv96_to_shutter)
+    FUNC(iso_to_sv96)
+    FUNC(sv96_to_iso)
+    FUNC(aperture_to_av96)
+    FUNC(av96_to_aperture)
They are not really part of the shot_histogram & continuous shooting exposure adjust code so I guess I'll strip them out too.   

But is "somebody" going to add the equivalent as part of 1.3.0 (or as part of the real vs market ISO conversion) ?

I can do it but I'm assuming it needs to be tied to the fixes for ISO in 1.3.0?

UPDATE :  patch file of lapser's apex96 Lua conversion functions attached

My suggestion for this would be:
- put the conversion functions in shooting.c (note some are already there) so they can be called by uBasic and Lua
- implement the following functions:
Code: [Select]
    ISO_to_Sv96(n)             - 'n' = ISO value (can be either real or market value since conversion in 1.3 is identical)
    Sv96_to_ISO(sv96)
    ISO_real_to_market(n)      - convert ISO from real to market
    ISO_market_to_real(n)      - convert ISO from market to real
    Sv96_real_to_market(sv96)  - convert Sv96 from real to market
    Sv96_market_to_real(sv96)  - convert Sv96 from market to real
    Aperture_to_Av96(n)        - 'n' = 1000 * f-number (e.g. f/2.8 = 2800)
    Av96_to_Aperture(av96)     - returns 1000 * f-number
    uSec_to_Tv96(n)            - 'n' is shutter speed in microseconds
    Tv96_to_uSec(tv96)         - returns shutter speed in microseconds
    rational_to_Tv96(n,d)      - convert shutter speed expressed as a rational number (n/d)

I think this is clearer and keeps everything in consistent units.

I prefer to name the functions with the case as shown above; but I can live with everything in lower case if that's the consensus.

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)
*

Offline lapser

  • *****
  • 1093
Re: Re: 1.3 development planning thread
« Reply #7 on: 24 / August / 2013, 01:26:46 »
Quote from: philmoz on 24 / August / 2013, 00:22:03
I think this is clearer and keeps everything in consistent units.

I prefer to name the functions with the case as shown above; but I can live with everything in lower case if that's the consensus.
Sounds pretty good. I like the case, too. I originally put the functions in shooting.c and tried to use the ones that were there, but I had trouble with the short to integer conversions, among other things, and decided it was easier to write them from scratch as integer functions. I could probably use the iso to market iso functions you just finished in shooting.c

I don't see the need for rational_to_Tv96(n,d). uSec goes up to 2147.483648 seconds with a 31 bit positive integer, doesn't it?

I do think we need a way to enter shutter times as 1/seconds, since that's the way the camera, and photographers think about fast shutter times. The spec for the G1X is 1/4000 seconds for fastest shutter time, for example. My script has a maximum and minimum shutter time. The maximum is in seconds, and the minimum is 1/seconds.

The way I did it is to interpret negative numbers as 1/n, which works well. It is similar to a negative exponent. To avoid overflow, it's probably better to interpret -n as 1/Sec instead of 1/uSec. But that makes the name "uSec" confusing, so maybe a new function
would be best, which would avoid the negative number confusion too. This is what the function would do, but we'd need a valid name for [1/Sec]:

[1/Sec]_to_Tv96(n)

Another problem is the accuracy of Sv96_to_ISO(sv96) at low ISO. I think that a change of 1 sv96 should always give a new ISO result. My SX50 goes down to 80 ISO. 80 to 160 ISO is 96 Sv96 units, but only 80 ISO units. We need at least ISO*10 to avoid this problem. Maybe ISO*1000 would be more consistent with the Aperture conversion function.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline philmoz

  • *****
  • 3155
    • Photos
Re: Re: 1.3 development planning thread
« Reply #8 on: 24 / August / 2013, 03:50:17 »
Quote from: lapser on 24 / August / 2013, 01:26:46
Quote from: philmoz on 24 / August / 2013, 00:22:03
I think this is clearer and keeps everything in consistent units.

I prefer to name the functions with the case as shown above; but I can live with everything in lower case if that's the consensus.
Sounds pretty good. I like the case, too. I originally put the functions in shooting.c and tried to use the ones that were there, but I had trouble with the short to integer conversions, among other things, and decided it was easier to write them from scratch as integer functions. I could probably use the iso to market iso functions you just finished in shooting.c

I don't see the need for rational_to_Tv96(n,d). uSec goes up to 2147.483648 seconds with a 31 bit positive integer, doesn't it?

I do think we need a way to enter shutter times as 1/seconds, since that's the way the camera, and photographers think about fast shutter times. The spec for the G1X is 1/4000 seconds for fastest shutter time, for example. My script has a maximum and minimum shutter time. The maximum is in seconds, and the minimum is 1/seconds.

The way I did it is to interpret negative numbers as 1/n, which works well. It is similar to a negative exponent. To avoid overflow, it's probably better to interpret -n as 1/Sec instead of 1/uSec. But that makes the name "uSec" confusing, so maybe a new function
would be best, which would avoid the negative number confusion too. This is what the function would do, but we'd need a valid name for [1/Sec]:

[1/Sec]_to_Tv96(n)

Ummm, that's exactly what rational_to_Tv96 is for - rational_to_Tv96(1,4000)
But by specifying both numerator and denominator you aren't limited to 1/N values.

Alternatively the function could be rational_to_uSec and would be called as uSec_to_Tv96(rational_to_uSec(1,4000))

Quote
Another problem is the accuracy of Sv96_to_ISO(sv96) at low ISO. I think that a change of 1 sv96 should always give a new ISO result. My SX50 goes down to 80 ISO. 80 to 160 ISO is 96 Sv96 units, but only 80 ISO units. We need at least ISO*10 to avoid this problem. Maybe ISO*1000 would be more consistent with the Aperture conversion function.

A change of 1 Sv96 unit is 1/96th of an f-stop - a virtually undetectable change.
Being able to request ISO 80.52 versus 80 or 81 is unlikely to make any difference to the resulting image. If you really need a 1/96th stop change in exposure then just use Sv96 units and forget about ISO.

A scale factor for aperture is required because the f-number values aren't whole numbers - *1000 matches the existing CHDK code; but is really not necessary (*10 would probably work just as well).

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)
*

Offline lapser

  • *****
  • 1093
Re: Re: 1.3 development planning thread
« Reply #9 on: 24 / August / 2013, 11:21:05 »
Quote from: philmoz on 24 / August / 2013, 03:50:17
Ummm, that's exactly what rational_to_Tv96 is for - rational_to_Tv96(1,4000)
But by specifying both numerator and denominator you aren't limited to 1/N values.
Oh, that makes sense then (sounds perfectly rational). I was thinking "d" meant it was a decimal number:  nnn.ddddd
I'm assuming n/d is in Seconds, not uSec then?

In Lua, I supposed you could make the numerator optional, defaulting to 1. I love optional parameters. Personally, I would probably never use a numerator other than 1. The main thing this function would be used for is inputting fast shutter speeds in (1/sec) format. Do you have a scenario where you would need a numerator other than 1? For simplicity, this would be better for my uses:

reciprocal_to_Tv96(sec)
Quote
A change of 1 Sv96 unit is 1/96th of an f-stop - a virtually undetectable change.
I was thinking more of the Sv96_to_ISO(sv96) function for output. My script varies sv96 1 unit at a time from 80 (min) to 1600(max), and outputs the log data in ISO, rather than sv96. But it's probably not worth the added complexity and confusion to allow more precise ISO units. I can always output the precise sv96 to the log if I want to show it changed.

Also, since all the other functions are all lower case, it's probably better to use lower case here too. I'm already having trouble keep things straight.
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