[PD] [pdp]/[gridflow] trying to use a webcam

[Roman Haefeli]

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 at 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