Decimal number values in intervalometer/bulb timer

Started by gerk.raisen, June 24, 2013, 01:59:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gerk.raisen

I need for a special project the possibility to use decimal number values in intervalometer (maybe also bulb) (like 0.8 and 1.6 sec for example)
I'm trying to figuring out how to add it...
I've added the custom values to "timer_values" and changed it to float
I've also changed some other variables to float to host the decimal numbers
The compiling is OK but in the intervalometer menu the values appear in menu in this manner:           
0.8s appear as another "0" value, 
1.6 appear as another "1" value   
3.2 appear as another "3" value         

The calculated timelapse values are incorrect, and seems also the shooting times
What I'm doing wrong or I forgotten?

It's also seems that with silent pictures and values just below one second the camera start to shoot normally ignoring silent pic option.
Is this 1 second value hardcoded somewhere?

CHANGES MADE:


+static float timer_values[] = {0, 0.8, 1.0, 1.5, 1.6 ............................



static MENU_UPDATE_FUNC(timelapse_calc_display)
{
-    int d = timer_values[interval_timer_index];
+    float d = timer_values[interval_timer_index];
     d = MAX(d, get_exposure_time_ms()/1000);
     int total_shots = interval_stop_after ? (int)MIN((int)interval_stop_after, (int)avail_shot) : (int)avail_shot;
     int total_time_s = d * total_shots;



static MENU_UPDATE_FUNC(interval_timer_display)
{
-    int d = timer_values[CURRENT_VALUE];
+    float d = timer_values[CURRENT_VALUE];
     if (!d)
     {
         MENU_SET_NAME("Take pics...");



static MENU_UPDATE_FUNC(interval_start_after_display)
{
-    int d = timer_values[CURRENT_VALUE];
+    float d = timer_values[CURRENT_VALUE];
     MENU_SET_VALUE(
         format_time_hours_minutes_seconds(d)
     );



static MENU_UPDATE_FUNC(intervalometer_display)
{
    int p = CURRENT_VALUE;
    if (p)
    {
        float d = timer_values[interval_timer_index];
        MENU_SET_VALUE("ON, %s%s",
            format_time_hours_minutes_seconds(d),
            BULB_EXPOSURE_CONTROL_ACTIVE ? ", BRamp" : ""
        );



static MENU_UPDATE_FUNC(bulb_display)
{
-    int d = BULB_SHUTTER_VALUE_S;
+    float d = BULB_SHUTTER_VALUE_S;
     if (!bulb_duration_index) d = 0;

     if (bulb_timer)



static MENU_UPDATE_FUNC(bulb_display_submenu)
{
-    int d = BULB_SHUTTER_VALUE_S;
+    float d = BULB_SHUTTER_VALUE_S;
     if (!bulb_duration_index) d = 0;
     MENU_SET_VALUE(
         format_time_hours_minutes_seconds(d)

dhilung

I think in the current implementation of intervalometer, the wait time for the shot intervals has the time resolution of seconds. Also, they are less accurate for finer intervals because of the random 'sleeps' introduced within the loop.

If the raw_rec resolution is okay for your project, frame-skipping option might be helpful for you (http://www.magiclantern.fm/forum/index.php?topic=6451.0).
Currently, it has interval choices of 0.1, 0.5, 1.0, 1.5 .. etc (in secs), but you can easily change the code to include your desired values.
5D2 | 40D

gerk.raisen

RAW Rec resolution unfortunately is too low :)

I've seen your proposal and it's very interesting but it seems not yet integrated in main code.
I see that the raw_rec code change very often, also from the date of your post, could you prepare a .diff file against the lastest commit? Even better a pull request....

Back to business, isn't possible to modify the normal intervalometer to be more precise (especially with low values) maybe applying to it  some of your code?
If the problem is with longer values, maybe we can use a more precise algorithm (like yours) for low timer values and standard algorithm (with loop) for higher values.

I think a similar change can be useful not only for me :)

a1ex

You may have to rewrite the intervalometer loop to use the milliseconds clock, not the seconds one.

I still don't see any good reason for hacking raw_rec instead of using FPS override (for low intervals) or intervalometer + silent pics (for large intervals).

gerk.raisen

Yes,
but an intervalometer change to be more precise could be for example the possibility of shoot fullres RAW picture not rounded to +-1sec
Or are there other collateral effects?

I'm rather brave,
but the change of intervalometer loop to milliseconds clock maybe is a little over my knowledge... :(
Anyone can please help me?

a1ex

Other than somebody having to sit down and troubleshoot all the unforeseen little quirks... nothing that I'm aware of.