[Bf-python] Blender.Image Function

[Gert De Roost]

I agree, one single method returning a colour vector,
separate RGB is ugly.

And while you're at it, give us setPixelColor(x, y) so
we can start writing a node-based FX-Tree(XSI)-like
compositing engine with effects and blending modes.
Backup original texture, create some IPO's and read
the curves on every FRAMECHANGED, change compositing
parameters... voila, fully animatable texture
manipulation.  Might be little over-ambitious and slow
using Python though.

And Image.Save() of course...

.gert.


--- Stephen Swaney <sswaney at centurytel.net> wrote:

> On Sun, Feb 20, 2005 at 05:01:21PM -0700, Austin
> Benesh wrote:
> > I am writing a patch that many people say is
> needed – it adds three new
> > functions to Blender.Image: 
> > 
> > getPixelColor_G(x, y)
> > 
> > getPixelColor_R(x, y)
> > 
> > getPixelColor_B(x, y)
> 
> In my not-so-humble opinion, a nicer and slightly
> more OO
> interface would be to provide a single method that
> returns
> a list of the values:
> 
> r,g,b = getPixelColor( x, y )
> 
> This would be nicer for treating the pixel as a
> vector in color
> space.  And much less typing and overhead than:
> 
> r = getP_R..
> g = getP_G..
> b = getP_B..
> 
> If you don't want the extra values, you can always
> toss
> them:
> 
> junk, g, junk = getPixelColor()
> 
> But opinions may vary.  Let the debate begin!



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com