Re: [Gimp-developer] LAB in Info Window

2010-10-23 Thread Sven Neumann
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


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-22 Thread Alexandre Prokoudine
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] LAB in Info Window

2010-10-22 Thread jcupitt
> 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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-21 Thread Graeme Gill
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.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-21 Thread Øyvind Kolås
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.

/Øyvind Kolås
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-21 Thread Martin Nordholts
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


-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-21 Thread Sven Neumann
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


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-21 Thread Sven Neumann
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


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LAB in Info Window

2010-10-21 Thread Martin Nordholts
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



-- 

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds"
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] LAB in Info Window

2010-10-21 Thread Jacek Poplawski
Hello,

Few days ago I asked about LAB/CMYK plans in Gimp, I am not sure
what's the current status is, so maybe I will try another question.

In Gimp one can use "Color Picker Tool", set "use info window" and
will see "Color Picker information" with color values.
There are 4 types of colorspace to choose:
1) Pixel
2) RGB
3) HSV
4) CMYK

I want to add LAB version, and after that, I want to fix (or just add
new) CMYK version - cyan is almost always 0% now.

It doesn't look very complicated, there is already gimp_rgb_to_cmyk
and gimp_rgb_to_hsv and inside decompose.c there is full code of
gimp_rgb_to_lab, just not placed in separate function. Then I will
need to add it to gimpcolorframe.c and it should work :)

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

PS. I use gimp-git
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer