Re: [Gimp-developer] i18n string
Hi, On Thu, 2007-03-15 at 18:43 +0100, Marco Ciampa wrote: Many thanks, here there is another: http://www.ciampix.net/color2alpha.png This string is marked for translation, it's in POTFILES and it even seems to be translated to italian. What exactly is the screenshot showing? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Deskew plugin
Hi, On Thu, 2007-03-15 at 19:52 -0700, Karl Chen wrote: Deskew, also known as auto straighten, rotates an image such that text is straight -- useful when dealing with scanned images. Looks very nice. I have always found this simple to do in GIMP using the Rotate tool in Corrective mode, but perhaps it becomes even simpler if it is done automatically. We might want to include this plug-in for the 2.6 release. Please keep on hacking and propose it again after the 2.4 release is out and we have branched for 2.6. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] i18n string
On Fri, Mar 16, 2007 at 08:40:52AM +0100, Sven Neumann wrote: Hi, On Thu, 2007-03-15 at 18:43 +0100, Marco Ciampa wrote: Many thanks, here there is another: http://www.ciampix.net/color2alpha.png This string is marked for translation, it's in POTFILES and it even seems to be translated to italian. What exactly is the screenshot showing? That even with the assuptions that you list, the dialog window shows some items (not all) untranslated. If it was the same problem of the last msg, it would be fixed by myself; now I'm skilled enough ;-) TIA -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush Scaling
Accessing the size and rotate settings through the pdb would be great, here is a lot of ways that I would end up using it... I have a few scripts where I have needed to change rotation and size of a brush... What I've ended up doing is creating a new layer, paint one instance at x,y, and then resize it - rotate it - merge it down - It works but it's very, very time consuming when you have a script that does it several dozen times... Multiple strokes on the same path or selection for sure... You could make some nice border scripts just by using different rotate, scale, and spacing settings with the same brush layered on top of each other... anyway thanks again for everything so far, it is really appreciated... (I've been using it constantly) Joao S. O. Bueno Calligaris wrote: On Thursday 15 March 2007 07:22, jbaker wrote: Thanks for all the work on this one, it works great... I was just curious if there are any plans add the ability to scale and rotate the standard brushes with python ? I did a quick search in the procedure browser but didn't see anything except the functions for the generated brushes... thanks, no plans made - except for generated brushes (the ones you can create and edit from within the brush dialog). But this is an area I am thinking about. (actually, mostly the pdb for brush stroking) Please say a little more on what you are planning to do (the final effect). Regards, js -- jerry ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] i18n string
Hello Sven, Sven Neumann ha scritto: ... This string is marked for translation, it's in POTFILES and it even seems to be translated to italian. What exactly is the screenshot showing? The screenshot should refer to the Layers - Transparency submenu. Cheers. -- Alessandro Falappa web: http://www.falappa.net/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush sizing
Greetings, I'm glad to see that GIMP is incorporating a brush scaling mechanism. I've been waiting for a long time for something like this! Although, it would be nice if the brush can scale up and down, instead of simply scaling down. This is something that I use quite a lot when painting. The current workaround for this problem I use is to use dynamic brushes and increase and decrease the radius with key bindings. The only drawback is that this works only dynamic brushes. Sometimes a would like to do the same for a bitmap brush (which can now be done via scaling). So, in short. Could you guys have the brushes scale up as well? Thanks for the fabulous work so far! As a side note: How about a separate mailing list for feature requests or where would you prefer feature requests go? Regards, Van Aarde. -- Van Aarde Krynauw http://students.ee.sun.ac.za/~idx Man who falls in vat of molten optical glass makes spectacle of self. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush sizing
On Fri, 2007-03-16 at 15:16 +0200, Van Aarde Krynauw wrote: Greetings, I'm glad to see that GIMP is incorporating a brush scaling mechanism. I've been waiting for a long time for something like this! Although, it would be nice if the brush can scale up and down, instead of simply scaling down. This is something that I use quite a lot when painting. The current workaround for this problem I use is to use dynamic brushes and increase and decrease the radius with key bindings. The only drawback is that this works only dynamic brushes. Sometimes a would like to do the same for a bitmap brush (which can now be done via scaling). So, in short. Could you guys have the brushes scale up as well? It's already done and will be in the next development release. Thanks for the fabulous work so far! :-) As a side note: How about a separate mailing list for feature requests or where would you prefer feature requests go? Feature request go into bugzilla and are preferrably discussed on this mailing list first, to avoid cluttering bugzilla with weird requests and to avoid hiding the discussion there. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] i18n string
On Fri, Mar 16, 2007 at 12:35:43PM +0100, Marco Ciampa wrote: On Fri, Mar 16, 2007 at 08:40:52AM +0100, Sven Neumann wrote: Hi, On Thu, 2007-03-15 at 18:43 +0100, Marco Ciampa wrote: Many thanks, here there is another: http://www.ciampix.net/color2alpha.png This string is marked for translation, it's in POTFILES and it even seems to be translated to italian. What exactly is the screenshot showing? That even with the assuptions that you list, the dialog window shows some items (not all) untranslated. If it was the same problem of the last msg, it would be fixed by myself; now I'm skilled enough ;-) TIA It seems (to me) that many dialogs are affected to this _partial_ localization problem, that is: some items appear translated, and some not, mainly in the filter sub-menus. Perhaps is only a mine build sandbox problem, someone could -please- confirm? TIA -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp_pixel_rgns_register
Pals,
As you noticed, this is my first plugin and I have many silly
questions... Sorry for bothering you with these.
What my plugin does is an iterpolation to get rid of noise by
means of a classical local analysis of a square neighborhood or
radius r of each pixel to change it (if necessary) after the analysis.
My plugin is working fine, using the 'gimp_pixel_rgn_set_row'
procedure and the shuffle raw function contained in
http://developer.gimp.org/writing-a-plug-in/3/myblur5.c
I am already using this in big images (5MB or more).
However, I saw that what is vastly used for plugins is
'gimp_pixel_rgns_register' with ONE iterator like:
for (pr = gimp_pixel_rgns_register (1, dest_rgn);
pr != NULL; pr = gimp_pixel_rgns_process (pr))
{
}
or even TWO iterators like:
for ( pr = gimp_pixel_rgns_register (2, dest_rgn, src_rgn);
pr != NULL; pr = gimp_pixel_rgns_process (pr))
{
..
}
I don't really understand what these for loop do, except that it
somehow loops between the tiles.
My questions: When to use one and when two iterators? Which one
should I use for a procedure like the one described in my plugin?
Is this indeed faster than the method I implemented based in myblur5.c?
Thanks a lot,
Luis.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgns_register
From: Luis A. Florit [EMAIL PROTECTED] [ . . . ] My questions: When to use one and when two iterators? Which one should I use for a procedure like the one described in my plugin? Is this indeed faster than the method I implemented based in myblur5.c? You probably shouldn't do this at all. The gimp_pixel_rgns_process method handles the data tile by tile, which means that it is impossible, or at least quite difficult, to handle interactions that extend across multiple tiles. It is mainly useful -- and very efficient -- for plugins that act on individual pixels. Your plugin, because it needs to look at neighborhoods, does not fall into that category. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgns_register
Hi, On Fri, 2007-03-16 at 10:39 -0700, William Skaggs wrote: You probably shouldn't do this at all. The gimp_pixel_rgns_process method handles the data tile by tile, which means that it is impossible, or at least quite difficult, to handle interactions that extend across multiple tiles. It is mainly useful -- and very efficient -- for plugins that act on individual pixels. Your plugin, because it needs to look at neighborhoods, does not fall into that category. Correct. It would be worth nothing though that a plug-in that processes the data row-by-row should make a call to gimp_tile_cache_ntiles() to make sure that tiles can be cached on the plug-in side. With a tile cache that is large enough to hold two rows of tiles, using gimp_pixel_rgn_get_row() and set_row() shouldn't make much a of a difference performance-wise. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] save for web plugin feedback
Hi, i have a friend who's just migrating off windows and is currently running Ubuntu which he's generally happy with. He complained about save for web functionality missing from the stock GIMP and had some good points on why it's needed, i found the save-for-web plugin through Linux for Designers blog ( http://my.opera.com/area42/blog/ ). While he thought it was an improvement he was still not quite happy with it and he wrote some feedback for it, some of which should be easy to fix. I'm currently trying to get him involved in various GNOME/FLOSS things as he's extremley good at usability and graphics and any help to scratch his itches would be appreciated. Here's his feedback to the save-for-web plugin: I have tried the Save for web Gimp plugin. What it offered in features are these: General: * Side by side comparison of original image vs. optimized version. However, when the optimized version refreshes when settings are changed it goes blank until the new preview has been rendered and file size been calculated. This is very bad for me because I can not keep track of small changes when trying to, say, optimize a GIF for the web and decide the lowest amount of colours that will suffice. * Resize; this works well, but could be useful if other measurement than px could be used (using Save for web for other media than the web is nice too.) * Cropping; Works very nicely. the cropped out area is a little too dark for my taste -- perhaps this can be changed in the Gimp settings Formats: * GIF; same as the Image Mode Indexed... dialogue features except for the Custom pallet option which Save for web does not have. It does have live previewing though, but the update problem makes it much less useful for me. * JPEG; Offers even less options than Gimps standard JPEG optimizer, which also has live previewing and without the update issue! * PNG-8; Same as GIF, but with a compression option (why?) * PNG-24; Interlaced on/off option and a compression setting only. Compression is only offered in 10 levels. So this plug-in has a long way to go before it can match Photoshops (or rather ImageReadys actually) Save for web feature. This is a real show stopper for me, as I mostly create for the web and I just can't go without the level of control that Save for web offers me. So unless there is a separate application for linux that I can give me this control after developing the lossless image in Gimp, Gimp will just have to wait, unfortunately. Will still keep and eye out for linux tools and Gimp, so hopefully things will turn for the good is not a too distant future. This is taken from his original post here: http://www.gimptalk.com/forum/topic/Colour-And-Quality-Optimi-ation-In-Gimp-18492-1.html He's not subscribed so if you can either post to the forum and the mailing list or i'll direct him to any replies on the archive. Thanks, Morgan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgns_register
Sven and Bill, I see. My plugin is already reasonably fast, so is good to know I don't need huge changes. Thanks a lot for your prompt answer!! Nice forum! Cheers, Luis. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. Finally, I'm looking at the latest SVN to see if this is a project that's within my abilities. It looks like a lot of the code that's needed already exists and just needs to be extended into a new dialog - pointers/pitfalls welcome. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
