I'm making my own film scanner and will attempt to sell it

[brbo]

It is a huge simplification, because you don't have to build Linux, MacOS and Windows versions. It is also cost efficient, because the cost of supporting downloadable desktop software over time is enormous (speaking from experience).

But you proposed doing basically nothing with the data that comes off the sensor and letting users figure it out what to do with it. Not writing code that does nothing on three platforms is the same as writing code that does nothing on one platform.

Again, I think there is no escape to providing a client software for at least Windows and macOS platform if you want to market a sub 3.000dpi 35mm-only scanner with a price tag north of $1.000 to home users. Hoping that OSS community or guys like Silverfast/Vuescan will sort that out for you is quite optimistic and still doesn't change the fact that end user is basically on its own. End users could quite quickly realise that maybe they don't want to pay that much money for a device that only has automated transport going for it over their current digital camera scanning contraptions.

Once you realise that you need to provide OEM client software, you need to decide whether you want to make base code portable to all major platforms or keep paying for additional HW components with every device you sell. And I think it's a pretty straightforward decision.

 

[koraks]

There are no limitations. Modern ARM-based Linux boards are no different from a PC from just a few years ago.

Yes, there are limitations. Because modern ARM-based Linux boards are so PC-like, they also have the drawbacks of a PC in this context. One of this is that these Linux boards, being Linux-boards, are not optimized for real-time applications. Yes, you can force-fit let's say an RPi into a real-time application by running FreeRTOS on it, but it's a bit like hacking your road-going sedan into a garden lawnmower. The more practical solution is to pick something that's more sensible to be the brain of a fairly straightforward, but critically timed mechatronics system - i.e. a regular microcontroller. Even if you would include a PC-like platform for interfacing purposes, you'd still end up adding a fairly modern uC on top of it to run the actual scanner, and then interface the two (possibly through USB2!), adding another layer of complexity.

It seems so obvious at first glance, until you start making the actual engineering decisions. And in this sense, a scanner is really a different thing from the machine vision applications you're probably used to, architecturally speaking. I trust you've taken a look at the datasheets of the CCD arrays OP is planning to use; now add to this the necessary motor controllers for the motion part and think for a minute how you'd typically go about controlling that. You'll notice that a PC-like platform is not an obvious choice for a variety of reasons.

 

[Adrian Bacon]

@Adrian Bacon it works in your case because your usb3 devices are engineered to be made backwards compatible with older usb2 hosts. This backwards compatibility is however not a given in building a new device; it's compatibility that needs to be added specifically along with native usb3 support. Please have a look at the differences in hardware connectivity and protocols. Usb3 adds complexity for the engineer of in this case the scanner while not constituting any added value in return for it.

Usb2 support is relatively easy; use any of the e.g. stm32 platforms with USB support and you're pretty much set. Usb3, not so much; count on having to add peripheral hardware for your uC of choice, be restricted to the few uC's that have native usb3 support (I guess those exist ...?) or be forced to not get away with a uC and use the sledgehammer approach of integrating an actual computer into the device as Steven Lee suggested. Which is massive overkill for again very little benefit (at least in terms of the USB connectivity).

Don't be fooled by your user-perspective experience which is NOT representative of the engineer's perspective!

No it doesn't. I actually have a fair amount of experience doing embedded stuff. Pretty much every USB3 capable chip designed to go into a device (i.e. not be a USB host in a computer) does all the negotiation for you and provides a standardized hardware interface that the rest of your device talks to. Most of the time, the rest of the device has no idea what version of USB is being used unless it's paying attention to how fast the data is coming in. This is how it has worked going from USB 1.0 to 1.1 to 2.0, to the plethora of 3.0/3.1/3.2 to the soon to be common 4.x variants of USB. You might have added complexity just due to the fact that you now have to be able to actually handle data at gigabit+ speeds, but the actual device interface is really not much more than talking to a USB chip using whatever fixed internal bus specification it uses. On the PC side it's literally a PCI express lane on one side of the chip and a USB port on the other. On the device side, it's a USB port on one side and one of several common embedded hardware interfaces on the other. Over the course of my career, I've written a fair amount of embedded code that talks to many kinds of devices over those hardware interfaces, and believe it or not USB anything is just one kind of all kinds of stuff that uses those embedded interfaces.

Here is a great example of what I'm talking about: https://www.ftdichip.com/old2020/Products/ICs/FT600.html. A single chip that provides USB3 and USB2 to either a 16 or 32 bit wide FIFO interface. It doesn't matter if you're connecting to a USB3 or USB2 host, your device talks to it the same way. This is just one of many that can be had.

 

[koraks]

Pretty much every USB3 capable chip designed to go into a device

Sure.
However, compare two use cases:

1: USB2 support. Just a single STM32 connected to the outside world through its own USB2 interface. Only a few passive external components required.

2: USB3 peripheral like the FT600, adding cost (it costs about as much as the 32-bit uC you'd use in this project) and complexity.

The added complexity and cost offers no real benefit due to the backwards compatibility of USB hosts, which is likely to continue into the foreseeable future.

In a project that doesn't require the speed of USB3 and that's complex enough in terms of the mechanics and optics involved, why bother!?
Demands & requirements are being flung around as if it's child's play, but this is one guy trying to get the job done on his own. I'd rather see this thing appear on the market with USB2 than remain in the planning stage perpetually with a USB3 interface and a variety of other 'nice-to-have' functionality that end up stalling the project.

 

[gswdh]

Hand-offs

Based on talks with mechanical engineers involved with scanning film, and my own experience, I know that hand-offs can be a problem with this type of design. A hand-off occurs when the film enters or leaves a roller.
Assume that you have a design like the one I posted a picture of above: A large rubber-lined roller with three small rollers on top. Let's call the small rollers L (left), M (middle), and R (right). Film moves left to right, so it will be fed using roller L, and scanned using roller M. There are two hand-off problems with this design:

1. Part way through the frame, the film will touch roller R. This disturbance can create an anomaly (artifact) in the scan.
2. Further in the frame, the film will come out from roller L, a second hand-off, creating a second anomaly.

I envision two possible solutions to these anomalies caused by hand-offs between rollers:

1. Use only one roller, eliminating hand-offs. This solution works well for an entire roll, but might make scanning the edges of a strip difficult. Strips are often cut poorly, cutting a bit into the image area, making the user want to scan to the edge.
2. Put a rubber belt around all three rollers, similar to the tread-belt on a tractor. This solution also eliminates hand-offs, but the mechanics are a little more complex.

Mark

This is a very good point and one of the key things I considered for the mechanical design.

For my first prototype, I have two rollers, one either side of the scanning area. They are mechanically linked with a belt to the stepper motor. I'm not sure if this setup will work but it was the simplest one. I have an idea for a single large wheel that draws the film around an arc with the scanning area in the middle.

 

[gswdh]

I think only labs wants to scan a whole roll, people usually scan frame by frame looking for maximum quality all least is my case. What i search in a scanner really exists , for example the now difunt hasselblad scanners or the heidelberg topaz drum scanners.

Personally, I always scan the whole roll at least at the preview stage.

I think a scanner like this could really improve people's experience when scanning their film. It has the potential to be majorly faster than existing scanner making that obvious pain point of scanning a whole roll disappear. If the scanner only takes a few minutes to scan a whole roll at full resolution and modern PCs have plenty of resources to store the images in RAM, why not? A whole strip of 35mm at 3000dpi 16 bit is only 1GB.

Photoshop can utilise 10s of GBs for example.

 

[gswdh]

No it doesn't. I actually have a fair amount of experience doing embedded stuff. Pretty much every USB3 capable chip designed to go into a device (i.e. not be a USB host in a computer) does all the negotiation for you and provides a standardized hardware interface that the rest of your device talks to. Most of the time, the rest of the device has no idea what version of USB is being used unless it's paying attention to how fast the data is coming in. This is how it has worked going from USB 1.0 to 1.1 to 2.0, to the plethora of 3.0/3.1/3.2 to the soon to be common 4.x variants of USB. You might have added complexity just due to the fact that you now have to be able to actually handle data at gigabit+ speeds, but the actual device interface is really not much more than talking to a USB chip using whatever fixed internal bus specification it uses. On the PC side it's literally a PCI express lane on one side of the chip and a USB port on the other. On the device side, it's a USB port on one side and one of several common embedded hardware interfaces on the other. Over the course of my career, I've written a fair amount of embedded code that talks to many kinds of devices over those hardware interfaces, and believe it or not USB anything is just one kind of all kinds of stuff that uses those embedded interfaces.

Here is a great example of what I'm talking about: https://www.ftdichip.com/old2020/Products/ICs/FT600.html. A single chip that provides USB3 and USB2 to either a 16 or 32 bit wide FIFO interface. It doesn't matter if you're connecting to a USB3 or USB2 host, your device talks to it the same way. This is just one of many that can be had.

So there are only two USB 3 interface options, the FT60x and the FX3 from Infineon. I have a lot of experience with the FT601 and it's a big pain to implement a controller core on in an FPGA, the timing constraints are hell and not one of the open source cores work - trust me I took the time. The FX3 is a much better designed chip but they are over $20 making it expensive for no reason, again. USB 3 can be implemented in FPGAs like the Ultrascales but that would be ludicrous overkill and such a waste of money. I will be using an FPGA costing a few $.

I will not use USB 3 unless it's needed to achieve the scan times I'd like.

Even then it's a risk as the scanner will have to constantly pause when being used with USB 2. I'm not sure what effect this will have on the scan quality.

 

[Adrian Bacon]

Sure.
However, compare two use cases:

1: USB2 support. Just a single STM32 connected to the outside world through its own USB2 interface. Only a few passive external components required.

2: USB3 peripheral like the FT600, adding cost (it costs about as much as the 32-bit uC you'd use in this project) and complexity.

The added complexity and cost offers no real benefit due to the backwards compatibility of USB hosts, which is likely to continue into the foreseeable future.

In a project that doesn't require the speed of USB3 and that's complex enough in terms of the mechanics and optics involved, why bother!?
Demands & requirements are being flung around as if it's child's play, but this is one guy trying to get the job done on his own. I'd rather see this thing appear on the market with USB2 than remain in the planning stage perpetually with a USB3 interface and a variety of other 'nice-to-have' functionality that end up stalling the project.

The guy that’s actually going to do it can do it however he likes. If it were me, I’d actually use a USB chip designed to be the USB interface for something like an imaging device (which is what a film scanner is) like what the linked chip actually is. Using something like an STM32 doesn’t really do anything but move the complexity into trying to make the solution work with that. It very well may work just fine, but imagine how much it would suck to get pretty far down the line of trying to get it work with that only to run into something that you can’t change (because you’re trying to get it to work on a platform you don’t control) and have to start over. Not saying that’d happen, but I have actually had similar things happen on stuff I’ve worked on.

 

[gswdh]

Some parts have arrived so starting on the assembly. The rest will take a week or two for the 3D prints and LED PCBs.

Remember this is just a proof of concept prototype at the moment and does not reflect how I intend the final product to look like.

 

[mshchem]

View attachment 358161

Some parts have arrived so starting on the assembly. The rest will take a week or two for the 3D prints and LED PCBs.

Remember this is just a proof of concept prototype at the moment and does not reflect how I intend the final product to look like.

Looks very interesting!!

 

[mshchem]

FireWire 400 1394a

SIIG DP 2-Port FireWire PCIe

SIIG DP 2-Port FireWire PCIe for purchase at CDW

Thanks for your help. I ordered a different card but I may buy one of these as well. This is specific for the cable I have. Back in the ancient times I built a couple of my own machines, plug and play, nothing sophisticated, just enough experience to not be afraid to try to get this going.

The OP's project is fascinating, I'm realizing that there's a lot of engineering talent on this forum. People who know this stuff.

 

[Adrian Bacon]

So there are only two USB 3 interface options, the FT60x and the FX3 from Infineon. I have a lot of experience with the FT601 and it's a big pain to implement a controller core on in an FPGA, the timing constraints are hell and not one of the open source cores work - trust me I took the time. The FX3 is a much better designed chip but they are over $20 making it expensive for no reason, again. USB 3 can be implemented in FPGAs like the Ultrascales but that would be ludicrous overkill and such a waste of money. I will be using an FPGA costing a few $.

I will not use USB 3 unless it's needed to achieve the scan times I'd like.

Even then it's a risk as the scanner will have to constantly pause when being used with USB 2. I'm not sure what effect this will have on the scan quality.

How you implement it is up to you. I don’t recall having much issue with timing with the FTDI chips, but the hardware we where pairing it to was pretty beefy.

at any rate, a monochrome 16 bit stream of data at 4000 dpi over the length of a ~5 foot roll of film is nearly 2GB. To move that across the bus in 5 minutes, you’re looking at sustaining ~50Mbps. If you want to do full color, that’d be ~150Mbps. To cut that time in half to 2.5 minutes, you’re now looking at ~300Mbps, getting pretty close to the upper limit of USB2, and that just for the raw bytes off a sensor and doesn’t take into account bus protocol overhead or anything else that will cut into that. This is why I’d personally be cautious about doing this over USB 2.

 

[brbo]

@gswdh, I might have missed it, but are you using area or line sensor?

 

[gswdh]

How you implement it is up to you. I don’t recall having much issue with timing with the FTDI chips, but the hardware we where pairing it to was pretty beefy.

at any rate, a monochrome 16 bit stream of data at 4000 dpi over the length of a ~5 foot roll of film is nearly 2GB. To move that across the bus in 5 minutes, you’re looking at sustaining ~50Mbps. If you want to do full color, that’d be ~150Mbps. To cut that time in half to 2.5 minutes, you’re now looking at ~300Mbps, getting pretty close to the upper limit of USB2, and that just for the raw bytes off a sensor and doesn’t take into account bus protocol overhead or anything else that will cut into that. This is why I’d personally be cautious about doing this over USB 2.

In all honesty by your numbers (match with mine) it seems USB 2 is plenty. I’m not trying to be annoying but it just seems the way.

The FT232H is capable of 40MBs continuous throughput where the error correction and packet loss is already taken care of. The transmission packet will be very simple consisting of a header of fixed length, pixel format identifier, number of payload bytes to follow then the payload. This will result in very little overhead.

 

[gswdh]

@gswdh, I might have missed it, but are you using area or line sensor?

It’s a line sensor. My initial prototype is using the TCD1209DG and I’m looking to use either the TCD2565BFG or the TCD2719DG. The latter being nearly triple the size of the former meaning the constraints on the optics is lower due to the lower magnification that offers. Thing is it doesn’t have a dedicated BW sensor and it’s expensive. I’m not sure the loss of the BW sensor is an issue as we can just use the red or blue channel for BW films, debayering would still not be necessary.

 

[Adrian Bacon]

In all honesty by your numbers (match with mine) it seems USB 2 is plenty. I’m not trying to be annoying but it just seems the way.

The FT232H is capable of 40MBs continuous throughput where the error correction and packet loss is already taken care of. The transmission packet will be very simple consisting of a header of fixed length, pixel format identifier, number of payload bytes to follow then the payload. This will result in very little overhead.

No annoyance taken. You don't have to justify anything to anybody. It's your design. If it doesn't work for some people, then they shouldn't buy it.

This just might be me, but given that the device is effectively a brick without a connection to a host computer, if it were me doing it, I'd start with the connection to the host computer, then design the rest of the device around that, not the other way around. It's not uncommon to see companies design a device to do something, then tack on a computer connection almost as an afterthought, then people wonder why the performance sucks, or the user experience or software sucks. It's because they did it backwards. They designed a device that's a brick without the connection to the computer and the software to use it, and added the connection to the computer and the software in the cheapest possible way.

Since speed of scanning is the primary driver, USB2 could be made to work, but will ultimately limit either how quickly you can scan high resolution, or limit the amount of resolution you can scan quickly. It's fine for a prototype, and I know you're targeting 3000DPI, but in all reality, that's not really much more than many scanning solutions offer today, and you're potentially limiting how many people would be willing to buy it. An Epson V850Pro can easily do 2400 dpi (I have one and have tested it) and a whole platen scan (which is a pretty good chunk of a roll of film) doesn't take that long. I'd have to go back and remeasure the time it takes, but if memory serves, at 2400-3200 dpi, it's not particularly slow. From a purely performance perspective, you'd not really be delivering much of a jump for something that costs the same or more. Granted, there'd be other pluses like having a more streamlined workflow from being able to just scan the whole uncut roll in one go, and potentially a better software experience, but at the end of the day, I don't see people willing to spend that kind of cash unless it can really outclass what's already available, and fast scanning at high resolution is the name of that game, which goes back to having enough bandwidth to the host computer with plenty of breathing room.

 

[albireo]

Since speed of scanning is the primary driver, USB2 could be made to work, but will ultimately limit either how quickly you can scan high resolution, or limit the amount of resolution you can scan quickly. It's fine for a prototype, and I know you're targeting 3000DPI, but in all reality, that's not really much more than many scanning solutions offer today, and you're potentially limiting how many people would be willing to buy it. An Epson V850Pro can easily do 2400 dpi (I have one and have tested it) and a whole platen scan (which is a pretty good chunk of a roll of film) doesn't take that long. I'd have to go back and remeasure the time it takes, but if memory serves, at 2400-3200 dpi, it's not particularly slow. From a purely performance perspective, you'd not really be delivering much of a jump for something that costs the same or more. Granted, there'd be other pluses like having a more streamlined workflow from being able to just scan the whole uncut roll in one go, and potentially a better software experience, but at the end of the day, I don't see people willing to spend that kind of cash unless it can really outclass what's already available, and fast scanning at high resolution is the name of that game, which goes back to having enough bandwidth to the host computer with plenty of breathing room.

Yep. I wonder if OP has the small family-run analog lab in mind, rather than the the scan-at-home enthusiastic amateur photographer, as the target customer for the product.

Going by what one reads on Reddit, seems like a lot of people drop their roll at the lab to then get back the entire set of 36 images as mid res scans (and often no negatives unless they explicitly ask!)

I can see how, for a minilab with fast turnaround, fast scanning times, whole strip scanning and 3000 dpi output all make sense.

I wonder though if all such establishments have long moved to custom-built, fast, scanning solutions (eg DSLR setup) and whether they'd be easily convinced that this scanner will offer important advantages.

 

[Adrian Bacon]

I wonder though if all such establishments have long moved to custom-built, fast, scanning solutions (eg DSLR setup) and whether they'd be easily convinced that this scanner will offer important advantages.

I moved to that years ago at this point for the higher resolution scans and 120 format. For lower resolution stuff, it's a Pakon F135 simply because it's mostly unattended and outputs finished files. I'd only consider replacing it with something else if it was faster and/or higher resolution AND outputted finished files. I've been studying the F135s output in various scenarios and have taking my observations and feeding them into my own code to get to finished output in a faster and more automated way when scanning on the DSLR scanning rig. I currently use a Canon R5 and their 100mm RF Macro lens and Negative Supplies motorized 35mm carrier. High resolution and fast is an understatement with that setup.

 

[albada]

For my first prototype, I have two rollers, one either side of the scanning area. They are mechanically linked with a belt to the stepper motor. I'm not sure if this setup will work but it was the simplest one. I have an idea for a single large wheel that draws the film around an arc with the scanning area in the middle.

It's clear that the OP has deep knowledge of scanners, electronics, mechanics, and software. He's the right one for this job!

I looked at those sensors in Mouser.com, and was surprised at how expensive they are. US$61 for the RGBM model and $200 for the higher-res RGB model. Wow! So I looked at a few CMOS sensors from AMS, and they cost even more!

Anyway, an interesting challenge will be to select wavelengths of LEDs that don't produce cross-over or other color problems in scans.

Also, auto-exposure is needed because some of us estimate exposures or deliberately underexpose indoor scenes to keep shutterspeeds from being too low. Auto-exposure requires a low-res pre-scan, which eats some time. I don't care how long it takes to scan a roll, but I'd like a single frame to take under one minute. With ICE, my Coolscan IV ED seems to take around 5 minutes. One minute will be easy, even with a pre-scan for auto-exposure.

Mark

 

[Ardpatrick]

I love the initiative so I'll note a few thoughts.

When I think of use cases, small labs are really all that comes to mind clearly, and I don't know much about small labs. They could tailor a processing / scanning package around your device, which combined with their relatively higher through-put of film could be profitable.

The attraction of 35mm over larger formats is mostly cost per shot and convenience of portability for photographers, in combination with quality that's 'good enough.' For those photographers shooting film and processing at home etc, most already own a Dslr. Adding a macro lens and a light panel would probably give good enough results for about half of the outlay you are talking about. Granted Dslr scanning is a more cumbersome process than what you are proposing. Older film scanners (Coolscan etc) whilst high quality and purpose built, are now all really quite old. They simply don't age as well as film cameras and I think relying on an old film scanner for a workflow is precarious.

So it's a fairly marginal call between the alternatives, as opposed to a clear cut advantage for one of the options. At the moment I'm using a dslr for scanning, with promising albeit not yet 100% convincing results. For 35mm it's great because I have excellent macro optics and my dslr out resolves film. Short of digital ICE I'm not convinced I'm missing much from dedicated film scanners until I move up to scanning larger formats.

Good luck with the project.

 

[Steven Lee]

The star of this show is @gswdh and his scanner. I don't think it's appropriate to be discussing alternative designs when we should be encouraging him instead. We all have an ideal scanner idea but ideas are cheap. It's quite rare when someone actually builds something with their hands. Linus Torvalds famously used to interrupt perfect-idea mailing list discussions with his trademark "show me the code!" argument. Kudos to @gswdh for "showing the code".

Anyway, an interesting challenge will be to select wavelengths of LEDs that don't produce cross-over or other color problems in scans.

I am curious about this too, but that's because I do not have a deep understanding of the color science involved. For example, print film datasheets publish spectral sensitivity curves that make sense to me. But RA-4 paper datasheets contain spectral sensitivity curves as well as spectral dye density curves, and they are not the same: the the cyan and yellow peaks are off by about 300-500nm. My incomplete understanding of this suggests that a scanner should not be picking up light frequencies that RA-4 paper has poor sensitivity to.

 

[Adrian Bacon]

The star of this show is @gswdh and his scanner. I don't think it's appropriate to be discussing alternative designs when we should be encouraging him instead. We all have an ideal scanner idea but ideas are cheap. It's quite rare when someone actually builds something with their hands. Linus Torvalds famously used to interrupt perfect-idea mailing list discussions with his trademark "show me the code!" argument. Kudos to @gswdh for "showing the code".



I am curious about this too, but that's because I do not have a deep understanding of the color science involved. For example, print film datasheets publish spectral sensitivity curves that make sense to me. But RA-4 paper datasheets contain spectral sensitivity curves as well as spectral dye density curves, and they are not the same: the the cyan and yellow peaks are off by about 300-500nm. My incomplete understanding of this suggests that a scanner should not be picking up light frequencies that RA-4 paper has poor sensitivity to.

The dye density curves are what you see when you look at the developed print. The spectral sensitivity curves are what the paper is sensitive to before development.

The dyes that develop don't have to match the paper sensitivity, but rather should match the light that exposed the film so that it looks correct when viewing it on the paper. The chain is: Light entering the camera -> exposes the film -> film is processed and produces dyes that represent the relative light levels that struck it -> film is projected onto RA-4 paper and exposes it with those relative light levels that it recorded, RA-4 paper is manufactured to work with that film and light source -> RA-4 paper is processed and produces dyes that match the light that entered the camera.

For scanning, the film is projected onto a sensor that has it's own spectral response, and the output color space is the equivalent of RA-4 paper, so you take that sensor response and contort it to match the color space in code. How you get there can be done many ways.

In terms of color crossover, that maybe might be a problem if using narrow band light sources, but a color enlarger uses a halogen lamp which outputs the full spectrum of light, so the RA-4 paper is exposed to the full spectrum of light albeit through the color filter system for making RA-4 prints.

 

[koraks]

The whole talk of RA4 paper is unnecessary for designing a scanning system for color negative. It's irrelevant and if you get down to the detail level, it can even get counterproductive. I wouldn't recommend OP going down that path too far, apart from perhaps a cursory exploration.

Don't forget also that his scanner needs to scan color positive and B&W, too, and of various types and vintages. Color positive is arguably the biggest challenge of the lot. Get that right and the rest will pretty much fall into place.

There's a good and recent research article online about illuminant wavelength selection for digitization of color film materials. It's written with preservation of heritage in mind, but it's relevant here as well. I'll update this post in a minute to include the link. Edit: here it is: https://barbaraflueckiger.files.wor...ilmmaterialscannerinteraction_2018_v_1-1b.pdf I also link to it from my blog on this topic (selecting wavelengths for digital scanning) https://tinker.koraks.nl/photograph...ht-sources-for-dslr-scanning-color-negatives/ Although that focuses to a large extent also on dSLR scanning. However, much of the approach is applicable here as well. The main caveat is that you (OP) should really be looking at the dye density curves of as many color film materials as possible, especially those that are likely to be scanned the most of course. The ultimate selection will have to be a compromise between a couple of considerations. The alternative, a wide-spectrum white light source, would of course also be a compromise, but it will be a more poorly controlled one since it's easier to pick specific LED colors than to tailor the broad spectrum of a white light source to your specifications.

Mind you, I find RA4 color paper a unique medium that I'm very fond (even passionate) about. I also understand the logic of "wasn't color negative intended to be printed onto RA4 paper and shouldn't a scanner thus mimic the paper", since it's so deceptively obvious. It's not at all obvious if you think about it, however, especially the limitations of RA4 paper and the realization that the paper is also a massive complex of compromises. Really the last thing one should do is try and make the scanner output mimic RA4 paper. Even using the spectral sensitivity peaks of RA4 paper are a poor choice for a scanner setup for a variety of reasons.

 

[Adrian Bacon]

link. Edit: here it is: https://barbaraflueckiger.files.wor...ilmmaterialscannerinteraction_2018_v_1-1b.pdf I also link to it from my blog on this topic (selecting wavelengths for digital scanning) https://tinker.koraks.nl/photograph...ht-sources-for-dslr-scanning-color-negatives/ Although that focuses to a large extent also on dSLR scanning

Interesting. I’ll have to do some reading. I wasn’t aware of the linked pdf.

 

[Deeezo]

Hi all,

I mentioned in another thread I'm working on the development of a new film scanner. I started this project almost 8 years ago but put it on hold as I wasn't shooting much film at that time. Back then I developed the electronics and more recently the PC software. I've now ordered all the parts for the prototype mechanical design - let's see if it all works in the New Year!

My motivations for this scanner come from the frankly poor set of options on the market. All the scanners seem to have one or more of the following traits:

- Terrible software
- Are legacy hardware only working with legacy PCs
- Poor scan quality
- Poor user experience
- Extremely long and tedious scan times

I think this can all be fixed quite easily. I plan to make a sort of copy of the Pakon F 135 scanner, at least the style of it any way where it's capable of scanning a whole roll of film.

The electronics I have got working can scan a whole roll of film in just over a minute at 2000dpi, 14bit in black and white only. If I look to sell this, It would be upgraded to colour and at least 2700dpi.

So, some key criteria for my scanner are:

- Can scan a whole roll of film in one go without human intervention (loading strips of film)
- Scanning time less than 10 minutes
- 3000dpi ideally
- Really good software that doesn't crash or require some exotic HW configuration
- Simple USB 2.0, drivers come with the SW
- Good optical quality up to 3000dpi
- 10 bit digitisation or better
- Scans the 135 film format

My philosophy for this project is in offering a product that is reliable and customers can have faith in using for the next 20 years - which is entirely possible. The software will be fully open source and the communication protocol fully documented and public to allow for 3rd party software. The software is already publicly available on github (see below) and is current written in Python, it will be rewritten in C++ for the official release - binary size will be in the region of 10s of MB. Community contributions to the software will be actively encouraged.

Github repo for the PC software.

Github repo for the electronics.

I think it'd be possible to achieve a retail price of around €1-1.5k but I'm a long way off that yet.

I would love to hear everyone's opinion / feedback / suggestions!

But please, do not just tell me why it won't work unless you have some real justification.



View attachment 357721

Being able to scan up to large format would always make it more desirable!