On 09/19/2010 03:46 PM, fufuz@gmx.net wrote:

A few programs (CinePaint for example) use dcraw to allow direct support for opening/processing RAW files of many camera manufacturers. I personally think, that it would be a great feature for GIMP, too.

I've also read, that the full implementation of GEGL will provide native RAW support in a future version of GIMP. Is this true or is raw support a planned feature at least?

The GIMP product vision [1] states among other things:

"GIMP is a high-end photo manipulation application"

which certainly includes RAW support out-of-the-box. So yes, eventually GIMP will get that. But there is no plan for when the code for it will be written. Maybe after GIMP 3.0 when we have high bit-depths and non-destructive editing in place will be a good time to include it, but no one will reject a good set of patches that adds it already to 3.0.

/ Martin

[1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

On Sunday, September 19, 2010 08:51:10 am Martin Nordholts wrote:

On 09/19/2010 03:46 PM, fufuz@gmx.net wrote:

A few programs (CinePaint for example) use dcraw to allow direct support for opening/processing RAW files of many camera manufacturers. I personally think, that it would be a great feature for GIMP, too.

I've also read, that the full implementation of GEGL will provide native RAW support in a future version of GIMP. Is this true or is raw support a planned feature at least?

The GIMP product vision [1] states among other things:

"GIMP is a high-end photo manipulation application"

which certainly includes RAW support out-of-the-box. So yes, eventually GIMP will get that. But there is no plan for when the code for it will be written. Maybe after GIMP 3.0 when we have high bit-depths and non-destructive editing in place will be a good time to include it, but no one will reject a good set of patches that adds it already to 3.0.

/ Martin

[1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

UFRAW has a nice GIMP plug-in that has full RAW processing features. Not sure why it is necessary to reinvent the wheel.

Hal

On Sun, 2010-09-19 at 15:46 +0200, fufuz@gmx.net wrote:

A few programs (CinePaint for example) use dcraw to allow direct support for opening/processing RAW files of many camera manufacturers. I personally think, that it would be a great feature for GIMP, too.

You can already open and process RAW files of many camera manufacturers in GIMP after installing the UFRaw plug-in from http://ufraw.sourceforge.net/. But I guess that "direct support" means something else for you?

Sven

On Sun, 2010-09-19 at 21:01 +0200, fufuz@gmx.net wrote:

Thanks, but I know UFRAW and I am also using it myself, but that's not the point of my question. I just wanted to know, when GIMP will support RAW processing out of the box.

Define "out of the box", please.

Sven

On 9/19/10, Hal V. Engel wrote:

UFRAW has a nice GIMP plug-in that has full RAW processing features. Not sure why it is necessary to reinvent the wheel.

There are different ways to deal with RAW images. A well-known proprietary analog of GIMP :) comes with a plug-in that takes care or doing that (just like UFRaw), but inserts processed images as smart objects, which means at any time later you can go back and tweaks things in that plug-in.

This is quite useful when you think about UFRaw and reimporting of resaved files. But when you think about it more, you'll immediately spot the problem even in this advanced solution: you have to start the plug-in, whereas if typical RAW features were implemented natively, in case of GIMP -- as GEGL ops (some already are) -- you could change things in-place, which would only boost productivity.

IMO, at some point in the future darktable's plug-ins should be reimplemented as GEGL ops and pushed to GEGL upstream. But since I treasure my pathological inability to write code, I'd rather sit back and enjoy the show :)

Alexandre Prokoudine http://libregraphicsworld.org

On 9/20/10, fufuz wrote:

I read on the Internet, that GEGL will provide support for many raw format types of different camera manufacturers already by itself

Where I come from people say that the only thing that happens by itself is newborn kittens :)

GEGL already uses libopenraw library that is a can-opener for RAW file formats. Unfortunately as a project this library seems to be dead. There are other open/free libraries for dealing with RAW, like LibRaw, so this is not exactly the issue.

The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...]

The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered.

[...]

A problem I talked about with people more than once.

I for myself like writing code from scratch and find it very annoying and exerting to work with code I don't know.

So what I often asked for is something like an overview on the Gimp-code. A documentation could help, but I personally would prefer workshops, where I can ask the more expereienced developers on who things are done.

This saves a lot of time and can motivate people.

Otherwise some developers that could help a lot would just do different things.

I looked at Gimp's code, and it's much code.

I don't know how other people see it, but such an intro-workshop would make sense to me. It's just a matter of effective work. Some things can be said in one or two sentences as answer for a question, or otherwise would take people weeks to get it from documentation (or even longer, if the docukmentation is spare or outdated).

Different people, different working and learning styles.

If thge core developers insiste that poeple who want to help has to have frustrating time consuming experiences with other people's code first, than no wonder development has slow progress.

Some weeks ago I asked on irc for some help in gimp script programming. The answers I got were rather uninformed - from people who seem to be developers in Gimp. No useful answer, rather rhetoric questions instead of answers.

I then got the answer from someone else, who has nothing to do with Gimp coe development, but did a lot Gimp scripting.

For me this was again something like: even the core developers don't know Gimp, but someone else, who rather is artist and does some scripting for himself, knows the details.

IMHO this comes from the behaviour that people just look at some code, start to hack and don't know the rest of the program. And I would guess, that's, because there is nobody who has an overview, or at least nobody who want's to provide that knowledge in a way that other people can jump in more easily - withgout just looking at some small portions of the code.

The time that is needed to look into a big bunch of code could also, maybe more effectively be used to write something different from scratch.

And that's maybe the reason, or at least one of the reasons, why there are not enough people that work in the Gimp core ("shorthanded and outnumbered").

Ciao, Oliver

On Mon, Sep 20, 2010 at 7:38 AM, wrote:

On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...]

The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered.

[...]

Oliver -

this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first.

What do you mean by a "workshop"? Like a physical face to face class, where one would be pointing "this is the tools directory, inside it there are the files that ,make for the tool classes..."? Not shure if that could help.

Anyway, I've written an article a couplle of months ago that is now published here:
http://www.ibm.com/developerworks/linux/library/os-gimp/index.html?ca=drs- Maybe that fulfills part of what you call "a workshop".

Now, please - these kindof rants won't change anyones atitude in here - the developers willjust feel ill towards you. Keep experimenting, trying, learning, and asking about code - refrain from rants: they just take us nowhere.

regards,

js ->

(...)

Ciao,
  Oliver

On Mon, Sep 20, 2010 at 09:25:12AM -0300, Joao S. O. Bueno wrote:

On Mon, Sep 20, 2010 at 7:38 AM, wrote:

On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...]

The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered.

[...]

Oliver -

this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first.

[...]

I didn't say people should not look into the code.

I meant: before looking into the code, an OVERVIEW on the code base would be helpful.

Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me.

I say it again: there are different styles of work. Is this is not addressed, then it makes no sense to mourn about shorthanded and outnumbered developers.

If that situation should be changed, new developeers should be invited. And not everybody who could contribute will have enough time to read Megabytes of Code, just for fun.

Ciao, Oliver

On 20 September 2010 15:10, wrote:

Is this is not addressed, then it makes no sense to mourn about shorthanded and outnumbered developers.

You're more than welcome to address the issue.

On 9/20/10, oliver wrote:

On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...]

The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered.

[...]

A problem I talked about with people more than once.

Not here, perhaps? :)

So what I often asked for is something like an overview on the Gimp-code. A documentation could help,

It is true that dev documentation is lacking essential bits for new developers. Barak Itkin used to have beginnings of GIMP's architecture overview. I wonder what stage the document is in :)

but I personally would prefer workshops, where I can ask the more expereienced developers on who things are done.

Workshops organized by...? Where? On whose money?

This saves a lot of time and can motivate people.

You live in Germany, as several GIMP developers do. Last thing I heard is that developers want to have a face-to-face meeting some time around release of 2.8 or maybe before (if I got that right). Thy will be occupied with things, but maybe they can find time to talk to you as well?

Otherwise some developers that could help a lot would just do different things.

In my experience people who really want to contribute find IRC good enough for discussing things. This is how the project acquired some of our most valuable contributors despite of lacking documentation and no workshops.

Some weeks ago I asked on irc for some help in gimp script programming. The answers I got were rather uninformed - from people who seem to be developers in Gimp.

Seem to be or are developers? Do you understand that you base your judgments on an assumption and proceed with them as if the assumption was correct? This is not nice really.

No useful answer, rather rhetoric questions instead of answers.

That still keeps a possibility of a question asked in a particular style :)

I then got the answer from someone else, who has nothing to do with Gimp coe development,
but did a lot Gimp scripting.

So the problem was solved then?

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Sep 20, 2010 at 2:10 PM, wrote:

Oliver -

this rant has no reason to be.  Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first.

[...]

I didn't say people should not look into the code.

I meant: before looking into the code, an OVERVIEW on the code base would be helpful.

Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me.

I'll bite ?

There is various libraries that GIMP depends on:

glib - does portable reusable low level data structures, and includes GObject which provides the basis for OOP in GIMP gtk+ - is a UI toolkit that was created for use with GIMP that is now widely used also elsewhere
babl - is a pixelformat conversion library that provides dynamic and efficient conversion of pixel formats. GEGL - is a graph based image processing framework that together with its plug-ins is destined to replace almost all code in GIMP and its plug-ins, doing work on the legacy 8bit code in GIMP will most often result in the brave new world promised by GEGL to be further postponed.

I maintain two of these projects, babl and GEGL, the following links point to overviews of the directory structures used for their source codes:

http://gegl.org/#_directory_overview , http://gegl.org/babl/#DirectoryOverview

/Øyvind K.

On Mon, 2010-09-20 at 01:11 +0200, fufuz@gmx.net wrote:

Without the requirement of installing separate software/plug-ins.

GIMP can't load or save any file format except XCF without separate plug-ins. So by your definition of "native support" GIMP doesn't support any file formats except XCF. Most features in GIMP are implemented as plug-ins. So I don't see your point in asking us to add RAW support to the core. There's a plug-in for it, just as for any other file format.

What's admittedly missing is the ability of the core to process files in higher bit depths than 8bit per pixel. This is definitely on the roadmap.

I read on the Internet, that GEGL will provide support for many raw format types of different camera manufacturers already by itself, without the need of UFRAW or anything else.

That is wrong. GEGL will also use third-party libraries to read and write RAW files. We are certainly not going to reinvent the wheel.

Sven

On Mon, Sep 20, 2010 at 7:44 PM, Sven Neumann wrote:

... GEGL will also use third-party libraries to read and write RAW files. We are certainly not going to reinvent the wheel.

GEGL already supports using dcraw to load raw files using the operations gegl:raw-load uses the dcraw binary, reading back the decompressed data using pipes.

http://git.gnome.org/browse/gegl/tree/operations/common/raw-load.c

There is also an operation in the operations workshop called gegl:rawbayer-load that can be used to only get the grayscale matrix allowing to use a custom operation for the demosaicing.

/Øyvind K.

On Mon, Sep 20, 2010 at 05:31:07PM +0100, Øyvind Kolås wrote:

On Mon, Sep 20, 2010 at 2:10 PM, wrote:

Oliver -

this rant has no reason to be.  Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first.

[...]

I didn't say people should not look into the code.

I meant: before looking into the code, an OVERVIEW on the code base would be helpful.

Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me.

I'll bite ?

There is various libraries that GIMP depends on:

[...]

I maintain two of these projects, babl and GEGL, the following links point to overviews of the directory structures used for their source codes:

[...]

Thanks.

I already have decided to write some code on top of GEGL. If it progresses as I hope, this will be something that I will use instead of Gimp-scripting.

Nevertheless a program wiuth GUI would be fine, so I hope Gimp will progress fast, if not with my help, then maybe without it.

Ciao,
Oliver

On Mon, 2010-09-20 at 22:18 +0200, fufuz@gmx.net wrote:

GIMP can't load or save any file format except XCF without separate plug-ins. So by your definition of "native support" GIMP doesn't support any file formats except XCF. Most features in GIMP are implemented as plug-ins. So I don't see your point in asking us to add RAW support to the core. There's a plug-in for it, just as for any other file format.

You get me wrong! I don't say to program it into the core, I am just suggesting, that GIMP should already be shipped with all the required stuff (third-party libraries/plug-ins) that's needed to open/write raw files, instead of depending on software, that has to be downloaded/installed separately.

Then you should direct that suggestion to your distribution of choice. We don't decide what's included in the GIMP package that you install. I agree that it would be a good idea if the gimp-ufraw package was suggested whenever you select gimp for installation. It should probably also be included in the Windows installer.

Sven

Quoting "Joao S. O. Bueno" :

Oliver -

this rant has no reason to be. Sorry for that.

I disagree. Oliver has politely raised an issue to be discussed and presents some valid points.

GIMP is nearly a million lines of code -- well over a million if you take into account GEGL and BABL. If a potential code contributor examine 1000 lines of code each and every day, it would take nearly three years before his perusal would be complete.

GIMP employs some rather creative coding approaches which a not exactly common knowledge to traditionally trained programmers. The GLIB object system itself is well documented and it is obviously employed throughout GIMP (and its documentation appropriately linked to on developer.gimp.org), but how is a potential contributor to learn the philosophy underlying the various object/method hierarchies? For example, why is transformation a method of a tool object, and not a method of the object being transformed? Oftentimes understanding the reasoning behind programming decisions is useful, if not critical, to understanding the programming itself.

Libgimp also is not what I would expect an application's library to be. Instead of being a library of functions which GIMP invokes but are factored out so other programs can make use them separate from GIMP, the opposite seems to be the case: libgimp invokes functions internal to GIMP (other programs can thus use libgimp, but only if GIMP is running).

In fact, it seems that a libgimp function will typically call a PDB function, which provides the interface to the internal GIMP function. Of course the PDB function doesn't exist in the original GIMP source code but is generated by a Perl script. And the internal GIMP function isn't called directly but is an invocation of an object's method which is defined at runtime.

I'm no doubt completely off-base in the above analysis, but then that is rather the point. How does a potential contributor get from reading the GTKDOC description of a libgimp function to finding the section of source code in the GIMP tree that actually implements the function? It may be just my own incompetence, but I've been unsuccessful more often than not in doing this.

Anyway, I've written an article a couplle of months ago that is now published here:
http://www.ibm.com/developerworks/linux/library/os-gimp/index.html?ca=drs- Maybe that fulfills part of what you call "a workshop".

That is precisely the type of documentation of which more is needed to encourage participation in the GIMP project -- both the GIT tutorial and the "how to write a tool". I applaud your effort and hope you would consider additional installments (if you are considering further installments, might I propose "how to expose an internal GIMP function to the PDB").

Now, please - these kindof rants won't change anyones atitude in here - the developers willjust feel ill towards you. Keep experimenting, trying, learning, and asking about code - refrain from rants: they just take us nowhere.

I can certainly understand the GIMP developers not being enthusiastic about writing development documentation, but that does not mean that the existing gaps aren't problematic for potential contributors. Perhaps a solution can be found that doesn't require an "attitude change", but still seeks to address the issue. Maybe a "contributors wiki" could be created, where those of us who are trying to learn GIMP's codebase can create documentation from our experiences, and the more knowledgeable developers could visit periodically and fix things that are inaccurate (if such a wiki were created, I'd volunteer to administrate it).

On 09/20/2010 10:51 PM, Sven Neumann wrote:

On Mon, 2010-09-20 at 22:18 +0200, fufuz@gmx.net wrote:

GIMP can't load or save any file format except XCF without separate plug-ins. So by your definition of "native support" GIMP doesn't support any file formats except XCF. Most features in GIMP are implemented as plug-ins. So I don't see your point in asking us to add RAW support to the core. There's a plug-in for it, just as for any other file format.

You get me wrong! I don't say to program it into the core, I am just suggesting, that GIMP should already be shipped with all the required stuff (third-party libraries/plug-ins) that's needed to open/write raw files, instead of depending on software, that has to be downloaded/installed separately.

Then you should direct that suggestion to your distribution of choice. We don't decide what's included in the GIMP package that you install. I agree that it would be a good idea if the gimp-ufraw package was suggested whenever you select gimp for installation. It should probably also be included in the Windows installer.

I think the point here is that configure, make, make install on a GIMP tarball - with all dependencies met - should result in a GIMP installation with good support for working with RAW images.

And I agree with that, we should not rely on third party packagers to help us fulfil our product vision.

/ Martin

On Mon, 2010-09-20 at 20:13 -0400, saulgoode@flashingtwelve.brickfilms.com wrote:

Quoting "Joao S. O. Bueno" :

Oliver -

this rant has no reason to be. Sorry for that.

I disagree. Oliver has politely raised an issue to be discussed and presents some valid points.

GIMP is nearly a million lines of code -- well over a million if you take into account GEGL and BABL. If a potential code contributor examine 1000 lines of code each and every day, it would take nearly three years before his perusal would be complete.

That's why we have the devel-docs folder in the GIMP source tree where we try to explain the structure of the source code and document the internal and external APIs as well as file formats. Sure, there should be more documentation like this. Everyone is invited to contribute.

Libgimp also is not what I would expect an application's library to be. Instead of being a library of functions which GIMP invokes but are factored out so other programs can make use them separate from GIMP, the opposite seems to be the case: libgimp invokes functions internal to GIMP (other programs can thus use libgimp, but only if GIMP is running).

Taking your example, the role of libgimp is explained in devel-docs/structure.xml. Sure, this documentation could be extended to make things even more clear. Everyone is invited to contribute.

Sven

On Tue, 2010-09-21 at 07:53 +0200, Martin Nordholts wrote:

I think the point here is that configure, make, make install on a GIMP tarball - with all dependencies met - should result in a GIMP installation with good support for working with RAW images.

Oh come on. The ufraw plug-in is much better maintained outside the GIMP source tree. No one would benefit if we tried to include all third-party plug-ins in the GIMP source tree. That's just silly. Our product vision states that GIMP should be easily extendable. Instead of adding more plug-ins to the source tree, as you suggest, we should work on making it easier for users to install additional plug-ins.

Sven

On Wed, 22 Sep 2010 22:35:49 +0200, Sven Neumann wrote:

On Tue, 2010-09-21 at 07:53 +0200, Martin Nordholts wrote:

I think the point here is that configure, make, make install on a GIMP tarball - with all dependencies met - should result in a GIMP installation with good support for working with RAW images.

Oh come on. The ufraw plug-in is much better maintained outside the GIMP source tree. No one would benefit if we tried to include all third-party plug-ins in the GIMP source tree. That's just silly. Our product vision states that GIMP should be easily extendable. Instead of adding more plug-ins to the source tree, as you suggest, we should work on making it easier for users to install additional plug-ins.

As the maintainer of one of those outside the tree plugins (the enhance Print plugin with Gutenprint), I have to agree with this. Keep in mind that one of the big reasons for Photoshop's success is the variety of externally available plugins available for it that offer functionality well beyond that of the core application.

This is particularly important for things like non-standard file formats (such as RAW, which is camera-specific and new formats come along with each new camera release). It's simply not practical for GIMP to do a new release with every new RAW sub-format, while the ufraw team is well equipped to do so.