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

[Hawke]

@Hawke Let me know if you try it and whether you like the results.

Hello, I flashed the firmware today. But I will test it tomorrow, it's now to late for today
Can you tell me your used settings for exposure and tint?

 

[0dan0]

I use -0.5 exposure, -1.5 sharpness and 0.0 tint. I'm now working to add some QP changes and bump the resolution back up. So there might newer FW for tomorrow.

 

[LukeV]

I have continued to tweak the manual white balance. Here I have included a second sequence that was too blue with the last version. Now is only slightly blue, while the garden sequence still looks good. The RGB gains are 2.0, 1.0, and 0.75. While this came from the same 1966 reel, the white balance is different between the sun-lit botanical gardens and the scene with the overcast capital buildings. I'm aiming for a fixed white balance that is easily correctable in post, or just left as is. The left is stock WB (adding 1600x1200 @ 24Mb/s), the right is the latest fixed WB (guessing around 5600K.) The auto WB is way too crazy, I will never use that again.
View attachment 19637

Attached is type C firmware with all my favorite resolution, bitrate and latest WB modifications (boot screen will show the current settings.) All feedback welcome. I do wish to make the WB controllable, but that might take a long while.

Just ran my first reel with this firmware and the results are glorious. Love the bitrate, and having a set WB avoids a LOT of problems. Kudos on the great work!!

 

[Andreas]

Hello,

I am living in Germany and I have the Kodak Reels (Model No. RODREELSEU) with firmware no. 2 (type B) since last year and I have it successfully converted to 23 Mbit/s with the instructions on this page.
What I am still missing now is
1. the manual white balance,
2. the manual exposure and
3. the possibility to create files larger than 4 GB with exFat formated SD cards.
Is there a manual on how to turn off the automatic white balance in the firmware?
Or a firmware version B where this is already done.
If there is a firmware that solves the problems mentioned, I will digitize my Super 8 films again

Andreas

 

[Mac84]

Hello,

I am living in Germany and I have the Kodak Reels (Model No. RODREELSEU) with firmware no. 2 (type B) since last year and I have it successfully converted to 23 Mbit/s with the instructions on this page.
What I am still missing now is
1. the manual white balance,
2. the manual exposure and
3. the possibility to create files larger than 4 GB with exFat formated SD cards.
Is there a manual on how to turn off the automatic white balance in the firmware?
Or a firmware version B where this is already done.
If there is a firmware that solves the problems mentioned, I will digitize my Super 8 films again

Andreas

Hello Andreas,

Thank you for your interest in this project.

The process of adjusting the white balance and exposure is not easy. People are working hard at looking at the code and trying to reverse engineer it. It is still be looking at by a number of great people here. When there is enough progress to be shared it will be.

Recent Kodak firmware updates did promise "longer recording times" but I am unsure if this bypasses the 4 GB limit of files.

 

[Hawke]

@Hawke Let me know if you try it and whether you like the results.

Hello 0dan0,

I tested it now with a short film sequence. Overall it looks very good. Sometimes I thought that yellow is a little bit to much.
But maybe it's just the age of the film. Left is stockfirmware with Mac84 Firmware, right image with your FW V2. The look feels not so cold.
I will test other movie reels

 

[0dan0]

I was only "calibrating" to a one reel, so it might be too warm on other reels. So ultimately a white balance control is want I hope for. But as the white balance is not changing, it is easier to fix in post for each shot or reel, rather than for each frame with auto WB.

 

[Hawke]

I was only "calibrating" to a one reel, so it might be too warm on other reels. So ultimately a white balance control is want I hope for. But as the white balance is not changing, it is easier to fix in post for each shot or reel, rather than for each frame with auto WB.

Especially compared to the original firmware, the colors are really much more stable when the light changes. I'll see which program is best for adjusting the colors. Do you have a recommendation? You have to cut and crop it anyway

 

[0dan0]

Especially compared to the original firmware, the colors are really much more stable when the light changes. I'll see which program is best for adjusting the colors. Do you have a recommendation? You have to cut and crop it anyway

I use Premiere Pro, which is a bit pricy. DaVinci Resolve is free and can easily do it.

 

[0dan0]

I have a new concern and maybe more extreme hack potential. We increase the bit-rate to get a more natural grain, rather than compression artifacts, yet the resolution (even 1920x1440) seems insufficient to resolve the grain. While it likely resolving something close to the film's potential (subject resolution), it is not resolving the grain, and I'm wondering why. Why is a high-end scan, even at 2K, have better grain structure than the output of Reels/Reelz 3280x2464 sensor? I'm not expected miracles, but something is less than optimal.

The first assumption we need to throw out, is the whole 1/3" sensor area is used. Wishful thinking: the whole 3280x2464 was being read in, cropped to the user requirement then scaled down to the output resolution. If this was the case, there should be more information in 1920x1440 scan, than a 1440x1080, but I'm not seeing it. Leads to these possibilities:

1) the filmmed image is only using a fraction of the sensor.
2) the camera is using a binned mode.

I expect the camera is using a combination of the two.

As this is based on dashcam technology, another clue is the weird 20fps. I filmed the LCD as the film was pulled through with a GoPro 120fps, and observed the sensor image is updating at 20fps. This is a bad sign. As a 20fps readout at 3280x2464 on this old SoC, is very unlikely. If the sensor is an OmniVision OV8810 (or similar), they can only read 3K at 10fps (it would have been better to see a 10Hz update)

https://media.digikey.com/pdf/Data%20Sheets/OmniVision%20PDFs/OV8810.pdf

Yet the same sensor does do 1080p up to 30fps. This is either binned or cropped, but likely binned. A binned sensor has a minimum of 2x2 resolution drop. 1640x1232 is the likely input image to the pipeline. This is still okay, way more information than Super 8 film is likely to hold. But I see less than that. When I test how much the reframing allows for left/right movement, to scan off the film, only about 56% is used for active picture. That would be around 932x700 for the good part of super-8. I'm resolving slightly less than that, more like 640x480. This part I've yet to determine.

I felt the resolution is so low as I'm seeing odd artifacts at the spocket hole. From a 1920x1440 scan (Mac84's spocket here) the smallest detectable detail is always about 3 pixels wide. 1920/3 = 640.

This could be a binning/debayer artifact at that bright edge, so I confirmed this by scanning some writing on the leader. Here is a crop of a leader only scan, no film grain involved. The image has aliasing that shouldn't be there, the aliasing is again around 3 pixels wide. Crudely confirmed but scaling the image down and up again, to see at what resolution the image information/detail is maintained.

As we are not getting the original source code, so the native sensor read-out is not available to us. I gather this is a M12 lens, that you can unscrew, and some users are changing the focus. My theory this is a 12mm lens (focal length), whereas it could be a 16mm, this would be 33% bump in scanned resolution, just be tighter in the framing (so camera alignment might be an issue.) A manufacture might choose a wider lens, to ease the tolerances, to make the device cheaper.

Can anyone help confirm this is a 12mm lens? What are the steps to remove the lens cover (focusing or lens replacement)?

I'm still missing a step where the potential drop is from 930 to 640 is happening, so all ideas are welcome for what could be fixed with firmware or hardware tweaks.

 

[fishgee]

I have a new concern and maybe more extreme hack potential. We increase the bit-rate to get a more natural grain, rather than compression artifacts, yet the resolution (even 1920x1440) seems insufficient to resolve the grain. While it likely resolving something close to the film's potential (subject resolution), it is not resolving the grain, and I'm wondering why. Why is a high-end scan, even at 2K, have better grain structure than the output of Reels/Reelz 3280x2464 sensor? I'm not expected miracles, but something is less than optimal.

The first assumption we need to throw out, is the whole 1/3" sensor area is used. Wishful thinking: the whole 3280x2464 was being read in, cropped to the user requirement then scaled down to the output resolution. If this was the case, there should be more information in 1920x1440 scan, than a 1440x1080, but I'm not seeing it. Leads to these possibilities:

1) the filmmed image is only using a fraction of the sensor.
2) the camera is using a binned mode.

I expect the camera is using a combination of the two.

As this is based on dashcam technology, another clue is the weird 20fps. I filmed the LCD as the film was pulled through with a GoPro 120fps, and observed the sensor image is updating at 20fps. This is a bad sign. As a 20fps readout at 3280x2464 on this old SoC, is very unlikely. If the sensor is an OmniVision OV8810 (or similar), they can only read 3K at 10fps (it would have been better to see a 10Hz update)

https://media.digikey.com/pdf/Data%20Sheets/OmniVision%20PDFs/OV8810.pdf

Yet the same sensor does do 1080p up to 30fps. This is either binned or cropped, but likely binned. A binned sensor has a minimum of 2x2 resolution drop. 1640x1232 is the likely input image to the pipeline. This is still okay, way more information than Super 8 film is likely to hold. But I see less than that. When I test how much the reframing allows for left/right movement, to scan off the film, only about 56% is used for active picture. That would be around 932x700 for the good part of super-8. I'm resolving slightly less than that, more like 640x480. This part I've yet to determine.

I felt the resolution is so low as I'm seeing odd artifacts at the spocket hole. From a 1920x1440 scan (Mac84's spocket here) the smallest detectable detail is always about 3 pixels wide. 1920/3 = 640. View attachment 19674

This could be a binning/debayer artifact at that bright edge, so I confirmed this by scanning some writing on the leader. Here is a crop of a leader only scan, no film grain involved. The image has aliasing that shouldn't be there, the aliasing is again around 3 pixels wide. Crudely confirmed but scaling the image down and up again, to see at what resolution the image information/detail is maintained.
View attachment 19675

As we are not getting the original source code, so the native sensor read-out is not available to us. I gather this is a M12 lens, that you can unscrew, and some users are changing the focus. My theory this is a 12mm lens (focal length), whereas it could be a 16mm, this would be 33% bump in scanned resolution, just be tighter in the framing (so camera alignment might be an issue.) A manufacture might choose a wider lens, to ease the tolerances, to make the device cheaper.

Can anyone help confirm this is a 12mm lens? What are the steps to remove the lens cover (focusing or lens replacement)?

I'm still missing a step where the potential drop is from 930 to 640 is happening, so all ideas are welcome for what could be fixed with firmware or hardware tweaks.

That's great deal of data, and interesting to think about.

Concerning the camera/lens, MAC84 in his Nov 12, 2023 (page 3 of this forum post) shows a great picture of the camera with the cover removed. Notice the 6 rectangular holes in the metal frame. The cover clips into these holes. I used an old credit card inserted from the front around the cover to depress the plastic clips carefully and removed the cover. The credit card is a soft plastic, so no damage to the case was seen. I tweaked the focus, but I think it was pretty spot on to begin with. The lens assembly seems to just unscrew, so another lens could conceivably screw right on in place of the OEM one.

 

[0dan0]

@fishgee Thank you. I have lens out now, and it appears to be an 8mm lens.

This is not great news, the lens is wider than I had expected. The active Super-8 frame will use 5.46x4.01mm out of an effective FOV of around 13.4x10mm. This about 40.7% on the active capture area. As I believe the image is binned to 1640, the active useful pixels are 688x516, very close to the 640x480 artifacts I was detecting. Marketing a 1728x1296 capture that is up-res'd from about 688x516 is a tad evil.

I have a 12 and 16mm lens on order to experiment.

 

[fishgee]

I can now build firmware with a fixed white balance, with independent red, green and blue gains. Here is an example comparing stock white balance with fixed WB with RGB gains of 2.0,1.0,1.06 (just guessing.)

View attachment 19592

I removed or bypassed a lot of code with the function at 0x002b7e00, which is the main white balance processing function.

void FUN_002b7e00(undefined4 param_1) { ... iVar1 = FUN_001f6f58(param_1,&local_28,&local_24,local_20); // This is the call for the new WB if (iVar1 == 2) { // This was 1, so now the WB smoothing is bypassed ... } else { // added hardwired RGB Gains for WB uVar4 = 0x1ff; // Red channel gain 511 - 1.996 uVar3 = 0x100; // Green channel gain 256 - 1.0 uVar2 = 0x10f; // Blue channel gain 271 - 1.06 ... } ... }

Attached is my WIP for Type C firmware (compare with stock type C, to implement changes on other variations.) The next big step, would be to see if the Tint control (saturation) could be turned into a more useful manual WB control. I haven't found where the tint code is yet.

0dan0, thank you for your work on this firmware. I installed it on my "C" machine and the difference is striking. I no longer have to fight the curves controls in my editing software. Now I can set it once for the whole scene. The workflow is SOOOO much easier.​

 

[wnt2fly]

Hi guys, wow I go away for a few days and look at you guys hacking this thing to pieces... So you guys are on the right track w/the sensor not fulling being used. I now have a frankenstein Wolverine with the Hawkeye modifications (I use the Eumig for fast rewind and for applying FilmGuard, it is not connected to the wolverine. The camera uses the IC capture software that allows you to set the resolution, which ranges from 640x480 up to 4000x3000 However, to properly capture at 2560x1920, metal risers are installed to size the image to be a bit larger than the film frame. You can see all of this in the attached images.

So yes, getting the right lens and the right distance from the film is critica. You won't see any improvements in resolution until you pull back the camera with risers, which then will require a different lens. This hawkeye system has a metal lens on it with an adapter to accomplish that.

@0dan0 you should look at https://drive.google.com/file/d/1e1cqvgu3F3VrwqnRD-9OUE_nICm1v9r5/view You probably can use the adapter that the designer used and possibly the lens as well.

@Joe90 I was in touch with a developer/reverse engineer expert on Upwork who looked at the code, he was going to quote me to do the work, but it looks like you are getting there as well. Besides whitebalance, the other thing that has to be fixed is the autoexposure being too sensistive.





9

 

[wnt2fly]

Also here is the end result of the Wolverine Hawkeye after my workflow:
If you have source files you'd like me to run my workflow on let me know, while I don't have a kodak machine anymore, I'm happy to help perfect the workflow. It's mainly running through a slimmed down version of VideoFreds scrip that was updated bys someone else, sometimes NeatVideo, which I run very light to preserve grain, color, crop, resize, sharpen and then focus fix.

Here is a size by side comparison of the Kodak unit (w/a higher resolution) vs the Wolverine Hawekeye. I think w/everone's help we can get the kodak to get close to the hawkeye. (ignore the resolutions in yellow, I typed them wrong. The kodak was at 1920 as well

 

[fishgee]

Hi guys, wow I go away for a few days and look at you guys hacking this thing to pieces... So you guys are on the right track w/the sensor not fulling being used. I now have a frankenstein Wolverine with the Hawkeye modifications (I use the Eumig for fast rewind and for applying FilmGuard, it is not connected to the wolverine. The camera uses the IC capture software that allows you to set the resolution, which ranges from 640x480 up to 4000x3000 However, to properly capture at 2560x1920, metal risers are installed to size the image to be a bit larger than the film frame. You can see all of this in the attached images.

So yes, getting the right lens and the right distance from the film is critica. You won't see any improvements in resolution until you pull back the camera with risers, which then will require a different lens. This hawkeye system has a metal lens on it with an adapter to accomplish that.

@0dan0 you should look at https://drive.google.com/file/d/1e1cqvgu3F3VrwqnRD-9OUE_nICm1v9r5/view You probably can use the adapter that the designer used and possibly the lens as well.

@Joe90 I was in touch with a developer/reverse engineer expert on Upwork who looked at the code, he was going to quote me to do the work, but it looks like you are getting there as well. Besides whitebalance, the other thing that has to be fixed is the autoexposure being too sensistive.





9 View attachment 19699View attachment 19698


View attachment 19693


View attachment 19692View attachment 19691

Wow, that's amazing video.

So do I have this right? You are using a DFM 37UX226-ML camera, via USB to a Windows PC running IC Capture software to capture the images? Is the Wolverine just a transport deck for the film at that point?

I found these links:

https://www.theimagingsource.com/en-us/support/download/iccapture-2.5.1525.3931/ software is free it seems.

https://www.theimagingsource.com/en-us/product/board/37u/dfm37ux226ml/ looks like the camera is around $330 US

I didn't have access to the Google Drive link you posted. I'll request it.

This may turn out to be a long journey.... but so much fun.

 

[wnt2fly]

Wow, that's amazing video.

So do I have this right? You are using a DFM 37UX226-ML camera, via USB to a Windows PC running IC Capture software to capture the images? Is the Wolverine just a transport deck for the film at that point?

I found these links:

https://www.theimagingsource.com/en-us/support/download/iccapture-2.5.1525.3931/ software is free it seems.

https://www.theimagingsource.com/en-us/product/board/37u/dfm37ux226ml/ looks like the camera is around $330 US

I didn't have access to the Google Drive link you posted. I'll request it.

This may turn out to be a long journey.... but so much fun.

Correct, however the designer of this made his own PCB that the camera sits on, includes an HDR chip as well (haven't tried that feature yet). But yes the wolverine is just the transport mechanism, as well as the light below. Agreed this is not a cheap solution, but it has all the control we want and is probably the next best thing until you get into the $8-$15k machines.

Correct software is free, not sure if it can find other cameras, maybe you can USB to the camera in the wolverine and bypass the firmware? i don't know..

Introduction to the wolverine here as well.

Wolverine-Hawkeye for Newbies - 8mm Forum

Here is a short guide to Hawkeye for the new forum members. The Wolverine Hawkeye mod is a new Wolverine controller that allows addition of 3rd party cameras and frame-by-frame image capture. The images can be captured in JPEG, BMP, or TIFF format and depending on the camera and lens can offer...

8mmforum.film-tech.com

Another item of note, @Mac84 I don't know if you've done this, but I found some of the exposure problems on the wolverine (and probably the kodak) are a result of the light plate being too large for the film and causing light leak. I took it apart and added two strips of electrical tape to block the excess light on the left/right of the film directly over the LED light plate. This light leak was causing the auto exposure to get a bit confused and also added a glare to the scan.

 

[Andreas]

I can now build firmware with a fixed white balance, with independent red, green and blue gains. Here is an example comparing stock white balance with fixed WB with RGB gains of 2.0,1.0,1.06 (just guessing.)

View attachment 19592

I removed or bypassed a lot of code with the function at 0x002b7e00, which is the main white balance processing function.

void FUN_002b7e00(undefined4 param_1) { ... iVar1 = FUN_001f6f58(param_1,&local_28,&local_24,local_20); // This is the call for the new WB if (iVar1 == 2) { // This was 1, so now the WB smoothing is bypassed ... } else { // added hardwired RGB Gains for WB uVar4 = 0x1ff; // Red channel gain 511 - 1.996 uVar3 = 0x100; // Green channel gain 256 - 1.0 uVar2 = 0x10f; // Blue channel gain 271 - 1.06 ... } ... }

Attached is my WIP for Type C firmware (compare with stock type C, to implement changes on other variations.) The next big step, would be to see if the Tint control (saturation) could be turned into a more useful manual WB control. I haven't found where the tint code is yet.

Hello OdanO,
I am very enthusiastic about what you have achieved with the white balance.
Unfortunately, I can't test it because my Kodak Reels has the firmware Type B. If you tell us which tools you used to do this, I would start at this point and try to incorporate this change into the firmware of the Type B. I use a Windows PC and have written software in "assembly", "PLZ" and "C" during my entire working life. Now I'm retired...

 

[0dan0]

Making the firmware changes to Type B (or A) should be straight forward with any hex editor (I use HxD.) Now that I've found the white balance, all you need to is download my Type C, find another Type C (without my hacks), and binary diff them. The same changes will apply. You will first have to follow Mac84 steps to decompress the firmware (use the free ntktool.jar tool.) You can ignore changes between 0x00333F00-0x0033AE60, as that is just the JPEGs I changed. I could give this a go if you don't follow. I hoping there are more enhancements coming so I didn't want to do other firmware versions yet.

 

[0dan0]

@Andreas I decided to try a Type-B to confirm it can be done with a hexeditor, without using decompiling tools like Ghidra (which what I used to find the white balance code.)

Type B users: let me know if this attachment works. It is 1600x1200 with a ~25Mb/s and a fixed (non-auto) white balance.