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?
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
another useful page for YUV<->RGB is this Intel page which goes through MMX optimization of such conversions.
http://cedar.intel.com/cgi-bin/ids.dll/content/content.jsp?cntKey=Legacy::ir...
daniel
tigital writes:
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?
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,
hi,
sorry, i've tried all these formulas :
/*
- 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
*/
julien from
/* * conversion from YUV to RGB * r = y + 1.403*v * g = y - 0.344*u - 0.714*v * b = y + 1.770*u * conversion from RGB to YUV * y = 0.299*r + 0.587*g + 0.114*b * u = -0.169*r -0.331*g + 0.500*b * v = 0.499*r -0.418*g - 0.081*b */
tigital :
/* * conversion from YUV to RGB * r = y + 1.140*v * g = y - 0.395*u - 0.581*v * b = y + 2.032*u * conversion from RGB to YUV * y = 0.299*r + 0.587*g + 0.114*b * u = -0.147*r - 0.289*g + 0.436*b * v = 0.615*r - 0.515*g - 0.100*b */
without any success, i guess we're trying to convert [0-255] scaled RGB values to BC_YUV420P color model --
any [ more ] hints appreciated here,
sevy/yves
ps : it's not really a serious issue for the color tracker because the tracked color is kept internally as YUV, but i need to convert it in order to display it in Tcl/Tk, so the displayed color is different from the real color that is tracked.
hi,
i was looking at the aa libs and imagining a pdp patch that could control the flow of the ascii data by treating each character as a particle within a 'physical system' [flock, swarm and wave etc]. what do you think? ascii video is a lovely thing, it'd be great to play around with this idea - really taking control of the ascii itself... alternatively a pdp interface to the aa libs itself could be enough, where the output of another pdp instrument is piped out as ascii.
chairs,
julian oliver
hi,
i will surely fancy to add text to video one day and aalib seems a nice candidate ( although i dont know how it works and if it has its own output device ?? ), mm, for now, i must optimize streaming....
cheers,
sevy/yves
delire wrote:
hi,
i was looking at the aa libs and imagining a pdp patch that could control the flow of the ascii data by treating each character as a particle within a 'physical system' [flock, swarm and wave etc]. what do you think? ascii video is a lovely thing, it'd be great to play around with this idea - really taking control of the ascii itself... alternatively a pdp interface to the aa libs itself could be enough, where the output of another pdp instrument is piped out as ascii.
chairs,
julian oliver
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
ooops, my first answer was [ quite ] stupid, now i had a look at aalib and ok, it could render images in ascii art but on its own display and that's not what i'm looking for.
i'm rather interested in a text rendering engine that could be integrated in PDP/PiDiP
but feel free to contribute....
sevy/yves
Yves Degoyon wrote:
hi,
i will surely fancy to add text to video one day and aalib seems a nice candidate ( although i dont know how it works and if it has its own output device ?? ), mm, for now, i must optimize streaming....
cheers,
sevy/yves
delire wrote:
hi,
i was looking at the aa libs and imagining a pdp patch that could control the flow of the ascii data by treating each character as a particle within a 'physical system' [flock, swarm and wave etc]. what do you think? ascii video is a lovely thing, it'd be great to play around with this idea - really taking control of the ascii itself... alternatively a pdp interface to the aa libs itself could be enough, where the output of another pdp instrument is piped out as ascii.
chairs,
julian oliver
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Wed, 15 Jan 2003 18:23:37 +0100 Yves Degoyon ydegoyon@free.fr wrote:
i'm rather interested in a text rendering engine that could be integrated in PDP/PiDiP
hmm i agree, i suppose aalib can only give us a design framework for translating colour sapce in to text. however i haven't seen any direct or --realtime manipulation of the text in aalib, so this would be something that PDP/PiDiP seems better suited to anyway.
christ it would be nice. funny it hasn't cropped up in other projects already.. < nudge >
but feel free to contribute....
hey i'd love to ;) sadly my code is better kept in a box while i come up to speed. we've decided to use pdp in a touring art project later in the year. i look forward to developing for it then.
julian
sevy/yves
Yves Degoyon wrote:
hi,
i will surely fancy to add text to video one day and aalib seems a nice candidate ( although i dont know how it works and if it has its own output device ?? ), mm, for now, i must optimize streaming....
cheers,
sevy/yves
delire wrote:
hi,
i was looking at the aa libs and imagining a pdp patch that could control the flow of the ascii data by treating each character as a particle within a 'physical system' [flock, swarm and wave etc]. what do you think? ascii video is a lovely thing, it'd be great to play around with this idea - really taking control of the ascii itself... alternatively a pdp interface to the aa libs itself could be enough, where the output of another pdp instrument is piped out as ascii.
chairs,
julian oliver
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Thu, 16 Jan 2003, delire wrote:
On Wed, 15 Jan 2003 18:23:37 +0100 Yves Degoyon ydegoyon@free.fr wrote:
i'm rather interested in a text rendering engine that could be integrated in PDP/PiDiP
hmm i agree, i suppose aalib can only give us a design framework for translating colour sapce in to text. however i haven't seen any direct or --realtime manipulation of the text in aalib, so this would be something that PDP/PiDiP seems better suited to anyway. christ it would be nice. funny it hasn't cropped up in other projects already.. < nudge >
Well, GridFlow already has got aalib support in the last release, and the cvs edition of GridFlow now allows more than plain aalib output: you may freeze the display while still rendering in-buffer (option autodraw), you may force display of a frame (option draw), you may take the buffer out of the @out object (option dump), in which case it comes out of outlet 0 in a "TA" color model (one ascii text channel, one attribute channel). That kind of picture may be sent back to the @out object by inlet 0, same as where greyscale pictures would normally enter, except that since they are already in "TA" they need not be converted to it.
I have written a custom object (in Ruby) that performs an effect specific to "TA" pictures, namely, replacing of certain letters in a picture by sentences taken from specified files and sockets. It's used in one of our patches for a show. This one will not be part of the GridFlow distribution though.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Wednesday 15 January 2003 12:54, delire wrote:
hi,
i was looking at the aa libs and imagining a pdp patch that could control the flow of the ascii data by treating each character as a particle within a 'physical system' [flock, swarm and wave etc]. what do you think? ascii video is a lovely thing, it'd be great to play around with this idea - really taking control of the ascii itself... alternatively a pdp interface to the aa libs itself could be enough, where the output of another pdp instrument is piped out as ascii.
i like the idea. i do agree that image<->ascii conversions should be both ways, so separate terminal output could be an additional feature but rendering to image seems like a must.. i could add support for an ascii packet if you want, and help you get started ;)
about the general text rendering support. that would be very nice to have indeed. but i don't really know how to do it.. ghostscript and latex come to mind, but that seems like a big pile of red tape to me..
tom
-
daniel heckenberg -
delire -
Mathieu Bouchard -
tigital -
Tom Schouten -
Yves Degoyon