1.3 development proposal - exposure conversion functions - page 3 - 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
  • 24899 Views
*

Offline reyalp

  • ******
  • 14080
Re: 1.3 development proposal - exposure conversion functions
« Reply #20 on: 31 / August / 2013, 14:30:35 »
Advertisements
Quote from: lapser on 31 / August / 2013, 13:59:24
I see phil and reyalp have answered this while I'm typing, and phil uses 69 for the conversion. Is this for all cameras?
All modern cameras, some early vxworks cams are different. You can go and re-read the market vs. real thread waterwingz linked if you want the gory details.

It is highly unlikely that the actual difference on your cameras is 59. If this was calculated using the old ISO code, it was probably an error. Though the 1/10th of a stop isn't likely to have a noticeable impact.
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: 1.3 development proposal - exposure conversion functions
« Reply #21 on: 31 / August / 2013, 15:09:33 »
Quote from: reyalp on 31 / August / 2013, 14:30:35
It is highly unlikely that the actual difference on your cameras is 59. If this was calculated using the old ISO code, it was probably an error. Though the 1/10th of a stop isn't likely to have a noticeable impact.
That's probably it. I used the Wikipedia equation, so the constant is off. I'll see what it comes up with after I update to the new trunk and get my mods working again. Thanks.

[EDIT]
I updated to the latest trunk and took out all my Apex96 functions successfully. Then I modified my time lapse script to use the new functions. So far, it looks like they're working correctly, and give correct results. The offset now comes out to 69, like it should. Good work everyone!

seconds_to_tv96(n,d) is a lot more flexible, so I didn't need to use usec_to_tv96(usec). Thanks for including seconds_to_tv96, and the name is perfect.
« Last Edit: 31 / August / 2013, 17:57:48 by lapser »
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline lapser

  • *****
  • 1093
Re: 1.3 development proposal - exposure conversion functions
« Reply #22 on: 10 / September / 2013, 15:58:33 »
I've uncovered a precision problem that stems from the use of (usec) in the shutter time to tv96 conversion functions.
Code: [Select]
float shooting_get_shutter_speed_from_tv96(short tv96){//function here}
static int luaCB_tv96_to_usec( lua_State* L )
{
  lua_pushnumber(L, (int)(shooting_get_shutter_speed_from_tv96(luaL_checknumber(L, 1)) * 1000000.0 + 0.5));
  return 1;
}
I input the max shutter speed as 1/seconds. A typical maximum is 1/3200 seconds, entered like this.

tv96max=seconds_to_tv96(1,3200)

This converts to tv96=1118, which looks correct.  However, to convert it back to 1/seconds, you have to compute:

tv96_to_usec(-1118)

This converts 3,200.0 seconds, which is returned as:

3,200,000,000 microseconds. The maximum positive integer is:
2,147,483,647   so I end up with 1/2147 seconds instead of 1/3200.

My feeling is that we need to get rid of the usec functions and use

tv96_to_seconds(tv96,multiplier)
and
seconds_to_tv96(seconds,divisor)


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

Offline reyalp

  • ******
  • 14080
Re: 1.3 development proposal - exposure conversion functions
« Reply #23 on: 10 / September / 2013, 16:25:26 »
Quote from: lapser on 10 / September / 2013, 15:58:33
I've uncovered a precision problem that stems from the use of (usec) in the shutter time to tv96 conversion functions.
...
That seems more like a problem in how you are trying to use it to me. tv96_to_usec correctly handles tv96 values that can actually be used by the firmware.  tv96 values that cannot be converted to a 32 bit integer usec value are invalid by definition, since that's what the camera actually uses to specify the exposure length.

If you choose to feed it tv96 values outside of that range, you get bad results. So don't do that?
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: 1.3 development proposal - exposure conversion functions
« Reply #24 on: 10 / September / 2013, 18:53:45 »
Quote from: reyalp on 10 / September / 2013, 16:25:26
Quote from: lapser on 10 / September / 2013, 15:58:33
I've uncovered a precision problem that stems from the use of (usec) in the shutter time to tv96 conversion functions.
...
If you choose to feed it tv96 values outside of that range, you get bad results. So don't do that?
You snipped the important part. tv96_to_usec(tv96) is used for displaying the shutter time in a human readable format. The format should correspond to what is shown on the camera, or in the EXIF data. The EXIF data is displayed in Windows as 1/3200 seconds, and all the faster shutter times are shown on the camera as 1/seconds. Microseconds just aren't used for showing shutter times.

Which is more understandable for photographers?

1/3200 sec
or
312 usec

It would probably work if the unit was 100 usec,

tv96_to_usec100().

but it's much more flexible to do it like this:
tv96_to_second(tv96,scale or multiplier)
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 #25 on: 10 / September / 2013, 20:22:31 »
Quote from: lapser on 10 / September / 2013, 18:53:45
Quote from: reyalp on 10 / September / 2013, 16:25:26
Quote from: lapser on 10 / September / 2013, 15:58:33
I've uncovered a precision problem that stems from the use of (usec) in the shutter time to tv96 conversion functions.
...
If you choose to feed it tv96 values outside of that range, you get bad results. So don't do that?
You snipped the important part. tv96_to_usec(tv96) is used for displaying the shutter time in a human readable format. The format should correspond to what is shown on the camera, or in the EXIF data. The EXIF data is displayed in Windows as 1/3200 seconds, and all the faster shutter times are shown on the camera as 1/seconds. Microseconds just aren't used for showing shutter times.

Which is more understandable for photographers?

1/3200 sec
or
312 usec

It would probably work if the unit was 100 usec,

tv96_to_usec100().

but it's much more flexible to do it like this:
tv96_to_second(tv96,scale or multiplier)

1000000 / tv96_to_usec(n)

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: 1.3 development proposal - exposure conversion functions
« Reply #26 on: 10 / September / 2013, 23:55:42 »
Quote from: philmoz on 10 / September / 2013, 20:22:31
1000000 / tv96_to_usec(n)
As usual, Phil figures out the solution.

I actually need 1/msec precision, but I can get that, barely within 31 bits, like this:

1,000,000,000/tv96_to_usec(n)  -- without the commas

My 1/3200 shutter time comes out to 1/3205 after the conversion. My old one came out to 1/3201.

I think there also is a precision problem with using (float) instead of (double) in this function:
Code: [Select]
float shooting_get_shutter_speed_from_tv96(short tv96)
{
    return pow(2,((float)(-tv96))/96.0);
}
//how about changing it to:
double shooting_get_shutter_speed_from_tv96(short tv96)
{
    return pow(2,((double)(-tv96))/96.0);
}
Search for the function in all source files. There's only a few places that need to be changed, i.e. cast to (float). Most of the time, the result is already cast to (int).  Also, I think pow() expects a (double) 2nd argument, so the cast to float is cast back to (double) after the division, which wastes precision.

(float) only has about 6 or 7 digits of precision, so when you multiply a float by 1,000,000 you're not getting accurate microseconds for values over 1 second or so. Basically, you're computing values to put into 10 digit integers, using 7 digit floating point arithmetic. So it should be using double. For consistency, I would like to see all the conversion functions changed from float to double.

============

Here's how I modified my function to print shutter times using Phil's idea. I changed it so it doesn't start using 1/seconds format until it gets to 1/2 second, which matches what the camera displays and puts into the EXIF (i.e. 0.6 seconds instead of 1/1.66)
Code: [Select]
function seconds(tv) -- tv96 to time string i.e. print(seconds(tv))
  local pre=""
  if(tv>=96)then
    tv=1000000000/tv96_to_usec(tv)
    pre="1/"
  else
    tv=tv96_to_usec(tv)/1000
  end
  local ti=tv/1000 -- integer part
  if(ti>1000)then ti=(ti/10)*10 end -- only 3 digits precision
  local 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
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 #27 on: 11 / September / 2013, 06:16:14 »
Quote from: lapser on 10 / September / 2013, 23:55:42
My 1/3200 shutter time comes out to 1/3205 after the conversion. My old one came out to 1/3201.

I tried your code and it gives exactly the same result (3205).

The difference between 1/3200 and 1/3205 is less then 1/2 microsecond - hardly likely to make a visible difference to any image exposure.

Quote
I think there also is a precision problem with using (float) instead of (double) in this function:
Code: [Select]
float shooting_get_shutter_speed_from_tv96(short tv96)
{
    return pow(2,((float)(-tv96))/96.0);
}
//how about changing it to:
double shooting_get_shutter_speed_from_tv96(short tv96)
{
    return pow(2,((double)(-tv96))/96.0);
}
Search for the function in all source files. There's only a few places that need to be changed, i.e. cast to (float). Most of the time, the result is already cast to (int).  Also, I think pow() expects a (double) 2nd argument, so the cast to float is cast back to (double) after the division, which wastes precision.

(float) only has about 6 or 7 digits of precision, so when you multiply a float by 1,000,000 you're not getting accurate microseconds for values over 1 second or so. Basically, you're computing values to put into 10 digit integers, using 7 digit floating point arithmetic. So it should be using double. For consistency, I would like to see all the conversion functions changed from float to double.

How exactly would a difference of a few microseconds affect an exposure > 1 second in length?

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 #28 on: 11 / September / 2013, 06:59:59 »
Quote from: lapser on 10 / September / 2013, 23:55:42

I actually need 1/msec precision

Why ?

What does 1/msec mean, do you mean one msec ?

Logged
*

Offline lapser

  • *****
  • 1093
Re: 1.3 development proposal - exposure conversion functions
« Reply #29 on: 11 / September / 2013, 15:15:20 »
Quote from: philmoz on 11 / September / 2013, 06:16:14
I tried your code and it gives exactly the same result (3205).
I'm not sure which code you're talking about. I'm comparing it with my initial function that used (double) internally and returned an integer result, with a scale factor.

If you're OK with casting a 24 bit float to a 32 bit integer, and the resulting loss of precision with larger numbers, then I guess there's not much I can do about it. You usually like to write optimized code, so I'm surprised you're resisting switching to double when it's so simple.  Remember, you're multiplying a float by 1,000,000 before casting to (int).
Quote
The difference between 1/3200 and 1/3205 is less then 1/2 microsecond - hardly likely to make a visible difference to any image exposure.
I'm not talking about setting exposure. I'm talking about displaying the exposure in a human readable format, like the camera does in the EXIF and on screen when you take a picture. It displays decimal seconds for exposures longer than 0.5 seconds, and "1/seconds" for exposures shorter than 1/2 seconds.

Quote from: Microfunguy on 11 / September / 2013, 06:59:59
What does 1/msec mean, do you mean one msec ?
There are 96 unique shutter times between 1/2 and 1/4 second, for example.  I need more decimal digits between 2 and 4. I print out:

1/2.000  to 1/4.000

So I need 1/shutter time in seconds*1000, or msec, to get that precision.

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