There seems to be large unit-to-unit variations, seems that mechanically the cam for the film movement is not tightly in sync with the firmware. The frame jitter, if I get it, is at the top of the frame. This means the capture started while frame was loading into place. The rolling shutter of the sensor, works like a slit scan, showing when the film is in motion. Jitter at the bottom means the frame was stationary at the start of the capture then moved too early. It is baffling that the design is so bad to allow this. I believe this is mostly relates to the new lens using more of the sensor, much less than the firmware hacks (although it has some it can influence.) I believe these unit pass QA, as the jitter most happens outside of the narrow window, used by the stock lens. The active pixel read out for the 12mm lens takes ~40ms, whereas the stock lens the low res image is read out in ~17ms.
You can see it on the stock lens, just less often.
Now for the fix. I was optimizing for the top of the frame jitter with 6.6, but that would potentially make bottom jitter worse for hardware with the bias. The fix for top was to shorten the first frames exposure time, maybe the opposite can work. Need to work out a user control to calibrate that.
You can see it on the stock lens, just less often, or less pronounced.
Now for the fix. I was optimizing for the top of the frame jitter with version 6.6, but that would potentially make bottom jitter worse for hardware with that bias. The fix for top was to shorten the first frame's exposure time, so the maybe the opposite can work. I need to work out a user control to calibrate that.
As for color artifact, still no idea. Although as you are seeing it on B&W scans, it less likely stale image data in chrome channels.
I shoot some reels for a short film project this weekend, the scans worked out great. So this can be made to work well:
https://www.dropbox.com/scl/fi/xmo0...roll.mp4?rlkey=6mimupzui75m2oelpzaar7dra&dl=0