Re: [Gimp-developer] The Mark Shuttleworth offer
Hi, On Fri, 2004-03-19 at 01:38, Daniel Rogers wrote: > More details have come forward about the Mark Shuttleworth offer. Mark > Shuttleworth made up his mind and decided to fund myself and Calvin to > work on GEGL and GIMP/GEGL integration. Until today, I didn't have any > specific details on the offer. Congratulations to us! This is good news for the future of GIMP/GEGL. A big thank you to Mark for sponsoring us. > The final thing I want to do here is to seek out what people think about > putting a "sponsors" section on the new webpage, and devoting some space > to thank Mark Shuttleworth for this (and hell, our past sponsers too). > Also, I want to prepare a press release about this, and would like some > help with that. I can write the content, but those current press > releases are so purty, and I'd like any new one to look like them. If you provide the contents I will be happy to help formatting the press release using LaTeX as I've done with the current press release. > First my milestone list, as I sent to Mark Shuttleworth. Please tell me > if it is sane. >From a quick read through I think the milestones look sane when taking into consideration that one developer will work on them full time. The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread. Sincerely, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] l10n warning
Hi there. I am updating the translation because some strings had changed on the last couple days. I thought it is interesting to mention that the string: #: app/gui/image-menu.c:1744 Which is Other (%s) ... Is copyed from another one (as fuzzy) by gettext as a _"Other (%d:%d)" from somewhere else. That means that in a lot of languages we will have a %d %d in a printf-like string that will get just a string as a parameter. Well, some of you will certainly know better than I what this means - and I hope it only would be an issue in plain Console C printf's, not inside the GIMP. Nonetheless, better be safe than sorry. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no ppd file usable with gimp2.0pre4?
From: Sven Neumann <[EMAIL PROTECTED]> Date: 13 Mar 2004 13:10:08 +0100 Frank Noack <[EMAIL PROTECTED]> writes: > Its the same problem that i had before. It works fine with build in > language (en) if i use it in german it fails. Now i can print with > Turborint but without ppd-file. I show at > http://gimp-print.sourceforge.net/ Did you update to gimp-print 4.2.6 yet ? Frank, have you tried the patch I sent you? This is the last outstanding 4.2.7 release stopper and I'd like it tested so that we can proceed with our release. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers <[EMAIL PROTECTED]> wrote: > More details have come forward about the Mark Shuttleworth offer. Mark > Shuttleworth made up his mind and decided to fund myself and Calvin to > work on GEGL and GIMP/GEGL integration. Until today, I didn't have any > specific details on the offer. You are bringing very good news here. Congratulations! > The final thing I want to do here is to seek out what people think about > putting a "sponsors" section on the new webpage, and devoting some space > to thank Mark Shuttleworth for this (and hell, our past sponsers too). Do you think that it should be on developers.gimp.org, or www.gimp.org? Maybe both? Anyway, I think that it would be nice to mention our sponsors somewhere. Maybe this should be discussed on the gimp-web list? > [...] The ones I really need to run past everyone are > 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I > am not going to be working on anything that would be outright rejected > by the gimp developers. 1 and 2 are gegl territory, and I know I'll > accept that work :-) Most of the milestones seem reasonable, but I have some questions about how the GIMP integration would take place, especially regarding the plug-ins. Many of the current plug-ins are making more or less the same assuptions as the core regarding the bit depth of the images, etc. There is a lot of code to be re-written in the plug-ins and I expect them to be broken as soon as the format of the tiles is changed. I also expect that it would be difficult to fix them before some parts of the core become more stable. I suppose that you did not include the plug-ins in your activity planning because that would be too much work for a single programmer (but maybe I am underestimating you? ;-)) So I am wondering how we will be able to coordinate the work and update the plug-ins. Will there be a phase during which there would be a call for volunteers for updating all of the plug-ins once the new interfaces to the core become more mature? Or would it be possible to provide some kind of backwards compatibility so that the transition could be spread over a longer period, with some plug-ins using the new API while some others would still use the old one through a compatibility layer? Anyway, I am glad to see that the offer for sponsoring is becoming more concrete. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The Mark Shuttleworth offer
So, More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. I am pretty sure the offer essentially the software development bounties described here: http://www.markshuttleworth.com/bounty.html. Mark has said Calvin and I should divide 30,000 dollars between each other and the milestones. We (Calvin and I) are paid when the milestones are delievered with the following conditions (from the Mark's bounty page): "Once the code is accepted, to the satisfaction of people identified before you started (for example, the project owners if it involves work extended an existing project), we pay the agreed bounty." Calvin and I have already decided how the money will be divided between each other. What I want to do here, is first announce that Mark is funding GEGL (and thus the GIMP) and second to pass my milestones through the list to make sure they are sane and achieveable. Keep in mind that this milestone list is not a list of work for other people (though other people are free to work on it). It is a list of tasks which I am bound to fufill, contractually, and are things that I _will_ do. I am not obligating anyone to do anything. I am simply confirming that my plan is acceptable, before obligating myself to it. The final thing I want to do here is to seek out what people think about putting a "sponsors" section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. First my milestone list, as I sent to Mark Shuttleworth. Please tell me if it is sane. My time for completion estimates are assuming one programmer working full time. They are also only relevent it that I will use them to help divide up the bounties. The bounties themselves don't have a time limit. You may also make suggestions on how I should divide up the bounties. I'll just divide by the time I think I'll need by default. The end result of these milestones is to add features Mark wants, so I can change the way or order I get to them, but the features achieved should not be changed. The order givin is the order I think I should approach things. The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) 1. Finish gegl/image () Goal: gegl/image is the directory that holds the data access libraries. It should contain the abstractions for high-bit-depth and multiple color space manipulations. () Time for completion: about 1-2 months -- a. finish up my nearly completed tile caching code -- b. implement color space classes -- c. write gegl-image can gegl-color 2. clean up nodes () Goal: This will bring gegl all together. Modify the existing node system to handle the new image data types, and get a strong core of basic image processing nodes. Also, build a few image i/o nodes and actually build one or two gegl test programs that actually manipulate image data. One might argue that this step would "finish" gegl. () Time for completion: 2-3 months -- a. make nodes work with new gegl-image stuff -- b. design processing model that can handle multiple data types and sample models -- c. implement the base set of core filters new filters -- d. implement different bit depth processing functions (prioritizing by what the gimp needs) -- e. make gegl work 3. begin gimp integration () Goal: This puts abstraction in place to actually start handling image high bit depth and color management. () Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor. 4. start adding deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float). 6. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painti
[Gimp-developer] Press Pack, take II
Hi, I've reformatted the upcoming Press Release and the About the GIMP documents which Raymond Ostertag, Eric Lamarque, David Neary et al has prepared. The results are available at http://brix.gimp.org/files/presspack/ Comments and suggestions are very welcome. If you have large changes for the documents please provide them as 'diff -u' patches against the .tex files. Sincerely, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: image processing
[EMAIL PROTECTED] (2004-03-18 at 0738.14 -0800): > If you need open source, then pretty much, your options are: [...] > I know there are a few other small image processing languages. These > are all projects with pretty difference focuses. And one or the other > may be more suited for you. Another lib that floated in IRC the other day: http://cimg.sourceforge.net/ GSR PS: A nice method (remove noise, fix "holes") that uses CImg is http://www-sop.inria.fr/odyssee/research/tschumperle-deriche:02d/appliu/index.html ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image processing
[EMAIL PROTECTED] wrote: Hi Gianluca, This question has really nothing to do with Gimp unless you want to use already existing gimp functionality. You may e.g. read an image into memory though the gdk_pixbuf functions, and then access the pixel data through gdk_pixbuf_get_buf(). Working with the gimp API is more complicated as the data may be stored tiled, and your algorithm will need to do special case treatement of the boundries. You might also want to have a look at GEGL that provides a graph paradigm for image processing, and which will be used in future versions of GIMP. Whether someone has written optimized algorithms for it, I don't know. Um, if this person needs a solution now, then GEGL is not for them. IF this person whats to help write a solution, then GEGL might be good for them. Regards, Dov On Thu, Mar 18, 2004 at 10:12:02AM +0100, Mattiroli, Gianluca wrote: Hi to all, I am interested in doing some filtering on an image stored in memory as a Pixmap, with particular attention to the time constraints. Could someone give me some advice about the resources available for this purpose? Thank you. Well, all of our image processing attention is focused on GEGL which, while progressing, is not yet able to actually process images. If you need a solution now, and are not interested in helping write one then you have a few options (these are a bit off topic though, so don't expect any help with these beyond this). If you need open source, then pretty much, your options are: Vigra: http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ Vips http://www.vips.ecs.soton.ac.uk/ Rivl http://www.cs.cornell.edu/zeno/projects/rivl/Rivl-mm95/mm-95.html PDL http://pdl.perl.org/ I know there are a few other small image processing languages. These are all projects with pretty difference focuses. And one or the other may be more suited for you. If you want to try closed source solutions there is: Matlab IDL Java Advanced Imaging SGI Image Vision . . . many others . . . -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp.app application bundle
On Wed, Mar 17, 2004 at 06:08:41PM -0800, Aaron Voisine wrote: > It's been uploaded to ftp.gimp.org/incoming. > > I'm not familiar with wiki. Did you mean for me to upload > the application bundle to the wiki? I thought wiki's were > just for blogging and hypertext. > http://moinmoin.wikiwikiweb.de/UploadFile it has to be added to the gimp wiki, however. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp.app application bundle
Aaron Voisine wrote: It's been uploaded to ftp.gimp.org/incoming. I'm not familiar with wiki. Did you mean for me to upload the application bundle to the wiki? I thought wiki's were just for blogging and hypertext. Wikis can be used for (almost) anything. There is no big difference between uploading text via a textarea field or uploading a file via a file input (and if there is one, you should switch to another programming language ;) I don't think that binaries (besides images etc) should be uploaded to the gimp wiki, though. HTH, Michael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-help i18n
Hi, I've now checked in my changes to the GIMP help system that make it possible to use help written in the user's language. This closes bug #136996. Here's a short explanation of the implementation: I've added a gimprc token called "help-locales". This isn't exposed anywhere in the GUI yet and it defaults to NULL. But it should allow us to configure things in a more flexible way later. If you want to play with this, you can for example request help in french, swedish, german, english with descending priority by adding the following line to your gimprc: (help-locales "fr:sv:de:en") In case this new option is not set, the locale is taken from the user's environment. When a help page is requested, the help is searched in the list of locales. In case no matching reference was found, a fallback reference is searched in a second walk over the locales. If there's still no help, the help plug-in checks if the default help domain (en) is available at all and will try to give a helpful error message. It would be nice if the gimp-help-2 team could add pages for missing help content and add or similar to the gimp-help.xml files for the different languages. As soon as these fallback pages are available, it would be nice to have a new help snapshot that people can install with 2.0rc1 to give this stuff some testing. I already changed the Makefile in the gimp-help-2 module to install the help files according to the new scheme that we discussed here earlier. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image processing
Hi Gianluca, This question has really nothing to do with Gimp unless you want to use already existing gimp functionality. You may e.g. read an image into memory though the gdk_pixbuf functions, and then access the pixel data through gdk_pixbuf_get_buf(). Working with the gimp API is more complicated as the data may be stored tiled, and your algorithm will need to do special case treatement of the boundries. You might also want to have a look at GEGL that provides a graph paradigm for image processing, and which will be used in future versions of GIMP. Whether someone has written optimized algorithms for it, I don't know. Regards, Dov On Thu, Mar 18, 2004 at 10:12:02AM +0100, Mattiroli, Gianluca wrote: > > Hi to all, I am interested in doing some filtering on an image stored in > memory as a Pixmap, with particular attention to the time constraints. Could > someone give me some advice about the resources available for this purpose? > Thank you. > > Gianluca > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] image processing
Hi to all, I am interested in doing some filtering on an image stored in memory as a Pixmap, with particular attention to the time constraints. Could someone give me some advice about the resources available for this purpose? Thank you. Gianluca ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
