SPC900 discoveries

[JamesF]

[Caveat: I don't understand the data format used between the SPC900 and the PC. What I've worked out here is the best I can understand from the driver code itself.]

A while back I was looking for information on which codec was best for data capture from the SPC900 cameras and found several web pages suggesting that YUY2 (aka YUYV, I believe) was best on the grounds that it generated larger capture files and therefore contains more data.

I've been looking for some Linux-based code that would allow me to take a still image regularly without needing any kind of graphical display and have been struggling to find anything, so I started to think about writing what I wanted myself. As part of that I wrote some code that used the V4L2 interface to probe the available settings and parameters of a webcam.

I was a little surprised when I found when I tested it against the SPC900 that not all the codecs offered by Sharpcap on Windows were available, and not all the frame rates were available at all resolutions, so I began to poke about in the driver code for the Philips cameras to see why.

It appears that the camera hardware itself only supports a single data format at a range of resolutions using four levels of compression (one of which is "none"). I believe the compression algorithm to be a lossy one. Compression becomes required (ie. no compression is not available as an option) if the frame rate at a given resolution goes beyond a certain limit (which varies depending on the resolution, unsurprisingly).

Once received by the driver, the image frame is uncompressed where required and then converted into a frame in the selected format (IYUV/YUY2 etc.) before being delivered to the application. As far as I can see, there's no loss of information after recovery of the uncompressed data and different output formats may just be a convenience, all the uncompressed data being available in each format though perhaps using different amounts of storage.

The part that seems really important to me though is that at VGA resolution (640x480) which is what I assume we're all using, the maximum frame rate for uncompressed data is 15fps regardless of the output format.

So, if you don't want to lose data to compression in your webcam images, it looks like you don't need to worry about what output format you're capturing in, but make sure your frame rate is no higher than 15fps.

James

[si@nite]

Thats intresting James i use an spc 900 , but thought the only uncompressed frame rate was 5fps but find the highest practical frame rate is 15fps otherwise it starts to drop frames which tallys with wot you say, i think it may be time to move on to full blown planetary cam like the imaging source dmk range, Regards SIMON.

[JamesF]

It's possible I'm mis-reading the code. I'm not entirely sure how all of it works I'll have another look.

James

[JamesF]

Hmmm. My original posting is not right. The Linux driver does not even allow selection of a frame rate greater than 15fps with 640x480. Looking at the compressed data size it appears that there just isn't enough compression available to achieve 20fps at that resolution.

In actual fact, *all* the 640x480 frame rates appear to require that the data be compressed. However, the 5fps and 10fps modes support low compression, whereas 15fps only supports medium and high, so it appears to be better to stick to 10fps than drop to 15fps. The "best" uncompressed resolution appears to be 355x288 @ 5fps.

I'd been trying to work this out earlier and had convinced myself I'd got my figures wrong, but as far as I can determine there are 24 bits of information per pixel produced by the camera. At 355x288 and 5fps that requires just over 11.5Mb/s excluding headers and the maximum rate of a USB1 connection is 12Mb/s so it makes sense that it should be the maximum uncompressed resolution/rate. The same figures give a requirement of 35Mb/s for 640x480 @ 5fps, so clearly a fair bit of compression/throwing away of data is required to get that to fit down a link with a third of the capacity. That figure will double for 10fps and triple for 15fps. At 20fps you'd need to be compressing/throwing away data enough to get reduce the data rate by a factor of more than ten. You can see why I start to doubt my figures

Which makes me wonder, what happens in Windows when someone requests a 20fps 640x480 image?

James

[si@nite]

Thanks James, cannot keep up with you on a technical basis you know ya stuff, but thanks for posting a very intresting thread i think your right about the 10fps, its probably the most practical frame rate. Regards SIMON.

[StuW]

Which makes me wonder, what happens in Windows when someone requests a 20fps 640x480 image?

James

Interpolated frames?

[JamesF]

That's what I'm thinking. Which really means it's useless from an imaging point of view, I think.

James

[Gina]

My experience of the SPC900NC is that while it's very sensitive it's also very slow. A few frames per second seems to be all you can get at 640x480 without a lot of compression. I tried it for planetary but it really isn't suitable - you definitely need a USB2 cam. The MS LifeCam is much more suitable - as long as you use a lowish res for high frame rates. I think I worked out that 640x480x30fps was the best you could get. It's quite sensitive enough for planetary and the smaller pixels mean you need less magnification to get a reasonable size image. But I'm hoping to get an IS camera when I can afford it.

[blusky]

I'd say anything below 20fps with at most 3x Barlow requires a decent tracking, no?

[JamesF]

Yes, when you actually do the maths it's amazing that images such as those posted in the planetary imaging forum are possible.

Still, if ebay prices continue to rise for the SPC900, you and I will be able to sell ours and buy one of the IS cameras with the proceeds

James

[Gina]

Yes I agree.

[JamesF]

I'd say anything below 20fps with at most 3x Barlow requires a decent tracking, no?

I only ever use 10fps and often use a 2.5x barlow with an extension to push up the image size, or a 3x barlow. I'm using an EQ3-2 with aftermarket motors that I've polar-aligned, but that's all I have in the way of tracking. I'm not guiding or anything like that. Registax will cope with most things.

Tracking does make it a lot easier to keep the image on the chip though -- it's only about 7mm by 5.5mm.

James