[Bf-python] Blender.Image Function

[Austin Benesh]

Thank You! What a pain this has been. I'll post the patch when I've got it
written.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of joeedh
Sent: Monday, February 21, 2005 12:31 PM
To: Blender Foundation Python list
Subject: Re: [Bf-python] Blender.Image Function

Ok, here's what I know:

Each pixel channel (R,B,G,A) is one byte, this is why ->rect is an int* 
, since the four channels combine themselves into one four-byte integer.

So basically, to get a pixel from an image all you have to do is to find 
it's one-dimensional array indice (which I can't remember the formula 
for), then to get the actual color data you cast to a char*.

So, basically the code would be:

char *pixel = (char *) image->rect[some_indice];
return Py_BuildValue("[f,f,f]", ((float)pixel[0])/255, 
((float)pixel[1])/255, ((float)pixel[2])/255);

Remember that it's usually the most convienent to return float colors 
that range between 0 and 1, so to do that you simply divide the color by 
255 (but casting to a float first, *very* important).

HOWEVER: big-endian OS's like OSX may require you to switch the ordering 
of the bytes in the integer. Look at the imbuf code to figure out how to 
do this, and if it's necassary :) .

joeedh

Austin Benesh wrote:

>Ok, but I need help figuring out how to actually access the pixels in the
>Imbuf->rect function. Does anyone know how I might do this? Here's the
code.
>Please tell me what's wrong!
>
>static PyObject *Image_getPixels_g(BPy_Image * self, PyObject *args)
>{
>	PyObject *pyObjImage;
>	PyObject *attr;
>	BPy_Image *py_img;
>	Image *image=self->image;
>	unsigned int u;
>	unsigned int p;
>	int ptr;
>	int x=0;
>	int y=0;
>
>	if( !PyArg_ParseTuple( args, "ii", &x, &y ) )
>		return EXPP_ReturnPyObjError( PyExc_TypeError,
>					      "expected 2 integers" );
>	
>//	py_img = ( BPy_Image * ) self;
>//	image = py_img->image;
>
>	if( !image->ibuf||!image->ibuf->rect )	/* if no image data
>available */
>		load_image( image, IB_rect, "", 0 );	/* loading it */
>		
>	if( !image->ibuf||!image->ibuf->rect )	/* didn't work */
>		return EXPP_ReturnPyObjError( PyExc_RuntimeError,
>					      "couldn't load image data in
>Blender" );
>
>	ptr=(x + y * image->ibuf->x);
>
>	attr = Py_BuildValue( "h", image->ibuf->rect[ptr+1] );
>// testing section	
>//	
>	
>
>	
>
>	if( attr )
>		return attr;
>
>	return EXPP_ReturnPyObjError( PyExc_RuntimeError,
>				      "couldn't get Image.depth attribute"
>);
>};
>
>-----Original Message-----
>From: bf-python-bounces at projects.blender.org
>[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Stephen Swaney
>Sent: Sunday, February 20, 2005 5:58 PM
>To: Blender Foundation Python list
>Subject: Re: [Bf-python] Blender.Image Function
>
>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!
>
>  
>

_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python