Hi,
following up on the color classification thread, I had promised a pix_equal object to mark the pixels that are equal to a given RGBA value/range. It is quite useful in the present form; perhaps another solution could be sought for the long term, but for now this does a useful job, in particular being required to decode the output of pix_colorclassify. pix_bitmask doesn't work for this, as what I need is an "and" interval test on all RGBA channels.
The code for pix_equal and its documentation is are in the 'pix_equal_new' branch at this repo: git://github.com/rfabbri/Gem.git
I rebased the branch on the latest Gem git master branch.
I look forward to your feedback on this simple object, and your opinion about incorporating it into Gem. Ricardo Fabbri -- Linux registered user #175401 www.lems.brown.edu/~rfabbri pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net
2011/11/14 IOhannes zmölnig zmoelnig@iem.at:
On 11/14/2011 06:30 PM, Ricardo Fabbri wrote:
That will come with a later contribution. I wrote a [pix_equal] external which can change any pixels "equal" to some value within a given cosed r & g & b range. I use it to separate the colors into different images, change the color label, etc.
actually, i think what we really would need was a (high-performant, jit-compiled) [pix_expr] object, that would allow to create such objects in Pd space rather than in C++ space.
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi,
just a sample of the tracking that the proposed [pix_equal] allows:
Let me know if this simple object should be included in Gem. Best, Ricardo Fabbri -- Linux registered user #175401 www.lems.brown.edu/~rfabbri pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net
2012/2/24 Ricardo Fabbri rfabbri@gmail.com:
Hi,
following up on the color classification thread, I had promised a pix_equal object to mark the pixels that are equal to a given RGBA value/range. It is quite useful in the present form; perhaps another solution could be sought for the long term, but for now this does a useful job, in particular being required to decode the output of pix_colorclassify. pix_bitmask doesn't work for this, as what I need is an "and" interval test on all RGBA channels.
The code for pix_equal and its documentation is are in the 'pix_equal_new' branch at this repo: git://github.com/rfabbri/Gem.git
I rebased the branch on the latest Gem git master branch.
I look forward to your feedback on this simple object, and your opinion about incorporating it into Gem. Ricardo Fabbri -- Linux registered user #175401 www.lems.brown.edu/~rfabbri pt.wikipedia.org/wiki/IPRJ labmacambira.sf.net
2011/11/14 IOhannes zmölnig zmoelnig@iem.at:
On 11/14/2011 06:30 PM, Ricardo Fabbri wrote:
That will come with a later contribution. I wrote a [pix_equal] external which can change any pixels "equal" to some value within a given cosed r & g & b range. I use it to separate the colors into different images, change the color label, etc.
actually, i think what we really would need was a (high-performant, jit-compiled) [pix_expr] object, that would allow to create such objects in Pd space rather than in C++ space.
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-01 01:36, Ricardo Fabbri wrote:
Hi,
just a sample of the tracking that the proposed [pix_equal] allows:
Let me know if this simple object should be included in Gem.
i'm still reluctant to include "random" simple objects into streamline Gem. in the given case i will most likely include it, but be prepared that once i find a decent [pix_expr] implementation that object will be replaced by an abstractions. not a bit deal, i guess :-)
also, i'd like to point to the existance of frei0r and FreeFrame-1.0 plugins, that would allow you to write code once for a large number of hosts, and which integrate seemlessly into Gem as well - at least for algorithms that don't do any fancy analysis which has to be output in non-pix form (like [pix_multiblob])
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-01 09:25, IOhannes m zmoelnig wrote:
i'm still reluctant to include "random" simple objects into streamline Gem. in the given case i will most likely include it, but be prepared that once i find a decent [pix_expr] implementation that object will be replaced by an abstractions. not a bit deal, i guess :-)
so i did include the object, with a noteable modification: color ranges in Gem are always normalized! e.g. it should be "1 1 1 1" rather than "255 255 255 255".
this change will break your (riccardo's) patch, so take care!
PS: [pix_equal] could have been done with [pix_curve] and is virtually identical to [pix_alpha]
vhmysdr IOhannes
i'm still reluctant to include "random" simple objects into streamline Gem. in the given case i will most likely include it, but be prepared that once i find a decent [pix_expr] implementation that object will be replaced by an abstractions.
I agree. I am still not in peace with the fact that any little pixel operation in Pd has to be written in C++, or else expressed in a combination of objects as if they were weird symbols in a high level messy language. You have to really know each pix_ object and express your idea in that irregular language. Only to realize that it can't be expressed in this language, and only then you write your simple C++ loop. This must be a sign that something is not right with the approach, or that this is just an expected drawback of the Pd paradigm. I'm not sure as I am not that experienced with Pd, but I've been willing to live with that drawback anyways. Not sure how the high number of users that are not familiar with C++ deal with this drawback/frustration.
Regarding the normalization of color to the 0-1 range, I was aware of it, but was not comfortable adhering to it in practice, since in the [pix_equal] case any round-offs may cause you pick out the wrong pixels. [pix_equal] needs to be precise, I want pixels with R=156 and *not* R=155. Worse, even: if you want R=0 and, after normalizations and denormalizations you get back to, say R=0.00001, you won't pick out any R=0 pixels. I actually faced that issue when I was writing [pix_equal].
Integers are very good for this situation. Moreover, I have seen other pix_* objects use the 0-255 range. Could we keep it not normalized?
also, i'd like to point to the existance of frei0r and FreeFrame-1.0 plugins, that would allow you to write code once for a large number of hosts, and which integrate seemlessly into Gem as well - at least for algorithms that don't do any fancy analysis which has to be output in non-pix form (like [pix_multiblob])
This is very interesting! I was aware of frei0r but didn't think the approach went beyond just algorithms useful for visual effects (filters for VJ and video editing software). I will keep this in mind.
-
IOhannes m zmoelnig -
Ricardo Fabbri