Ok. Do you know what should be done to convert to Pd's rgb format?
I'm pretty sure the 4th value is alpha
Sent from my iPhone
On Dec 31, 2015, at 7:53 AM, João Pais jmmmpais@gmail.com wrote:
Hello list,
I'm trying to use [pix_data] to get the RGB values from an image, and
color a canvas using them. But the results come out a bit weird, as not
all colors match.I can try to some a more detailed patch in a couple of days, but wanted
to ask first the there is any example of how to use the values coming
out of [pix_data]:
- should the gray value be used?
- the middle outlet should send a list of RGB values, but I noticed
that instead a list of 4 values comes out. This isn't documented, what
is the 4th value?Attached are 2 pictures that should exemplifiy the issue:
- rgb.tif - a rgb palette
- rgb-conv.tif - the result after my interpretation of the data
Best,
Joao <rgb.tif> <rgb-conv.tif> _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Well if there are 4x 8 bit values (RGB+alpha) =32 bits trying to be encoded/decoded into a single precision float, there will be loss of fidelity.
It amazes me that it works for encoding 24 bit values (I tested it for RGB only and can send a demo patch, or check the one Katja posted here: http://lists.puredata.info/pipermail/pd-list/2015-12/112694.html )
Check out Katja's page and video about "Pd Double" for the best explanation of this problem.
I personally wish there was a 32 bit integer data type in Pd for counters and binary registers and such, which I know will never get converted into floats, and risk strange rounding errors or noise in the Least Significant Bits.
On Thursday, December 31, 2015, João Pais jmmmpais@gmail.com wrote:
Ok. Do you know what should be done to convert to Pd's rgb format?
I'm pretty sure the 4th value is alpha
Sent from my iPhone
On Dec 31, 2015, at 7:53 AM, João Pais jmmmpais@gmail.com wrote:
Hello list,
I'm trying to use [pix_data] to get the RGB values from an image, and
color a canvas using them. But the results come out a bit weird, as not all colors match.
I can try to some a more detailed patch in a couple of days, but wanted
to ask first the there is any example of how to use the values coming out of [pix_data]:
- should the gray value be used?
- the middle outlet should send a list of RGB values, but I noticed
that instead a list of 4 values comes out. This isn't documented, what is the 4th value?
Attached are 2 pictures that should exemplifiy the issue:
- rgb.tif - a rgb palette
- rgb-conv.tif - the result after my interpretation of the data
Best,
Joao <rgb.tif> <rgb-conv.tif> _______________________________________________ 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
You're making a jump from "iemgui has a lossy color representation" to "Pd's float precision is a problem". Both may be true, but they aren't related. Pd has symbols, which are capable of losslessly storing rgb color values in any of the standard forms you see on the web (#abc, #abcdef, blue, etc.). Additionally, Pd messages are capable of losslessly storing rgb color values (as well as just about any other color format).[foreground 80 160 240( is a valid Pd message, as is [background 1 2 3( or [fill 42 42 42(. Also, notice that the lossy, human-unreadable iemgui color representation isn't a standard format, and that this thread is six levels deep. Those two facts are definitely related. -Jonathan
On Thursday, December 31, 2015 10:55 AM, William Huston <williamahuston@gmail.com> wrote:
Well if there are 4x 8 bit values (RGB+alpha) =32 bits trying to be encoded/decoded into a single precision float, there will be loss of fidelity.
It amazes me that it works for encoding 24 bit values (I tested it for RGB only and can send a demo patch, or check the one Katja posted here: http://lists.puredata.info/pipermail/pd-list/2015-12/112694.html )
Check out Katja's page and video about "Pd Double" for the best explanation of this problem.
I personally wish there was a 32 bit integer data type in Pd for counters and binary registers and such, which I know will never get converted into floats, and risk strange rounding errors or noise in the Least Significant Bits.
On Thursday, December 31, 2015, João Pais jmmmpais@gmail.com wrote:
Ok. Do you know what should be done to convert to Pd's rgb format?
I'm pretty sure the 4th value is alpha
Sent from my iPhone
On Dec 31, 2015, at 7:53 AM, João Pais jmmmpais@gmail.com wrote:
Hello list,
I'm trying to use [pix_data] to get the RGB values from an image, and color a canvas using them. But the results come out a bit weird, as not all colors match.
I can try to some a more detailed patch in a couple of days, but wanted to ask first the there is any example of how to use the values coming out of [pix_data]:
- should the gray value be used?
- the middle outlet should send a list of RGB values, but I noticed that instead a list of 4 values comes out. This isn't documented, what is the 4th value?
Attached are 2 pictures that should exemplifiy the issue:
- rgb.tif - a rgb palette
- rgb-conv.tif - the result after my interpretation of the data
Best,
Joao <rgb.tif> <rgb-conv.tif> _______________________________________________ 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
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.
Best,
Joao
You're making a jump from "iemgui has a lossy color representation"to
"Pd's float precision is a problem".Both may be true, but they aren't related. Pd has symbols, which are
capable oflosslessly storing rgb color values in any of the standard forms you see
on the web (#abc, #abcdef, blue, etc.). > Additionally, Pd messages are
capable of losslessly storing rgb color values (as well as just about
any other color >format). [foreground 80 160 240( is a valid Pd message, as is [background 1 2 3(
or[fill 42 42 42(.Also, notice that the lossy, human-unreadable iemgui color
representation isn'ta standard format, and that this thread is six levels deep. Those two
factsare definitely related.-Jonathan
On Thursday, December 31, 2015 10:55 AM, William Huston
williamahuston@gmail.com wrote:Well if there are 4x 8 bit values (RGB+alpha) =32 bits trying to be
encoded/decoded into a single precision float, >there will be loss of
fidelity. It amazes me that it works for encoding 24 bit values (I tested it for
RGB only and can send a demo patch, or check >the one Katja posted here:
http://lists.puredata.info/pipermail/pd-list/2015-12/112694.html )Check out Katja's page and video about "Pd Double" for the best
explanation of this problem. I personally wish there was a 32 bit integer data type in Pd for
counters and binary registers and such, which I know >will never get
converted into floats, and risk strange rounding errors or noise in the
Least Significant Bits.On Thursday, December 31, 2015, João Pais jmmmpais@gmail.com wrote:
Ok. Do you know what should be done to convert to Pd's rgb format?
I'm pretty sure the 4th value is alpha
Sent from my iPhone
On Dec 31, 2015, at 7:53 AM, João Pais jmmmpais@gmail.com wrote:
Hello list,
I'm trying to use [pix_data] to get the RGB values from an image, and
color a canvas using them. But the results >come out a bit weird, as
not all colors match.I can try to some a more detailed patch in a couple of days, but
wanted to ask first the there is any example of >how to use the
values coming out of [pix_data]:
- should the gray value be used?
- the middle outlet should send a list of RGB values, but I noticed
that instead a list of 4 values comes out. This >isn't documented,
what is the 4th value?Attached are 2 pictures that should exemplifiy the issue:
- rgb.tif - a rgb palette
- rgb-conv.tif - the result after my interpretation of the data
Best,
Joao <rgb.tif> <rgb-conv.tif> _______________________________________________ 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
May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
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
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:
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 mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
On 01/11/2016 10:54 PM, Olivier Baudu wrote:
I've lost a of of time to convert RGB output from [pix_data] for them to work with canevas...
for what it is worth: all the help-patches for the iemguis include a subpatch that will turn a set of RGB values (0..255) into that weird color-format. so the conversion between [pix_data] and canvas-colors should be mostly copy-and-paste.
But, it works with pd-extended, not vanilla+GEM only...
i wonder why...and see that you are using [once], [repeat] and [counter] [once] and [counter] should be trivial to replace by tiny subpatches. and [repeat] can be replaced by [until] in this specific usecase.
fmarsd IOhannes
On Mon, 2016-01-11 at 23:07 +0100, IOhannes m zmölnig wrote:
On 01/11/2016 10:54 PM, Olivier Baudu wrote:
I've lost a of of time to convert RGB output from [pix_data] for them to work with canevas...
for what it is worth: all the help-patches for the iemguis include a subpatch that will turn a set of RGB values (0..255) into that weird color-format.
This is true for the color format used in the 'color' method of the iemguis. And this method also allows to create pure white. The original poster asked about "the other" color format used in iemguis, the one based on 6-bit per channel used as creation argument. He tried the approach from the help-file, but got weird results.
Roman
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.
It's probably worth explaining why you say "the one representing white" and not simply "white". (I.e., what every other sane color format calls "white" does not equal what iemgui's file color format calls -262144.) -Jonathan
On Sun, 2016-01-10 at 22:08 +0000, Jonathan Wilkes wrote:
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.
It's probably worth explaining why you say "the one representing white" and not simply "white".
Oh, I'd attribute this to my tendency to sometimes express things too verbosely.
(I.e., what every other sane color format calls "white" does not equal what iemgui's file color format calls -262144.)
I wasn't thinking of that, but you're right. It's not possible to create white (as in #ffffff) iemguis dynamically. If one needs white, one needs to set the color by message. But still when you save it in the patch, it won't be white on the next patch load.
Roman
What I mean is that iemgui color format is so complicated and difficult to understand, saying "represents white" is probably the most accurate way to explain how that number maps to a human readable color. On the bright side, this thread has convinced me not to add an animation api in my GUI port. While I think it would serve my own peculiar interests just fine, I really don't understand the implications for more sophisticated use-cases. (And I can easily imagine a user getting stuck because I didn't consider the downsides of my approach.) -Jonathan
On Monday, January 11, 2016 3:08 AM, Roman Haefeli <reduzent@gmail.com> wrote:
On Sun, 2016-01-10 at 22:08 +0000, Jonathan Wilkes wrote:
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.
It's probably worth explaining why you say "the one representing white" and not simply "white".
Oh, I'd attribute this to my tendency to sometimes express things too verbosely.
(I.e., what every other sane color format calls "white" does not equal what iemgui's file color format calls -262144.)
I wasn't thinking of that, but you're right. It's not possible to create white (as in #ffffff) iemguis dynamically. If one needs white, one needs to set the color by message. But still when you save it in the patch, it won't be white on the next patch load.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/11/2016 09:31 PM, Jonathan Wilkes via Pd-list wrote:
What I mean is that iemgui color format is so complicated and difficult to understand, saying "represents white" is probably the most accurate way to explain how that number maps to a human readable color.
i took this conversation as a trigger to finally implement symbolic names for the iemguis:
https://sourceforge.net/p/pure-data/patches/569/
as far as possible, it's backwards compatible (that is: patches saved with old Pds can be read; patches saved with new Pds can be forced into legacy mode).
it should make naming colors much more easy.
gmards IOhannes