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

I need more decimal digits between 2 and 4.

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.

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

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

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

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.

Quote from: philmoz on 11 / September / 2013, 19:37:38Can 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.

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

extern double pow(double x, double y); //from math.hfloat 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;}

Started by RaduP Firmware Dumping

Started by flarn2006 Feature Requests

Started by reyalp General Discussion and Assistance

Started by waterwingz General Discussion and Assistance

Started by reyalp « 1 2 ... 7 8 » General Discussion and Assistance