GIMP 2.8 is getting finalized, high bit depth support is on radar

GIMP 2.8 is getting finalized, high bit depth support is on radar

While GIMP 2.8 is really in the last stage of development, there is even more work planned for 3.0 already going on.

First, on v2.8. The last big chunk of work, working masks for layer groups, is likely to be postponed. It's too much of work, and developers don't want to delay the release even further. So what needs doing is mostly various fixes and finishing the metadata editor/viewer which is a work in progress by Roman. If it gets included in the release, that means end of over 6 years of struggling to finish it.

Now, on 3.0. To understand what's going here you on you need to know how the project is organized. Right now there is just one person in the project who can be classified as jack of all trades: it's mitch, who knows pretty much all of the codebase. Other developers and contributors have their narrower domains of competence and responsibility.

Martin's primary objectives are improving user interface and migrating GIMP to GEGL. Given that most work on the optional single-window mode for v2.8 is already done, and very few, if any, tasks for v2.10 touch his domain, he started working on high bit depth support which is planned for v3.0. That work was started in late September, but the private Git branch got pushed into public repository just over the last weekend.

Before you get excited and start twitting that GIMP is going to support 16/32bit per color channel any time now, you need to know that this is just the beginnings. Right now Martin is working on getting GIMP to use GEGL buffers directly, and that's just a tiny part of the work involved. But it's essential to know that there is some real work being done to get there.

Let's do a recap then:

  • GIMP 2.8 is planned to be released as soon as possible, very little work is left to do;
  • GIMP 2.10 will have a short development cycle with internal clean-up and GSoC2011 projects (two new tools + new size entry widget);
  • GIMP 3.0 will be v2.10 rewritten in GTK+3 (work in progress) with high bit depth support (work in progress).

As usual, we'll keep you informed on what's going on with the project.

Was it useful? There's more:

21 Comments

Leave a comment
  1. What happened to the GIMP-dev mailing list archives?

  2. Alexandre Prokoudine 17 October 2011 at 9:42 pm

    What happened to the GIMP-dev mailing list archives?

    A number of services including mailing lists archives are being moved to a different server. GIMP.org had an announcement on that yesterday

  3. I really appreciate any news concerning the Gimp. Thanks a lot!

    I welcome the plans of short releases and upcoming new features! It will for sure attract more contributors. Developers, thank you :)

  4. it is ironic that now there is ‘excitement’ about gimp implementing a modern 32bit color model. about 7 years ago when the graphics community switched over to using 32bit images there was a lot of hands extended to the gimp developers to try to bring the gimp into a professional graphics environment. but unfortunately the arrogance of some of the gimp developers brushed off these attempts as unimportant to there ‘users’. well now the the rest of the world has caught up with were the the professionals were 8 years ago and every paint app is 32bit. everyone knows what a HDRI is. and there is wonderful work being done with gegl etc. and gimp? it is rewriting the gui. i think even a regular ‘user’ is put off by the fact that gimp can only handle 8bit images. they can’t even edit there digital photos in gimp without loss.

    perhaps the gimp developers should put the ego on hold and listen to people who are at the forefront of digital imaging. people who have the talents to make there livelihood making digital images. gimp would have been revolutionary 7 years ago had it done so. Implement the work that was done for 32bit image processing and integrate the exr image format published by ILM. i hope the developers are eating humble pie now. 

  5. Sadly, I’ll have to agree with grubz. While I truly welcome and salute the improvement, I also can’t help but to wonder why Gimp didn’t go down the obvious 32-bit path all those years ago. Gimp even forked to Cinepaint at a very early point because of the reluctance to support higher bit-depths.

    On the other hand, I do use Gimp more and more professionally for special cases such as creating ico-files. In that respect, it’s quite refreshing compared to many of the existing ico-design applications on Windows.

    I’ve also used it for some low-end photo manipulation with great results.

  6. @grubz and JimmyVolatile

    Sorry, folks, but I wish you did some facts checking beforehand. Here is a summary: http://prokoudine.info/blog/2011/08/on-cinepaint-gimp-and-gegl/

    As for work on UI vs. work on high bit depth, with a team that small you can’t do both, and nobody can really say which tasks is more important, because there will always be people who will emphatically claim that one is more important than the other :) So you need trade-offs, which is what the team has been doing for past several years: gradually improving UI and merging support for GEGL.

  7. Thats why, I’m personally so happy about changing how team works on a project, because it will help whole project, users and devs.
    Separating Master from working branches, faster release cycles, decision to go with changes in UI, finishing moving to GEGL! All this will be surely more attractive environment for new developers and small Gimp team won’t be so small in future.

  8. Thanks to developers.
    Hard work awaits them in migrating to GEGL and implementing support for 16/32bit.
    I hope that after the changes, the development becomes simpler and more modular and more easily to implement new features.
    I was hoping that Michael could finish Warp Tool for version 2.8, but it seems not possible. But at least we will have a great new tool, “Cage Tool” thanks to Michael.

  9. @Alexandre
    actually I see more FUD in that post. there was real software development sponsorship directed at gimp. (ie) the equivalent of a years salary was donated to one developer. and a ridiculous amount of development hours by many people were put into gimp in a attempt to make it a flagship open source graphics package. something better then commercial software that could be used by professionals and everyone else oss and free. solid enough to be used in producing block buster movies. how could you possibly screw up such a great plan? simple, absolutely refuse to commit any of the code that was worked on into the main code base! film gimp would never have existed if it was not for the hostility of a few developers to features and ideas they considered a thereat to there control.

    you can not over state the severe blow that a few gimp developers gave to the progress of open source graphics software. the gimp fiasco showed that open source projects can have dictatorial power. and that power is more important to some developers then the progress of the software. most large oss projects strive to be better then commercial software and offer a viable option for professionals. gimp on the other hand has done the opposite. the result has been that it is impossible for any other project to find sponsorship or collaboration with professional studios to develop serious oss graphics software. remember that every time you see successful sponsorship of oss development. because it happens all the time. just not in graphics software. thanks gimp!

    now look at blender… look and learn…

  10. @grubz

    No FUD, just plain boring facts :)

    I’m not exactly interested much in having an argument over that. The decision to not use the changes from the fork was perfectly justified by disadvantages of the architecture. Which was later confirmed by the Cinepaint team. If it means dictatorship to you, I’d rather not participate in a further discussion on the subject. I respect your views, but I don’t see how this can lead to a constructive conversation.

    As far as I can tell, GIMP team has learnt a lot over the last years, and their new approach to development and releasing is way better and safer. Unfortunately we cannot truly estimate that until 2.10 development cycle starts.

  11. @Alexandre

    this is my last post on this subject. you are correct this is not productive. but neither is denying past development mistakes and a flawed project governance. we can all see that the ‘new’ development approach is an attempts to try and change some of this without publicly stating the fact. you do have to keep in mind that the graphics community is for the most part the same people that were around 6 years ago. and posting news about gimp and 32bit color depth will cause the rolling of eyes around the globe. 

    what ever failings the previous 32bit architecture had the fact remains that it was not and is still not seen by certain gimp developers as anything more then an extravagant ‘feature’. when in fact to the graphics community of artists and coders the lack of a modern 32bit color model is the main shortcoming of the gimp architecture as a whole. practically all of the progress in graphics theory and practice in the past 5 years has been in a 32bit color space. the gimp project will see little interest from serious developers or practitioners until they address the issue.

    I enjoy your site and news. take care not to dig up old land mines!

  12. Sorry but I read nonsense which you write and I have to ask. Do you think that Gimp devs are idiots?
    They know how 32bit depth works and how it is useful, better than you.
    There was a choice, make crappy 32bit support and waste time, or make it once and good.

  13. @n-pigeon

    no the gimp coders are probably not idiots. but anyone who thinks they care about a 32bit color pipeline probably is. i would add that if it has taken them over 8 years to implement a 32 bit color pipeline without a single build of a pre-alpha stage executable to show then yes they probably are idiots in the literal sense of the word.

    its quite obvious that gimp is a showpiece for gtk. once the attempt to integrated gegl into gtk is done then perhaps the gimp will be able to magically update there widgets extravaganza to 32bit with out any work. but this is backward. gtk does not need a 32bit color model. image editors do. so instead of actually coding 32bit support for the program that needs 32bit support its integrated into the desktop widget library which is useless. at that point it would be easier to start form scratch with a new editor based on a gegl core. in which case gimp should be put to pasture for good. and hopefully a new group of coders with some connection to the graphics community other then people editing wallpaper for gnome could step in.   
     

  14. @grubz

    Would you like to reveal where you got the strange idea that the ongoing work is about GEGL in GTK? Also, what is a “32bit color model”? Surely you meant to say “32bit depth”?

  15. Great news,

    I’m happy to see that Gimp is always alive, i was afraid it would slowly disappear over the horizon with the apparently smaller and smaller dev team working on it.

    Hopefully the 2.8 release and reorganisation will trigger the interest of additional developers to get onboard and help build Gimp for the future.

    I have a question about the article, this part :
    “” Before you get excited and start twitting that GIMP is going to support 16/32bit per color channel any time now, you need to know that this is just the beginnings. Right now Martin is working on getting GIMP to use GEGL buffers directly, and that’s just a tiny part of the work involved. But it’s essential to know that there is some real work being done to get there.”“

    After reading the debate in the comments and re-reading this part of the article i don’t understand : does it mean that 16/32 bit will be supported by the 2.8 release , or such support will be again set for future versions and 2.8 will continue to have 8 bits with the losses on high quality images we had so far ?

  16. Gorbas:
    “does it mean that 16/32 bit will be supported by the 2.8 release , or such support will be again set for future versions and 2.8 will continue to have 8 bits with the losses on high quality images we had so far?”

    yes exactly the point. show me the money! after 5,6,7 years… its just around the corner? i dont think anyone who has been keeping score at home could take these anouncements seriousy anymore without a beta, an alpha, a cut and paste code snippet on a wiki somehere that you have to compile by hand that shows a 32bit image moveing through gimp with atlest a few basic tools working.

    and don’t try to heckle people who work in a 32bit color space all day about there nomenclature. every app I use has support for 32bit color to some degree for the past 5 years or longer. its not some extra feature where you just slap on some extra bits. you have to reconfigure your whole pipleine. and most tools work differently in floating point. rendering is different. and you can’t just mix 8, 16, 32float. it all has to be cordinated. there are other issues also with display gamma etc.

    your not going to win this argument with people who are already working in a 32bit enviroment. were already there. were not waiting for gimp all the professional tools switched long ago. its up to the gimp developers to show us there wondefull progress. sadly they have nothing to show. and instead for what ever reason certain people choose to attacked the graphics community. the very people who tryed to help them in the first place. the effect is a much harder road for other open source developers who wish to make serious graphics software.

    as for gtk i dont fallow gegl’s every move but last i heard there was a good deal of work to integrate a gegl \window\nodes\buffer into gtk to some extent. i dont have time to dig up all the links on that. but it is more then likely that it will be easier to start from scratch with gtk and gegl to make a 32bit graphics app then to recode all of gimp.

  17. @Alexandre

    I have a question for you since you seem to be keeping track.

    i was referring to the gegl-gtk which has been moved to a separate project its obviously a small project. but thats not the point.

    is there some other effort from the gimp developers to integrate gegl into gimp or gimp into gegl? a new core that is designed for 32bit image manipulation and useing the gegl graph etc?
    if there is do you have a link to this project?

    or are the gimp developers using gegl-gtk. if so do you have a link to this project?

  18. @Gorbas

    The discussion has very little to do with the subject. The blog entry clearly states that final stage of GEGL integration is not for 2.8.

    @grubz

    yes exactly the point. show me the money! after 5,6,7 years… its just around the corner?

    Noone ever promised it to be just around the corner. I don’t remember the team doing any promises on that in the last 6 year that they wouldn’t keep. The plan was to gradually rewrite bits of GIMP to use GEGL as a core. That’s what has been happpening since then.

    as for gtk i dont fallow gegl’s every move but last i heard there was a good deal of work to integrate a gegl \window\nodes\buffer into gtk to some extent. i dont have time to dig up all the links on that.

    It would be much better if you did :)
    gegl-gtk is just a way to use GEGL for other apps that rely on GTK. It doesn’t do anything about regular GTK widgets. Please read the relevant article again.

    but it is more then likely that it will be easier to start from scratch with gtk and gegl to make a 32bit graphics app then to recode all of gimp.

    You have to be a programmer to mke such a statement. Are you? :)

    a new core that is designed for 32bit image manipulation and useing the gegl graph etc?

    I don’t know of any such project and. honestly, I don’t understand why you’re asking.

    or are the gimp developers using gegl-gtk.

    Not yet, and I’m not sure if they would be doing that. The gegl-gtk project (as well as gegl-qt) was started by a MyPaint developer to meet his own requirements. It wasn’t an initiative by GIMP developers.

  19. I’ve just been having a dabble with 2.7.5 & it’s quite nice, however I think that performance (or lack of, might well be an issue - or show stopper more like!). I was using the heal brush at approx the same size that I use it in 2.6 & although the results were stunning I found myself having to move the cursor very very slowly and even then the heal was lagging a good 5-10 secs behind. Gimp 2.6 by comparison is sufficiently fast that I don’t need to move the cursor slowly - the healing gets done in real time.

  20. Hi Tom, what OS are you on? And what is the brush size?

  21. I’m running Windows XP SP3, 2Gb RAM & 2.4GHz dual core processor. The basic image size was 15Mpix with about 3 layers, two of which were masked. I started with a brush size of 500 & reduced it by degrees to 100.
    After posting I noticed that paintbrush was also quite slow as in 1-2 secs lag between moving the mouse & the circle/painting catching up.
    What I did eventually find out is that with a brush size not exceeding 100 both Paint & Heal are quite quick to start with, but after a few strokes with the mouse button help down continuously they start to slow down.

Tell us what you think

Submit the word you see below: