Hi...
I've red this thread too late, sorry... I've done the same thing a while ago and I've lost a of of time to convert RGB output from [pix_data] for them to work with canevas...
For the archive, I join my solution... But, it works with pd-extended, not vanilla+GEM only...
Here is the original post : http://lists.puredata.info/pipermail/pd-list/2013-06/103145.html
Sorry "to arrive after the battle"...
°1ivier
Le 08/01/2016 22:58, João Pais a écrit :
Thanks for your help. Here is the resulting patch, pix2canvas. Sooner or later it will join the other abstractions in the jmmmp library.
Best,
Joao
2016-01-01 13:10 GMT+01:00 Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com>:
On Thu, 2015-12-31 at 18:01 +0100, João Pais wrote: > If understandable, I send this patch so that it's possible to see what > I'm doing. > > > The idea is actually to convert a pix into a bunch of canvases, pixel > per pixel - so that a "picture" can be shown on vanilla. Follow the > instructions in the patch, and everything should be clear. > The conversion is done in [pd RGB]. There are 2 versions, but they > have the same output. There are quite a few different color encodings around in Pd world. For the iemguis, there is a difference in encoding between sending a 'color' message and defining a color as creation argument. What you've done works well for sending 'color' messages to canvas, but not as a creation argument. If you want to define a color as creation argument, you have to encode it differently, namely as 6bit-per-channel value. So, instead of multiplying by 255 and powers of 256, you need to multiply by 63 and powers of 64. See attached patch. I guess the reason is a limitation in how Pd displays (and saves) numbers. Although 32-bit float numbers can fully represent 24bit integer numbers, numbers are saved with less precision in pd files (and text files), since they are truncated to 6 digits. This limitation is worked-around by reducing the resolution to 6 bits per channel. The highest number (the one representing white) is -262144. It does not exceed 6 digits and can be stored at full precision. Roman _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list