Live data from Hacker News

Driver adventures for a 1999 webcam

blog.benjojo.co.uk

41–50 of 78 posts

Re: Driver adventures for a 1999 webcam

#41
post #29

This is pretty cool and impressive work! In a pleasant turn of events, "USB video device class" or UVC would have its initial release just 4 years later in 2003. Webcams implementing UVC, which most do since the early 2000s, communicate using a standard protocol which means almost any OS can access almost any webcam without any special drivers or software. I have an 2012 Logitech webcam connected to an OpenBSD box. A…

Even better, this device class also covers things like cheap digital "microscopes" and external USB video capture devices. It really simplifies working with those kind of tools.

Re: Driver adventures for a 1999 webcam

#42
Lovely!

I recently picked up a Creative Labs webcam with an LPT and PS/2 connector (probably used for power). I wanted to try it out on a W98 machine, but this inspires me to even try and write a driver for it.

A computer with LPT I have, now i just need to find the time :)

Re: Driver adventures for a 1999 webcam

#43

>This means that all attempts to get data from it using the first USB interface would fail. Now you might ask, why does the webcam have an endpoint with a 0 byte MaxPacketSize on its first interface? Who knows! Paper cuts like this is why the Linux Desktop isn't mainstream.

[deleted]

Re: Driver adventures for a 1999 webcam

#44

There is a lot you can do to improve the quality of the image. This camera has a very early CMOS sensor, which suffered from huge pixel-to-pixel variation. By characterizing each pixel (which you can do by taking dark field and flat field images), you can correct for this variation, and get an image that looks much less noisy. There are also various algorithms to undo the Bayer filtering, with tradeoffs between sharp…

Does pixel-to-pixel variation change based on temperature or some other ambient factor, or would characterization be a one-shot deal?

Re: Driver adventures for a 1999 webcam

#45
post #12

Reminds me when I had to read barcodes from a USB-connected barcode scanner on a Mac. The manufacturer supplied a closed-source library which only supported PPC code and they told me that they lost the source code, so I couldn't easily add intel support. In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoint…

Core memory unlocked. Somewhere deep in the bellows of my electronics pile, I have an ancient HP barcode reader box that plugged inline with an AT keyboard. Into this box plugged a reader pen that you dragged across a barcode.

Once read, it would send the barcode number as keyboard commands. It was a very tactile experience.

Re: Driver adventures for a 1999 webcam

#48
post #44

There is a lot you can do to improve the quality of the image. This camera has a very early CMOS sensor, which suffered from huge pixel-to-pixel variation. By characterizing each pixel (which you can do by taking dark field and flat field images), you can correct for this variation, and get an image that looks much less noisy. There are also various algorithms to undo the Bayer filtering, with tradeoffs between sharp…

Does pixel-to-pixel variation change based on temperature or some other ambient factor, or would characterization be a one-shot deal?

In professional astronomy (where sensors are kept in dewars to reduce dark current) this process (flat field, dark field) is carried out at least once a night.

Re: Driver adventures for a 1999 webcam

#49
post #44

There is a lot you can do to improve the quality of the image. This camera has a very early CMOS sensor, which suffered from huge pixel-to-pixel variation. By characterizing each pixel (which you can do by taking dark field and flat field images), you can correct for this variation, and get an image that looks much less noisy. There are also various algorithms to undo the Bayer filtering, with tradeoffs between sharp…

Does pixel-to-pixel variation change based on temperature or some other ambient factor, or would characterization be a one-shot deal?

It is mostly the dark current (which is reflected in the values you would get if no light is hitting the CMOS sensor) which is affected by temperature. However, its effect scales with the exposure time. Since night time astrophotography requires long exposure times, this would require recalibration (see also @bdigiifh's post). However, for typical daytime use the effect is much less significant.

Some CMOS sensors or the surrounding electronics components on the PCB can heat up significantly while the sensor is in use.

If the sensor has a configurable gain (which is the hardware amplification applied before digitizing the voltage measured for each pixel), then you probably want to characterize the pixel-to-pixel variation for each gain level.

Re: Driver adventures for a 1999 webcam

#50
While Linux support for old hardware tends to be great, lately various kinds of Linux support are suffering in some ways, as higher percentages of software techies are now using Macs and MS Windows.

Add to this many people now going to pains to do open source for closed (and sometimes abusive) platforms, which has network effects, bringing and cementing more techies to closed, and leaving them oblivious to why and how we have the open things we still do.

This also has network effects in removing some hard-earned pressure on hardware developers to cooperate with open platform efforts.

There's an expression about wealth, which I'll rephrase something like: "The first generation earns it, the second generation preserves it, the third generation fritters it away."

There's also an expression: "The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants."

We could avoid a lot of needless abuse in the next several years (and questionable tree-watering), by more of us actively trying to preserve and even improve libre/open platforms now.

Post reply on HN