On Sat, Jan 25, 2003 at 09:36:03AM +0100, Bertrand Lamy wrote: > > I think the most general way for Soya to handle images would be to > > accept strings along the lines of what's made by Image.tostring in PIL > > and Array.tostring in Numerical Python. This would eliminate the need > > for image loading code in Soya. > > I think it's a good idea and me too I was thinking of using the PIL instead of the >SDL image loader > > Do you want me do quickly code that or do you want to try to make it works yourself ?
I have no problem with trying to code it other than I wouldn't know what you'd want to make the API look like. In all of the places that use images in Soya, an image is never actually passed to Soya, it's a filename. It seems like the best thing to do would be to have a Soya image type and a way to convert between it and a string, if you don't want to make it always depend on PIL, say if someone wants to use the SDL image loading routines because they're using Pygame anyway. I think the way to do this is to create a new structure called P3_image in image.c and image.h, containing width, height, type, and GLubyte* pixels. Then create a function called P3_image_from_string (or something) that takes the arguments unsigned char* data, width, height, type, and a flag saying if the data needs to be flipped upside down (I believe this is needed between PIL and OpenGL?). This would copy the string over into the pixels field, making any necessary format conversions. We should probably just focus on supporting the formats OpenGL supports and force the user to do the conversion for us to keep things simple. I think we should do the flipping though because I don't think PIL, and pygame does it. We'll also want a P3_image_free to make it easier to clean up, and so we don't have to change every place that frees an image every time the P3_image structure changes. I notice that there is currently no P3_material_free, and freeing is handled in the Python wrapper, which is probably OK since the Python interface is the only place where that freeing should ever occur, but there *is* a P3_material_new in material.c, so it would kind of make sense to have a P3_material_free and call *that* from the Python wrapper. The Python interface for creating images would accept a string for the format, such as RGB, RGBA, RGBX (for 32 bit padded if OpenGL supports that), etc. Arguments would be just like pygame.image.fromstring: soya.model.image_fromstring (data, size, format, flipped=0), or size could be split into width and height if that's how it's done in other parts of Soya. If you agree that this is the correct way to proceed, I'm definitely willing to code it myself. Just let me know. CVS access would make this easiest for me :) -- Sean Lynch http://sean.lynch.tv/
msg00092/pgp00000.pgp
Description: PGP signature
