Reviving the Pakon film scanner | Hacker News Reader

Reviving the Pakon film scanner

ktkaufman03.github.io

249 pointsktkaufman67 comments

Making old hardware work with new software and vice-versa has always felt like the true "hacker spirit"; more so when source code isn't even needed, contrary to what many FOSS advocates think. Much like how you don't need the original design drawings and such to fix physical machines, but just need to understand what's wrong and how to correct it. This is also near right-to-repair.

It's also worth noting that "ezloader" USB interface was later acquired by Cypress and became the infamous FX2/FX2LP MCUs that popularised a lot of USB devices, including logic analysers.

(I usually do more of the latter, but the same skills are used.)

Good point about the Cypress acquisition. While I was investigating part of the driver code recently, I realized it was based on FX2 sample code. The development kit that I got, on the other hand, was pre-FX2. The article notes that Cypress acquired Anchor Chips, the original creator of EZ-USB, in 1999, which would seem to line up perfectly with the time frame in which the Pakon scanners were developed.

Interestingly, the acquisition happened only a few months before the kit you received was packed: https://www.eetimes.com/cypress-buys-anchor-chips-to-bolster...

Oddly, there are files on the CDs that are dated after the date on the packing slip - several months after, in fact. So I'm not quite sure exactly how old my kit is...

> more so when source code isn't even needed, contrary to what many FOSS advocates think

Source code isn’t always needed, it just makes the process simpler and quicker. There’s way more old devices that people would like to continue to use than there are hackers with the time and skills to reverse engineer them! For example, I’ve been lurking on the Magic Lantern forums (alternative firmware for canon dslrs) and the time it takes to port the software to a new camera model is counted in years…

To reduce e-waste I think companies should be obliged to release the source code to their devices when they stop supporting them (and if they’re afraid of releasing trade secrets—they’ll just have to keep supporting them longer!).

Cool machine.

Our company used to build 35mm film scanners, called Northlights, for film post-production.

Originally they were driven by SGI Octanes. Then x86 Linux machines. Biggest problem these days would be the interface cards. I believe we were stuck with PCI-X cards for a long time, requiring host machines capable of accepting them.

We still support them, as there are many still in active use on both new films and restoration/archival jobs.

https://www.filmlight.ltd.uk/products/northlight/overview_nl...

TIL about PCI-X. Northlight looks like a pretty cool piece of hardware! It's cool to see what other obscure stuff is out there - that's why I like Hacker News :-)

I'm in awe at the level of expertise required to dive this deep into the kernel.

At one point there are very few people who have even looked at piece of code you are looking at.

Are you going to release patches so at least other people can replicate things?

Patched versions of the original drivers will be released, along with the new drivers. I'm not sure if I'll release the source code yet because of the legal gray area around this sort of work, but it's still something I'm considering.

I think it's less about "level of expertise" than it is about having a willingness to explore, learn, and analyse. IMHO working in ring0 isn't a huge change in difficulty than ring3, despite the different environment. Device drivers are mainly libraries that translate between interfaces.

> First and foremost, for reasons that are unclear to me, ObfDereferenceObject is exposed to driver developers through a macro3 called ObDereferenceObject. I don’t understand what the point of this even is, but in any case, we can find the documentation for the macro here.

Emphasis mine. The reason why this is done in big projects is adding just one more level of abstraction to be able to preserve how userland interacts with your library, but still allowing you to make underlying structural changes to the code.

Kai, could the author please share your port of the 64 bits driver? I happen to own a F135. Thanks in advance. Great article, it brings back some memories.

The custom drivers will be released soon :-) If you're not in the Pakon Facebook group, I recommend requesting to join it, since there's a lot of useful information there.

This is pretty cool. Would you consider releasing the reverse engineered source code? I imagine that could be pretty helpful for anyone dealing with future OS changes (perhaps trying to make this work on Windows ARM for example, or even linux), and while it's probably technically against the license agreement, I can't imagine anyone would care much about such old software that's no longer maintained.

It seems like a grey area. Especially given that the driver is a mash-up of sample code from a third-party hardware SDK and a Microsoft book, would Kodak/Pakon really care?

I would think the only part of the software that still might retain trade secrets would be the color management code, and that's not in the driver.

Maybe there's a way to distribute dissembler hints and patches where you need the original driver files to get the source code. I assume the MS code has a reasonable license since it was published as sample code

> trade secrets would be the color management code

Are trade secrets even protected? If there's a patent, yes, but that's expired. The implementation is protected by copyright, but the know-how isn't.

Kodak sold a lot of their patents to other companies as a result, IIRC, of their bankruptcy. I'd have to look at the patents for this particular system again, because I can't remember if they were ever reassigned or if they were simply allowed to expire.

I don't think reassignment changes the duration of the patent. Looks like the early versions of the devices came out in 2004, so it's getting really close to when they'd expire.

IANAL, but my concern would be distributing either the original drivers or 64-bit drivers, but in practice, no one is going to care. It's not worth an hour of a lawyer's time to send a cease and desist letter for distributing driver source for an 18-year-old device.

Trade secrets may not be protected by patents (if expired), but protection of them is a potential motivation for copyright litigation.

> Maybe there's a way to distribute dissembler hints

Tavis recently posted about using STABS for that <https://lock.cmpxchg8b.com/symbols.html> and has existing code that seems relevant: https://github.com/taviso/wpunix/blob/main/debug/idb2stabs.p...

I've never used Ghidra in anger to know if it would work for their platform, nor whether the Ghidra database can be shipped separate from the binary

Like steve_austin said, releasing the code is in a grey area. Realistically, it's highly unlikely that anyone would actually be upset about it, so it may happen in the future.

Linux support is a completely different beast. There is a lot of code that I didn't talk about, including the absolutely massive image post-processing/color-correction library that we only have a Windows version of (and no source code for, obviously.) The Pakon's added complexity (especially automatically finding frame boundaries) makes a cross-platform, source-code-less port extremely unlikely to succeed in a remotely reasonable amount of time.

Perhaps share the code privately with someone in another jurisdiction that is more suitable (reverse engineering laws, copyright, whatever), and that person can take the legal liability? Perhaps someone who owns a scanner like user yesimahuman in this thread?

Does it need all that support stuff to just get an image out of the device?

I would guess there’d be value in just piping the raw output into photoshop (or something) and doing the color correction/frame boundaries there.

In theory it's unnecessary. The problem is that one of the main selling points of the Pakon is its convenience - then again, if somebody wants to do things the hard way, who am I to stop them?

I don't have any plans to develop a cross-platform client, but I will be publishing more technical information about the scanner so people aren't left wondering what I know.

It would be awesome to have the scanner supported with an open source driver in SANE, which now has an IPP module, so this would enable doing film scans from a smartphone :)

http://sane-project.org/ https://openprinting.github.io/gsoc2019/03-sane-module/

Very cool! I own a Pakon F135+ and using it through a VM has worked well enough for me, but I’ve always wanted someone to modernize the tooling so that wasn’t necessary. Thanks for putting in the work here!

By popular demand, the article now has a picture of the scanner I have access to - an F135 Plus - with a bit more information about how it's used. For those who wish to see an F235 and/or F335, I recommend Google Images, since I'm not going to use someone else's pictures without their permission.

>In the course of this article, the Pakon film scanners went from being a user’s nightmare to being totally usable with modern versions of Windows.

Right, but I think it's still nightmare because Windows require driver signature verification by default. But why there's dedicated kernel driver at all? I wonder how feasible would be transplating decompiled driver code into userspace shim that uses WinUSB.

>I think it's still nightmare because Windows require driver signature verification by default

I've taken care of that already :) My custom drivers are properly signed and basically ready to release once I tidy up some loose ends.

I'm not entirely sure if this really needs to run at the kernel level. In the future I might investigate converting it to a user-mode driver, but for now I think a signed kernel-mode driver will suffice.

You actually paid to have them signed?

I had help, but yes. I think it's worth the cost to give people peace of mind that they won't have to disable some of the most important security features available to them in order to use a scanner.

I own Nikon CoolScan 9000, which I picked up for cheap without film adapters/holders. It takes me more than year to find 120 film adapter on EBay and it cost me as good flat-bed scanner alone. But, boy, quality of scans of good 120 slide film! I never liked colour negatives, but MF Velvia 100F is a magic!

As a photographer who has always lusted over Pakons and will eventually own one, I truly appreciate the effort here.

Looking at the F135 film feeding path, I wonder how did they deal with dust, the bane of film scanning?

Is there some active dust-off stage? The feeding channel seems all open and next to plastic, I'd guess static charge would attract dust specs.

Hard to miss those days with hours spent rubberstamping dust specs in photo editor.

The way the scanner deals with dust is by complaining that there's dust :-) (It doesn't have a special dust error, AFAIK, but it does do some checks that will end up failing if too much dust has accumulated.)

The way to avoid dust accumulation is to keep it covered when it's not being used. That works nicely and is a reasonable thing to do anyway.

The service manual recommends hitting the film channel with compressed air every couple of weeks. If you do that and keep it covered when not in use dust is not an issue.

Cool work, but how do you write this entire article and not post a single picture of the scanner?

Good question - honestly, I forgot. Also, there are multiple models that look very different, so then the question becomes: which one do I show?

In any case, those who are really curious won't have a hard time finding pictures. I'll include some next time :-)

And please walkthrough the process so I may see whether to get one. Well last time I read about Paton around 2000 I presume : https://www.dantestella.com/technical/f235plus.html only 6Mpix but for quick and good scan great. He scanned 12,000 of his.

I don't plan on doing a walkthrough - the only reason I even touched a Pakon scanner was for development/testing purposes - but there's an abundance of information online that I'd encourage you to seek out if you're interested.

In SANE, which now has an IPP module, it would be awesome if the scanner was supported with an open-source driver.

http://sane-project.org/ https://openprinting.github.io/gsoc2019/03-sane-module/

A few photos of the subject would be nice. (if I'm not missing them due to ad blocker, in which case - sorry)

I've added a picture of my scanner to the article :-)

This is great, but why didn’t I see a photo of the scanner?

I've addressed this a couple of times in response to others, but the main problem is that there are multiple models that look quite different from each other. I could pick one, but that wouldn't be telling the whole story, or I could show them all and add extra clutter to the page.

That being said, I'll probably just pick a model and add a picture to the article. Google Images is good for finding the others.

Wow mention of Walter oney’s book brings back memories of learning to write NT drivers back in the day. A classic book of the time

I had never even heard the name "Walter Oney" before I started researching this thing. I was pleasantly surprised by how well his 20 year old code held up, though.

Great article. And Paton is the fastest scanner you can have for old 120 film scanning.

Hope more on the user side can come.

Alas, Pakon only scans 35mm film. No 120. I wish.

Coolest scanner? Thought we were talking the IC-R9000 for a minute there.

That does look pretty cool!

> the package had never actually been opened, and contained the original packing slip… with a date several years before I was born.

But the packing slip says 1999!!!!

Indeed it does. I was born a few years later :-) That's what I love about "digital archaeology" like this - it's so much fun to find and explore things from a time you can't possibly imagine on your own.

You call our childhood "archeology"? Get off our lawn! People born after 2000 aren't real anyways.

Huh, I guess I should tell everyone I know that I don't exist ;)

In all seriousness, I like learning about things that were before my time, and that's why I use the term "archaeology." It's not really archaeology, since I know plenty of people who were alive at the time, but it still appeals to my inner curiosity.

Don’t worry, we all appreciate it!

Remarkable! I'd buy you a beer if you're old enough to have one :) Really cool project and write-up! Looking forward to any future posts

Fun fact: People born in 2004 are all turning 18 this year :)

And still, 2004 feels "a few years ago" to me. I don't know if I'll ever get used to it.

Oh wow, to think I was a college sophomore then. Ouch. Right to the ego!

> Right to the ego!

You mean as an ego boost, right? You're certainly wiser than anyone born circa 2000s. We can hack drivers for breakfast.

Yeah the earliest I can stomach driver hacking is lunchtime

And touch type. Or that while the internet is great, it should be viewed with a distance and skepticism.

Probably the biggest thing I wish I could share though is general civics and history knowledge. A lot got cut from education since then in the US. Plus what 90s America felt like-freedom before “terrorism.” (Quotes because there are many great books on all this that I’m not able to even point at right now.)

Apologies for jumping into code - this is "Hacker" News, after all. The feedback is still appreciated. I actually meant to include pictures but forgot :/

The practical results can best be described as 36 super high-quality TIFFs (if you scan a full 35mm roll) obtained in just a couple of minutes. You can find more information by looking at other online sources - one I'd recommend reading, if you're interested, is https://www.dantestella.com/technical/f235plus.html.

I'm not surprised that it's relatively unknown - after all, digital photography has mostly taken over, and even those people who benefited from drug-store film development/scanning probably wouldn't have cared too much about what hardware was in use.

Reviving the coolest scanner you've never heard of

But I have heard of it. Does that mean the scanner isn't the coolest anymore? Or maybe just the author.

A more accurate title would be "Reviving the coolest scanner you've probably never heard of", but it was already a bit long.

I make no claims about my own coolness :-)

Reply on news.ycombinator.com