Domain: gegl.org
Stories and comments across the archive that link to gegl.org.
Comments · 41
-
Re:Hmm... Source Code...
-
Re:Hmm... Source Code...
-
Re:Here comes the complaning...
You're incorrect they're not working on features "professionals want." It says right in the summary the porting to GEGL is making huge advances... this will give the GIMP CMYK, 16/32 bit colorspace, non-destructive editing. This release has already given it single-window mode.
The greatest hits of the people that say it's not ready for the big time.
It's a great free tool, I use it almost every day and have for years. You're right it's not photoshop, but I don't much care.
-
Re:Square peg, round hole
Um, from the GEGL website:
GEGL provides infratructure to do demand based cached non destructive image editing on larger than RAM buffers. Through babl it provides support for a wide range of color models and pixel storage formats for input and output.
So UFraw won't been necessary, assuming GEGL supports as many formats.
-
Re:Wow, improvements really show
I don't know much about GIMP, but when 2.6 comes out you should give it a try. I can't seem to find a roadmap for GIMP, but it's expected that GEGL will be integrated into GIMP 2.6, which appears to address the colorspace problems photographers cite against GIMP itself.
As for batch processing thousands of photos, at least to me it seems like imagemagick is more appropriate... -
Re:Grabbing my copy before it gets slashdotted
GEGL does support floats. Quote:
Features:
* 8bit, 16bit integer and 32bit floating point, RGB, CIE Lab, and Y'CbCr output.
http://www.gegl.org/ -
Re:16 bit RGB support is more important than CMYK
Why don't they just work with 16-bit colour.
Good question. The answer is that for years now the GIMP developers have been putting all their eggs in the GEGL basket. GEGL is a library that should allow them to chain all kinds of complex operations, but development on it has been slow. -
Re:patentsWhat part of "patent" do you not understand?
No, that's not the problem.
CMYK and spot colors by themselves are not patent encumberd. They are actually part of the open published standards for Postscript and PDF. Anyone saying anything different is clueless or spreading FUD and/or openly demonstrating their ignorance of the fact. http://rants.scribus.net/2006/06/03/why-no-cmyk-in-gimp-is-a-good-thing-now/The Gimp developers do intend to bring CMYK to the app, but the underlying graphics engine is based around 8bpp RGB. Rather than hack the old engine to work with CMYK and higher bit depths, they decided to build the future Gimp on a generic graphical library called GEGL. That meant waiting until GEGL had a stable API and worked well enough to be better than the existing 8bpp engine in production use.
GEGL will most likely be in 2.6, along with the new MMIWorks-designed UI UI
-
Re:CMYK is irrelevantDo you have any more information on CEGL?
Just what's on the web site. -
Re:Hmmmm
I imagine that's a lot easier said than done, let me tell you a sad tail, a long time ago there was this project that forked off from the GIMP originally called film Gimp and is now called cinepaint and that happened about version 1.3 for the GIMP. It different from the gimp because it was designed movies with big honking frames at 32 bit color depth, and I'm not talking 8+8+8 = 24 bits, were talking 32 * three color channels! So when the UI gets bloated it really bogs the whole system down. Cinepaint is currently undergoing a rewrite of the core to better support high color depth images and undergoing a change in the UI from GTK to FLTK. What they should have done was first separate the UI code from the program logic and made sure very thing still compiled and worked, then changed from the increasingly bloated, slow and ugly GTK to the still ugly but small and fast FLTK. What the Gimp team needs to do is get their code-Nazi's to finish the GEGL overhaul and then separate the code for the user interface so it can be worked on without FUBARing the whole project. The other problem that the GIMP has is the GTK, Gimp Tool Kit that they wrote for the gimp is now integral with gnome so whatever evils gnome introduce the GIMP inherits and there is a limit to what they can fix.
-
Re:CMYKQuit screwing with the UI and add CMYK support. I'm not talking about some half baked script- real CMYK support from the bottom-up.
It's on the way, and has been in process for quite some time. GIMP is getting an entirely new graphics engine called GEGL that supports different colorspaces (incl. CMYK and all of the other widely-used spaces), 32 bit per channel color, support for adjustment layers, and a lot more.
-
Re:representative ?
Failing that Krita is coming along very well as an image editor, it lacks a few features, but is far more usable than the GIMP.
One of the features that it's lacking (as of version 1.6.0) is the ability to edit text. Until it gets that, I will continue using the Gimp.
-
Re:representative ?
I like the idea, but will the folks who use ingimp be at all representative of the user population at large?
... Especially of the user population that would complain about accessibility / usability.My wife does Web design for University of Waterloo and she's always moaning about the usability of the GIMP. I too am more into design than development these days, so that makes two people who're--more or less--ideal for the task.
Not to mention we have both customised our GIMP's to look and behave more like Photoshop (the missus was fiddling with the keyboard-shortcuts for ages). It seems this data should be collected in this project, as I doubt we're the only ones who've changed everything to our tastes, the developers should finally realise what people want in an image editor.
On a related, by tangential, note: GIMP's new core (GEGL) seems to be nearing completion, with that comes all the things people have been clamouring for. Such as non-destructable layer effects, CMYK etc. If they fix the usability and shift to GEGL as the core of GIMP it might finally become the Photoshop killer we've all been waiting for! Failing that Krita is coming along very well as an image editor, it lacks a few features, but is far more usable than the GIMP.
Overall, I don't think anyone should be saying: 'year of the Linux desktop!' just yet. But this is definitely a step in the right direction.
:) -
Re:representative ?
I like the idea, but will the folks who use ingimp be at all representative of the user population at large?
... Especially of the user population that would complain about accessibility / usability.My wife does Web design for University of Waterloo and she's always moaning about the usability of the GIMP. I too am more into design than development these days, so that makes two people who're--more or less--ideal for the task.
Not to mention we have both customised our GIMP's to look and behave more like Photoshop (the missus was fiddling with the keyboard-shortcuts for ages). It seems this data should be collected in this project, as I doubt we're the only ones who've changed everything to our tastes, the developers should finally realise what people want in an image editor.
On a related, by tangential, note: GIMP's new core (GEGL) seems to be nearing completion, with that comes all the things people have been clamouring for. Such as non-destructable layer effects, CMYK etc. If they fix the usability and shift to GEGL as the core of GIMP it might finally become the Photoshop killer we've all been waiting for! Failing that Krita is coming along very well as an image editor, it lacks a few features, but is far more usable than the GIMP.
Overall, I don't think anyone should be saying: 'year of the Linux desktop!' just yet. But this is definitely a step in the right direction.
:) -
Re:Finally someone gets it in education...
Because the graphical libraries weren't designed for it. Peeps are working on a new graphical library that will handle it. See http://www.gegl.org/ for further information.
-
Re:As...
By all means, show me where I've gone wrong.
At this point you're not wrong, however the GIMP developers have just re-written the entire engine behind GIMP. It's called GEGL and is a compositor (allowing those non-destructive layer effects you were talking about), it can also do CMYK. The reason the GIMP is so behind is because they've been waiting for this, version 2.6 will see a re-write of GIMP internals to use GEGL (we're currently on version 2.2).
Alternatively, you can try Krita, which is also not professional-ready yet but is possibly closer than GIMP. Either way I believe thick client FLOSS apps have far more to offer than online thin-clients.
-
Re:Does it work on 12 or 16 bits/channel images?
I understand GEGL will be the new backend for GIMP, supporting deeper color among other things. A friend closer to GIMP development mentioned to me that it may be ready for GIMP sometime this year, but neither the GEGL website or quick searches turn up anything on that topic. A 2003 thread stated that a move to GEGL would be very gradual so as not to necessitate major rewrites.
-
Re:Cool But...
It's a more modern, extensible architecture under the hood, so it can be extended to do things like CMYK, it has some nice performance optimization capabilities, and if I understand the way it is written, it sounds like it might be a good fit for image pipelining in the GPU a la Core Image, but that's just from a skimming of their FAQ, so I could be wrong.
For more information, see http://www.gegl.org/faq.html.
-
Re:Does it have a "healing brush"?
I belive that those will arrive with the "GEGL" library. This library is being coded to be a base of future 'gimp's and it model all image manipulations with a graph of operations. For more info check it out in http://www.gegl.org/.
-
still waiting for GEGL and/or 48bpp support
I love GIMP, but I am still waiting for GEGL and/or 48 bits per pixel (16 bits per channel per pixel) support. I conduct scientific research and the thought of trowing away extra data to work in the 24 bits per pixel space is unnerving. I mean most digital cameras support 48bpp pictures now using the RAW format which is supported by linux.
-
Help with next generation GIMP
No doubt that Photoshop has some features that GIMP lacks, and that professionals can't do without (CMYK color, higher color depth, etc.). The next generation of GIMP will be based on GEGL (Generic Graphical Library) which will provide the bulk of these features, but it's development has been a bit slow. Lend a hand and we can help bring GIMP on-par with photoshop.
http://www.gegl.org/
Todd -
Re:Huh?
In my opinion, rewriting GIMP from scratch and making it extensible would be the best choice.
You mean like instead of making your primitive a bunch of stored images and a set of operations that can be applied to them, making your primitives images and DAG operations (thus allowing going back in a history of image editing and modifying a parameter or so)?
Good thing the GIMP people feel the same way. -
Re:Here's why
1. Where are my blending options? I want to be able to bevel, emboss, texture, etc. on each layer with an easy to use dialog. I don't want to fiddle with 5 layers, each filtered their own way just to achieve a button. And I want immediate feedback.
Granted, not there today, but if my understanding of the gegl rework is correct, it should be easy to feed a layer into a "series of operations", and when updating that layer, have the "series of operations" reapplied. Basically, if you can store a directed acyclic graph of operations to be applied, it becomes a trivial operation to make a layer an "effect layer".
3. And yes, color support. I've only been able to achieve some effects with CMYK.
Also will be in gegl. -
Re:8-bit graphic ?
I think they are more than well aware that people want 16 bits per channel support. Too bad there's been too many hurdles on their way. You probably want to go for the FilmGimp/Cinepaint for 16bpc.
Also there'll be still no trace of color models other than 8bitRGB/Gray/Indexed. They were supposed to develop a whole new framework for colorspace management and port the GIMP to it, but apparently all of the developers who knew anything about colorspace stuff choked to death when they tried to pronounce the name of the framework, so the project's been in limbo for years. Man, I'd kill for L*a*b.
But at least they'll get good CMS stuff! I think GIMP already uses littlecms, just there's no GUI for it, but sweet that it's coming in next release =)
-
Re:32bit?
I havent finsihed reading the docs on GEGL yet but I'll look into it. Kinda wish you would of posted a link so for anyone else interested http://www.gegl.org/
-
Re:Anyone who says
"I though 16bit support was due in GIMP about now?"
Yes, for any given meaning of "now". :-)
GIMP 1.4 (later renamed to 2.0) was going to a reorganization of the code, with a better separation of core functionality and interface. Then the GEGL library was going to replace the graphics processing functions. Except that by 2.0, GEGL wasn't nearly ready yet.
In the meantime it had been decided that because of the many ideas for new features that had been on hold while waiting for 2.0, a version 2.2 would be brought out first that incorporated all these new features (better previews, live transformations, better dialogs, &c.).
GEGL was going to happen in 2.4, IIRC, but that plan also seems to have been given up. A mail on the developer list from June 5, 2005, titled "The GUADEC meeting", detailing a meeting of several developers, reads:
"We would like to get GIMP 2.4 out soon. The plan is to finish what has been started in the development branch. This should be doable over the summer. This means that 2.4 will have color management but we aren't going to try larger changes such as adding support for higher bit depths."
"We agreed though that 8bit is not going to get us much further and that we need to pick up on GEGL again. The GEGL source tree had been abandoned for a while, the last commit dating back to March 2004. We found that in order to make further plans, we first need to get an overview on the current state of the code."
There is also mention of reworked menus.
It doesn't say so in the e-mail message, but the colour management Sven is referring to probably does not entail true CMYK, because that was also planned for (and put off for) GEGL.
"There's always cinepaint, the new version sounds promising."
Last time I checked, Cinepaint was a one man show and fairly buggy. (Granted, that was a while ago.) -
Re:adjustment layers are the way to go...
"Adjustment layers are the way to go and they've been asked for several years already but evidently the gimp developers don't care about them enough to provide them."
Just because someone on Slashdot tells you that adjustment layers are easy to make, doesn't make it true.
Adjustment layers are discussed in bug report 79025, where Sven suggest that their implementation depends on GEGL.
From what I seem to remember from earlier discussions (nobody will correct me if I am wrong), the problem is as follows: an image can be made up from hundreds of layers. For the renderer to correctly composite your view of the image, it has to traverse all these layers and decide per pixel whether to render it, or not, or part of it. This can slow things down tremendously, so tools like the GIMP and PS have smart caching routines that allow them to skip part of the rendering loops. Apparently, interfering with the layer stack (for instance by adding adjustment layers) means rewriting the caching routines.
Again, this is from memory, I probably remembered it wrong.
-
Well... n-bit depth
1, 4, 8, 12, 16, 24, 32... the user shouldn't have to care.
As I understand it, once they shim GEGL in, the rest will be easy.
Unfortunately, the GEGL domain is off-air as I type, the last contribution to the GNOME repository for itis some testing stuff 9 months ago, and the last "real" code 11 months ago, most of it's a year or two old, all of the recent (in relative terms) changes were done by dsrogers. Not lookin' too sanguine. -
More advanced compositing
This has been planned for a long while, GEGL is the library that is planned for this in GIMP, by introducing a new low level library for all the core image processing a smoother path towards higher bitdepths will also occur.
There is no opposition between a graph of operations / connectable blocks and a layer tree.
/pippin -
Re:GIMP is NOT all you need.
> What's worse is that, if you read the GIMP lists, 16-bit support is probably years away (I think someone mentioned "2006, maybe"
GEGL is dying. -
Just for the Record
This sane Mike Shuttleworth offered, about 2 months ago, some funding for The Gimp, and two of the current developers made a deal with him to be paid to further GEGL (Generic Graphical Library) development and integration with the GIMP.
GEGL, once fully implemented, and integrated to The GIMP core, will finally allow it to use images with higher color depths than 8 bit per plane. -
CMYK support getting closer, but not here yet
I wanted to clarify one point from this slashdot posting: GIMP 2.0pre1 has plugin or two that can handle some CMYK functionality, but this is not the release that uses gegl, or the generic enhanced graphics library. GEGL is the project that will bring all the bells and whistles necessary for proper colorspace support.
-
Open source alternatives.
Its time to promote open source, and for people to improve it.
Photoshop = Gimp, the lastest version is much improved, with a DECENT GUI, masking layers, the beginings of CMYK support and much much more. There is no need to complain about the gimp, and if you need a feature that is not there, Then you can help. Also check out the gegl project, which will add much wanted stuff such has weird colourspaces and 48-bit support
Illistrator = Karbon. Sodipodi is nice, but its designed as an SVG editor only, Karbon has a more illistrator like interface and supports more file formats. As usual, give feedback, its how open source improves.
InDesign = Scribus. A powerful DTP application, its a lot to explain on this page, so go and read the page and don't forget to help.
GoLive = Quanta. Quanta is the best OpenSource Website creator. Support for wysiwyg is in the CVS, so help them out ;).
I use these tools everyday and FOR PRODUCTION work, remember don't complain on slashdot about $APP dosen't have $FEATRURE. Either help fix it if you can program, or submit a feature request in bugzilla. I have several times and gotten the features I wanted. So, if you are tired of Adobe lock in, then help open source. -
Re:Where will Linux be?Hopefully, it will make some progress on the desktop. I have peeked in the CVS and mailing lists, and there is ACTIVE PROGRESS to solve these problems...
- Fix the file dialogs
- Fix the fonts
- Fix the cut and paste
- Fixing the gimp (see the gegl project
- Slow unification of KDE/GNOME, they won't merge, but they will be much closer together
- Better hadware support (see kernel 2.6)
- And yes, better goatse support
-
Re:The GIMP New Web Site
The GIMP is on the road for a 2.0 release that shall happen this year. Actually, this 1.3.21 release shall be the last one before the 2.0pre release series.
My understanding was that 2.0 is still a ways off and that this 1.3 development cycle is leading to a 1.4 stable release. This 1.3 devel cycle is meant to clean out all of the old cruft from 0.6->0.9->->1.0->1.2, in particular bringing the codebase in line with GTK+ 1.3/1.4. Remember, GTK+ is the Gimp ToolKit. It developed with The Gimp so there was a lot of old code in The Gimp from the days when GTK+ was a lot simpler. Anyway, Gimp 2.0 will use GEGL to handle multiple colour spaces (e.g HSV, CMY/CMYK, YCC, cieLab XYZ) and depths (e.g 48/64-bit RGB/RGBA, floating point, HDR). When 2.0 is released, the abomination that is currently CinePaint (personal opinion) should be largely unnecessary.
-
Re:How about
1. Adjustment layers
Planned for a future release. Contributions are welcome.
2. 48-bit color support (and don't point me to buggy cinepaint)
Planned for a future release. Again, contributions are welcome.
3. COLOR MANAGEMENT.
A part of this should already be handled by your X server (see Xcms, xcmsdb and related tools). For the other part, see the next item.
4. L*a*b color space
Also planned for a future release, when GEGL is integrated into the GIMP. Look at the GEGL Task List and scroll down to the item "Additional ColorSpaces and ColorModels". You will see that L*a*b is mentioned there.
For all of these, the GIMP and GEGL developers would be more than happy to accept any contributions from users of developers. Providing a patch implementing the missing feature is of course the best way to contribute, but paying someone for doing it may also work in some cases. Bribing some developer with money, food, books, movies or any geeky stuff may also help.
;-) -
At last.
SVG support is useful, as I use SodiPodi (a great svg tool, and the latest CVS version is really good, I expect it will become 0.4 soon) a lot to create diagrams and pictures. Being able to import them into the gimp without having to export to png first will help me.
Gimp keeps impressing me as being the most versitle image program, that is free and open source. It is now so easy to use compared to photoshop! Features are being added everyday, and if the feature you want its not there, then make a feature request. If you don't request, then don't complain. Most of the requests are trivial and can be implemented quickly, so if you are developer with some time to kill then add it and make a lot of people happy.
Then there is the GEGL project, which is a new version of the GIMPs core engine, witch will extend beyond the the traditional RGB-8 and provide several new colour spaces, which is what a lot of people wan, it will be coming in future gimp releases. (post 2.0)
I'm happy with gimp, and when you try you will be happy to. For 95% of people who use graphics tools, gimp is overkill, and the gimp developers are working VERY hard to satisfy those 5% who complain. Graphics manipulation is complex, and you should be very happy people have made this wonderful tool for free, rather than having to shell out $$$$! Photoshop would probably be a lot more expensive today if it wasn't for the gimp, so even if you don't use gimp then your being indirectly benifetted. -
Re:I don't mean to gripe but....
Effort is being invested in this, but it is substantial changes and development of the featureset you mention happen outside the main gimp tree. You want gegl now,..
-
Re:Good enough...
The other things I know Gimp doesn't have are support for more than 8 bits per color plane
CinePaint is a fork of Gimp that has up to 32 bits per channel (and can do 8 or 16 bits per channel if that's what you want).
(CinePaint doesn't seem to have path support, so there's still a reason to use Gimp if you're more into drawing and web work, like me.)
and maybe the Gimp will steal that code from Scribus...
"Steal"? Scribus uses liblcms, no need to "steal" anything.
Gimp is great, but I'm kind of looking forward to something even better. Maybe that'll be GEGL, maybe something else. -
Why Gimp rejected Film Gimp
According to the page, the rumor is that the committee saw the Film Gimp effort as the prototype, "the one you throw away" and decided to put their efforts into gegl.
-
GNOME
GNOME is full of easter eggs
well 3
1: April 1st, Wanda the fish will die
2: Triple click the right mouse button on the panel tab in the control centre, and a new tab will appear with a GEGL waving.
3: Type GNOME on the About GNOME program and the logo changes to the sqeaky gnome toy, and it sqeaks when you click it.
Thats all.