Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
Hi, [EMAIL PROTECTED] writes: I am having difficulties enumerating, and identifying layers in a Gimp Plug-in. Is there a good source for code that shows how to do this? My need is to save the text information found in a Gimp document/image into another file. To do this, I need to iterate through all of the layers, find the text ones, get the text and save it to a file. My end goal is to make a new Plug-in Filter for an archaic file type that many people would like to have. Any code would be appreciated, I am just having a problem getting started with Gimp development. I am using the Plug-in Template, Linux (Fedora Core 2), Developer and Base RPM's. I have compiled the sample plugin, and got it to list the layers, but I cannot identify the contents of the layer or the simply the layer type. I am afraid there is no way for a plug-in to find out if a layer is a text layer or even to access the text properties. You could perhaps implement what you are trying to do using some internal knowledge about text layer. Basically I could tell you how to do it but I'd have to kill you afterwards ;) If you could outline what information you need exactly, we could try to come up with an API that allows you to do this in a proper way. Having access to the text layers has been requested before so I think we should add this for GIMP 2.4. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
Hi Bill,
[EMAIL PROTECTED] wrote:
I am having difficulties enumerating, and identifying layers in a Gimp
Plug-in. Is there
a good source for code that shows how to do this?
Not really - the usual way is to do something like this:
gint nlayers, i;
gint *layers = gimp_image_get_layers(image_id, nlayers);
/* layers[0] is the top layer */
for (i = 0; i nlayers; i++)
{
/* Do stuff with layers[i] */
/* layer is a text layer if the parasite gimp-text-layer has been
* set */
GimpDrawable *layer = gimp_drawable_get (layers[i]);
GimpParasite *text_parasite = gimp_drawable_parasite_find
(layers[i], gimp-text-layer);
if (text_parasite != NULL)
/* We have a text layer */
}
All the standard GIMP parasites are listed in the gimp sources,
in devel-docs/parasites.txt. There are also docs for things like
debugging plug-ins, overviews of many of the GIMP's internal
formats including xcf, and some documentation for important
subsystems like undo, as well as gtkdocs for the libgimp API.
To do this, I need to iterate through all of the layers, find the
text ones, get the text
and save it to a file.
I'm not sure how the text is stores in a gimp-text-layer
parasite. It is a GimpText object serialised to a string, if that
helps any. UTSL (Use the Source, Luke) or ask Sven :)
Hope this helps,
Cheers,
Dave.
--
David Neary,
Lyon, France
E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
Hi,
David Neary [EMAIL PROTECTED] writes:
Not really - the usual way is to do something like this:
gint nlayers, i;
gint *layers = gimp_image_get_layers(image_id, nlayers);
/* layers[0] is the top layer */
for (i = 0; i nlayers; i++)
{
/* Do stuff with layers[i] */
/* layer is a text layer if the parasite gimp-text-layer has been
* set */
GimpDrawable *layer = gimp_drawable_get (layers[i]);
GimpParasite *text_parasite = gimp_drawable_parasite_find
(layers[i], gimp-text-layer);
if (text_parasite != NULL)
/* We have a text layer */
}
OK, now I will have to kill you both. Well, perhaps not but I can only
strongly discourage to do it this way. You must not rely on the text
parasite and it's content. Doing this might to some extent work on
XCF files that have been freshly loaded but it will fail as soon as a
text layer is modified. There is also no guarantee that this behaviour
won't change in future versions of GIMP. I might even decide to change
it in the middle of a stable release cycle. Perhaps even for the only
reason to break your code that should not be doing this.
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Re: 2.2 splash screen competition
My favourite so far is the colourful paint pots by Metin Amiroff: http://www.gimp.org/contest/gallery.cgi?display=imagename=20041202090612748 6 Or maybe the paint tubes by Andreas Nilsson, I can't decide: http://www.gimp.org/contest/gallery.cgi?display=imagename=20041202090610747 8 I think ones featuring the traditional artist's tools are some of the best, although some of the bold flower-based ones are good too, eg: Brandon King's chrysanthemum against a desaturated background: http://www.gimp.org/contest/gallery.cgi?display=imagename=20041202094328970 6 Or Becky Cierpich's flower digital background: http://www.gimp.org/contest/gallery.cgi?display=imagename=20041202094428993 6 The standard of entries is (by and large) very high; I'm impressed. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: 2.2 splash screen competition
On Thu, Dec 02, 2004 at 01:49:39PM -, Austin Donnelly wrote: My favourite so far is the colourful paint pots by Metin Amiroff: http://www.gimp.org/contest/gallery.cgi?display=imagename=20041202090612748 6 Or maybe the paint tubes by Andreas Nilsson, I can't decide: http://www.gimp.org/contest/gallery.cgi?display=imagename=20041202090610747 8 I found this (digital) interpretation of paint pots very nice: http://www.gimp.org/contest/gallery.cgi?display=imagename=200412020906377591 But after all, it will be hard to decide - a lot of good stuff. Bye, Tino. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Some tests of GIMP startup time over NFS
Hi all, On Monday, there was a brief discussion on irc about the GIMP startup time when the files are fetched over NFS. Using NFS or any other remote file system, all read/writes/stats are more expensive than from a local disk. The discussion was about what could be improved to make the GIMP load faster. I initally thought that some of the delays that are more visible over NFS were due to the way all plug-ins are stat()'ed to check their timestamp, but the test results included below show that I was wrong. So I would like to share these results with those would could be interested (I am unable to re-join irc for the moment). Note that the discussion was about the time that it takes for the GIMP to scan all its plug-ins, brushes, patterns, and other data files (i.e., the time during which the splash screen is shown) and not about the time taken to open an image, create the menus or related stuff that is found in Bugzilla. I made some tests from a rather old Sun Ultra10 box running Solaris 8, which is connected over 100Mbps Ethernet to an old NFS server containing the GIMP installation and to another slightly faster NFS server hosting my home directory. Using the Solaris truss -d command (similar to strace -tt for Linux), I timed the startup time of the gimp-2.0, the stable version that I installed on our NFS server. I created a first trace file on Monday (about 2.5 MB of trace messages), which I uploaded to: http://wilber.gimp.org/~raphael/gimp-2.0-solaris-syscalls.txt That file was good but not perfect because a few files were still in the NFS cache when I did the test, so I re-did a new trace later. Unfortunately I cannot upload it for the moment because I have some problems accessing wilber.gimp.org, but the results are not very different from the previous run. Here is a summary of the timings (from the new file, unfortunately): - from 0 to 1.76 seconds: loading of the app and all libs (gtk, X11...) - until 3.24 (diff: 1.48): X client init, connection to X server - until 5.23 (diff: 1.99): get pixbuf loader, load splash, init pango, get font, display splash - until 5.43 (diff: 0.20): load environ, parasiterc, init progress bar - until 6.34 (diff: 0.91): load 48 brushes - until 7.05 (diff: 0.71): load 58 patterns - until 8.24 (diff: 1.19): load 39 palettes - until 8.76 (diff: 0.52): load 78 gradients - until 9.55 (diff: 0.79): load fonts, templates, modules, sessionrc... - until 12.07 (diff: 2.52): load tool presets - until 12.24 (diff: 0.17): stat all plug-ins - until 12.69 (diff: 0.45): read pluginrc - until 14.63 (diff: 1.94): update progress bar during init of 156 plug-ins - until 25.75 (diff:11.12): pipe fork script-fu, init 95 scripts and pdb - until 30.56 (diff: 4.81): read menurc, devicerc, final init, display docks - after that, the GIMP is idle for some seconds and then I close it I repeated the same test several times, waiting a couple of hours and doing some other tasks between each test in order to flush the NFS caches (client and server). In all cases, the startup time was around 30 seconds (between 30.1 and 30.6) so the test can be reproduced easily and the results are consistent. Some comments: - It takes about 5 seconds until the splash is displayed, but it would be difficult to improve that time because most of it is spent loading the main executable and libraries over the network. It would be possible to show a splash screen earlier by using some hacks such as loading it from a small statically-linked executable written only for that purpose but this is not worth the effort IMHO (some commercial apps do it that way). - The gih brush loader could be improved because it reads its files one byte at a time, but that has only a minor impact on the overall delay (the whole brush file is cached locally anyway). We could not save more than a fraction of a second by improving this. - Loading palettes is slower than I expected. Not a problem, though. - Loading tool presets is slower than I expected. The time is spent in the GIMP itself and not loading the very small files, so NFS is probably not making much of a difference here. - Doing the stat64() for all plug-ins is faster than I expected, so this is not the main cause of delays as I thought initially. - Initializing script-fu takes a lot of time (more than 10 seconds), mostly due to the large amount of inter-process communication. This delay is not related to NFS. It would probably be similar on a x86 machine running at less than 500MHz. - If most files are already in the local NFS cache before starting the GIMP, then it starts about 7 seconds faster (23 seconds instead of 30 seconds). Conclusion: the additional delay due to potentially inefficient usage of NFS is not that big, if we keep in mind that it would be difficult to reduce the initial loading time for the main app and libs. The other potential optimizations are not specific to NFS. -Raphaël
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
Hi, Sven Neumann wrote: OK, now I will have to kill you both. Well, perhaps not but I can only strongly discourage to do it this way. You must not rely on the text parasite and it's content. Sorry - wrote that before I got your reply :) I know you were hoping to implement text transforms this week before 2.2, aside from that, is there any (good) reason why the parasite's format would change? Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ Tél: 04 72 33 95 35 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
On Thursday 02 December 2004 09:50, Sven Neumann wrote:
Hi,
David Neary [EMAIL PROTECTED] writes:
Not really - the usual way is to do something like this:
gint nlayers, i;
gint *layers = gimp_image_get_layers(image_id, nlayers);
/* layers[0] is the top layer */
for (i = 0; i nlayers; i++)
{
/* Do stuff with layers[i] */
/* layer is a text layer if the parasite gimp-text-layer has
been * set */
GimpDrawable *layer = gimp_drawable_get (layers[i]);
GimpParasite *text_parasite = gimp_drawable_parasite_find
(layers[i], gimp-text-layer);
if (text_parasite != NULL)
/* We have a text layer */
}
OK, now I will have to kill you both. Well, perhaps not but I can
only strongly discourage to do it this way. You must not rely on
the text parasite and it's content. Doing this might to some
extent work on XCF files that have been freshly loaded but it will
fail as soon as a text layer is modified. There is also no
guarantee that this behaviour won't change in future versions of
GIMP. I might even decide to change it in the middle of a stable
release cycle. Perhaps even for the only reason to break your code
that should not be doing this.
Actually, it doesn't even work on a newly created text layer. No
parasites in there, checking interactively.
There is one thing to do - The plug-in have to manage text layers on
it's side, creating itsef the parasites it need to store the
information. - Just like the old Dyn text. Then, the standard
text-tool api can be used. The plug-in won't know about any other
text layers but the ones it creates, thought.
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: 2.2 splash screen competition
On Thu, Dec 02, 2004 at 02:22:44AM -0800, Manish Singh wrote: This has been moved to: http://www.gimp.org/contest/contest.cgi Current submissions can be seen at: http://www.gimp.org/contest/gallery.cgi thank you for this! thank you Manish and Helvetix. are the web servers handling it as predicted and designed? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Best way for limit distance
Thanks for the suggestion. Using Joao [EMAIL PROTECTED] lead I use for now python-fu with the numarray extension. As far as I know such speedups are something scrip-fu is not capable off, and I truly hope one day script-fu will be phased out and python-fu (or any other sane scripting language) will take it's place.Others might disagree, but I don't consider perl sane :) BTW, all this was part of a small evaluation of CCD noise removal method. If you are interested, the details are in http://pages.quicksilver.net.nz/pepe/d70/Nikon_D70_on_Linux.html#ISONoise The results are quite dismaying. I appreciate any insight on the subject. However please note I am not looking for a solution for the specific image I used, but a generic one. -Joseph Øyvind Kolås wrote: On Tue, 30 Nov 2004 13:25:16 +1300, Joseph Heled [EMAIL PROTECTED] wrote: (I think this has been discussed on the list before, but not sure where/when.) What is the best way to achieve the following functionality - Given two layers L1 and L2, I want L2 limited by it's distance from L1 Result - L1 - MIN( MAX(L1 - L2), -20), 20) Options: A. Write a plugin B. Write it as a script-fu (not sure if script-fu can iterate on pixels, and what is the speed implication). And I hate scheme. C. Write it in python fu if I can compile it, but even though it is probably not as universally available as scrip-fu. Can I iterate over an image in python-fu? D. I know I can do it with 5 layers and overlay modes. write this as a script-fu. Not elegant and requires loads of memory for large images. E. extend gluas to be able to pick an auxiliary drawable for additional pixel sources, (essentially resurrecting some code I initially had in a different version of gluas, and write the expression in gluas). ( gluas is at http://pippin.gimp.org/plug-ins/gluas/ ) /pippin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] writing plug-ins
Hi all, I'm a student and as a university project I have to write a document about writing plug-ins in gimp (and create a plug-in as well). I already managed to discover some pieces of information scattered through the net, but it seems to me it's not enough to write a complete document. I've read Kevin Turner's document and found it quite interesting. I've also downloaded gimp-plugin-template-1.3.3 and that was very helpful too (though a little outdated). In any case, I didn't found a document explaining all I'd like to know (that's why I'm trying to write one, maybe ;)) and I was hoping you could point me to something I may have missed. BTW, I noticed the template uses gimp_image_menu_new() which is now deprecated. What should I use instead? A ComboBox maybe? (I'll have to wait until 2.2 if that's the case, right?) Oh, I almost forgot: the document I'm writing is in italian. I'd be glad to share it if you think it may be useful to the GIMP community (AND if my professor agrees) but I don't think I'll have the time for an english translation. ;) Bye, Alessandro Morandi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
This is a response to the Why
would you need to have the text?
Well, when writing a filter to save
a file, or generate a file set. Some old IBM
file formats allow you to optimize your
image with text objects and rules
(horizontal or vertical lines). If
I could determine the text content, I could
generate a very small and optimized
file.
Also, file formats such as wmf, postscript,
pdf and such benefit from
vector based information and text information.
I guess, my thought would be for widget
implementers, to abide by
certain rules, with the raster based
image being the common
denominator. So, Text
tools, should implement the GimpText
object. Curve Editors
should implement their counterpart. This
way, enumeration of layers and content
would yield good information
(not great) for exporting in specific
file formats.
Gimp is great tool, could be a start
to more than photo's and images, a
whole world of document management
could be assisted by this :)
This is all just my opinion.
Thanks
Bill
Sven Neumann [EMAIL PROTECTED] wrote
on 12/02/2004 05:50:58 AM:
Hi,
David Neary [EMAIL PROTECTED] writes:
Not really - the usual way is to do something like this:
gint nlayers, i;
gint *layers = gimp_image_get_layers(image_id, nlayers);
/* layers[0] is the top layer */
for (i = 0; i nlayers; i++)
{
/* Do stuff with layers[i] */
/* layer is a text layer if the parasite gimp-text-layer
has been
* set */
GimpDrawable *layer = gimp_drawable_get (layers[i]);
GimpParasite *text_parasite = gimp_drawable_parasite_find
(layers[i], gimp-text-layer);
if (text_parasite != NULL)
/* We have a text layer */
}
OK, now I will have to kill you both. Well, perhaps not but I can
only
strongly discourage to do it this way. You must not rely on the text
parasite and it's content. Doing this might to some extent work
on
XCF files that have been freshly loaded but it will fail as soon as
a
text layer is modified. There is also no guarantee that this behaviour
won't change in future versions of GIMP. I might even decide to change
it in the middle of a stable release cycle. Perhaps even for the only
reason to break your code that should not be doing this.
Sven
Re: [Gimp-developer] Best way for limit distance
On Fri, 03 Dec 2004 10:12:37 +1300, Joseph Heled [EMAIL PROTECTED] wrote: BTW, all this was part of a small evaluation of CCD noise removal method. If you are interested, the details are in http://pages.quicksilver.net.nz/pepe/d70/Nikon_D70_on_Linux.html#ISONoise The results are quite dismaying. I appreciate any insight on the subject. However please note I am not looking for a solution for the specific image I used, but a generic one. I think you are running with an old version of the gimp, the artifacts from the median filtering done in the Despeckle plugin doesn't look good at all in your image,. somehow it seems like the result I achieve in http://pippin.gimp.org/tmp/despeckle_adaptive_non_recursive_radius_1_black_level_0_white_level_256.png.html might be similar to what you want (note that I have run it on the jpeg version of your original.) running with a radius of 1. /pippin -- Software patents hinder progress | http://swpat.ffii.org/ Web : http://pippin.gimp.org/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Best way for limit distance
I am using gimp-2.2-pre2. I certainly get totally different results than you for the same setting. I would appreciate some advice on how to find out how can that be, -Joseph Øyvind Kolås wrote: On Fri, 03 Dec 2004 10:12:37 +1300, Joseph Heled [EMAIL PROTECTED] wrote: BTW, all this was part of a small evaluation of CCD noise removal method. If you are interested, the details are in http://pages.quicksilver.net.nz/pepe/d70/Nikon_D70_on_Linux.html#ISONoise The results are quite dismaying. I appreciate any insight on the subject. However please note I am not looking for a solution for the specific image I used, but a generic one. I think you are running with an old version of the gimp, the artifacts from the median filtering done in the Despeckle plugin doesn't look good at all in your image,. somehow it seems like the result I achieve in http://pippin.gimp.org/tmp/despeckle_adaptive_non_recursive_radius_1_black_level_0_white_level_256.png.html might be similar to what you want (note that I have run it on the jpeg version of your original.) running with a radius of 1. /pippin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Best way for limit distance
Øyvind Kolås wrote: http://pippin.gimp.org/tmp/despeckle_adaptive_non_recursive_radius_1_black_level_0_white_level_256.png.html might be similar to what you want (note that I have run it on the jpeg version of your original.) running with a radius of 1. /pippin I was careless and did not realize the jpeg will make such a big difference. I replaced the original on my page with a png file, which you can grab if you wish and see the problem for real. While your settings are definitely better, personally I find the result not good enough. And as I mentioned, the speed of the plugin is a big deterrent as well. -Joseph ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] intltool 0.30 produces XML error in gimp-tips.xml
On Dec 1, 2004, at 5:57 AM, Sven Neumann wrote: Brion Vibber [EMAIL PROTECTED] writes: What I don't understand here is why does fink use autogen.sh at all? It doesn't; *I* do when I build Gimp from CVS to test it. OK then. I have changed the warning in autogen.sh. Hopefully it is more clear now. Thanks! The Fink GNOME package maintainers will include an updated intltools package along with coming GNOME 2.8 updates. -- brion vibber (brion @ pobox.com) PGP.sig Description: This is a digitally signed message part
