Hi - New Forum user (so be gentle).
Love the "hacking" you have done, but question the value of some of the efforts.
First - the sensor is a CMOS 3280x2464 which really means a 1640x1232 pixel image capability after combining the 4 color cells (R-Gb-Gr-B) which can either integrate to 10 or 12 bits/pixel typically A-Law companded to make 24 bit RGB (Assuming typical cmos image sensor operations). But this then needs to be mangled into 720p ( 1280x720) or 1080p (1920 x 1080) and time slapped from 18fps or 16fps to 24fps to be playable. Throwing a $90 lens at the problem seems like pig cosmetics, however, optics is always the bane of good scanning.
Eliminating and stabilizing the color and white balance are great - but the goal should be to get the best image out of the sensor without adding all manner of conversion artifacts in the process. This means keeping a 720p output based on a 1280x720 sensor window judiciously selected from the sensor view; attempting to up-convert or compress frames simply adds artifacts, not detail.
If you REALLY want 1080p, a 12MP sensor (e.g. Sony IMX477) will provide an output of 2028x1520 which can produce a "real" 1080p output and worthy of the 12mm Macro lens. That would require a processor upgrade, say a Raspberry Pi CM4 and a carrier suitably equipped with some integration to the screen, buttons, and motor; definitely not for the faint of heart, but reasonably doable. This also pushes the limits of the film's resolution but does "honestly" double the scanning quality.
The goal, in any case, should be a true one-to-one raw sequence of digitalized frames without any 720p/1080p conversion or speed artifacts (e.g. inserted frames); i.e., RAW. Finagling color balance and speed in a later digital stage is far less frustrating than trying to crowbar an underpowered SOC to do more than it was ever designed to do. If you're going to use the full capabilities of the existing sensor, then find a way to pad the image to fill the 1080p frame, or stick to 720p with an under scan optically selected from the frame. That is 2.8 (720) or 6.2 (1080) MB/Frame uncompressed that may reasonably compressed - i.e. keep the largest bitrate possible.
One thing I never saw in the thread (sorry - it is WAY too long; maybe a wiki is needed to separate the journey from the results/recommendations) is modifying the light source to allow adjustment of the illumination color balance, rather than trying to constantly apply conversions during scanning. This can be done with a three color led light source tuning or optical filters. Catching and analyzing the sprocket hole leakage would allow dynamic adjustment against source illumination as well, but probably not possible on this platform (especially with ONLY 128MB frame buffer : did I read that correctly?).
However - the results of this team's efforts is phenomenal given the base material! I will be looking for a unit to modify given the head start available herein.
T
