> I believe that the API for animated and non-animated should be the same. > This seems to be the most intuitive way to do it. An animated image is > still an image, after all.
The API should be the same, yes. > One way or the other, since there doesn't seem to be a python module to > do these animated formats, someone is going to have to write it. Having > it be seperate from Soya could be good. Having it do non-animated PNG > and JPEG is also good. Heck, PIL being as large as it is, why don't we > target that instead of continuing to use PIL? :-) Because my main target is doing games and 3D engines that work. PIL works well and my previous experiences tell me to avoid to link directly to libPNG. Finally, don't confound ends and means ! > PIL doesn't fit all our needs. Not anymore. So it is a problem. PIL DOES fit our need for images. Video is a different thing. Do you think libPNG support Ogg Theora ? BTW remind what says the "Soya's spirit" about Python module usage (Soya's spirit will soon resurrect at http://home.gna.org/oomadness/en/soya/soyaspirit.html). > I don't think py-theora exists. I would know, check my address ;-) Write it ;-) > I have tried to work with libmng; the MNG format is just soo complicated > with all sorts of variables, it's not just frames with variable delay > between them. > > For this reason, I vote for APNG and maybe, also, Theora support later. I don't know about APNG, but why not ? However, normal PNG should still relies on PIL. BTW you mention GIF, I believe PIL support animated GIF (at least it can generate them). > I propose, given the concern over Soya linking to these image libraries > directly, a small Python module with decode support for (A)PNG and JPEG. > > This module could give stats about a file without doing a full decode > yet then preform the decode when the data is actually to be used and > even provide partially-loaded data if nessesary (to keep fluid animation > if loading new images mid-game) while it loads/decodes it. Using non-encoded image as Soya currently does is not a problem for me. Images are not so big. And, on the other hand, I think it is the reason why Soya-based games start so quickly compared to other games, which is important for rapid development and short edit-run-debug cycles. > Such a module shouldn't take more than a day or two to write. That's still a day lost, and I don't want to suffer again from the same problems we have had previously with libPNG. If you want to develop a new image library for Python, do it but please understand that it is NOT a Soya-related project, and that Soya might or may not use it, and surely won't use it until it would be as stable and well-accepted than PIL. Jiba _______________________________________________ Soya-user mailing list [email protected] https://mail.gna.org/listinfo/soya-user
