Home Creators Posts Import Register Favorites Logout

Content

https://www.youtube.com/watch?v=DlgWsFJScU8

I was able to rescue it entirely with editing! Rejoice.

This is the final version which I'll be releasing tomorrow. The two edits begin at about 1:16:25 and 1:28:00; I essentially just cut out the conjecture about color increasing the complexity/bandwidth of sensors, because that appears to be completely false, and moved the rest of the CCD talk into the explanation of 3CCD systems.

This error happened because I've had a misunderstanding of bayer sensors for over twenty years. Everyone I've described this mistake to has replied "...that's how I thought it worked too," so I figured I'd explain what I got wrong.

I was under the impression that they had implicit pixel binning; that if you had a 640x480 camera, that meant it had four times as many photosites, and that each group of RGGB got blended together to produce a finished pixel. This seemed reasonable enough, and it also seemed necessary in order to get accurate luma for each pixel - you can't do that without looking at all three color channels.

This is completely false. A 640x480 sensor has 640x480 photosites (ignoring the actual practice of pixel binning, which I believe is relatively recent?) and simply does not capture full chroma or luma for any given output pixel. If you look at (5,5) in a digital camera image, you are not seeing what was captured at the fifth row and column of the sensor; if you did, it would just be stark red, green or blue, as you can see in various "debayered" sample images online.

To produce a full color pixel in the finished image, the processor has to infer from the surrounding photosites. By all reports this is "incredibly good" technology and has been for a long time. I do not pretend to understand how that's possible - if you didn't capture the red channel at (5,5) then you can never know how much red was at (5,5). You can guess, based on the pixel next to it, but if there was a red dot that fit entirely within a single pixel, that information is lost forever. And that's not just a chroma thing - that dot contributed to luma. If it didn't spill over to the adjoining sites, then you can't guess that it was there, so the final luma will be wrong.

Perhaps this doesn't matter; perhaps there's no functional difference between the way this actually works, and the way I was imagining it with the microlenses etc. maybe because of the realities of optics and maybe because it Involves A Lot Of Math. I am not good at intuiting what is and isn't possible with A Lot Of Math.

What I'm confident about however is that bayer sensors do not capture full data for every single pixel, and this is why they are subject to moire etc. And I'm also confident that 3-sensor systems do - the output from a three-CCD array with a prism system is 4:4:4, every pixel is a stack of red, green and blue values from the exact same physical spot on the image circle cast by the lens. The luma and chroma of the finished pixel are (within limits of optics and ADCs) completely accurate.

The specific description that will be present in the finished video is probably still nitpickable; I expect to get some comments about it, but I'm satisfied with it for the purpose of a summary in passing. In the future I will probably just avoid the hell out of discussing the details of image sensors, I am starting to think that I will just never really fully get it.

Files

The Grey Scanner For Computer RC3 final final FINAL RELEASE draft 1

Support me on Patreon: https://www.patreon.com/cathoderaydude Tip me: https://ko-fi.com/cathoderaydude

Comments

Perrin Anderson

Cool. If you had to jump in from the "editing bay" to do some more explanation that would most likely be perfectly acceptable instead of actually going in to shoot a 1 minute segment

cathoderaydude

My home office has been incorrigibly messy and it would have taken more time and effort to make it look acceptable lol

Perrin Anderson

Lol, I'm also sure most people wouldn't care about your messy background and if they did they're assholes anyway

Akshay Anand

Lol this is a common mistake to make when you venture into the "knows just enough to be dangerous" territory... Why would sensor manufacturers adopt the Bayer CFA if it meant having to put in 4 times as many photosites 😅? The economics just don't work. The reality is of course that debayering and the whole field of jpeg compression are designed to throw away data that wouldn't be all that perceptible at a casual glance. Debayering algos have a lot of Gaussian weighted averages etc. JPEG is straight-up bonkers math devilry.

cathoderaydude

I think that's a bit unreasonably harsh. There are hundreds of technologies that significantly increased the cost and complexity of the products they were added to, which is why b&w TVs continued to sell for decades after color was introduced. I had no reason to think they didn't have to increase the resolution of sensors given the extreme cost of video gear at the time. I cop to the mistake but I think it's one anyone could have made.

Arios

I think image sensors and debayering are one of those fractals of knowledge you can lose your entire life to - we spent almost a month talking about it in one of my college courses and we came *nowhere* near close to the state of the art. The gist that I got is that it works very well for the same reason that chroma subsampling in video works very well - humans are just not that sensitive to red and blue light, so subsampling and then interpolating is "fine" for quality. Especially because "modern" algorithms (as in, the ones discussed in my 2010-era course materials) go far beyond basic interpolation and do things such as edge detection, following curves etc. Modern cameras and RAW editing suites probably have far more advanced processing still. The impression I got is that debayering is essentially a "solved" problem for almost all practical purposes, but I could be wrong on that. Oh and things get even more wild with Fuji and their X-Trans sensors, which use an entirely *different* color filter pattern 🙃

Chas Becht

At risk of making things worse, I'd like to point out that even the naive pixel-oriented grid with color subpixels has the same theoretical spatial resolution problem. If a red dot falls entirely within a green subpixel, it won't be detected. So in all cases, you have a set of spatially distinct samples of light intensity that each have incomplete color information, and you infer from that a set of pixels that each have full color information. You could solve this by putting a microlens on each pixel, so that each colored subpixel would get an identical portion of the full spectrum of light that hit that pixel. But in practice the math is good enough, and for the extra cost of a precisely aligned microlens array, you could just have a higher resolution sensor that would be better anyway. So since we're left with spatially separated color samples, we aren't tied to a pixel grid and are free to pick a pattern that best matches the perception of the human eye. That means oversampling green, and we end up with the bayer filter. Easy, right?

cathoderaydude

Oh absolutely, any solution using a filter array is going to have issues, and as far as my brain can figure it out, this approach does not actually make things worse or better than what I thought was happening. In a philosophical sense it doesn't matter *as far as the impact on final image quality.* The reason I had to edit the video is only because I had given an explicit description of how the pixels were combined which was both unnecessary and wrong, and then derived conjecture about the economic impact on the development of the sensor technology from that, which was an even bigger problem.

Chas Becht

There's also the voice over option. "My office is messy, so watch these ducklings while I talk about bayer filters." Edit: Or I guess bear cubs would be the comedically appropriate baby animal.

Thomas Fuchs

Well the gist is, it's complicated and there's multiple different debayering algorithms that all have strengths and weaknesses. But they all only reconstruct kind of an approximation of the original image. My other hobby (besides old computer crap) is astrophotography and there I use a monochrome sensor (aka a sensor without a bayer array) and a filter wheel and shoot everything 3 to 6 times (depending on how many filters I use). :)

t

I stumbled down this rabbit hole when I was trying to figure out how the hell an atmos ninja could record ProRes raw over a standard hdmi cable, the math on the debayered images far exceeded hdmi biteate. Also I was stumped on how the bitrate was less than the equivalent prores 422/444 and then it hit me in the Apple ProRes raw white paper. It happily shows that they’re recording the signal before debayer and this is same bitrate as a colorless image. Also the moire isn’t intrinsic to color exactly, you get it anytime you have a signal near or above the sampling frequency and don’t use some sort of low pass filter. I also ran into this about the same time I learned about removing the IR/UV filters from cameras for “full spectrum” photography and naively thought I could get much higher resolution photos in “native” b&w but then realized it just improves the light gathering by like ~1/3 of a stop and decided that was too steep a price to pay with Sony already having stupid sensitive sensors.

cathoderaydude

...wow, that's twisting my brain into knots. bayer CFA can be thought of as a _compression technique._ oh i hate that a lot but it's hard to deny Interesting point about moire; anything using a grid is going to be sensitive to it at some point. My understanding is that it still makes it worse, and the idea is knocking around my head that the bayer filter may basically induce moire in patterns with a frequency four times lower than the native resolution of the sensor would suggest, but my intuition for these things is not great.

Lily Finley

I had to write an embedded camera driver for work recently, and that required implementing de-bayering. Speed mattered a lot more than visual fidelity for this application, so I intentionally avoided any of the fancier techniques. Each 4-way intersection of input pixels gives you a full set of RGGB, so for every intersection, I just grabbed the red and blue and averaged the 2 greens. That sacrificed one row and one column of resolution but that was fine for this. The result actually looked decent despite its simplicity.

t

I'd have to think about that a lot more than I want to, but my intuition is also lining up with sampling chroma(s) and luminance at different rates is going to lead to "issues" that need to be handled some way or another (and mostly are handled somewhere in the software/hardware/visual perception stack)

Akshay Anand

I did say it's an easy mistake to make. My tone may have come off wrong because my point was that unless you dive deeper or specifically start looking up sensor designs (as I had to for a DSP class), you don't understand the enormous amount of trickery needed to make digital imaging work.

antlers

This was so unexpectedly fun. If it's not too much trouble, do you think you could post just a scan of like, nothing (a white/gray/black blank page?) from Gray Scanner (For Computer) somewhere? I really liked the look of the texture from its messed up distortion...

antlers

Awesome, thanks. An edit of fullgrey.tif may become a texture overlay on my new website soon . . . . . . .

Jaymz Julian

My first job was working at a digital print shop in 1991, and so I thought I was going to be so clever and be able to be like "Um, actually...". But what actually happened is you caught all of my memories exactly, safe remembering the old times on a day when I was feeling terrible really improved my day. And yes, we did have a Bernoulli drive at work. And yes, color scanning was a giant pain - what we'd do, is work on grayscale and then use the one Mac with enough power to handle color work to replace all of the images at the last minute. This was an early version of quark ,iirc. I wish I could remember the name of the rip software though .. I know it ran on sunos, but that's all I recall sadly. But just hearing someone else having heard of rippers at all made me smile. So thanks!

Philippe

Milla Jovovich

Danny Forche

So I noticed you started talking about parallel port modes (EPP and ECP), and this reminds me of something I've never quite figured out. Do you know if anybody makes a USB adapter that supports bi-directional ECP protocol? I have a Chinese Gameboy cartridge dumper that uses parallel, and it needs this; I suspect some of the early 2000s peripherals like ZIP drives do as well. I tried a coupeo generic "USB parallel port adapters" but despite showing up as a LPT port in Windows device manager, the software just said it couldn't detect the hardware. I suspect most (if not all) of these adapters just emulate SPP single-direction mode for compatibility - after all, they were primarily designed to let you use old printers on modern PCs, which wouldn't require any sort of communication back with the PC (I don't remember printers ever sending status codes such as low ink levels before the dawn of USB printers) Even if SPP and EPP were bi-directional by design, those cheap USB parallel ports do not seem to do ECP. I've read 1-star reviews from people saying they bought one trying to hook a ZIP drive up to a modern PC and it also didn't work, so I'm obviously not alone in this observation. It's super easy to find USB serial ports that show up in device manager as COM ports - they're almost always plug-and-play - but what's the deal with parallel ports and why has nobody made an ECP version?! I did find some bespoke electronics company that *claimed* theirs did ECP, so I bought one for like $30 or whatever they were charging, but haven't tested it out yet. Thought I'd see if you had any suggestions too

Anthony Biondo

Wild. Fun. The rabbit hole just keeps going, though. You got me curious, and the earliest reference to a "flatbed page scanner" I could find in US patents was from 1974, but it was for fax purposes so I don't think it really counts, though it has the main parts of a scanner: https://patents.google.com/patent/US3867569A It has a background of the art in its first couple of pages. This sends me down slightly different rabbit holes. It talks about the cylindrical drum scanner, which it dates back to 1970 or 1971. For example - https://patents.google.com/patent/US3867569A And it also references an earlier patent for a "selective copier" and "selective reading device" from 1970 that used optical character recognition. https://patents.google.com/patent/US3512129A -- It was apparently used to avoid having to retype documents when editing text?? So, like, a typewriter that could read text, maybe? And THIS reference goes into other earlier scanner-like things, like the "Farrington Automatic address reader utilized by the US. Post Office." Which ... read mail... in the 60s?? https://artsandculture.google.com/asset/farrington-automatic-address-reading-machine/IwE3YqxP1jnzEw?hl=en According to hackaday: "The post office was an early adopter of OCR, beginning their R&D in the 1950s. During this time, the Farrington Manufacturing Company began developing their Automatic Address Reader under contract with the USPS." https://hackaday.com/2023/09/20/youve-got-mail-reading-addresses-with-ocr/ https://www.youtube.com/watch?v=V4LJs2ZoDR4 Anyway, this rabbit hole just keeps going and I'm done for now. I'm an IP attorney and love when I get to do this kind of research for work. And now I end up watching two hour stories about the history of PC scanning and loving it .

cathoderaydude

Yeah, same deal, I've never heard of one. I have the suspicion that those things have very high level controllers in them and are basically hardwired to only implement the original PC parallel port spec. Given the low signaling rates I imagine it's something that could be fairly easily achieved by a skilled hardware hobbyist but 95% of the work would be in the driver.

t

Also I really like the editing, transitions, graphics, pacing, and general flow of the video.

Danny Forche

Thanks for the reply! If I ever find the "GB Transferer 2" that I misplaced somewhere in my house, I'll test out that bespoke USB adapter I bought and see if it works in a Windows XP VM. I doubt it, but they *claim* it supports ECP, so it would be nice to find out. I finally finished watching the video - your note about fax machines and color scanners made me remember that in the mid 2000s, there were "color fax machines" being advertised for a hot minute, I remember seeing them at Best Buy and thinking that was kinda wild, since flatbed scanners and PDFs were already ubiquitous by then, and the technology disappeared just as fast as it emerged. I wonder what the deal was with that, I believe it sent a special signal first to see if the recipient's machine responded with an acknowledgement signal that it can print in color, if it didn't get one back it proceeds to do the original greyscale mode... but I never tried it. Personally I hate fax and wish it would die off, but the stupid medical billing industry will ensure that never happens here in the US. Lastly, regarding moiré patterns in scans... are you sure that problem was fixed? I've noticed, when I scan printed materials (e.g. things that aren't photographs, that were originally created on a computer - such as album covers, book covers, stuff like that) at 600DPI, as I'm wont to do since it's basically "larger than life", and more often than not, if I'm viewing it scaled down to fit my screen, it has really bad moiré and is practically unusable. If I zoom in to 100% scaling, I see the individual dots that were used by the printer - which is cool, but not what I'm after lol. The only solution I've found is to literally scan at a lower resolution, like 150DPI, just so the image is smaller and I don't run into that. But I'm an archivist and want to get things in future-proof qualities (remember when 500x500 album art was considered good? and now every streaming site has 1400x1400 at a *minimum*) and it would be nice to figure this out. I have an HP all-in-one printer with flatbed scanner that I use, and I have also tried a larger flatbed my local library has.

Evan Grove

I was actually wondering the other day "when the hell did this become a thing?" Lol. If I had to take a guess, one of the reasons for the early flatbeds' higher costs (besides the moving scan head) is the big sheet of optical glass. I have an Epson V800 that I use for scanning film, and I used to have a V600. Both incredibly boring devices, though the V800 does make some very pleasing robot noises.

Jason McKillican

I imagine that the motor control (microcontroller, sensors, power components) needed to move the scan head along a linear path as opposed to just using a brushed DC motor driving a drum contributed to the delay in Flatbed adoption. The "easy" way would be to use a stepper motor, or a screw type linear actuator with rotation counting, but you have to have a microcontroller for a stepper, or even just to re-home and count rotations on a regular DC motor. A drum can just switch on/off power to the motor according to the buffer control, and maybe have some kind of paper detect sensor/switch to tell it when to stop without getting heavy on the microcontroller side

Loading_M_

Well, the other thing to remember here, is that for most CCDs, the fluctuations caused by random noise and imperfections in the lens, etc, are going to cause larger problems than the Bayer filter. Also keep in mind that when you run the resulting image through JPEG compression, you're discarding all the high frequency noise, so a tiny green dot would likely be discarded by JPEG even if it happens to fall on a green pixel. Finally, the filters aren't perfect - other light does still get through, so some luma information is still retained.

Loading_M_

Actually, I wouldn't be surprised if manufacturs actually did have to increase resolution to get a comparable image - maybe just 1.5-2x, instead of a naive 4x, but an increase nonetheless.