On 10/21/2010 09:10 PM, Jacek Poplawski wrote:

The question is - can I do it? Can I submit a patch somewhere and it could be commited into development branch?

Of course you can!

I suggest you create a patch and attach it to a new bug report filed at bugs.gimp.org. Don't forget to take the active color profile into account.

Regards, Martin

On Thu, 2010-10-21 at 21:26 +0200, Martin Nordholts wrote:

On 10/21/2010 09:10 PM, Jacek Poplawski wrote:

The question is - can I do it? Can I submit a patch somewhere and it could be commited into development branch?

Of course you can!

I suggest you create a patch and attach it to a new bug report filed at bugs.gimp.org. Don't forget to take the active color profile into account.

You can't really take the active color profile into account unless we decide to add a dependency on littlecms to the core. The whole color management system would basically need to be rewritten. This has the potential to allow some important improvements all over the place. But we really need someone willing and capable to finish this work if we want to open this can of worms.

Sven

On Thu, 2010-10-21 at 23:23 +0200, Martin Nordholts wrote:

You can't really take the active color profile into account unless we decide to add a dependency on littlecms to the core. The whole color management system would basically need to be rewritten. This has the potential to allow some important improvements all over the place. But we really need someone willing and capable to finish this work if we want to open this can of worms.

The experiment doesn't need to take place in git master though, we can create an experimental branch if we get a set of interesting patches. So it doesn't matter if it gets finished or not, we either abandon or merge that experimental branch depending on the outcome.

If someone starts experimenting with this, I suggest making littlecms one of potentially backends, so that we can compile against the native color management library of a platform when available.

That is what the current color management infrastructure does. So far no one has ever expressed any interest in implementing a native backend though. So I guess we better abandon that idea and just use lcms for all platforms. Would be a lot easier if lcms could be used in the core and if we wouldn't have to create some sort of abstraction layer that fits all color management backends.

But then we might run into trouble when cairo gets color management capabilities. Currently display color management is totally broken in trunk, so we need to find a way out of this anway...

Sven

On 10/21/2010 11:30 PM, Sven Neumann wrote:

On Thu, 2010-10-21 at 23:23 +0200, Martin Nordholts wrote:

If someone starts experimenting with this, I suggest making littlecms one of potentially backends, so that we can compile against the native color management library of a platform when available.

That is what the current color management infrastructure does. So far no one has ever expressed any interest in implementing a native backend though. So I guess we better abandon that idea and just use lcms for all platforms. Would be a lot easier if lcms could be used in the core and if we wouldn't have to create some sort of abstraction layer that fits all color management backends.

I guess you're right. It won't be hard to retrofit an abstraction on top of littlecms if the need arises anyway.

/ Martin

On Thu, Oct 21, 2010 at 10:03 PM, Sven Neumann wrote:

On Thu, 2010-10-21 at 21:26 +0200, Martin Nordholts wrote:

On 10/21/2010 09:10 PM, Jacek Poplawski wrote:

The question is - can I do it? Can I submit a patch somewhere and it could be commited into development branch?

Of course you can!
I suggest you create a patch and attach it to a new bug report filed at bugs.gimp.org. Don't forget to take the active color profile into account.

You can't really take the active color profile into account unless we decide to add a dependency on littlecms to the core. The whole color management system would basically need to be rewritten. This has the potential to allow some important improvements all over the place. But we really need someone willing and capable to finish this work if we want to open this can of worms.

Shedding some light on this can of worms from my perspective babl and GEGL perspective:

I think the best thing for now is to not take the color profile into account, and make that assumption that GIMP is working on sRGB data...

The responsibility for color management in GEGL is distributed among the operations. Raster Buffers passed around are tagged with a BablFormat describing the pixel format (color space, bit depth and component permutations).

When files with ICC profiles are loaded they should either be converted upon load to a predefined BablFormat, or a BablFormat depending on lcms should be dynamically constructed referencing the ICC profile.

Operations are performed in whatever is their preferred working space, some natural spaces here are RGBA float, RaGaBaA float, CIE Lab float and Y float. The meaning of these formats is well defined thus the behaviour of operations will be predictable and fully color managed.

The "active profile" is the final transformation to be applied to the color data after it leaves GEGL/gets saved (within GEGL data is most likely mostly stored as RaGaBaA float). User interface elements showing color triplets or quadruplets like the color picker would use babl to transform single pixels of data to and from CIE Lab, R'G'B'A u8 and similar. When using an output target profile lcms should either be used directly or indirectly through babl. The profile of your display as well as soft proofing and rendering intents is not
relevant for these bits.

/

Sven Neumann wrote:

But then we might run into trouble when cairo gets color management capabilities. Currently display color management is totally broken in trunk, so we need to find a way out of this anway...

This is unlikely. For one thing, what is cairo likely to use ? - lcms. For another, you don't have to use other underlying CMM's, as long as the underlying device colorspaces are exposed. It can help to have access to system configuration information (ie. an association between devices and their color profiles), and for this some platform independent wrapper is desirable, but in the first instance you can ignore all of that and have the user select the profiles manually. Retrieving the display profiles automatically would be nice though, and there is code around to do this on various platforms (I've certainly written some under GPL for MSWin, OS X and Linux).

Graeme Gill.

On Thu, 2010-10-21 at 23:23 +0200, Martin Nordholts wrote:

If someone starts experimenting with this, I suggest making littlecms one of potentially backends, so that we can compile against the native color management library of a platform when available.

The native CMS is often horribly unreliable and incomplete. The one that ships with XP, for example, is almost unusable. I think this component has been replaced now, but the new version is still missing support for more recent profiles (hope I have that right). Gimp would need to make at least three Windows binaries: LCMs, XP and Vista+. They'd produce subtly different results in hard to explain ways.

Photoshop gets around this by having it's own cms and using that on all platforms. This helps make save files work between platforms too. I think it would be quite reasonable for GIMP to do the same.

John

On 10/22/10, jcupitt wrote:

The native CMS is often horribly unreliable and incomplete. The one that ships with XP, for example, is almost unusable. I think this component has been replaced now, but the new version is still missing support for more recent profiles (hope I have that right). Gimp would need to make at least three Windows binaries: LCMs, XP and Vista+.

What would be the point of that, when one could implement abstraction layer for pluggable CMMs and LittleCMS as default CMM? It's what Scribus team was working on last summer.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, 2010-10-22 at 11:15 +1100, Graeme Gill wrote:

Retrieving the display profiles automatically would be nice though, and there is code around to do this on various platforms

Code for retrieving the display color profile from the operating system is already in place in GIMP for X11 and Mac OS.

Sven