That way, writing the log doesn't hang the script when the camera is busy writing photos (especially large RAW files). In my Tlapser.lua script, I found that writing every line to the SD card sometimes hangs for up to 7 seconds!
while the G1X is 511
That sounds like the M3 would have less range, but it's actually like having 13.8 bits instead of 14. Presumably, this helps to lower the noise level.
I discovered that I could sync 2 different cameras running Tlapser.lua by doing this,
Quote from: lapser on 03 / July / 2017, 16:45:21That way, writing the log doesn't hang the script when the camera is busy writing photos (especially large RAW files). In my Tlapser.lua script, I found that writing every line to the SD card sometimes hangs for up to 7 seconds! I can’t believe why it’s so much. Since I update my G1x to CHDK 1.5 I can rawopint with log on Intervals with 1.1s without problems…
But if you had this function: set_next_shutter_open_time(tick_time) then the script could do a lot more processing (or garbage collecting) during the entire shot. It could handle a single long delay without missing the next shot. That would give it time to close and reopen the log file without missing the interval, for example.
What you are really looking for is an interrupt driven system where certain event can be guaranteed to occur at specified times. While it seems unlikely that CHDK Lua will ever truly get to that state, it does seem possible that a "high priority" call back mechanism could be implemented in the script engine with some work. It's just a question of how valuable that would really be I guess.
All I'm looking for is for you to add this function: set_next_shutter_open_time(tick_time)
shoot_when(tick_time)
That moves the precise control of the shot timing to the shoot task, instead of being dependent on the keyboard (script) task AND the shoot task. It's a simple coding change!
AFAIK, the hooked "shoot tasks" (capt_seq_task or exp_drv_task) respond to messages from other parts of the firmware - they don't run on a regular basis. So having them open the shutter at a specified tick time doesn't really work. But it seems likely that there is another way to make this work satisfactorily.
void __attribute__((naked,noinline)) capt_seq_hook_set_nr(){ asm volatile("STMFD SP!, {R0-R12,LR}\n");******* my code shot_histogram_shot_delay(); //wait delay interval, if any, right before taking shot //note: must delay BEFORE setting NR values******** switch (conf.raw_nr){ case NOISE_REDUCTION_AUTO_CANON: // leave it alone#if defined(NR_AUTO) // If value defined store it (e.g. for G12 & SX30 need to reset back to 0 to enable auto) set_nrflag(NR_AUTO);#endif break; case NOISE_REDUCTION_OFF: set_nrflag(NR_OFF); break; case NOISE_REDUCTION_ON: set_nrflag(NR_ON); break; }; camera_info.state.shutter_open_time = _time((void*)0); camera_info.state.shutter_open_tick_count = get_tick_count(); asm volatile("LDMFD SP!, {R0-R12,PC}\n");}
Can you give me a link to the source code file that contains reyalp's code that delays the shutter opening until the script calls hook_shoot_continue()?
But scripts run in the keyboard task, which is a low priority task.
Sometimes low priority tasks don't execute for long periods of time when a higher priority task is busy. If the keyboard task is controlling the shot interval, then you'll miss the interval when another task is busy.
Another problem with having the script do the shot timing is that the script can't do any processing after calling hook_raw.continue(). It has to enter a delay loop so it can call hook_shoot.continue() at the proper time.
ETTR (Exposure To The Right) means the photo is exposed as brightly as possible without overexposing any part of the image.
Started by Sterling Forum related topics (including issues)
Started by Coutts « 1 2 3 4 » DSLR Hack development
Started by waterwingz General Discussion and Assistance
Started by Garden DryOS Development
Started by reyalp LUA Scripting
