1.3 development proposal - exposure conversion functions - page 4 - General Discussion and Assistance

Microfunguy

4037

Re: 1.3 development proposal - exposure conversion functions

« Reply #30 on: 11 / September / 2013, 16:05:57 »

Advertisements

Quote from: lapser on 11 / September / 2013, 15:15:20

There are 96 unique shutter times between 1/2 and 1/4 second

So what, you are not under obligation to make use of them.

Quote

I need more decimal digits between 2 and 4.

You might, photographers do not.

Is this about 'the joy of programming' or practical photography ?

Generally, 48 APEX96 units is sufficient precision for me.
For HDR bracketed sequences 128 units is just fine.

Logged

lapser

1093

Re: 1.3 development proposal - exposure conversion functions

« Reply #31 on: 11 / September / 2013, 18:15:07 »

Quote from: Microfunguy on 11 / September / 2013, 16:05:57

Is this about 'the joy of programming' or practical photography ?
Generally, 48 APEX96 units is sufficient precision for me.
For HDR bracketed sequences 128 units is just fine.

I can't seem to get it across that the function, tv96_to_usec(tv96) is NOT about setting exposure. You set the exposure with tv96, and you already have that!

I do time lapses of sunsets. I change the exposure from one picture to the next by 1 tv96 unit. If you change it more than that, you see a "flash" in the dark portions of the video. It's not about how the individual pictures look, it's about how the video looks when you switch between the two pictures. I'm not using the 2 pictures to make a single picture, like with HDR. I'm displaying the two pictures consecutively in a video.

While taking each picture, I show the shutter time for that picture on the screen using tv96_to_usec(tv96). It's important that the value displayed changes when tv96 is incremented by 1, and that fast shutter speed be displayed as fractions in the form 1/x.xxx. This requires precision since the changes are small. I had it working fine with my original function, tv96_to_shutter(tv96,scale), which used (double) for it's calculations, and output (int) after rounding. But by insisting on a fixed scale of 1,000,000 the function is pushing the limits of 32 bit integers, and exceeding the limits of 24 bit floating point. The imath library uses a scale of 1,000 and computes with (double) for a reason.

But I still think the best solution is to add the function:

tv96_to_seconds(tv96,multiplier)
tv96_to_seconds(tv96,1000000) is the same as tv96_to_usec(tv96)
It allows me to use tv96_to_seconds(-tv96,1000) for the 1/x.xxxx output format without overflow
This function is essentially the inverse of the current function:

seconds_to_tv96(seconds,divisor)
seconds_to_tv96(usec,1000000)is the same as usec_to_tv96(usec)

For now, I guess tv96_to_seconds(..) will be specific to my builds.

Logged

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

Microfunguy

4037

Re: 1.3 development proposal - exposure conversion functions

« Reply #32 on: 11 / September / 2013, 18:51:33 »

Fair enough, I have not read the entire thread.

Is there anything special about seconds, why not just display the Tv96 number ?

Logged

philmoz

3450

Re: 1.3 development proposal - exposure conversion functions

« Reply #33 on: 11 / September / 2013, 19:37:38 »

Quote from: lapser on 11 / September / 2013, 18:15:07

While taking each picture, I show the shutter time for that picture on the screen using tv96_to_usec(tv96). It's important that the value displayed changes when tv96 is incremented by 1, and that fast shutter speed be displayed as fractions in the form 1/x.xxx. This requires precision since the changes are small. I had it working fine with my original function, tv96_to_shutter(tv96,scale), which used (double) for it's calculations, and output (int) after rounding. But by insisting on a fixed scale of 1,000,000 the function is pushing the limits of 32 bit integers, and exceeding the limits of 24 bit floating point. The imath library uses a scale of 1,000 and computes with (double) for a reason.

Can you provide a real example where your seconds(tv) function does not give a different value to seconds(tv+1) or seconds(tv-1)?

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)

lapser

1093

Re: 1.3 development proposal - exposure conversion functions

« Reply #34 on: 11 / September / 2013, 20:55:18 »

Quote from: philmoz on 11 / September / 2013, 19:37:38

Can you provide a real example where your seconds(tv) function does not give a different value to seconds(tv+1) or seconds(tv-1)?

I haven't had a chance to test the 1000000000/tv96_to_usec(tv96) method yet. Just looking at it, you can tell it's ripe for overflow. Plus, it only has 3 digits of precision in the result, so the low digit of 1/3200 isn't valid. I can't add another 0 to the numerator to get another digit, because that's a 33 bit signed number. The problem isn't producing different values. The problem is that there aren't enough digits of precision.

But why do you demand an example when you're casting 24 bit (float) to 32 bit (int)? It's obvious that (double) should be used. There aren't any time critical calculations involved. What's the advantage of using (float) instead of (double) here, anyway?

You also should be able to use tv96_to_usec(-tv96) to get 1/xx.xxx shutter times. 1/3200 needs tv96=-1188, but that evaluates to 1/2147, which is the max positive int. Anything larger than tv96=1064 results in 2147 as a result. The fixed usec unit is very limiting.

You do get the same sv96_to_iso(sv96) results for a change of 1 sv96 when you start at ISO 80, for example. There are 96 sv96 units between ISO 80 and ISO 160, but only 80 ISO units. People may also want to use lower ISO than 80. This is why I added an optional scale to ISO. I'm not as worried about this as the shutter time problem, although the SX50 does start at 80 ISO.

Quote from: Microfunguy on 11 / September / 2013, 18:51:33

Is there anything special about seconds, why not just display the Tv96 number ?

I used to do that, but it's more understandable to input and output in seconds. It's like saying, "I'll call you back in -576 tv96" instead of "I'll call you in a minute."

I usually want to enter the maximum shutter time in seconds, i.e. 15 seconds, and the minimum as 1/seconds, i.e. 1/3200 seconds. I don't think microseconds is a unit that's used in photography much. The seconds_to_tv96() function is perfect for this:

tv96Max=seconds_to_tv96(tmax,1)
tv96Min=seconds_to_tv96(1,tmin)

It's reasonable to want the seconds display to be 1/xx.xxx for shutter times less than 1/2 second, and xx.xxxx for times longer than 1/2 second. That's what my seconds(tv) Lua function does, and that's where I discovered the overflow, and precision problems with tv96_to_usec(tv96). tv96_to_seconds(tv96,1000) is equivalent to my original tv96_to_shutter(tv96,scale), which worked well.

Logged

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

waterwingz

12139

Re: 1.3 development proposal - exposure conversion functions

« Reply #35 on: 11 / September / 2013, 20:56:49 »

Quote from: Microfunguy on 11 / September / 2013, 18:51:33

Fair enough, I have not read the entire thread. Is there anything special about seconds, why not just display the Tv96 number ?

The whole point of this thread and the resulting changes to CHDK were to allow the UI provided by CHDK scripts to work easily in the units a camera owner expects to see ( seconds, f-stop, ISO sensitivity). Showing Tv96 values tends to be confusing to photographers who are not programmers.

Logged

Ported : A1200 SD940 G10 Powershot N G16

Microfunguy

4037

Re: 1.3 development proposal - exposure conversion functions

« Reply #36 on: 11 / September / 2013, 21:49:54 »

Quote from: lapser on 11 / September / 2013, 20:55:18

It's like saying, "I'll call you back in -576 tv96" instead of "I'll call you in a minute."to_seconds(tv96,1000) is equivalent to my original tv96_to_shutter(tv96,scale), which worked well.

Well, -576 is instantly recognisable as 64 seconds.

576/96 = 6, 2^6 = 64, it is a negative number so that must be the numerator rather than the denominator.

Just a number, as long as we can see it change ........

Logged

philmoz

3450

Re: 1.3 development proposal - exposure conversion functions

« Reply #37 on: 11 / September / 2013, 21:56:53 »

Quote from: lapser on 11 / September / 2013, 20:55:18

Quote from: philmoz on 11 / September / 2013, 19:37:38
Can you provide a real example where your seconds(tv) function does not give a different value to seconds(tv+1) or seconds(tv-1)?
I haven't had a chance to test the 1000000000/tv96_to_usec(tv96) method yet. Just looking at it, you can tell it's ripe for overflow. Plus, it only has 3 digits of precision in the result, so the low digit of 1/3200 isn't valid. I can't add another 0 to the numerator to get another digit, because that's a 33 bit signed number. The problem isn't producing different values. The problem is that there aren't enough digits of precision.

But why do you demand an example when you're casting 24 bit (float) to 32 bit (int)? It's obvious that (double) should be used. There aren't any time critical calculations involved. What's the advantage of using (float) instead of (double) here, anyway?

I was trying to be polite. My analysis shows that the maximum difference you can possibly get using double instead of float is 0.001%. That's 1/100,000th of a second.

Now if you can find a real world example that proves otherwise please post it.

Quote

You also should be able to use tv96_to_usec(-tv96) to get 1/xx.xxx shutter times. 1/3200 needs tv96=-1188, but that evaluates to 1/2147, which is the max positive int. Anything larger than tv96=1064 results in 2147 as a result. The fixed usec unit is very limiting.

As reyalp already explained that's not the purpose of the function. Just because you want to abuse it doesn't change that fact.

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)

lapser

1093

Re: 1.3 development proposal - exposure conversion functions

« Reply #38 on: 13 / September / 2013, 04:01:26 »

Quote from: philmoz on 11 / September / 2013, 21:56:53

As reyalp already explained that's not the purpose of the function. Just because you want to abuse it doesn't change that fact.

The purpose of the function is to convert tv96 into something photographers can understand. Photographers don't understand shutter times in microseconds. They understand shutter times in fractions (1/seconds).

The function is just 2^x with some constants. 2^(-x) = 1/(2^x). It's not abusing the function to expect that to be true, and to expect it to be able to output a value of 5,000, corresponding to a 1/5000 second shutter time. The function is crippled, not abused.

As far as casting float to int, I can't believe you'd actually argue to keep that sloppy code in CHDK. You still haven't given me a reason to use float instead of double. I can give you several reasons to use double.

You get about 3 extra digits of precision in your int values.
You're casting int to short to float to double and back and forth so much it's hard to follow.
You're doing all your calculations in double anyway, and just throwing away all that precision by casting double to float.
Truncation errors get worse the more calculations you do with the result.

Here's all the code involved. It should be in a textbook for how not to do calculations:

Code: [Select]

extern double pow(double x, double y); //from math.h

float shooting_get_shutter_speed_from_tv96(short tv96) //from shooting.c (worthless cast to short too)
{
    return pow(2,((float)(-tv96))/96.0);
}

static int luaCB_tv96_to_usec( lua_State* L ) //from luascript.c
{
  lua_pushnumber(L, (int)(shooting_get_shutter_speed_from_tv96(luaL_checknumber(L, 1)) * 1000000.0 + 0.5));
  return 1;
}

// All I'm asking for is:    tv96_to_seconds(tv96,scale)
static int luaCB_tv96_to_seconds( lua_State* L ) //to be added to luascript.c
{
  lua_pushnumber(L, (int)(shooting_get_shutter_speed_from_tv96(luaL_checknumber(L, 1)) * luaL_checknumber(L, 2) + 0.5));
  return 1;
}

OK, we've argued about this enough. Let's move on to more important things. I'll keep using a custom build that does what I need and not bug you any more about this.

Logged

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

lapser

1093

Re: 1.3 development proposal - exposure conversion functions

« Reply #39 on: 13 / September / 2013, 16:48:32 »

Thinking about this overnight, I think I see where the disagreements come from, and how I can proceed without getting into any more of these kind of conflicts. First, let me apologize if my tone came across as rude or arrogant. I think you're all really incredible programmers, and that Phil is in a league by himself.

The CHDK menus provide an interface between the user and the camera operating system. As a user interface, menu functions must choose how to present data to the user, and accept data from the user, including the units and range for that data. The shutter time short override menu function uses 10 usec units, for example. The long shutter override menu function uses units of 1 second, with a somewhat excessive maximum time of 10 days.

The Apex96 conversion functions for scripts, as written, are user interface functions. They choose the units, and limit the range of the input and output based on those units. However, the script is what provides the user interface that presents and accepts data from the user. Script functions should be written as operating system functions, not user interface functions. The script is then free to provide the user interface, including choosing the units best suited for each application.

My philosophy is that script functions, as operating system functions, should provide maximum flexibility, precision, and efficiency to the script. If we all go forward with this in mind, scripts in CHDK can become incredibly powerful. I'm sure Phil and the other CHDK geniuses can come up with ways to do this that are much better than mine. For example, Phil's idea of the seconds_to_tv96(numerator, denominator) function is a much more flexible and clear method than my original shutter_to_tv96(t,scale) function, with -t indicating 1/t.

Smartphones have already implemented these ideas. The user interface to smartphones is all done with scripts (apps). Partly because of this, smartphone camera apps are taking over the point and shoot market, despite the limited capabilities of their tiny lenses and sensors in the phones.

The only way I can go from here is to change the current Apex96 functions from fixed unit user interface functions to flexible operating system functions, and use them in my own builds and scripts. Then I'll post a diff of the changes for others who might find them useful. I'll have to accept that maximizing script flexibility and capability is not the direction CHDK is going at the moment.

Logged

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