Pd-dev January 2003

pd-dev@lists.iem.at

33 participants
41 discussions

Re: [PD-dev] [GEM] proposal for color-space handling
by bbogart＠ryerson.ca 17 Jan '03

17 Jan '03

This sounds good to me Chris, good work. Ben ----- Original Message ----- From: chris clepper <cclepper(a)artic.edu> Date: Tuesday, January 14, 2003 9:06 pm Subject: Re: [PD-dev] [GEM] proposal for color-space handling > Hi all > > This is my proposal for how to handle different color-spaces in > GEM. > I'll try to lay it out in a formal, yet concise manner, so we > easily > can discuss the merits of various points. > > 1) Objects that initialize the image rendering chain, like > pix_film > and pix_video, should handle the necessary color-spaces by > creating > image.data buffers in the requested format. These objects will do > all the required decompression and conversion to deliver raw data > in > either RGB or YUV. The user will be able to specify which > color-space by a message to the left inlet or an argument given at > creation. There is a reasonable chance that the API or lib used > by > these objects will not use one of the color-spaces, so in that > case a > conversion will have to be done. > > example of the messages: [colorspace yuv( or [colorspace rgb( > > example code: > if (!strcmp(type->s_name, "rgb")) > m_pixbock.csize = 4; > else if (!strcmp(type->s_name, "yuv")) > m_pixbock.csize = 2; > else > error message > > 2) Pix processing objects will not do any conversions. If an > object > does not support the color-space passed to it, then it will post a > single error message to the console and pass an unmodified buffer > to > the next object. > > example error message: > > "pix_foo: No support for (rgb/yuv) color-space, insert > pix_(rgba/yuv) before this object to convert" > > > 3) There should exist objects (pix_rgba, pix_yuv) for converting > color-spaces to be used in certain special cases. These would be > used before and after objects that don't support a requested > color-space in order to make a functional processing chain. > > 4) Texturing objects should support all available color-spaces. > If > the requested color-space is not possible then conversion is done > in > the object before texturing. This will probably have to happen on > Windows and Linux for YUV at this point, but perhaps future > drivers > will support direct yuv texturing. Perhaps an error could be > posted > alerting the user of this conversion an possible remedy as well. > > 5) The default color-space will be RGBA. The current byte > ordering > will stay the same for 'native' pixel types on Windows and Linux. > OSX will use ARGB for processing and BGRA for texturing as it > currently does. > > The proposed system will allow for the transparent handling of > multiple color-spaces and yet still offeerr user control of the > process. I welcome all comments and opinions on this proposal. > > Thanks > cgc >

3 2

Re: [PD-announce] pdp v0.7
by tigital 17 Jan '03

17 Jan '03

> > btw, i have a color conversion problem >> and as people spoke about YUV/RGB colormaps, >> i may ask for an advice here : >> >> i'm using color conversions from effectv, the formulas are : >> >> /* >> * conversion from YUV to RGB >> * r = 1.164*(y-16) + 1.596*(v-128); >> * g = 1.164*(y-16) - 0.813*(v-128) - 0.391*(u-128); >> * b = 1.164*(y-16) + 2.018*(u-128); >> * conversion from RGB to YUV >> * y = 0.257*r + 0.504*g + 0.098*b + 16 >> * u = -0.148*r - 0.291*g + 0.439*b + 128 >> * v = 0.439*r - 0.368*g - 0.071*b + 128 >> */ >> > >i use exactly the same formula for conversion from the rgb colour model from >v4l and i've noticed some differences too compared to directly capturing in >yuv.. maybe the standard is not that standard? > >this page mentions another formula, along side the one above. maybe you can >try that one? > >http://www.fourcc.org/fccyvrgb.htm > weird... ...I use the following conversions for gamma-corrected RGB and YUV: Y = 0.299R + 0.587G + 0.114B U = -0.147R - 0.289G + 0.436B = 0.492 ( B - Y ) V = 0.615R - 0.515G - 0.100B = 0.877 ( R - Y ) R = Y + 1.140V G = Y - 0.395U - 0.581V B = Y + 2.032U ...of course, it turns out that it all depends on what the original RGB is in, and differs if it's 16-235 or 0-255 per channel, and whether your going for YUV, YCbCr:HDTV (Y709) or YCbCr:SDTV (Y601)...for the record, the effectv conversions are Y601 based, with RGB channels of 0-255... another good reference is: http://www.faqs.org/faqs/graphics/colorspace-faq/ l8r, jamie

6 8

Status request of the jackified versions of pd
by Thomas Charbonnel 16 Jan '03

16 Jan '03

Hi, I'm currently using the fifo based jackified pd version. It works quite well except it can't achieve real low latency operations (I can't use it with frames-per-period under the default 1024 settings). The version I use comes from the CVS devel_0_35 branch. The stable pd version is now 0.36, does a fifo based jackified 0.36 pd version exist ? What is the status of the callback based pd version ? Thanks, Thomas

3 2

import is not that easy...
by Krzysztof Czaja 15 Jan '03

15 Jan '03

hi Miller, hi all, I took binbuf_convert(), and started hacking the import feature of cyclone library. The original routine requires a complete rewrite, being incompatible with newer max patchfiles. It loses lots of objects ('hidden', 'user', data-embedding), which is really bad, because then, even correctly recognized objects are wrongly numbered and connections go to wrong places... Anybody having done or doing anything similar, let me know please! Krzysztof

1 1

Re: [PD-dev] [GEM] proposal for color-space handling
by chris clepper 15 Jan '03

15 Jan '03

Hi all This is my proposal for how to handle different color-spaces in GEM. I'll try to lay it out in a formal, yet concise manner, so we easily can discuss the merits of various points. 1) Objects that initialize the image rendering chain, like pix_film and pix_video, should handle the necessary color-spaces by creating image.data buffers in the requested format. These objects will do all the required decompression and conversion to deliver raw data in either RGB or YUV. The user will be able to specify which color-space by a message to the left inlet or an argument given at creation. There is a reasonable chance that the API or lib used by these objects will not use one of the color-spaces, so in that case a conversion will have to be done. example of the messages: [colorspace yuv( or [colorspace rgb( example code: if (!strcmp(type->s_name, "rgb")) m_pixbock.csize = 4; else if (!strcmp(type->s_name, "yuv")) m_pixbock.csize = 2; else error message 2) Pix processing objects will not do any conversions. If an object does not support the color-space passed to it, then it will post a single error message to the console and pass an unmodified buffer to the next object. example error message: "pix_foo: No support for (rgb/yuv) color-space, insert pix_(rgba/yuv) before this object to convert" 3) There should exist objects (pix_rgba, pix_yuv) for converting color-spaces to be used in certain special cases. These would be used before and after objects that don't support a requested color-space in order to make a functional processing chain. 4) Texturing objects should support all available color-spaces. If the requested color-space is not possible then conversion is done in the object before texturing. This will probably have to happen on Windows and Linux for YUV at this point, but perhaps future drivers will support direct yuv texturing. Perhaps an error could be posted alerting the user of this conversion an possible remedy as well. 5) The default color-space will be RGBA. The current byte ordering will stay the same for 'native' pixel types on Windows and Linux. OSX will use ARGB for processing and BGRA for texturing as it currently does. The proposed system will allow for the transparent handling of multiple color-spaces and yet still offeerr user control of the process. I welcome all comments and opinions on this proposal. Thanks cgc

1 0

Re: [PD-dev] object for motion control
by bbogart＠ryerson.ca 14 Jan '03

14 Jan '03

In case anyone is interested AID is a project I am currently working on and will probably end up writing the PD interface objects for it: www.interaccess.org/aid Ben ----- Original Message ----- From: Frank Barknecht <fbar(a)footils.org> Date: Sunday, January 12, 2003 8:28 am Subject: Re: [PD-dev] object for motion control > Hi, > Julien Jassaud hat gesagt: // Julien Jassaud wrote: > > > Well, if someone is interested in this little device, I can put > up a > > web page decribing it. > > It sounds interesting, my question is: Could this be made two-way? So > that you could build a kind of motor-fader that can control and be > controlled by Pd? > > ciao > -- > Frank Barknecht _ ______footils.org__ > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

3 3

Re: [PD] Gem(lastest cvs) + video + linux
by IOhannes zmoelnig 13 Jan '03

13 Jan '03

Marco Scoffier wrote: > Hello, > > perhaps I have the wrong packages, because the output of ./configure > looks ok: they really seem to be ok. > > checking for png_set_compression_level in -lpng... (cached) yes guess you already removed the config.cache and recompiled. anyhow it did find everything. > but when I go to test the pix_film example I get the error messages as > though pix_film hasn't been compiled properly: > > error: GEM: pix_film: > '/usr/local/share/doc/gem/examples/04.pix/../data/anim-1.mov' does not > appear to be a supported movie > error: GEM: pix_film: > '/usr/local/share/doc/gem/examples/04.pix/../data/alea.mpg' does not > appear to be a supported movie > > > Am I right that pix_film is the object to be used under linux? yes when creating the [pix_film] object the first time it should display the used libraries (like "libmpeg3" ). I guess it does not, meaning that the configuring somehow didn't really do what it should Open the src/Base/config.h file. Edit it as appropriate (set values to one or define them like <conf> #define HAVE_LIBMPEG3_H 1 #define HAVE_MPEG3 </conf> ), similar for quicktime i do know that the configure script + config.h are somehow broken but of course i need time.... > I want frame per frame control of a video file synched with temporal > events. which you should get... mfg.asd.r IOhannes

2 2

bug: streamin13~ for windows
by smoerk 12 Jan '03

12 Jan '03

hi, streamin13~/out13~ does not work very well with pd 0.36 for windows. open streamio13~.pd change [connect foo.com 8008( to [connect localhost 8008(, then connect and disconnect and pd hangs ( stuck on highlighting [disconnect( ) why not rename streamin13~ to streamin~? I think we don't need the object in two versions.

2 7

Re: [PD-dev] object for motion control
by Julien Jassaud 12 Jan '03

12 Jan '03

> Sounds cool. There's a good externals-howto available at: > > http://pd.iem.at/externals-HOWTO/ Arf, it's the one I learned the PD API with... I think I should have pushed my reading a little deeper than the examples :) Reading references is always good... > [pack] likes to output the selector "list", so if you want to > feed [pack]'s output to your object, you need to do something > like: > > class_addlist(servo_class, servo_list); > > in servo_setup() and write a method: > > void servo_list(t_servo *x, t_symbol *sel, int argc, t_atom *argv); > > ... where you can just do some type-checking and call "servo_go()" It works great! Now I can go to sleep! > I've never tried it, but you might be able to do: > > class_addmethod(servo_class, (t_method)servo_go, &s_list, > A_DEFFLOAT, A_DEFFLOAT, 0); > > in servo_setup(), and pass the object pairs of floats: > > [42\ [24\ > | | > [pack 0 0] > | > [servo ...] > > ... providing that every [pack]ed message is interpreted as > a "go" message... I tried this before I knew about class_addlist. It doesn't work. Also tried getsym("list") which, I believe, is the same as &s_list. Your other very easy solution works, of course. How could I have missed it? Ho! I'm tired too :) Well, if someone is interested in this little device, I can put up a web page decribing it. Thanks to all and especialy Bryan, Julien

2 1

object for motion control
by Julien Jassaud 12 Jan '03

12 Jan '03

Hello all, This is my first post to any of the PD lists, so I'll introduce myself a little. I'm a student at the national school of fine arts in Paris. My main interest is in new media. A fellow student introduced me to pure-data. I thought it could be used as a great real time motion control system. So I build a little circuit that contols 32 RC servos through TCP/IP (works really fine) and started to code a PD object that could interface with that circuit. Basically, this object works. I can connect to the circuit and move any of the 32 servos. But to move a servo, I have to send to the object's hot inlet a [go servo_number servo_angle] message. I thought I could use pack to build such a message but I get a: error: servo: no method for 'list' I tried to play a little with class_addmethod, inlet_new and floatinlet_new but to no avail. Can anyone give me a hint to inlet configuration or point me to a good tutorial. I'll attach my code and an example (though it won't work without the circuit). This object is designed for Mac OS X. I think it should also compile on any UNIX system. Thanks, Julien

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev January 2003