Re: [Gimp-developer] script fu and image file support?
On 8/25/05, Leon Brooks [EMAIL PROTECTED] wrote: You can build PPC and PPC64 binaries. I think you'd need eitehr a real machine or a good emulator to actually thest them. I think I agree (with an added caveat that cross compiling environments are not always trivial to work with). Thanks! (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Friday 26 August 2005 03:36, woc wrote: On 8/25/05, Leon Brooks [EMAIL PROTECTED] wrote: You can build PPC and PPC64 binaries. I think you'd need eitehr a real machine or a good emulator to actually thest them. I think I agree (with an added caveat that cross compiling environments are not always trivial to work with). On Mandriva Linux, at least, installing the targets for each architecture is a one-liner, and using them is a single compiler option. Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/Member, Linux Australia ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
Hi, woc [EMAIL PROTECTED] writes: Can someone point me at: * gimp 2.2 load/save support for some type of file written in script-fu? Or, * a concise reference work describing the data types I'd need to deal with and their fundamental support routines? Or, * a faq which is specific to this topic (script fu support for load/save)? Or, Script-Fu isn't designed to access images at the pixel level. It is probably not impossible to write an image loader in Script-Fu but it would be teribly slow. In other words, I wouldn't even attempt to do that. C is a very portable language, I don't understand why you aren't willing to use it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/23/05, woc [EMAIL PROTECTED] wrote: I do not want to write a .c plugin, because portability is more important to me than speed. Gimp itself is written in some variant of C, isn't it? The only portability issue here is that you'd need to compile it on all target OS's. No big deal -- that's how GIMP is made anyways. Use MinGW for Windows, and Linux uses the GCC and related tools. Easy enough. Script-Fu only has the advantage of not requiring compilation before execution, but it doesn't handle Raw IO or pixel-based image creation IIRC (for good reason, too, proally). Perl probably has similar limitations, to a certain extent. Perl handles text best -- binary data, it's best at simply passing... I believe the term is ad verbatim or something. Try copying a C image format plugin that already exists, maybe (e.g. xbm)? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wednesday 24 August 2005 15:48, michael chang wrote: On 8/23/05, woc [EMAIL PROTECTED] wrote: I do not want to write a .c plugin, because portability is more important to me than speed. Gimp itself is written in some variant of C, isn't it? Right. ANSI C 89' with some extensions that are common enough to rely on. The only portability issue here is that you'd need to compile it on all target OS's. No big deal -- that's how GIMP is made anyways. Use MinGW for Windows, and Linux uses the GCC and related tools. Easy enough. Right. Script-Fu only has the advantage of not requiring compilation before execution, but it doesn't handle Raw IO or pixel-based image creation IIRC (for good reason, too, proally). You can theoretically draw on an image using a 1*1 pixels brush. But this would be very slow. Perl probably has similar limitations, to a certain extent. Perl handles text best -- binary data, it's best at simply passing... I believe the term is ad verbatim or something. While Perl has many facilities for handling text very well, it does not have any limitations with handling binary data. It can easily segment such data, convert it from ASCII to binary, generate it, etc. Perl strings can contain \0 characters, and thus can represent binary data. Several functions in the perlfunc man page can be used to manipulate binary data (like pack() and unpack()), and often text-oriented functions that are operated on binary data will also work. A similar functionality should be available for programming languages that are similar to Perl. The main problem with using Perl for this job is that processing thousands or millions of Pixels in Perl may be considerably slower than in C, due to the fact executing expressions, conditionals and loops in Perl has much more speed overhead over their C counterparts. Thus, it is recommended to write an image loader in C. But handling binary data alone is not the problem here. It is not harder in Perl than in C, albeit may be (like many other tasks) slower. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Tcl is LISP on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, michael chang [EMAIL PROTECTED] wrote: The only portability issue here is that you'd need to compile it on all target OS's. No big deal -- that's how GIMP is made anyways. Use MinGW for Windows, and Linux uses the GCC and related tools. Easy enough. Which means I'd have to mess around with getting access to the right development environment every time I needed to make a change. (And I do anticipate needing to make changes.) Script-Fu only has the advantage of not requiring compilation before execution, but it doesn't handle Raw IO or pixel-based image creation IIRC (for good reason, too, proally). Perl probably has similar limitations, to a certain extent. Perl handles text best -- binary data, it's best at simply passing... I believe the term is ad verbatim or something. So it takes a second or two to convert an image using perl. Longer if it's a format varient where pixels adjacent visually aren't stored adjacent to each other, or some of those format variants. This costs what, a few minutes out of a day? Anyone using this image format is going to have to spend considerably longer than that just to load it into the environment which uses these images. Speed is not one of my priorities. Simplicity is. Try copying a C image format plugin that already exists, maybe (e.g. xbm)? BMP and TGA are closer than XBM (all the image formats are binary pixel formats with a short header at the front. Some of the details can get strange, but those tend to be issues unique to this format.) But I'll take a look at XBM to see if it deals with multiple layers. Sure, GIMP is written using C, but I'm not planning on building or distributing the GIMP. I suppose I can try doing this in C, but shudder at the time I'm going to have to spend, building and maintaining those binaries. (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Shlomi Fish [EMAIL PROTECTED] wrote: While Perl has many facilities for handling text very well, it does not have any limitations with handling binary data. It can easily segment such data, convert it from ASCII to binary, generate it, etc. Perl strings can contain \0 characters, and thus can represent binary data. Several functions in the perlfunc man page can be used to manipulate binary data (like pack() and unpack()), and often text-oriented functions that are operated on binary data will also work. A similar functionality should be available for programming languages that are similar to Perl. The main problem with using Perl for this job is that processing thousands or millions of Pixels in Perl may be considerably slower than in C, due to the fact executing expressions, conditionals and loops in Perl has much more speed overhead over their C counterparts. Thus, it is recommended to write an image loader in C. But handling binary data alone is not the problem here. It is not harder in Perl than in C, albeit may be (like many other tasks) slower. Exactly. I'm using pack, unpack and substr in perl. This works quite well. And slower means a second or two instead of a fraction of a second. For what I'm dealing with, this is a minor issue. My interest is in breaking new ground. There's sometimes other people who are happy to write and support fast C code -- they sometimes use what I've written as a design basis, and more power to them. That's less maintenance work for me. But I'm guessing what people are saying is that even with the gimp bindings, SIOD doesn't have enough relevant type punning features, so it'll be considerably slower than using perl to just write a different kind of image file. In other words, I can't use the everything is a sequence of bytes mechanism for representing image data? (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wed, Aug 24, 2005 at 12:58:35PM -0400, woc wrote: On 8/24/05, michael chang [EMAIL PROTECTED] wrote: Perl probably has similar limitations, to a certain extent. Perl handles text best -- binary data, it's best at simply passing... I believe the term is ad verbatim or something. So it takes a second or two to convert an image using perl. Longer if it's a format varient where pixels adjacent visually aren't stored adjacent to each other, or some of those format variants. This costs what, a few minutes out of a day? Anyone using this image format is going to have to spend considerably longer than that just to load it into the environment which uses these images. Speed is not one of my priorities. Simplicity is. You can use Perl or Python to write a file format plugin. Script-fu is a nonstarter, there's no way to register a load/save handler from a script (though there could be in the future). Script-fu sucks for this for other reasons, as others have told you already. You can actually do things with reasonable efficiency in both Perl and Python, since you get the pixel region abstraction just as you do in C. There's a save plugin example that comes with both the Perl and Python bindings. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: You can use Perl or Python to write a file format plugin. Script-fu is a nonstarter, there's no way to register a load/save handler from a script (though there could be in the future). Script-fu sucks for this for other reasons, as others have told you already. You can actually do things with reasonable efficiency in both Perl and Python, since you get the pixel region abstraction just as you do in C. There's a save plugin example that comes with both the Perl and Python bindings. Hmm... in my opinion C is more portable than perl or python, in the context of the gimp. If the standard gimp distribution contained those bindings, I'd probably think differently. But thanks for the suggestion! (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wed, Aug 24, 2005 at 01:49:50PM -0400, woc wrote: On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: You can use Perl or Python to write a file format plugin. Script-fu is a nonstarter, there's no way to register a load/save handler from a script (though there could be in the future). Script-fu sucks for this for other reasons, as others have told you already. You can actually do things with reasonable efficiency in both Perl and Python, since you get the pixel region abstraction just as you do in C. There's a save plugin example that comes with both the Perl and Python bindings. Hmm... in my opinion C is more portable than perl or python, in the context of the gimp. If the standard gimp distribution contained those bindings, I'd probably think differently. Well, the python bindings are disted with GIMP, though not on Windows. This will change with GIMP 2.4 though. If you care about Windows, you should've said so from the beginning. ;) You're basically stuck with C for 2.2, script-fu won't cut it. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Wed, Aug 24, 2005 at 02:34:28PM -0400, woc wrote: On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: Well, the python bindings are disted with GIMP, though not on Windows. This will change with GIMP 2.4 though. If you care about Windows, you should've said so from the beginning. ;) You're basically stuck with C for 2.2, script-fu won't cut it. ... and I was almost sure I mentioned that portability is a priority for me. I apologize for failng to ennumerate the current and potential future platforms I might hope to let people use. /wry Yeah, and you contradicted this statement when you said that C wasn't portable enough for you. There are differing definitions of what portability means. Oh well, looks like C it is, with all the non-portability that implies. I was hoping for more generic abstractions. You could patch script-fu to do what you want, or you could deploy pygimp or gimp-perl to your users, since they are running a custom app anyway... It's up to you how much you want to constrain yourself. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: Yeah, and you contradicted this statement when you said that C wasn't portable enough for you. There are differing definitions of what portability means. C is definitely less portable than I'd like. Unfortunately, it looks like it's as portable as I'm going to get unless I abandon the gimp entirely or wait a few years for a better version. (Which I might, but I'll try following your recommendations first. I just wanted to make sure my priorities were understood before I jumped in blind.) I really do appreciate you helping me get oriented. That is quite useful -- I'm sure you've saved me days or weeks of searching the docs for how to make script fu work when basically I would have been wrong to try that route. (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: Well, the python bindings are disted with GIMP, though not on Windows. This will change with GIMP 2.4 though. If you care about Windows, you should've said so from the beginning. ;) You're basically stuck with C for 2.2, script-fu won't cut it. ... and I was almost sure I mentioned that portability is a priority for me. I apologize for failng to ennumerate the current and potential future platforms I might hope to let people use. /wry Oh well, looks like C it is, with all the non-portability that implies. I was hoping for more generic abstractions. Thanks! (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, woc [EMAIL PROTECTED] wrote: On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: Yeah, and you contradicted this statement when you said that C wasn't portable enough for you. There are differing definitions of what portability means. C is definitely less portable than I'd like. I presume you mean this in the sense that you'd want to write it and distribute it as-is for your users in this cases? If you want, you can always cross compile for Windows on a Linux system, and develop on Linux. (Not sure about vice-versa.) Mac OS X, IIRC, comes with a compiler; Linux might, if you specify it, but various people use deb binaries or rpms. *sighs* If Windows compatability isn't a issue immediately (future problem) then, of course, Python would be the way to go for your circumstance. From what I gather, many people seem to use the Python bindings. I really do appreciate you helping me get oriented. That is quite useful -- I'm sure you've saved me days or weeks of searching the docs for how to make script fu work when basically I would have been wrong to try that route. At least that got straightened out. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, michael chang [EMAIL PROTECTED] wrote: I presume you mean this in the sense that you'd want to write it and distribute it as-is for your users in this cases? Yep -- plain text is ideal, but I can deal with other formats if I have to. If you want, you can always cross compile for Windows on a Linux system, and develop on Linux. (Not sure about vice-versa.) As long as they're using something that runs i386, sure. Cross compiling for other architectures gets into painful issues. And, today, probably everyone I care about could run gimp on windows on a platform that'll run i386 binaries. Should I expect things to always be this way? (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On Thursday 25 August 2005 00:58, woc wrote: I'd have to mess around with getting access to the right development environment every time I needed to make a change. (And I do anticipate needing to make changes.) Shouldn't be a big issue. For MS-Windows, go to CygWin.com and click on the install link. You're only a few clicks and a big wait (seconds over ethernet from a mirror, minutes over ADSL, maybe a couple of hours of dialup) away from a complete toolkit. On most Linux distros, getting the complete development environment installed is a one-liner. On Mandrive 10.2/2005 it goes like this: urpmi gcc Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/Member, Linux Australia ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
woc wrote: On 8/24/05, michael chang [EMAIL PROTECTED] wrote: The only portability issue here is that you'd need to compile it on all target OS's. No big deal -- that's how GIMP is made anyways. Use MinGW for Windows, and Linux uses the GCC and related tools. Easy enough. Which means I'd have to mess around with getting access to the right development environment every time I needed to make a change. (And I do anticipate needing to make changes.) If you make sure that GCC can build it, use stuff that'savailable on any platform (Hint: make heavy use of glib functions), make the plug-in available at http://registry.gimp.org and announce new releases on the gimp mailinglists, you won't have to worry about win32 binaries. HTH, Michael -- The GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, Michael Schumacher [EMAIL PROTECTED] wrote: If you make sure that GCC can build it, use stuff that'savailable on any platform (Hint: make heavy use of glib functions), make the plug-in available at http://registry.gimp.org and announce new releases on the gimp mailinglists, you won't have to worry about win32 binaries. Hmm... would this approach also let me support power pc people? If so, I think I'm happy. (Thanks) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] script fu and image file support?
(This is a nearly verbatim copy of a message I sent to gimp-user. After posting it, I belatedly realized that this is probably more of a developer question than a user question. Or, if not, just ignore me and I'll go on and bug other people.) I want to write gimp support for an obscure file format. The format is relatively simple (simpler than TGA or BMP, for the most part), but does have a few variations where I would want to use multiple layers. I've written code in perl to convert to/from other image file formats, but maintaining that with all the variations is suboptimal because image features don't precisely overlap. I do not want to write a .c plugin, because portability is more important to me than speed. (I also don't want to use perl because gimp support for perl isn't as portable as for script fu.) These images are relatively small (a few megabytes at most), and I'm hoping I can ignore all the load image an arbitrary tile at a time features of the GIMP. If not, I'll live with that, if only I could figure out how. If doing this from script fu kills performance, I can always advise people to save images in some other file format (such as .XCF) before manipulating them. I do NOT know much about scheme internals. I've been trying to study them, but I keep getting off on tangents that lead me elsewhere. I am comfortable with scheme, and think I know how to look up anything scheme-related but non-gimp-specific. Can someone point me at: * gimp 2.2 load/save support for some type of file written in script-fu? Or, * a concise reference work describing the data types I'd need to deal with and their fundamental support routines? Or, * a faq which is specific to this topic (script fu support for load/save)? Or, * anything else which you think would be specifically useful in this context? Or, if all else fails, I suppose I could try to dig up .XCF file format documentation and write conversion support to/from that format in perl. But I just know I'm going to hate myself, if I attempt that route. Thanks! (woc) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
