Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Future Of The GIMP

Posted by ryuzaki0 on from the bring-out-the-gimp dept.

LinuxNews Team writes: "Sven Neumann and Michael Natterer prepared an RFC about GIMP. We learn that there will be three branches in CVS: 1.2.x branch (stable GIMP), 1.3.x ( devel GIMP but not many new features) and 1.9.x (VERY devel GIMP with whole new structure, GEGL and GCim stuff). Looks like GIMP 1.2.0 is on its way to the users. Check out the RFC."

6 of 119 comments (clear)

  1. One over plugins by Sludge · · Score: 3

    I've been playing around with the design of a terrain engine. For those who don't know the basics of heightmap engines, the obvious thing to do is to have a grid of vertices. The height of the vertices is defined by a bitmap image, where each pixel's grayscale intensity represents the height of the vertex.

    The result is that a grayscale image can be created in The Gimp, and the output sent to my (and many other) terrain engines after saving a file. This is an unsatisfactory amount of feedback.

    I'd been doing some thinking about making a real terrain editor when it struck me that I would probably be recreating most of the tools and filters in The Gimp, but at a decidedly lower quality. I then realised that what I wanted to do is the opposite of plugins, additional filters, Perl-Fu and Script-Fu: I wanted to throw out the buffer where all the filters and tools are rendered to, and replace THAT with a plugin to the other end of The Gimp.

    I am interested in replacing the framebuffer in The Gimp with a AF_UNIX socket which transmits the framebuffer data over to another app, which would be in this case, my terrain. I would be able to paint modifications onto my terrain with all of The Gimp's tools.

    I'm pretty busy with my website these days, as we just went live, but I'm definately interested in looking into the code for The Gimp soon enough to see if this is feasible.



  2. Question... by redhog · · Score: 3

    Does this tree-based rendering thingy mean that it would be possible to implement a tree of layers, instaed as it is now a stack of layers, that is, that layers could be grouped into "meta-layers", to which the same things (like opacioty, mode, colour balance, etc) could be applied as to real layers? I have missed this feature in gimp.

    Perheaps it would allready be possible to implement (just a bit messy?). I don't know. I am a developer, but I have never looked at the gimp sources...

    --
    --The knowledge that you are an idiot, is what distinguishes you from one.
  3. GIMP really needs an auto-nude script-fu by Hairy_Potter · · Score: 3

    Where you can take an image of a foxy female, and then have the script-fu trace her clothing, remove them and replace them with the appropriate flesh tones.

    You'd have to allow customization though, for nipple and aurolae size and color, as well as pubic hair color, shaping and or lack of.

    Once this gets done, though, I then need many screencaps of a certain George Lucas movie.

  4. A whole new structure for Gimp? by _outcat_ · · Score: 4

    Can you elucidate on this "whole new structure"? Or is not enough about it known yet? Taking a look at the information at

    http://plugins.gimp.org/gimp2/doc_components.html it says:

    libgimpwidgets: core-independent widgets used e.g. to build libui widgets (similar to gimp 1.x's libgimpui)

    but I really cannot stand it when graphics programs change drastically and add "functionality" (on the level of the user interface) that replaces other things that I'm used to. For instance, I really liked PSP3. I really did. (OLD, old stuff we're talking about here.) But I coulddn't stand PSP4.

    I'm reasonably sure the GIMP guys are smart enough not to change things around too drastically, but it's a concern of mine, since I really enjoy working with and playing with The GIMP as it is. I don't want to have to update to a newer form that I really don't like to get the latest neat things.

    Just a concern of mine.

    --
    Angry IT woman in big clompy boots. And talking lint!.
    1. Re:A whole new structure for Gimp? by neutrino · · Score: 5
      The changes that are planned for 2.0 were discussed at Gimpcon this summer. There is a review of the planned new features. For those who are too lazy to read the page, the following is a short rundown:
      • It will use the GEGL, or Generic Graphics Library for pixel manipulatio
      • The rendering pipepline will be tree-based instead of a simple stack
      • The program itself will become much more modular in design -- Model View Controller
      • Plugins and app will communicate via CORBA
      • Generally more flexible -- possible integration with vector-based tools and video editing capabilities
      This is, as you can see, all backend work. Obviously, some changes will have to be made to the interface, but the result will be a vastly more powerful system. If they can successfully implement all of these ideas, then the GIMP would be, in many ways, the most technologically advanced image manipulation program in the world.

      Also, you should see the code as it stands in the 1.x series. It is obvious that the program has evolved to its current state and was not designed to this point.

      --neutrino

      --
      History has the relation to truth that theology has to religion-i.e. none to speak of. - Lazarus Long
  5. Where is GIMP going? by ajs · · Score: 5
    There's some pretty clear problems with the GIMP (to me) that point out one of the greatest weaknesses of open software development. Before I go on, thought I should say that I have contributed to the GIMP, and I think it's a great effort that should keep going.

    Ok, let's say you're developing an OS. You have a clear mandate for what an OS does based on decades of examples.

    On the other hand, if you're developing a photo-manipulation program, you don't have so clear a map. Once you've "done Photoshop", what else should photo-manipulation be? How does that apply to the extant (and future) UNIX(-like) desktops? How important is performance? How important is non-interactive use? How important is any new feature?

    Here's where I think the GIMP should go in the next 2-3 years, but others will disagree....
    • The UI and the photo-editing parts should be separated from eachother. The editing engine should be a library with a well-defined API between it and the UI so that others can slap a GNOME UI on it or a KDE UI or another Gtk+-only UI which uses a single window, etc.
    • All plugins should be re-catagorized and many re-written to fit smoothly into the new catagories. Perl, C, Scheme... it should not matter to the user.
    • Non-interactive use needs an overhaul. One of the most powerful features of the GIMP is being able to script your interaction with it, but most of what people want to do with this will require a single, stateful GIMP that can accept lots of requests at once (call it World Wide GIMP, if you will). This is not really what GIMP was designed for, so most people settle for using a library-based interaction with ImageMagick.
    I know that this list of wants is 180 degrees off of what a lot of people want, but that's sort of my point. It's really hard to figure out what community to serve in the Open Source world....

    I wish the folks at GIMP the best. If I ever have any more spare time, I'll go back to helping them out.