[Prev][Next][Index][Thread]
Re: load & brightness
> I don't know how standardized you can make it, with different video
> cameras. Different cameras are probably going to be fairly different
> (i.e. resolutions supported, parameters like white bal., etc). This is
> why I suggested using /dev/qc0ctl as the device to set the device
> independant things. Is this the first digital camera driver in Linux? I
> believe it is in FreeBSD (but there is work on drivers for things like
> the Matrox framegrabber?).
The answer to this is "No, not really." Again, the problem appears
to be the lack of any standard. I'm all for defining a standard
interface, and everyone uses that.
Standard IOCTL's, reading the frame buffer, syncing frames, and whatever
else is good in my opinion (oh, oh, here it comes.. ICAM, the Internet
Camera And Motion standard. naahhh.)
For those who don't know, my linux driver uses the following system:
1 ioctl to get everything, 1 ioctl to set everything. I plan to add
seperate brightness, contrast, and white balance controls. Everything
else is best left to be atomic. (ie, change y, you change the x..)
To read a frame from the camera, simply open /dev/quickcam, and read upto
320x240. The act of opening the device takes a scan.
To read another frame, simply fseek to the beginning of the buffer.
fseek past end of the buffer is not allowed.
That's it. Simple, eh? You can do "cat < /dev/quickcam > /tmp/snapshot",
and get a raw file with whatever the default settings of the quickcam are..
Really. You want PGM? Make a /dev/qcpgm, or /dev/qcraw to get PGM, raw..
(note - these don't exist yet, but on my list of things to do...)
I really want to be able to use a seperate program to control the camera
from the program reading the data. That way, on systems with good thread
or multiple processor support, you can maximize the performance..
>
> > Does anyone know if Sun or SGI have already defined a generic set of
> > video camera ioctls? Maybe we can just re-implement their ioctls (if
> > they are sensible) and avoid re-inventing a new set.
>
> This is a good thing to investigate, but the Linux kernel driver already
> has a decent set of stuff defined. Anyone wanna investigate whether or
> not Sun or SGI has a standard for this? (Anyone have access to a IndyCam
> or something?)
>
I thought about it, and thought, and decided it's probably best to
simply define our standard, and make it generic enough to support
video streams over the net, while still supporting simple applications..
What you probably need to standardize is the frame format, and commands
to set things like color, hue, staturation, contrast, brightness, white
balance, picture size, bits per pixel. Transfer mode should be automatic,
based on the hardware on the system (go for the faster possible mode).
I'm game for changing the interface to what is defined. But, I'm not
game for changing it multiple times. Let's get one standard, that _any_
Unix system (BSD, SysV, UnixWare, Solaris x86) can at least support.
(Sorry OS/2 and NT people..) Maybe even get the library and the drivers
to be _one_ package... Pick it up, and the package builds the library,
and then uses THAT to build the driver for your system.. (in fact, One
True Package would be really, really nice..)
>From the looks of it, only about 2-3 hundred quickcams have been sold
because of our efforts.. (just kidding.. that's coming from my ftp
logs..) With the NV stuff, that should, say, triple, right?
--
Thomas Davis | Internet: Thomas.Davis@mnscorp.com
Systems Consultant | Snail Mail: Suite 528
Midwest Network Solutions Corp. | 1941 South 42nd Street
(402) 346-7687 | Omaha, NE 68105-2939
Follow-Ups:
References: