hi matju
thanks a lot for that info. i get a picture also in gridflow now. a bit confusing is, that if you select [colorspace YUV420P(, you get an error, but you already mentioned that in your post.
without knowing the principles behind the programming of gridflow, it is a pain, that the colorspace conversion ([#yuv_to_rgb]-[#clip]) eats quite a huge amount of cpu without any further processing. here on my pentium m 1.7GHz it is about 30% with 'dim 240 320' and a framerate of 30. again, i don't know the technical details behind the objects i work with, but it seems strange in my eyes, that having to do a conversion in gridflow is the only available option to get a 'normal' looking picture. for many applications it might not be absolutely necassary to do such a conversion. but on the other hand - as far as i can understand - it is not always easy to work in the 'wrong' colorspace, depending on what one wants to do, since a change in the brightness results in a change of the color, is that right?
if only YUV420P is a 'valid' colorspace, why are there others available?
anyway, it works now, so i will stop moaning around...
cheers roman
On Wed, 2006-11-08 at 10:40 -0500, Mathieu Bouchard wrote:
On Wed, 8 Nov 2006, Roman Haefeli wrote:
-logitech quickcam pro 4000
This camera is known to work. Vidéographe-PARC just bought 10 of them for the big pd workshop.
You have to select colorspace YUV420P (even though it complains a bit). You also have to select "transfer read". GridFlow is a little less automatic than I'd like to.
Then you can optionally click the [radio] that enables YUV->RGB conversion, depending on whether you want to work in RGB or in YUV.
Note that GridFlow's YUV is not faster than RGB, supposing that you have to convert to RGB anyway for displaying: selecting YUV420P still feeds you with YUV444 (same data rate as plain RGB) because that's what easy to work with.
I think everybody just uses RGB.
it seems that the according objects in gridflow [#in] overwrite some settings in the cam when instantiated.
If you're using [#in videodev] directly, you may want to have a look in [#camera]; most people use [#camera]. You can do everything with [#in videodev] as [#camera] is just an abstraction around it.
I don't think that [#camera] overwrites settings. [#in videodev] overwrites the minimum possible.
suddenly i don't know what VIDIOCSPICT and VIDIOCGFREQ mean, but it seems that gridflow tries some invalid settings here.
If I recall, VIDIOCSPICT is for setting the colorspace, width, height, etc. GridFlow might be trying RGB even though it's invalid. VIDIOCGFREQ is reserved for devices that have a television input.
anyway, i'd really like to know what these codes like VIDIOCSYNC and such stand for.
They come from /usr/include/linux/videodev.h
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de