>> Gewendell said:

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) Click to expand...

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.

>> fishgee said:

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. Click to expand...

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.

>> ThePhage said:

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. Click to expand...

@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.

@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.

>> KODIAK said:

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. Click to expand...

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?

Hello everyone! I'm new to this forum but was drawn into it after recently purchasing the Reels unit. Unhappy with the results I was achieving, my searches for other people's insights eventually led me to here. And boy, what a treasure trove of insights I've found!! I doubt my background would be of much help to your progress (Industrial Design), but I'll chime in if I can contribute. In the meantime, I'm going to try the latest firmware postings to compare with I've already scanned. I have a couple of questions first:

1. I've found firmware in both Mac84's lookup page, and the direct downloads from this forum from @0dan0. Are they both the same firmware builds, or is there a recommendation to use one over the other?

2. Mac84's downloads also includes the original firmware. Dumb question I'm sure, but will the original firmware restore the system back to its factory setting, regardless which firmware hack I use?

Thank you in advance!

>> fishgee said:

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? Click to expand...

I need a bunch of hours to do this kind of experiments, maybe next month. I'll post the result.

>> Deano said:

Hello everyone! I'm new to this forum but was drawn into it after recently purchasing the Reels unit. Unhappy with the results I was achieving, my searches for other people's insights eventually led me to here. And boy, what a treasure trove of insights I've found!! I doubt my background would be of much help to your progress (Industrial Design), but I'll chime in if I can contribute. In the meantime, I'm going to try the latest firmware postings to compare with I've already scanned. I have a couple of questions first: 1. I've found firmware in both Mac84's lookup page, and the direct downloads from this forum from @0dan0 . Are they both the same firmware builds, or is there a recommendation to use one over the other? 2. Mac84's downloads also includes the original firmware. Dumb question I'm sure, but will the original firmware restore the system back to its factory setting, regardless which firmware hack I use? Thank you in advance! Click to expand...

The downloads from Mac84's lookup page, are the versions I also started with six months ago. You should start there to work out which hardware type you have. Once you have the type, try version 6.6 of the firmware hacks from the forum, I think you will find it is the best configuration so far. The hacks are far from perfect, particularly as I have broken on-unit playback, but it is the mostly reliable for higher quality outputs.

You can reinstall older or original firmware at any time.

Hello I'dlike to say that I tested last 6.6 firmware Post link build by 0dan0 and I found a problem inside version for A device which I have. Everything is working fine but when you d'like to save your file to SD card my device is halting menu stops to work and only restarting power helps. So is impossible to save scanning on SD card. I also checked my card in PC nothing is saved. Then I checked with different card to be certain and is the same. When I return to stock firmware or this made by Mac84 saving on card is working without problems.

>> blazejos said:

Hello I'dlike to say that I tested last 6.6 firmware Post link build by 0dan0 and I found a problem inside version for A device which I have. Everything is working fine but when you d'like to save your file to SD card my device is halting menu stops to work and only restarting power helps. So is impossible to save scanning on SD card. I also checked my card in PC nothing is saved. Then I checked with different card to be certain and is the same. When I return to stock firmware or this made by Mac84 saving on card is working without problems. Click to expand...

I have confirmed that v6.6 is working on my Type A hardware. The only know issue is with playback, so when you stop the record, select "Close" not "Playback".

Hi everyone,
thanks for sharing your tremendous efforts on improving this device. I bought a new one some 3 weeks ago and luckily found here.

Model: RODREELSEU
Ser.No: H2324148BK00769
EAN: 843812165280
FW-Version according do display: 2.0

The lookup page gave me 'Firmware C'. However the firmware I read out from my device is not identical to any of the files provided here:
find -type f -exec md5sum "{}" +
My Files:
2e281900ad9a19922cd6396c0e57e2c8 ./DUMPCODE.BIN
92ca4b99b47e71dc0afcc8d09e225b09 ./UITRON.BIN
Provided Files:
63cb2a2b137e92c8e59d526e1d59067d ./OLDER Versions and Categories/Firmware for Version 2.0 USA Devices Only/Original Unmodified v2.0 Firmware/FWDV280.BIN
3fe571c0c1a6f0baebceb1f1cd04f464 ./OLDER Versions and Categories/Firmware from Kodak.com (Assumed for version 2.0 - "IRT" Pulled)/FWDV280 - Kodak EU Website Firmware.bin
c4447ab687a9748c65b54fdce64aa6d6 ./OLDER Versions and Categories/Firmware for Version 1.0 USA Devices Only/Original Unmodified v1.0 Firmware/FWDV280.BIN
906c2b13b3b9cc68a1a457a87e49a972 ./OLDER Versions and Categories/Firmware for Version "2.1" Units - From Kodak's Email/FWDV280 Unmodified EU 20 from Kodak Email/FWDV280.bin
b5d0bb7b688f6f862573752016e5b817 ./OLDER Versions and Categories/Firmware for Version "2.1" Units - From Kodak's Email/FWDV280 Unmodified EU 20 from Kodak Email.zip
906c2b13b3b9cc68a1a457a87e49a972 ./Firmware B - Compatible files/Option 3 - Original Firmware/FWDV280.bin
3fe571c0c1a6f0baebceb1f1cd04f464 ./Firmware A - Compatible files/Option 3 - Original Firmware/FWDV280.bin
8c5fbb140bc38457d647cbbf71bd9501 ./Firmware C - Compatible files/Option 3 - Original Firmware for C/Kodak FW for H2324148BK Series/FWDV280.BIN
bb248dcc9a8770da1bd66f56cdeae28d ./Resources - Other files/Original Dumped BIN file (From the EPROM reader, cannot be used to flash)/kodak ver 2 orig dump untouched.bin

So I'm asking myself if my device is really type C or something different, leaving me hesitant to try out these awesome modifications, not wanting to brick my device.

I've attached my extracted FW files, maybe someone can confirm the device type or compatibility with the modified versions here? Thanks in advance!

>> CDenhart said:

Hi everyone, thanks for sharing your tremendous efforts on improving this device. I bought a new one some 3 weeks ago and luckily found here. Model: RODREELSEU Ser.No: H2324148BK00769 EAN: 843812165280 FW-Version according do display: 2.0 The lookup page gave me 'Firmware C'. However the firmware I read out from my device is not identical to any of the files provided here: find -type f -exec md5sum "{}" + My Files: 2e281900ad9a19922cd6396c0e57e2c8 ./DUMPCODE.BIN 92ca4b99b47e71dc0afcc8d09e225b09 ./UITRON.BIN Provided Files: 63cb2a2b137e92c8e59d526e1d59067d ./OLDER Versions and Categories/Firmware for Version 2.0 USA Devices Only/Original Unmodified v2.0 Firmware/FWDV280.BIN 3fe571c0c1a6f0baebceb1f1cd04f464 ./OLDER Versions and Categories/Firmware from Kodak.com (Assumed for version 2.0 - "IRT" Pulled)/FWDV280 - Kodak EU Website Firmware.bin c4447ab687a9748c65b54fdce64aa6d6 ./OLDER Versions and Categories/Firmware for Version 1.0 USA Devices Only/Original Unmodified v1.0 Firmware/FWDV280.BIN 906c2b13b3b9cc68a1a457a87e49a972 ./OLDER Versions and Categories/Firmware for Version "2.1" Units - From Kodak's Email/FWDV280 Unmodified EU 20 from Kodak Email/FWDV280.bin b5d0bb7b688f6f862573752016e5b817 ./OLDER Versions and Categories/Firmware for Version "2.1" Units - From Kodak's Email/FWDV280 Unmodified EU 20 from Kodak Email.zip 906c2b13b3b9cc68a1a457a87e49a972 ./Firmware B - Compatible files/Option 3 - Original Firmware/FWDV280.bin 3fe571c0c1a6f0baebceb1f1cd04f464 ./Firmware A - Compatible files/Option 3 - Original Firmware/FWDV280.bin 8c5fbb140bc38457d647cbbf71bd9501 ./Firmware C - Compatible files/Option 3 - Original Firmware for C/Kodak FW for H2324148BK Series/FWDV280.BIN bb248dcc9a8770da1bd66f56cdeae28d ./Resources - Other files/Original Dumped BIN file (From the EPROM reader, cannot be used to flash)/kodak ver 2 orig dump untouched.bin So I'm asking myself if my device is really type C or something different, leaving me hesitant to try out these awesome modifications, not wanting to brick my device. I've attached my extracted FW files, maybe someone can confirm the device type or compatibility with the modified versions here? Thanks in advance! Click to expand...

Looks like Type C, fortunately flashing the wrong version doesn't harm the units.

>> 0dan0 said:

I have confirmed that v6.6 is working on my Type A hardware. The only know issue is with playback, so when you stop the record, select "Close" not "Playback". Click to expand...

Just checked again this what you propose and I found that in such case when I don't use playback menu don't freeze and I can move to different options but when I go to my recordings and d'like to check what is saved after push on My Recordings software freeze and only reboot my helps. I checked also SD card on PC and nothing is saved here. So looks in my opinion like something is broken with saving file to card and that is why firmware freeze during checking what is on the card.

Looks like I found the solution for this problem. After checking I formatted SD card not on Kodak device firmware option which use ExFAT but on PC and then using FAT32 system from old WIN95. And now is working 0dan0 firmware is saving on SD card files.

Funny fact after some testings. Now with FAT32 file are always stored on SD cards but preview in my recordings sometimes is working sometimes is not on Kodak machine depends from don't know what this way but file is always saved so is possible to copy file on PC

I suppose there are three solution's for this problem.
1. Rebuild area in kodak firmware to create FAT32 instead exFAT on SD card (probably hard to implement)
2. Add notification to firmware in menu to create SD card partition on PC and not using menu for that (easy)
3. repair part of firmware to store movie files on exFAT (probably hard to implement)

>> blazejos said:

Looks like I found the solution for this problem. After checking I formatted SD card not on Kodak device firmware option which use ExFAT but on PC and then using FAT32 system from old WIN95. And now is working 0dan0 firmware is saving on SD card files. Click to expand...

The Kodak devices can only use FAT32 formatted SD cards when flashing firmware to the device. I believe this is posted in the instructions. Otherwise, the system just ignores the firmware update.

ExFAT formatted cards will typically work fine when recording content from the Kodak device. I've recorded tons of reels without issue to ExFAT cards.

Playback of video content on the Kodak device that has modified firmware often produces odd artifacts or glitch-filled playback/visuals. This is simply because the built-in player of the device was not designed to playback the better video files that the unit is now recording. Thankfully, the video files themselves are fine and play fine on a computer or similar device.

>> 0dan0 said:

Looks like Type C, fortunately flashing the wrong version doesn't harm the units. Click to expand...

Thanks for confirmation. Flashed V6.6 for Type C and it just works. However I needed to re-format my 128 GB SDXC card used for recording from exfat, which worked well with original FW, to fat32. Before this, it silently didn't record any files. The card used for flashing is a 2GB SD in fat32. Will now happily proceed ordering the new lens and stuff.

Hello, greetings to all the handy people here on the forum.
Today I picked up the shipment of my Kodak v.2 number C1725148BK00237.
I tried to search for new firmware on the website https://mac84.net, but I got the answer that Your serial number was NOT found. So I don't know whether to upload the recommended version B or wait to see if it appears directly for my Kodak.
But that's not what bothers me so much now.
I started trying it out on old black and white film right away. But I'm embarrassed by the quality of the shift. Some frames jump and some even have a "split" image. There is a dividing line between the frames in the middle.
When projecting, the image jumps and it's impossible to watch.
¨Can anyone advise me how to remove the jumping?
Thank you very much to everyone for the advice.
Please excuse my English, it's just a translator.

>> omega said:

Hello, greetings to all the handy people here on the forum. Today I picked up the shipment of my Kodak v.2 number C1725148BK00237. I tried to search for new firmware on the website https://mac84.net , but I got the answer that Your serial number was NOT found. So I don't know whether to upload the recommended version B or wait to see if it appears directly for my Kodak. But that's not what bothers me so much now. I started trying it out on old black and white film right away. But I'm embarrassed by the quality of the shift. Some frames jump and some even have a "split" image. There is a dividing line between the frames in the middle. When projecting, the image jumps and it's impossible to watch. ¨Can anyone advise me how to remove the jumping? Thank you very much to everyone for the advice. Please excuse my English, it's just a translator. Click to expand...

Can you share whether you're working with "normal" or Super8 film? I've scanned ca. 2 hrs of Super8 film from the late 60s for now, and didn't experience a single mispicked frame. Did you switch the mode normal / super back and forth like described in the manual?

Sorry, I forgot to add that it is super 8mm.
I switched as written in the instructions. The film plays well for a while, then skips a few times, sometimes more and sometimes less, and then plays normally for a while. This repeated itself on the entire reel where there were two films.

>> Mac84 said:

Since your machine differs than the ones in this thread, I suggest making another thread so your requests aren't buried under 25 pages of Kodak-related chat. Sadly, the underlying software or chipset don't seem to be the same - so I don't have any ideas. Click to expand...

Agreed on new thread, but the machines are very similar though and there's little other resource around. Pretty sure the main chipset is the same or a gen or 2 different.

>> 0dan0 said:

New findings. I found the non-volatile memory for storing all the settings. Non-volatile Type A 80E0B78C - Exposure 1-8 (+2.0 thru -2.0) 80E0B790 - Sharpness 1-8 (+2.0 thru -2.0) 80E0B794 - Tint 1-8 (+2.0 thru -2.0) NVM more free 80E0B7A0+ Non-volatile Type B 80E0B87C - Exposure 1-8 (+2.0 thru -2.0) 80E0B880 - Sharpness 1-8 (+2.0 thru -2.0) 80E0B884 - Tint 1-8 (+2.0 thru -2.0) NVM free 80E0B890-80E0B8fc (likely 80E0B800- 8ff is NVM) Non-volatile Type C 80E0AD0C - Exposure 1-8 (+2.0 thru -2.0) 80E0AD10 - Sharpness 1-8 (+2.0 thru -2.0) 80E0AD14 - Tint 1-8 (+2.0 thru -2.0) NVM free 80E0AD20-80E0AD8C There are a significant number of byte free to use for new features. I have also decoded how the bit-maps are stored. All 8-bit, some grey scale, some color look-up tables, all easily replaceable. More of the firmware image is just bit-maps, and JPEGs, very little code. bitmaps are just <width><height><8-bit data of size ((width+3)&~3)*height> then repeats. View attachment 22354 Why is any of this useful? I intend to replace the exposure bias (with my firmware does use) with a manual white balance control. View attachment 22355 Part way there. The fonts used palette-based (indexed color). White text is 0xd6, black text is 0x3c, transparency is 0x0. Click to expand...

Not sure if i shared this but I found you can put a DCTCONFIG.bin file on an sdcard with a filename uengmode and the machine will attempt to update these values (at least on mine). I've documented it here:


Problem is I cannot verify the changes made. It resets it back to Chinese each time you flash the modified capture config, but other than once inadvertently managing to dump a clear text output of the config, I've not been able to repeat it.