rawopint.lua: Fast, accurate intervalometer with raw exposure metering - page 19 - Completed and Working Scripts - CHDK Forum

rawopint.lua: Fast, accurate intervalometer with raw exposure metering

  • 182 Replies
  • 43479 Views
*

Offline c_joerg

  • *****
  • 1147
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #180 on: 09 / August / 2021, 02:14:07 »
Advertisements
What kind of exposure range do you get from that video?

I can't say exactly because my tests are always limited by the set parameters.

In this example with the M3, ISO goes from 100 to 1600 (4 steps) and the exposure time from 0.13s to 3s (4.5 steps).
In this video I also change the values linearly from 255 to 0. This means that the dark times are less represented.

M100 100a, M3 101a, G9x II (1.00c), 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

*

Offline Caefix

  • *****
  • 599
  • Sorry, busy deleting test shots...
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #181 on: 09 / August / 2021, 12:35:04 »
The file is only closed when the script ends, so if the camera is powered off, anything in the OS buffer is lost.
Where to place "log:flush()" without disturbing intervall?  :-[
Code: [Select]
function restore()
...
        log:flush()
log:close()
end
All lifetime is a loan from eternity.

*

Offline reyalp

  • ******
  • 13387
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #182 on: 09 / August / 2021, 18:44:09 »
Where to place "log:flush()" without disturbing intervall?  :-[
Why should such a place exist?

The csv log module used in rawpoint accepts 3 buffer_mode values
'os' - output is buffered by the OS, written to the card when the OS thinks it needs to, or when log:close() or log:flush() is called. This is the default.
'table' - output is kept in a Lua table until log:flush() or log:close() is called. May use all available RAM unless the script takes steps to avoid this.
'sync' - output file is opened, written and closed each time log:write() is called. log:flush() is ignored.

The assumption is that 'os' will generally minimize disturbance, since the OS will probably try to write optimally sized chunks. Scripts that do the equivalent of 'sync' have been reported to have much less consistent intervals, which isn't surprising since it would likely involve a lot of writes smaller than an allocation unit on the SD card.
If you have enough memory and don't care about losing everything in a crash, then 'table' would have the minimum impact.
Don't forget what the H stands for.

 

Related Topics