[GEM-dev] pix_equal (was Re: new pix_colordetect)

[Ricardo Fabbri]

> 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.