next try ;D
What is the exact part number of your camera and where can we buy one? Or maybe we can borrow yours!
I have three cameras :
creative live!cam sync which is not working, but driverless. it is not possible to detect the video formats from your usbhost driver.
[url]http://de.store.creative.com/kameras/live-cam-sync/218-19046.aspx[/url]
older creative live!cam, from 2008, i’ve made the picture with this one, but no more available, it seems that this one is a new version :
[url]http://de.store.creative.com/kameras/live-cam-chat-im-vf0530/218-18083.aspx[/url]
speedlink ‘Case Online Communication Set’, slower than the creative but with the same picture quallity, same wrong colours :
[url]speedlink
it is no problem to borrow you mine, but keep in mind, i’m from germany.
i could send you protocols from uvcview of all three cameras too.
cu
Andreas
Thanks, will forward to the right people to look into it.
I am not the Webcam expert. but since you are in Germany and it is usually PAL system. not NTSC like in US. Could this be the reason the colors are not OK? I am just wondering.
I do not think there is “PAL” or “NTSC” in USB webcam world but I could be wrong. This question is probably answered by Mike.
No, it don’t belongs to any tv standart.
For me it is a conversation problem of the YUV format to Bitmap.
I have seen these problems in my work at a MI0283QT_2 Display.
cu
Andreas
I do not have any color problem or what so ever.
Colors are very good and I don’t think they can get any better.
I took a look at the image formats again (because of the shattered image).
The following formats are supported:
-320240
-160120
What I’ve noticed is that it takes a long time to get a new image on 320*240.
When it finally got a new image, the image looks like this:
When I use the 160*120 format, the images are constantly ready and are sent to the display.
The image looks fine and the colors are too.
What is going on?
This is what it looks like on 160*120 format: (it’s a chair)
The test result with chipworkx are the same:
320*240:
160*120:
We have to order a camera to see the color problem.
@ Robert Jacobs
What is your camera so we can get one and try it?
@ Mike: This one:
Performance issues?
I have been working with a Logitech Pro 9000 camera and a FEZ Cobra.
I decided to write a program to read an image from the camera and send it to a windows client via UDP.
Just reading from the camera and displaying to the LCD I was seeing about five frame per second. I consider this to be a good number.
I then added code to convert the LCD bitmap to bitmap file format using the new routine in the Util library and then send it to the PC GUI client in 1024 UDP packets. I was seeing a rate at the PC of less than 1 frame per second.
I then did some timing analysis to see if I could find where the delays were occurring.
I was seeing BitMap to bitmap file conversion times of 450 to 650 milliseconds for the small and large images from the camera.
I then measured the UDP send byte rate and was seeing about 35KBS. This I felt this was slow.
This will be a busy week for me, so I will not be able to do any further analysis, but I wanted to post the results of my testing in case it will help. I will try to do some further analysis time permiting.
I am just guessing, but I suspect that the USB polling to the camera is consuming a lot of the CPU resource and impact the file conversion and UDP send rate.
UDP should be much faster than what you are seeing!
[quote]UDP should be much faster than what you are seeing!
[/quote]
That’s what I thought also.
Has GHI done any measurements on the overhead of video capture?
Try to stop the camera streaming first:
start streaming.
Get the image.
Stop camera streaming.
convert and transfer over UDP.
Hi Mike:
The idea of stopping streaming after capturing an image did occur to me, and is something I will try.
I don’t have great expectations though…
It seems to me that it takes a long time to acquire the first image after the start of streaming.
But, I will try…
Maybe I have found an excusefor a ChipWorkX?
It is normal for the first image to take some time. The camera has to get ready first. This is the same as desktop.
It is normal to get lower frame rates on the camera. This is because of the USB full speed connection. So it will the same as ChipworkX or even PC running a full speed connection (not high speed usb).
ChipworkX will be faster when converting the image. But the video streaming in the background takes a lot of processing. Disable it and try converting again. It should be faster.
Mike:
Based upon your suggestion, I changed my capture program to start and stop image capture for frame.
Shutting off image capture gave about a 4X improvement on BitMap->.BMP and around the same for the UDP sending rate.
But… I am only able to capture one frame… When I try to start capture for the second time I get an exception.
To isolate the problem I developed a simple program where I could switch between continuous capture and start/stop capture. I now have a program which is repeatable.
Before I post the code, I want to try running with an external power supply to insure I am not having a power issue.
While I suspect the issue is related to this camera or power supply, I wanted to ask if during the GHI testing you had verified that the start/stop mode of image capture is working…
BTW, I am now get about 14 frames/second duringcontinuous capture.