script fu and image file support?
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
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)
script fu and image file support?
Hi,
woc 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
script fu and image file support?
On 8/23/05, woc 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)?
script fu and image file support?
On Wednesday 24 August 2005 15:48, michael chang wrote:
On 8/23/05, woc 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 shlomif@iglu.org.il 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.
script fu and image file support?
On 8/24/05, michael chang 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)
script fu and image file support?
On 8/24/05, Shlomi Fish 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)
script fu and image file support?
On Wed, Aug 24, 2005 at 12:58:35PM -0400, woc wrote:
On 8/24/05, michael chang 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
script fu and image file support?
On 8/24/05, Manish Singh 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)
script fu and image file support?
On Wed, Aug 24, 2005 at 01:49:50PM -0400, woc wrote:
On 8/24/05, Manish Singh 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
script fu and image file support?
On 8/24/05, Manish Singh 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.
Oh well, looks like C it is, with all the non-portability that implies. I was hoping for more generic abstractions.
Thanks!
(woc)
script fu and image file support?
On Wed, Aug 24, 2005 at 02:34:28PM -0400, woc wrote:
On 8/24/05, Manish Singh 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.
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
script fu and image file support?
On 8/24/05, Manish Singh 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)
script fu and image file support?
On 8/24/05, woc wrote:
On 8/24/05, Manish Singh 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.
script fu and image file support?
On 8/24/05, michael chang 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)
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
script fu and image file support?
woc wrote:
On 8/24/05, michael chang 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
script fu and image file support?
On 8/24/05, Michael Schumacher 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)
WMF on GIMP
Hi
I want to use WMF on my C/GTK application As such, when i try to open a WMF on the GIMP or on my application, the image is set to a specific size on its own and hence it gets distorted.. Can anybody give a solution for this? Thanks in advance
Uma
script fu and image file support?
On Thursday 25 August 2005 09:31, woc wrote:
On 8/24/05, Michael Schumacher 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?
You can build PPC and PPC64 binaries. I think you'd need eitehr a real machine or a good emulator to actually thest them.
If so, I think I'm happy.
Be happy anyway. You're going to live through the time you spend no matter how you feel, you might as well enjoy it while you're there.
Cheers; Leon
script fu and image file support?
On 8/25/05, Leon Brooks 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)
script fu and image file support?
Hi,
woc writes:
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?
The only way you could do a file loader in Script-Fu (except for the fact that you cannot register it properly as a file load procedure), would be to use gimp-drawable-set-pixel. Feel free to give it a try but I don't think you want to wait that long for your images to load.
Sven
