Perry Paolantonio

As Tyler says, you need to add 3:2 pulldown. The resulting file is interlaced (since you're repeating fields, not frames) with this pattern. It can be done in a lot of applications, such as After Effects.

They're different. Gamut refers to the range of colors a device is capable of displaying, which is limited by the display technology. If the display, for example, can't properly show deep blacks without crushing them all into the same value, or it can't display particular shades of a given color, that's a limitation of the display and that in turn limits the display's gamut. But the file you're looking at on that display could hold color values well outside of the limits of that screen. Bit Depth doesn't really care about the gamut of the display, it's just the potential number of colors each pixel in the file could be. -perry

It's worth noting that in most cases, HDR scanning is mostly useful with film that has the extreme ends of the range represented - that is, lots of shadow and lots of highlights, at the same time, in the same frame. What HDR scanning does is let you pull that shadow detail out, while preventing the highlights from blowing out. Modern print stock, even older print stock, is typically fine on non-HDR scanners and you can pull tons of detail out of the shadows with a good sensor. Reversal tends towards the extremes, with deeper shadows, so it's harder to get that detail out. That's why the Director does a good job on reversal that has areas of deep shadow as well as areas with nearly clipped highlights, in the same frame. That said, scanners like the ScanStation have approximately 13 stops of dynamic range, and don't typically have an issue with workprint or release prints, because those tend to be less extreme than OCR. -perry

The Bit Rate of a file simply refers to the amount of data the file contains per unit of time, typically a second. So a standard definition DV file (a highly compressed acquisition format) is 25mbps, or megabits per second (note the small 'b' -- that means megabits, not megaBytes). A typical HD Blu-ray AVC encode is also somewhere around 25mbps, but it's a different compression scheme (AVC, a variant of H.264). Bit Rate is not a universal measure of picture quality. Hell, it really shouldn't be used as a measure of picture quality at all, because it's only relevant when you're talking about the same type of file (for example, two MPEG2 files, or two AVC files), and when you're talking about the same encoding tools. And there are many other factors that affect the final quality of a compressed file besides the bit rate (including the quality of the source footage, the quality of the encoding algorithm, the quality of any scaling algorithms used, whether or not there's low pass filtering happening, whether or not there's artificial sharpening, and on and on). Back in the early days of DVD, one couldn't expect to get a decent looking picture at a bit rate below about 6Mbps (DVD MPEG2). By 2005 or so, encoders had come out that were capable of encoding at sub-6mbps rates without significant quality loss. By 2015, we can encode a pretty good looking MPEG2 file at around 4.5Mbps, if the source is clean. But this is 100% dependent upon the encoder. You can't do that in Apple Compressor. You can do it in Cinemacraft. With Blu-ray, you're talking about files that have 4x the resolution of standard definition, but with a codec like AVC and a proper encoder to do the compression, you can easily make a really good looking encode at an average bitrate of 12-15Mbps. That's only double the bit rate of DVD, but for 4x the data. This is because AVC and MPEG 2 are totally different, and can't be directly compared. The bit rate of an MPEG2 file has absolutely no relevance when talking about the bitrate of an AVC file, if the intention is to compare the quality. People do this all the time, though. All that being said, the effect of a lower bitrate file compared to a higher bit rate file of the same compression type typically results in blocking, or quantization artifacts. See this wikipedia article for an example: https://en.wikipedia.org/wiki/Compression_artifact Some of these artifacts can result in banding, as David Mullen mentioned. But banding is also a result of poor (or no) dithering from 10 bit sources to the typical 8 bit files used for display in formats like DVD. Bit rate is one parameter of many within an encoder. In many cases, all you need to do is set this higher to get a better image. But with formats like DVD, Blu-ray, or even web streaming, where you have caps on how much data can be streamed or how much space the files can take up, lower bit rates are required. And this is where good encoders shine, because they can handle it. -perry

Does this work with the Windows version of Resolve? I can't find anything but Mac software on the JL Cooper site.

We do a lot of this kind of thing - as Will points out, use the guides in your viewfinder, if you've got them, so that when it's cropped you don't lose anything. That said, you do get more flexibility by scanning at 2k with no or minimal overscan. That way you have a tiny bit of left/right wiggle room when you crop (~120px), but more more up/down (about 500px). That means you can crop it yourself shot by shot and do it exactly the way you want, without having to use a one-size fits all approach when scanning and doing the crop at that stage. It's easy enough to crop in most edit systems, resolve, etc. -perry

There is no post-scan stabilization feature in the ScanStation. It's done in real time as the scan is being made, and once the end frame of the film is reached, the scan is 100% complete. Any post-scan stabilization is done in different software (pick your poison), and not by the scanner or its control software. -perry

Moises says "It has not been edited or processed in any form other than the color change to B&W." Presumably Moises did that on his end, but it could be done in the scanner as well. There are basic primary color grading tools in the ScanStation software that allow you to control Lift, Gamma, Gain and Saturation. When scanning color negative, the scanner is calibrated to the film base, and that process removes the orange mask. A proper flat color negative scan of correctly exposed film should require no grading in-scanner - you literally choose "no grade" from a popup menu to turn off all color correction, and just a base calibration. But in some cases, such as when dealing with a dense negative, you might have blown out highlights (base calibration sets the bottom end of the scale, putting black at a code value of 95, the standard for DPX log files. In this case, highlights might get clipped, so you'd turn grading on and pull the gain setting down from its default a bit, just to keep the whites from clipping in the highlights. Of course, you could try to do a real grade in the scanner, but because it's not designed for that, it's not really advisable. You have no proper reference monitor for one, and just histograms or an RGB parade to go by, to ensure you're not crushing or clipping. The scanner is aligning the film on the left edge to a fixed point on the Y axis. If there is some slight rotation on the left edge, like if the film is going through the gate at a slight angle), it will correct for that rotation to make the left edge perfectly vertical. The entire image is rotated in that case. It does no scaling in the process of registering the frame, as far as I'm aware. While you can set crop and scale values in the scanner, you're talking about frame by frame changes, not overall changes. The scanner only sets overall (whole scan) crop and scale values, they do not vary from frame to frame. This is the point I've been trying to make. We've had our ScanStation longer than just about anyone else with one of these machines, and I can tell you that we have never seen any rocking in our scanner with any film, ever. None. never. The only time it has appeared was when the film was post-scan stabilized, as in Friedemann's footage. But the original scan had no rocking, it was an artifact of the post-scan stabilization process. We will be scanning the film Moises posted as soon as we get it, so we'll know more then. -perry

...Except, that's not what it's doing. The scanner ONLY looks at the left edge (perf-side) and aligns that to a fixed point on the Y axis. The right edge falls wherever it may. The scanner does not care about that, and doesn't align anything on the right edge. Indeed, if the film is slit inconsistently, then aligning both left and right edges would warp the picture, because a right edge that's at a slight angle, that's then made vertical would stretch part of the image in the process of making it vertical. but that's not what's happening here.

The large white rounded-corner edge you're referring to is the gate. When the film is passing through the scanner, by design, it's allowed to "float" inside the larger gate area. that is, the gate does not determine the edges of the scanned frame, because it's bigger than the film is wide. The reason for this is that the scanner is designed to handle film that's shrunken or damaged. There is no pressure plate. There is no mechanical registration pin. It's a curved gate with a V-groove channel that keeps the film in position (plus a couple roller bearings on each side of the film at each edge of the gate, again, to keep the film in the correct position for the feed and takeup sides of the transport, but NOT to provide edge guidance within the gate itself. Once the image is made, the horizontal edges (top and/or bottom) of the perforations are used to register the frame vertically. The entire frame is moved on the Y axis until the perf is lined up vertically to where it should be. The Left (perf-side) edge of the film is used as a horizontal reference point, and the film is aligned on the X axis until the left edge of the film is where it should be. Everything else falls where it may. Because the overall image includes the gate, and the gate is absolutely fixed in space relative to the sensor in the scanner (that is, it doesn't float like the film does), when you fix the floating object to a point (the film on the X and Y axes), then the previously fixed objects (the gate) appear move relative to the film. Of course, nobody scans with this much overscan so you would never really see that. On the OP's scan, at about 20 seconds, on the right edge of the overall frame (not the camera gate, but the whole scan), you'll briefly see the white creep into the right edge of the overall scan frame. This is the same thing we're seeing here. That said, the end result is cropped to eliminate all this, so it's moot. It's just how the scanner does its registration and is this way by design. -perry

I understand the logic. I used Friedemann's film as an example, simply because you keep saying there is rocking happening in the scanner. Our experience (and that scan) says otherwise. Where is this rocking coming from? We don't know yet. I'm not convinced it's the scanner because we can demonstrate that footage shot on the Logmar does not exhibit this problem. I've reached out to Moises, and will be getting his film here to test on our scanner, but it will probably be several weeks as he's on location. Stay tuned. -perry

The distance between perfs *in the film* varies from frame to frame, in a 5-frame pattern (like the horizontal position variations). The scanner is aligning the perfs vertically, but because the distance perfs varies, the frameline shrinks and grows by an amount that matches that variation. -perry

I still have Friedemann's film here from May. This film, which we've discussed earlier in this thread: I just put it up on the scanner and scanned a few hundred frames at 4k, with the scanner set to the widest overscan possible. This captures a little bit of the scanner gate (the white rounded-corner area), the entire film including both left and right edge, the perfs and the image as well as a bit of the surrounding frames. I brought this into After Effects and placed 3px red reference lines along the two film edges, and near the top and bottom of the frame. These are in fixed positions, so it's easy to spot any movement in the scan. Here is what you will see: 1) Left edge of Film: There is some horizontal variance in the position, +/- 2 pixels or so at 4k. This amounts to about .04% (2/4096). This is an inconsequential amount. 2) Right edge of Film: There is a bit of variance here, parallel to the left edge. When the left edge moves 1px, the right edge correspondingly moves 1px. Therefore, we know that the film is horizontally positioned within the film gate to a tolerance of about .04%. We also know (from looking at the film edge reference lines) that there is no rotation of the physical film in the scanner gate. When you see the film edge move a pixel or two, the opposing edge is moving in sync with it. The opposing edge's opposite corner is also moving in sync with it, therefore, there is no rotation in the scanner. 3) Top and Bottom edges of frame: There's a variance of several pixels up and down, which corresponds to the varying distance between perforations. This repeats in a 5-frame pattern, which makes sense since it's a 5-perf punch used to make the perforations at the factory. THERE IS NO ROTATION in the scanner. What you see is the entire frameline, perfectly horizontal, moving up and down in a uniform way. 4) The perforations weave left and right, indicating the degree to which the edge of the film has been stabilized to correct for the variation in perf position relative to the film edge. This footage is direct from the scanner, with a quick trip into After Effects to draw the red lines. No stabilization was applied. No color grading was applied. It was scanned to ProRes 422HQ at 4096x3112 and exported to the same codec and resolution from After Effects. Please compare this with the footage on Vimeo which has been post-scan stabilized. The rotation in the frame occurred at that stage. I didn't do that stabilization, so I can't really say what settings caused that, but it is not in the raw scan. Here is the test scan: https://www.dropbox.com/s/jpg8o7rduymilvv/4k_Overscan_ReferenceLines.mov?dl=0 Now Carl, can you please stop insisting this is in the scanner, when it is demonstrably not? Thank you. -perry

Hi Lasse, Thanks for clearing that up. Do you suppose the rocking effect we're seeing in the footage Moises posted could be caused in-camera, if the side-steer is not engaged? Thanks! -perry

We have seen logmar footage with much more extreme buildup in the gate. According to Logmar, in that case it was because the edge guide and pressure plate were not engaged, causing the film to be slightly out of the correct film path. As a result, it was rubbing on things it shouldn't have, and the emulsion was getting scraped off and building up in the gate. In that case, operator error when loading the film. I haven't used the camera myself, but I wonder if it's possible that the pressure plate could be engaged, but the edge guide not? That might allow for some slop in the film path that could cause this. or that a poorly formed loop is somehow allowing the film to scrape against a surface that's causing this buildup of emulsion (assuming that's what it is). -perry

It's not a matter of "belief" -- you're simply wrong about it being in the scanner. I am right now looking at the flat scan we made for Friedemann Wachsmuth (the more recent clip he posted on Vimeo). I have it playing in Quicktime Player. On top of the quicktime window I have another window, using the horizontal top edge of that window as a straight edge to judge the supposed rocking motion. It's not there. I'm not sure why you keep insisting that it's in the scanner, when you can't see the original footage. I know the footage Friedemann posted was post-scan stabilized by him, and that's where the rocking was introduced. Again, there is NO rocking in the initial scan, it is not something caused by the scanner. There is a bit of vertical jumpiness from frame to frame and the gaps between frames (the frame line) change, and this is in the camera. This is not in the scanner (it can't be) because the scanner is scanning the target frame and about 1/10 of the bottom of the previous frame and about 1/10 of the top of the next frame, all in the same image. It has no concept of the frame line, and is only doing stabilization based on the perf and film edges. Therefore, variable frameline height is a camera issue. It seems likely to me that rocking was introduced in a post-scan stabilization pass, and might be tied to this frameline thing. Just a theory. But it's worth noting that the whole frame line is moving an equal amount - that is, the whole frameline height changes in a uniform way, it's not showing a rocking pattern where it alternates from left to right. I will see if I can get permission to post an excerpt of this footage as a 2k flat scan so we can put this to rest. -perry

Resolve on Windows doesn't support ProRes. It's a licensing issue with Apple. You can read and play the files in Resolve, but you can't render to it. Our workflow has been to render out to an uncompressed format (DPX, 10bit Quicktime, etc), then use ffmpeg and AVISynth scripts to make ProRes files. We've had 100% compatibility with the files using this method and the quality is great. But it's a bear to pull together a workflow and a lot depends on your setup. There are a couple applications out there that can render ProRes files on Windows, though, ranging from very inexpensive to several hundred dollars. -perry

This is telling you how much detail from the real world the film is able to resolve. Grain size, optics, camera transport all come into play here, but basically, it's saying that X film stock can resolve Y lines of detail. And that's important information. ...but: The film scanner is not making the initial image, the film camera is. The scanner's job is to make as faithful a digital copy of the FILM as possible (not so much the picture on the film, but the physical film itself). The more faithful a reproduction of the FILM the scanner is able to make, the better the end result. If the scanner is only able to make an image of a given grain of film using say, 1-2 pixels, that grain of film isn't going to have the same detail in the scan as as scan made using a sensor that's using 5-6 pixels to render that same grain. So you're talking about the film's resolution here, and that's different than how much detail the scanner is able to capture of what's on the film. You're talking about now. I'm not. 10 years ago I worked for a company that authored DVDs. The owner of that company insisted that watching video over the internet could never happen because (at the time) the files were too big. He couldn't imagine how you'd move an HD file over the internet. That's because he ignored the facts that: A) Bandwidth constantly gets wider (I'm talking about internet connection speeds here) B) Compression algorithms continually get better (H265 and others, for example), allowing more data in the same size file, or smaller files, depending on your needs C) Processing speeds continually increase (related to B, allowing better decompression at cheaper costs. Moore's Law). D) Storage costs continually drop and storage systems continually get faster. 2 years later, the company went out of business. And here we are 10 years after he said that. DVD and Blu-ray, long my company's bread and butter, are nearly dead at this point. The majority of the work we're doing in that area now is VOD file prep for all the streaming services. We've had the same case of blank DVDs sitting on the shelf since 2013 (we used to go through a case every 2 months on average). A scanner that could do 4k 10 years ago approached a million dollars. It was a massive expense, it was hugely expensive to maintain and operate, in some cases it required special electrical lines and cooling systems and rooms to house it. 4k was expensive because the hard costs of getting into the business were so high. That hasn't been the case for several years. Our 4k rate is about 30% higher than our 2k rate. We can do this because our cost of entry into the business was lower and our overhead is lower. We use a Lasergraphics ScanStation for small gauge and a Northlight 6k scanner for 2/3/4 perf 35mm. We're not alone in offering lower cost scans, there are plenty of places out there that are doing this. So again, the idea that it's astronomical to scan 4k is no longer accurate if you look around. I can't even being to tell you how much 4k we scan for 8mm home movies for people who want to make digital archives of their shrinking and aging films. I don't think you're a hypocrite. I think you're making my point. Though, who knows if that scanner will ever actually be released (it's coming up on 18 months since it was first announced with no sign of it). Also, when I saw it at NAB 2014 it couldn't do 4k 16mm, only 35mm. 16mm is an add-on (again, who knows if that'll ship with the scanner) and at least at the time, it used a window at the center of the sensor, rather than physically moving the sensor back to capture the whole frame using all the available pixels. In fact, it couldn't do true 4k at all, because it's a UHD scanner, limited to a 16:9 at 3.8k. -perry

Yes. Both will do it, because both scan the film from edge to edge. The gate is larger than the physical width of the film so there's no issue with formats like this. -perry

Not really. It's not a "bad batch" -- we have seen this problem in Super 8 going back to the 1960s. In some cases the pattern is different (I posted an example earlier in this thread of that, from film manufactured in 1969). But the "sawtooth" weave pattern has been there for a while. It's in some of my own Super 8 shot in the 1990s -- so while it may vary from batch to batch, and some may be worse, this is not a one-off problem, it's an issue that's been present in Super 8 since its release. I think what you're seeing there is from the compression on Vimeo. Never use anything you see on Vimeo or YouTube or other sites to analyze the grain of the film, because part of the compression they apply to the films that are uploaded (which is usually already compressed, so it's getting a double dose of compression), is to smooth out the grain. The repeating pattern probably has more to do with the GOP structure of the file that's being streamed than with the grain of the film. The only way to test is to have the original scan files made available. unfortunately, this is usually impractical because they're so large. -perry

Actually, I never said it was definitely a software glitch. It could also be something in the camera. You're saying that if the rocking was introduced in stabilization then it should also affect the perf? It's really hard to tell on Vimeo since you can't frame through the film or download the file to load up in a desktop application, but pausing it in full screen mode, then playing and pausing quickly, it sure looks to me like the perf's right edge is parallel with the frame's left edge (even though the distance between them changes from frame to frame). That would indicate that it's moving in sync with the rocking motion. I'll see if I can get permission to post footage shot on a logmar. I believe we're expecting some to arrive in the next week or so. At the moment, I don't have any scans of footage shot on that camera that includes the perfs. -perry

Ok, Sorry if I seem a little snippy here, but have you actually read any of this thread? The two examples Friedemann posted are from BEFORE Lasergraphics updated the scanner software - the earlier one is from over a year ago, the newer one from May of this year. The scanner update, which was literally released in the last few weeks, does the stabilization in the scanner. This is NO LONGER AN ISSUE, and the videos you're using as reference are "old" in the sense that they were scanned before this addition to the ScanStation software, and would have required a post-scan stabilization pass to correct for the perf alignment issue. We didn't scan the clip Moises posted at the beginning of this thread, Pro8mm did, so they'd have to provide detail on the workflow on their end, I can't say what happened there. But it sure looks like the same rocking motion we see in Friedemann's clip so it seems likely to me that a similar stabilization pass was made that caused this, at some point after the scan and before the video went up on Vimeo. As I've said repeatedly, we've never seen this rocking motion in our scans, and it is definitely NOT in the original scans we did for Friedemann, or in scans we've done for any other Logmar owners. -perry

There's no contemplation or guessing here. I personally scanned the film you used as examples, on the scanner that's sitting 10 feet away from me right now. There is no rocking in the original scan, that appeared after it was post-scan stabilized. At least for the earlier example, the fact that it was stabilized was brought up by Friedemann, who shot the film, in the comments on that vimeo clip. Why is that so hard to imagine? I think it was done in either Motion or After Effects, which are commonly available tools. Doesn't that seem a bit premature, since we don't know what caused this? Seriously, I'm pretty sure since we got the ScanStation a couple years ago, we've scanned well over 400,000 feet of film on it, in 8mm, Super 8 and 16mm. These three films we're talking about are the *only* ones I've ever seen this rocking motion on. -perry

This is an excellent point. Our Lasergraphics ScanStation can do the same thing (output to multiple formats at once). A 2k scan made with the scanner in 2k mode (a 2.5k window in the center of the 5.1k sensor) does not look the same as a 2k scan made with the scanner in 5k mode, where all 5.1k photosites are used to make the image. Here's an example of the difference, from some Super16 footage: http://www.gammaraydigital.com/blog/case-super2k I'm not certain, but I think the Director may always operate in 4k mode, downscaling the image to 2k if that's what you want. That said, if you're comparing it to another scanner that's operating at a native 2k, you'll almost certainly see a difference. -perry

This is not accurate. It's a longstanding bit of incorrect "common knowledge" that 16mm is 2k, 35mm is 4k, etc, etc, but it's simply untrue. There is no way one can say X film gauge = Y pixel resolution, because film isn't made of pixels. That's an apples to oranges comparison. Film grain is an organic shape. It's not a square pixel. If you want to get an accurate representation of that grain, you need more pixels to properly render all the subtle details, curves and variations. Let's pretend you're a scientist working with nanoscale-level material. Are you going to use an optical microscope like you'd use in a biology lab, or are you going to use a scanning electron microscope, if you want to get an accurate picture of what you're looking at? Sure - in practice, if you look at a 2k scan projected with a 2k projector, and a 4k scan projected with a 4k projector, assuming both are correctly calibrated and you're viewing at the correct distances you *shouldn't* see any difference between the two. But if you get close up, you will. It's the same as 1080p and 720p. Once you're past a certain distance from the screen, your eye simply can't resolve enough detail to discern a difference. But if you increase the screen size or get closer to it (imagine a 60" television 6 feet from a couch, not an uncommon situation), then you clearly see the differences. So what does that extra resolution get you? Better grain resolution, as mentioned. Since the grain *is* the image, why wouldn't you want this? Even if the end product is destined for a lower resolution, you're better off scanning at a higher res and downscaling it anyway. More photosites on the sensor mean you have more points picking up the fine details and that can mean not only increased sharpness, but slightly better dynamic range (again because you're able to render a single grain of film with more than one or two pixels like you'd get with a lower res scan). But much of this arguing about resolution is kind of silly (the number of pixels are only one of many factors here - optics, dynamic range, transport stability of both camera and scanner, and registration quality are all arguably more important), I'll say that to me the most compelling reason to scan to 4k is to avoid having to scale up later. 4k televisions are under $1000 now, and they're going to replace HDTVs (unlike all that 3D nonsense being pushed on consumers a couple years ago). When you have a gigantic 4k screen and you're close to it, you're going to see softness from upscaling the image from a 2k scan. 8k TV isn't that far off. The less you have to blow up the image in the future, the better, and there's no real downside to downconversions for use on current systems. It makes no sense to me to *not* scan at 4k right now based on this argument alone. -perry