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 > _______________________________________________ [email protected] 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
