Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration
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. Joao: Unfortunately I'm not a coder. I'm not even a student :) Just throwed the idea to see if someone could be interested on it and take it to GSoC. About the plugin itself, it already provides profiles management. It's completely functional but it's limited in the separation methods. The real deal with improving this plugin would be adding point gain, black generation, overprint threshold, curves, etc. The integration part is definitively too simple and not-so-atractive to start a GSoC project, as Sven pointed out. Thanks for your kind reply. Regards, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] batch-processing gallery
Hi, On Tue, 2008-03-25 at 10:06 -0700, Bill Skaggs wrote: If you can build the svn-trunk version of gimp (which by the way is a very useful thing to do if you are interested in soc), you can find there a new gegl tool that allows a long list of operations to be performed, but has a pretty weak user interface. (It's very buggy too right now.) Turning this into something that users can actually work with, and use for gui-based batch operations, would be a pretty valuable contribution. The GEGL tool is just a playground for developers. Something that allows us to play with GEGL. I don't think we ever want to expose this to users. So I am not sure if we should base a GSoC project on it. It's correct though that some ideas for a possible batch function could be taken from this tool. Sven ___ 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, On Tue, 2008-03-25 at 20:20 -0400, Robert Krawitz wrote: A lot of what was described about separate+ is already present in the Gutenprint plugin for GIMP (and I think also in Cinepaint), and also in PhotoPrint, which is a standalone application layered on the Gutenprint core. I'd rather beef this up, and provide the necessary machinery in CUPS to take advantage of it, than have a specialized plugin for one application. These capabilities are just as critical in all applications. For that matter, if saving the separations to a TIFF file (or multiple TIFF files) is really important, it's a capability that could be added to Gutenprint and again made available to all applications. I don't see how saving a CMYK TIFF file from GIMP could be implemented in the printing layer. Let alone the fact that GIMP doesn't depend on Gutenprint. Sorry, but we really need this as a GIMP plug-in. Otherwise we simply can't provide the user experience that we and our users expect. Sven ___ 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, On Wed, 2008-03-26 at 04:07 -0300, Guillermo Espertino wrote: About the plugin itself, it already provides profiles management. Profile management should be left to the GIMP application and to widgets provided by it. It doesn't make sense if every plug-in does its own thing here. It's completely functional but it's limited in the separation methods. The real deal with improving this plugin would be adding point gain, black generation, overprint threshold, curves, etc. The integration part is definitively too simple and not-so-atractive to start a GSoC project, as Sven pointed out. Yeah, this sounds like it could be more of a GSoC project. But I am afraid that we would have a hard time finding a mentor for this. I don't think any of the GIMP developers know enough about printing. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: batch-processing gallery
Well, I guess I'm a little confused about the actual purpose of GEGL. It sounded like it would provide a more formal and robust interface for GIMP's image processing. GEGL might be a good choice if the current tools are hard to interface with, but I really wanted all filters, for example, accesible to the user. It just seems like a waste of time to reimplement many of them using GEGL unless they all will be reimplemented anyways in the future, in which case I wouldn't mind implementing a lot of the filters, etc. I just think that it would be easier using the current filters and migrate them to GEGL later if needs be. Josh On Wed, Mar 26, 2008 at 2:01 AM, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Tue, 2008-03-25 at 07:40 -0600, Joshua Stratton wrote: Well, I do not know the current status of GEGL in GIMP's code, although I do believe it is the right way to go (from the GEGL presentations I have seen). I was assuming much of GEGL's implementation would be transparent to the user such as filter operations (as in the user wouldn't know if GEGL is doing the convolution or the original implementation). I guess it would pretty much depend on GEGL's integration status during the project. Looking at the current GIMP snapshot, it looks like GEGL is already integrated into at least a good chunk of the code. The current GEGL integration is minimal. Let me try to outline how batch processing in a future GIMP would work: Whatever you do to the image is represented as a graph. If you are doing a series of operations on an image, then your graph boils down to a load operation, a chain of manipulations and a save operation. Now if you want to apply the same chain of manipulations to another image and save it to another file, all you need to do is to change the filenames in the load and save nodes. That is how batch processing in a future GIMP would work. You wouldn't need a dedicated UI for it. You could just say, do this same thing that I just did with this image with all images in this folder. I'm assuming I could do it all with GEGL if it is a complete image-processing API. I was not planning on having the user use any XML like GEGL could process, but I certainly could add it. I would need some feedback from other developers as to what would be a good interface, but I envisioned something similar to Adobe's Lightroom, where photos were easily browsable, stackable, and hopefully most of GIMP's operations (as opposed to a select subset) could be applied to the group. Well, you could do it with GEGL. And all GEGL operations could be applied to the group. But all GEGL operations would need a user interface to specify their parameters. And GEGL doesn't provide that user interface. How So you would end up coding a completely new application and that doesn't sound like a good proposal for a GSoC project. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] batch-processing gallery
Hi, 2008/3/26, Sven Neumann [EMAIL PROTECTED]: Whatever you do to the image is represented as a graph. If you are doing a series of operations on an image, then your graph boils down to a load operation, a chain of manipulations and a save operation. Do you mean every stroke path like interactive paint tool MUST become an graph nodes ? Or do you mean only some specific operations (one that is suitable for batch) are represented as gegl node, and rest of the operations can still modify image directly ? If we chose first policy, the operation nodes quickly be flooded with enormous amount of stroke path history for users who use GIMP as a paint tool. I believe that we should classify operations into destructive ones (like paint brush) and non-destructive ones (like filters and rotations etc.) , and user can use combination of destructive and non-destructive operations in some ways. Or we should allow users to blit a part of the nodes into newly created image to save memory space by discarding some of the operation history. Please let me know the treatment of the destructive editing operations in future gimp. -- Souichi TAKASHIGE ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] batch-processing gallery
Hi, On Thu, 2008-03-27 at 00:55 +0900, Souichi TAKASHIGE wrote: Do you mean every stroke path like interactive paint tool MUST become an graph nodes ? Probably not an individual graph node, but it will be kept in a paint operation node which itself stores each stroke so that it can be edited later. At least that's the theory. As far as I know Pippin is currently working on a paint core in GEGL. I suggest that you ask further questions about this on the GEGL mailing-list. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ‘no image’ window: progre ss...
hey GIMPsters, let me give you an update here. in the last 10 days the concept and spec has matured quite a bit. the feedback and plain old bug reports, both here and on the IRC went into what is being built right now. check it out when you have the chance. thanks, --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp-Perl memory leak
Hi, I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB. If the image is not deleted in the script, then after the same amount of images created the size of the swap file is of 900 MB. I would be interested in eliminating the swap file or at least limiting its size. I think it should resize itself, but this doesn't happen. Is there a setting in gimprc for this? Thanks, Andrei ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Perl memory leak
Andrei Simion [EMAIL PROTECTED] wrote: I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB. If the image is not deleted in the script, then after the same amount of images created the size of the swap file is of 900 MB. I presume you meant 2.7 GB. I ran into a similar thing some time ago, working with a modified version if gimpressionist that created and deleted lots of images. I think probably there is a bug somewhere responsible for it, but I never managed to figure it out. In any case, of course, Gimp 2.2 is no longer maintained and won't be fixed. You'll probably have to replicate this in Gimp 2.4 or 2.5 to get anybody interested. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Perl memory leak
Andrei Simion wrote: I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB. I have done some work on gimp-perl in recent months. A new version of gimp-perl is in the works. I still need to finish testing of the build and packaging of it. I would be interested in a script that can demonstrate the problem. I have a client that uses gimp-perl with 2.2 and I'd like to alert them to the problem if it can be reproduced. I am even more interested to find out if the problem still exists with gimp-perl from SVN and a 2.4 version of GIMP. -- Cheers! Kevin. http://www.ve3syb.ca/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172 |Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
