September 22nd, 2022, 9:14 pm
This is odd - for some reason my post did not get published. I wrote this on the 30th of August:
Hi again.
So, for the past week or so, we've really been racking our brains, trying to really find the root cause of the issue you're seeing. We really had a hard time, as no-one else has ever reported, nor have we ever seen anything like it ourselves.
Today, we finally cracked it, and it is indeed a bug (or to be more specific, it's actually a combination of about several separate bugs) in our Firmware, which only ever comes to light in a rare edge case. At first, we were almost certain that the issue that triggers the failure was the short 3 second interval! However, we found that while this can help bring the issue to light, it’s not actually the root cause.
We did find that this is the reason why you saw this problem, and no-one else has reported anything similar:
- you’re running a sunrise timelapse.
- your ISO day limit was 100
- your cameras NEXT step after ISO 100 would have been a full stop (Lo 1.0), not 1/3rd of a stop!
The 5D Mark IV is by no means a seldom camera, nor is it odd to want to use the lowest native ISO as the limit, though our default limit is the very lowest value - Lo 1.0 or ISO 50 equivalent, so I guess there’s just not that many of our customers shooting sunrises AND changing the default ISO limit. So thank you for reporting this odd case with all these details.
A bug in our firmware remembered the last “NEXT step”, which is never a problem, except when that last next step is different than the actual next step. This is what caused the 1.3EV jump down instead of 0.3EV when the Unleashed finished ramping ISO, and started with the aperture. We implemented it so that want to ramp by 0.3 stops, then check each of the three settings in a row whether we can and want to ramp this setting and by how much. If yes we then check whether we SHOULD (ie check the day limit)and should ramp this setting,. on sunrise, we check ISO first, and realise we can't ramp by 0.3, but only by 1.0 stops. Then we realise that we're at the limit, so we don't ramp iso and move onto aperture. We find out we can ramp 0.3, it's OK to do so, so we do that. Unfortunately, due to the aforementioned bug, we checked whether one value is greater than or equal to another, instead of just greater than, so even after applying the 0.3 stop change to aperture, the two values were then equal, so we also ramped the 1.0 stops from ISO, which we still remembered due to another bug. So this explains the big dip when you reached the ISO limit.
Then, another bug comes into play, which creates the spikes. We made all parts of our implementation as independent of each other as possible - the input for the calculation, the calculation itself including determining which settings to change, and then actually changing the settings happens quite independently, also from the interval itself. This does allow for short intervals, that might cause us to miss an opportunity of changing settings before the next picture is taken. After the calculation, we save how many EV steps are remaining to adjust by, then after adjusting, subtract how many steps we DID adjust by, and save how many steps are remaining that we’ll need to adjust by next time. Unfortunately our bug reset this “remaining” value to 0, and when we got the confirmation by how much we did adjust, we’d suddenly have a remaining value in the opposite direction of the one we’re actually ramping in. We only do the next calculation when the threshold is passed, and that’s why there’s the spike upward, only each time we actually want to ramp downward. Its 1 full stop because of the first bug our “remaining” value was reset to 0, then 0- (-1.3EV) = +1.3EV, and when we wanted to adjust by -0.3EV, we added the two together and got +1.0EV. on the next photo we do ramp down again, and because of the first bug, it’s by 1.3EV again, luckily getting back to our desired value.
This repeats on each adjustment.
We’ve implemented the fix, and will be releasing a new firmware version soon.
That said, while a short interval not uncommon for certain timelapses, and while you're of course allowed to be creative in whatever way you like, I just wanted to note that it is very, very uncommon for holy grail timelapses. So I wanted to offer an idea on how to "save" your ruined timelapses: You could simply ignore 2 out of 3 images, resulting in a 9s interval which is close to the much more commonly used 10s interval. Then make sure you always delete the two over exposed images where the each of those "spikes" in the graph are. This might result in the odd 6 or 3 second difference between two frames, instead of the usual 9s but that should not be be visible in the final result. I think it would be quite easy to do in LRTimelapse, where you can easily spot the problematic two pictures.
Nonetheless, sorry again for the trouble, and thanks for the detailed report and helping us find these hidden bugs.
Founder & CEO of Foolography, Hardware & Firmware developer.
