Slashdot Mirror
GIMP Core Mostly Ported to GEGL
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.
A few weeks ago, two GIMP hackers got together to do some general hacking, and inadvertedly ported the core graphics code to GEGL.
Is it just me, or does that not pretty much sum up GIMP development since day one?
Now if these guys would just inadvertently fix the user interface, or perhaps trip and fall into a total redesign, or accidentally re-organize and re-name all the tools using bumbled into industry standard names, and serendipitously selected value scales, they might unintentionally come up with something that, purely as a side effect, resembled, ever so slightly, the principal of Least Astonishment.
Sig Battery depleted. Reverting to safe mode.
My sentiments are somewhat similar to the poster above, although a bit less... aggravated.
This sounds like a "cool hack". Which, .. ya know.. is "cool" an all... but usually not a good idea for a major piece of software such as GIMP.
IFF what they're describing is some kind of transition phase, where it allows dual-mode backend sort of stuff, and a concrete plan of action to eventually port all existing (standard) plugins to the newer methods, and then DITCH the old way.... then great.
But otherwise, having heavily layered interface/mechanics conversion code, is a Really Really bad idea. The bigger the software, the worse idea it is. It would be better to just toss it all out and start from scratch, if this is going to be an indefinitely lived hack.
Those who deliberately engineer masterpieces, those who "inadvertently" engineer masterpieces and those who write the (cough) software that causes the other two groups to act.
In this case, these accidental geniuses are responsible for work that mainstream GIMP developers had long claimed was impossible. From the looks of it, six impossible things were achieved, so said developers should round things off with a meal at Milliways.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"How do I draw a circle? I CAN'T DRAW A CIRCLE WITH IT YET AFTER LIKE 30 YEARS" --lowuserid1997
"Does it still suck at CMYK...because where I work we are focusing *so hard* on CMYK right now, it'd be ridiculous for GIMP not to support that" --a_complete_liar
"I noticed that the interface is still a series of 'windows'...my granddaughter's IPAD allows her to paint the entire mona lisa with her pinky finger, never even showing a single window. WHAT HAPPENED TO OPEN SOURCE???" --300baud
"Anybody know of an alternative to GIMP that lets you publish to ebook formats like Kindle? I need to be able to import a 1200 page scientific text, and I want to have drop shadows on the letters and a parchment background. Also something that exports to iBooks would be great but I can't pay any money for this, and I don't want to have to work for an hour to make it all just work." --cluelessphd
Versions are not decimal numbers!!!!! what number is 2.8.4?
"Oops! Oh, it worked?" ...
"Crap. WHY does it work? It totally shouldn't work!" ...
*shrug* "Ship it."
I'd love to see the brainfuck that ensues when you're tasked with figuring out whether 192.168.0.1 comes before or after 192.168.0.10.
I'm hoping for something on a similar level to that video that went viral of the blonde trying to figure out miles per hour.
Yup, I don't get it, for example, why rotating a photo to get the horizon straight is not just a matter of drawing a straight line over horizon, and have GIMP figure out how to rotate the photo to get it straight.
Here's how to correct a horizon in GIMP 2.6.11:
Pixelmator
Price to anyone who owns something other than a Mac: $630.
Here it is.
http://commons.wikimedia.org/wiki/File:GIMP_2.7.3_splash.png
Why is it so hard to only have politicians for a few years, then have them go away?
1. I'm not sure what you're saying. The 32/24 bpp support has been there since day one. The same maximum depth as my video card, and probably yours as well, It's only 16 bits per channel (128/96 bits per pixel) that isn't supported, and that's mainly an issue for those who work in the dying industry of paper-publishing, and those odd individuals who want to work on "raw" photographic images despite not being able to see the results of their manipulation.
2. Why does a "plugin" need to be "buildt inn"? You're not making any sense here.
3. Why on earth should a UNIX program depend on proprietary Microsoft technologies that aren't available on UNIX? If you want to make a Windows-only fork, feel free.
4. That's what this article is about, dummy!
As a photographer I disagree with your statement. The advantage of working with raw picture files is that you have much more data available then you have after a lossy compression has been applied to your image. Shooting in RAW allows you to do all sorts of neat tricks that with a standard jpg are extremely difficult if not impossible.
Believe me, you do notice the difference between a processed jpg & a processed raw file.
I know slashdot now uses PNGs for the icons to fit with the theme... but I *really* miss the old Gimp icon with the animated eyes. Can't an exception be made?
Most people who are educated enough to read and write also have enough experience with their language to cope with the existence of homonyms, and not be compelled to associate a term only to one particular thing when the context is obviously referring to something else that only happens to share the same spelling.
File under 'M' for 'Manic ranting'
This should be the only objective for 2.10 other than bug-fixing the single window interface which debuts in 2.8. They should get feedback on the UI, tweak a few things (not rework them) go full GEGL and get 2.10 out the door ASAP. The 2.8 is going to get a lot of people to look at it again, but when the features of GEGL are found to be missing they'll walk away AGAIN and it will be some time before they check in again. So let's not advertise 2.8 so much, but hurry with 2.10 and then make a push for people to switch.
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.
1. I'm not sure what you're saying. The 32/24 bpp support has been there since day one. The same maximum depth as my video card, and probably yours as well, It's only 16 bits per channel (128/96 bits per pixel) that isn't supported,
Correct, although I think you mean 64/48 bits per pixel, not 128/96.
and that's mainly an issue for those who work in the dying industry of paper-publishing, and those odd individuals who want to work on "raw" photographic images despite not being able to see the results of their manipulation.
No, that is wrong. While most pictures are saved in 24 or 32 bit formats, once loaded in a graphics program any workflow involving colour or level manipulation at 8-bits per channel (a paltry 256 shades of gray) very quickly shows up artifacts, compounding with every operation. This is a very real problem and it has been solved for pretty much every other photo editing program out there (including Krita and the GIMP fork CinePaint).
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
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...
Use of CMYK inks does not mean that RGB images cannot be printed. I think you will find that a vast amount of those images you are thinking about were never anything other than RGB before they were converted by a printer driver to CMYK.
CMYK is vaguely useful for exact control of a known output device. It is useless if you plan to print on more than one type of printer, or if your printer does not accept raw control of the CMYK guns (most every non-professional device will not print raw CMYK, doing things like turning on the black 100% will turn the others off). Modern software has floating point so mismatched gamuts are no longer a problem.