Any new developments with the FilmFabriek HDS+?

[Tyler Purcell]

6 hours ago, Perry Paolantonio said:

You keep saying this, but it's simply not the case. Please provide documented proof (and not anecdata from some random forum) that this is truly an issue. This was a problem with Windows XP, for sure. 15 years ago.

You wouldn't believe me even if it came out of a Microsoft's engineers mouth. So why should I bother. 

My company has built the top facilities in the country from Fotokem to Technicolor. 

Guess what our techs have said over and over and over and over again, the same damn thing about bandwidth, system resources and small files. When you actually sit down with storage vendors and Microsoft system engineers, to do a final proposal for a multi million dollar facility, these questions are always brought up. It's a HUGE issue in the audio industry where they'll have millions of small files (caches mostly) on raid arrays. This is one reason so many facilities work on mac's exclusively. They DO NOT have this issue at all. 

An example of this is very easy to produce at home.

Take a set of 4k 10 bit DPX files, write them to a limited speed volume, lets say a 1tb NVME over USB-C via NTFS formatting. 

Then take that DPX folder and play it back on both a Mac and Windows system. 

You'll get somewhere around 12fps on BOTH systems. 

Now take that same file, put it on a Mac OS Journaled volume and play it back on the Mac, you'll get full 24fps playback. 

This is why so many storage solutions DO NOT USE NTFS formatting. They have proprietary formatting and use a program or plugin on the client/server system which does the translation. This is why Stornext has been so popular and why companies like DFT have sworn by it for so long. It eliminates all of the issues. 

6 hours ago, Perry Paolantonio said:

Most VFX houses are using image sequences of some kind (DPX, EXR, etc), and not having these issues. 

They are using shared storage without NTFS formatting. I only know two SAN providers who use Windows, all the ones we sell use Linux FOR THIS EXACT REASON! 

6 hours ago, Perry Paolantonio said:

We work with DPX sequences all the time, reading and writing them, on Windows machines. Our ScanStation is a Core i9 with a built-in 24TB RAID 5 that can easily do north of 1GB/second. We capture 4k DPX to this system at 15fps all the time. That's the max scan speed of the ScanStation in that resolution. We can do faster than that with lower resolutions. 

Bro, you don't understand the issue. 

It's overhead. NTFS has horrible overhead issues. You need to have 2x the bandwidth on NTFS systems to do the same thing you can do with Mac OS Journaled or extFS for instance. So sure, if you throw a bunch of drives at something, it will work. But the only reason you need to is because of how bad NFTS formatting is. 

Another thing that is programmable, is turning off indexing. When you write a lot of new files, the automatic indexing system will gobble up system resources. This is easy to turn off on the writing system, probably off on the Scan Station solution, but not magically off on any other system. 

It could be the reason why Lasergraphics sells a computer with the system, maybe is because of these issues. They have probably tweaked the OS quite a bit to get it to work properly. 

6 hours ago, Perry Paolantonio said:

On our Phoenix system we have an internal RAID-0 which we use as a scratch disk for caching. Caches are 10bit DPX at the native res of the job being done - typically about 4.5k. Again, we're easily able to play back and write cache files to this drive at faster speeds than our ScanStation.

Phoenix is much slower at processing than the system can read and write. I don't think that example means much. You need a minim of 32 core Threadripper to get Phoenix to work at any speed worth discussing. Even our little 16 core 3950X system, ran Phoenix horribly slow, it's not storage. 

6 hours ago, Perry Paolantonio said:

Our SAN arrays can do more than 2GB/s and when we copy massive DPX sequences off the ScanStations internal RAID to the SAN, there are no issues as you describe. The SAN is windows based. 

San's generally do not use NTFS unless you're using something junky, even our complete toy Qnap is 100% linux. 

Edited December 8, 2022 by Tyler Purcell

[Tyler Purcell]

10 hours ago, Andrew Wise said:

I guessed the design of the gate was chosen to cause the film to track in one direction. the rollers above and below the gate are on a slight angle to (what I assume) cause the film to want to track in one direction. Here's a video of some 16mm original camera positive running, pushed against the two bearings causing them to spin. But you're right, I have had film just do it's own thing regardless of the rollers. 

 

Yes, I think that's what they were attempting to do. Sadly, the only way for it to work is to squeeze the film in place like a camera does or the Pictor for instance. Using a very light spring, you can hold the film from shifting very easily, but you can't use the perf side, you have to use the non-perf side. We achieved this by using an alternative gate, which we can very easily change it's relative position in the system. It works a lot better than the "steady" gate. I will send pix when we are done with our next design phase. 

[Tyler Purcell]

6 hours ago, Perry Paolantonio said:

You're missing the point. Laser detection has exactly zero to do with the stability of the image. You are saying the laser's position is related to the stability. it is not. The point of the laser is to trigger the camera when it detects a perf, or to count frames. It is not there to stabilize the image. 

What's happening is that the film is warping slightly as the roller pulls it through the gate. That warping is changing the position of the perf, frame over frame. It only has to change by .01mm for the image to appear jittery in the final scan. This issue is because the capstan is not round or flat. This is why the Spirit uses a precision metal capstan with a scratch resistant material. They also use a sprocket trigger, which I think is a lot better for negative. 

The laser detector should be part of the gate, with a little hole, so the film is running through the gate and then triggered before it exits the gate. When it exists the gate, it "floats" for quite a while before it hits the detector. The only other solution to solve this problem (without building a new gate) is to add rollers along the path of the film before the capstan, which can prevent the film from warping around the laser detector. This will solve the issue of vertical stabilization, which is our only issue right now. We have solved lateral. 

6 hours ago, Perry Paolantonio said:

If the gate is not holding the film steady, then the only option for stabilizing is to do it post-scan (Whether you're doing that in the scanner behind the scenes or in software afterwards). but this is utterly unrelated to the laser, which is just a trigger. The Scanstation's gate has nothing to hold the film stable and is designed to allow it to weave quite a bit, so all of the stabilzation is done in the computer after the image is taken but before it's written to disk. This is the only way to do it if you're not using a system with a proper edge guiding and mechanical pin registration.

We are using opposite side of the perf edge guiding, which the stock system can not do. 

The Scan Station does not need to have perfectly optically aligned film. Have you seen how bad the alignment is without the computer stabilization? It's really bad actually, way worse than our scanner. 

We aren't expecting perfection, it's impossible actually. We are just expecting our vertical stability to fix itself with our mods and it will. 

[Perry Paolantonio]

Yes, you turn off the OS-level disk indexing because that's always going to slow stuff down. But NTFS isn't the problem. As I said, we use an 8-drive 24TB RAID5 on our ScanStation. This is NTFS. It easily reads and writes 60fps DPX if the resolution is low enough. When you copy files from it (so, reading) to our SAN, you're doing it at speeds faster than that. The Phoenix system is a similar setup, but RAID-0 NTFS. I've been building RAID arrays for video for the past 27 years. I know exactly what they're doing and how our systems are set up because I set them up personally and tuned them myself. What you are describing has never been an issue for us since Windows 7 came out. Old versions of Windows - absolutely. And MacOS as well. In fact, in 2005ish, it was significantly worse on the Mac than on Windows. 

Our SAN set up is this: bare RAID-5 pools on a linux server presented to a Windows TigerStore metadata server as iSCSI targets via 40GbE. These are UNFORMATTED on the Linux box where they live, which is how iSCSI works. The machine that mounts the iSCSI target formats it however it wants. They are formatted as NTFS by TigerStore, which acts as an intermediate layer,  serving the NTFS volumes to any of the connected clients in such a way that they appear to be that platform's native disk format. That is, they show up as HFS+ to a mac, and as NTFS to a Windows box to optimize performance. The metadata server handles file locking and sharing conflicts. It is a proper SAN. 

16 minutes ago, Tyler Purcell said:

The reason why Lasergraphics sells a computer with the system, is because of these issues. They have probably tweaked the OS quite a bit to get it to work properly. 

Lasergraphics does not provide storage or storage controllers. You buy the scanner and you get the PC that runs the scanner but you are on your own to integrate the storage as you need. We installed an internal RAID card and moved the entire PC into a larger enclosure that could house the number of drives we wanted. Additionally we added a 10GbE card so we can move files to the SAN. All of our scanning is done directly to the internal RAID then copied to the SAN. The issues you describe sound more like misconfigurations than anything else. 

 

18 minutes ago, Tyler Purcell said:

Phoenix is much slower at processing than the system can read and write. I don't think that example means much. You need a minim of 32 core Threadripper to get Phoenix to work at any speed worth discussing. Even our little 16 core 3950X system, ran Phoenix horribly slow, it's not storage. 

Dude - this is ridiculous. First, DigitalVision only just started supporting AMD CPUs for Phoenix recently. Their recommended hardware has been multi-core Xeons for years and still was as of the last time I checked a few months ago. But they do now support threadripper. They have been optimizing for Intel chips for many many years.It's only in the past few years started to work with AMD to optimize their software. And I know this because we proposed to them, right around 2019, building a threadripper system. they talked us out of it because it was unsupported. So instead we built a new machine with dual 12-core Xeons.

Ours is easily capable of doing a lot of work at 60+fps for lower resolution files. Because Phoenix is CPU bound, yes - it's slow with very high res files. But work done at HD or 2k, depending on which DVO Tools you're using, can be incredibly fast. It depends on what you're doing and how you have things set up. It's heavily cache dependent, so our setup reads files from the SAN, caches locally, and writes final output to the SAN. This works well. and the cache drives are NTFS RAID0 that have none of the problems you describe. 

[Perry Paolantonio]

14 minutes ago, Tyler Purcell said:

What's happening is that the film is warping slightly as the roller pulls it through the gate. That warping is changing the position of the perf, frame over frame. It only has to change by .01mm for the image to appear jittery in the final scan. This issue is because the capstan is not round or flat. This is why the Spirit uses a precision metal capstan with a scratch resistant material. They also use a sprocket trigger, which I think is a lot better for negative. 

This is a fundamental misunderstanding of the purpose of the laser perf detector. It's literally just an on-off switch. It tells the scanner "I see a perf" or "I don't see a perf" and nothing more. If they are using it as a means of stabilizing the film then that's a massive design flaw. but I don't think that's what they're doing. Their scanners have always assumed you'd do post-processing of the footage, and one of those steps is stabilization. The way to fix this is for them to do optical frame registration before the file is written to disk. 

There is always going to be some level of slop in any transport, due to splices, or stretched or shrunken film. and the smaller the film gauge the more that slop will be magnified. It's the job of the scanner to create a stable image, which this machine does not do, simply because they are not doing it. The perf detector tells the scanner "there's a frame in the gate" and it probably triggers the camera to snap an image when it doe, but it doesn't (and shouldn't) determine where in the gate that frame is. Moving the laser closer to the gate might help a bit, but it's still the wrong solution because there are other things that could cause instability that can all be fixed in one fell swoop simply by taking the image wherever the frame may be in the gate, and registering it before the file is output. 

21 minutes ago, Tyler Purcell said:

The Scan Station does not need to have perfectly optically aligned film. Have you seen how bad the alignment is without the computer stabilization? It's really bad actually, way worse than our scanner. 

It's not. bad. It's 100% by design. The ScanStation was conceived as a machine to handle film that is shrunken and warped or damaged. So the gate is oversized to allow the film to naturally float. Of course the frames appear to be "off" relative to the scanner's gate. It was never their intention to try to nail the positioning of the frame mechanically, because that's impossible due to the variety of conditions the film might be in. The scanner knows where the frame should be based on how far it has moved the capstan, and it takes an image. It measures shrinkage amounts as well, so if the frame position drifts, it likely compensates for that by analyzing the positions of the last couple frames and making sure it's roughly in the center of the gate before taking the next one. Digital frame registration done after the image is taken is then used to align it so it's perfectly fine, in fact expected, that frame A and Frame B will not be in precisely the same position in the gate when the image is made. 

The whole point here is that you shouldn't bother trying to do a super-stable gate when the software tools exist (FOR FREE: See OpenCV) to relatively easily do realtime registration that's completely seamless to the end user. FilmFabriek chose not to do that, and that's why I've never taken their scanners seriously. They don't seem to be interested in doing this the right way. 

[Robert Houllahan]

8 hours ago, Tyler Purcell said:

The Scan Station does not need to have perfectly optically aligned film. Have you seen how bad the alignment is without the computer stabilization? It's really bad actually, way worse than our scanner.

I scanned 25ft of 16mm ECN ( which did not have perfs at all ) two days ago on the SSA and it was decently steady enough for that film ( from a Minox ) and the frames were steady enough to be worked with.

The Scan Station 16mm and 8mm gates do have a set of roller bearings on either end of the gate to get the film basically in position.

Edited December 9, 2022 by Robert Houllahan

[Tyler Purcell]

4 hours ago, Perry Paolantonio said:

Dude - this is ridiculous. First, DigitalVision only just started supporting AMD CPUs for Phoenix recently. Their recommended hardware has been multi-core Xeons for years and still was as of the last time I checked a few months ago. But they do now support threadripper. They have been optimizing for Intel chips for many many years.It's only in the past few years started to work with AMD to optimize their software. And I know this because we proposed to them, right around 2019, building a threadripper system. they talked us out of it because it was unsupported. So instead we built a new machine with dual 12-core Xeons.

I talked for a long time with them about it. 

No there is no GPU support outside of grading, which of course isn't something you'd do in Phoenix anyway. 

Xeons are nowhere near the speed of AMD Threadrippers. Intel has basically not done any development of them in years. AMD's latest chips aren't even on the same planet as anything Intel makes for the professional market. In fact, they're still at 10nm. 

So yes, the 32 core threadripper, which is fully supported today, is the way to go. Liquid cooled, with a decent GPU, doesn't have to be crazy and A LOT of memory. I would build a dedicated system with 256gb because Phoenix is a memory hog. 

But we've done a lot of testing and no, it barely grazes the disc compared to other things like capturing. 

5 hours ago, Perry Paolantonio said:

Ours is easily capable of doing a lot of work at 60+fps for lower resolution files. Because Phoenix is CPU bound, yes - it's slow with very high res files. But work done at HD or 2k, depending on which DVO Tools you're using, can be incredibly fast.

Been probably 8 years since I've done a 2k project outside of my YouTube channel. All of our scan work is 4k and for digital we are 6k and 8k. The last two features we did were both 8k entirely, with 8k finishes.

We got Phoenix to restore my brand new film, which was damaged from Kodak. Unfortunately the Resolve tools did not work well enough. So we resorted to getting Phoenix and working with them directly to try and figure out the best method to fixing the very subtle damage the film had. It wasn't like big gashes and slashes, which could be easily AI replaced. When dealing with subtle issues, it's much harder to compensate, but it did a great job. The render was a fix+dust, mixed with a sharpening tool to bring it back to the crispness it was before the fix. I would then do manual dust removal in Resolve since I know those tools much better. The original 4k 10 bit DPX files were used for the process and it was around 3200 ft, so around 33 minutes. I was not impressed by the Phoenix stabilizer, it was ok, but it didn't do what we needed and because I didn't want to deal with scene detection, I just decided to do the stabilizing in Resolve, which had already been done since the film was already cut and I was just replacing the original file. It took Phoenix 16hrs roughly to do the job at a few frames per second, not sure of the actual number as we started it and left. 

So for our high-res only workflows, it's not quite fast enough for this type of cleanup. I did notice other tools which weren't as aggressive, were a lot faster, but we needed that aggression to remove the problem. It's still there in some shots as well, I didn't want it to be just a soft mess, so it was a trade off. I think with a much faster system, we could have probably gotten the time down substantially, but not under two hours which is about how long it would take us to render/export the same thing in Resolve. In fact, the resolve clean up tools do a great job, they just leave too many artifacts around. 

[Tyler Purcell]

5 hours ago, Perry Paolantonio said:

This is a fundamental misunderstanding of the purpose of the laser perf detector. It's literally just an on-off switch. It tells the scanner "I see a perf" or "I don't see a perf" and nothing more. If they are using it as a means of stabilizing the film then that's a massive design flaw. but I don't think that's what they're doing. Their scanners have always assumed you'd do post-processing of the footage, and one of those steps is stabilization. The way to fix this is for them to do optical frame registration before the file is written to disk. 

The system has no stabilizing, zero, nada, none. Again, I've already stated several times it's a flawed design. 

The film "floats" in the gate, with nothing rigid to hold it outside of the back. They did this because print film and negative can be different widths, so to insure one gate can work on different film stocks, they made the gate a lot bigger. How much bigger? It doesn't matter honestly, because again .01mm can be seen on screen. 

When film bends or warps, it changes position relative to where it was prior to the bending or warping. 

When your capstan is not round OR even flat for that matter, it can very easily bend/warp the film. 

If the trigger is positioned near the capstan, for this effect to be picked up by the laser, every time this phenomena happens, which is usually once per rotation, the position of where the image in the gate vs where the warped perforation is, will change compared to the frames previous or after.

This warping IS the problem, because obviously if the film was being triggered perfectly every time, it wouldn't matter how fast or slow the capstan moves. However, this warping effect, changes the relative position of image to perf, due to the poor location of the laser trigger. 

We can solve this by making the gate longer and making the film stable as it rides over the laser detector. However, that is going to be a lot of time and money. So our quick and dirty solution is to run the film perfectly round rollers in that area. This will eliminate any of that warping of the film, which is causing our problem. 

Post registration is coming, but for the time being its not here. Until it is, we are stuck trying to make the system as smooth as it can be, which we know it CAN be because it's so close right now. 

I know for fact our scanner has better stabilization than the scan station without post stabilization.

I have not been able to figure out OpenCV. 

 

 

[Perry Paolantonio]

10 hours ago, Tyler Purcell said:

I know for fact our scanner has better stabilization than the scan station without post stabilization.

Huh? By "post stabilization" do you mean the Scanstation's optical pin registration? It's not really post stabilization since it happens inside the scanner before you see the output.  And there's really no reason to ever have optical pin reg turned off. You gain no advantage by doing so.

As I said, a sprocketless scanner doesn't need to, and should not spend any real effort trying to achieve anything more than a "good enough" approach to getting the film frame inside the view of the scanner's camera. That is to say, somewhere inside the gate. The mechanical work involved to make a stable image for multiple gauges, and for film that's widely varied in condition (shrinkage, warping, etc), without software assistance, makes that an almost impossible task. Instead, the scanner should only aim to get the film in roughly the right area, then it should handle registering it by looking at the captured image, determining the position of the frame. Any other approach is really trying to fit a square peg in a round hole. 

The point I've been trying to make is that you're blaming the lack of a stable image on position of the laser perf detector, because you have an expectation that the image should be consistently placed in the gate. Yes, flat rollers will smooth the film out and "fix" your problem. But the issue is that the HDS+ wasn't designed to produce a perfectly stable image at the point of capture. That was a conscious design decision on the part of their engineers. With the FilmFabriek scanners, the idea has always been that you scan the image and deal with all that stuff later. So comparisons to the pre-registered frames between two scanners are kind of pointless. I mean, who cares? as long as the film is in the frame it can be stabilized one way or another. The two machines just do it differently: Scanstation does it internally, HDS+ leaves it to you to do. 

The Kinetta (at least the early models) took the same approach by the way. It's because this is hard to do in that it involves a fair bit of engineering work. I think registration might be part of the capture process on the Kinetta now though.

 

10 hours ago, Tyler Purcell said:

I have not been able to figure out OpenCV. 

OpenCV is not an end-user tool. It's a programming library. You wouldn't use it unless you're writing an application to do stabilization. It's FilmFabriek who should be looking at it and integrating it (or something like it - such as FPGA-based machine vision libraries on a frame grabber board), not you. 

[Perry Paolantonio]

11 hours ago, Tyler Purcell said:

Xeons are nowhere near the speed of AMD Threadrippers. Intel has basically not done any development of them in years. AMD's latest chips aren't even on the same planet as anything Intel makes for the professional market. In fact, they're still at 10nm. 

I'm not really interested in getting into a holy war about CPUs. Use what works for you. The 16-core system you say you have is woefully inadequate though. DigitalVision's software is CPU-bound and heavily multi-threaded, but not for all DVO Tools. For example. the scratch tool (at least in the most recent version we got) is still single threaded, which means it makes zero difference how many cores you have: you will max out exactly one of them when running a scratch repair. Other functions, such as DVO DryClean, are multithreaded, so you gain an advantage from more cores. And the programming was optimized for Intel chips. Say what you want about them, but the system we have is pretty fast for many functions, pretty slow for others. But the things that are slow wouldn't gain much advantage from more cores.

11 hours ago, Tyler Purcell said:

Been probably 8 years since I've done a 2k project outside of my YouTube channel. All of our scan work is 4k and for digital we are 6k and 8k. The last two features we did were both 8k entirely, with 8k finishes.

Yes, the vast majority of what we do is higher resolution than that as well.

I brought up 2k because you keep talking about image sequences and NTFS not being able to handle lots of small files. Phoenix (or any other tool) will be slower with larger files for obvious reasons. But I was talking about the NTFS issue you bring up over and over again here, to illustrate that we can easily work with high frame rate image sequences in Phoenix on an NTFS volume, without these problems you claim are a plague on the post production world. 

 

Edited December 9, 2022 by Perry Paolantonio

[Robert Houllahan]

The Kinetta / Xena / Scan Station all use a high resolution capstan encoder and GPU machine vision pin registration now.

I cannot imagine having to use a scanner without that these days, secondary perf detection to fire the camera (laser or sprocket) without GPU stabilization just does not yield the same results. Having to do post stabilization is just ridiculous at this point and with the amount of film we scan as a lab it would be a completely impossible workflow.

One thing I do like about the Xena perf stabilization is that you can select X-Y or X or Y only and there have been some very difficult films that has helped me scan.

The Track Perf pin registration on the Scan Station works 99.8%  of the time totally reliably in my experience.

[Dan Baxter]

On 12/10/2022 at 4:42 AM, Robert Houllahan said:

The Track Perf pin registration on the Scan Station works 99.8%  of the time totally reliably in my experience.

For 35mm the LaserGraphics only uses the perfs on one side of the film for stabilisation (the side that the optical soundtrack goes on). It's one of those "under-the-hood" settings you can't change.

[Andrew Wise]

On 12/9/2022 at 2:33 PM, Tyler Purcell said:

This warping IS the problem, because obviously if the film was being triggered perfectly every time, it wouldn't matter how fast or slow the capstan moves. However, this warping effect, changes the relative position of image to perf, due to the poor location of the laser trigger.

My assumption has always been the laser by it's own limitations just doesn't have a fine enough resolution to detect the edge of the film within a small enough tolerance to make the perf perfectly stable in the vertical axis. But this isn't a design flaw of the scanner, it's just how it is with the laser/light source! the moviestuff with the red light reflective sensor is the same. This is why other scanners eventually settled with using computer stabilisation from the images received. 

 

What Perry says here is what I agree with. 

On 12/10/2022 at 1:27 AM, Perry Paolantonio said:

The point I've been trying to make is that you're blaming the lack of a stable image on position of the laser perf detector, because you have an expectation that the image should be consistently placed in the gate. Yes, flat rollers will smooth the film out and "fix" your problem. But the issue is that the HDS+ wasn't designed to produce a perfectly stable image at the point of capture. That was a conscious design decision on the part of their engineers. With the FilmFabriek scanners, the idea has always been that you scan the image and deal with all that stuff later. So comparisons to the pre-registered frames between two scanners are kind of pointless. I mean, who cares? as long as the film is in the frame it can be stabilized one way or another. The two machines just do it differently: Scanstation does it internally, HDS+ leaves it to you to do. 

 

The pictor scanner by FilmFabriek has excellent sprocket registration. the sprocket idler wheel triggers the camera to capture a wide overscan with the fame pretty close to where it needs to be, and then the software locks onto the sprocket hole to stabilise it perfectly in real time as you scan. It works really well!

I'd make a wild guess that at some stage the HDS will benefit from a paid firmware/software update to add the same stabilisation which I'd be very keen to jump on

[Tyler Purcell]

4 hours ago, Andrew Wise said:

My assumption has always been the laser by it's own limitations just doesn't have a fine enough resolution to detect the edge of the film within a small enough tolerance to make the perf perfectly stable in the vertical axis. But this isn't a design flaw of the scanner, it's just how it is with the laser/light source! the moviestuff with the red light reflective sensor is the same. This is why other scanners eventually settled with using computer stabilisation from the images received. 

Of course, nobody is trying to get pin registered footage directly from the scanner. 

We just want it to be about what a Spirit can do, which isn't too bad. 

The reason why the resignation is bad, is a design flaw. 

Edited December 12, 2022 by Tyler Purcell

[Andrew Wise]

1 hour ago, Tyler Purcell said:

Of course, nobody is trying to get pin registered footage directly from the scanner. 

We just want it to be about what a Spirit can do, which isn't too bad. 

The reason why the resignation is bad, is a design flaw. 

Lol what?!? your opinion is jumping all over the place, you were just saying earlier how much work you are doing modifying the machine, and how it needs to be better, but now you’re saying otherwise.

sometimes I feel like you just have to disagree with anyone’s comments/opinions just to appear more knowledgeable. 

Edited December 12, 2022 by Andrew Wise

[Joerg Polzfusz]

Children! It's Advent! Can't you stop verbally fighting now?

[Dan Baxter]

3 hours ago, Tyler Purcell said:

We just want it to be about what a Spirit can do, which isn't too bad. 

The spirit is completely different it has a line-sensor. If the film isn't perfectly steady through that then the transfer is warped and it looks deformed. That kind of design won't handle even the most slightly shrunken film because you're vertically stacking lines to make a picture. If you're looking at a spirit scan that is not looking perfectly steady then the scan is deformed. They were designed as a telecine not a digital scanner, the whole idea is you have a 2K or higher line-sensor (they went all the way up to 8K I think) with a height of 1, 2, or 3 pixels and then when you set the output resolution it selects how many lines it has to stack to make the output. You can do low-resolution TV formats (256 vertical lines), standard resolution TV (480/576), high definition (720/1080), other formats common to PCs before 1920x1080 became the standard (so you could transfer to 640x480 for inserting into a video game for example), or even 2K and 4K depending on the model.

[Tyler Purcell]

18 hours ago, Andrew Wise said:

Lol what?!? your opinion is jumping all over the place, you were just saying earlier how much work you are doing modifying the machine, and how it needs to be better, but now you’re saying otherwise.

sometimes I feel like you just have to disagree with anyone’s comments/opinions just to appear more knowledgeable. 

The HDS+ does not deliver anything near a "stable" image. All I'm looking for is something that's actually usable. 

We just printed our prototype fix last night, the scanner is now stable enough for me to be satisfied. My "guess" was accurate. The capstan is not round, thus the film warps slightly and just enough to make it unstable. Our fix, seems to solve this problem. Now we can integrate it into the gate, which should solve all the problems. It'll take a hot minute, but hopefully spring time, we'll have a new gate which solves all these issues. 

16 hours ago, Dan Baxter said:

The spirit is completely different it has a line-sensor. If the film isn't perfectly steady through that then the transfer is warped and it looks deformed.

I understand how a spirit works. 

[Robino Jones]

3 hours ago, Tyler Purcell said:

We just printed our prototype fix last night, the scanner is now stable enough for me to be satisfied. My "guess" was accurate. The capstan is not round, thus the film warps slightly and just enough to make it unstable. Our fix, seems to solve this problem. Now we can integrate it into the gate, which should solve all the problems. It'll take a hot minute, but hopefully spring time, we'll have a new gate which solves all these issues. 

Can you post pictures of your modified gate?

[Robert Houllahan]

22 hours ago, Dan Baxter said:

The spirit is completely different it has a line-sensor. If the film isn't perfectly steady through that then the transfer is warped and it looks deformed. That kind of design won't handle even the most slightly shrunken film because you're vertically stacking lines to make a picture.

I have three DFT Spirit 2k/4K scanners of the very last generation and I can tell you that they can scan shrunken film and make very good scans. These machines use 4K 3-CCD linear sensors and have excellent color and DR they are just costly and complex to run in 2022.

A Spirit 4K was $2M in 2008 and the machining work that went into building the film transport and gate(s) far exceeded the cost of building many more modern CFA based scanners. The Scannity is still the "goto" scanner for many high end jobs for TV and Film and it too can scan shrunken and damaged film with good results.

The Spirit like the Cintel DSX etc. uses a very high precision sprocket encoder in the gate to "time" the scan and a secondary capstan encoder for the servo and so the scan registration is not based on the irregularities of the rubberized capstan. I know sprockets are "not modern" but really well made sprockets can be used with shrunken and damaged film quite effectively.

[Dan Baxter]

51 minutes ago, Robert Houllahan said:

A Spirit 4K was $2M in 2008 and the machining work that went into building the film transport and gate(s) far exceeded the cost of building many more modern CFA based scanners.

Yeah that was my point, although not just CFA but also area-scan like Director which now go for $10K and are sold as consumer-electronics (used that is!)

53 minutes ago, Robert Houllahan said:

The Spirit like the Cintel DSX etc. uses a very high precision sprocket encoder in the gate to "time" the scan and a secondary capstan encoder for the servo and so the scan registration is not based on the irregularities of the rubberized capstan. I know sprockets are "not modern" but really well made sprockets can be used with shrunken and damaged film quite effectively.

Yes I know Arriscan still has the sprocket transports (as well as the other option) even with the latest model.

[Tyler Purcell]

13 hours ago, Robino Jones said:

Can you post pictures of your modified gate?

We are actually doing the modification without a gate right now, it's just a roller system before the capstan and yes I will post pix of it working shortly. The whole idea is to just insure holding the film steady before the capstan fixes the issue and it does. So now that we know this, elongating the gate should work. We will happily post our progress as we go along, I'll make a new thread about it. 

[Niels kakelveld]

I had some old 16mm film from the 1920's scanned at FF 2 years ago. Unfortunately the film was warping and curling horribly so the sprocket was curling in and out of the registration sensor so the result was very jumpy.

Thankfully I was able to stabilize the sprockets with Davinci Resolve by making boxes around the edges of the sprockets. With overscan there was enough room above and below for the entire 16mm frame to always be into view.

The reason FF has no guides on the HDS+ is to accommodate many different film sizes, also weird ones like 9,5 or 3mm and very shrunken film.

Edited December 13, 2022 by Niels kakelveld

[Tyler Purcell]

1 hour ago, Niels kakelveld said:

The reason FF has no guides on the HDS+ is to accommodate many different film sizes, also weird ones like 9,5 or 3mm and very shrunken film.

The original FF gate does have guides. Using shims, we shimmed out the rollers slightly, so the film rides against the edge of the gate. Horizontal stabilization is now good, way better than the later generation "steady" gate. The only problem is vertical stabilization. We solved this by adding a fixed roller between the end of the gate and the capstan. This holds the film in line with the gate perfectly and negates any unevenness with the capstan. 

Is it perfect? Nope. We will need to make a new gate. 

We have run very warped film through our machine and it's quite impressive once post stabilized. 

The newer FF gates do scratch film tho, so we couldn't use them on camera negative. 

Edited December 14, 2022 by Tyler Purcell

[Robert Houllahan]

I find that the ceramic guide systems on RTS and Spirit gates work really well. Basically a fixed ceramic guide on one side and a spring loaded guide on the other. They tend to distribute pressure more evenly over a few frames of film. Roller bearing guides are a bit less effective IMO.

The Form Labs SLA 3D printers can print material which is a Kiln Fireable ceramic.