A new firmware modification for Chinese 8mm film scanners

[nicost]

Wolverine MovieMaker-PRO — firmware that saves every frame as a full-resolution still (1:1, no upscale)

As I´ve told you before, I'm not a programmer — just a patient, stubborn person who wanted better scans, working with Claude (Fable). After a lot of trial and error on the NT96650, here is a firmware for the Wolverine MovieMaker-PRO (MM100PRO) that changes what the machine does:

- Saves every film frame as an individual JPEG, instead of the stock 1440x1080 H.264 MP4.
- Native 1:1, no interpolation: 2304x1536, JPEG 4:2:2. It captures the full film gate (picture + the sprocket-hole column), about 0.9 MB per frame. (Sample still attached.)
- Extra firmware fixes vs. the OEM build: correct still colour, OSD text sized for the PL11 panel, Fast-Forward/Rewind stop, USB mass-storage, a take-up motor pulse, and a format-aware centred preview.

Capturing the whole gate, including the sprocket holes, is deliberate: it lets you stabilize and align every frame using the sprockets as a fixed reference. So I also put together a small tool (attached) to do exactly that and turn the captures into a movie (Telecine Studio):

- Sprocket-hole registration -> it locks onto the exact frame, so there is no gate weave or "flashing" between frames.
- Auto-calibrates for Super 8 and Regular 8 (nothing hard-coded), and picks the correct frame in the tricky half-pitch cases.
- Optional colour restore (removes the magenta cast of faded film) and optional extra stabilization — only if you want them.
- It is local and offline, and runs in your browser.

Its a small Web GUI that runs locally made with Claude that uses ffmpeg among other things to capture the frame from the JPGs and make a video.

The catch — it is much slower. Scanning runs at roughly 3.8 seconds per frame, about 4-5x slower than stock. So this is not for everyone. But it is unattended — you press start and walk away — so in my opinion the extra time is well worth the quality. Your call.

I am also attaching all the documentation: a full reverse-engineering knowledge base of the NT96650 (memory addresses, the capture pipeline, the emulator setup we used, the dead-ends). If anyone wants to keep improving this, it should save you a lot of time (and a lot of tokens).

I think a posible future project from all this is could be to stop Video Mode upscaling. Video mode captures at 944×652 and it upscales it to 1440×1080. The latest firmware edits from this forum already improves quality a lot by reducing video compresion. By reducing the upscaling you could get a more real output without interpolation. I think this could be a good balance between speed and video quality. The JPG method from the firmware I´m attaching has the drawback of speed and postprocessing on a PC. But on the other hand, you could stabilize the film which, at least in my scanner, wobbles a little bit during scan using the sprocket as a reference, and has almost no pixel nor colour compression at all. I think this firmware its at the practical top when referring to the quality you can get out of this scanners.

A heads-up: this runs in photo mode, so on the unit you will see a different on-screen menu than the stock movie mode — that is expected.

Flash at your own risk — it is built from the MM100PRO 20210508B-ZS15 base, so keep a rescue card with your original firmware. Details are in the firmware readme. That said, it has been running happily on my father's scanner after several nights of trying, and honestly that made all the effort worth it.

Happy to answer any questions.


[Attachment 93786 - Click to enlarge]

[nicost]

Update: Telecine Studio 1.2 — frame detection rewritten, and what I'm learning about the take-up reel

Short update for anyone trying the per-frame-stills firmware.

The PC tool (Telecine Studio 1.2, ZIP attached). The frame detector has been rewritten. The old one anchored each frame on a single sprocket hole, so one clipped or bloomed hole could throw the whole frame off. The new one fits the entire film template to every capture — all visible perforations, their known pitch, the film edges and both frame lines — with outlier rejection and sub-pixel measurement. On my two test reels the worst-frame error went from ~33 px to under 4 px, and I discovered Super 8 frames were being cropped on the sides by about 13% (fixed). Other changes:

• a scan-session selector, because a card copied whole holds several scans and the old version silently joined them into one movie;
• sharpening is now a switch (it was always on); nothing in the tool removes scratches, dust or grain — that's the film;
• frames captured while the scan was paused (near-black) are dropped by a conservative rule that keeps real scene cuts and fades;
• a "defective capture" repair path: a frame whose top band was smeared during capture gets that band from the previous frame, and it is logged. More on why below.

What I'm still fighting: the take-up reel. In photo mode the stock firmware never drives the take-up reel, so my build pulses it every 6th frame to keep up with the film. That pulse fires at the start of the capture, and I can now measure what it does: on that one capture in six, the reel's tension pulls the film while the sensor is exposing. The frame comes out 1–10% compressed and motion-blurred, and the dark frame line smears into the top of the picture — a black band on those frames. The tool now repairs the visible band, but it cannot un-blur a capture, so the real fix has to be in the firmware.

What I'm studying:

1. Move the pulse off the exposure — fire it after the capture completes, or during the film advance when the film is moving anyway. Same stub, different hook. This is the one I expect to solve it.
2. Keep the wind short. Longer or more frequent pulses make it worse; the current setting (every 6th frame, half wind) was already the least bad compromise.

It may partly be my own machine: it doesn't seem to grip the film in the gate as firmly as it should, so the reel tension moves the film more than it would on a tight unit. If your captures don't show the band, you probably don't have the problem. Either way, the firmware change should make the capture immune to reel tension on any machine, and the tool handles it in the meantime.

I'll post the firmware update once it's tested. If you have a clear-leader capture (the empty gate with blank film), keep it: the tool can use a few of those as a flat-field to map the lamp's vignette, and I'd like to compare units.

[mokyng55]

Good find. Same hardware, different brands. Firmware mod is the real fix. I'll check it out.

[x86Ger]

Hi there,

I found this thread because I've bought the Somikon 8mm Film Scanner which should be the same hardware as Reflecta / Wolverine.
I flahed it with the modified firmware from Joe to get better results. Didn't even try the OG firmware. I'm very interested in this still picture mode.

so im curious...i got the firmware version 20190529B-ZS02 from Joe.
Your Wolverine MM Pro firmware isn't compatible then?

by the way...i have some troubles while scanning. if the scanner was off for a couple of hours (like a cooldown) an i start a scan...everything works peferctly for around 10-15 min.....then...as longer the scanner is working ..the shorter the time gets to scan footage....up to a point where it scan only a few frames. always stops with the message "Please recheck film's place!" ....but the film is ok. perforation ok, no glued film....no blocking motor sound...spools run free....it's just the abrupt error message and then stopping. i can easily restart the scan...but for a 200ft reel i so have about 150 individual movie files....always have to restart the scan.

i thoght about maybe a firmware bug..timing with film transportation out of sync or sth. like that?
that's why i'm interested in testing alternative firmware.

best wishes
sascha

[nicost]

Hi Sascha,

I haven't tried Joe's firmware for too long. Just a few short test. What I found was that Joe´s firmware significantly improves the quality versus original firmware by reducing video compression. My firmware version takes a very different aproach. It saves JPG images of each frame and then I join the pictures together into a video using my PC. It takes much longer to scan than Joe's firmware (4 to 5 times longer), but, at least for me I get better results so far. In a couple of minutes ill be publishing a minor fix to my edited version of the firmware. I have a Hammacher Schlemmer, but I have tried different firmwares in the past, including Somikon, and at least in my scanner they've worked. So I think your machine is compatible.

Nicost

[nicost]

Firmware update: take-up reel fixed (no more smeared frames), a menu to tune it, and the full documentation + evidence bundle

Follow-up to my post on the take-up problem. Short version: found it, fixed it, you can now tune the reel from the scanner's own menu — and I'm finally really happy with the output.

What was wrong
My photo-mode build pulsed the take-up reel at the start of the capture. On this SoC "capture start" only queues the capture; the sensor actually exposes about 600 ms later, so the reel was pulling the film exactly while the picture was being taken. One capture in six came out compressed and motion-blurred with a dark band at the top. Measured on a 776-frame Regular 8 reel: 46 compressed, 31 with a visible band.

The fix
The pulse now fires when the capture is complete (RAW already read out): ~1.2 s after the frame trigger and ~3.4 s before the next exposure. Same reel, 880 frames with the new build: 0 compressed, 0 bands, frame-to-frame registration error down to sigma 0.4 px / max 1.6 px. The half-step ambiguities the PC tool used to fight almost disappeared as well — a good part of the "jump" was the reel disturbing the film, not the transport.

Then two full reels with the final build ("takeup-menu3"): Regular 8, 1,288 frames — 2 repaired bands and 3 flagged captures (0.2%, against 4% before), sigma 0.6 px / max 2.1 px; Super 8, 1,692 frames — 0 bands, 0 flagged, sigma 0.8 px / max 3.2 px. That Super 8 reel also exposed the last detector weakness: in a stretch of bright sky the light floods the perforation column and the small Super 8 hole vanishes into it, so the tracker had to dead-reckon for 18 frames. Telecine Studio 1.3 (below) measures the hole's top and bottom in its left third — which is always framed by unexposed film, whatever the scene — and that stretch now registers within 2.6 px.

New menu rows (photo menu; the dead Playback row and the Image Flip row were repurposed, Language is untouched)

• Take-up every: 6 frames (default) / 3 / 9 / 12 — how often the reel pulls. Bigger spools or tight reels may want 3; slack ones 9 or 12.
• Take-up wind: 6 ms (default) / 1 ms / 12 ms — how long each pull lasts. Measured with a logger, the three really are ~3 / 6 / 12 ms, but honestly the difference is hard to see by eye on my unit; it is there for machines with more tension.
• Resolution labels corrected to what the firmware actually produces: "2304 native" (leave it here), "3264 upscale", "2048 small". The stock "5M 2592x1944" label was simply wrong.

Settings survive power-off (the first version didn't: the boot-time settings validator was silently resetting them, so they now live in slots it never touches).

Known cosmetic bug: the Rewind row works when you pick NO instead of YES. Harmless, will be fixed in a later round.

How it was measured
I built an instrumented firmware that logs every transport event with a 1 MHz timer into a RAM ring buffer and writes it to the card only when the lamp goes off (never during the scan, so it can't fight the motor for the SD bus). One run settled things I had been guessing at for weeks: in photo mode the per-frame trigger is the hardware frame sensor (GPIO117 edge → fixed 1 s delay → capture), the advance motor runs continuously with a 4.000 s mechanical period, and every timing above is measured, not assumed. The whole technique is written up as a how-to so anyone can add a logger for a new question.

Documentation — what's new
The knowledge base grew from ~1950 to ~2350 lines. New or corrected:

• The real photo capture flow with addresses (capture start only posts; RAW grabbed; capture-complete handler), and the measured timing of one still.
• The photo window's message map, which the whole project had been reading one word off — with the corrected key bindings.
• Motors: the take-up pulse site and why the old one smeared frames; "PWM8" is really channel 3; the settings block, how it is saved to NAND, and the boot validator that clamps it.
• A how-to for building a transport logger: hooking with one-word jumps, the 1 MHz timer, the ring buffer, the safe dump path, the parser, how to add a site and verify it before flashing, and the lesson that a handler binding is not a button behaviour until you press the button.
• On the PC side: the frame detector was rewritten as a whole-template fit (sub-pixel, all perforations + film edges + frame lines) after finding that all earlier captures were anamorphic (a 9/8 vertical stretch of the sensor window) — the tool now fits scale per axis.

Telecine Studio 1.3: same tool as last time, plus the Super 8 fix above and the engine's console log in English. The zip now also carries DEVELOPER-NOTES.md — the engine pipeline function by function, the calibration model, the console↔GUI contract and how to validate a change — for anyone who wants to modify the tool (with or without an AI).

Files (two ZIPs)

• Firmware + tool — FWDV180N.bin (build "takeup-menu3", built on the 1:1-stills firmware from the first post; same flashing procedure, same rescue advice) + Telecine Studio 1.3.
• Documentation + evidence — meant as a starting repo for anyone who wants to point an AI at this firmware and make their own changes. It mirrors my working tree, so every file path cited in the knowledge base resolves inside the ZIP:
  - the knowledge base (Markdown + HTML), the project brief the AI sessions worked from, and the dated experiment log with every command and result;
  - the 18 per-topic analysis reports and the disassembly evidence they cite;
  - the raw transport logs (MOTION.LOG from the two instrumented runs) with their parsed CSV/summary and the parser;
  - the three RAM dumps: RAMD.BIN (128 MB, the full DRAM image of the running scanner), RAMKC.BIN (8 MB, the settings/config region the address map was verified against) and RAMK_probe.BIN (the sensor-interface registers) — if you want to check an address yourself, they are all there;
  - the patch/build system (every firmware variant is regenerated from the base image by a script) and the analysis tools (BCL/LZ77 unpacker, checksum, emulator harnesses, post-build checkers);
  - the base firmware images and a SHA256 list of every build in the lineage.

Nothing in the second ZIP is needed to use the firmware or the tool. It is there so the next person doesn't have to rediscover any of this.

[x86Ger]

i installed the new firmware to my Somikon 8mm Scanner. So far the firmware update worked.
there are some problem though:

screen resolution broken - flickering background, actual screensize reduced to half - wrong colors
the takeup wheel does not spin at all

the good news: the frame caputuring seems to work. i will put trough a real and then have a closer look.

idk why...picture here is shown upside down....

[nicost]

Thanks for testing it and for the clear report — the photo tells me exactly what happened, and it is my fault, not yours.

The screen: your unit has a different LCD panel than mine, and my build retargets the panel.

There are (at least) two silent panel revisions of this machine. The stock ZS15 firmware declares a 960-pixel-wide stripe panel. My unit (build string 20171017-PL11P-D) has a 480-wide delta-arrangement glass instead, so out of the box the stock firmware drew my UI 2-3x too wide with rotated hues. I fixed that with eight data words in the panel descriptor (tLCD_PARAM) — and those eight words are in the build I posted.

On a unit that really has the 960 panel, those same words do the damage in reverse, and they predict your three symptoms one by one:

• width 960 -> 480 and OSD render width 960 -> 320: the picture is drawn at half the screen width — exactly what your photo shows;
• vertical total 246 -> 262: the vertical timing no longer matches the glass — the flickering / rolling bands;
• odd-line start colour 0 -> 1 and panel type 2 -> 0x0D: wrong colours.

Attached: the same firmware with those eight words left at their stock values (zip; inside it, FWDV180N.bin, 2,478,684 bytes, sha256 c914f23169c2bc2a9e11fedf053d4bb014480213f90f4f8415 ff1ef90c65a403, plus a short readme with the flashing steps). Everything else is identical to the posted build — take-up pulse moved out of the exposure, the two take-up menu rows, the resolution relabels, 1:1 native stills. Flash it the same way (FAT32 card, file in the root, and delete it from the card afterwards).

Fair warning: I could not test this one. I do not have a 960-panel unit here, so this is reasoning from the panel descriptor, not something I have seen boot. It passes the same build checks as the posted firmware and it touches nothing outside those eight words. Keep your own original firmware on a rescue card before flashing it — as you should with any of these.

The take-up wheel

Let us do that one after the screen, because a readable screen makes it much easier. Two things to know meanwhile:

1. There is a quick test that tells us whether the motor itself is reachable. The take-up reel and the Rewind function are the same motor (GPIO116 on/off, GPIO114 direction). So: run Rewind from the menu (select NO instead of YES to rewind, its a minor bug that I always forget to fix). If the reel turns for Rewind, the motor and its wiring are fine and the problem is only that my pulse is too short or too rare for your mechanism — which the menu can fix. If Rewind does not turn it either, your unit drives that motor differently from mine and I will need to look further.

2. The pulse is adjustable from the menu — that is what the two new rows are for. Default is a 6 ms pull every 6th frame, which is what my machine wants. Yours may want much more: try Take-up every = 3 frames and Take-up wind = 12 ms (12 ms is the longest the firmware will do; it is the original full wind).

One thing that will confuse you until you know it

Your screen shows "10M" for the resolution, which means your unit is not set to English. I only relabelled the English string block, so in any other language you still see the old PictBridge texts on the rows I repurposed: the row that now sets the take-up cadence still reads Playback, and the wind row still reads Image Flip. Switch Language to English (that row is untouched and still works) and the rows will read "Take-up every" and "Take-up wind" with the right options. The resolution label lies in the same way — whatever it says, the captures themselves are 2304x1536 native; check the JPEG properties on the card to confirm.

On safety, since I am asking you to flash an untested image

A rule I follow without exception: my patches never touch the first part of the firmware — the loader. Everything I change lives in the application partition, and every build is regenerated from the stock image by a script, so I can always see exactly which words differ and why (this one differs from the posted build by eight words, and by nothing else). The reason for the rule is precisely your situation: if an image misbehaves, the loader is still the stock one, the unit still accepts an update from the card, and you flash your way back. That is also why I keep saying to have a rescue card with your own original firmware — not because I expect a brick, but because the recovery path only works if you have an image to recover *to*.

If we need to dig deeper, there are things I can ask of your machine

If the panel fix works but the take-up still does not, or anything else turns out to behave differently on your unit, I can build you a diagnostic firmware rather than guess. Two kinds exist already:

• An event logger. It records every transport event — motor on/off, the frame sensor, the take-up lines, capture start and end — with a 1 MHz timer into a RAM buffer, and writes it to the SD card as a file only when the lamp goes off, never while the motor is running. That is how I found that the take-up pulse was firing during the exposure. If your reel behaves differently from mine, this is what would tell us why, with microseconds instead of opinions. You scan for a few minutes, turn the lamp off, and send me the file.
• A RAM dump. It writes the scanner's memory to the card so I can check addresses against your unit instead of assuming they match mine. Useful if your unit turns out to differ in more than the panel.

Both are the same kind of change as the firmware above — application partition only, loader untouched — and both are in the documentation zip, along with a how-to for building new ones. If you would rather not flash diagnostic images, that is completely fine; just tell me what you see and we work from there.

One honest note about how fast I can help

All of this was built by me working with Claude, and the heavy lifting — the disassembly, the emulation, the firmware patches — was done with its strongest model, Fable. I have run out of credits for that one until next week. I still have Opus available, which is good and is what I used to work out your panel problem and build the attached firmware, just not as powerful for the deepest reverse-engineering work. So: I will keep helping as I can squeeze gaps out of my work day, and anything that needs the heavy artillery I will pick up next week. Please do not read a slow reply as a lack of interest — I am very interested in getting this working on your machine, not least because yours is the first unit other than mine.

If the new firmware fixes the screen, please say so and also post your unit's build string if you can find it — I would like to know which panel generation the Somikon rebrands carry, so the next person does not have to discover this by flashing.

[x86Ger]

Okay...Screen is now working perfectly.
Language is not changed / set to english...with no effect to "10M".

the rewind fucntion -> no lets the motor spin correctly.
while capturing it does not work it all....

[nicost]

Great — so the panel was exactly it. That also tells us the Somikon rebrands carry the 960-wide panel the stock firmware declares, while my Wolverine has the 480-wide one. One unknown closed for everybody.

About the "10M": my advice to switch the language was wrong, sorry. I checked the binary instead of guessing. There are two separate resolution strings: the long ones in the menu list, which I relabelled ("2304 native", "3264 upscale"), and the short badge in the corner of the live screen, which I never touched — it still says "10M" in stock and in my build alike. It is a leftover label, not a measurement, and I will fix it in the next build. To confirm what you are actually getting, put the card in your PC and check a JPEG's pixel size: it should be 2304x1536.

Two questions, and then we take it from there:

• Do you see the new menu rows? Open the menu and tell me what the first row and the sixth row say. They should read "Take-up every" and "Take-up wind".
• Did you try the strongest setting? Take-up every = 3 frames, Take-up wind = 12 ms, then scan a few dozen frames and watch the reel.

Since Rewind spins the reel properly, the motor and its wiring are fine — it is the same motor and the same lines my per-frame pulse uses. So if it still does not pull at the maximum setting, tell me and we will work out a solution from there.

[x86Ger]

I put screenshots of the menu here.
i tried every takeup-setting. no difference. while capturing -- no movement of the reel.
only when ein set rewind to "no" it moves continuesly.

JPEG size is as described 2304x1536.

[nicost]

Thanks — that settles it. The menu rows are reading correctly on your unit, the JPEGs are 2304x1536 as they should be, and you tried every take-up setting with no movement. That last part is the useful one.

I compared your stock Somikon firmware against mine instruction by instruction. The take-up motor is wired and driven identically on both machines, so that is not the difference. What differs is how long each manufacturer runs that motor: the shortest take-up burst in my Wolverine firmware is 200 ms, and the shortest one in your Somikon firmware is 400 ms — twice as long. Neither one ever runs it for single-digit milliseconds.

My per-frame pulse maxes out at 12 ms. On my machine that is just enough to nudge the reel; on yours it clearly never breaks the clutch loose — these scanners use a spring-loaded slip clutch on the take-up, and yours is evidently stiffer. Your own observation confirms it: with Rewind the motor is energised continuously and the reel turns fine.

So the pulse is simply far too short for your machine, and that is my fault for calibrating it on the only unit I had.

I am building you a firmware with pulse lengths in the range the Somikon's own firmware uses — up to 400 ms, and an option to just leave the motor running during the scan, which is what both manufacturers actually do. I will post it shortly.

[x86Ger]

let me say thank you for your kind support and efforts you take. it's well appreciated

[nicost]

Here it is — takeup-long, attached. Same base as the build that fixed your screen (stock 960-panel), so it will not touch the display again.

FWDV180N.bin — 2,478,712 bytes — sha256 327f607cf5ed1e546042424303a462d45b5f21f823ce4f720b d7f0df425e82ea

Two menu rows in photo mode:

• Take-up wind — 400 ms | 6 ms | 60 ms | Cont
• Take-up every — 6 frames | 1 frame | 3 frames | 12 frames

The defaults are now 400 ms every 6 frames — 400 ms is the shortest take-up burst your own Somikon stock firmware ever uses. So flash it and just scan a junk reel; you should not have to touch anything. The old 12 ms-ish behaviour is still there as the "6 ms" option if you ever want it back.

One thing to check: your unit remembers menu positions across a flash, so open the menu once and confirm Take-up wind really reads 400 ms rather than a slot it remembered from the build you are running now.

If the reel moves but slack builds up between pulses, keep 400 ms and go to every 3 frames or every frame. If it does not move at all, use Cont, which leaves the motor energised for the whole scan — that is what both our machines' stock firmwares actually do.

Two honest caveats, both in the README inside the zip:

1. The 400 ms pause sits inside the per-frame capture callback. I simulated it — there is about 2.8 s of slack in the 4 s frame cycle, so there is room — but I cannot prove from the firmware alone that nothing else is waiting on that callback with a shorter timeout of its own. If a scan at 400 ms stalls or drops frames, that is the reason: drop to 60 ms, or use Cont, which has no pause at all.

2. With Cont, the motor is switched off when you stop the scan with MODE, MENU or OK — I verified all three. It is not switched off when the film simply runs out, because at that point the frame sensor stops firing and the code that would switch it off never runs again. The motor keeps turning an empty spool until you press a key. The clutch slips, so it does no harm, but do not leave a finishing reel spinning unattended.

What was done instead of a hardware test, since I do not have a Somikon: the image passes the same five build gates as everything else I have posted; it differs from your current build by exactly 49 words, all in regions that are safe; and I ran the pulse routine under a MIPS emulator on the real firmware for all 16 combinations of the two settings — the right frames fire, the sleep asks for the right number of milliseconds, and Cont switches the motor on and never off. The three scan-stop paths were run the same way and all three switch the motor off before the lamp goes out. A second AI reviewer (Claude Fable) went over the disassembly independently and agreed.

As before: nothing here touches the loader, so a bad application image can always be flashed over from the card — but keep a rescue card with your unit's own original firmware anyway.

Let me know which setting finally moves it. That number is worth having: it tells me how much stiffer the Somikon clutch is, and it goes straight into the documentation for the next person with your machine.

[x86Ger]

i now set it to 12frames 400ms and it works!
also the screen now says 8M instead of 10M.

Great work!

i also want to give a shout out to you detailed explanations. i like that you take us along the way and keep us informed about the progress and how it's done.

[nicost]

Excellent News! I'll be signing off for today, but leave me any feedback and I will try to solve (if I can) any new issues tomorrow.

[x86Ger]

So...i tested it with a reel. what i can say so far is that it works for around an hour. then...the film transportation stillt works....the take up reel does not spin anymore...and it takes no pictures....but puts the film continuesly through...

that was with setting native resolution.
i'll try if there is any difference when i try a different resolution.

[nicost]

Ok, thanks for trying it out. I went and read the code, and I think I can partly explain what happened.

The take-up stopping is a symptom, not a second fault. The take-up pulse is fired by the code that runs after a frame has been captured and written. No capture, no pulse. The film transport is a separate motor that runs continuously and knows nothing about any of this — which is exactly the picture you describe.

Why it goes quiet. The per-frame capture handler (the OEM's own `UIFlowWndPhoto_OnKeyShutter2`) starts by asking the system whether it can write at all. If the answer is no, it prints

"UIFlowWndPhoto_OnKeyShutter2: Card or memory full!"

...to the serial debug port, not to the LCD, sets the photo window's state, and returns without capturing. So the machine tells you nothing, takes no picture, and never fires the take-up, while the film keeps rolling. That is your symptom set exactly, and it is stock OEM behaviour, not something I added.

There is a second bail-out immediately next to it with the same silent treatment: "Battery is too low!". Same result — no capture, no pulse, nothing on screen.

Worth noting what this is not: a plain write failure takes a different path, which logs the result and carries on. The fact that the take-up stopped too means the capture never even started — so it is one of those two checks.

So, two candidates.

1. The card. At native resolution each frame is about 1 MB and the machine takes one every 4 seconds, so it writes roughly 0.9 GB per hour. The thing to look at is not just whether the card is full — a slow card can start failing well before that. As a card fills, the driver spends longer finding free clusters and the card itself spends longer on internal housekeeping, and at some point a write no longer completes inside the window the firmware allows it. Then this check trips even though there is still space on the card. Cheap cards and worn cards do this first. For scale: my own longest continuous run is over five hours on the same capture path, so there is no built-in limit at one hour.

2. Power. If it is running off a USB port or a power bank rather than the original adapter, an hour is about when that second check would start to trip.

3. Something else. I will do some simulations on my side to see if I find something new.

Could you tell me:

1. How many JPEGs are in the folder after it stopped? That single number is the most useful thing you can send me.
2. Which card is it — brand, size, speed class — and how full was it when it stopped?
3. What is it powered from — the original adapter, or USB / a power bank?
4. After it stopped, did power-cycling and starting a new scan work again?

If you have a faster card, or a different one, that is the first thing I would swap. Copy the JPEGs off to your PC first — on some power-ups the file counter restarts at 1, and a new run can overwrite the old files.

Your idea of trying a different resolution is a good test and it discriminates cleanly: smaller files mean that if the card is the problem the run gets much longer, whereas if it stops at roughly the same number of frames regardless of resolution, the card is not the problem and I have something else to look for.

Send me those numbers and I will keep digging on this end meanwhile.

Thanks for your patience and trying the firmware out!

[nicost]

I kept digging, and I found something much more real than a card simply running out of room.

When one single JPEG write fails, the firmware permanently marks the card as bad. Every frame after that is refused before the capture even starts, which also means the take-up never fires again. I checked every place in the firmware that touches that status flag: exactly one sets it to "bad" (the failed-write path), and the only two that set it back to "good" are inside filesystem start-up. There is no retry.

So a single hiccup does not cost you one frame. It costs you the rest of the reel.

I simulated it on the real firmware: normal frame captures and the take-up pulses; I make one write fail; from that point on every frame is refused, the take-up never moves again, and the film just keeps rolling through. That is your symptom exactly.

My best guess is that one JPEG failed on your run and that killed the whole reel — which also explains why a restart should get it going again.

Still useful to know what card it is and whether power-cycling brings it back, but this is what I am chasing now.

[x86Ger]

Okay good to know. I will observe this behaviour.

on my first try i used the native resolution setting. the my problems occured.
currently i am spinning the reel again with upscaled setting. so far it runs smoothly. haven't yet reached the point of last runs dead end.

i'll look for the sc card details when the workflow is finished or stopped. what i can tell so far it is 16gb sd card formatted FAT32/64k. i think it's an original sandisk card...but i'll tell you about when i know.

write speed will not be the problem i think.

[nicost]

I have a build for the latch I described. Attached.

First, so you can decide whether you want it yet: I do not get my own scanner back until Sunday, so this has been verified by disassembly and emulation but not on hardware. It differs from the build you are running by 15 words. If you would rather wait until I have tested it on my own machine, that is completely fine — say so and I will post again on Sunday.

What it changes: a failed JPEG write now costs one frame instead of the rest of the reel. The firmware only gives up if ten writes fail in a row — and then it stops exactly the way the stock firmware does today, so nothing is lost if the card really is dead.

One thing to be aware of if it does give up. When the tenth failure stops it — or whenever capture stops for any other reason — the transport motor keeps running and keeps pulling film through, and the take-up will not wind it. That is how the stock firmware behaves too and I have not changed it: doing it properly means interfering with the transport, and that is not something I am willing to try blind, for the reason above. So do not leave a scan unattended and assume it will look after itself.

What to look for on the card afterwards. The run itself becomes the diagnostic:

• A gap in the file numbering — the file could not be opened.
• A JPEG of 0 bytes, or a truncated one, with its number in sequence — it opened but the write failed.
• Neither, and the reel completes — no write ever failed, which means what stops your machine is something else and I am looking in the wrong place.
• It stops exactly as before. If there are about ten 0-byte files right before the stop, then ten writes failed in a row and the build did what it is supposed to do — your card really is failing. If instead the last files are all healthy and there is simply nothing after them, see the caveat below.

Tell me which you get, and roughly how many of each. A clean run is not a wasted run.

Where this build cannot help, so you know before you spend a reel on it. The file number is taken and stored before the file is opened, so every attempt burns a number whether it succeeds or not. That is good news when the failure happens while writing — the file exists, at 0 bytes, and you can count them. But if the failure happens while creating the file, no file is left behind at all, and since the machine stops right afterwards there is nothing further along to make the missing numbers visible. In that case the card looks exactly the same whether it gave up after one failure or after ten, and I will not be able to tell you which.

And even when it is visible, this build shows that the writes failed, not why. The why needs a firmware that records the drive's own error messages, which I am not attempting until I have my own machine back to test on.

[x86Ger]

I just wanted to post my results to my last test. this was done with firmware before your last edit.
i found out that i'm using a kexin 16GB sd card UHS-I U1 Class 10.

google shows some reports of unreliablity. i'll switch the card for the next run.

on the actual run (upscaled setting) the scanner took 7156 pictures. i could observe that the scanner then moved on pushing the film transportation, but - and here is the interesting part -> the takeup reel and capturing did not stop completely....it just did not got over 12th frame.....on the screen i could make out a difference, wheter a frame was "skipped" or not. for some miliseconds after taking a picture...you can see the taken picture on screen (full size). this counts for the 12 frames takeup movement. but many frames are skipped (motor stops...frame in screen but not showing taken photo) Free space on sd card at this time: 1.6GB

just for info: i use the original power supply.

for the next run i will stick with the firmware version before your last edit and try a better sd card.

[nicost]

Thank you — that is a genuinely useful report, and the card model is exactly the kind of detail that is hard to guess from here.

Two things stand out: 7156 pictures is far more than the run that stopped at native resolution, and 1.6 GB free means the card was nowhere near full. The skipped frames you describe are new information to me — I do not yet know whether that was happening on earlier runs too and simply went unnoticed, or whether it is particular to this one. That is worth investigating properly and I will.

No need to change anything on your side — carry on with the card swap and the build you have. All of this feeds straight into making the firmware edit more robust.

[x86Ger]

So here are the results of 2nd test.
this time with setting "native resoluton", kingston 8GB SD Card / Fat32/64k.

The scanner took 2075 pictures...then the rest of the reel moved to the ground....(as was known to be happen).

as i pulled out the sd card i got the feeling that its very warm...maybe too warm. could perhaps result in write errors?
if true...i got thinking if there is any thermal problems with my machine.

i got similar observations with firmware from Joe. after a cooldown the machine did scan more film without stopping...the longer the machine runs...the more often i got errors then too. so...maybe no firmware problem at all. i ordered some brandnew sandisk sd cards 32GB. i'll if that will make any difference. so my next run will possibly on tuesday.

[x86Ger]

As i move on to investigate further details of the run...i noticed that there are many defective frames taken. you can see it in my picture below. the images with the "sunset symbol" are defective.

also i used telecine studio to make a video out of the pictures. i'll post the log here. it found 10 sessions? it was only 1 run.
the finished movie also show very clear, that while recording frames...many frames are dropped. the movement in the video ist cropped.
i would like to show you but i am not willing to post private video here in the forum.

[1] 2051 captures of 2304x1536
dropping 2017_0107_075303_351.JPG (brightness 115; neighbours 73 / 80) [no gap in the clock]
scan paused here: 25 s between 2017_0107_083711_985.JPG and 2017_0107_083736_986.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_083756_989.JPG and 2017_0107_083820_990.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_083952_1006.JPG and 2017_0107_084008_1007.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_085440_1191.JPG and 2017_0107_085512_1192.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_085512_1192.JPG and 2017_0107_085528_1193.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_085528_1193.JPG and 2017_0107_085600_1194.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_085600_1194.JPG and 2017_0107_085616_1195.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_085628_1197.JPG and 2017_0107_085644_1198.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_085656_1200.JPG and 2017_0107_085716_1201.JPG (nothing dropped here)
scan paused here: 28 s between 2017_0107_085716_1201.JPG and 2017_0107_085744_1202.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_091004_1353.JPG and 2017_0107_091020_1354.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_091052_1359.JPG and 2017_0107_091112_1360.JPG (nothing dropped here)
scan paused here: 36 s between 2017_0107_091200_1367.JPG and 2017_0107_091236_1368.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_091248_1369.JPG and 2017_0107_091304_1370.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_091304_1370.JPG and 2017_0107_091320_1371.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_091320_1371.JPG and 2017_0107_091336_1372.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_091336_1372.JPG and 2017_0107_091352_1373.JPG (nothing dropped here)
scan paused here: 92 s between 2017_0107_091352_1373.JPG and 2017_0107_091524_1374.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_091536_1375.JPG and 2017_0107_091556_1376.JPG (nothing dropped here)
scan paused here: 28 s between 2017_0107_091612_1378.JPG and 2017_0107_091640_1379.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_092624_1501.JPG and 2017_0107_092640_1502.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_092640_1502.JPG and 2017_0107_092656_1503.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_092712_1507.JPG and 2017_0107_092728_1508.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_092816_1514.JPG and 2017_0107_092832_1515.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_092832_1515.JPG and 2017_0107_092904_1516.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_092904_1516.JPG and 2017_0107_092920_1517.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_092920_1517.JPG and 2017_0107_092952_1518.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_092952_1518.JPG and 2017_0107_093008_1519.JPG (nothing dropped here)
scan paused here: 48 s between 2017_0107_093008_1519.JPG and 2017_0107_093056_1520.JPG (nothing dropped here)
scan paused here: 124 s between 2017_0107_093056_1520.JPG and 2017_0107_093300_1521.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_093300_1521.JPG and 2017_0107_093316_1522.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_093316_1522.JPG and 2017_0107_093332_1523.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_093348_1525.JPG and 2017_0107_093404_1526.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_093420_1528.JPG and 2017_0107_093436_1529.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_094308_1623.JPG and 2017_0107_094324_1624.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_094428_1633.JPG and 2017_0107_094444_1634.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_094500_1636.JPG and 2017_0107_094524_1637.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_094532_1638.JPG and 2017_0107_094548_1639.JPG (nothing dropped here)
scan paused here: 308 s between 2017_0107_094556_1641.JPG and 2017_0107_095104_1642.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_095108_1643.JPG and 2017_0107_095124_1644.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_095140_1646.JPG and 2017_0107_095156_1647.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_095156_1647.JPG and 2017_0107_095212_1648.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_095820_1709.JPG and 2017_0107_095836_1710.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_095940_1722.JPG and 2017_0107_095956_1723.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_100100_1732.JPG and 2017_0107_100116_1733.JPG (nothing dropped here)
scan paused here: 36 s between 2017_0107_100132_1735.JPG and 2017_0107_100208_1736.JPG (nothing dropped here)
scan paused here: 80 s between 2017_0107_100208_1736.JPG and 2017_0107_100328_1737.JPG (nothing dropped here)
scan paused here: 312 s between 2017_0107_100328_1737.JPG and 2017_0107_100840_1738.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_100900_1741.JPG and 2017_0107_100916_1742.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_100916_1742.JPG and 2017_0107_100932_1743.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_101748_1828.JPG and 2017_0107_101804_1829.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_101836_1833.JPG and 2017_0107_101852_1834.JPG (nothing dropped here)
scan paused here: 52 s between 2017_0107_101852_1834.JPG and 2017_0107_101944_1835.JPG (nothing dropped here)
scan paused here: 48 s between 2017_0107_101944_1835.JPG and 2017_0107_102032_1836.JPG (nothing dropped here)
scan paused here: 267 s between 2017_0107_102032_1836.JPG and 2017_0107_102459_1837.JPG (nothing dropped here)
scan paused here: 28 s between 2017_0107_102459_1837.JPG and 2017_0107_102527_1838.JPG (nothing dropped here)
scan paused here: 17 s between 2017_0107_102527_1838.JPG and 2017_0107_102544_1839.JPG (nothing dropped here)
scan paused here: 17 s between 2017_0107_102547_1840.JPG and 2017_0107_102604_1841.JPG (nothing dropped here)
scan paused here: 15 s between 2017_0107_102620_1843.JPG and 2017_0107_102635_1844.JPG (nothing dropped here)
scan paused here: 13 s between 2017_0107_102635_1844.JPG and 2017_0107_102648_1845.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_102812_1861.JPG and 2017_0107_102828_1862.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_102828_1862.JPG and 2017_0107_102844_1863.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_102912_1866.JPG and 2017_0107_102928_1867.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_103020_1874.JPG and 2017_0107_103036_1875.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_103152_1886.JPG and 2017_0107_103212_1887.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_103228_1889.JPG and 2017_0107_103300_1890.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_103300_1890.JPG and 2017_0107_103316_1891.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_103316_1891.JPG and 2017_0107_103332_1892.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_103332_1892.JPG and 2017_0107_103348_1893.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_103348_1893.JPG and 2017_0107_103412_1894.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_103412_1894.JPG and 2017_0107_103436_1895.JPG (nothing dropped here)
scan paused here: 64 s between 2017_0107_103436_1895.JPG and 2017_0107_103540_1896.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_103540_1896.JPG and 2017_0107_103556_1897.JPG (nothing dropped here)
scan paused here: 351 s between 2017_0107_103556_1897.JPG and 2017_0107_104147_1898.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_104159_1899.JPG and 2017_0107_104219_1900.JPG (nothing dropped here)
scan paused here: 44 s between 2017_0107_104219_1900.JPG and 2017_0107_104303_1901.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_104303_1901.JPG and 2017_0107_104323_1902.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_104439_1914.JPG and 2017_0107_104455_1915.JPG (nothing dropped here)
scan paused here: 15 s between 2017_0107_104500_1916.JPG and 2017_0107_104515_1917.JPG (nothing dropped here)
scan paused here: 13 s between 2017_0107_104707_1936.JPG and 2017_0107_104720_1937.JPG (nothing dropped here)
scan paused here: 19 s between 2017_0107_104720_1937.JPG and 2017_0107_104739_1938.JPG (nothing dropped here)
scan paused here: 15 s between 2017_0107_104812_1945.JPG and 2017_0107_104827_1946.JPG (nothing dropped here)
scan paused here: 13 s between 2017_0107_104827_1946.JPG and 2017_0107_104840_1947.JPG (nothing dropped here)
scan paused here: 13 s between 2017_0107_104855_1949.JPG and 2017_0107_104908_1950.JPG (nothing dropped here)
scan paused here: 13 s between 2017_0107_104915_1951.JPG and 2017_0107_104928_1952.JPG (nothing dropped here)
scan paused here: 23 s between 2017_0107_104956_1955.JPG and 2017_0107_105019_1956.JPG (nothing dropped here)
scan paused here: 17 s between 2017_0107_105019_1956.JPG and 2017_0107_105036_1957.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_105036_1957.JPG and 2017_0107_105052_1958.JPG (nothing dropped here)
scan paused here: 40 s between 2017_0107_105052_1958.JPG and 2017_0107_105132_1959.JPG (nothing dropped here)
scan paused here: 64 s between 2017_0107_105132_1959.JPG and 2017_0107_105236_1960.JPG (nothing dropped here)
scan paused here: 423 s between 2017_0107_105236_1960.JPG and 2017_0107_105939_1961.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_110007_1964.JPG and 2017_0107_110023_1965.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_110127_1974.JPG and 2017_0107_110147_1975.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_110407_1997.JPG and 2017_0107_110423_1998.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_110423_1998.JPG and 2017_0107_110443_1999.JPG (nothing dropped here)
scan paused here: 40 s between 2017_0107_110451_2000.JPG and 2017_0107_110531_2001.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_110555_2004.JPG and 2017_0107_110615_2005.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_110707_2013.JPG and 2017_0107_110731_2014.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_110739_2015.JPG and 2017_0107_110755_2016.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_110755_2016.JPG and 2017_0107_110827_2017.JPG (nothing dropped here)
scan paused here: 495 s between 2017_0107_110844_2019.JPG and 2017_0107_111659_2020.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_111659_2020.JPG and 2017_0107_111715_2021.JPG (nothing dropped here)
scan paused here: 20 s between 2017_0107_111727_2022.JPG and 2017_0107_111747_2023.JPG (nothing dropped here)
scan paused here: 44 s between 2017_0107_111747_2023.JPG and 2017_0107_111831_2024.JPG (nothing dropped here)
scan paused here: 44 s between 2017_0107_111831_2024.JPG and 2017_0107_111915_2025.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_111919_2026.JPG and 2017_0107_111951_2027.JPG (nothing dropped here)
scan paused here: 36 s between 2017_0107_111951_2027.JPG and 2017_0107_112027_2028.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_112059_2032.JPG and 2017_0107_112131_2033.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_112131_2033.JPG and 2017_0107_112147_2034.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_112235_2041.JPG and 2017_0107_112251_2042.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_112251_2042.JPG and 2017_0107_112307_2043.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_112307_2043.JPG and 2017_0107_112331_2044.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_112355_2048.JPG and 2017_0107_112427_2049.JPG (nothing dropped here)
scan paused here: 480 s between 2017_0107_112427_2049.JPG and 2017_0107_113227_2050.JPG (nothing dropped here)
scan paused here: 80 s between 2017_0107_113227_2050.JPG and 2017_0107_113347_2051.JPG (nothing dropped here)
scan paused here: 28 s between 2017_0107_113347_2051.JPG and 2017_0107_113415_2052.JPG (nothing dropped here)
scan paused here: 48 s between 2017_0107_113419_2053.JPG and 2017_0107_113507_2054.JPG (nothing dropped here)
scan paused here: 48 s between 2017_0107_113507_2054.JPG and 2017_0107_113555_2055.JPG (nothing dropped here)
scan paused here: 48 s between 2017_0107_113555_2055.JPG and 2017_0107_113643_2056.JPG (nothing dropped here)
scan paused here: 72 s between 2017_0107_113643_2056.JPG and 2017_0107_113755_2057.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_113803_2059.JPG and 2017_0107_113819_2060.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_113835_2062.JPG and 2017_0107_113859_2063.JPG (nothing dropped here)
scan paused here: 24 s between 2017_0107_113859_2063.JPG and 2017_0107_113923_2064.JPG (nothing dropped here)
scan paused here: 784 s between 2017_0107_113923_2064.JPG and 2017_0107_115227_2065.JPG (nothing dropped here)
scan paused here: 96 s between 2017_0107_115227_2065.JPG and 2017_0107_115403_2066.JPG (nothing dropped here)
scan paused here: 112 s between 2017_0107_115415_2067.JPG and 2017_0107_115607_2068.JPG (nothing dropped here)
scan paused here: 36 s between 2017_0107_115607_2068.JPG and 2017_0107_115643_2069.JPG (nothing dropped here)
scan paused here: 32 s between 2017_0107_115643_2069.JPG and 2017_0107_115715_2070.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_115727_2071.JPG and 2017_0107_115743_2072.JPG (nothing dropped here)
scan paused here: 68 s between 2017_0107_115743_2072.JPG and 2017_0107_115851_2073.JPG (nothing dropped here)
scan paused here: 16 s between 2017_0107_115851_2073.JPG and 2017_0107_115907_2074.JPG (nothing dropped here)
scan paused here: 752 s between 2017_0107_115907_2074.JPG and 2017_0107_121139_2075.JPG (nothing dropped here)
[1b] pauses: 132 clock gaps (median cadence 4 s), 1 captures dropped by the rule (brightness threshold 31, texture 35)
[2] Calibration over 48 captures: perforation 120x152 px at x=640, pitch 544.6 px (full res.; 144 perfs, 96 gaps)
line between frames: phase 131.0 px relative to the perforation (pitch 272), width 7 px, contrast 0.75 -> frame y = perf-135 .. +124 (scale 1/2)
picture column x = 353..744 [temporal variability (line contrast gave 354..744)] -> frame x = perf+45, width 375; height 259 (scale 1/2; output 750x516 px)
travel direction: the content RISES (new frames enter from the bottom) (votes up 28 / down 0, median margin +0.237)
fine geometry (scale 1/2): perforation height 78.1, pitch 272.95 (top edges, 96 pairs; coarse 272.95), line width 5.0 (217 measurements), perforation column dx/dy +0.0013 (MAD 0.0103); 0 calibration captures excluded because the film was buckled
line -1: perf-416.3 +0.00 px per pitch of height, sigma 1.18 px (n=35)
line +0: perf-142.3 +2.52 px per pitch of height, sigma 0.90 px (n=73)
line +1: perf+134.1 +3.68 px per pitch of height, sigma 0.80 px (n=72)
line +2: perf+405.8 +0.00 px per pitch of height, sigma 0.88 px (n=36)
frame height line to line (at the center): 276.21 +0.00 px per pitch of height, sigma 0.42 (n=97)
format Super 8 (line phase 0.48 of the pitch): VERTICAL scale 128.9 px/mm (pitch); HORIZONTAL 137.4 px/mm (picture width) / 131.3 (perforation width, unreliable); anisotropy y/x = 0.938 [check only: the geometry is measured per axis, one scale is never derived from the other]
gate vignetting (from the roll itself): core 76, band >= 90% = rows 20..726 of 768 (scale 1/2)
50/2050 {'OK': 50} (3s)
100/2050 {'OK': 100} (6s)
150/2050 {'OK': 150} (10s)
200/2050 {'OK': 199, 'NOIMG': 1} (13s)
250/2050 {'OK': 249, 'NOIMG': 1} (16s)
300/2050 {'OK': 299, 'NOIMG': 1} (19s)
350/2050 {'OK': 349, 'NOIMG': 1} (23s)
400/2050 {'OK': 399, 'NOIMG': 1} (26s)
450/2050 {'OK': 449, 'NOIMG': 1} (30s)
500/2050 {'OK': 499, 'NOIMG': 1} (33s)
550/2050 {'OK': 549, 'NOIMG': 1} (37s)
600/2050 {'OK': 599, 'NOIMG': 1} (41s)
650/2050 {'OK': 649, 'NOIMG': 1} (45s)
700/2050 {'OK': 699, 'NOIMG': 1} (48s)
750/2050 {'OK': 749, 'NOIMG': 1} (51s)
800/2050 {'OK': 799, 'NOIMG': 1} (55s)
850/2050 {'OK': 849, 'NOIMG': 1} (59s)
900/2050 {'OK': 899, 'NOIMG': 1} (62s)
950/2050 {'OK': 949, 'NOIMG': 1} (66s)
1000/2050 {'OK': 999, 'NOIMG': 1} (69s)
1050/2050 {'OK': 1049, 'NOIMG': 1} (73s)
1100/2050 {'OK': 1099, 'NOIMG': 1} (76s)
1150/2050 {'OK': 1149, 'NOIMG': 1} (79s)
1200/2050 {'OK': 1199, 'NOIMG': 1} (83s)
1250/2050 {'OK': 1249, 'NOIMG': 1} (86s)
1300/2050 {'OK': 1299, 'NOIMG': 1} (90s)
1350/2050 {'OK': 1349, 'NOIMG': 1} (93s)
1400/2050 {'OK': 1399, 'NOIMG': 1} (96s)
1450/2050 {'OK': 1449, 'NOIMG': 1} (99s)
1500/2050 {'OK': 1499, 'NOIMG': 1} (102s)
1550/2050 {'OK': 1549, 'NOIMG': 1} (105s)
1600/2050 {'OK': 1599, 'NOIMG': 1} (108s)
1650/2050 {'OK': 1649, 'NOIMG': 1} (112s)
1700/2050 {'OK': 1699, 'NOIMG': 1} (115s)
1750/2050 {'OK': 1749, 'NOIMG': 1} (120s)
1800/2050 {'OK': 1799, 'NOIMG': 1} (123s)
1850/2050 {'OK': 1849, 'NOIMG': 1} (127s)
1900/2050 {'OK': 1899, 'NOIMG': 1} (131s)
1950/2050 {'OK': 1949, 'NOIMG': 1} (134s)
2000/2050 {'OK': 1999, 'NOIMG': 1} (137s)
2050/2050 {'OK': 2049, 'NOIMG': 1} (141s)
[3] Registration: {'OK': 2049, 'NOIMG': 1} -> 2049 output frames (750x522) in 141s
INDEPENDENT crop check (p90 line across the width, unsaturated, output px at scale 1/2): median +0.0, sigma 2.9, p90|err| 1.5, |max| 41.1, > 5 px: 16, 1168 of 2049 measurements
(v1 check, reference only: saturates at +-16 px and assumes a rigid pitch, NOT comparable after the resampling): median +1.6 px, sigma 1.6 px, |max| 15.7 px, 1964 of 2049 measurements
defective captures: 11 with the band repaired from the previous frame (#1158 [anomalous top band 8 rows], #1438 [anomalous bottom band 4 rows], #1743 [anomalous top band 88 rows], #1744 [anomalous top band 38 rows], #1777 [anomalous bottom band 4 rows], #1778 [anomalous bottom band 44 rows], #1803 [anomalous bottom band 29 rows], #1805 [anomalous top band 40 rows], #1812 [anomalous top band 75 rows], #1847 [anomalous top band 4 rows], #1962 [anomalous bottom band 20 rows]); 146 only flagged (#78 [extensive change top relative to the previous frame: not a band, not repaired], #85 [extensive change top relative to the previous frame: not a band, not repaired], #86 [extensive change top relative to the previous frame: not a band, not repaired], #94 [extensive change top relative to the previous frame: not a band, not repaired], #110 [extensive change top relative to the previous frame: not a band, not repaired], #125 [anomalous top band 3 rows; no reference (scene differs from the previous one): not repaired], #126 [extensive change top relative to the previous frame: not a band, not repaired], #133 [anomalous top band 4 rows; no reference (scene differs from the previous one): not repaired], #134 [extensive change top relative to the previous frame: not a band, not repaired], #138 [extensive change top relative to the previous frame: not a band, not repaired], #146 [anomalous top band 51 rows; no reference (scene differs from the previous one): not repaired], #198 [anomalous top band 11 rows; no reference (scene differs from the previous one): not repaired], #202 [extensive change top relative to the previous frame: not a band, not repaired], #205 [anomalous top band 5 rows; no reference (scene differs from the previous one): not repaired], #206 [anomalous top band 57 rows; no reference (scene differs from the previous one): not repaired], #214 [extensive change top relative to the previous frame: not a band, not repaired], #223 [extensive change top relative to the previous frame: not a band, not repaired], #225 [anomalous top band 127 rows; no reference (scene differs from the previous one): not repaired], #226 [anomalous top band 126 rows; no reference (scene differs from the previous one): not repaired], #228 [anomalous top band 117 rows; no reference (scene differs from the previous one): not repaired], #232 [anomalous top band 121 rows; no reference (scene differs from the previous one): not repaired], #233 [anomalous top band 122 rows; no reference (scene differs from the previous one): not repaired], #236 [extensive change top relative to the previous frame: not a band, not repaired], #242 [anomalous top band 12 rows; no reference (scene differs from the previous one): not repaired], #243 [anomalous top band 43 rows; no reference (scene differs from the previous one): not repaired], #247 [anomalous top band 49 rows; no reference (scene differs from the previous one): not repaired], #250 [anomalous top band 59 rows; no reference (scene differs from the previous one): not repaired], #253 [anomalous top band 61 rows; no reference (scene differs from the previous one): not repaired], #254 [anomalous top band 33 rows; no reference (scene differs from the previous one): not repaired], #257 [anomalous top band 3 rows; no reference (scene differs from the previous one): not repaired], #261 [anomalous top band 33 rows; no reference (scene differs from the previous one): not repaired], #300 [extensive change top relative to the previous frame: not a band, not repaired], #304 [anomalous top band 125 rows; no reference (scene differs from the previous one): not repaired], #309 [anomalous top band 124 rows; no reference (scene differs from the previous one): not repaired], #310 [anomalous top band 19 rows; no reference (scene differs from the previous one): not repaired], #311 [anomalous top band 129 rows; no reference (scene differs from the previous one): not repaired], #320 [extensive change top relative to the previous frame: not a band, not repaired], #322 [extensive change top relative to the previous frame: not a band, not repaired], #323 [extensive change top relative to the previous frame: not a band, not repaired], #325 [extensive change top relative to the previous frame: not a band, not repaired], #329 [anomalous top band 11 rows; no reference (scene differs from the previous one): not repaired], #330 [extensive change top relative to the previous frame: not a band, not repaired], #439 [extensive change top relative to the previous frame: not a band, not repaired], #445 [extensive change top relative to the previous frame: not a band, not repaired], #460 [extensive change top relative to the previous frame: not a band, not repaired], #461 [extensive change top relative to the previous frame: not a band, not repaired], #465 [extensive change top relative to the previous frame: not a band, not repaired], #466 [extensive change top relative to the previous frame: not a band, not repaired], #468 [extensive change top relative to the previous frame: not a band, not repaired], #469 [extensive change top relative to the previous frame: not a band, not repaired], #472 [extensive change top relative to the previous frame: not a band, not repaired], #473 [extensive change top relative to the previous frame: not a band, not repaired], #475 [extensive change top relative to the previous frame: not a band, not repaired], #476 [extensive change top relative to the previous frame: not a band, not repaired], #478 [extensive change top relative to the previous frame: not a band, not repaired], #479 [extensive change top relative to the previous frame: not a band, not repaired], #480 [extensive change top relative to the previous frame: not a band, not repaired], #481 [extensive change top relative to the previous frame: not a band, not repaired], #484 [extensive change top relative to the previous frame: not a band, not repaired], #485 [extensive change top relative to the previous frame: not a band, not repaired], #486 [extensive change top relative to the previous frame: not a band, not repaired], #487 [extensive change top relative to the previous frame: not a band, not repaired], #488 [extensive change top relative to the previous frame: not a band, not repaired], #493 [extensive change top relative to the previous frame: not a band, not repaired], #494 [extensive change top relative to the previous frame: not a band, not repaired], #498 [extensive change top relative to the previous frame: not a band, not repaired], #499 [extensive change top relative to the previous frame: not a band, not repaired], #500 [extensive change top relative to the previous frame: not a band, not repaired], #501 [extensive change top relative to the previous frame: not a band, not repaired], #502 [extensive change top relative to the previous frame: not a band, not repaired], #506 [extensive change top relative to the previous frame: not a band, not repaired], #516 [extensive change top relative to the previous frame: not a band, not repaired], #518 [extensive change top relative to the previous frame: not a band, not repaired], #519 [extensive change top relative to the previous frame: not a band, not repaired], #520 [extensive change top relative to the previous frame: not a band, not repaired], #525 [extensive change top relative to the previous frame: not a band, not repaired], #529 [extensive change top relative to the previous frame: not a band, not repaired], #530 [extensive change top relative to the previous frame: not a band, not repaired], #539 [extensive change top relative to the previous frame: not a band, not repaired], #540 [extensive change top relative to the previous frame: not a band, not repaired], #541 [extensive change top relative to the previous frame: not a band, not repaired], #542 [extensive change top relative to the previous frame: not a band, not repaired], #553 [extensive change top relative to the previous frame: not a band, not repaired], #554 [extensive change top relative to the previous frame: not a band, not repaired], #565 [extensive change top relative to the previous frame: not a band, not repaired], #659 [extensive change top relative to the previous frame: not a band, not repaired], #660 [extensive change top relative to the previous frame: not a band, not repaired], #731 [anomalous top band 113 rows; no reference (scene differs from the previous one): not repaired], #732 [anomalous top band 127 rows; no reference (scene differs from the previous one): not repaired], #744 [anomalous top band 106 rows; no reference (scene differs from the previous one): not repaired], #745 [anomalous top band 89 rows; no reference (scene differs from the previous one): not repaired], #761 [anomalous top band 42 rows; no reference (scene differs from the previous one): not repaired], #762 [anomalous top band 7 rows; no reference (scene differs from the previous one): not repaired], #763 [anomalous top band 46 rows; no reference (scene differs from the previous one): not repaired], #816 [extensive change top relative to the previous frame: not a band, not repaired], #829 [extensive change top relative to the previous frame: not a band, not repaired], #830 [extensive change top relative to the previous frame: not a band, not repaired], #1176 [anomalous bottom band 41 rows; no reference (scene differs from the previous one): not repaired], #1697 [anomalous bottom band 90 rows; no reference (scene differs from the previous one): not repaired], #1698 [anomalous bottom band 99 rows; no reference (scene differs from the previous one): not repaired], #1700 [anomalous bottom band 97 rows; no reference (scene differs from the previous one): not repaired], #1717 [anomalous top band 42 rows; no reference (scene differs from the previous one): not repaired], #1721 [anomalous top band 80 rows; no reference (scene differs from the previous one): not repaired], #1872 [extensive change bottom relative to the previous frame: not a band, not repaired], #1873 [extensive change bottom relative to the previous frame: not a band, not repaired], #1877 [extensive change bottom relative to the previous frame: not a band, not repaired], #1878 [extensive change bottom relative to the previous frame: not a band, not repaired], #1879 [extensive change bottom relative to the previous frame: not a band, not repaired], #1882 [extensive change bottom relative to the previous frame: not a band, not repaired], #1885 [extensive change bottom relative to the previous frame: not a band, not repaired], #1886 [extensive change bottom relative to the previous frame: not a band, not repaired], #1887 [extensive change bottom relative to the previous frame: not a band, not repaired], #1888 [extensive change bottom relative to the previous frame: not a band, not repaired], #1889 [extensive change bottom relative to the previous frame: not a band, not repaired; anomalous top band 5 rows; no reference (scene differs from the previous one): not repaired], #1892 [extensive change bottom relative to the previous frame: not a band, not repaired; anomalous top band 58 rows; no reference (scene differs from the previous one): not repaired], #1893 [anomalous top band 90 rows; anomalous bottom band 110 rows; no reference (scene differs from the previous one): not repaired], #1894 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 74 rows; no reference (scene differs from the previous one): not repaired], #1895 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 43 rows; no reference (scene differs from the previous one): not repaired], #1896 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 5 rows; no reference (scene differs from the previous one): not repaired], #1897 [anomalous top band 12 rows; no reference (scene differs from the previous one): not repaired], #1900 [anomalous top band 63 rows; no reference (scene differs from the previous one): not repaired], #1901 [anomalous top band 68 rows; no reference (scene differs from the previous one): not repaired], #1902 [anomalous top band 79 rows; no reference (scene differs from the previous one): not repaired], #1903 [anomalous top band 62 rows; no reference (scene differs from the previous one): not repaired], #1904 [anomalous top band 76 rows; no reference (scene differs from the previous one): not repaired], #1905 [anomalous top band 42 rows; no reference (scene differs from the previous one): not repaired], #1960 [anomalous top band 3 rows; no reference (scene differs from the previous one): not repaired], #1966 [extensive change bottom relative to the previous frame: not a band, not repaired], #1968 [anomalous bottom band 127 rows; no reference (scene differs from the previous one): not repaired], #1969 [anomalous bottom band 122 rows; no reference (scene differs from the previous one): not repaired], #1970 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 120 rows; no reference (scene differs from the previous one): not repaired], #1971 [anomalous top band 130 rows; anomalous bottom band 113 rows; no reference (scene differs from the previous one): not repaired], #1972 [anomalous top band 123 rows; anomalous bottom band 99 rows; no reference (scene differs from the previous one): not repaired], #1973 [anomalous top band 113 rows; anomalous bottom band 102 rows; no reference (scene differs from the previous one): not repaired], #1988 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 74 rows; no reference (scene differs from the previous one): not repaired], #1994 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 18 rows; no reference (scene differs from the previous one): not repaired], #1998 [anomalous top band 91 rows; anomalous bottom band 117 rows; no reference (scene differs from the previous one): not repaired], #1999 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 58 rows; no reference (scene differs from the previous one): not repaired], #2002 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 40 rows; no reference (scene differs from the previous one): not repaired], #2006 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 34 rows; no reference (scene differs from the previous one): not repaired], #2009 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 26 rows; no reference (scene differs from the previous one): not repaired], #2011 [extensive change top relative to the previous frame: not a band, not repaired; anomalous bottom band 20 rows; no reference (scene differs from the previous one): not repaired], #2031 [anomalous top band 58 rows; no reference (scene differs from the previous one): not repaired], #2034 [anomalous top band 27 rows; no reference (scene differs from the previous one): not repaired], #2039 [anomalous top band 34 rows; no reference (scene differs from the previous one): not repaired], #2044 [anomalous top band 66 rows; no reference (scene differs from the previous one): not repaired])
SUB-PIXEL check, top line (valley centroid vs crop, scale 1/2): median +0.23 px, sigma 0.81 px, |max| 3.0 px, 1555 of 2049 measurements
SUB-PIXEL check, bottom line (valley centroid vs crop, scale 1/2): median +0.12 px, sigma 0.88 px, |max| 2.4 px, 1574 of 2049 measurements
fit vs the perforation alone: median correction -0.34 px, |correction| p90 1.1 px, max 2.0 px
vertical frame scale (lines / nominal pitch): median 1.0120, p5 1.0092, p95 1.0143, min 1.007; |s-1| > 0.5%: 2049, > 2%: 0; resampled 2049 of 2049
perforation x: 316.2 .. 320.4 (horizontal weave 4.2 px at scale 1/2)
[4] Assembling at 18 fps -> /media/sascha/44A2-20FE/FilmScanner/PHOTO/test.mp4

[DONE] -> /media/sascha/44A2-20FE/FilmScanner/PHOTO/test.mp4

[x86Ger]

So my new SD cards already arrived today. I made a new test.
the scanner very quickly started to drop frames. already after 15mins many frames have not been caputured. when it captures a frame then, the count number of the image files goes +1. although there maybe have been 10 frames in row where it did not capute but move the film forward.

[x86Ger]

Hello again,

i made a new test yesterday (let it run over night). This time i used the write-retry firmware. here are some interesting observations:
- the reel runs through until the end
- after pictur no. 723 the reel was pushed forward...but no pictures were taken
- many dropped pictures (without numbering inbetween).
- after 5 hours of not taking any pictures...it continues with pic 724....(the reel was already empty then)

[x86Ger]

In addition to my last post. I analyzed a defective jpg file:

Summary of the failure in file 2017_0101_013838_519.JPG

The analysis of the original file shows that this is not simply a damaged JPEG header. The file contains a valid JPEG structure, but the image data itself is corrupted or incorrectly generated.

1. Unexpected data before the JPEG

The file starts with approximately 65,536 bytes of non-JPEG data.

Instead of the normal JPEG signature:

FF D8 FF

the file begins with structured ASCII/binary data containing entries such as:

RGB
Flash Info
Redeye
Noflash CA
Preflash CA

and numerous RGB values.

The JPEG starts only at:

offset 0x10000 (65,536)
FF D8 FF E1

The exact 64 KiB boundary strongly suggests that this is a buffer or diagnostic data block, rather than random filesystem corruption.

2. The data is clearly related to the camera's image-processing pipeline

The data found both before and after the JPEG contains parameters such as:

ExpectY
LumY
PrvEV_Value
CapEV_Value
Prv_ISOGain
Prv_ExpoTime
RGain
GGain
BGain
Weight Table

These are characteristic of internal image-processing operations such as exposure, gain, brightness and color processing.

Therefore, the data appears to originate from the camera/firmware image-processing system, not from a normal JPEG file.

3. A valid JPEG is embedded in the file

A complete JPEG starts at offset 65,536 and ends at approximately 873,720.

Its header identifies it as a:

2304 × 1536

JPEG image with Exif information.

The JPEG itself is syntactically valid and can be decoded. However, the resulting image is visibly incorrect: only parts of the expected film image are present, with corrupted/misassembled image content.

This is important because it means that repairing or replacing the JPEG header cannot restore the correct image.

4. There is another JPEG/data structure afterwards

Immediately after the first JPEG, additional data follows, including another JPEG structure and further camera/ISP parameters.

A separate intact 640×480 JPEG can be extracted from this region, and that JPEG is technically valid. It appears to be a secondary/preview image rather than the original full-resolution image.

5. Comparison with the neighbouring valid file

The correctly recorded 520.JPG has a conventional JPEG structure beginning directly with:

FF D8 FF E0
JFIF

and does not contain the large diagnostic data block found in 519.JPG.

This makes ordinary filesystem damage or a simple missing JPEG header unlikely.

Conclusion

The most plausible interpretation of 519.JPG is:

The camera/firmware did not correctly create the image file during capture. Internal image-processing/debug data was written into the file, including a 64 KiB block before the JPEG. Although a complete JPEG container is present, its actual image data is already incorrect/corrupted.

In other words, the problem is not primarily a damaged file header. The JPEG header and much of the JPEG structure are intact; the corruption occurred at the image-generation/file-writing stage.

The available evidence does not allow us to determine the exact firmware bug or the precise reason why frame 519 was affected. Possible causes include an incorrect/overwritten image buffer or a synchronization problem between image capture, ISP processing and JPEG encoding, but those would remain hypotheses without further affected/working files or firmware analysis.

Most importantly: the original 2304×1536 image cannot currently be reconstructed simply by removing the 65 KiB prefix. The necessary correct pixel data does not appear to exist in the file in a usable form.

[x86Ger]

And yet another post from me

I just found out that the light sensor on my unit was faulty. Maybe that is a possible reason for writeproblems?
I took my unit apart and reassembled it with hot glue. So far it worked with Joes firmware. I will do a test soon with the photomode and report then.

This video helped me:
https://www.youtube.com/watch?v=8mteSTBtO54&list=WL&index=33

[Check D. Gate]

ZS16 firmware — Wolverine MovieMaker Pro
Hi nicost,
I just joined the forum after finding your work on the MovieMaker-PRO firmware modification. Thank you for taking this on — I have one of these scanners and have been trying to figure out how to get the best possible image quality from it.
My MovieMaker Pro reports:
20211215B-ZS16
I noticed that your current firmware work is based on 20210508B-ZS15, and that you mentioned other firmware versions may potentially be supported once the relevant offsets are mapped.
Would my ZS16 build be of interest for that? I would be happy to provide whatever information or firmware dump you need from my machine if it would help determine whether your modifications can be ported to ZS16.
I have not flashed or modified my scanner, so the ZS16 firmware currently on it is untouched.
In particular, I'm interested in the native-resolution JPEG work, but I'd also be interested in whether the earlier higher-bitrate/H.264 work could potentially be adapted to this build.
Thanks again for the work you're doing.
— Danny