Soke Engineering / Knokke film scanner

[brbo]

If this project turns out to be more than just pretty renders, Auralab will have to do a major shift in their $trategy

 

[miha]

If this project turns out to be more than just pretty renders, Auralab will have to do a major shift in their $trategy

You pretty much made my day!

 

[koraks]

If this project turns out to be more than just pretty renders, Auralab will have to do a major shift in their $trategy

Camera scanning, but automated. Sounds perfectly feasible. Let's see how it performs; I guess we'll find out soon.

 

[brbo]

Camera scanning, but automated.

Hmmm... To be honest, going through the specs (any format, double speed for lower resolution scans) I was actually hoping for a "traditional" line sensor.

But, of course area sensor seems more likely and then doing more (stitching) in software. Double scanning speed for lower resolution still seems odd for an area sensor. Of course, there will be less data to transmit, but with USB3 this shouldn't be much of a factor.

Anyway, I did a napkin calculation and if this scanner is using a traditional area sensor it's not bigger than 1" (considering 2µm pixel size). I have some experience scanning 35mm film on m4/3 and it's not that great (using a very good scanner lens). True 4000dpi scanners are definitely better at pixel level.

I guess, we'll have to wait and see. They promised sample scans before the Kickstarter campaign, which at 999 EUR I might sit out and pay the full price (1.599 EUR) after (if?) scanner demonstrates that it beats the 135 format Noritsus and Frontiers. Software dust&scratch repair is also a thing thats a big unknown. I tried some software implementation with quite poor results. Did a couple of enthusiastic photographers figured that out?


(I still hope that at 1.599 EUR it will have those nice linear sensor pixels and not small-bayer-sensor mangled/wormy ones. BTW, AURA 35 uses linear sensor)

 

[koraks]

To be honest, going through the specs (any format, double speed for lower resolution scans) I was actually hoping for a "traditional" line sensor.

It's very explicit/clear from the hardware design. It's a regular CMOS sensor, so not a linear array.
I frankly don't see what the advantage of a linear array would be here. It's just slower and dimensional consistency would be affected by film transport. How would that help? There's only loss, no gain.
As to your problem with the Bayer array: theoretically you could improve the situation by modifying the software (which will be open source, so that bit is feasible) to acquire 3 consecutive images using the separate R, G and B channels on the light source. This would require the color channels on the light source to be separately switchable, which is likely the case as they probably needed to implement PWM dimming anyway to balance out the channels. But that bit is for now a guess; later on we'll see when the designs are published.

Double scanning speed for lower resolution still seems odd for an area sensor.

I don't see it. Depends on where the bottleneck is and what kind of interface the sensor exposes to the firmware.

I have some experience scanning 35mm film on m4/3 and it's not that great

Much of the problem is likely in the optics; in this scanner the optics are optimized for the application, which is a different ballgame from a regular camera lens which needs to work at a variety of focus settings. In this case they can get away with a fixed focus and fixed aperture design.

True 4000dpi scanners are definitely better at pixel level.

I don't think we can say something like this at this point. You need to factor in the entire image chain and compare at the application level.

Software dust&scratch repair is also a thing thats a big unknown.

It's not a big unknown; they're using an RGB light source and no IR channel, so there's not going to be some kind of optical ICE implementation.
They do mention an optional brush that can be installed in the scanner to remove dust as the film is transported. Of course that will only do so much and carries a risk in itself (depositing dust or scratching the film is the brush isn't kept in good condition).

I think you're drawing a lot of conclusions without taking into account the available information on the project.

 

[brbo]

It's very explicit/clear from the hardware design. It's a regular CMOS sensor, so not a linear array.

I must have missed the explicit statement that the sensor is an area one. CMOS does not rule out a linear sensor. There are multiline linear CMOS sensors around. And as I said, AURA 35 uses such a sensor (I have no reasonable cause to doubt the validity of their claims).

I think you're drawing a lot of conclusions without taking into account the available information on the project.

If you read my post, I'm actually not drawing any definite conclusions.

 

[koraks]

I must have missed the explicit statement that the sensor is an area one.

It's implied in the fact they use a "modern backside-illuminated CMOS" sensor. AFAIK there's not much development currently on strip sensors that would suit this kind of application since virtually every application benefits from the faster capture offered by an area sensor. Hence, if you're setting up a project like this, you face substantial choice in area sensors, but you'd paint yourself into a very niche corner (for no really good reason IMO) if you are bent on using a strip sensor.

 

[brbo]

Yes, implied is a MUCH better word than explicit.

I would just add that there are many linear CMOS BSI sensors that are considered modern in every sense of the word. As to why would anyone choose a linear sensor in this time and age, well, there are reasons for and reasons against that were already mentioned.

As this is primarily a thread on Aura scanner(s), it's obvious that some people still found using line sensor has benefits worth considering. I wouldn't go as far as claiming they blew it with their decision even though I would really really love a consumer scanner with an area BW sensor scanner with all the obvious benefits of such configuration (true trichrome scans, IR, optimal sharpness...).

5min per roll is actually very slow for an area sensor capture. On the other hand, 1min (quite possible with area sensor) vs 5min doesn't make much difference in real world since judging and adjusting 36 scans takes longer than 5min and with sensible scanning workflow this will be basically done in parallel with operator being the limiting factor.

 

[koraks]

5min per roll is actually very slow for an area sensor capture.

I agree. I don't know where the bottleneck is in their setup.

My observation is that every pro-oriented, recent scanning solution for film (e.g. motion picture domain) uses area scanners. It's beyond me why any engineer would even consider linear sensors at this point.

 

[gswdh]

Hi all, I’m George, the owner, founder, and sole engineer at Soke. The topic of image sensors is a bit of a contentious one that falls into the overall film vs digital debate — i.e. why shoot film and then just scan it with your digital camera?

There are many, many dimensions to the trade-offs with image sensor size, type, and usage, along with lens pairings and backlight design.

One of the main ones is noise / integration time. The reason a “full-frame” sensor is desired in a digital camera is really driven by the fact that the user is limited both by the amount of light entering the camera and by the limitation in integration time due to having to use it handheld (mostly). This means the pixel sensitivity needs to go up, which increases noise / degrades image quality, etc.

But in Knokke, we are in control of the amount of light going into the sensor. We put a lot into the system to end up with enough light at the sensor to use a (relatively) small sensor with very high performance (dynamic range) for its size, so we don’t need to use any gain.

But then why use a smaller sensor than full frame if we don’t have to?

1. For a small company like us, the cost of just a full-frame image sensor, in the quantities we would be buying, would be more than the current retail price of Knokke.
2. A smaller image sensor means lower-cost optics, which is the most expensive aspect of the design, where almost 40% of the BoM cost goes. For example, reducing the image sensor size by two times reduces the size of a lens by four times and ths reduces the cost at an even higher rate. Using a smaller sensor makes the optics small enough that we can spend sufficient money on them to achieve very high performance.

As for linear sensors vs area sensors: it’s a bit of an apples-and-oranges debate. Both can be good, or better than each other, technically. But area sensors make more sense at this point due to the sheer quantity of production and the number of models to choose from. This makes them dramatically cheaper and more accessible. Linear sensors are not used in high-volume commercial applications and so are much more expensive. These days, image sensor manufacturers who make linear sensors typically also make area sensors, and the linear sensors tend to use exactly the same pixel designs anyway.

The old Toshiba CCD sensors are absolutely terrible in terms of optical performance and are basically the reason why the majority of currently existing film scanners are so slow.

 

[koraks]

Thanks so much for giving some insight into your rationales behind the image sensor choice @gswdh . Makes perfect sense to me, but I guess that follows from the fact that you confirmed a few of the things I had guessed.

 

[brbo]

@gswdh, thank you for your information! Any we look forward to any additional details about this scanner.

I know that you are probably bombarded by request for any test scans, so I won't do that here (or did I just do that? )...

So great to see that you keep an eye on Photrio folks... This scanner deserves a proper dedicated thread!

edit: Duh... I DOES have it's own thread!

 

[gswdh]

@gswdh, thank you for your information! Any we look forward to any additional details about this scanner.

I know that you are probably bombarded by request for any test scans, so I won't do that here (or did I just do that? )...

So great to see that you keep an eye on Photrio folks... This scanner deserves a proper dedicated thread!

edit: Duh... I DOES have it's own thread!

Of course! I've been a long time lurker from way back in the APUG days. In fact I arrived here because an extremely generous person (who I can't remember the name of) gifted me an Nikon F3 on the condition of a token donation to APUG when I was a poor student around 12 years ago.

Yes we get a lot of requests for scans but I'm just not 100% happy with them yet although some do exist on the internet out there however you wouldn't know which ones. I'm finding the feedback on Instagram overwhelming positive but also extremely quick to criticise so posting something a little sub par with the promise of getting better in the future wouldn't do a lot of good I don't think. Scans should be availble in the next couple of weeks, tho. Almost everything is working great but we've had some troubles with some Chinese suppliers and a design engineer setting everything back a couple of months.

I think I might start a new thread considering how much has changed. I will open one with some scans .

 

[koraks]

I think I might start a new thread considering how much has changed.

That would be appropriate; in fact I might just split off these posts from the present thread into a new one and you can then keep updating it.
Edit; and it's done!

 

[brbo]

I think I might start a new thread considering how much has changed. I will open one with some scans .

Excellent!!!






I apologize in advance to Photrio web master(s). There will be a least one user abusing the refresh button on this site...

 

[albireo]

Hi all, I’m George, the owner, founder, and sole engineer at Soke. The topic of image sensors is a bit of a contentious one that falls into the overall film vs digital debate — i.e. why shoot film and then just scan it with your digital camera?

There are many, many dimensions to the trade-offs with image sensor size, type, and usage, along with lens pairings and backlight design.

One of the main ones is noise / integration time. The reason a “full-frame” sensor is desired in a digital camera is really driven by the fact that the user is limited both by the amount of light entering the camera and by the limitation in integration time due to having to use it handheld (mostly). This means the pixel sensitivity needs to go up, which increases noise / degrades image quality, etc.

But in Knokke, we are in control of the amount of light going into the sensor. We put a lot into the system to end up with enough light at the sensor to use a (relatively) small sensor with very high performance (dynamic range) for its size, so we don’t need to use any gain.

But then why use a smaller sensor than full frame if we don’t have to?

1. For a small company like us, the cost of just a full-frame image sensor, in the quantities we would be buying, would be more than the current retail price of Knokke.
2. A smaller image sensor means lower-cost optics, which is the most expensive aspect of the design, where almost 40% of the BoM cost goes. For example, reducing the image sensor size by two times reduces the size of a lens by four times and ths reduces the cost at an even higher rate. Using a smaller sensor makes the optics small enough that we can spend sufficient money on them to achieve very high performance.

As for linear sensors vs area sensors: it’s a bit of an apples-and-oranges debate. Both can be good, or better than each other, technically. But area sensors make more sense at this point due to the sheer quantity of production and the number of models to choose from. This makes them dramatically cheaper and more accessible. Linear sensors are not used in high-volume commercial applications and so are much more expensive. These days, image sensor manufacturers who make linear sensors typically also make area sensors, and the linear sensors tend to use exactly the same pixel designs anyway.

The old Toshiba CCD sensors are absolutely terrible in terms of optical performance and are basically the reason why the majority of currently existing film scanners are so slow.

Thanks for this.

If I understand correctly, you're photographing the 24x36mm negative a number of times with your smaller area sensor, followed by stitching.

If that's correct, may I ask if the stitching is happening in hardware (e.g. FPGA or equivalent) or software, and what's moving during capture, the negative frame or the area sensor?

Thank you for your work.

 

[koraks]

If I understand correctly, you're photographing the 24x36mm negative a number of times with your smaller area sensor, followed by stitching.

That's not how I interpret this; I expect they photograph the entire image in one go.

So nothing moves and no extensive processing is necessary in the firmware, let alone hardware.

@gswdh can confirm; if I were to make something like this, I'd just acquire the data from the CMOS and dump it into the USB interface, and then figure out the rest on the host platform. Trying to do too much in the firmware (let alone hardware) is unnecessarily complicated and costly for an application that's intended to run tethered to a host computer anyway.

 

[albireo]

That's not how I interpret this; I expect they photograph the entire image in one go.

So nothing moves and no extensive processing is necessary in the firmware, let alone hardware.

So the lens' job is to project the full frame data onto the area sensor all at once.

If that's the case, what causes the reported differential in speed between full res (4000dpi) and standard res (2000dpi)? Just data transfer via USB 3.0 bus? Seems a bit much.

 

[koraks]

Something interfaces between the sensor and the USB stack.

 

[albireo]

Something interfaces between the sensor and the USB stack.

I suspect you're being flippant, and I will ignore that. I'm just trying to understand.

'Something' -> ? ADC conversion?

That should take 4 times as much for a 4000dpi capture wrt a 2000 dpi capture, yes.

But are you suggesting that ADC conversion is entirely responsible for the very large published differential?

 

[koraks]

Not being flippant at all. A CMOS image sensor doesn't come with a USB interface, so a bit of hardware needs to go between it. Currently that would typically be something like an STM32-series microcontroller.

ADC conversion I expect takes place on the CMOS device itself (on-chip ADC's) and that it offers digital readout. Without having looked too deeply into relevant datasheets or having run numbers on it, I would expect there are three potential bottlenecks that limit datarate:
1: The actual on-chip ADC('s), assuming there are any. These will likely sample one pixel at a time and offer the output to the outside world. This means the X-megapixels need to be clocked out in a semi-serial fashion. This slows things down considerably even if you use a high clock rate on the ADC's.
2: The path from the CMOS (more to the point, its ADC's) to the microcontroller or whatever device reads the image data and sends it to the host machine. This needs to be timed in accordance with (1) above, but there can be additional limiting factors here depending on hardware choice.
3: The actual USB connection; we know the device uses USB-C but that doesn't guarantee it uses USB3; it can still work at USB2 speeds.

But are you suggesting that ADC conversion is entirely responsible for the very large published differential?

Not necessarily, see above, but I do expect that it's the major bottleneck since that's where the matrix of let's say 25 million image sites is smashed down into a relatively narrow data path.

PS: I think it's also safe to assume that the choice has been for a CMOS image sensor with onboard ADC's since the electronics design and signal handling of doing that off-chip on a custom board would be akin to rocket science. No disrespect to the developers here, but that's a different league of EE.

 

[kozesluk]

lower-cost optics, which is the most expensive aspect of the design

I just looked at the specs and it mentions 4 element lens used for the capture - are 4 elements really enough to achieve elimination of all aberrations whilst maintaining flat field reproduction?

Also, is there a Bayer colour mask on the sensor?

 

[_T_]

At or near 1:1 magnification symmetrical lenses automatically correct for lateral aberrations which would make it much simpler to design a lens which corrects for the other longitudinal aberrations with fewer lenses. So I would guess that they chose a symmetrical lens

 

[mshchem]

Not being flippant at all. A CMOS image sensor doesn't come with a USB interface, so a bit of hardware needs to go between it. Currently that would typically be something like an STM32-series microcontroller.

ADC conversion I expect takes place on the CMOS device itself (on-chip ADC's) and that it offers digital readout. Without having looked too deeply into relevant datasheets or having run numbers on it, I would expect there are three potential bottlenecks that limit datarate:
1: The actual on-chip ADC('s), assuming there are any. These will likely sample one pixel at a time and offer the output to the outside world. This means the X-megapixels need to be clocked out in a semi-serial fashion. This slows things down considerably even if you use a high clock rate on the ADC's.
2: The path from the CMOS (more to the point, its ADC's) to the microcontroller or whatever device reads the image data and sends it to the host machine. This needs to be timed in accordance with (1) above, but there can be additional limiting factors here depending on hardware choice.
3: The actual USB connection; we know the device uses USB-C but that doesn't guarantee it uses USB3; it can still work at USB2 speeds.


Not necessarily, see above, but I do expect that it's the major bottleneck since that's where the matrix of let's say 25 million image sites is smashed down into a relatively narrow data path.

PS: I think it's also safe to assume that the choice has been for a CMOS image sensor with onboard ADC's since the electronics design and signal handling of doing that off-chip on a custom board would be akin to rocket science. No disrespect to the developers here, but that's a different league of EE.

I've wandered into computer nerd territory! I'm glad I don't have to understand this stuff! Keep up the good work!

 

[koraks]

At or near 1:1 magnification symmetrical lenses automatically correct for lateral aberrations which would make it much simpler to design a lens which corrects for the other longitudinal aberrations with fewer lenses. So I would guess that they chose a symmetrical lens

More so, let's keep in mind that this is a fixed-focus design. I imagine that makes the optics a little easier to optimize as well. Besides, all it has to do is approximate the resolving power of the sensor; not more than that. OK, that's still around 160lpm, I suppose.