Re: [Gimp-developer] (python) string don't appear translated
2011/9/2 Cristian Secară li...@secarica.ro: In GIMP 2.7.3 (testing on Windows with the latest development version from Sourceforge) there is a menu File - New Brush from Text... The New Brush from _Text... string is present in python template http://l10n.gnome.org/POT/gimp.master/gimp-python.master.pot and is already translated in my Romanian translation file http://l10n.gnome.org/POT/gimp.master/gimp-python.master.ro.po However, that particular menu displays in English. Hi Cristian -- thank your for your feedback - that particular plug-in was added in the current development cycle, and incorrectly was not marked for translation - Regards, js -- Any known reason for this ? Thank you, Cristi -- Cristian Secară http://www.secarica.ro ___ 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] Camp Ticket Presale Closing
On Tue, Jul 19, 2011 at 5:32 AM, Simon Budig si...@budig.de wrote: Michael Natterer (mi...@gimp.org) wrote: everybody who wants to come to the camp should buy a ticket until *tommorow* the 20th of July: I ordered mine a while ago already and I can only wholeheartedly recommend this event. I won't be able to join you there this year. Got my fun quote at good old LGM. - best hacking wishes. js -- Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] I need help about CMYK on gimp
On Mon, May 23, 2011 at 3:59 AM, Arnon Namsanit arnon.g...@gmail.com wrote: Dear GIMP developer team, My name is Arnon Namsanit. I am a Thailand government officer working for the Ministry of Science and Technology. My team's main responsibility is introducing the open source software to Thais including GIMP. At the moment we are interested in introducing GIMP to a group of users in publisher manufacturing therefore we have been discussing about CMYK on GIMP. I might need to ask you some questions please. - Is there any people currently working on CMYK on GIMP? - If yes, How? Can we join them? - If no, Could we know the complexities or the problems of that please? Since I am not a developer but my organization is able to set up a team to implement the module. I would like to have your opinion on this please. We are looking forward to hear from you. Kind Regards, Good morning, Arnon, The agrreded idea among GIMP developers is that CMYK as an _image editing mode_ will not be implemented in GIMP. Where as there maybe in the future more straightforward ways foreasier CMYK separation and printing. That is due to the fact that CMYK is more the mapping to inks of a printing method than a color mode. Even though this is the de facto printing method for volume, and even personal printing, CMYK values don't have a 1:1 mapping of color values as are visible to the eye, or representable in computer videos or images. (which color is black in an image? (100, 100, 100, 0), (0,0,0,100) or (100, 100, 100,100)? ) That said, for generating CMYK Tiff files as expected for some of today's printshops, and even allowing for some per-plate correction of the amount of colorants in each part of the image, there is the third party plug-in Separate+ ( http://cue.yellowmagic.info/softwares/separate-plus/ ) I believe that installing and getting used to that might your requirements for CMYK. So ..what is the idea for GIMP presently and on the long term, is that proper printing requires actually conversion between the color spaces of the various devices used in the press chain (video monitor, proof printer, large scale printer), making use of _color profiles_ . With proper calibration of devices and use of color profiles one can ensure that a color shade will look on paper, under certain lighting conditions, as it does look on the screen at editing time. All the time the colors are represented internally as an RGB tripplet, and just the printing driver, or software, takes care of mapping the normalized color to the actual colorants in use on the device - taking into account information on the device's color profile. On GIMP's roadmap, there lays, in the future, a way to preview a per plate separation of the image prior to having it exported to a CMYK file in a more integrated way than currently possible with the separate+ plug-in. But that depends on the implementation of a new, very different, U.I. that will allow for non-destructive editing, among other things. Work on this U.I. will start only after current development cycle (which will yield GIMP 2.8). Meanwhile, if you find that GIMP with the Separate+ plugin is not enough for your office's needs, there are other Open Source graphic editing programs that offer varying CMYK capabilities, such as Krita and Cinepaint. Regards, js -- Arnon Namsanit ___ 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] I need help about CMYK on gimp
On Mon, May 23, 2011 at 11:05 AM, Bogdan Szczurek thebod...@gmail.com wrote: One final thougt: CMYK support subject was touched more than once on this list, but I think we should consider much broader view on the matters of printing. CMYK is only most often used set of colorants but there are much more colorants out there. Having native CMYK would be cool thing but even cooler would be to be able to add more colorants to prepared images. What about having metallic overprint/underprint in your projects? What about Hexachrome? Sure, one could prepare image in wide enough RGB (example ;)) and rely on profiles with hexachrome or prepare metallic layer in separate file but hey… one could also edit RGB files stored channel by channel in separate files but what for? Note that GIMP does offer support for such a a manual spot-color workflow through the use of Channels - it can work for jobs sporting one or more distinct spot ink such as metallic or fluorescent. Although there is no preview or separation for that, at least one can edit everything in the same .xcf project and export to distinct files. As for yor other comments, even though they might express a need of some designers, as you stated, they are not in current GIMP road map neither seem as a goal of the program. If one is willing to ditch color profiling alltogether, and wants to compose an image work only with colorant intensity, it should be clear that GIMP's code base does not support that, and another program should be used, unless it can be achieved with the naive approach offered by image Channels. Regards, js -- My best regards tb ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] file-psd-save plug-in should embed a color profile
On Fri, May 6, 2011 at 4:27 AM, Yoshinori Yamakawa y...@yellowmagic.info wrote: Hi, The GIMP can read embeded color profile from the PSD file, but cannot save into the PSD file. I think that file-psd-save plug-in should embed a color profile. I already wrote patch : https://bugzilla.gnome.org/show_bug.cgi?id=647361 Very nice - thank you! I think that an important next step is to get people to indepently test the files generated with this patch working, to see if its working fine. I say that since most GIMP developers won't have easy access to a Photoshop to test the generated files. After that, I think we can just apply it, after a review. js -- -- Yoshinori Yamakawa y...@yellowmagic.info ___ 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] Fractal image scaling
2011/4/1 Александр Белобородов vala...@gmail.com: Good evening! Liquid scaling is beautiful technology, but differs from fractal scaling pretty much. The fractal image scaling is based upon an Fractal compression algorythm and a functional analisys. In the fractal compression algorythm we propose that our image is fixed point of contractive affine transformations. Such system of the affine transformations is called Iterated function system (IFS). We build the IFS based upon our image. Then, to get our image we should take any starting point (any image for example) and apply the IFS many times. As the result we get our image. That's interesting, that the IFS don't know about image resolution, and we can take an big resolution image as the starting point. This way of image scaling is noted by Stephen Welstead in his book Fractal and Wavelet Image Compression Techniques (Chapter 3, 3.6. Resolution independence). If it is not good approach, could you offer me another task related to image processing research field? Regards, Alexander Beloborodov.] Hi Alexander - I myself find this idea very interesting. Certainly, a fractal scaling algorithm of some sort should find its way into GEGL. Can you elaborate a bit more, or give us a link to a digest article describing fractal scaling? In order to consider it as a project, the motivation and advantages of it should be clear to all developers, so that your project is voted up. Your e-mail above is still a bit cryptic on the capabilities of this algorithm regarding what could be available for the final user. You describe the general lines on how does, but we don't know now what it does. For example - can it scale up and down? Can it compare, visually, to the algorithms already implemented in GIMP? Does it offer at least a theoretical big advantage for the final user? (/me hopes so :-) ) Thanks, js -- __ 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] Enabling a 2.8 release: planning for a 2.10 release
On Tue, Mar 15, 2011 at 4:43 AM, Martin Nordholts ense...@gmail.com wrote: On 03/14/2011 11:59 AM, Joao S. O. Bueno wrote: Hi, This decision, as I see it, change the release date from within months to within some weeks - May I ask for the calculations that led you to the conclusion that we are weeks away from a release? I haven't done the math yet, but I still expect us to be months away from a release. I hope you have in mind that Translators have to know about so they can update translations as possible, as well. At some reasonable point before the release, a string freeze status for GIMPshould be set (even if a few string chanegs are to happen after that). Thanks for the reminder. We should probably enter a soft string freeze soon... Other than translation, we have to work the Python bindings so there are no functionality regressions, (whch includes the ability to work with layer groups) - so to the above list of bugs, we shuld at least have one more about this task. (this also depends on being able to transform layer groups). Not including API to work with layer groups in Python is not a regression, it's just missing functionality in one of the scripting languages. It is unfortunate if GIMP 2.8 will be released without layer groups support in Python, but the alternative is worse: not releasing GIMP 2.8 at all. And we should arrange for the Python bindings to be automatically generated from the PDB rather than wasting man-weeks on manually keeping it up to date. Not an easy task perhaps, but the only sensible one. Scripts which previously interated through layers are currently not working. That is a regression. Possibly making layer groups transform work seamlessly. I will do my best to include such support personally over the next few days - allright if you think it shoud not be a blocker. The python bindings do work from the PDB. The current matter with layer groups is that they introduce a new kind o f object, and the Python bindngs on't work with simple integer IDs that the PDB use - there must be a corresponding object on the Python side. (it won't cost a single man week to integrate it - but I've been so absetn I ahven't weven checked the PDB calls available to deal with layer groups yet). js -- / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ 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] CMYK file export plug-in
On Sat, Mar 12, 2011 at 5:15 PM, Yoshinori Yamakawa y...@yellowmagic.info wrote: Hi, According to the GIMP Roadmap, it seems to take time very much for the CMYK support to be added to the GIMP. Now we can use the separate+ plug-in, but I think that the separate+ plug-in is not proper for the GIMP distribution because the separate+ plug-in has unnecessary features for general users and the separate+ workflow is not very seamless. The Separate+ team has written the subset version of separate+ (named separate-) as a GIMP file plug-in. Separate- is the CMYK file exporter and is very simple to use. It supports TIFF, JPEG and Photoshop PSD formats. https://bugzilla.gnome.org/show_bug.cgi?id=640613 From the feedback I have from users here in Brazil - and I mean professional artists working with FreeSoftware, I'd say it would be very important if we could get this in GIMP 2.8 Even if for gimp 3.0 and beyod we think of CMYK exports in a totally different way - all plug-ins will have to be rethough when we get to GIMP 3.0 anyway. The demand for this ability however we agree that it is not the best approach, is very high in the professional levels. At least around here, where the print stores use to require pre-separated artwork from the authors. Regards, js -- -- Yoshinori Yamakawa y...@yellowmagic.info ___ 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] Adding a layer mode
On Wed, Mar 2, 2011 at 10:00 PM, Jörn P. Meier li...@netgods.de wrote: Hi, I would like to implement the following layer mode in the GIMP: 1) Transform destination and source pixels to HSL space. 2) Note original destination pixel saturation. 3) Set luminance component of destination pixel to luminance component of source pixel. 4) Transform destination to HSV color space. 5) Set saturation of destination pixel to original saturation of destination pixel. I'm assuming destination is also the result of the operation. Not sure how GIMP handles this, though. The purpose of the mode is to colorize a greyscale image while keeping both the saturation and hue data of the color layer and the luminance data of the greyscale image. Existing modes (as far as I see) unfortunately either mess up the color information or the luminance information. Hi John --- regardless of the desired operation, it would be very difficult to stick a new layer operation in GIMP - due to file compatibilities, and everything else. When I first started hacking around the GIMP source code, some years ago, new layer operations also where something that I messed with. But see..even if one doe shave a great idea, and a nice pacth taht wuld be included in the GIMP's source, there would be a problem of compatibility of new XCF images using the new layer mode, and older GIMP versions around. So, while, yes, you could create a new layer mode just to poke around, it would be of little use other than for yourself. (Regardless, it is fun enough, I suggest you try it). If you get a usefull enough result, maybe yu could make a plug-in that would combine two normal layers using the algorithm you describe. You loose all real time niceness, but at least you can achieve your result. (and this plug-in can be passed around to others). As for where to create a layer mode-- there are some files - -I don remember which now -- part of the fun is locating them -- you get to know yoru way around GIMP. You will even find out that there are different code paths to render layers on the source tree. There are all the files on the app/composite directory -- or one can enable GEGL compositing, for which the files are under app/gegl This article can have some usefull hints on how to poke around GIMP' s source: http://www.ibm.com/developerworks/linux/library/os-gimp Regards, js -- So, the question is, what changes would I need to make to add this layer mode? I would be very grateful for any hints. :) Cheers, Jörn ___ 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] gimp-item-transform-scale vs gimp-drawable-transform-scale
On Fri, Feb 11, 2011 at 11:13 AM, Ofnuts ofn...@laposte.net wrote: On 02/11/2011 01:02 PM, Alexander Rabtchevich wrote: I apologize, you are right. I apparently only added links to the new context functions from the new selection API. It's the new context API, e.g. gimp_context_set_interpolation(). Will add the docs after work today. Hmmm. What proportion of existing plug-ins working in 2.6 will have to be rewritten for 2.8? In my neck of the IT woods, within the same version backward compatibility is implied... And if a rewrite is necessary we will have to support both versions for quite some time (some people fall in love with some plug-ins and won't upgrade Gimp until there is a new version of their beloved plug-in). And do it again when 3.0 shows up... Most existing plug-ins will just work in gimp 2.8 - at least in non-layer group using images (and most plug-ins don't care about more than the current layer/drawable, so these will work anyway, just not on the group, but on individual layers). The fact that some procedures are marked as deprecated does not mean they will stop working in gimp-2.8: they are still there. New plug-ins are however expected not to use these calls (an expectation that is strongly enforced by the fact that the deprecated procedures have their documentation replaced by a stub) When the time comes to GIMP 3.0, that is another history - - chanigng in the major version number also means it is time to break backwards compatibility, and remove deprecated functions. But that is not the case for 2.8. js -- ___ 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] gimp-item-transform-scale vs gimp-drawable-transform-scale
On Fri, Feb 11, 2011 at 12:41 PM, Øyvind Kolås pip...@gimp.org wrote: On Fri, Feb 11, 2011 at 1:13 PM, Ofnuts ofn...@laposte.net wrote: On 02/11/2011 01:02 PM, Alexander Rabtchevich wrote: I apologize, you are right. I apparently only added links to the new context functions from the new selection API. It's the new context API, e.g. gimp_context_set_interpolation(). Will add the docs after work today. Hmmm. What proportion of existing plug-ins working in 2.6 will have to be rewritten for 2.8? In my neck of the IT woods, within the same version backward compatibility is implied... And if a rewrite is necessary we will have to support both versions for quite some time (some people fall in love with some plug-ins and won't upgrade Gimp until there is a new version of their beloved plug-in). And do it again when 3.0 shows up... But the rewriting needed for 3.0, porting to be GEGL ops, can be done already now, and I would strongly encourage GIMP to make use of GEGL ops more on an equal footing to GIMP plug-ins (and not be hidden in an own menu under the GEGL tool like it is now) so that freshly developed plug-ins can be done as GEGL ops already now and be more future proof. For example, people usually marvel at the GEGL c2g filter - and it is completly hidden under tools-GEGL operations. Maybe it could be somewhat more exposed as an option in Colors-desaturate, or filters-artistic? js -- /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://gegl.org/contribute.html ___ 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] Creating sub-directories from Script-Fu scripts
On Mon, Feb 7, 2011 at 1:24 PM, Alexia Death alexiade...@gmail.com wrote: On Mon, Feb 7, 2011 at 4:12 PM, Rob Antonishen rob.antonis...@gmail.com wrote: In particular, (system command) would be real handy. It would also make gimp scripts easily exploitable for abuse on the system, like exectuting malware. Well.. since we never put a single thought in hardening script-fu scripts against being explotable for abuse - then it is all for the better that the possibilities are explicit, and available for users. It is clear that running a complete-featured language program wihtout a carelfully constructed sandbox environment pretty much gives the script access to all resources the user runningt he script has. It is hard to make it otherwise in specific environments to avoid that - so I think this is a non-issue. Note that I still advice anyone trying more sophisticated scripts to do so in Python, but I see no point in artificially restricting tiny-fu. js -- -- --Alexia ___ 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] Photoshop ?compatibility? mode
On Tue, Feb 1, 2011 at 1:45 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Because people talk about the big picture. Pretty please carefully reread what Jon Cruz wrote in the thread. It's a spot-on message. You mean Jon Senior? js -- Alexandre Prokoudine http://libregraphicsworld.org ___ 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] GIMP GNU GPLv3/LGPLv3 in general (was: Re: distributing gimp with another program)
On Mon, Nov 22, 2010 at 8:04 AM, Michael Schumacher schum...@gmx.de wrote: Von: Christopher Curtis ccurt...@gmail.com *** (Sven, Mitch) *** This LICENSE text should probably be updated as 'Section 2' of GPLv3 doesn't talk about aggregations - it's been moved into section 5. It might also be useful to address this issue directly as the GPLv2 is generally well understood to allow command line usage as an 'aggregation', but GPLv3 seems to muddy this distinction. At the moment I'm not even sure if GIMP should be licensed under GPLv3 without a much better understanding of the license. For example, the fact that it is now impossible to use GPLv2-only libraries in plug-in wasn't considered at all. It's not such much the fact that we can't use them anymore, rather the problem of no one even thinking about it when we changed the license version to v3. I have contacted the Freedom Task Force of the FSF in order to get help, and they requested more details. Unfortunately my spare time (or the lack thereof) didn't allow me to write a reply yet. I'd be glad to learn about any additional side-effects of a GPLv3-licensed GIMP (note that libgimp* is licensed under LGPLv3) that may surprise us - but please base them on actual FSF information and not mere speculation. Since a long time ago, we had an exception of the license for plug-ins in a sense that GIMP plug-ins can be non GPL. If you as much as take a look at the LICENSE file provided in the tree, it is at the second and third paragraphs. Therefore, there should be no problem in suiong GPLv2 or any other license for libraries linking to plug-ins. js -- Regards, Michael -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ 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] Blocking for...@gimpusers.com
On Tue, Nov 16, 2010 at 6:28 PM, g...@catking.net wrote: Hi, the running polemical thread on VG filter has made me aware of what is presumably a new feature on that gimpusers.com blog that allows users of the site direct access to this list via the address for...@gimpusers.com Would it be a best to simply block this address? Anyone wishing to discuss gimp-devel can sign up here and join the list. Letting users spam the list with inane comments form a blog is probably not productive. A request could be made to remove that from the blog but bouncing that address would probably be quicker and easier. regards, gg No - we rather let people participate - the amount of messages on that topic is not that overwhelming - and anyone not interested might simply ignore it by subject. js -- ___ 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] Optimizing border-like selection in python
On Mon, Sep 27, 2010 at 3:45 AM, Ofnuts ofn...@laposte.net wrote: On 24/09/2010 17:05, Joao S. O. Bueno wrote: On Fri, Sep 24, 2010 at 11:19 AM, Ofnutsofn...@laposte.net wrote: Hi, My code needs to do a one-pixel-wide selection, at distance x from the current selection. This looks a lot like a border selection except that the border selection creates at best a two-pixel wide ribbon and I only want one (but if I'm wrong, please tell me how to :-) So far my code goes like this: # Selects pixels that are between x and x+1 pixels from # the original selection. Bumping the selection by one # each time doesn't work, a small circle degenerates into # a square with rounded corners instead of a big circle. def select_ribbon(self,image,selection,dist): pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist+1) outer=pdb.gimp_selection_save(image) pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist) inner=pdb.gimp_selection_save(image) pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0) pdb.gimp_selection_load(outer) image.remove_channel(outer) image.remove_channel(inner) That works, but can be slow (especially since it's at the core of a loop). Is there any better way? Or useless code to jettison? Next improvement is to create a 3-pixels selection and feather it one pixel. Anything to be wary of? Hmm..this _will_ be slow. :-) You can speed it up by making a copy of your drawable to another image, disable the undo system on this new image and perform your cations above, before copying the results back to the original image - but it is about it. Maybe you can perform the whole loop in the copy with undo disabled - but I don't know your intent. Disabling undo on the main image (just for tests) doesn't show much speed gain (from 2'03 to 1'56 in my test). It's only better memory-wise. Hmm..maybe soem of the spped-up I experience has tod o with the new image I create on BG not being displayed - it will certainly help on this due to the marching ants that are used midway that don't need to show up. js -- ___ 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] Optimizing border-like selection in python
On Fri, Sep 24, 2010 at 11:19 AM, Ofnuts ofn...@laposte.net wrote: Hi, My code needs to do a one-pixel-wide selection, at distance x from the current selection. This looks a lot like a border selection except that the border selection creates at best a two-pixel wide ribbon and I only want one (but if I'm wrong, please tell me how to :-) So far my code goes like this: # Selects pixels that are between x and x+1 pixels from # the original selection. Bumping the selection by one # each time doesn't work, a small circle degenerates into # a square with rounded corners instead of a big circle. def select_ribbon(self,image,selection,dist): pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist+1) outer=pdb.gimp_selection_save(image) pdb.gimp_selection_load(selection) pdb.gimp_selection_grow(image,dist) inner=pdb.gimp_selection_save(image) pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0) pdb.gimp_selection_load(outer) image.remove_channel(outer) image.remove_channel(inner) That works, but can be slow (especially since it's at the core of a loop). Is there any better way? Or useless code to jettison? Next improvement is to create a 3-pixels selection and feather it one pixel. Anything to be wary of? Hmm..this _will_ be slow. :-) You can speed it up by making a copy of your drawable to another image, disable the undo system on this new image and perform your cations above, before copying the results back to the original image - but it is about it. Maybe you can perform the whole loop in the copy with undo disabled - but I don't know your intent. js -- -- Ofnuts ___ 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] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 7:38 AM, oli...@first.in-berlin.de wrote: On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. What do you mean by a workshop? Like a physical face to face class, where one would be pointing this is the tools directory, inside it there are the files that ,make for the tool classes...? Not shure if that could help. Anyway, I've written an article a couplle of months ago that is now published here: http://www.ibm.com/developerworks/linux/library/os-gimp/index.html?ca=drs- Maybe that fulfills part of what you call a workshop. Now, please - these kindof rants won't change anyones atitude in here - the developers willjust feel ill towards you. Keep experimenting, trying, learning, and asking about code - refrain from rants: they just take us nowhere. regards, js -- (...) Ciao, Oliver ___ 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] Fwd: Drawing per Script
On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: Hello, Hi I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse to draw circles, right? What does prevent you from using the calls for gimp_vectors_bezier_stroke_new_moveto and gimp_vectors_bezier_stroke_lineto to draw lines? (Don't forget to alias then in your code to shorter names, last you have really undereadable stuff) Still, creating a vectors object from stroking is one way of painting with scripts in GIMP (the recomended one to draw curves and circles, though) - for stragiht lines you can use pdb.gimp_paintbrush instead. Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? As I stated above, there are calls to draw lines. Are you even using the procedure browser? (Help menu - Procedure browser) - In Python you can access the image data directly, using calls to get the pixel regions if you want to as well (that is about 100x faster than gimp_drawable_set_pixel due to the function calls involved for each pixel change) When using the circle drawing with vectors I would expect that this technique can do it's work fast. But it's very slow (using a loop to set paths in those vectors). (In OpenGL for example there are Vertex Arrays that can be used to speed up drawing. Something like that in GIMP, and available for scripting would be nice.) Sorry to tell you that - tehre is some slowdown in using the PDB, but this is more or less as fast as it gets using GIMP to draw yiu stroken circles. You probably coukd get some speed-u dealing straight with the image data if you don't need the stroking engines from GIMP - i.e. - no need to use different brushes, gradients, dynamics and so on) If so you can get some significant speed-up using C, or maybe even python if you get an efficient way to draw your circles using pixel data. (A suggestion would be to cache different pixel data for the circles with the radii you want, as gimp-buffers, and paste then on the desred places on teh image - that shoul be much faster than creating/stroking paths) (I also saw, that what on the GUI are Paths internally are called vectors. To make things better undesrstandable, it would make sense to give things the same name... but maybe there is more to vectors and I don't see it so far. Why are there different names?) will leave that up to Simon :-) How can I speed up my drawings without switching to C? With my Python script I need about 3 or 4 seconds just for drawing 2072 circles. So, besides my hints above: when I need speed on a PDB using script (which includes python scripts), I found out that GIMP's undo system is the cause for a significant slow down. Creating an Undo group does not help - you have to disbale the undo with pdb.gimp_image_undo_disable This can give you a 3x to 4x times improvement when you have many small operations going on (like drawing thousands of circles) . Unfortunatelly this spoins the undo system for you rimage -even after a call to undo_enable. If you are editing the image interactvely I suggest you make your script to: - copy the drawable you are interested to a new image - disable the undo system on the new image - perform your painting operations - copy the drawable back to the original image (and destroy the newly created image, of course) This seems very slow to me. If I also would need to write pixels of a line pixel-wise, If you weant 1 pixel thick straight lines, use the pencil tool and the pixel brush. I would also await to have very slow scripts. Special functions for drawing lines from within Python-plugins, that use C-speed would be fine. Regards, js -- Gruß, Oliver ___ 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] Fwd: Drawing per Script
On Mon, Sep 13, 2010 at 8:56 PM, oli...@first.in-berlin.de wrote: Hi, On Mon, Sep 13, 2010 at 05:21:09PM -0300, Joao S. O. Bueno wrote: On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: Hello, Hi I tried drawing per Script. I'm using Python. I can already use vectors for drawing circles, and set single points. I did not found a way to create rectangles, or lines. You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse to draw circles, right? I use: pdb.gimp_vectors_bezier_stroke_new_ellipse Your way is the correct - mine was just a typo - a thing I excel in. So I think it's what you are talking about, just the absolute name is different. What does prevent you from using the calls for gimp_vectors_bezier_stroke_new_moveto and gimp_vectors_bezier_stroke_lineto to draw lines? I looked for draw and did not find functions that do it. So, in short words: I did not found thos functions. yes-- the procedure broswer has this downside -- you have to keep looking with related words if you don't find something at first. (Don't forget to alias then in your code to shorter names, last you have really undereadable stuff) If it does not eat up too much ressources in Python... It does not. What is delaying the execution is much more the nature of the PDB and the Undo system than python. With aliasing I mea just attributing the pdb functions to a local variable - with lines like these at the start of your function (or even at the start of your module): lineto = pdb.gimp_vectors_bezier_stroke_new_lineto ellipse = pdb.gimp_vectors_bezier_stroke_new_ellipse From then on you can jsut type ellipse( ...) instead of the long name designed to avoid namespace clash. This does not create new functions - you call the very same function, just using another name. ...you mean using def for creating a function that just calls the other one? or are aliases what Python offers as a separate feature? [...] Aren't there pdb-functions that draw a line? Do I have to create it pixelwise? In a loop? As I stated above, there are calls to draw lines. Are you even using the procedure browser? (Help menu - Procedure browser) - I use the procedure browser. But it does not help me, if I look for names that aren't there ...if I look for draw I got nothing. The circle-drawing function via bezier I found by accident/chance. If you type vectors you will see all teh vector related functions. Howeer to paint straight without using a path, you have to look for the tool name: pencil, paintbrush, etc... In Python you can access the image data directly, using calls to get the pixel regions if you want to as well (that is about 100x faster than gimp_drawable_set_pixel due to the function calls involved for each pixel change) How can I access the pixel data directly? That would be very interesting to me, especially for some other scripts, where I think about even more intensive work. px = drawable.get_pixel_rgn(top, left, width, height) px [:, :] = \xff\x00\x00 * drawable.width * drawable.height() drawable.update(top, left, width, height) The get_pixel_region and update are methods of GIMP drawable objects. The item assignment to set/reset pixels is a bit aukward - the example above paints the whole drawable in red (if it is a 3BPP RGB channel, else you willget an error telling the setting string is of the wrong size) For serious work with pixel regions you might prefer to copy the pixel data to a Numpy array - ther eyou can work with numbers from 0 to 2545 instead of having to convert all data to string prior to setting the pixels. [...] So, besides my hints above: when I need speed on a PDB using script (which includes python scripts), I found out that GIMP's undo system is the cause for a significant slow down. Creating an Undo group does not help - you have to disbale the undo with pdb.gimp_image_undo_disable OK, I will try that. Thanks for all that hints. :) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] make layer active when enabling its visibility
On Mon, Aug 16, 2010 at 8:57 AM, tmaes thierry.m...@gmail.com wrote: Hi, here is an enhacement request I posted in the bugzilla, Martin Nordholts told me to send it to the mailinglist, so I hope I post it in the right place: I often have this problem: when enabling/disabling layers visibility during my work, to choose in whitch layer I want to work, when I find the one I want, I directly go to the image and draw... but sadly, it is in the last active layer that I draw and the result is not what I wanted. I think it would be more ergonomic if the turned on layer becomes automatically the active layer. At least, if people could choose this behaviour(instead of the actual) in the preferences, it would be great, I think. I hope my description is understandable. Regards to all, Hi Thierry - While this behavior can make for a productive workflow in you case, it would otherwise break completely the way the program behaves now - it would be impossible for one turning on another layer to continue painting where he was previously. In contrast, activating the newly visible layer is just a matter of one additional click for who wants this to happen. So I think your request is not feasible in the way it stands. On a connected issue, there is a somewhat hidden feature regarding activating layers: in the preferences dialog, on the tool options, you can set the Move tool to automatically select the moved layer (that is not the default behavior) - and on the Image Windows tab of the preferences, you can set the Space bar to switch temporarily to the Move tool (instead of the default 'pan') - in that way, you can have a fast and agile workflow to change the active layer, by pressing space and clicking on a part of the image on the desired layer. Regards, js -- -- Thierry Maes ___ 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] Help with new default resources in 2.8
On Mon, Jul 19, 2010 at 10:49 AM, peter sikking pe...@mmiworks.net wrote: hi all, the reason I talked myself into the position of 'maintainer of default resources' (is that a title like 'floor manager' at mcdonalds?) at the LGM is that I voiced concern over how they can either enhance or sabotage the product vision: (...) one last thing: we have a green pepper problem. it fails several of criteria outlined above, but the GIMP team seems to be emotionally attached to it. similar to the GIMP name, we seem to wear it as a badge of honour. so I am 50/50 on in/out. this may prove to be the hardest decision of my career ^} One thing that applies to to the pepper , but may ease the conflict of what should go in or not: maybe the default resources could be tagged to default -- and instead of showing all items at program satrt=up, we could show just the deffault tagged items. That way, the pepper, sun, wine brushes could go under a bitmap tag, but have no default tag attached. That would also make it easier to display just the wanted gradients - several of the gradients shipped with GIMP are used in tiny-fu scripts. (as for the pepper per se, my personal opinion: I have no problem at all with it going away. I have _one_ real use for it: it helps me to locate the pixel brush, since it is next to it in alphabetical order. The pixel brush should, IMHO, be tagged pixel by default, so it can be found with less keystrokes) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp UX: Paste
Hi, This has just been discussed in the Libre Graphics Meeting which just took place, and should be the main subject of the Summer of Code project I am mentoring. there are other motives for the Floating Selection (i.e. the quasi layer) to exist, but of course, the existing usability for that is way broken. We will be working closely with peter Siking to get pasted objects to behave in the most useful and unobtrusive way possible. js -- On Wed, Jun 2, 2010 at 10:14 AM, Michael Schumacher schum...@gmx.de wrote: Von: Jason Simanek jsima...@gmail.com Thanks for listening. If a discussion about these issues has already taken place, please provide URLs to those discussions. I have no intention of reopening discussions that have already been resolved. https://bugzilla.gnome.org/show_bug.cgi?id=561576 HTH, Michael -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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] Question on new (2.8) paint dynamics
On Thu, May 20, 2010 at 10:35 AM, Rob Antonishen rob.antonis...@gmail.com wrote: I will have to play with the force setting. I a looking to have a pixmap brush be lighter or darker based on brush pressure. Maybe explained like a dynamic dodge/burn applied to the brush source while painting? Features apart, Rob, you can use some sort of source layer tracking by using the clone tool instead. Just use it in registered mode, and explore the painting modes/ painting on the layer mask, etc... Regards, js -Rob A On 5/20/10, Alexia Death alexiade...@gmail.com wrote: On Thu, May 20, 2010 at 7:13 AM, Rob Antonishen rob.antonis...@gmail.com wrote: I have looked at some of the previews and devel paint dynamic reports/reviews and still have a couple questions. In amongst all those settings is there any trace a source layer as an option? No. and there wont be one in this iteration either. Its nontrivial and probably pretty slow to access pixel under cursor for dynamics evaluation and the whole thing needs to stabilize first. there are other simpler dynamics inputs that are proposed, but not happening for 2.8, like the position of the cursor in the image. And along with that is there a brush dynamic to control the gamma of a brush while painting? (This would be much like hardness for parametric brushes but for colour (stamp) type brushes would have some value). What do you mean by gamma? There is the Force output. It tries to emulate the force a brush is applied to the canvas with, that saturates some parts of the brush when applied. It has been part of gimp for ages, under the name of hardness but it is not really hardness as used in vector brushes so it has a new name now. -- --Alexia -- Sent from my mobile device ___ 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] Still GIMP @ LGM 2010
So, When I emailed about this subject last week, I've been told everyone was already booked up and talks registered: it looks like teh talk registration is not quite complete, and we have to fill in the details for the LGM programme. Who is intending to talk? Peter? GSoC mentors? (including myself)? We shouldprovide then some details ASAP. js -- -- Forwarded message -- From: Femke Snelting snelt...@collectifs.net Date: Thu, May 13, 2010 at 8:51 AM Subject: Re: GIMP @ LGM 2010 To: gwid...@gmail.com Hey Joao Any news on who will be there for Gimp :-) We're finalizing the program right now and it would be great to know more about your contributions. Here's what the programme looks like at the moment: http://ospublish.constantvzw.org/documents/LGM2010/LGM_programme_110510.pdf all the best + hope to hear soon Femke ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Still GIMP @ LGM 2010
On Thu, May 13, 2010 at 1:08 PM, Tobias Ellinghaus h...@gmx.de wrote: Am Donnerstag, 13. Mai 2010 schrub Michael Schumacher: On 13.05.2010 14:46, Joao S. O. Bueno wrote: So, When I emailed about this subject last week, I've been told everyone was already booked up and talks registered: it looks like teh talk registration is not quite complete, and we have to fill in the details for the LGM programme. No idea what the Saturday 100:00 talk is supposed to be, but for... Who is intending to talk? Peter? GSoC mentors? (including myself)? We shouldprovide then some details ASAP. ... there are two talk proposals in their wiki: http://create.freedesktop.org/wiki/A_first_outline_for_a_UI_for_a_fully_GEG Led_GIMP http://create.freedesktop.org/wiki/Writing_GIMP_scripts_and_plug-ins According to [0] those two are scheduled for thursday, yet there is still a half hour slot on saturday which just reads GIMP. So - maybe we should take this slot to demonstrate thenews in 2.7 master and GSoC projects? Who could do the talk? HTH, Michael Tobias [0] http://ospublish.constantvzw.org/documents/LGM2010/LGM_programme_070510.pdf ___ 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] Fwd: GIMP @ LGM 2010
On Fri, May 7, 2010 at 7:46 AM, Michael Schumacher schum...@gmx.de wrote: Von: Joao S. O. Bueno gwid...@mpc.com.br I think I have seen no e-mail on this list about LGM 2010 - it is due in a couple weeks. That's because everything has been discussed on IRC - the participants are registered, two talks and one lightning talk have been proposed, everyone has travel and hotel booked, ... ... and we've agreed on handling reimbursement with GIMP money. Ok; Since I had been absent from IRC, I know nothing of the discussions. I've got myself travel tickets yesterday. - Can you give me details on the hotel people are staying? js -- Regards, Michael -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Creating a new Layer
Hi Thales -- thank you for your feedback - we will take that in account while working in the UI - However, this need of yours can be easily implemented through a script - either in Python or Script-fu (if you are on Windows and have issues configuring GIMP- Python) -- this would give yiou this feature immediatelly (instead of you having to wait several months for a new gimp release). feel free to write further if you want more information on such a plug-in. js -- On Thu, May 6, 2010 at 11:24 AM, Thales img tha...@imgbrasil.com wrote: Hello, I have an idea and I'd like to know what you think about it. Let's suppose a situation: We make a 100 x 100px rectangle selection on a 2000 x 2000px, and we want to create a new layer to paint the rectangle, so when we ask a for a new layer a popup is opened asking Name, Width, Height, etc, for the new layer, for default the Width and Height values are 2000px² (our document's size), we click Ok and we have a new layer. My point here it is that we have a 2000px² layer for a 100px² object, and as I can see - as a user - a 2000px² consumes more performance(I don't know if it's Memory or CPU) than a 100px². So my idea is to have a option when creating a new layer; maybe a checkbox with something like: [__] Follow Selection's Size Did I make myself clear? Anyway, thanks for the attention, Thales -- Thales Oliveira - Img Brasil +55 31 (8365 3869 - 3309 8760) ___ 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] Fwd: GIMP @ LGM 2010
Moin - Hi folks - I think I have seen no e-mail on this list about LGM 2010 - it is due in a couple weeks. (I know I am at fault with the reimbursements for last year - lets get that moving as well) So, who is intending to get to Brussels? Can someone help organizing the lists? We also should have to plan GIMP activities beforehand. I just got the e-mail pasted bellow from Femke regards, js -- -- Forwarded message -- From: Femke Snelting fe...@constantvzw.org Date: Thu, May 6, 2010 at 4:43 PM Subject: GIMP @ LGM 2010 To: gwid...@gmail.com Cc: Jon Phillips j...@rejon.org, Louis Desjardins louis.desjard...@gmail.com, Nathan Willis nwil...@glyphography.com Hello Joao, I'm Femke, local organiser for LGM 2010. We're currently finalising the program and I was wondering whether GIMP team members would like to give talks, demo's or anything else? Do you have plans for sponsoring teammembers to participate in the Brussels meeting and if so, is there any way we can help to do this? Let me know! best, Femke -- Constant: Association for Art and Media | Rue du Fort straat 5 | 1060 Brussels Belgium | t/f +32(0)2 5392467 | http://www.constantvzw.org * * * * * * * * * C O N S T A N T V Z W ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] square brushes
On Sat, Apr 24, 2010 at 12:29 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Hi, An interesting issue was brought up by a user. It really isn't easy defining a square brush with a particular length of a side. For example, creating a square brush with a side exactly 2px large. Could anything sensible be done about that? (Apart from telling users they don't really need 2px large square brushes, that is :)) Hi Prokoudine -- Right now, I am afraid it would not be easy - and I don't see how someone could go and work on change the measurement on radius for generated brushes to side when the shape is square. However, a way to create a 2px square brush would be to make a 2x2px selection in agrayscale image, , copy it and edit- paste as - brush... It would be easy to have that as a plug-in, but I can't think of a way such a plug-in would not clutter the menus. However, now that I mentioned it, ther is a File - create[...] action that create a brush. (create brush from phrase) Maybe we could come along with some more 2 or 3 ideas to populate a file-create-brush... submenu. There an Exact square brush... could easily fit. Let's see whatthe maintainers and Peter have to say on sucha submenu, and throw in some ideas on whatthe other entries could be. regards, js -- Alexandre _ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-user] [GSoC] Student applications can be submitted, mentors please sign up
Hi Schumanl -- I am apply8ng as a mentor, as I intend to mentor Thiago's work on Siox integration and implementation of a second algorithm for segmentation - as can beseeen on his e-mails. On Mon, Apr 5, 2010 at 1:50 PM, Michael Schumacher schum...@gmx.de wrote: Hi, the student application period for Google Summer of Code 2010 is on. Applications can be submitted until 2010-04-09, 19:00 UTC 1. Students --- To apply, visit http://socghop.appspot.com/ and follow the instructions. 2. Mentors -- Sign up at http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010 and pay attention to your notifications. 3. Next important dates --- 2010-04-09, 19:00 UTC : Student application period ends 2010-04-21, 07:00 UTC : All mentors have to be signed up, all viable proposals have to have a mentor assigned 2010-04-21, 17:00 UTC : Application scoring period ends GIMP GEGL GSoC home page: --- http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/gimp Regards, Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Plug-ins http://registry.gimp.org | .de: http://gimpforum.de ___ Gimp-user mailing list gimp-u...@lists.xcf.berkeley.edu https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Hi:) The basic behavior of this tool would be: - you put a closed polygon on the image (not limited to 4 handles) - you deform the cage, the image is deformed accordingly - user can choice if the pixels can go outside of the cage or not. In the normal behavior of the Green Coordinates, the pixels can overflow the cage, due to the shape preservation. I looked through the paper and examples there were very impressive. This tool can be the tool of choice for many use-cases currently handled by iwarp plugin and perspective transform in a much more convenient and usable way. As a project it has great potential. Im thinking, it might make sense to implement it as a gegl op with UI in gimp. however, we dont have an example of such tool yet... Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? js -- -- --Alexia ___ 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] GSOC proposal: cage-based transform tool
On Thu, Mar 25, 2010 at 1:23 PM, Alexia Death alexiade...@gmail.com wrote: On Thu, Mar 25, 2010 at 6:12 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? Could you point me to the plug-in? I don't think Ive seen it before http://liquidrescale.wikidot.com/ It does the trick thatadobe sohowed off in the new photoshop yesterday -- it is quite well maintained - I keep the .pt_BR translation for it. Give it a try, it is worth it. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] remove layer should not force you to last selected layer
On Fri, Mar 5, 2010 at 3:05 PM, Akkana Peck akk...@shallowsky.com wrote: Luiz Felipe Moraes Pereira writes: Also I do not mind much about not having a selected layer after the deletion of a layer. But the forced viewer scroll down( or up ), depending of the last selected layer is a problem. This used to annoy me a lot, because I frequently want to delete, say, the top 5 layers. But once I figured out what it was doing, I developed a habit of clicking on the layers I want to delete in sequence before deleting. For instance, click on the 5th layer from the top, then the 4th, and so on until I get to the top; then click Delete 5 times. It sounds tedious but it doesn't take long at all -- certainly it's a lot faster than scrolling back up each time. Try it -- you may find that it solves the problem. yes, I do that as well. The new Layer Groups feature in 2.7 will ease this and several other workflows a whole lot. (For example, probably all the layers you are deleting, if more than one, would not be themselves part of the same group - you just have to delete the group) js -- ...Akkana ___ 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] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann s...@gimp.org wrote: On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: Yes, I will submit a proper patch. I'm new but I can figure it out. I mainly wanted to get feedback whether it was desirable. I'm not clear when a discussion of an enhancement should move to Bugzilla. More testing reveals other issues and test cases: First, most plugins have unguarded calls to register(), so importing some plugins from a plugin ends up reregistering a plugin, with a warning to stderr from the Gimp PDB but apparently harmlessly. I'm still exploring, eg whether the order in which plugins are loaded matters, whether the warning is only for local plugins, whether Gimp supports multiple registrations of different plugins from the same Python source, etc. I wonder if importing a plug-in from another plug-in is really something that we want to support. If the goal is to share code, then perhaps the code that is worth sharing should be factored out into a Python module that the plug-ins can import. Every Python program is also able to be a python module that plug-ins can import. We should preserve this feature of the language. (For example, one can implement an app with a comand line interface, and then just add a GUI in another file that uses the functions defined on the stand-alone first file). Sven __ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On Wed, Mar 3, 2010 at 9:07 AM, Sven Neumann s...@gimp.org wrote: On Wed, 2010-03-03 at 08:46 -0300, Joao S. O. Bueno wrote: I wonder if importing a plug-in from another plug-in is really something that we want to support. If the goal is to share code, then perhaps the code that is worth sharing should be factored out into a Python module that the plug-ins can import. Every Python program is also able to be a python module that plug-ins can import. We should preserve this feature of the language. What exactly does that statement mean for the problem at hand? Means that the language has a feature to make development easier: that is it eases up reuse of the code by requiring less source code fiels to achieve the same tasks. So - it is not usual for a Python developer to be required do factor out a fully working source code file, that can be used as a stand alone piece, in order to re-use parts of the code in that file in other applications. The language has a trivial, elegant and seamless mechanism to allow this. The problem at hand as I see is exactly to preserve this Python language feature in GIMP plug-ins. On the other hand, simply putting a python module that is not a fully functional plug-in in GIMP's plug-ins directory, would cause GIMP to issue error messages on start-up , due to failed plug-in initialization. All GIMP will see is an executable .py file along with the plug-ins. Having to provide a directory structure, hacking with import paths, etc...just because one wants to share, say a couple RGB-HSV functions in a set of 2 or 3 plug-ins is overkill. js -- Sven ___ 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] Gimp - prolog interface
Hi Ryan - I strongly suggest you learn python instead, and us it for your scripts, instead. It attends eveeryone of yoru requisites: - no dealing with pointers or memory allocation/deallocation - gimp data structures are provided as high level objects - the language syntax even allows for a funciotnal-like programing if you prefer that. (for example to interact through layers, you just do: image = gimp.list_images()[0] for layer in image.layers: #your code dealing with the layer object When you get to the pixels you have then as a byte sequence, you then convert to a bytearray (python 2.6) - to get all the green bytes for the pixels from such an array on a separate array, I could do: green =[1::4] Follow the tutorial in www.python.org docs, you could get proficient in the language in less than 1 hour - then check the pythons cripts that come with gimp for examples of the API use and pixel access. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP to be removed from Ubuntu Lucid Lynx?
On Thu, Nov 19, 2009 at 4:48 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Nov 19, 2009 at 9:45 PM, Thorsten Wilms wrote: I have been in that session and can confirm it. OK, but what session? At UDS? Yes, friend of mine was tehre, confirmed it too. (btw, it evenshowed up in slashdot). IMHO, stupidiest decision ever - they _want_ their users to be dumb and continue that way. As for me, up to today I used to recomend ubuntu to people I presented Free Software. (despite some ongoing really great flaws, like translating the name of special user folders such as Desktop and Documents). Now, with the promise of a GIMPless Ubuntu, I will burn some other distro for people to taste Linux and Free Software. Alexandre ___ 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] What would be a better set of default resources?
Getting back to the start of this discussion -- I am in talks with the new mantainer of a very popular brazillian GIMP comunity portal this week (Guilherme coordinating www.ogimp.com.br with ~20.000 unique visitors a day)-- he has resources of his own which could be made available eitehr in GIMP or in gimp-data-extras . Moreovr a call for help on these online comunities could result in a large number of contributions from Brazillian artists (most with poor English comunication skills) So it ocurred to me: maybe we could make a call for contributions for new resources, and some open voting mechanism. The top rated artwork would make it into GIMP as patterns and brushes, and some more could be made available in gimp-data-extras . The last call for contributions of this kind we had, taht I rememebr, was for the gimp 2.2's splash screen, and had a good number of nice submitions. Guilerme, me, and other brazillian Free Graphics software contributors could help to assemble the needed structure for voting + contributing in a few weeks - we could set some prdefined tags to help orient the contributions (like natural brushes, clip-art, and so on) and populate the gimp-data-extras package with them. (Of course I am talking about itnernational contributions, not only .br ones - some 'call for clip-art' well placed announcements could make it) So, any objections to something like this? If anyone think this might have drawbacks an alternative would be to make a low-profile 'trial' and put the results in a branch for review. js -- On Sunday 19 July 2009, Martin Nordholts wrote: Hi, With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources. Not being an artist myself makes me rather useless for this task. To get things rolling I thought I'd start a discussion on what a better set of default resources would be. A few things are clear: * The new default resources must fit the product vision [1] * The resources must be very general in nature * We can't have a huge set of resources since we need to keep the size of the tarball within reasonable limits * We not only need resources, we also need to assign tags to them I think we at least should: * Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px * Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources? / Martin [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision ___ 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] http post or ftp post
On Saturday 25 July 2009, Nico wrote: Hi Is it possible to send data (http and/or ftp) in a script-fu plugin ? Some examples ? Wich way ? Nico The Scheme intrpreter used in script-fu it is there because an scheme interpreter is tiny enough to fit inside the source tree. (And for historical reasons as well, of course.) There are no libraries or moduyle to provide the tiny-fu scheme with much outside the GIMP API and some basic file I/O. So, while with unixish systems it is possible to provide a pipe/socket setup to make tiny-fu scripts answer network requests, that is not the way to do it. For doing larger applications, you should use plug-ins in a language that can make full use of libraries and modules manintained outside of the GIMP project. The oficial high level language supported for GIMP plug-ins is Python, and it is easy to make data available via vairous network protocols using Python's standard libraries. There re also gimp bindings for perl (although I think this is currently unmaintained) and ruby should you prefer these languages. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
On Monday 20 July 2009, Sven Neumann wrote: Hi, On Mon, 2009-07-20 at 00:36 +0200, Martin Nordholts wrote: * Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way You can just remove those if we agree that they are not useful. I doubt that any script out there actually uses them. This is different for the main geometric brushes. They are actually used and it would be nice if we could add code that avoids breaking scripts if we decide to remove them. +1 from me for the removal of all brushes that only serve as an example but have no other value for the user. I d'be against the removal of the vintage pixmaped brushes. However, what I think would be a good solution for preserving compatibility would also take these out of the way of users, while keping then available for scripts or anyone who looks for them. Basically: we have to figure out a way of GIMP not displayin all available resources if no tag filtering is active. By figuring out a way, I mean an interface way. Then, woud be a matter of tagging the unwanted-by-default backwards compatible brushes with an specifc tag (like classic), that would not be shown. If changes in the current behavior of displaying everything when there are no tag filters are not desirable, the way to achieve this would be simply to tag the resoruces we want showing with default, and this tag could come pre- selected on the UI. js -- Sven ___ 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] What would be a better set of default resources?
On Tuesday 21 July 2009, Sven Neumann wrote: Why? Tell us a good reason then why we should keep them. On Tuesday 21 July 2009, Rob Antonishen wrote: One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp. Thanks Rob -- that is goog reason enough. Sven: Besides, with the current set, without these, GIMP woul be a 100% bw boring looking program - A litle bit of color in the brushes would be needed for this reason alone, IMHO. It is true that when lecturing on GIMP I usually to say that the best use for the Pepper brush is to help us locate the Pixel brush, right next to it :-) (but then, I'd actually favor a whole set of fruit vegetable brushes to ship by default with GIMP) Alexia also holds that they should stay in terms even more clear than Rob did: they help one experimentt with the brush dynamics, color combination modes and otehr painting settings in ways that generated brushes or monochrome + alpha brushes can't help. Now, my tagging proposal would just keep then available for people and scritps alike, while making then 100% non-obtrusive, - I don' t understand why you haven't commented on that. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
On Friday 29 May 2009, Martin Nordholts wrote: Akkana Peck wrote: I'd like a way of bringing up a Save-as or Export-as dialog from a Python script. There's no API for this currently, as far as I can tell. The Save and Export dialogs are rather tightly coupled to the core currently so it will not be trivial to extend the plug-in API to show and interact these dialogs but I would not reject patches that implemented it properly. Would be be possible to add an API for this, or maybe an optional argument in gimp_file_save and the corresponding _export function? IMO we should not reuse gimp_file_save() for this but instead introduce gimp_show_save_dialog() and gimp_show_export_dialog(). I am a bit worried however that plug-ins will abuse this power. In your case, why do you need to show these dialogs? Isn't it better if the user has to go through a single place to save or export? Certainly not -- the idea of plug-ins is to automate workflows! And a common enoguh use case is to save a modified copy of an image - or a series of images with diferences between them (although this would need a folder + file name pattern rther than =justa file path). Akkana: I've never missed callign the save or export dialogs because I normally use the PF_FILE and PF_DIRECTORY entry parameters for my plug-ins taht deal with file export. Aren't they (with gimp_file_save) enough for your use case? In the new framework, will gimp_file_save() fail if the filename isn't xcf? No, the existing API needs to be backwards compatible so even though it is unfortunate that _save() can be used to export, we need to allow that for the sake of backwards compatibility. / Martin js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API for bringing up a Save dialog
k!! The E-mail client is showing me unread messages from months ago as if they where New :-( Sorry for digging into this ancient thread. :-( js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brush rotation - abotu the chanegs on 10-feb-09
Hi, I am aware that it is a work in progress -- just to let you know (Alexia and others) - the changes in the two commits dated 10-feb-2009 got things a lot worse and less natural for me than it was before. I am nto complainign, I know a lot of tunning is getting in, and I am writing this just for feedback while you adjust it. Now, I f I paint slowly, the brush will suddenly reverse its angle - Also, if I mark the direction x angle dynamic, the painting angle does nto feel natural, and it felt before - at least when I use a brush that is oriented towards up like an up arrow, or the letter A - both behaviores were better previously. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brush rotation
For those of you who don'tṫ follow trunk closely or the irc channel, I can't resist the urge to tell that Alexia Death and Mich have been working on brush dynamics over the last few days - and have thus far added brush rotation. It now works both as a fixed factor and following painting direction. Yaii!! (as any brand new feature, it still buggy and error prone, but they are actvelyy fixing everything) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Travel expenses estimates for LGM 2009
So people, As for Louis'e-mail I had forwarded a couple weeks back, I am collecting the travel estimates for GIMP people who wants to attend LGM 2009 in Montreál. Please write me at gwidion(at)gmail.com Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] trunk - new status for empty images
2009-01-29 Sven Neumann s...@gimp.org * app/tools/gimptool.c (gimp_tool_oper_update): if the image is empty and the tool can't handle that, display a message in the statusbar telling the user about this. That works great! thanks, Sven. But when trying i I could not help bu tnote it also show upswht the text tool -- text tool should be able to work with an epty image, should'nt it? The move tool, o the other hand, is not displaying the message properly. I t does, however whe n I try to move a path on a 0 layer image - then, instead of moving the path it eels me it is expecing layers. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: LGM 2009 Travel cost estimation
Hi there -- just got this from Louis. I can handle the estimated costs and assemble a spreadsheet as I've done in '07. - So I'd like those of you who intend to go to Montreal on the beginning of May send me your travel estimates (please use the gmail address - gwid...@gmail.com as I've had blacklisting problems with this .br one) js -- -- Forwarded Message -- Subject: LGM 2009 Travel cost estimation Date: Tuesday 20 January 2009 From: Louis Desjardins louis.desjard...@gmail.com To: Bryce Harrington bryce@, Joao S. O. Bueno gwid...@mpc.com.br, mrb@ Hi Bryce, Joao and Craig, * Please feel free to reforward this email to the person in your team that could help gather the estimated travel costs for the LGM participants. So here we are! We need to establish a rough budget for now and for this I would need within the next 2 weeks a fair estimate of the travel costs per team. Please include the name of the developers and the amount for the flight or train or car to Montreal. This can be in Euros or USD, as needed. Try to be as precise as possible. My first rough bet is we're looking at 40K USD but it could be more or less... I need to know. Also, if anyone can give a hand with the sponsors, we would all be happy! Please let me hear some feedback. You can cc all so we all know who's in charge of what, who responded and what. Thanks! Looking forward to welcome you again in MTL! Louis --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp license
On Friday 09 January 2009, Martin Nordholts wrote: Michael Natterer wrote: On Fri, 2009-01-09 at 15:36 +0800, C Wang wrote: So finally, I hereby suggest to move to GPL3 asap. Comments from any developers appreciated. Hi I agree, it's about time we move to GPLv3 now. I am all for it as well! js -- - Martin ___ 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] Fwd: [CREATE] Suggested dates for LGM 2009 Montreal
On Sunday 09 November 2008, Sven Neumann wrote: Hi, On Fri, 2008-11-07 at 20:31 -0200, Joao S. O. Bueno wrote: May 6-7-8-9, 2009. LGM would start on Wednesday morning and end on Saturday, end of the day! That would mean taking at least four days off to participate in the conference. That makes it very hard for anyone who has a regular job. The format is under discussion, as are the dates. What do you think about proposing something like having teo core days on the weekend, and one or two days before that for end usre talks and workshops? Something like: thee mroe technical oriented, and inter-software operation talks for subjects like GEGL, the Create Raster format, etc..all would be scheduled on Saturday, and on Sunday we schedule inter-team BOFs and other thing, like the in the first LGM), and thurday and friday would have using the GIMP, doing great art with Inskcape, maybe a plug-in creation workshop, and such? (btw, at my regular job, if I am going to an itnernational conference, I can have the extra days off) Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: [CREATE] Suggested dates for LGM 2009 Montreal
So - anyone wnat a say on the proposed dates for LGM (bellow)? Regards, js -- -- Forwarded Message -- Subject: [CREATE] Suggested dates for LGM 2009 Montreal Date: Friday 07 November 2008 From: Louis Desjardins [EMAIL PROTECTED] To: Create ML [EMAIL PROTECTED] Hi all, Here are the best possible dates for LGM 2009. May 6-7-8-9, 2009. LGM would start on Wednesday morning and end on Saturday, end of the day! (maybe with a party?!?!) Before we make that the official dates, anyone with serious concerns about those dates, please speak up asap! Side note : we could move that from 7-10 including Sunday instead of Wednesday. But why not take Sunday to visit... or relax... of have a beer on a terrasse!!! :-) Or a poutine! ;-) Anyway, you let me know! Cheers!!! Louis -- Louis Desjardins Organiser Libre Graphics Meeting 2009 - Montréal --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
On Tuesday 04 November 2008, David Gowers wrote: Hi vabijou, On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 [EMAIL PROTECTED] wrote: peter sikking wrote: the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual. I would also like to see a dynamically updated list at the top of the list that shows the last 3-5 used blend modes under a heading of Recent:. This may be outside the scope of the OP's original suggestion, but for many users there are a select few modes that are used frequently, and having to dig through a long list slows things down. I am such a user, and I say: This is a change I do not want, it would reduce my working speed further. This is because of the way recently-accessed lists work -- the most recent is at the top. This means unless I am constantly selecting *the* most recent (instead of eg. 2nd most recent), where I have to click to achieve the same result changes, because my choice reorders the list. In conjunction with locking functionality (so that your later choices no longer change the order or content of the recent-list), this could be effective. I would honestly like similar locking functionality for the recent-filters-list .. the constant disordering is just so confusing and slow that I usually find it faster to select from the original menu path.. which defeats the purpose. David, as far as filters are concerned, I'd strongly, and that means __strongly__, suggest you to use keyboard shrotcuts to get to your filters. Yes, stopping ytour work to configure keyboard shortcuts is a major pita, and that is why most people donṫ do it in any software, even knowing it is possible. However, GIMP has setup a unique feature that was once available to all GTK+ applications: dynamic keyboard shortcuts. Just enable these once in preferences, and you will never again have to selct a single filter in the thrid menu level more than once. The tooltip on the edit-preferences-interface option that enable these shortcuts is self explanatory. As for layer combination modes...Martin, is there any clean way of allowiyng setting keyboard shortcuts to layer combiantion modes? That ḋ be a nice feature to have. js -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] make the layer name still
On Monday 03 November 2008, Martin Nordholts wrote: [EMAIL PROTECTED] wrote: hi guys and girls :) As far as we know the name, we still have to scroll the slider to reach it. So what is my purpose? Could we add another shortcut to make the layer name still? For example right button click. It would make my life easier. :) Hi! Edit - Preferences - Tool Options - Move Tool, Set layer or path as active Then you can select layers with the Move Tool. Actually, this is the only sane way of working with GIMP at all. I can't really understand why the default behavior had changed to the current one (not keeping the picked layer). Probably it was a matter of mimicking the main proprietary similar program once again. And even then, at the time of the change, I remember restoring the classic behavior as a tool option, and this was later changed from a tool option to a tool preference, and got hidden deep in the preferences dialog where it can't be found by anyone, unless one ask the developers thenselves (like it just happened). I remeber the excuse for hidding it in preferences was nto to polutte the tool options with many options. Right now, I have there: Move tool: 4 lines worth of options. Blend tool: 8 lines in the tool options Bucket fill: 15 lines in the tool options!!! (move tool would bump to merely 6 six lines of widgets with the option for the keep selected layer there in plain view of everyone). Anyone feeling like reconsidering this, unless we get layer groupign and a completley new way of getting to layers on gimp 2.8 ? js -- BR, Martin ___ 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] [CREATE] LGM 2009 Proposals
On Wednesday 15 October 2008, Louis Desjardins wrote: 2008/10/8 Sven Neumann [EMAIL PROTECTED] Hi, On Tue, 2008-10-07 at 10:39 +0200, Dave Neary wrote: I've previously proposed a committee made up of ex-organisers and the biggest attending projects. That is, a group of 6 with: Me, Louis, Kamila, and someone from each of the GIMP, Inkscape and Scribus (probably Sven, don't know who from Inkscape (Bryce maybe?) and either Peter or Craig). I don't think I will have time to become part of that committee. And I haven't even been at Montreal, nor do I expect to find time for next year's LGM. But I am sure we can find someone else from the GIMP team for the committee. Hi Sven, I am cc'ing the gimp dev list so we find a good soul from the GIMP team to be part of the LGM committee. If anyone is interested in representing the GIMP team, please don't be shy and show up here quick! We need to make a decision for next year's venue. A week ago, we thought 2 weeks would be fine to complete the discussion. So we have one more week from now. I propose that we make that decision by Friday, October 24. Is that ok? /me steps forward. I've been GIMP LGM contact person for 2007 (for 2008, I had been mostly unreachable, tough). If no one else is picking that, it would ok for me. As well, I am looking forward to bring LGM to Brazil - but not in 2009 - I am looking at a 2010/11 timeframe. Anyway, I will be talkign to the right people in a conference at the end of the month. (The same one Bolhs attended once, in Foz do Iguaçu) js -- Cheers! Louis p.s. I have made a slight update on http://create.freedesktop.org/wiki/index.php/Conference Please follow the Montreal link to find out. Sven ___ CREATE mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/create ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [CREATE] LGM 2009 Proposals
On Friday 17 October 2008, Dalai Felinto wrote: LGM in Brazil? This would be awesome. We have already the BlenderPRO www.blender.pro.br that is a one day Blender event. And I will look forward for this initiative. 2010/11 looks a little distance but I'm interested about the plans. I have the feeling that this is not the proper channel to specifically follows LGM discussion. João, there is another site/email list/... that you plain to put your ideas and actions regarding that? Yes, the create list: [EMAIL PROTECTED] [EMAIL PROTECTED], http://create.freedesktop.org/wiki/index.php/Conference Cheers, Dalai http://blenderecia.orgfree.com ps.: congratulations and thanks for the new GIMP. It's becoming a very stable/robust software. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python back-up files
On Saturday 27 September 2008, Chris Mohler wrote: On Sat, Sep 27, 2008 at 6:16 PM, Samuel [EMAIL PROTECTED] wrote: Another question from me: When I write a plugin, my text editor (kwrite or kate) creates a backup file named plugin.py~. When I start now the plugin in GIMP, it is executing the backup instead the original. Hi, I think you should file a bug against kwrite and kate - while it's a good idea to create backup files, I see no reason why they should have the execute bit turned on (even if the file you are editing is executable). Yes. I have filed such a bug some years ago. Never fixed that I remember. Onthe same day I flied the same bug against gedit - they did implement the fix some 18 months later or so. But as for kde editors, the only way to go is to delete the backup files by hand. :-( js -- Chris ___ 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] Splash proposal for 2.6
On Monday 22 September 2008, Aurore D. wrote: Hello, A while ago Jimmac asked me if I could try to work on a splash screen for GIMP 2.6. I did several proposals, and here is the one that has the preference: http://aurore.d.googlepages.com/splash_proposal Tell me what you think :) Cheers, Hi. Sorry - This is a beautiful image, but I don't think it would do a great splash screen. IMHO wilber's sleep would be too easily associated with the lack of some features that are waiting to be implemented for a long time - that among those who already know the program. Among those who don't know the program, it would be rather difficult to associate the sleeping wilber with a really great product. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 splash screen
There have been on the list a few propostions for splash screens. It is a quite hard decision to pick one above others. It is allright if one is quietly picked up, or developed under request by one of the long time contributors. However since we alrady have more than one proposal, and from project contributors, maybe tehre should eb a more formal process for choosing a splash screen? For Gimp 2.2 we made a widerepad contest, havign to select from hundreds of entries. Maybe this time we could just formalize a deadline, and having some people to pick one from the presented entries - but without making the widespread advertisement. I do volunteer for helping picking the best one, but I am ok if we just have a date and a single person picks one and commit it. I just don't think we will have the best choice if people sparsely send their entries to this list, and whoever feels compeled enough comment on it. There is the matter of having to publicly express teh motives why one feels or thinks an entry should not qualify (like I just did) - and that is annoying both for the proponent and for the one who comments negatively on the proposal. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should we replace the 'Zoom when res izing image window'-button?
On Sunday 10 August 2008, Akkana Peck wrote: Martin Nordholts writes: Hi There is a little button in the upper right corner of each image window with the tooltip Zoom image when window size changes. I have never used this and I can't figure out in what way it is useful. It's useful in that it lets you scale the window exactly as big as you want -- you're not limited to 25%, 33%, 50%, 100% etc. That said ... Does anyone ever use it? I don't (partly because I always forget it's there). I set the Resize on zoom preference, and usually scale with the +/-/1 keys. I suggest we replace it with a shortcut to the Resize window on zoom option which I find much more useful. Does anyone have any objections to this? Should some completely other feature be accessible through that button? It seems odd to devote space to toggling a preference like that ... in theory, the current functionality seems more useful since it lets you do something that isn't otherwise possible. But as I said, I don't actually use it very often in practice. And it's not very discoverable. I didn't know from the tooltip what it would do and only found out by experimentation. It might be clearer if the tooltip added a few words, e.g. Zoom image to fit window when window size changes or Zoom image proportionally when window size changes. I don'tṫ know how many people actually rely on this toggle. But this is a usefull behavior when you scale up small image by a 2 or 3 times factor (rather usefull), and could be anooying when scalling down. So maybe, one thing would be to make GIMP's defuaslt behavior to be: - if the image is scaled up and the window is smaller than a certain percent of the screen(like 60%, or space for the main window + dockables at the sides), the iamge window would increase in size - if the image is scaled down, do not reduce window size. (Or reduce to the minimum size where all menus would fit in the menu bar) js -- ...Akkana ___ 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] Enhancement request - Use alpha channel for non-transparent information
On Sunday 20 July 2008, Raphaël Quinet wrote: On Sun, 20 Jul 2008 21:22:11 +1000, Snake Arsenic [EMAIL PROTECTED] wrote: Okay I made a feature request at http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing a solution that will not remove any functionality. [...] Hi! Going beyond all of Raphael's excelent remarks, I still see some issues here : 1) The ability to ciew teh layer sans transparency and edit the alpha channel as if it where any other channel is provided in GIMP - you copy the alpha channel to the layer's mask, and edit it (the layer's mask). 2) The request indeed points a thing: GIMP _has_ the ability to set each channel visible or not - in the layers channel. If the image channel is disabled in the channels dialog, channel cvaleus are considere as zero for all display operations. However, setting the alpha channel to zero in this way - which is what gimp does -is useless - you just can't see anything in the image, as it is rendered with alpha = 0 for all layers. I'd suggest that when the alpha channekll si disabled in the channel dialog, image is rendered with alpha =1.0 (255) insetead. That would: a) enable the feature thought when the ability to run channel'son and off was included; b) Make gimp attend the requesterś (Snake) needs. Maybe the bug request should be chanegd accordingly? Moreover - I really think it is a more usefull (even if seldom used) behavior for disabling the alpha. What do you say of doing it? I think that it would be a big mistake to use the alpha channel for anything else than transparency. I assume that you are asking for this because you have some program (I don't know which one) that is incorrectly using the alpha channel to store bump map information or something else that is not related to transparency. It is likely that this program doesn't use a file format that supports layers or independent channels, so its authors of have decided to hijack the alpha channel in some existing file format. The correct way to solve this problem is to use layers instead of abusing the alpha channel (or maybe additional channels, but I think that using layers would be more convenient in this case). With layers, it is very easy to toggle the visibility of the image or the bump map layer, specular map layer or whatever else you are working on. So instead of extending the mistakes done by the authors of some other software, it would be much better to know what file format has been subverted, and to perform the conversion in the file plug-in: * When the plug-in loads a file that uses this strange format, it would convert the alpha channel into a layer and mark that layer (using a special name like the GIF plug-in does for animations, because that can be edited easily by the user if necessary). * You would then be free to edit the image in GIMP and modify the layer containing what should be visible or the layer containing the bump map. * When saving the file, the plug-in would detect that some layers have a special name and would then combine these layers in a way that can be read by whatever other program you are using. So I suggest that you: 1) Identify what file formats need some special treatment. 2) Check if there is a way to detect what files using that format are special, so that we do not have to ask the user every time if a file using that file format should be read in the intended way (alpha channel = transparency) or in the non-standard way (bump map). 3) Suggest improvements to the corresponding file plug-ins, instead of requesting major changes in the GIMP core. -Raphaël ___ 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] Enhancement idea: Snapshot tool for quick comparisons
On Thursday 26 June 2008, Akkana Peck wrote: vabijou2 writes: Image - Duplicate is an unacceptable alternative. The idea is to create a single window that allows the user to cycle through multiple (named) snapshots in any order he chooses to see large or small changes more readily. Image - Duplicate has so many negatives to this process that I don't know where to start. How about this? The first time, do Copy Visible then Paste as-New Image. Call this new image the snapshot image. After that, do Copy Visible then go to the snapshot image and Paste (then click New Layer). Now the snapshot image has all the snapshots as layers. To cycle through you need only turn layers on and off. Of course, if you did this all the time you could very easily automate the process: make a little script-fu that does Copy Visible, checks whether the snapshot image exists, then either does Paste as New or Paste + New Layer in the snapshot image, from a single menu item. k Please stop that. :-p I will finish the more usable layer group plug-in this weekend. js -- ...Akkana ___ 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] Enhancement idea: Snapshot tool for quick comparisons
On Thursday 26 June 2008, vabijou2 wrote: I tried posting this to the list first, but apparently the list was down, so I went ahead and submitted a bug (#540091). The text below is from that bug report, and I would love to have this idea discussed on the list for possible development. When editing photos I find that it is tedious waiting for the rendering to be completed as I turn layers on and off for comparing the effects of the changes I'm making. I would like to see a new tool/UI that would allow a snapshot to be taken of any currently displayed view and saved for comparison with other snapshots later. It would be good to allow these snapshots to be named. I visualize a list of snapshots, and clicking on each one displays it in a snapshot review window. This window would have zooming and panning capabilities. By eliminating the processing that I assume is required each time a layer is turned on/off, I would think that the snapshots could be displayed very quickly and make subtle differences between snapshots more apparent. Perhaps something like this might be done using the Copy Visible function and creating a display window with a list of snapshots displayed on the side? Hi there - I am improving the layer group plug-in that hacks some layer group functionality in GIMP. You can have a version of it at [1] right now - but I am working on a version featuring a dialog where one can trun the groups visible or invisible with a single click. That will still work on teh same image, but you can do image-duplicate if you need to see diferent versions at once. [1] - http://www.gimpstuff.org/content/show.php/Layer+groups?content=83137 js -- --- - Comment #1 from Martin Nordholts (GIMP developer, points: 14) 2008-06-25 04:29 UTC [reply] Hi Why not just use Image - Duplicate as the snapshot mechanism? If that doesn't work, please bring this up on the gimp-developer mailing list. Before opening an enhancement request the feature and solution should have been discussed there. Thanks --- - Comment #2 from vabijou yahoo com (reporter, points: 6) 2008-06-25 13:12 UTC [reply] The gimp-developer mailing list has had no activity since June 16, so it does not appear to be working. I've tried posting there, and my e-mails have been returned. I've e-mailed the gimp-developer administrator and had that e-mail returned. I posted it on nabble on June 20 and there it sits. I think I've done my best to work within the system, and the system failed me. Hence, I'm posting it here. Image - Duplicate is an unacceptable alternative. The idea is to create a single window that allows the user to cycle through multiple (named) snapshots in any order he chooses to see large or small changes more readily. Image - Duplicate has so many negatives to this process that I don't know where to start. Two major problems with Image - Duplicate immediately come to mind: 1) It would be a huge waste of memory, since it completely copies the image info (except for the History). 2) It scatters windows all over the place, making comparisons difficult. What I'm after is a fast-rendering, easy to use method of flipping through snapshots of my workflow. Shift-clicking on the eye-ball by each layer comes close, but it is slowed by the processing required during rendering. My proposal is a way to get around that and speed things up for the user. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC Status Report for pygimp
On Sunday 15 June 2008, Lars-Peter Clausen wrote: Thank you for the e-mail -- there is a lot fo thing going on. I am not shure if I understood the exact nature of the palletes and gradients problems you describe - but you have to take care to let they behave like python - even if it is not the most intuitive thing when one does not understand what python is doing. if palette.entries[0] = palette.entries[1] palette.entries[0].color = gimp.colors.RGB(0, 0, 0) From a python point of view it should change the color of entry 0 and 1. This is what should happen in pygimp. We should introduce a copy methotd to gimp colors, if they don't have. So one would do: palette.entries[0] = palette.entries[1].copy() to duplicate the entry. (this won't be a problem, and will be even less of an issue if it is properly documented on the palette and gradient classes doc strings ) * I have been looking into wrapping libgimpmath. But I'm not sure how to handle it. The matrix and vectors code looks incomplete and inconsistent. Some objects are GObjects others are not. hmmm..Python cando it is own math -- but it may be possible that are function calls that use the matrix structs and others as they are defined in libgimpmath - maybe you could use ctypes there? It is an easy wrapping around C dynamic libraries taht is made in python only at runtime (Ctypes is part of standard python distro as of python 2.5 so it won't increase our dependencies). On the other hand, if the structs desscribed in the libgimpmap/*h files are not usefull for other function calls made from python, just docuemtning what is available and suggesting how to do it in NumPy would be enough, IMO. Thank you for the post. I think it is a nice oportunity for everyone to see the money they make google win with their eyeballs is being well spent! :-) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
On Sunday 15 June 2008, TriKri wrote: Hi! I am wondering which data type GIMP uses to represent the color in a pixel of an image? 8 bits/channel? 12 or 16 bits? float? Hi! The gimop currently works with 8 bit per channel only. According to http://pippin.gimp.org/image_processing/chap_dir.html#id2525344, there seems to be some different representation types, but glaus is somewhat unknown to me, though. I’m having a bit of trouble myself deciding which type I should have in the program I’m going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if I use floating point values. In a new program dealin gwith images, you certainly should take a close look in GEGL - the Generic Graphics Library - which has been though from the beggining as a library to enable GIMP to work in other color dephs in a clean way. Most likely, if your program needs to perform operations in an image you will be fine implementing these operations in GEGL thenselves, and then havign the remaning of the program as a UI around the GEGL calls (or even as a GIMP Plug-in if the users of your programs are likely to do other things with the images before or after your program do its thing on them) If you should, by chance, use floating point representation of the colors, is there some function in GIMP to read a jpg image directly into an image with floats, instead of using some function already existing to read it into an image with 24-bit color and then convert it to floating point values? yes, GEGL can do that for you (but not GIMP). /Kristofer js -- (ps. http://www.gegl.org/ ) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Customizable Toolbar
On Saturday 14 June 2008, Sven Neumann wrote: Hi, On Sat, 2008-06-14 at 19:03 +0200, Ingo Ruhnke wrote: It currently only supports a single toolbar and isn't customizable via the GUI, but only by editing menus/image-toolbar.xml. In my opinion this is useless as long as it is not configurable by the user. And editing XML files doesn't count as being configurable by the user. And in my opinion, this is a 80% done feature that should not be simply called useless and disregarded. I myself had never missed such a toolbar, but as well, I am not a tablet user. From where it is, it does not seen it will be to hard to implement some drag and drop using the actions (configure keyboard shortcuts) dialog. I would agree that it imight be too late for consideration for 2.6, and of course we just can't just go bloating the UI, but I think shuch a toolbar would be highly praised and the UI team shoudl take a look at it. Moreover, once configurable, it could keep the most used tool icons, making the toolbox really optional, which is one of the ains of the whole set of UI large changes for 2.6. js -- One open question: Can menus/image-toolbar.xml currently be stored inside ~/.gimp directory, i.e. is there a way to customize those .xml files without messing around with the systemwide Gimp installation? No, there isn't. I dount that this would be implementable at all, at least not without changes in GTK+. Sven ___ 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] Little question about development
On Friday 23 May 2008, Michael Natterer wrote: On Fri, 2008-05-23 at 11:44 +0200, Marco D'Ambros wrote: Dear GIMP developers, BTW, Marco - GIMP's ChangeLog files are usally accurate to the last white-space. And the person who overssess that even whitespaces are correct is exactly Mitch. I am Marco D'Ambros, a PhD student in the university of Lugano Switzerland. I am working in analyzing the evolution of software system and a couple of years ago I was looking at the development of GIMP. I saw that a large number of commits in the GIMP cvs repository were performed by an account called mitch. I was wondering if that account was used by one developer only, who contributed with a lot of code, or maybe it was an account used by several developers which works as a kind of proxy. Heh, nope this is simply me :-) ciao, --mitch ___ 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] LGM 2008 - rooms are booked, all is well
On Thursday 01 May 2008, Michael Schumacher wrote: Hi, just wanted to let everyone know that the rooms are booked now (May 7th to May 13th; Joao: please contact me for 14th and 15th, I have asked for a single room as well but haven't booked it yet). Hi - I am around - I donṫ know how these apartmnents work - but maybe for just one person, booking a hotel would be simpler. If arrangements for a single person are on the same price range, then I am fine with the room anyway. Thank you very much for taking care of this! js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] LGM again
Hi Folks -- Soory for the long time offline. Schuman has been taking care of people willing to go to LGM at Wroklaw while I e been out. He passed me the names and costs, and there are very few people compared to other 2006, 2007. If anyone else of the GIMP Developers decide to go to LGM, please e-mail me ASAP. (If Schumanl have confirmed you, no need to contact me - his notes include the carpool leaving Berlin, for example.). ASAP == tomorrow! LGM orgs need to close their costs sheet. regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.
Hi Guillermo, On Mon 24 Mar 2008 14:01:00 Sven Neumann wrote: Hi, On Mon, 2008-03-24 at 13:34 -0300, Guillermo Espertino wrote: First of all, sorry if this is the wrong place or moment to post this. II think that integrating the separate+ plugin to Gimp would be a great GSoC project. Doesn't sound like it would be worth making this a GSoC project. In particular because that would mean that it would definitely not make it into GIMP 2.6. As far as I can see all that is needed for integration of the seperate+ plug-in is someone who volunteers to review the code and the user interface and to propose it for inclusion on this list. As we wanted to have this plug-in in 2.4 already, I wonder why this has still not happened yet. So, adding on to this - while only reviewing the code and the UI might be much less than expected for a whoe GSoC project, I perceive this as a valuable idea. Maybe adding to this review the implementation of some, or even more, of the features suggested could do for a Google Summer of Code. Guillermo, I would encourage you towards formalizing this application - try to summarize objectively what exists today and what do you plan to implement. Also, try some guestimates on a time frame for completing each task. The idea, bellow, of integrating it to the GIMP TIFF save plug-in is great and would make it really feel like part of GIMP. So, take a look at GIMP's TIff plug-in and giver your say on it. And of course, the separate plug-in should take into account ICC color profile magement, as implemented in the GIMP core (I reall don't know if it aready does that). And least - have in mind that the chances of approval depend very much on a favorable review of your proposal by the GIMP developers. You got some critics on your first e-mail, and some ideas as well. So use those in your favor and come up with a propose everyone here should like. regards, js -- Sven On Mon, 2008-03-24 at 18:01 +0100, Sven Neumann wrote: As far as I can see all that is needed for integration of the seperate+ plug-in is someone who volunteers to review the code and the user interface and to propose it for inclusion on this list. An alternative that we should consider would be to integrate the functionality into the TIFF save plug-in. But I will leave it up to whoever evaluates and proposes the plug-in here to consider this option. ___ 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] LGM 2008 - call for atendants
Hi Gimp folks! We are getting close to the 3rd edition of the ibre Graphics Meeting, where, over the last years, we have been organizing the equivalent of GimpConf as well. It will take place in may, 8th to 11th, in Wrocław, Poland. So, it is time for us to organize who is attending so that the conference and GIMP treasure can hep funding transportation fees. People interested in attending, please send me name, and a rough estimative of the travel costs to getting there (sometime nearby we will need more precise values, but I prefer to have a rough estimate as soon as possible) Note that in other years people where asked to put their names on a wiki page - this time, I am asking you to write me directly. We shall setup such a wiki page, but I am rather getting e-mails and preparing a list here without having to rely on the wiki. http://www.libregraphicsmeeting.org/2008/index.php?lang=en http://create.freedesktop.org/wiki/index.php/Conference Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation for brushes
On Tue 18 Mar 2008 09:38:26 jbaker wrote: it would also be nice to tie in scale and rotate (and any other changes) with gimp-python... That part comes last - when it is implemented in the core, calls for this should be added to te PDB (there are missing PDB calls for controling brush scale, and paint parameters as jitter currently). Once it is in the PDB, they wod be available from python, but also, I am working in implementing gimp brushes as python objects, and it would be trivial to add rotation support there once it is in the core. As for the User Interface for this, I think mapping curves from input parameters to brush/tool properties is the way to go. (that is, I can think of a curve mapping painting angle to brush angle :-) ) http://wiki.gimp.org/gimp/SummerOfCode2008ideas http://bugzilla.gnome.org/show_bug.cgi?id=119240 js -- ___ 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] Congratulations, your organization has been accepted in to the Google Summer of Code(tm) 2008T
There it is - we are in! :-) I should post some follow up to mentors later on. :-) I see no number of slots at this point! E-mail has been sent by google by the mentors I had added previously. AFAIK there is further room for mentors if anybody else is interested js -- - Congratulations, your organization has been accepted in to the Google Summer of Code(tm) 2008 [EMAIL PROTECTED] [EMAIL PROTECTED]Mon, Mar 17, 2008 at 4:47 PM To: [EMAIL PROTECTED] Congratulations! Your organization GIMP - GNU Image Manipulation Program has been accepted in to the Google Summer of Code(tm) 2008. You have been assigned as primary point of contact and as an administrator for your organization. Please make sure you review the information we have on your organization and about you by logging in to the Google Summer of Code(tm) 2008 web application at http://code.google.com/soc/mentor_step1.html. You can then visit http://code.google.com/soc/mentor_home.html to make any updates to your organization profile. Make sure you are logged in using your Google Account ([EMAIL PROTECTED]). Thanks. - Your friendly Google Summer of Code administrators ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC 2008 ideas
Hi - here are the ideas listed again. I had trimmed down the previous list, as there are things that simply do not sound attractive enough for anyone to pick. Ideas for Gimp-python and the UF-Raw plug-in have been added. And we are still lacking mentors for pretty much everything else. :-) Also, there is still a little time for adding some more ideas, or try to focus some more. Regards, js -- [http://wiki.gimp.org/gimp/SummerOfCode2008ideas] = GSoC2008 Project Ideas = '' Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it.'' Note to people who add stuff here: Please try to add information about a proposal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... == Tagging of GIMP resources == Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things and think of them by names for these collections, like sprinf flower brushes or fancy fonts. However, one resource can belong to more than one set, and there can be sets which are determined by other means than the content, maybe even without the user having to do anything manually - think Favorites, Most recently used and Most frequently used. It has been suggested that this should not be a finite set of categories, bug rather done by assigning tags. The tasks in this project include: * adding a way for gimp resources to be tagged * decide which types of resources (i.e. which types of gimp objects) should be tagged * find a nice way for users to manage tags (add them, remove them) * present tags in the UI (i.e. how do you show them in the brush list, font list, ...?) * think about how tags can assigned to resources (or resources to tags) == On-canvas text editing == Right now, the text tool opens a dialog window where the text has to be put, thereby creating a new text layer. Nearly every other option of the text tool - font, font size, color, line height, ... - is available in the text tool options dialog, so it would be nice to get rid of this dialog as well. There have been feature requests about being able to edit text directly on the image, like for example Inkscape does it. It may be that getting to the point where editing text on the image canvas is possible isn't that much of work, actually. But this is where the interesting challenges do begin: eventually, we do also want multiple styles in one text layer. This is not so straight forward anymore if your enter text in the image. Not present right now, so not having it isn't exactly a showstopper, but making it hard to ever get there is. And you will have to consider support for GTK+ input methods. They may be used to enter characters from languages (or, more precisely, scripts) beyond the simple Western scripts which define how our common keyboards are layed out. This is supported right now in any GTK+ text entry, not having it for on-canvas editing would be a regression. Tasks for this project include: * port the text core to PangoCairo * get on-convas text editing implemented * figure out if we do still need a text entry dialog (even Inkscape still has it in the properties of the text object) * make sure that GTK+ input methods work this this new approach * think about making it possible or not making it impossible to style the text while editing it this way == GIMP Python == mentors: Yosh or João With version 2.4, python becomes the preferred method of scripting plug-ins for GIMP. Python is an universal multipurpose cross-platform language, adopted as scripting language by several applicatives, easy to understand, with a feature rich set of standard libraries. GIMP python scripting is possible since 1999, before version 1.2 and it allows access either to GIMP's procedural database and to internal image pixel data, just like plug-ins written in C. However there are points that can be greatly improved. Things that can be done for a Google Summer of Code project: Properly map Gimp Widgets and objects to Python Wrap all libgimpwidgets to be acessible from python, so python plug-ins can have the same presentation as gimp components written in C (that is gradient and palette selectors, scale entries). Additionally map all remaining gimp objects to proper python objects, just as layers and images are already: palettes, gradients, brushes, patterns, fonts, Enhance the interface builder, add plug-in previews Add
[Gimp-developer] GSOC 2008 - ideas
Hi there! We have some ideas for Google Summer of Code project in the wiki, but all of tehna re dangling since last year. Mos t of tehm look good, but some may have been obsoleted in the current devel cycle, or would involve changes in code that is going away in the cycle. I am posting the full set of ideas bellow and asking for commetns on ideas, new ideas, and overall, people who would be willing to mentor a stundet through some of them. regards, js -- http://wiki.gimp.org/gimp/SummerOfCode2008ideas - [BOTTOM][TOP]GSoC2008 Project Ideas Please note that, although you are welcome to look at what is here, this is a workspace for mentors to write down and modify their ideas, and suggestions here should not be taken as necessarily viable projects until they have been finalized. Also, the fact that something appears here does not necessarily mean that anybody has volunteered to mentor it. Note to people who add stuff here: Please try to add information about a prorpsal's overall complexity and experience that could be helpful. E.G. experience with GTK+, image manipulation algorithms, web application development, ... Filetype registration There is currently no way to register a file type to open with GIMP from within GIMP itself. On some desktop environments and platforms, this makes registering types to open with GIMP awkward. We need a configuration GUI within GIMP, which does show the available types and/or file extensions, and a means (a backend) to register them according to the platform/environment. The latter should probably be modular and extensible, because this is different on each of them. Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, only sorted alphabetically. This greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. It has been suggested that this should not be a finite set of categories, bug rather tags. Create an SDI manager widget. Would allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.) Plug-in stability effort Tests have shown that it is possible to crash plug-ins when feeding them bogus data via the PDB API, for example when calling them from scripts (another interesting approach might be to run file loader plug-ins with [WWW] zzuf). Needed: a test framework to find the bugs, and then time to fix them. Additional file format plug-ins There is a number of file formats that GIMP should support, but doesn't or at least doesn't support fully, for example MNG. The MNG save plug-in needs to be modified to save images in MNG-LC profile. Then a loader can be easily written to work similar to the GIF loader. It also needs support for JPEG chunks. On-canvas text editing Right now, the text tool opens a dialog window where the text has to be put. Nearly every other option of the text toold is in its tool options dialog, so it would be nice to get rid of this dialog as well. Search-based menu browser The amount of menu entries in GIMP - either from plug-ins, scripts or internal functions - is huge. The name of a particular function might be easier to remember than its menu location. Being able to search for the function and applying it to the image without having to go through the menus can help (similar to Emacs' M-x feature). Unified UI for scripting We have three major scripting interfaces, Script-Fu, ?PyGimp and Perl-Fu. All of them allow to create an interface for a script easily, just by registering a function with their respective parameters. However, all widgets look a bit different depending on the binding. Redesign and reimplementation of Save and Export in GIMP. Change the semantics of Save and Save As so that images are always saved in the XCF file format. Only the native GIMP format really saves all the image information and allows to lossless continue editing later. So only saving as XCF should clear the dirty flag of the image. Saving to other formats than XCF is done by exporting the image. The File menu should have an Export menu item (and perhaps also Export As). Unit testing framework GIMP currently doesn't have a test framework that API changes or internal changes could be tested against. This is crucial to avoid regressions, especially with the major rewrite we will seen when GEGL is introduced. Work on GEGL [WWW] GEGL is a graph based image processing framework. It will be introduced into the GIMP trunk after 2.4 has been released. Processing is done by the nodes of the graph, which are implemented as so-called operations or 'ops'. A good introduction to the current state of GEGL is the [WWW]
Re: [Gimp-developer] script-fu menu
On Sunday 02 March 2008, Luis A. Florit wrote: * El 02/03/08 a las 15:25, Laxminarayan Kamath chamullaba: I am not a GIMP developer, though I have been a spectator on this list for a while now. I suggest that you specify exactly what you are trying, and what exactly you are looking for. A detailed work-flow and a UI mock-up image would best describe what you want. Specify the problem.. not the solution. Sorry, I thought I was clear enough (did I specify the solution??) What I want to do is what is pretty standard in these cases: My script-fu has a lot of options, and a check box to use default values of these options. I want these options to become grayed out when the check box is checked. Just that. My other question was if it is possible to add text to a script-fu option window that is not related to an option of the script. But I do not know if these are possible in script-fu, and I didn't find a complete enough reference for script-fu. Thanks again, L. Hi there, At first, I have toḋ say to you it is likely these chanegs are not going to be made. The auto-interface build up in script-fu, perl-fu and python-fu is a convenience, and presented as is. More sofisticated plug-ins should use GTK+ to draw their own interfaces . Unfortunatelly this is no option when you are using Scheme (script-fu). If you do your work in python, however, you have, in the opinos of many people, and in my strong opinion, an easier to work langauge than Scheme, and will gain the flexibility to build your custom interface as you please. (And still, won't miss any flexibilit otherwise avaliable only to plug-ins written in C). Ah, there are also Ruby bindings, should you prefer Ruby than Python. And finally, so that you don't think you are alone in this desire for greater control on the authomatic interfaces, I have thoguth about that as well, and it is possible that something more or less like what you are asking to be implemented for Python plug-ins. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 66, Issue 3
On Sunday 02 March 2008, Luis A. Florit wrote: Ok, this is what I suspected. Someone here told me some time ago to try python-fu, but my script is almost done since long time ago, and I am not sure if python-fu would do it. Of course C would... Thanks Bill! Python-fu is capable of everything script-fu is, an dmost of what C is, as well. Translating a script-fu to a python-fu is mostly a matter of re-arranging (and dropping) parenthesis :-) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC 2008
Hi, Iṕ've been talking to Schumanl and Prokoudine this afternoon, and they agreeded to indicate me to be GIMP's Google Summer of Code Admin (mostly: contact person), for 2008 edition. I am willing to pick the role, but I have to know if everyone agrees, or if someone else would like to do it (Iḋ'd still colaborate). Regardless of that the window for registration starts next Monday and it will be somewhat short. So we have to get things ready at http://wiki.gimp.org/gimp/SummerOfCode2008application and even more important (as this application is most bureacratic stuff I can fill in), we have to arrange the ideas we'd like to see implemented in this years' project - here http://wiki.gimp.org/gimp/SummerOfCode2008ideas We have up to March, the 12th to have this in order. If I am in charge I'd prefer doing it even earlier. This is not unmutable though, and even applying students can suggest their own ideas. And more important than filling the application, and having the ideas, are _mentors_ ! So people willing to mentor students, please do so at the application wiki page, and possibly indicate which ideas you would like to mentor. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Libre Graphics Meeting 2008 - call for presentations
On Monday 25 February 2008, kamila giedrojc wrote: Dear GIMP team, Hi, I've added a talk I'd like to give there: http://create.freedesktop.org/wiki/index.php/PythonTalkLgm3 It goes well beyond GIMP, but I hope it is ok for everybody. js -- Libre Graphics Meeting 2008 is few steps from here. We are currently working on the program. I'm sure I can count on you. This week we are waiting for the emails from everyone who did not yet contact us, and would be interested in giving a talk, or conducting a workshop. I'd be grateful to get your responses up to March 2nd. You can also subscribe as a presenter in conference wiki http://create.freedesktop.org/wiki/index.php/Conference Don't hesitate to contact me if you have any questions. Cheers! Kamila --- Kamila Giedrojc Official Organiser Libre Graphics Meeting 2008 - Wroclaw kamila.giedrojc [at] gmail [dot] com www.libregraphicsmeeting.org ___ 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] tagged resources such as brushes, gradients, etc
On Friday 18 January 2008 15:08, William Skaggs wrote: In any case, let me ask a basic sort of question about user interaction. Suppose I'm a user, painting with a set of brushes. I decide that I want to use a certain grunge brush. (Let's say I have a specific brush in mind, but all I remember about its tags is that it is a grunge brush from a set I imported last week.) What are the steps I have to take, as a user, in order to find the new brush and start using it, without losing access to the other brushes I am currently using? (I'm willing to assume that if I load everything with the grunge tag, I will be able to find the brush I want in there.) Of couse, this will have to be refined by the UI team. But I have two ideas for it: one would be abel to type in tags into a dialgo shwing brushes without lossing the ones already selected. Like, just typing more tags on the tag text entry widget, and having tehn combiend as or. The other one, is to allow the user to pop up another brushes dialog, in which he perfomes hs searches, He then can either select brushes from this ne dialog, or drag brushes from there to the first one, where they are transparently added to the group tag in use on the first window. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
On Thursday 17 January 2008 14:45, William Skaggs wrote: From: peter sikking [EMAIL PROTECTED] chiming in here (getting back to speed). [...] Peter! Great to hear from you again! I absolutely agree about the virtues of a tagging system, but I fear that the difficulties are not being appreciated well enough. Here, for example, is just one of the problems: Problem: should tags be stored as part of a data file, or in a separate tags-database? separate tags database - which might be a xml file, I think. 1) If they are stored as part of the data file, then this calls for a new file format for every sort of gimp resource object, and changing tags calls for file system operations. ok - this won't happen. 2) If they are stored in a separate database, keyed by file names, then there is a great danger of losing the linkage between tags and object. If, for example, the user renames the directory holding some brushes, all of the tags for those brushes will be lost. The only way to prevent this sort of thing from happening is to make sure that all operations on resource files are mediated by Gimp (or some new utility program) that will make sure to keep the tags in sync with the data files. If for some reason a user's tags database gets corrupted, it will be a major disaster. I think we just need to worry about it being a minor disaster. I can think of recover scripts that could be written to restore some tags, in case of directory renaming, for example. There are many other issues of the same sort, which I don't believe have been thought through. I don´ t think so. It looks plain straightforward for me. I have worked with many web systems that reference filesystem paths for images, for example, and never had a maintanance problem due to that. Besides, yes, gimp would need some kind of scanning through resource folders, and possibly group all resopurces tehre under an all flag. That is needed so that one can download resources and add then to GIMP through the filesystem. The bottom line is that introducing tag-based resource organization is like setting up a virtual, non-hierarchical file system. The ordinary file system may be weak in comparison, but it is extremely robust, and users know how to manipulate it. A new tag-based file system can't possibly be robust until it has had an extensive testing period, and therefore exposes a user to the worst of all disasters: a corrupted file system. The solution I favor is to build a tag-based system *on top of* a filesystem-based system. That way: 1) The tag-based system can be built gradually, instead of being imposed all at once on a flat set of files. A flat set of files become a flat set under one tag in teh worst case scenario. 2) The user can manipulate files using ordinary filesystem operations without fear of wrecking gimp. Yes, that need to happen therefore the folders where resources are expected to be, as they are today should remain, IMHO. 3) A naive user who doesn't understand tags will still be able to use Gimp without having to learn about tags at the very beginning. This one is for Peter. In short: yes, there should be resources visible in a default GIMP install, first use. Maybe we could name a Basic tag for these start-up resources. A drop down for the most used tags could be fine as well. 4) A corrupted tags database will still be very bad, but won't make Gimp completely unusable. Indeed. As I said, the scanning should be made at gimp-load, and any resources found should be mapped to a default tag. Using something as simple as a hash of the entire file data could preserve all tags even when resources where moved across directories (rescanning hashest might need an explicit action) regards, js -- -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
On Wednesday 16 January 2008 17:42, William Skaggs wrote: This mixes together two separate issues. Tags are, as I have already agreed, an excellent way of doing a search mechanism. They don't get rid of the need to have a workspace, though. Suppose I want to switch back and forth between five very different brushes. Must I remember and select a set of tags each time I switch? That would be very unpleasant. No, whether or not there is a tag-based search system, there still needs to be a way for the user to maintain a workspace holding a limited set of arbitrarily chosen brushes. What about using...tags... for that? The idea of such a workspace would be that it would display brushes containing a certain tag. In teh above use case, I'd just apply a one-of-five-very-different-brushes tag to all the brushes. For this to make sense it _must_ be very easy and fast to edit a resource's tags. But that could be refined later on the development. Actually, maybe it would make sense containers that could show several types of gimp data in a single dialog. So, if I am working with trees, I'd have palettes, gradients, and brushes which show up in a single window. More than one such dialog should be allowed to be open at once, so that a user could simply drag and drop things around (and internally, tags are added/removed transparently). So ... the workflow for the case of use above would be something like: create an empty multicontainer, go to another multicontainer displaying only brushes (the equivalent of today's brushes dialog), type in a tag to the first brush, drag it into the empty new container - repeat for brushes 2-5. Start painting. When it is over, destroy the current container, or just save it under an arbitray tag name for later re-use. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at the 24C3
On Sunday 16 December 2007 09:48, Sven Neumann wrote: Hi, as announced earlier, some GIMP developers are going to meet at the 24th Chaos Communication Congress (24C3) http://events.ccc.de/congress/2007/ We already discussed that travel costs for such events should be reimbursed from GIMP donation money. For this event, I would like to transfer EUR 1000 from the GIMP account. We would use that money mainly for travel costs. Should something be left, we will spend it on pizza. Does anyone see a problem with that? Please object now or never... never. :-) Enjoy it! js -- Sven ___ 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] dir(gimpfu.pdb) crashes
On Monday 03 December 2007 06:19:21 am Jayesh Salvi wrote: Hi, I am trying to see what all methods gimpfu.pdb offers, by running dir() operation on it. But it crashes as follows: [EMAIL PROTECTED] plug-ins]$ PYTHONPATH=$PYTHONPATH:/usr/lib64/gimp/2.0/python python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type help, copyright, credits or license for more information. import gimpfu dir(gimpfu.pdb) LibGimpBase-ERROR **: gimp_wire_write_msg: the wire protocol has not been initialized aborting... Aborted [EMAIL PROTECTED] plug-ins]$ rpm -qf /usr/lib64/gimp/2.0/python gimp-2.4.2-1.fc7 Does anyone know if this is known error? Is someone fixing it? I won't be using dir() operation in final code, but can this abort happen in other situations as well? Gimpfu module can only be imported from a python console which is run under GIMP itself. Try that from the python console within GIMP. js -- Thanks, Jayesh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changing the shape of a text layer
On Sunday 02 December 2007 01:29:39 am William Skaggs wrote: From: [EMAIL PROTECTED] I like the idea of having this functionality available. I have tried the patch and it seems very capable. There appears to be bug which presented itself when I did the following: ... Thanks for the bug report. I'll take a look at it. As a general comment, I would point out that this interface might present a problem in the future when in-place text editing is implemented. Since the primary function of the tool is text input, perhaps it would be better to require a modal key (ALT?) when adjusting the frame so that, in the future, unmodified mouse clicks could be used to specify cursor location and text selections. I hadn't thought about this, but it seems to me that it would be simpler to distinguish between clicking (used in in-place editing) and click-and-drag (used for modifying shape). I actually dislike the idea of having clicking modes - We might have clicking locations - ike, clicking in the handlers always do resize, and just draw the handlers so that no text falls inside them. Certain programs that do use the two modes for editing and dragging the text container are an absolute PITA to use exactly due to this. (OOo anyone?) js -- But in general I am absolutely delighted to leave that sort of question to the wisdom of Peter and his cohorts. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option for the fill tool (feature suggestion/request)
Hi Shin, I'd hardly find this useful but for some very specific patterns. Instead, I'd suggest you tried using layers and layer masks in your workflow, more or less like this: once you select the area to be filled, create an empty layer, create a layer mask on it, choose from selection (and empty your selection afterwards) There you are - you now fill the whole layer with your pattern and transform it however you like, with translation (not move tool), scaling, rotation, etc... js -- On Thursday 22 November 2007 02:14:56 pm Shin Diggar wrote: Sorry, I'm not a programmer so I wouldn't know how to do this myself but I'd like to suggest a new feature for the fill tool. How about an option to use the cursor position as a start point for tiling fill-patterns rather than the top left corner of the layer? Perhaps this could be greyed-out when fill mode is set to colours rather than patterns. I still want the whole layer/selection filled, but wherever the cursor is when I click it is where the top-left pixel of the filling pattern should be aligned to. I'd find this useful sometimes, would anyone else? _ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 ___ 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] Exporting Vectors to a SVG file
A Thursday 15 November 2007 14:27:30, Lionel Tarazon Alcocer escreveu: I am developing a plug-in which makes use of SVG files to store Gimp Vectors. The Import functionality is quite straight-on due to the gimp_vectors_import_from_file(), but I haven't found a function which works the other way around. Is there a function which exports paths/vectors to a SVG file or string? Given that this is quite straight-on at the GIMP GUI (right-button over a path, Export Path), I was wondering if I had missed it at the API. thanks Hi, I have a python script that does this. It has not been updated for the new vectors API in gimp 2.4 however. Anyway you can take a look at a simple translation of gimp bezier curves to svg equivalents, without using gimp internals: http://www.pion.com.br/~gwidion/paths.tar.gz js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
A Sunday 11 November 2007 20:48:27, peter sikking escreveu: but the real question is the priority of this yet-another-feature. something like geometry tools integration has a much higher priority than this. There eason I proposed this at this stage is that I have this feature complete minus UI and XCF saving in my GIMP tree. It has been like that for over an year when I was told it was too late to make it into gimp 2.4. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
A Monday 29 October 2007 16:24:11, Sven Neumann escreveu: I suggest that we keep brainstorming for the 2.6 roadmap for another week and then collect the ideas. It would be nice if we could end with a list of well-defined tasks. When that list is collected, I would like to discuss which of these tasks should be put on the roadmap for 2.6. Hi Sevn and others, I have been obn the process of moving myself to another city over the last few weeks (almost complet now, just waiting for my mobile nad main machinne to get here). ] As soons as that happens I should consolidate my work hours and spare a few of then for GIMP. The feature I'd like to work on is a brush stroke pannel to be able to set up stroking with curves for relating pressure, speed, angle, etc with opacity, size, jitter, color, etc... One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Angled guides - was Re: 2.4 and how to continue from here
A Friday 09 November 2007 13:01:06, você escreveu: Hi, On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote: One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. I would like to get some feedback from the UI team and from some artists on this. And of course the patch would have to be reviewed before it is committed. I am not yet convinced that this is an important feature and I also have the impression that it's just added ad-hoc without seeing the big picture. It certainly has the potential to cause a lot of problems. I had never added a UI for it - I add then through scripts. And except for bugs with the guides thenselves (which i ironed out as I developed then), I never had any side effect from using them. Snapping to these guides or intesections of these guides and others works fine. If tehre are potential greater problems, just a larger userbase would be able to detect it, and then we just fix it, or remove the feature if it needs very large changes to other program areas to work properly. And rest assured I would not commit it without having an ok from you first. Of course I'd like more feedback from users and the UI team, but nearly everyone I had mentioned this had liked the idea. It is of little use in a program like GIMP where free handed drawing is not emphasized, but sometimes it is just nice it is there. (like for stamping a brush repeating it at a gven angle). My idea for UI is just writing some code for the rotate tool to be able to rotate guides, just as the move tool can move guides. i think that once tested this won't get in anyone's path and will be a little nice feature for GIMP. regards, js -- Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
On Sunday 05 August 2007 06:45, [EMAIL PROTECTED] wrote: Hi, On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris wrote: I am getting an error linking gimp-gap svn in a 64bit enviromment, in both trunk and gap-2-2 branch: That's a problem with the copy of libavcodec that is included with GAP. You better disable support for libavcodec when configuring gap. For GAP 2.4 we should include a recent version of libavcodec. Sven To expand on Sven's answer a little, the FFMPEG project does not provide a stable API; therefore the GAP includes the source for a specific snapshot of the code and staticly links to it. The snapshot in the GAP's tree is from 2005 ; it needs to be updated and the GAP code modified to employ the new FFMPEG API (also for 64-bit support and GCC4 compatibility as well). Wolgang Hofer, the main developer of the GAP, is working on that update but he does not have direct access to the Internet right now. It may be a few months before updated FFMPEG support is available but it is being worked on. In the interim, I would suggest disabling libavcodec support and using an external utility to convert your frames to video. Hehh..that is a bit too much, ain't it? It actually _did_ build when I tweaked the Makefiles in the library dirs (and only there) to include the -fPIC GCC directive. 64 bit, GCC 4.1.1 It is not like this will only work in 2010 or 2012. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
On Friday 03 August 2007 17:18, Sven Neumann wrote: Hi, On Fri, 2007-08-03 at 23:54 +0400, Alexandre Prokoudine wrote: Are you absolutely sure that you removed the fuzzy marker after updating the translation? Yes, I am. OK, please try again after updating from SVN. I added some missing calls to gimp_plugin_domain_register(). That should fix it, but there might be more places affected that need a similar fix. Sven I am getting an error linking gimp-gap svn in a 64bit enviromment, in both trunk and gap-2-2 branch: /usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC bitstream.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libavcodec.so] Error 1 when doing: gcc -shared -o libavcodec.so bitstream.o utils.o mem.o allcodecs.o mpegvideo.o jrevdct.o jfdctfst.o jfdctint.o mpegaudio.o ac3enc.o mjpeg.o resample.o resample2.o dsputil.o motion_est.o imgconvert.o imgresample.o mpeg12.o mpegaudiodec.o pcm.o simple_idct.o ratecontrol.o adpcm.o eval.o dv.o error_resilience.o fft.o mdct.o mace.o huffyuv.o cyuv.o raw.o h264.o golomb.o vp3.o asv1.o 4xm.o cabac.o ffv1.o ra144.o ra288.o vcr1.o cljr.o roqvideo.o dpcm.o interplayvideo.o xan.o rpza.o cinepak.o msrle.o msvideo1.o vqavideo.o idcinvideo.o adx.o rational.o faandct.o 8bps.o smc.o parser.o flicvideo.o truemotion1.o vmdav.o lcl.o qtrle.o g726.o flac.o vp3dsp.o integer.o snow.o tscc.o sonic.o ulti.o h264idct.o qdrw.o xl.o rangecoder.o png.o pnm.o qpeg.o vc9.o h263.o h261.o msmpeg4.o h263dec.o svq1.o rv10.o wmadec.o indeo3.o shorten.o loco.o alac.o wnv1.o ws-snd1.o aasc.o a52dec.o liba52/bit_allocate.o liba52/bitstream.o liba52/downmix.o liba52/imdct.o liba52/parse.o liba52/crc.o liba52/resample.o -lm -lz -ldl -Wl,--warn-common -rdynamic (trying the suggested fPIC makes build halt early on.) ___ 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] [Gegl-developer] PyGEGL instant crash
On Thursday 19 July 2007 19:28, Kevin Cozens wrote: David Gowers wrote: Using Python 2.6, typing 'import gegl' at the interpreter prompt causes the following crash to immediately happen: [snip] I'm also pretty sure that the bug lies in the pygegl module, as I've compiled and used many other modules for Python 2.6, with no problems, and I ran the babl and gegl tests successfully (and the gegl editor works okay too) I have only tested pyGEGL with the 2.4 version of Python. It possible (or very likely?) that something has changed in the 2.6 version of Python. I don't have the 2.6 version installed at the moment so I can't investigate this further. Python 2.6??? The stable python is 2.5.1 - there is not even mention of a 2.6 release on teh python.org pages. David: do you mean python 2.5 instead? regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: LGM 2007 Final Report - Help needed
-- Forwarded Message -- Subject: LGM 2007 Final Report - Help needed Date: Thursday 10 May 2007 12:10 From: Louis Desjardins [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED], Joao S. O. Bueno Calligaris [EMAIL PROTECTED], Plinnell [EMAIL PROTECTED], Cyrille Berger [EMAIL PROTECTED], Boudewijn Rempt [EMAIL PROTECTED], Igor Novikov [EMAIL PROTECTED], Alexandre Prokoudine [EMAIL PROTECTED], Jon Phillips [EMAIL PROTECTED], Andy Fitzsimon [EMAIL PROTECTED], Martin Poirier [EMAIL PROTECTED] Hi guys, (I am writing to a few of the team leaders and please feel free to relay this request to the person in your team you feel would do the best job to gather the resquested information. Also, if you think I have forgotten somebody or a project, please let me know. — Thanks!) LGM 2007 has been a tremendous experience! I hope all travellers had a good trip back home! Thank you so much for being in Montréal with us! Thank you so much for all your encouragements and enthusiasm! We now must think about the final report of this year's LGM. This is important to keep track of what was accomplished and to prepare next year's edition. It is of upmost importance for our sponsors, to secure next year sponsorship, to let them know how and why LGM is important for the participating projects. From each team I would ask a short but enough detailed summary of what was accomplished since last year. It can be both quantitative and qualitative. I doesn't need to be a long text. Since it is the first time we do that (I think) I leave it up to you. We will make it a nice layout and will include some nice pics as well. The report will help us draw attention on LGM and will also serve as a reference point for the teams. Thank you for responding quickly. We'd like to have the report done within a few weeks from now. Cheers! Louis -- Louis Desjardins Organisateur / Organiser Libre Graphics Meeting 2007 - Montréal www.libregraphicsmeeting.org/fr www.libregraphicsmeeting.org +1 514 934 1353 HAE / EDT GMT -4 --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
On Tuesday 01 May 2007 00:15, Mark Lowry wrote: I'm working on a script in which it would be advantageous to use the mouse to click on an image and have the pixel coordinates captured as an input. Right now I have to manually enter the coordinates for four points, which is a tedious process. Is there a way to capture these coordinates as inputs to a script? If not, where is the appropriate place to suggest a feature request for this? Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -- Thanks . Mark __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] Pixel coordinates input type for script-fu?
On Tuesday 01 May 2007 17:05, Mark Lowry wrote: --- Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -- I have thought about doing that and I think that is the way I will have to go. I'm confused with how to extract elements from the vector returned by gimp-path-get-points. I thought I understood that (vector-ref vector k) was the way to pull the k-1 element from the vector, but when I input (vector-ref '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on vector-ref. What do I need to do to be able to extract a value from the result of (gimp-path-get-points image path)? oh man.,.. 2 things: 1) I do python-fu, not Scheme (script-fu) - so I have erased from my mind the esoteric ways of getting elements out of a vector or array in Scheme. btw, if your plug-in is of any complexity, unless you think your time is being well spent as you exercise your mind around how to get and use data with scheme expressions as an extra exercise, I'd suggest writting it in python. If you are on windows, that will only work witht he developemtn version of GIJMP, though. But it has the advantadge of letting you worry with your problem instead of the language _and_ your problem. 2) this very API is being obsoleted in GIMP 2.3.x - there are all new vector manipulation calls in place, that can finally deal correctly with multiple stroke vectors (not needed to fecth just one or two coordinates anyway) In python, an interactiuve session exploring the return values might just display: img = gimp.image_list()[0] pdb.gimp_path_get_points (img, a) (1, 0, 15, (103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 529.480002, 102.039996, 1.0, 529.27428571428572, 101.679995, 2.0)) v = pdb.gimp_path_get_points (img, a) points = v[3] points (103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 529.480002, 102.039996, 1.0, 529.27428571428572, 101.679995, 2.0) points[0], points[1] (103.03428571428572, 101.01142857142861) (the are the prompt, not part of the language) -- Bill...could you see if it iyou can add a simple api for retrieving the sample points? I think this will bother no one at this point, it is starightforward as you said, and...we want to get 2.4 out, so it has to be done real soon. js -- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to change the active current tool from a plugin?
On Wednesday 25 April 2007 17:27, Laurent gauvrit wrote: hello everybody, I work on a hopefull edge detection plugin for gimp and i need to change the active current tool by a button in my plugin. Anyone know the answer??? Yes. The answer is: it is not possible at the moment. Sorry for that. A plug-in can itself use the tools, , but it can't change most things in the UI context. js -- thanks lolo _ Windows Live Spaces : créez votre blog à votre image ! http://www.windowslive.fr/spaces ___ 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] how to call gimp procedure from text terminal ?
On Monday 23 April 2007 21:02, stu seven wrote: +I asked this on the google group, but with no answer yet... How can a menu item or gimp procedure be called from a text terminal, with a graphical gimp session already running ? I know that, using a function name, and parameters, this can be done in batch mode, for instance... however, all Im looking for is to remotely open the function dialog, via the text terminal. Is this possible... or... some other way of opening the menu item dialog besides clicking on it ? Such a terminal would have to be done from within GIMP. The easiest way I can think of doingthis is writing a python plug-in that will listen to a socket and execute what you type in there once you connect to that socket. thanks ___ 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] Fwd: [CREATE] Standard RAW File Format (fwd)
-- Forwarded Message -- Subject: [CREATE] Standard RAW File Format (fwd) Date: Tuesday 17 April 2007 05:36 From: Kai-Uwe Behrmann [EMAIL PROTECTED] To: libtiff - Liste [EMAIL PROTECTED], Kunst Tuepfel [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Hello, just to inform all the digital camera RAW developers out here. Sorry for any duplication. -- Forwarded message -- Date: Fri, 16 Mar 2007 18:18:33 +0100 From: Dietmar Wueller [EMAIL PROTECTED] To: Dietmar Wueller [EMAIL PROTECTED] Subject: Standard RAW File Format -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as a member of the ISO TC42 (technical committee for photography) working group 18 (electronic imaging) standards group I would like to inform you that the existing Tiff/EP (ISO 12234) standard for images captured by digital cameras is currently under revision. The Adobe DNG format was derived from this standard and the group has Adobe's permission to incorporate modifications and developments made for DNG in the new standard. In addition the standards group is asking all interested people for comments and requirements - which are not part of the current DNG or Tiff/EP standard - to be incorporated in the new standard. If you have such please forward them to me by the end of April. Hopefully we will soon be able to provide a standardized file format which meets everybody's expectations and gets a wide support by camera manufacturers, software vendors, and photographers. Please forward this message to everybody who may have contributions to the revision. Best regards Dietmar Wueller Image Engineering Dietmar Wueller Augustinusstr. 9d 50226 Frechen Germany phone +49 2234 912141 fax +49 2234 912142 [EMAIL PROTECTED] www.image-engineering.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+tFp7Olj94xfLY4RArPaAKCtTyhP4rWNjRwfNmb5WW7B9TrtngCfYKMm qSARyPFRA4/lBFuQE54LTm0= =1Yi9 -END PGP SIGNATURE- ___ CREATE mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/create --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] internal representation of a selection
On Friday 30 March 2007 13:10, Helmut Jarausch wrote: Hi, can somebody, please, point me to some information on how a selection is represented (internally) within Gimp and how one can access this. Is it represented by a matrix of bits? If the selection has many holes it's not sufficient to have a lower and upper bound for each pixel row. I need the selection exactly for my attempt at a new healing tool. Many thanks for a pointer, Hi Helmut - the selection is a matrix of bits, yes - a drawable object, with one byte per pixel, meaning the strenght of the selection at that point. the call gimp_image_get_selectin available for plug-ins can return you the selection as a drawable object. Through the UI you can simply enable the quickmask (click on the little square to the left of the hor. scroll bar on an image window), to transfer the selection to an editable image channel. js -- Helmut Jarausch. ___ 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