chris clepper wrote:
someone brought up the issue of using float vs int arguments to the pix_ objects, but i can't find the mail right now.
that was me. i think it was in a personal email to you.
be used. the exact RGB or YUV integer value in certain objects is much more precise than using a float
true
and it saves conversions.
well, i guess one conversion per processing a whole picture (or better: one conversion when setting a value) is not that bad.
right, but my point is more about precision and ease of use. i'm about to commit [pix_chroma_key] which has R G B (or Y U V) for the key value as an int, which makes more sense to use than a float. to my mind it's easier to work with R=100 G=10 B=135 rather than figure out the percentage 135 is of 255. of course you can add a few [/ 255] before the object but that seems like a wasteful method. also, i'm working on some objects that move pixels around in various ways and it's just insane to use a float 0..1 to describe a 4:3 image. you'll go mad trying to keep the numbers straight (in fact, GL is now moving away from float texture mapping to int).
an object like [pix_offset] should use integer arguments rather than floats for example.
int is surely the "right" way. but i though it more convenient to use floats (0..1) which "maps" automagically to ints when using negative numbers (-1 .. -255). But of course, that's not correct in mathematical terms....
i do think that floats make sense for most objects and in GEM as a whole since both audio and GL use floats. but there are certain cases where ints work better than floats.
and then we have all these compatibility issues with old patches...
good point, so maybe there really is no need to change existing objects. in fact, [pix_offset] might work just as well using floats since it does make sense to subtract 6% from blue or add 15% to red, etc. so just new objects need to have the option of using ints as arguments? it really makes using some of the objects i'm working on a whole lot easier..
cgc
mfg.ads.r IOhannes