Modding the Kodak Reels 8mm Film Digitizer (Firmware Hack)

[ThePhage]

Absolutely LEGENDARY work, @0dan0 !! Major kudos to you for unlocking this unit even further for the rest of us. We sincerely appreciate ALL your efforts in our behalf and for freely sharing these firmware updates regularly.

Question for the group: assuming a second scan/pass of the same reel would frame match similarly enough, do you think we could do a slightly underexposed pass and a slightly overexposed pass, then within Resolve layer them and use a blend mode (or isolate shadows & highlights with the Qualifier) to combine into a essentially an HDR pass? Anyone done anything like this before? (again, this is assuming the mechanism would retain a close enough framing match between each pass to have it near pixel accurate, etc)

Agreeing with Gewendell, that this recent FW takes the work into a whole new exciting direction. Thanks for all your time and energy putting into this, and then to share it with us all! I love being able to dial in a custom white balance. The more color adjustment can be done do the sensor data before encoding, the higher quality the end result will be!

Regarding the idea of a bracketing (multiple exposure passes), I suspect that a second pass of the entire reel is not likely to align close enough when compositing. Perhaps some frames would, but others won't. Even if it's just a couple of pixels off, I imagine an HDR merge would result in a decrease in resolution. On the other hand maybe HDR merge tools are sophisticated enough to correct for mis-alignment (I think Photoshop can do that).

An alternative method for bracketed exposures that might yield a pixel accurate alignment is to somehow adjust the timing of the motor/gear that drives the film through the gate so that it would take 2 or 3 captures of each frame (each at different exposure). Then some fancy image editing would be needed to separate out and properly sort the appropriate frames, and do the HDR merge to 10bit. I imagine Resolve, Adobe, or FCP could probably be setup in a way to do this.

Also, if that kind of hardware timing manipulation is possible, then there's also probably a way to encode the frames with fewer compression artifacts (0Dan0 demonstrated this in a previous post in this thread) which could increase perceived resolution.

Disclaimer: I'm not an HDR/bracketing guru, but a film/video enthusiast. I'd love to hear additional ideas on this topic.

 

[KODIAK]

Looks like you'll have to get creative. At this point, I'd remove the plastic flag/pin, drill out the holes in the bracket slightly oversize, enough to allow adjustment. Put it back together with some small lock washers under the screws. Adjust flag/pin right or left as needed. I hope there are only the two screws and not six total for you to deal with.

Sadly, this would not be useful. The problem is not the position of the pin, but the position where the pin stops in its cyclic movement. You can see in the two videos I posted above that this pin should stop only after lowering and partly reversing leftward, instead my pin stops just after lowering a little and fully rightward. Electronics should allow a slightly retarded stop, after going little leftward an fully lowering.

 

[Gewendell]

Agreeing with Gewendell, that this recent FW takes the work into a whole new exciting direction. Thanks for all your time and energy putting into this, and then to share it with us all! I love being able to dial in a custom white balance. The more color adjustment can be done do the sensor data before encoding, the higher quality the end result will be!

Regarding the idea of a bracketing (multiple exposure passes), I suspect that a second pass of the entire reel is not likely to align close enough when compositing. Perhaps some frames would, but others won't. Even if it's just a couple of pixels off, I imagine an HDR merge would result in a decrease in resolution. On the other hand maybe HDR merge tools are sophisticated enough to correct for mis-alignment (I think Photoshop can do that).

An alternative method for bracketed exposures that might yield a pixel accurate alignment is to somehow adjust the timing of the motor/gear that drives the film through the gate so that it would take 2 or 3 captures of each frame (each at different exposure). Then some fancy image editing would be needed to separate out and properly sort the appropriate frames, and do the HDR merge to 10bit. I imagine Resolve, Adobe, or FCP could probably be setup in a way to do this.

Also, if that kind of hardware timing manipulation is possible, then there's also probably a way to encode the frames with fewer compression artifacts (0Dan0 demonstrated this in a previous post in this thread) which could increase perceived resolution.

Disclaimer: I'm not an HDR/bracketing guru, but a film/video enthusiast. I'd love to hear additional ideas on this topic.

@0dan0 , have you seen if it’s possible to adjust the timing of the actual motor within the firmware? Also, is the chipset capable of saving individual frame still images vs buffering to the H.264 long-GOP compression? If it could spit out an image sequence, it would be significantly better (theoretically) vs the highly compressed video output. Even decent quality JPEGs at 2fps would produce far fewer artifacts than 8-bit MPEG-4. Super game-changer would be if it could take one snap at lower exp (appended with “A” to the file name), and one at higher exposure (append with “B”) for each frame before it moves. Then you’d sort by name, to have the “A” image sequence separated from the “B” image sequence. Since both images were snapped from the same frame, it should be pixel perfect and would align for HDR in any NLE. I’d be totally fine with 1fps scan speed if this was a capability option. (one can dream, right?? . Regardless, what you and @Mac84 have brought to life with hacking this unit is light years from where it was coming off the factory floor.

 

[0dan0]

@Gewendell I don't have the source code to these scanners, so everything I'm doing it a lot of guesswork, preventing or forcing a particular code paths and seeing what happens. I've had a lot of lucky guesses. However nothing has changed the motor behavior or reliably output JPEGs. The hardware can do JPEG as there are many strings like "%s() Encode JPEG Failed" is also supports VideoCodec_MJPG, likely an AVI or MOV with JPGs within. Using the command shell and command "mode photo" I got two images out before the unit crashed. I never got it to do any more. The two came out at 1920x1080 and about 550KBytes. At 18fps, this is about 80Mb/s. A long GOP 1600x1200 at 35Mb/s in H.264 has more quality than 80Mb/s MJPEG sequence. If the JPEG encoding could be made stable and quality improved, nice, but the unit is getting less convenient to use.

 

[fishgee]

Sadly, this would not be useful. The problem is not the position of the pin, but the position where the pin stops in its cyclic movement. You can see in the two videos I posted above that this pin should stop only after lowering and partly reversing leftward, instead my pin stops just after lowering a little and fully rightward. Electronics should allow a slightly retarded stop, after going little leftward an fully lowering.

Sure, but what makes the stepper motor stop at a particular position? The pin moving into the sensor and breaking the infrared beam maybe? Perhaps test this by adding some black electrical tape (or something that wouldn't allow infrared to pass through it) to the end of the pin to make it a couple of mm longer and break the beam earlier than it does now. Does that make the motor now stop at a different place?