After I wrote this lines of code I asked my self why I did not used a float or double. I actually was not sure if there is a performance or memory issue using doubles since I could only find Integers in the code.
I want to share my experience and some code changes I did to rawopint.lua in this and the next post.
For a better understanding of the settings/parameters ui_bv_ev_shift_pct, ui_bv_ev_shift_base_e, ui_ev_shift_e I did a bit of reverse engineering by gradually changing one parameter and then recording a sunset and so forth.
I attached a pdf with the plots of the ui_bv_ev_shift_pct changes from 2% to 80%, which I think could be also interesting to others for the understanding of this functionality. For my kind of timelapse a value of about 16-24% is best depending on the ui_bv_ev_shift_base_e and ui_ev_shift_e parameters. At the beginning it was quite strange that high values would overexposed the image in daylight. But in the end it makes sense since it lowers the exposure when it's dark and rises the exposure when it is higher than the "neutral" exposure. The ui_bv_ev_shift_base_e did basically the same as the ui_bv_ev_shift_pct.
An other topic was the under_expo_weight, over_exp_weight. As far as I understand for my type of sunset it is best to switch this two parameters off and only relay on the meter exposure, because I think that if a bright cloud comes into the frame the hole frame should not darken.
What does actually mean a rise of the meter weight from 100 to say 200? I attached a plot where exactly that happens but I could not see any changes in the timelapse video itself..
ev_change = (ev_change*meter_weight - self.ev_change_max*over_weight + self.ev_change_max*under_weight)/(meter_weight + over_weight + under_weight)
The last part I'm not sure is, if whether the ui_meter_width_pct and ui_meter_height_pct are dependent on the selected image format. E.g. if I choose 1:1 or 16:9 image format stays the area that rawopint uses to calculate the exposure always the same?
bv_ev_shift_base and bv_ev_shift_pct shouldn't be equivalent in the general case. base should define the Bv value (derived from meter and exposure) where the effect of bv_ev_shift is 0, regardless of the bv_ev_shift_pct value. Bv is an absolute measure of the amount of light, where a scene in full daylight would typically be around 10 APEX.Looking at your plots, I guess bv_ev_shift_base_bv is APEX 4? I would generally set it around the brightest you expect the scene, since you don't want to overexpose much, but meter and overexposure limits should stop it from going too far.In your examples, bv_ev_shift crosses the origin right around where bv96 crosses 400. When Bv is higher, it pushes exposure brighter, and when it's lower, it pushes it darker, subject to the meter thresh/limit values (and I think a bit confused by the ui_ev_shift values, but it's hard to say without the actual log).
I would set the "thresh_frac" values to 0 if you want to completely disable under or over protection. This should completely disable all the related calculations.
The weights are arbitrary numbers that determine the relative influence of the meter and over / under exposure, subject to various limits. The key line isCode: [Select]ev_change = (ev_change*meter_weight - self.ev_change_max*over_weight + self.ev_change_max*under_weight)/(meter_weight + over_weight + under_weight)ev_change is the difference between the meter value and the target value, clamped to +/-ev_change_max. over_weight and under_weight are calculated from the percentage of over and under exposure, such that they reach 100 when "thresh" is reached, and quickly ramp up to 200 after that. You can see if over and under are 0, then ev_change is unaffected. Meter weight starts at 100, and ramps up to 200 between from thresh to limit.The intent is that the three factors will tend balance in the range defined by the thresh and meter limit values, without any sudden transitions triggered by if/else logic. For example, if overexposure is at the "thresh" value, it will balance with meter the thresh value in the opposite direction, and if that is exceeded, push meter to the limit value without allowing much more overexposure.The actual change in any given frame is limited to ev_change_max.I haven't tested much with the weights at non-default values. I'd generally use the thresh / limit and over / under fractions instead.
Anything related to size/position in rawopint refers to the full raw buffer. So if you use a different jpeg aspect ratio than the native sensor resolution, you'll have to account for that yourself.
Yesterday I did an M3 time lapse with rawopint. When heavy rain set in, I unfortunately switched off the camera via Power Off. In the logfile there are now about 130 entries of 8s each missing. I wondered why so many lines were lost.
2 Observations:Without smoothing the ev change value some flickering in the video appears, most noticeable when light condition are stable and don't change at all. I would suggest a minimum value of 3-4 to get rid of the "flickering".
The file is only closed when the script ends, so if the camera is powered off, anything in the OS buffer is lost.
The log module can write every line if you want (commented line buffer_mode = 'sync'), but that may make the shooting interval less consistent.
This all begs for some kind of controlled, reproducible testing, but I haven't figured out a manageable way to do it. Maybe a video playing on a monitor?
Do you know the size of the buffer?
At least that's how I do it for simple cases. It works very well with that. But I can't test the oscillation with it.
Started by rosspian
Started by reyalp
Completed and Working Scripts
Started by Stephan
« 1 2 »
General Help and Assistance on using CHDK stable releases