GIMP Core Mostly Ported to GEGL 312
A longstanding task for the GIMP has been porting the core graphics code from the ancient implementation (dating back to version 1.2) to GEGL. Progress has been hampered by the amount of code relying on details of the implementation of image data: tiles are directly accessed instead of linear buffers, and changing that detail would break the entire core and all plugins. A few weeks ago, two GIMP hackers got together to do some general hacking, and inadvertedly ported the core graphics code to GEGL. They work around the mismatch between GEGL buffers and GIMP tiles by implementing a storage backend for GEGL using the legacy GIMP tiles; to their surprise things Just Worked (tm), and their code branch will become the 2.9 development series once 2.8 is released. With this, 2.10 will finally feature higher bit depth images, additional color spaces (CMYK for one), and hardware accelerated image operations. There's still work to be done: to take advantage of the new features, plugins need to be ported to access GEGL buffers instead of GIMP tiles, but the conversion work is straightforward and current plugins will continue working as well as they do now in the meantime.
Re:Inadvertently... (Score:4, Interesting)
Re:Inadvertently... (Score:5, Interesting)
There should never be a huge feature gap between stable and dev versions of software, really. I always grab stable versions because I don't want my programmes crapping out on me when I'm trying to do something important.If the stable version is 2 years old while features are being added to the dev version every day, then something's gone wrong.
Call it a need for a more "agile" development approach. They should be picking a feature, building it, trying it out in dev, then rolling it into stable where they can move it to regular support. Rinse, repeat.
Happens in all my favourite FOSS projects, though. Games are especially bad at it, where a million great new feature are always nearly-ready, but never quite seem to be polished enough for show time.
/. no longer has an animated gif for Gimp?!! (Score:4, Interesting)
Long Time GIMP User (Score:5, Interesting)
I'm a digital artist and iOS programmer and I haven't had Photoshop installed in 10 years. I've developed 3 design-heavy iOS apps and shown artwork in museums in New York made with GIMP.
Recently I got fed up with the long absence of GIMP updates and decided to finally switch to Photoshop. I was sure it was going to be a lot better if I just got over the hump and learned it. After converting my latest iOS project to Photoshop and learning how to do the basic operations I needed to get around, I found that many of the basic tasks I do regularly are a bit more cumbersome to do in Photoshop. I went onto forums and found other people on Adobe's forums trying to figure out the same thing, and then coming to an inpass. I even discussed my issues with long time Photoshop users. Photoshop is definitely easier and has more features, but is inflexible compared to GIMP in some ways, like with keyboard shortcuts.
I eventually went back to GIMP. For what I'm doing it just makes more sense. Everything in GIMP is hard to do and the interface is weird, but if it fits your needs and you spend the time to learn the interface, it's great. It's always been more stable than Photoshop for me, and it's free.
Really excited there's a new version on the way.
Re:16-bit? (Score:4, Interesting)
It has not been solved. 16-bit integers are not the answer because you lose resolution when you multiply brightness levels. 16-bit integers are actually a huge impediment to doing things correctly but they were forced on us by people who did not know better, and for machines that were not as fast as current ones they did offer a bit of benefit.
The correct method is to use *floats*, and ideally a linear colorspace. There is even a 16-bit float so it takes no more memory than 16-bit integers. When you multiply a float by 2 you still have the same number of levels between the darkest and brightest visible colors.
I have no idea what GEGL does but I suspect it gets it wrong still...