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

[0dan0]

Flashed the above 7.4, boot screen says 7.4, folder name is FilmScnC7.3. Set the Qp to 23 min, sharpness -1, loaded a reel, scanned for 90 minutes, and got 1.7GB of jittering bad scan result begin to end... sigh.. its already bad at the start, but worse at the end.

I've updated the Type C download (above) to have the updated folder name.

Unfortunately there is nothing in the build that changes the randomness of the startup jitter. The cause is still completely unknown. As for the jitter drift relating to compression, that is still an unproven theory. Maybe 23 is still too low, but it is unrelated. Compression level can't be the cause for errors in the startup jitter, as those frames are scanned before they are compressed.

 

[Erwin]

My recent observation is that Qp doesnt do anything. It seems to go to highest quality on its own irrespective of the minimum value that you set. Can you confirm this? Do you see higher/lower data rates in your scans?

I uploaded two short clips - the Qp=30 one shows an interesting effect. Not much jitter in these two. But that was just lucky.

 

[0dan0]

Flashed the above 7.4, boot screen says 7.4, folder name is FilmScnC7.3. Set the Qp to 23 min, sharpness -1, loaded a reel, scanned for 90 minutes, and got 1.7GB of jittering bad scan result begin to end... sigh.. its already bad at the start, but worse at the end.

EDIT: changing minimum Qp doesnt seem to do anything. Bitrate for all clips is about 22.1 to 22.5 Mbit/s. Even if I put it on 39 (the max value). Actually the same as previous scans on Qp=20 or Qp=23. What I saw once with min Qp=39 I get a few blocky frames, but then the quality is back as usual. So perhaps the minimum value that you set is displayed but it is not respected by the encoder.

Just tried another clip on Qp=39, 180 frames, 27 MB, mediainfo reports 22 Mb/s wich is correct looking at file size.

You are correct, for some reason 22Mb/s is the lowest, I can get higher bit-rate, but not lower. Found the bug. 7.4.1 shortly

 

[0dan0]

The bug is both more minor than I thought and might not be worth improving. The minimum Qp is working to limit the scanner stress. When the scanner is stressed with too much data from compression, it adjusts the Qp upward 3 or 6. This part is working. If the scanner is not stressed, it will not use the new minimum Qp. So with Qp Minimum set to 16, the Qp bounces between 17-20, has the output is 45Mb/s, with 12mm lens (the stock lens is softer, to you likely will not achieve that.) It seems the scanner stops being stress around 22Mb/s, so it will not lower its compression any further.

So I think I leave this as is.

 

[sheider]

The bug is both more minor than I thought and might not be worth improving. The minimum Qp is working to limit the scanner stress. When the scanner is stressed with too much data from compression, it adjusts the Qp upward 3 or 6. This part is working. If the scanner is not stressed, it will not use the new minimum Qp. So with Qp Minimum set to 16, the Qp bounces between 17-20, has the output is 45Mb/s, with 12mm lens (the stock lens is softer, to you likely will not achieve that.) It seems the scanner stops being stress around 22Mb/s, so it will not lower its compression any further.

So I think I leave this as is.

I second your motion to leave the Qp functioning as-is... I am happy with it bouncing between 17 and 20, even when it infrequently crashes.

Regarding jitter, I have only seen it on the bottom of the frames, and only from the very beginning of a scan. For me it is a mechanical issue, not a firmware issue... It occurs when the film transport mechanism is hindered during the first few frames, usually due to a too-thick splice, bent/warped film or leader, or even a single bad film perforation. Unfortunately, there is no way to see the jittering occur on-screen while scanning is in progress. Perhaps there is some hidden flag in the firmware that knows the jittering is occurring, but I wouldn't expect you to be able to locate it without having the source code. My takeaway: If a scan doesn't begin completely "smoothly" (without mechanically binding up during the first few frames), then stop the scan, fix the cause of the binding problem (bad splice, torn perforation, etc.), and try again. Disclaimer: YMMV.

 

[Erwin]

The bug is both more minor than I thought and might not be worth improving. The minimum Qp is working to limit the scanner stress. When the scanner is stressed with too much data from compression, it adjusts the Qp upward 3 or 6. This part is working. If the scanner is not stressed, it will not use the new minimum Qp. So with Qp Minimum set to 16, the Qp bounces between 17-20, has the output is 45Mb/s, with 12mm lens (the stock lens is softer, to you likely will not achieve that.) It seems the scanner stops being stress around 22Mb/s, so it will not lower its compression any further.

So I think I leave this as is.

So that is not the cause of the bug for my hardware. I demonstrated jitter present from beginning to end, and it gets worse towards the end. Also it is deterministic with a repeating pattern so this suggests software/hardware. The start of the scan seems important but random - I have to be lucky to get a good scan. I will remove the Qp minimums (back to 16) and see what happens. Also will make sure I start after a few stop/starts at a clean part of the film strip so everything mechanical is aligned and stable. I guess there's not much more to investigate, apart from going back to original or less modified firmware. Suggestions still welcome.

EDIT: first 2 minutes scanned, 720 MB file, 46,8Mb/s, no jitter. This old Kodachrome film is still brilliant with deep colors, I beat your special lens with my stock lens! (or its just encoding noise ). Fingers crossed again, next part..

 

[0dan0]

As for jitter, I have capture 45 ~100 frame clips (long enough to see jitter.) Only 4 of the 45 had jitter, this is why it is hard to debug, with only ~9% error rate is hard too measure if an change has improved things.

However three of the four bad captures, all had a weird overexposed first frame.

Yet the film was not overexposed, and the black level on the left indicate the shutter time was very wrong. You can often see the flash when you press record, so it timing can be off, if the capture happens during that exposure flash.

However a flash at the clip start does always result in jitter, so it is only an indicator that the startup was wrong.