DIY Drum Scanner?

[mongole]

Hi all!

First things first: Neil, I really hope I did not offend you. This had been the last of my intentions. As English is not my mother tongue, I might sound a bit harsh from time to time. It's a really impressive list of different areas you have covered during the years!

My experience up to now, is mainly Java web and desktop application development and some years with JavaScript now. Currently I am interested to learn some Go, as it would be great for multi-core CPU programming. For sure I did a bit of C++ years ago, but whenever I get in touch with it I realize how handicapped I feel with this language...

Regarding mechanical stuff, I also did service my motorbikes on my own. The precision part of the mechanics for sure is done by other engineers, just assembling. But enough to know, how to deal with this parts.

And long time ago, I went into a school for electrical engineering. But I never worked in this area. Hence, there are some hazy memories about electrical stuff, but it's all covered below a big layer of dust.

In the moment I would say, I could imagine to take an existing drum scanner and replace the electronically part. But only with a long and steep (re)learning curve.

I can imagine to pursue such kind of project as a real long term thing. Just to invest some hours here and there. Hence, for sure it would take more than some months to see something polished working in the end.

After starting this thread, I stumbled upon two ScanMate 5000 scanners. Not to far away of my home town. I took a look on them on Sunday and consider to buy both of them. One is broken, but the current owner thinks it should work, after fixing some damage done during transport. The second one is in working condition. I could use one to scan for now, have the second for spare parts and also as base for the DIY scanner project. We the working one (preview, focus and white point calibration), but could not do any scans, as the software lacks a dongle and we could not figure out how to get into demo mode. Next Sunday I will know more, as I bring my own old computer with SCSI connector to test...

Then I wanted to cover the points discussed up to now:

Bruce, for sure you are right! "First thing you do is, make a formal functional specification for it. If you can't do that, you can't make a drum scanner. You can't solve a problem that you can't define."
But first, one has to get a to a state of knowledge, one can define the formal functional specifications.
And of course, you are right. The whole thing is much more complex and complicated as I expected it in the first moment. Maybe it stays a thought experiment, but I like to play around with things like that.


Scan and rotational speed. Optical header positioning.
Of course it has to rotate as fast as e.g. 1600 rpms. If one scans a 8x10 inch sheet, you have 10 * 5000 (dpi) horizontal resolution. Divide by 1600 rpms/lines it's 31.25 minutes to do the scan. Actually straight forward, as soon as you do the simple maths. And for sure it also has to be positioned on every rotation in the gap to archive this scan speed.

Mounting / moving options.
I think rotational is the way to go, as moving linear in two directions would be slow and take long time. You would have to accelerate the table (?) and stop it again. This is for sure much slower than to rotate at constant speed and reposition for one pixel on every turn. Of course it would be easier to handle, but would produce scanning times of hours. I also think todays general use ADCs should be capable to take enough samples fast enough. But would have to checked of course.

light source:
LED would allow to skip the optical fiber to illuminate the sheet, but I guess to shape the light correctly, it would also increase the effort. The optical fibers give the light already a direction... not very scientifically, but I think you know what I mean.
Laser as light source. Would this mean to skip the optics to bundle the light into a focus point? I have far to little knowledge about laser light, to grasp the implications. Would the same photomultipliers be able to detect them?

jp, actually a drum scanner is some kind of lathe! just a very special kind of!
Luckily the taking of the image information is non destructive in this case!

Neil, you mentioned alternative sensors. What kind of them did you think of? Do you have examples?

Pali, precision for sure would be the most challenging part on the whole project. But starting with an existing scanner could be the key to avoid it for the beginning. After a prototype is there, one could replace existing parts with own designed ones. If this ever happens...


One point popped up my mind: color profiling!
Of course would have to be done with targets and software.

(Just a note for later: drum material perspex)

Well, this beast is really going to be complex. A one persons lifetime project!

I am interested to hear your opinions about this wrap up!

Greets,
Andreas

Just in case you are interested, the service manual for the ScanMate 5000: http://www.analogfilm.camera/wp-cont...vice-Guide.pdf

It has some valuable information about the schematics of the thing...

[Peter De Smidt]

Maybe buy a cheap drum scanner, perhaps one that needs repair, and totally rebuild it. That would probably give a lot of info for coming up with your own design.

[mongole]

Maybe buy a cheap drum scanner, perhaps one that needs repair, and totally rebuild it. That would probably give a lot of info for coming up with your own design.

Well, for the mechanical part of the story for sure.

From the electronically side, I just did some calculations...
Following the service manual, the ScanMate scans at 5000dpi with 900 rpms. Which are 15 rounds per second.
As the drum has a diameter of 100mm and is 314 mm long (sounds a bit like pi, doesn't it?) the extend is (surprise surprise) 314,12 mm (sounds like pi again) and the whole area of the drum gives a square.
Google tells me this are 12,3622 inches.
This means an extend has 12,3622 x 5000 pixels = 61.811 pixel. This are a lot of pixels!
If we scan now with 15 rounds per seconds our roughly 62.000 pixel we get (15 x 62.000) 930.000 sampels per second. Also known as Hz.
This means the AD converter has to be capable of about 1 MHz.

Obviously this is something which can be achived with this chip which costs around 15 Euros...

[barnacle]

Andreas, no offence understood or taken!

Light sensors include:

- photo resistors, where the resistance changes depending on the light falling on it. Pros - cheap. Cons - neither fast nor sensitive, probably very non-linear. Very thermally sensitive.

- photo diodes, where the voltage generated across the diode changes according to the light. Pros - cheap, very fast, reasonably linear, reasonably sensitive. Cons - high output impedance

- photo transistors, a photodiode formed in the base-emitter junction of a bipolar transistor. Pros - cheap, fast, sensitive. Cons - non-linear, maybe restricted range.

- ccd and cmos sensors, usually either a one or two dimensional array of sensors; charge is generated by the action of light in a diode junction and shifted out in bulk. Pros - reasonably cheap, small cell size, usually with amplification and linearisation on chip. Cons - physical sensor arrangement not really suited to the shape of the spot we need to detect, non-matched between cells, complex driving electronics.

- photomultiplier tube, where an avalanche of electrons is generated from an initial photo-electric generated charge. Pros - very sensitive, large target area, good output level. Cons - high voltage supplies, expensive.

Bearing in mind that the idea of a drum scanner is to (effectively) move a very small spot across an image, there are a couple of issues, even ignoring the mechanics of the movement, and the issue of actually generating the small spot. We want a large exposure range with at least 14 bits of image depth and we need to be able to discriminate between very similar values at both dark and light levels. Ideally, we'd prefer to limit the amount of light we get on the film to avoid it catching fire...

The PMT is probably the best option in terms of its dark performance - it can detect single photons - but a photodiode or transistor is certainly something I'd like to play with as a first attempt.


Neil

[Bruce Watson]

Bearing in mind that the idea of a drum scanner is to (effectively) move a very small spot across an image, there are a couple of issues, even ignoring the mechanics of the movement, and the issue of actually generating the small spot. We want a large exposure range with at least 14 bits of image depth and we need to be able to discriminate between very similar values at both dark and light levels. Ideally, we'd prefer to limit the amount of light we get on the film to avoid it catching fire...

My old ColorGetter 3Pro did fine with 12 bits. But with today's tools, you might as well make it 16 bits. I doubt this will change the file size -- I'm thinking the 12 bits/pixel of my scanner were actually stored in a 16 bit byte (three bytes per pixel) so the file size wouldn't change if you were to use the other 4 bits for data. So why not use them if they bring value to the process?

I wouldn't worry about heating the film. To get the most out of a drum scanner you fluid mount the film to the drum, and cover it with an optically clear overlay. So you have drum, fluid, film, fluid, overlay. The film will come out of the drum at exactly the same temperature as the drum. You can't put energy into it faster than it can dissipate it into the drum.

While you might think that you are pushing all kinds of energy thought a tiny aperture and that should result in a "hot spot" on the film, in reality is doesn't. Because the light is going through that pixel for a very short time (A few milliseconds? Microseconds? IDK because I never did the calculations), the total energy transfer is very small. That said, the hugely bright xenon lamp in my Colorgetter is dumping waste heat at around 900W (I did say it was really bright didn't I?). It will really heat up any room that you run it in, and the fan noise is very high.

It's the waste heat and the noise that makes me suggest looking at alternative light sources.

Finally, if using PMTs, you'll want to look up the concept of the log amps, and how they are typically used with PMTs in drum scanners. The basic way this is used is you get to set the end points of the scan to match the film you are scanning. So you can apply the entire 12 bits the scanner can deliver to just that density range that physically exists on the film.

Said another way, your software interface lets the operator set his black and white points (three times, for three colors) for what's actually there. For a B&W negative, for example, the black point is typically set on the film rebate (scanning below "film base + fog" is sorta pointless, yes?), while your white point is set a little beyond (leave yourself some cushion) the densest part of the film you can identify. And that's the density range you scan, no more.

The opposite way to do this is to make that density range fixed, which is how most flatbed scanners work. And you'd fix that range to the worst case scenario, which would be transparencies. This is one of the reasons that most flatbed scanners (particularly less expensive ones) do a less than stellar job scanning B&W film. B&W film has a much smaller density range than tranny film does, so it can turn that 14 bits of range into 4.5 bits in a big hurry. If you like your tonality to be smooth, far better to spread your 14 bits just over the density range you need at the time. Thus... PMTs and log amp circuits.

[Ted Baker]

The opposite way to do this is to make that density range fixed, which is how most flatbed scanners work. And you'd fix that range to the worst case scenario, which would be transparencies. This is one of the reasons that most flatbed scanners (particularly less expensive ones) do a less than stellar job scanning B&W film. B&W film has a much smaller density range than tranny film does, so it can turn that 14 bits of range into 4.5 bits in a big hurry. If you like your tonality to be smooth, far better to spread your 14 bits just over the density range you need at the time. Thus... PMTs and log amp circuits.

That's not necessarily the case, though the controls to do this are often not readily explained to the user or are not directly controllable in some cases. The epson flat beds can vary the CCD exposure of all three channels (unless its faking it) and log amp doesn't really offered anything if a 16bit A/D is offered, or if multi exposure HDR approach is used.

it's interesting to learn how drum scanners work, and how they solved the problems of the day with the limitations of the technology. Some of those limitations no longer apply, the need for a log amp for example. But you still got the problem of keeping the film flat, which I guess a drumm does a good job of.

Personally I think you would have more success if you embraced some newer technologies. Perhaps a drum combined with a modified dslr, one with pixel shift so you record each spot with a correct color, or just a monochrome sensor behind appropriate filters.

[Pere Casals]

This means the AD converter has to be capable of about 1 MHz.

Obviously this is something which can be achived with this chip which costs around 15 Euros...

In fact you need 4 chips, 3 colors + IR for dust correction...

I'm a heavy user of the AD7730 part (http://www.analog.com/media/en/techn...7730_7730L.pdf), a very complex chip I know very well and I integrate in the PCBs I design, low speed and very high precision. It has MUX, instrumental amp, PGA amp, precision DA for offset generation and an internal Microcontroller for SINX and FIR digital filtration...


With the ADS8329, first is that's SAR type, requiring a very good analog signal conditioning as SAR type are not as good as Delta-Sigma in common mode noise rejection. Then one has to take a magnifiying glass to read well 10 times the graphs from page 12 (http://www.ti.com/lit/ds/symlink/ads8329.pdf) to know how many true precision bits you have at what sampling frequency.

If you want reading 4.0 densities you may need an advanced development, perhaps you may use a dual amplification of the same signal to be infeed in two separate A/D chips, and combining the result, this is the way ARRI uses in Alexas, they call it DGA, dual gain amplifier. Another way would be pulsing the laser intensity in two levels, chopping/buffering the signal for the two levels and sending it to two separate A/Ds for each channel.

What I mean is that while silicon parts are so cheap a suitable development may be very expensive and multidisciplinar.

To experiment and to have a "proof of concept" I'd recommend to take a good/suitable USB ocilloscope, 4 channels perhaps, for example Picoscope, you have an SDK https://www.picotech.com/downloads and then you concentrate in the software and in the physics, if not you may invest too much effort in the electronics before knowing if the thing has sense.

You would also need to track drum angular position with extreme precision, 1/4 of pixel perhaps, a PC can deliver 1uS realtime control, but even this soft RTC requieres a realtime extension, or programming drivers + hooking IRQs and HAL entry points, or doing it in Linux. A good way would be extrenally controlling the acquisition, so your custom electronics would only require clocking the oscilloscope and the pc, you would clock the init row in the PC software and the pixel acquisition clock in the USB oscilloscipe, so the pc would know when next sample is for the next row. I guess it can be done in this way, as you don't stress the PC realtime and the pixel clock that's hard realtime is managed by a simple custom electronics, and the oscilloscope holds all signal integrity... At least is how I would go...

At 15 rounds per second, clocking the init row in the PC it's easy, you should increase the Windows task manager granularity to 1ms (from normal 30ms) with SDK funtion timeBeginPeriod(1);

https://msdn.microsoft.com/es-es/lib...(v=vs.85).aspx

Then you can do it in IOPL 3, this is user mode, but process and thread priorities have to be raised to the maximum, this is REAL_TIME and TIME_CRITICAL.

Regards

[barnacle]

Yep, first thing to start with is the sensor/light source. And to start with I'd work in mono; three channels is just multiplication.

Bruce, I suspect there may still be a need for a log amp between the sensor and the ADC though basically I'd want to have a close look for any contouring (quantisation error) at both the high and low points. Though of course the target output device is also a critical part of the system.

Setting black and white levels by changing the gain and DC offset is the broadcast standard way of setting up both cameras and display devices.

Neil

[Ted Baker]

If you want reading 4.0 densities you may need an advanced development, perhaps you may use a dual amplification of the same signal to be infeed in two separate A/D chips, and combining the result, this is the way ARRI uses in Alexas, they call it DGA, dual gain amplifier. Another way would be pulsing the laser intensity in two levels, chopping/buffering the signal for the two levels and sending it to two separate A/Ds for each channel.

Or you could just do multiple exposure, with differing exposure times, a few of the smartphones take this approach. Drum scan after all is a multiexposure device in the first place no?

[Pere Casals]

Or you could just do multiple exposure, with differing exposure times, a few of the smartphones take this approach. Drum scan after all is a multiexposure device in the first place no?

Well, in fact when I suggest "pulsing the laser intensity in two levels, chopping/buffering the signal for the two levels and sending it to two separate A/Ds for each channel." this is a Multi-Exposure (dual) system in a single pass,

You would make two short laser shots, buffering+chopping the signal very fast (two time per pixel) while allowing the converters a full pixel clock time interval to make the conversion.