Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread David Gowers
On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz j...@joncruz.org wrote:
 However, the answer to the base question is Yes, X and Gtk support that to
 a very good degree, and all the low-level API's support delivering all the
 required information.
 and No, X does nothing with the colorspaces. It is left to the application
 to implement
 It also is more of a per-monitor issue, rather than per-pixel. So one
 generally will have to deal with a small set of rectangles (two being the
 most common) to adjust. So it's not *quite* up to the complexity of a purely
 per-pixel problem.
 I also would question the assertion that it is an uncommon use case. Those
 most likely to be working seriously with images are generally much likely to
 have two (or more) monitors. They also have a higher chance of caring about
 color fidelity.

I agree; GIMP windows should support color management for individual
image windows according to these atoms, absolutely;
What it would be of little use to do, is to support showing the SAME
image in a single window spanning multiple monitors, with different
colormanagement for each monitor-segment of that Single window.
As I understand, that is what Christopher was requesting and yahvuu
was accurately describing as an uncommon use case, rather than the
general case of one image window on this monitor, one on that, and
they are color managed differently because of it.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-13 Thread yahvuu
David Gowers wrote:
 * Color selector colors must be stored in a profile independent
 colorspace (LAB?[1]). This ensures that we can paint any color onto
 any image and get the right result. Otherwise, we'd have to know the
 profile that the color was specified in, in order to use the correct
 color on the image we're painting in now.. which makes color storage
 way too heavyweight.
[..]
 * We should be able to a) specify colors outside of the color profile gamut
   and b) clip the current color to the limits of the current color
 profile when painting, previewing etc.
   b) should probably be a toggle, then it could be quite helpful in
 quick soft-proofing

simpler:

Color selectors give an overview of available colors and
display a few selected colors, namely fg/bg color plus history.


The range of available colors changes with the current working color space,
and the color selectors should reflect that. E.g. the colors inside the
'triangle' should change according to current working space.

The selected colors however, should be transferable between images and
thus need to be stored in an absolute color space. Gamut warnings
indicate when they are outside the current working space.
(They may well be outside of display gamut as well..)


everything IMHO,
yahvuu

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread yahvuu
Christopher Curtis wrote:
 What happens in a multi-head setup when I maximize an image over (say)
 a CRT and an LCD?  Does monitor profile take this into account?

Following the logic of the diagram, i'd say yes:
your case is equivalent to cutting an image into two pieces and printing
one piece with an ink jet and the other one with a laser printer.

In reality, the wall of monitors probably won't work like that as long
as GIMP has to manage the windows' colors. As others have said, it is
unreasonable to manage split windows at application level.

However, in those places where color is really important,
a second monitor means additional calibration cost
and an additional potential source of error, i guess.


regards,
yahvuu

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Christopher Curtis
On Sat, Feb 13, 2010 at 5:39 AM, yahvuu yah...@gmail.com wrote:
 Christopher Curtis wrote:
 What happens in a multi-head setup when I maximize an image over (say)
 a CRT and an LCD?  Does monitor profile take this into account?

 Following the logic of the diagram, i'd say yes:
 your case is equivalent to cutting an image into two pieces and printing
 one piece with an ink jet and the other one with a laser printer.

I don't know that I'd agree with that; the example was not meant as a
use-case, just a demonstration of a potential problem.  One could
argue that you'd need to print exactly this way to take advantage of
the specific gamuts (or materials) of each device.

But that's not my point.  I would rather suggest this:  that GIMP not
do colorspace management of the display profile at all, and rely on X
to do the right thing even if it does not do so today.

Imagine you are editing some image on one screen and trying to match
another image opened in another program on a different head.  This
other program is not colorspace aware because it's scientific modeling
data or whatever so you have this dichotomy.  In reality, you may
never be able to match the colors because of the different display
device gamuts.  Maybe you can work around this with 'Acquire Image -
Screen Shot' but isn't that really too burdensome?

You could push colorspace management into GTK, which would be better,
but at the end of the day only one thing should be transforming gamuts
and I think that thing is X.  Perhaps GTK and X can negotiate who's in
control so it becomes optional at the GTK level, but then you have the
possibility that the transformations are implemented differently and
slightly incompatibly.  I think it's better to fix the problem once
and to do so in a way that all applications can take advantage of it.

It is X's job to render the final display, whether it's local, remote,
DPS, Xprt, or whatever else X can render to.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Hal V. Engel
On Saturday 13 February 2010 09:15:13 am Christopher Curtis wrote:
 On Sat, Feb 13, 2010 at 5:39 AM, yahvuu yah...@gmail.com wrote:
  Christopher Curtis wrote:
  What happens in a multi-head setup when I maximize an image over (say)
  a CRT and an LCD?  Does monitor profile take this into account?
 
  Following the logic of the diagram, i'd say yes:
  your case is equivalent to cutting an image into two pieces and printing
  one piece with an ink jet and the other one with a laser printer.
 
 I don't know that I'd agree with that; the example was not meant as a
 use-case, just a demonstration of a potential problem.  One could
 argue that you'd need to print exactly this way to take advantage of
 the specific gamuts (or materials) of each device.
 
 But that's not my point.  I would rather suggest this:  that GIMP not
 do colorspace management of the display profile at all, and rely on X
 to do the right thing even if it does not do so today.
 
 Imagine you are editing some image on one screen and trying to match
 another image opened in another program on a different head.  This
 other program is not colorspace aware because it's scientific modeling
 data or whatever so you have this dichotomy.  In reality, you may
 never be able to match the colors because of the different display
 device gamuts.  Maybe you can work around this with 'Acquire Image -
 Screen Shot' but isn't that really too burdensome?
 
 You could push colorspace management into GTK, which would be better,
 but at the end of the day only one thing should be transforming gamuts
 and I think that thing is X.  Perhaps GTK and X can negotiate who's in
 control so it becomes optional at the GTK level, but then you have the
 possibility that the transformations are implemented differently and
 slightly incompatibly.  I think it's better to fix the problem once
 and to do so in a way that all applications can take advantage of it.
 
 It is X's job to render the final display, whether it's local, remote,
 DPS, Xprt, or whatever else X can render to.
 
 $0.02
 Chris

I some ways I agree with Chris but the X.Org developers have insisted on an 
ongoing basis that it is NOT their responsibility to handle color management 
of the display.   If we wait for X.Org to implement CM it will likely never 
happen.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Jon Cruz

On Feb 13, 2010, at 9:42 AM, Hal V. Engel wrote:

 I some ways I agree with Chris but the X.Org developers have insisted on an 
 ongoing basis that it is NOT their responsibility to handle color management 
 of the display.   If we wait for X.Org to implement CM it will likely never 
 happen.

I'd definitely second this point. I've been in many discussions with several 
key players in this arena, and when all technical details are explored it does 
seem to come down to the points that X11 does not and should not deal with 
color management in these regards and needs to leave it to the individual apps. 
To get a fully usable system, X11 would require some major reworking, and thus 
won't be seen any time soon.

Of course, to end up with an optimal workflow for end users, GTK could be 
adapted to handle a fair bit by itself (and, yes, there is work happening on 
this at the moment). Toolbars, icons, menus, color selectors, etc., ideally 
would be color managed by GTK. But whatever automatic color management is 
added to GTK needs to be done in such a way as to allow the smart programs 
(such as GIMP) to hook in and control/override as needed.___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Jon Cruz

On Feb 13, 2010, at 2:39 AM, yahvuu wrote:

 
 In reality, the wall of monitors probably won't work like that as long
 as GIMP has to manage the windows' colors. As others have said, it is
 unreasonable to manage split windows at application level.

Well, personally I don't consider it unmanageable at all to have an application 
manage split windows. Especially with all the detail being presented via GTK on 
the geometry and positioning of the monitors, this is a fairly trivial matter. 
That's trivial in the abstract case, of course. The main complication will be 
in the details of hooking GIMP's display code at the very last moment (since 
among other things color management adjustments need to be done once and only 
once and on the final result just before it gets sent to the display).
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Jon Cruz

On Feb 13, 2010, at 12:08 AM, David Gowers wrote:

 I agree; GIMP windows should support color management for individual
 image windows according to these atoms, absolutely;
 What it would be of little use to do, is to support showing the SAME
 image in a single window spanning multiple monitors, with different
 colormanagement for each monitor-segment of that Single window.
 As I understand, that is what Christopher was requesting and yahvuu
 was accurately describing as an uncommon use case, rather than the
 general case of one image window on this monitor, one on that, and
 they are color managed differently because of it.

Ah, but that is exactly what I was thinking. I know the ancient-of-days 
workflow was to have one good color monitor for the actual images, and a 
monochrome control monitor with the buttons and interfaces to control the 
software. Over the years I've seen more and more users with two or three good 
monitors, including gamers and programmers in addition to artists. And I have 
seen such users have windows with images spanning those monitors very often.

I'd also point out that this single-window-across-multiple-monitors use case is 
exactly one of the main ones that artists using Macintoshes had been quite fond 
of pointing out to their poor cousins on Windows (when I've seen them do 
such, it reminds me very much how real programmers use Linux). It highlights 
the fact that MacOS has had good color management built in to the OS for years 
and years.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Christopher Curtis
On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz j...@joncruz.org wrote:

[...]
 does seem to come down to the points that X11 does not and should not deal
 with color management in these regards and needs to leave it to the
 individual apps. To get a fully usable system, X11 would require some major
 reworking, and thus won't be seen any time soon.

Do you have a reference to these discussions?  It seems like X
*should*, accepting that it may be difficult.

 Of course, to end up with an optimal workflow for end users, GTK could be
 adapted to handle a fair bit by itself (and, yes, there is work happening on
 this at the moment). Toolbars, icons, menus, color selectors, [...]

I was just going to say here that putting it in GTK could also 'fix'
the color selector issues; let me just emphasize that point here.


On a more philosophical note, how does one represent a color that does
not exist on a display but does on an output device?  Do we make the
assumption that the display always has the widest gamut?  (I.e: GIMP
will never run on a mono/CGA device and print to a CMYK printer.)  Is
that a concern?

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Graeme Gill
David Gowers wrote:
 Imo the video card is the correct handler of these issues. X should
 just upload an appropriate lookup table (which is functionality
 already available in X, but doesn't happen automatically). Presumably
 a multihead video card allows multiple LUTs. From that point of view,
 it might make most sense for the desktop environment to do the
 uploading of the LUT(s), since you would probably use it to select and
 test the profile.

Calibration != Profiling

While most cards have per channel Luts, none will have
per rendering context 3D color transforms (although it
can be simulated using 3D texture lookups). Rendering
context is usually somewhere up the rendering stack though,
not something the hardware will be directly aware of.
(It's rendering context because the transform depends on
the source colorspace  intent as well as the display
profile. In general it's not a 3x3 matrix transform either.)

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Graeme Gill
Christopher Curtis wrote:
 On a more philosophical note, how does one represent a color that does
 not exist on a display but does on an output device?  Do we make the
 assumption that the display always has the widest gamut?  (I.e: GIMP
 will never run on a mono/CGA device and print to a CMYK printer.)  Is
 that a concern?

There's nothing special about this. In general any transformation
from one colorspace to another has to cope with different gamuts.
You simply choose how to handle it (ie. clip, perceptually map, etc.)
by choosing an intent.

It's not unknown to have a mode in an image editor that compresses the
gamut of the source so that a very large gamut image can be viewed
on a limited gamut display without loosing the ability to be able
to see all its color variations. Naturally it will look a lot
duller than it will when displayed on the intended device.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Omari Stephens
On 02/12/2010 04:55 PM, yahvuu wrote:
 Hi,

 here are some diagrams depicting selected configurations for colormanagement:
 http://yahvuu.files.wordpress.com/2009/08/dataflow.png

I believe number 1 is incorrect:
All images in GIMP will have a color profile.  This will either be the 
implicit sRGB profile, or some explicit profile.  Similarly, in the case 
where the monitor has no explicit display profile, we send it RGB on the 
assumption that it mostly conforms to sRGB.

More specifically, that means that everywhere we display an image will 
be color-managed, even if that image isn't explicitly tagged with a 
profile.  Color-related tools (the color picker comes to mind) should 
always function relative to the color profile of the image, be it 
explicit or implicit.  This may spell some interesting changes for 
Curves and Levels down the line; I'm not sure.


For 2, an image that, when imported, does not have any explicit color 
profile information will be exported without saving any explicit color 
profile information (unless an explicit color profile was added).  I 
also do not understand why 2a and 2b are separated.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Martin Nordholts
On 02/12/2010 06:27 PM, Omari Stephens wrote:
 On 02/12/2010 04:55 PM, yahvuu wrote:
 Hi,

 here are some diagrams depicting selected configurations for colormanagement:
 http://yahvuu.files.wordpress.com/2009/08/dataflow.png

 I believe number 1 is incorrect:
 All images in GIMP will have a color profile.

People will want to create unmanaged images without a color profile for 
use on the web for example, so we need to handle images with no color 
profile attached. I think introducing the conepts of implicit profiles 
adds unnecessary complexity.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Alexandre Prokoudine
On Fri, Feb 12, 2010 at 8:36 PM, Martin Nordholts wrote:

 People will want to create unmanaged images without a color profile for
 use on the web

That is, if people want to make everyone's lives more difficult, who
are we to stop them from doing so? :)

Just make web equal to sRGB as it already is.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread yahvuu
hi, and thanks for the feedback


Omari Stephens wrote:
 I believe number 1 is incorrect:

First thing to note is that i should have added a legend:
  - grey:   device-dependent colors, plain RGB values, no profile info 
available.
  - orange: colors from an absolute color space

Picture 1) was intended to show the situation before color management was
introduced: the RGB data gets exchanged between devices without any
conversion. The resulting colors are unknown as none of the devices
has been profiled or calibrated.


 All images in GIMP will have a color profile.  This will either be the 
 implicit sRGB profile, or some explicit profile.  Similarly, in the case 
 where the monitor has no explicit display profile, we send it RGB on the 
 assumption that it mostly conforms to sRGB.
 
 More specifically, that means that everywhere we display an image will 
 be color-managed, even if that image isn't explicitly tagged with a 
 profile.  Color-related tools (the color picker comes to mind) should 
 always function relative to the color profile of the image, be it 
 explicit or implicit.  This may spell some interesting changes for 
 Curves and Levels down the line; I'm not sure.

oh, i meant to talk about the principal configurations / UX options.
I hope that there's no conflict with implementation issues by now.
I'm working on a set of use cases to use as a decision aid...


 I 
 also do not understand why 2a and 2b are separated.

the goal was to make explicit that importing unmanaged data
and creating unmanged data on export might be unrelated.

For example, 2b) might be a photographer that opens a ClayRGB file from
his archive and exports a JPG without any profile information, for web use.


regards,
yahvuu

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Omari Stephens
On 02/12/2010 05:36 PM, Martin Nordholts wrote:
 On 02/12/2010 06:27 PM, Omari Stephens wrote:
 On 02/12/2010 04:55 PM, yahvuu wrote:
 Hi,

 here are some diagrams depicting selected configurations for 
 colormanagement:
 http://yahvuu.files.wordpress.com/2009/08/dataflow.png

 I believe number 1 is incorrect:
 All images in GIMP will have a color profile.

 People will want to create unmanaged images without a color profile for
 use on the web for example, so we need to handle images with no color
 profile attached. I think introducing the conepts of implicit profiles
 adds unnecessary complexity.

If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a 
display profile and opens an image-without-profile, what do we display? 
  We can't apply the display profile unless the image has some source 
color profile to link to the transform.  Hence, we assume sRGB to enable 
this and other situations to behave as correctly as possible.  The sRGB 
assumption is one what we already make, this change will simply make 
that assumption a bit more explicit.

In doing so, it allows us to stop special-casing for cases where the 
image may not have a color profile.  We gain uniformity of display logic 
and a decrease in code complexity by being able to assume the presence 
of a color profile as an invariant.

And the code itself is trivial: just add a give_me_color_profile 
function which returns icc-profile contents if present, or the sRGB 
profile otherwise.  (with a more-reasonable name, of course).

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Martin Nordholts
On 02/12/2010 07:18 PM, Omari Stephens wrote:
 If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a
 display profile and opens an image-without-profile, what do we display?
We can't apply the display profile unless the image has some source
 color profile to link to the transform.

This is where I suggest we use the working space color profile, although 
always using sRGB would work too in the scope of this discussion. Yes, 
in order to display the image we need to assume a color color profile, 
but the way I think this is different from thinking about the image as 
having an implicit color profile.


 In doing so, it allows us to stop special-casing for cases where the
 image may not have a color profile.  We gain uniformity of display logic
  and a decrease in code complexity by being able to assume the presence
  of a color profile as an invariant.

We need special casing either way, it's just a matter of where we have 
it. With your implicit profile strategy, we need a special case in the 
export code and image property code:

   if image.color_profile_implicit()
 color_profile = null
   else
 color_profile = image.get_color_profile()

while with my strategy it would be in the display code:

   color_profile = image.get_color_profile()
   if (color_profile == null)
 color_profile = gimp.get_working_space_color_profile()

Since we want to support working with non-color managed images it is 
more logical to handle images with no associated color profile than to 
handle images with implicit color profiles.

Images always have an associated color profile is by design not an 
invariant.


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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Christopher Curtis
On Fri, Feb 12, 2010 at 11:55 AM, yahvuu yah...@gmail.com wrote:

 here are some diagrams depicting selected configurations for colormanagement:
 http://yahvuu.files.wordpress.com/2009/08/dataflow.png

What happens in a multi-head setup when I maximize an image over (say)
a CRT and an LCD?  Does monitor profile take this into account?

I think my question is: Is X handling the colorspace or are profiles
being applied on individual pixel regions?  Is this even supported or
is there something else I'm not understanding at a very basic level?

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


Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-12 Thread SHIRAKAWA Akira
On 2010-02-09 19:52, Martin Nordholts wrote:
 GIMP is nearly flawless in its color handling, but there is one
 problem. It forgets to convert copy and pasted image content.

Also don't forget that the various color picker/selectors aren't color 
managed at the moment, so selected colors (FG/BG colors) will look 
differently when painted on a color managed image.

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


Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-12 Thread David Gowers
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira
shirakawa.ak...@gmail.com wrote:
 On 2010-02-09 19:52, Martin Nordholts wrote:
 GIMP is nearly flawless in its color handling, but there is one
 problem. It forgets to convert copy and pasted image content.

 Also don't forget that the various color picker/selectors aren't color
 managed at the moment, so selected colors (FG/BG colors) will look
 differently when painted on a color managed image.

I think color management of individual colors and color selectors is a
tricky subject.

* Color selector colors must be stored in a profile independent
colorspace (LAB?[1]). This ensures that we can paint any color onto
any image and get the right result. Otherwise, we'd have to know the
profile that the color was specified in, in order to use the correct
color on the image we're painting in now.. which makes color storage
way too heavyweight.

* We should consider improving the color history system.
  MyPaint has one with the property that I think is important here: A
color gets added to the history once it is 'read' (in Mypaint's case,
when you paint with it;
   In GIMP's case, this would also be if it was read via the PDB (ie
plugins or scripts)). And the previous color is shown in the color
selector side-by-side to
the color you're now adjusting. This makes it easier to do color
comparisons, which are pretty important to get right when the previous
color and current color are based on different color profiles.

* We should be able to a) specify colors outside of the color profile gamut
  and b) clip the current color to the limits of the current color
profile when painting, previewing etc.
  b) should probably be a toggle, then it could be quite helpful in
quick soft-proofing

* Some of the color selectors are already quite slow (eg. the 'scales' one).
  We should avoid making them slower if possible.

[1] correct me if I'm wrong here... scRGB might do the job okay, I'm
not 100% sure.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Omari Stephens
On 02/12/2010 10:12 PM, Christopher Curtis wrote:
 On Fri, Feb 12, 2010 at 11:55 AM, yahvuuyah...@gmail.com  wrote:

 here are some diagrams depicting selected configurations for colormanagement:
 http://yahvuu.files.wordpress.com/2009/08/dataflow.png

 What happens in a multi-head setup when I maximize an image over (say)
 a CRT and an LCD?  Does monitor profile take this into account?

 I think my question is: Is X handling the colorspace or are profiles
 being applied on individual pixel regions?  Is this even supported or
 is there something else I'm not understanding at a very basic level?

This is an uncommon usecase that would require too much effort to 
support properly for the small amount of benefit.

X11 has an atom which stores one ICC display profile per screen.  We 
would have to change the display transform depending on which screen 
each pixel shows up on.  This would also mean that we'd have to deal 
with the case where an image tile is split across two screens.

Again, this would be a lot of code (and, thus, the potential for a lot 
of bugs).  It would be infrequently used (and so the bugs would tend to 
not be found as quickly).  And it would likely slow down our common code 
paths for little benefit.

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


Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Jon Cruz

On Feb 12, 2010, at 5:42 PM, Omari Stephens wrote:

 On 02/12/2010 10:12 PM, Christopher Curtis wrote:
 On Fri, Feb 12, 2010 at 11:55 AM, yahvuuyah...@gmail.com  wrote:
 
 here are some diagrams depicting selected configurations for 
 colormanagement:
 http://yahvuu.files.wordpress.com/2009/08/dataflow.png
 
 What happens in a multi-head setup when I maximize an image over (say)
 a CRT and an LCD?  Does monitor profile take this into account?
 
 I think my question is: Is X handling the colorspace or are profiles
 being applied on individual pixel regions?  Is this even supported or
 is there something else I'm not understanding at a very basic level?
 
 This is an uncommon usecase that would require too much effort to 
 support properly for the small amount of benefit.
 
 X11 has an atom which stores one ICC display profile per screen.  We 
 would have to change the display transform depending on which screen 
 each pixel shows up on.  This would also mean that we'd have to deal 
 with the case where an image tile is split across two screens.
 
 Again, this would be a lot of code (and, thus, the potential for a lot 
 of bugs).  It would be infrequently used (and so the bugs would tend to 
 not be found as quickly).  And it would likely slow down our common code 
 paths for little benefit.

However, the answer to the base question is Yes, X and Gtk support that to a 
very good degree, and all the low-level API's support delivering all the 
required information.

and No, X does nothing with the colorspaces. It is left to the application to 
implement

It also is more of a per-monitor issue, rather than per-pixel. So one generally 
will have to deal with a small set of rectangles (two being the most common) to 
adjust. So it's not *quite* up to the complexity of a purely per-pixel problem.

I also would question the assertion that it is an uncommon use case. Those most 
likely to be working seriously with images are generally much likely to have 
two (or more) monitors. They also have a higher chance of caring about color 
fidelity. And given the direction GIMP is taking in regards to dropping support 
for the casual users (or whichever wording best describes the current directive 
on this) I would expect this to be even more in line with GIMP's targeted user 
base and use cases.

Of course, I've not delved down into the details of GIMP's display code and 
where to best hook in such display transformations. On the other hand, when I 
added the initial XICC X11 profile support to Inkscape I had researched this a 
fair bit, and for Inkscape's display code the extra needed for multi-monitor 
support is actually rather trivial.

Then again the main consideration does need to go to the pragmatic factors. 
Given the constraints of that situation (including being the sole engineer 
doing any and all color work), per-monitor simultaneous profile support was 
deferred. However, switching profiles as the window moved mainly from one 
monitor to the next went in, along with dynamic detection and reloading of the 
profile as they get set or cleared on the current monitor also went in quite 
easily.

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


Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-09 Thread Martin Nordholts
On 02/08/2010 07:07 PM, yahvuu wrote:
 From the User Scenarios [1], i'd like to pick Creating Original Art,
 short name: create a collage. This seems to be the clearest case,
 and perhaps the others can be modelled after this one.

 Compositing several images into one image requires that all parts
 have the same color space. The work is saved as XCF.

 Interestingly, from this follows that the working color space is not
 a preference item, but a property of the image (XCF). Instead,
 the _default_ image's color space is a preference item. The color
 space should be set by choosing a template or from the Image-Mode menu.


 For collage work, 'open as layers' can safely auto-convert to working color 
 space:
 if a to-be-imported image requires manual color space adjustment,
 it can be opened as an image on its own, be converted and then just be
 dragged to the collage. So dragging layers between images should
 silently auto-convert, too.

This problem was observed in the excellent GIMP 2.6 review by Ars Technica:

GIMP is nearly flawless in its color handling, but there is one 
problem. It forgets to convert copy and pasted image content.

http://arstechnica.com/features/2009/01/gimp-2-6-review.ars/2

 Somewhat related, why is 'color management' available as a display filter?
 The name suggests it's a filter between image and monitor, so at most
 the monitor profile(s) may be chosen here.

As far as I know this is just an implementation detail leaking out in 
the UI: color managaing the viewing of an image is handled internally 
through a display filter.

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


Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-17 Thread Sven Neumann
Hi,

On Wed, 2007-01-17 at 09:45 -0500, Christopher Curtis wrote:

 Something to consider, I think, is momentum.  I think that people want
 to be part of a vibrant developer community.  If a project does not
 have this, it may be beneficial to create an artificial one by
 increasing the number of releases.  To this end, it may be wise to
 make future releases more bite-sized:  2.6 implements CMS workflow
 and fixes 2.4 problems.  2.8 introduces Cairo rendering.  And then 3.0
 can integrate GEGL.

That's what we are targeting for with 2.6. It will be a short
development cycle with only very few changes. But there are people
waiting to be able to commit GEGL code into the GIMP tree. So we will
definitely not wait with that. The transition to GEGL will take a while
anyway and the user won't notice in the beginning anyway.

 Now, I'm not trying to be so bold as to propose a schedule, but it
 seems that if there were three or four releases this year - 2.4 now,
 then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per
 release.  Asking people to wait for the next release to include your
 plugin doesn't sound so severe then.  The biggest burden I think
 would fall to the translators, which is something that developers just
 need to be sensitive to.

Four releases per year is impractical. We wouldn't get anything done
because we would be busy preparing releases all the time. Even the two
releases per year schedule that GNOME is running is considered to be too
short by most developers.

And we can't release 2.4 now. It may even take another four months
before we are there. Have a look at the bug reports on milestone 2.4. A
few of them can be postponed but there are still some major ones that
absolutely have to be addressed.


Sven


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


Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-16 Thread Alexandre Prokoudine
On 1/16/07, Sven Neumann wrote:

 We plan to have 2.6 out shortly after so I am currently postponing
 pretty much everything related to color management to the 2.6 release.

Is 2.6 going to be bugfix release or a first stable version using GEGL/babl?

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


Re: [Gimp-developer] color management

2007-01-16 Thread Alexandre Prokoudine
On 1/13/07, Sven Neumann wrote:

 I thought about having it in 2.4 but I think it's probably best
 distributed seperately until we find the time to integrate it properly.
 Since we are almost ready for 2.4, we should probably not add any new
 plug-ins at this point.

Makes sense.

  3. Is it planned to support OpenIcc's initiative to look for profiles
  in /usr/color/icc and ~/color/icc on Linux and standard profiles
  directories on other systems? If no, why?

 Yes, we plan to support it at some point. But it's too late to implement
 this for 2.4. Fortunately though we are planning to release 2.6 shortly
 after and that should give us the chance to add a proper ICC profile
 selection widget that can be used from the core and from plug-ins.

Is it possible to at least default to /usr/share/color/icc or
~/.color/icc on unixes in current dialog?

  5. Main question: is color management going to be enabled by default
  in 2.4? With Scribus we found out that users actually demand it (on
  all platforms) and that it is safe, if sane defaults are used.

 Not sure yet. It depends on how well it works by then and if we manage
 to find sane defaults.

You can reuse default settings in Scribus (those applicable ones) ;-)

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


Re: [Gimp-developer] color management

2007-01-16 Thread Alexander Rabtchevich
It is located at [WINDOWS]\system32\spool\drivers\color\ at least on 2000+


Sven Neumann wrote:
 Hi,
 
 On Tue, 2007-01-16 at 11:23 +0300, Alexandre Prokoudine wrote:
 
 Is it possible to at least default to /usr/share/color/icc or
 ~/.color/icc on unixes in current dialog?
 
 The profile file selection dialog isn't finished yet. But it already
 installs a shortcut to the systemwide profile folder. At least on UNIX,
 no idea if there's a similar folder on Win32.
 
 


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


Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-15 Thread Frédéric
On Tuesday 16 January 2007 03:45, Hal V. Engel wrote:

 3. The file dialog does not have a way to show hidden directories that I
 have been able to find other than typing in the path.  This is probably
 a GTK issue rather than a GIMP issue.

Just right-click on the file list and you'll see a pop-up menu showing an 
option to let you display or not hidden files.

This *is* a GTK issue ;o)

-- 
   Frédéric

   http://www.gbiloba.org


pgpLRpsylEAg8.pgp
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-15 Thread Sven Neumann
Hi,

some of these things will be fixed for 2.4. But we can't delay the
release any further and this means that color management is not going to
be fully functional and usable in 2.4. We plan to have 2.6 out shortly
after so I am currently postponing pretty much everything related to
color management to the 2.6 release.

Perhaps in the next development cycle, there will not only be people who
point out problems and request features but also someone who wants to do
the coding. Otherwise it might taken even longer before a full CM
workflow is implemented.


Sven



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


Re: [Gimp-developer] color management

2007-01-14 Thread Yoshinori Yamakawa
Hi,


The functions included in Separate+ are jointly used, so I think that
it is appropriate that those are placed in the same submenu.

I don't understand where the Separate menu should be placed.
However, I don't have the sense of incompatibility very much even if it
is in a present place.

 Only context valid profiles should be suggested (see question 4
 above).

It isn't what I should do.
Appropriate widget will be added to the GIMP's core in the future. Then
I will use it. 

 I would also merge normal and to Colour into one dialog with a
 combobox or a radiobuttons group to switch between them and a hint
 explaining the difference.

Try Separate+ (20070115).
I'm not good at English, and pardon the incompleteness of the
explanation, please.

--

Yoshinori Yamakawa
[EMAIL PROTECTED]
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2007-01-13 Thread Sven Neumann
Hi,

On Sat, 2007-01-13 at 13:35 +0300, Alexandre Prokoudine wrote:

 1. Is it planned to have separate+ as part of 2.4? There was some
 mentioning of it in gimp-developer@, but the thread came from some
 other mailing list or a private discussion, so no clues.

I thought about having it in 2.4 but I think it's probably best
distributed seperately until we find the time to integrate it properly.
Since we are almost ready for 2.4, we should probably not add any new
plug-ins at this point.

 3. Is it planned to support OpenIcc's initiative to look for profiles
 in /usr/color/icc and ~/color/icc on Linux and standard profiles
 directories on other systems? If no, why?

Yes, we plan to support it at some point. But it's too late to implement
this for 2.4. Fortunately though we are planning to release 2.6 shortly
after and that should give us the chance to add a proper ICC profile
selection widget that can be used from the core and from plug-ins.

 5. Main question: is color management going to be enabled by default
 in 2.4? With Scribus we found out that users actually demand it (on
 all platforms) and that it is safe, if sane defaults are used.

Not sure yet. It depends on how well it works by then and if we manage
to find sane defaults.


Sven


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


Re: [Gimp-developer] Color management -- softproof comments

2006-09-20 Thread Sven Neumann
Hi,

On Mon, 2006-09-18 at 21:40 +0200, Peter Karp wrote:

 I assume that RGB and CMYK space are the default spaces for new
 pictures and that it can be assigend to untagged pictures? For what is
 CMYK space used when Gimp does not support CMYK editing of files or
 have I overseen that this will be possible with Gimp 2.3/2.4?

The CMYK default colorspace is supposed to be used by the CMYK color
selector as well as by plug-ins that want to offer export to CMYK.

 2) I loaded a picture which has an embedded profile, but I found that
 the embedded profile is not honored (of course the mode colormanaged
 monitor was active).
 
 That's a 'must have' for a colormanaged image editor.

We know that. Colormanagement is still unfinished and it's not
considered to do anything useful yet. You are loooking at a rough
prototype. I hope that I can get back to hacking on color management
soon.

 3) In addition to 2) I could not find an option to assign or in the
 other case convert a file from one color space to the other. That's
 also a very important function which is possible with lcms and which
 must be present.
 
 4) From 2) and 3) will follow that one has to make a decision what to
 do when a picture profile does not match the default RGB working space
 (as long as Gimp does not support CMYK editing). Photoshop allows to
 choose
   a) no colormanagement
   b) assign profile (Combo box with installed profiles)
   c) convert to  profile (Combo box with installed profiles)

This is all planned.

Your comments are however quite useful and I would very much appreciate
if you could have a look at color management again as soon as the
implementation has come forward a little.


Sven


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


Re: [Gimp-developer] Color Management

2005-08-13 Thread Jay Cox
On Mon, 2005-08-08 at 23:31 -0700, Hal V. Engel wrote:
snip
 
   View  == Print Simulation (or SoftProof or Proof Setup?) 
 (currently is located in View == Display Filters which is
confusing)
 
   Simulation (SoftProof or Proof?) Mode on or off (radio button or
check box)
   Printer Profile (drop down use profile path to get list)
   Rendering Intent (drop down)
   Black Point comp (check box)
   Use Paper White (check box) (new - low priority)
   Use Ink Black (check box) (new - low priority)
 

Just some notes for anyone thinking about implementing some of this:


Black point compensation is not a part of the ICC specification and is
not currently available in any icc library that I know of.


Use paper white:  requires ink black to be on also.  Use an absolute
colorimetric transform.

Use ink black: I belive this option would be pretty simular to using an
absolute colorimetric transform for the shadow, and a relative
colorimetric transform for the highlight.  I know this is possible with
the argyll cms library, but I'm not sure about any others. (see the -w
option to icclink)

Neither ink black or paper white is on:  Use a relative colorimetric
transform.


IMHO: Rather than trying to duplicate adobe's black point compensation,
I think our time would be better spent exploiting argyll's device link
profiles and image specific gamut mapping capabilities. 

more info on argyll at http://www.argyllcms.com


Jay Cox
[EMAIL PROTECTED]



___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2005-08-13 Thread Alastair M. Robinson

Hi,

Jay Cox wrote:


Black point compensation is not a part of the ICC specification and is
not currently available in any icc library that I know of.


For the record: Black Point Compensation is supported by LCMS - you just 
supply a flag when building the transform...


All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2005-08-09 Thread Hal V. Engel
On Saturday 15 January 2005 05:37 pm, Sven Neumann wrote:

snip

 Let's try to implement this in small steps then. As a first step I
 would like to add a couple of options to the preferences to allow
 users to define default locations for color profiles, to
 enable/disable color management and to set a number of default
 settings. Stefan Döhla sent me a patch last year that implements this
 and I will probably base the changes on that. The settings he
 suggested are:

  - use CM or not
  - display profile
  - default workspace profile
  - default rendering intent for color conversion
+ from workspace to display (default set in display profile)
+ from workspace to printer (should default to
* perceptual for pictures
* relative colorimetric for most other work)
  - default cmyk-profile (is later used to convert RGB-CMYK)
  - default profile path (/usr/share/color/icc/ and ~/.color/icc/)

 As soon as we have such settings, we need to figure out a way to make
 them available to plug-ins and modules. We also need an API to access
 the color-profile attached to an image.


 Sven


Sorry for such a long note.  

I have been playing around with the 2.3.2 snap shot and it looks like much of 
the above is working.  It also gave me some ideas about what needs to be done 
and also how the menus for this could be structured.  

I thought that perhaps some of this is allready underway and in CVS.  So I got 
a copy of CVS and tested it.  I did not see any noticeable changes.

Things that need to be implemented:

1.  Currently embedded profiles are not used.  This needs to be implemented.  
The gimp-color-management plug-in (by Jordi Canton 
[EMAIL PROTECTED]) looks like it has the code needed to read in 
an embedded profile and could be leveraged to get this functionality.  
Highest priority of any CM work.

2. Default Profile Paths need to be implemented.  This should be user 
modifiable.  On open source systems it should be set to 
~/.color/icc:/usr/share/color/icc by default and the user should only be able 
to add additional locations to this path (not sure about the last part). On 
open source systems The GIMP installation should create these directories if 
they do not exist (? not sure about this).  On closed source systems the 
system default locations should be used.  On Windows XP this would normally 
be C:\windows\system32\spool\drivers\color.  I don't know what it is on a 
Mac.   Medium to low priority.

3. Menu items to assign profiles to images and to convert images between color 
spaces needs to be implemented.  There is already a plug-in available that 
sort of does this (gimp-color-manager).  It is on the rough side and has a 
more complex UI than is really needed and the UI confusing.  This either 
needs to be simplified and cleaned up or just used to pull out needed 
functionality for implementing a cleaner UI.  High priority.

4. Some (image acquisition) plug-ins will need a way to pass profile 
information into GIMP.  For example UFRAW (recommended) is a RAW conversion 
utility that runs both stand alone and as a  GIMP plug-in.  It is CM aware 
and it can embed user specified profiles and optionally convert images from 
that device profile to a working space profile.  In standalone mode it can 
save the image file with an embedded profile.   Currently it has no way to 
pass the profile information to GIMP when running as a plug-in.   Medium 
priority.

Here is a proposal for how the color management related menus could be 
structured.  It leverages what is allready there but tries to make the intent 
of each item clearer and easier to understand if possible.  It also implies 
certain functionality that needs to be implemented.

Global CM configuration menus located in:

File == Preferences == Color Management

  Color Management on (check box)
(global flag to turn CM on or off.  Default is off.  
If off all CM options, global or image specific, have no affect.
This is currently missing.)

  Profiles Path dialog (see #2 above)

  Display (This could also be located in File == Preferences == Display)

Try to obtain the monitor profile from the X server (check box)
Monitor profile (drop down use profile path to get list of profiles)
Rendering Intent (drop down)
Desaturate monitor colors by ??? % (new - low priority)
(This does not need the current Mode of operation drop down.
see Color Management on item above and Print Simulation 
item below.)

  Color Management Policies

Working Color Spaces 
   (These are the RGB and CMYK profiles 
 in the current GIMP preferences menu)

RGB (drop down use profile path to get list)
CMYK (drop down use profile path to get list)
Grey (drop down use profile path to get list) (new)

Profile Mismatches
On Opening  
 ask or always convert to working 

Re: [Gimp-developer] Color Management

2005-08-09 Thread Sven Neumann
Hi,

interesting how much effort is being spent lately on reiterating what
still needs to be done on color management. I think we have made a
rather detailed list of required changes for GIMP 2.4 and obviously
it's not quite there yet. I will get back to color management as soon
as the new foreground select tool is working good enough. Then, as
soon as the missing infrastructure for plug-ins and modules is added,
I could need some help with implementing the missing bits in plug-ins
and modules.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2005-08-09 Thread Francisco Bernal
I reiter my desire to work in that modules. But do not have time to play the
game of the bugs to learn the basis of the gimp programming.

/*--*/
If quality is important, sRGB is not an option
(From the European Color Initiative web page www.eci.org)

Francisco Bernal Rosso

Luz-color-fotografia
Redacción y traducción

Webpage at:
http://pacorosso.blogspot.com
http://www.geocities.com/pacorosso
http://www.fotoforum.net/socios/b/b_f/fotos.htm
http://www.michelle7.com/contributors/r/paco_rosso.htm


 Hi,

 interesting how much effort is being spent lately on reiterating what
 still needs to be done on color management. I think we have made a
 rather detailed list of required changes for GIMP 2.4 and obviously
 it's not quite there yet. I will get back to color management as soon
 as the new foreground select tool is working good enough. Then, as
 soon as the missing infrastructure for plug-ins and modules is added,
 I could need some help with implementing the missing bits in plug-ins
 and modules.


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management was GEGL development/gimp integration

2005-01-15 Thread Gerhard Gaußling
Am Samstag 15 Januar 2005 23:42 schrieb Gerhard Gaußling:
 Photoshop lets pop up a dialog where the user can decide the kind of
 conversion he will do for the pasted/dragged image

Of course only if the source color space of the imported 
(pasted/dragged) image is different from the working color space. As I 
mentioned before the working color space is also meant as 'device 
independent' like recommended by eci.org, and there for suitable for 
archives. (The recommendations might be different for the US and other 
non-european states: there it might be recommend to use AdobeRGB as 
wotrking color space - and WebCoatedSWOPv2v as printing profile ).

If the archived files are saved in (the recommended wide working color 
space such as eciRGB or AdobeRGB, or WideGammut) the appropriate color 
space, then it can be imported without flaws (w.o. popup window with 
the selection dialog) into theGIMP.
 
regards

Gerhard

 
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management was GEGL development/gimp integration

2005-01-04 Thread Sven Neumann
Hi,

Hal V. Engel [EMAIL PROTECTED] writes:

 I didn't think we were talking about user interface issues.  Rather
 this is about how the image data is handled while it is being
 manipulated by the GIMP.  Specifically should there be a color space
 transformation as part of loading the image and another when the
 image is saved.

Well, at this point we are rather talking about preparing the
framework that we will need to implement color management. How exactly
this is all wired up and presented to the user remains to be seen.
Your feedback will certainly help with this.

 I think I already did but not in great detail.  My main point is that 
 the color space of the users image should ALWAYS be untouched unless 
 the user specifically asks for a transformation.  There are a number 
 of cases where the image must go through a color space transformation 
 but only a limited set of these should affect the actual image data.

If we don't convert the image at load time, all plug-ins that change
colors would have to be aware of the color-space the image is in.
Since this is not the case for the time being, it would probably be a
bad idea to not convert the image. As soon as we go further down the
road and have all plug-ins as GEGL ops, this will change. But for the
time being, I don't see much choice but to convert everything to sRGB.
Note that we are just talking about the first step here. Something
that we can achieve in the next few months, without changing each and
every piece of code in GIMP and it's plug-ins.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management was GEGL development/gimp integration

2005-01-03 Thread Hal V. Engel
On Monday 03 January 2005 14:27, Sven Neumann wrote:

snip

 
 I don't think we rejected this part. IIRC we said that it should be
 optional and that we want to allow people to disable color management
 entirely. Anyway, whatever we decide to do is just a matter of user
 interface and doesn't affect the GEGL operators involved.
 

I didn't think we were talking about user interface issues.  Rather 
this is about how the image data is handled while it is being 
manipulated by the GIMP.  Specifically should there be a color space 
transformation as part of loading the image and another when the image 
is saved. 

Yes the user should be able to turn color management off if they want.  
In fact I think that at install time it should be off by default.  
Color management is not for all users as it requires a lot of work to 
understand how it works,  to setup a good work flow and to get good 
device profiles (printers are particularly difficult).   So color 
management is really only for those that are graphics and photo 
professionals and hard core amateurs.  Anyone not prepared to do a lot 
of work to get this right should not bother with it.

snip

 Sure, that's much appreciated. Perhaps you want to suggest a better
 design then?
 

I think I already did but not in great detail.  My main point is that 
the color space of the users image should ALWAYS be untouched unless 
the user specifically asks for a transformation.  There are a number 
of cases where the image must go through a color space transformation 
but only a limited set of these should affect the actual image data.

1. When the image is acquired.   The image may either remain in the 
device color space or be transformed to the users preferred working 
color space.  Either way that then becomes the image color space.   

As an example a scanned image might initially be tagged with the color 
space profile of the scanning device by the scanning software and then 
optionally converted to the users working color space either in the 
scanning software or the image software.  In Photoshop the user can 
setup Photoshop to do several different things when am image is opened 
and the embedded profile is not the same as the default (user 
selected) working profile.

a. If no profile is embedded in the image ask the user if one should be 
and allow the user to select the profile.  So if your scanning 
software was not color aware (like sane) you could embed the correct 
device profile here and then optionally convert the image to the (user 
selected) working color space.

b. Do nothing and use the embedded profile.

c. Ask the user if they want the image converted to the default (user 
selected) working color space.

d. Automatically convert all images to the default (user selected) 
working color space.  In this case the transformation is automatic but 
the user has specifically requested that this happen.

High end scanning software like VueScan Pro and SilverFast AI can also 
be configured to support conversion from the device color space to a 
user specified working color space.  This software scans the image 
then converts it to the working profile using the device profile as 
the starting point for the conversion.  As a side note Vuescan Pro is 
available for Linux for $79 and supports all scanner supported by 
sane.

This is one of the few cases where it is normal for an image to have a 
color space transformation that affects the actual image data.

2. Before sending the image to a printer the image will be optionally 
converted from the image color space to a user selected printer color 
space.  But this is only done to a copy of the image as it is being 
sent to the printer.  

This could also happen in the print driver.  I would personally prefer 
that the print driver handle this as this would allow for the printer 
to be color managed from all software not just color aware software.  

In Photoshop the user selects File == Print with preview.  In the 
dialog the user can select how the color transformation will happen by 
selecting both the from and to color profiles and the conversion 
intent (same as image(AdobeRGB1998) to Epson1280-1440 intent is 
perceptual with black point compensation - would be typical settings).

3. When the image is sent to the display device it will be converted 
from the image color space to the display color space.  Again like 
images going to a printer (#2 above) this will be done to a copy of 
the data not to the original image.

4. The user can at any time pull up a menu and force a color space 
conversion to an image. I have never used this functionality in 
Photoshop.  Others may have work flows that require this functionality 
such as those that work on images for customers that require that the 
final images be in a specific color space. 

Color work flows will vary depending on what the user is trying to do.  
But once someone has a good color work flow they will stick to it in 
every detail.  My experience 

Re: [Gimp-developer] Color Management

2004-08-20 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] [EMAIL PROTECTED] writes:

 The display filter for gamma is nice, but 
 it should be accompanied by some linear 
 adjustment of brightness and contrast.
 (That contrast filter that's there just
 doesn't do the trick!)

That contrast filter is not meant to be used for adjusting contrast.
It is meant to be used to visualize very subtle color changes that are
otherwise invisible.

Writing a display filter for brightness/contrast adjustment would be
trivial. Why don't you just do it?


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2004-08-19 Thread [EMAIL PROTECTED]

The display filter for gamma is nice, but 
it should be accompanied by some linear 
adjustment of brightness and contrast.
(That contrast filter that's there just
doesn't do the trick!)

I looked into using ICC profiles, but that 
would be too difficult to adjust easily.
Perhaps a mechanism for saving a set of 
display filters into a display profile 
could be adopted.

(note how dark and ugly stuff looks on a
CRT that looked fine when developed on an LCD
without a display filter to compensate - so 
this is a great way to help compensate for 
that problem)



The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2004-08-15 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] [EMAIL PROTECTED] writes:

 What's the easy way to get an ICC color profile?
 I'd like to look at an image on my display and 
 on the wall simultaneously and tweak the profile
 until the display matches the wall.  But I don't
 see any kind of GUI to accomplish this.  Do I have
 to create the profile by entering some numbers with 
 a text editor? or am I missing something here?

You will need software that allows to create ICC profiles.
Please use google to find such software.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2004-08-14 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] [EMAIL PROTECTED] writes:

 I use GIMP to touch up photos before projecting
 them on a wall.  The washed out effect of a projector
 might be nice to see while editing the image on 
 a different device.  (i.e. use a filter to preview
 approximately what it would look like being viewed 
 with a different device).  
 
 Maybe this is a different feature, but it seems
 like some kind of display filter would be helpful
 in this scenario.

You should be able to achieve this using the proof display filter.
All you need is an ICC color profile that simulates the projector.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Management

2004-08-14 Thread [EMAIL PROTECTED]

] I use GIMP to touch up photos before projecting
] them on a wall.  The washed out effect of a projector
] might be nice to see while editing the image on 
] a different device.  (i.e. use a filter to preview
] approximately what it would look like being viewed 
] with a different device).  
] 
] Maybe this is a different feature, but it seems
] like some kind of display filter would be helpful
] in this scenario.
]
]You should be able to achieve this using the proof display filter.
]All you need is an ICC color profile that simulates the projector.
]
]
]Sven

What's the easy way to get an ICC color profile?
I'd like to look at an image on my display and 
on the wall simultaneously and tweak the profile
until the display matches the wall.  But I don't
see any kind of GUI to accomplish this.  Do I have
to create the profile by entering some numbers with 
a text editor? or am I missing something here?



The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-29 Thread David Neary
Hi,

Sven Neumann wrote:
 Alastair M. Robinson [EMAIL PROTECTED] writes:
 
  Finally, a question:  How is a plugin supposed to go about storing
  persistent data between sessions (i.e. in my case, the filenames of
  the profiles last used)?
 
 The plug-in can attach a persistent parasite to gimp.

Are parasites ever saved across sessions? I didn't think they
were.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-29 Thread Sven Neumann
Hi,

David Neary [EMAIL PROTECTED] writes:

   Finally, a question:  How is a plugin supposed to go about storing
   persistent data between sessions (i.e. in my case, the filenames of
   the profiles last used)?
  
  The plug-in can attach a persistent parasite to gimp.
 
 Are parasites ever saved across sessions? I didn't think they
 were.

Persistent parasites are saved of course. Otherwise they wouldn't be
persistent.

This also implies that the plug-in authors should be careful with
persistent parasites. They would better be able to parse any parasite
they set in an earlier version (or at least detect that the format
changed and gracefully ignore it).


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Sven Neumann
Hi,

I wrote this in an earlier mail already but perhaps you didn't notice,
so here's my question again:

   I wonder if we should add the separate plug-in to the GIMP tarball
   for GIMP 2.2. Would you like to see that happening?


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread David Neary
Hi,

Sven Neumann wrote:
 I wrote this in an earlier mail already but perhaps you didn't notice,
 so here's my question again:
 
I wonder if we should add the separate plug-in to the GIMP tarball
for GIMP 2.2. Would you like to see that happening?

I would. I assumed you were asking Alastair, though.

Also, I found another color management plug-in for the GIMP
(pretty old, and I haven't looked at it in depth yet, but it's
someone else who has looked into the issue and might save us some
work): http://www.khk.net/color/color_manager.html

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Sven Neumann
Hi,

David Neary [EMAIL PROTECTED] writes:

  I wrote this in an earlier mail already but perhaps you didn't notice,
  so here's my question again:
  
 I wonder if we should add the separate plug-in to the GIMP tarball
 for GIMP 2.2. Would you like to see that happening?
 
 I would. I assumed you were asking Alastair, though.

I do, that's why I sent my mail To: Alastair M. Robinson.
 

Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Alastair M. Robinson
Hi Sven,
Sven Neumann wrote:
I wrote this in an earlier mail already but perhaps you didn't notice,
so here's my question again:
Sorry, yes I did miss that...
 I wonder if we should add the separate plug-in to the GIMP tarball
 for GIMP 2.2. Would you like to see that happening?
I'd be delighted - though there are a few bugs I'd like to fix first!
If it's going to become semi-official, though, I guess some discussion 
is needed about various points:

1.  Where in the menus it should live.  Currently, my functions are in 
Image-Separate.  The separation is, however, performed on the current 
layer, not the whole image.  The separation functions themselves are 
really not much more than a colour-profile-aware version of the 
compose/decompose code that's there already, so maybe alongside those 
would be the best place.  Alternatively, depending on how far we get 
with colour-management in general, a new top-level Colour Management 
menu might be a better option?

2.  Should the saving function be left with the separation functions, or 
be moved into the TIFF plugin.

3.  How about adding support to the TIFF plugin for loading CMYK images 
into individual greyscale layers, thus solving the biggest limitation 
that the separate plugin currently has, i.e. not being able to load its 
own images back in.  (This would have to be an alternative option to 
converting the CMYK data to RGB using lcms, if we implement that, or 
using libtiff's own Everything-RGBA converter.)

Does anyone else want to bring up any further points?
Finally, a question:  How is a plugin supposed to go about storing 
persistent data between sessions (i.e. in my case, the filenames of the 
profiles last used)?

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Sven Neumann
Hi,

Alastair M. Robinson [EMAIL PROTECTED] writes:

 Finally, a question:  How is a plugin supposed to go about storing
 persistent data between sessions (i.e. in my case, the filenames of
 the profiles last used)?

The plug-in can attach a persistent parasite to gimp.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-24 Thread Sven Neumann
Hi,

Alastair M. Robinson [EMAIL PROTECTED] writes:

 Sure, but the plugin will depend on the implementation of the other
 stages.  The guts of the plugin, thanks to lcms, will be pretty
 trivial - far simpler than the separate plugin; the most important
 factor will be the design of its user interface, and supporting
 factors, e.g. do we support tagging images both with an actual
 profile, or with the filename of a profile, and such like.

Well, adding a few gimprc options takes a couple of minutes only and
that should be all that is needed for now.

We already support tagging images with a profile. the suggested
parasite name for this is currently icc-profile and we should try to
keep this for backward compatibility. Of course we will need to define
some more parasites. Perhaps someone could sit down and propose the
parasites we will need for color management.

 There are a couple of other issues that might warrant discussion
 with the developers of lcms; how to go about comparing profiles for
 equality for instance (we want to be able to avoid converting
 between an embedded profile and the working space if they are in
 fact the same profile!)

Does lcms provide an API for this?


Sven

PS: I wonder if we should add the separate plug-in to the GIMP tarball
for GIMP 2.2. Would you like to see that happening?
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-22 Thread William Skaggs

So at the most concrete possible level, here is a suggestion on
how to start:

Step 1: Add a Color Management page to the Preferences.

Step 2: Add enable/disable color management and working
colorspace options to the page.  To start with, sRGB will
be the only option for the latter, but the infrastructure
should not build in any assumption that this will always
be true.

Step 3: In the file-loading code, after an image has been
loaded, check for the presence of parasites called either
icc-profile or colorspace.  If one of these is found,
execute the color management plug-in.

Step 4: Write a color management plug-in.

Best,
  -- Bill



 

 
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-22 Thread Sven Neumann
Hi,

William Skaggs [EMAIL PROTECTED] writes:

 So at the most concrete possible level, here is a suggestion on
 how to start:
 
 Step 1: Add a Color Management page to the Preferences.
 
 Step 2: Add enable/disable color management and working
 colorspace options to the page.  To start with, sRGB will
 be the only option for the latter, but the infrastructure
 should not build in any assumption that this will always
 be true.
 
 Step 3: In the file-loading code, after an image has been
 loaded, check for the presence of parasites called either
 icc-profile or colorspace.  If one of these is found,
 execute the color management plug-in.
 
 Step 4: Write a color management plug-in.

Sounds good except that Step 4 should be first.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-22 Thread Alastair M. Robinson
Hi Sven,
Sven Neumann wrote:
William Skaggs [EMAIL PROTECTED] writes:

So at the most concrete possible level, here is a suggestion on
how to start:
Step 1: Add a Color Management page to the Preferences.
Step 2: Add enable/disable color management and working
colorspace options to the page.  To start with, sRGB will
be the only option for the latter, but the infrastructure
should not build in any assumption that this will always
be true.
GIMP really won't care what this working space is; as far as the core is 
concerned it's just a filename, so why limit it to sRGB even temporarily?

Step 3: In the file-loading code, after an image has been
loaded, check for the presence of parasites called either
icc-profile or colorspace.  If one of these is found,
execute the color management plug-in.
Step 4: Write a color management plug-in.
Sounds good except that Step 4 should be first.
Sure, but the plugin will depend on the implementation of the other 
stages.  The guts of the plugin, thanks to lcms, will be pretty trivial 
- far simpler than the separate plugin; the most important factor will 
be the design of its user interface, and supporting factors, e.g. do we 
support tagging images both with an actual profile, or with the filename 
of a profile, and such like.

There are a couple of other issues that might warrant discussion with 
the developers of lcms; how to go about comparing profiles for equality 
for instance (we want to be able to avoid converting between an embedded 
profile and the working space if they are in fact the same profile!)

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color management: conclusions?

2004-07-20 Thread Sven Neumann
Hi,

David Neary [EMAIL PROTECTED] writes:

 The two propositions are (or seem to be):
 
 1) Apply embedded profiles (after prompting the user whether they
 would like to do that) at load time, or attach the profile to the
 image at load time and use the raw image data, assuming that sRGB
 (or some other colourspace) is the internal colourspace all the
 time.
 
 2) Allow the user to set the internal colourspace, and warn when
 an attached colourspace does not match the current internal one,
 allowing the user to either apply the profile to convert to the
 current colourspace, set the internal colourspace to the new one,
 or not use the colour profile for the image.

I don't see how (2) could work without adding color management
throughout the application and most plug-ins. This is certainly a goal
for the time with GEGL but nothing that we should target for 2.2.

It seems to me that (1) is the best solution for now. I propose
however that we keep most of this functionality in a color-management
plug-in. Such a plug-in would offer to apply color profiles and to
change the color profile attached to an image. Combined with a color
display filter to handle the monitor profile this would keep the lcms
dependency to a few defined places and would still allow us to add
some basic color management. This should allow us to collect some
experiences in this new area. Experience that should help us to get
color management right in GEGL.
 
 I was talking to Sven on IRC, and he seemed to believe that neither
 of these would be done for 2.2, and that only the infrastructure
 which would allow these to be done easily post-2.2 (when we hope to
 have higher bitdepths internally for image data). At least, that's
 what I think he said, but I didn't really follow.

I think that we should focus on adding the API that is needed to
implement some basic but useful color management in plug-ins and
modules. Whether this means that 2.2 will include these plug-ins and
modules or if they will be developed separately (and perhaps even
after 2.2 is released) remains to be seen.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-13 Thread Stefan Klein
David,

 So say I open an image with a color profile, and then load a
 second image with a different profile. If I now decide to do the
 above, what do we do to the first image?

how about attaching a profile to each image? Correction is then done
using the individual image's profile and the application-wide monitor
profile. This gives you a lot of flexibility in the use of different
profiles and saves you from having to switch the workspace profile back
and forth.

From my own research on the matter, the way it is done in most apps and
CMS workflows seems to use three profile settings:
1. a monitor profile
2. a default image profile
3. a working space profile

The meaning of the monitor profile is obvious. The default image profile
is assigned to images that don't have an embedded profile. The working
space profile is a kind of preferred colour space, such as the in-house
space of a studio.

The workflow is then as follows:
When an image is opened, it is assigned its embedded profile, or, if
there is none, the default image profile. The assigned profile is then
compared to the workspace profile. If they are identical, nothing
happens, since the image already is in the user's working space.
Otherwise, the user is notified of the fact that the image profile
differs from the working space profile and is asked whether she would
like to convert the image to the working space or to maintain its
original profile. For ease of use there should be a preference setting
that defines a default for this dialog and allows it not to be displayed
(e.g. always convert images to working space).

Display correction is then done based on the profile that was assigned to
the image (which could be the embedded profile, the default image
profile, or, if the image was converted, the workspace profile).

Here the working space is more of a preference setting, a colourspace
that the user prefers to work in. It is not necessarily used in the
display correction (only if it is made the image's profile).

In addition there are usually functions to assign a different profile to
an image (only changes the attached profile, but doesn't manipulate the
image data) or to convert an image to a different profile (changes the
profile and the image data).


Hope this is of any use
Stef

an
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-12 Thread Øyvind Kolås
I haven't read the whole thread, but the last mail in the thread by
William Skaggs seems very similar to the ideas discussed at gimpcon,
what follows is my own understanding of what we discussed there:

assuming working space of gimp == sRGB

new image
  parasite_set (export_profile, sRGB)

loading of file profile==sRGB
  best scenario, just load the file
  parasite_set (export_profile,sRGB)

loading of file !profile
  no color profile associated with image
  convert from [sRGB (dropdown)]
  save as [sRGB (dropdown)]
  parasite_set (export_profile, users_choice)

loading of file profile!=sRGB
  image has a color profile attached
  convert from [YUV (dropdown)]
  save as [sRGB (dropdown)]
  parasite_set (export_profile, users_choice)

displaying the image while working on it
  this is actually the hardest thing to get right,. since it requires
user interaction
  and cooperation,. even with a correct icc profile for the display the user can
  introduce errors to the display by fiddling with the
brightness/contrast knobs.

saving when export_profile == sRGB
  attach profile if possible

saving when export_profile != sRGB
  this is of course dependent upon the file supporting the intended
format, if it does
  pixel data should be converted upon saving, and the correct profile attached.

/pippin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-12 Thread Sven Neumann
Hi,

Øyvind Kolås [EMAIL PROTECTED] writes:

 new image
   parasite_set (export_profile, sRGB)
 
 loading of file profile==sRGB
   best scenario, just load the file
   parasite_set (export_profile,sRGB)
 
 loading of file !profile
   no color profile associated with image
   convert from [sRGB (dropdown)]
   save as [sRGB (dropdown)]
   parasite_set (export_profile, users_choice)

This means that we would need to open a dialog for almost every image
file the user opens. Is that a good idea? Shouldn't we just assume
sRGB in that case?


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-12 Thread Øyvind Kolås
On 12 Jul 2004 21:47:21 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
  loading of file !profile
no color profile associated with image
convert from [sRGB (dropdown)]
save as [sRGB (dropdown)]
parasite_set (export_profile, users_choice)
 
 This means that we would need to open a dialog for almost every image
 file the user opens. Is that a good idea? Shouldn't we just assume
 sRGB in that case?

We should provide a checkbox in the dialog, asking that the dialog
newer be shown again, (it whould hide that part of the dialog, and a
preference would be used to toggle it back on).

/pippin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi,

Tor Lillqvist [EMAIL PROTECTED] writes:

 I don't know what the solution is. Maybe some way to (temporarily)
 associate an invokation of the colour selector with a specific image?
 An entry in the Image menu Select colour in image's colour space?

The color selector is opened from the toolbox or it is even
permanently opened in one of the user's dock windows. I don't think we
want to change that. Color management shouldn't stand in the way of
established work-flows.


Sven

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi,

Tor Lillqvist [EMAIL PROTECTED] writes:

 Assume GIMP uses Sven's original idea (i.e. Alastair's preferred
 method) where images keep their original colour space. Say a user is
 working on an image in some colour space with a much larger gamut than
 sRGB. If the colour selector allows only sRGB colours to be selected,
 the most blue colours he can select have the B value 255.  When
 converted to the image's wide-gamut colour space, the colour will have
 significantly less B value. There won't be any way to select the
 colours that are out of the colour selector's sRGB gamut.

Who said the color would be converted to the image's color-space? We
are discussing short-term solutions for color management here. GIMP
won't know anything about color-spaces. All we are discussing here is
whether it makes sense to use display filters to color-correct the
image display (and optionally color selector displays). The other
point that we are discussing is how file plug-ins should handle
embedded color profiles, i.e. whether to attach the profile to the
image or not.
 

Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Dave Neary

Hi,

Quoting Sven Neumann [EMAIL PROTECTED]:
 All we are discussing here is
 whether it makes sense to use display filters to color-correct the
 image display (and optionally color selector displays).

I don't think there is any argument about that. It does make sense to apply the
monitor's profile as the last step in the projection.

 The other
 point that we are discussing is how file plug-ins should handle
 embedded color profiles, i.e. whether to attach the profile to the
 image or not.

I may be listening to a different conversation. The other point was whether
embedded profiles should be applied at load time or be factored into the
projection. In this scheme, the core would have to be at least aware of color
profiles attached to images. It's not simply a question of attach or apply,
since one has implications for the core, and the other doesn't. So this isn't
just about the file plug-ins.

Cheers,
Dave.

-- 
Dave Neary
Lyon, France
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi,

Dave Neary [EMAIL PROTECTED] writes:

  point that we are discussing is how file plug-ins should handle
  embedded color profiles, i.e. whether to attach the profile to the
  image or not.
 
 I may be listening to a different conversation. The other point was
 whether embedded profiles should be applied at load time or be
 factored into the projection. In this scheme, the core would have to
 be at least aware of color profiles attached to images. It's not
 simply a question of attach or apply, since one has implications for
 the core, and the other doesn't. So this isn't just about the file
 plug-ins.

Well, it got to be doable in the file plug-ins since we don't want to
have the core depend on lcms. Applying the embedded profile at load
time could very well happen in the file plug-ins though. If the core
needs to perform colorspace transformations then we should postpone
this whole thing and do it properly with GEGL.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Alastair M. Robinson
Hi David,
David Neary wrote:
I'll conduct some tests some time and try and figure out just how bad 
these quantisation errors could be.
Great - quantitative data will really help.
I've done some testing - I wrote a little program that puts every 
possible 8-bit RGB colour through an lcms transform.  A frequency table 
is kept of every colour that comes out the other side, which gives us 
some idea of how many codes are lost - how badly the dynamic range is 
reduced.

First, as a control subject, I analyzed the gamma function at 1.1 and 
0.6.  The results are as follows:

Gamma 1.1
Code use tally:
00: 1707993
01: 13481272
02: 1529388
03: 0
04: 57834
05: 0
06: 0
07: 0
08: 729
09: 0
In other words, 13,481,272 colours are mapped with a 1:1 ratio, so can 
be transformed back again without loss.  1,707,993 colours are missing 
from the destination set, and just under 1,600,000 colours are arrived 
at from multiple source colours.

Gamma 0.6
Code use tally:
00: 7647887
01: 4251528
02: 3700404
03: 0
04: 1073574
05: 0
06: 0
07: 0
08: 103823
09: 0
Gamma 0.6 is considerably more destructive, only 1/4 of the codes 
maintain a 1:1 mapping.

Now for AdobeRGB - sRGB:
sRGB - AdobeRGB1988
Code use tally:
00: 8102616
01: 4172676
02: 3175714
03: 438068
04: 538838
05: 66267
06: 124002
07: 23117
08: 48831
09: 87087
AdobeRGB1988 - sRGB
Code use tally:
00: 8012181
01: 8325155
02: 156167
03: 54498
04: 10468
05: 58725
06: 15054
07: 2108
08: 2129
09: 140731
This isn't as bad as I'd feared, but still considerably worse than 
either of the gamma tests.

In both cases nearly half the codes in 8-bit RGB space are lost!
This in effect reduced 24-bit RGB to 23-bit RGB.  As I said, this isn't 
as bad as I'd feared - I was expecting to see a loss of nearly 1-bit per 
channel; in fact we lose only approximately 1-bit over the whole image.

If anyone's curious enough to want the source of my test program, just 
ask :)

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Alastair M. Robinson
Hi Sven,
Sven Neumann wrote:
Well, it got to be doable in the file plug-ins since we don't want to
have the core depend on lcms. Applying the embedded profile at load
time could very well happen in the file plug-ins though. If the core
needs to perform colorspace transformations then we should postpone
this whole thing and do it properly with GEGL.
Given the limitations we're trying to work within, I think the best 
compromise is likely to be something like this:

- GIMP uses a user-selectable working profile.
- If a user loads an image tagged with a different profile, she is 
presented with the following options:
  - Convert from the image's profile to the working profile, and accept 
the degredation that will result.
  - Change the GIMP's working profile to match this image.  This will 
leave the image data untouched.  (This should disable the display filter 
for existing images, since they are presumably using a different profile.)
  - Load the image without colour management, disabling the display 
filter for this image.
- If a use loads an image with no profile, the display filter should be 
disabled.

- A simple plugin should be available to fill in the gaps, i.e. tagging 
an image with a specific profile (for images with no profile), or 
converting an image to the current working space if it has changed.

For the majority of users, this should suffice; I suspect compositing 
images with different profiles won't be a particularly common occurrence 
- the user just needs to be made aware that colour-space transformations 
are a destructive change, and have an opportunity to avoid them.

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread David Neary
Hi Alastair,

Alastair M. Robinson wrote:
 Given the limitations we're trying to work within, I think the best 
 compromise is likely to be something like this:

snip some very good suggestions

   - Change the GIMP's working profile to match this image.  This will 
 leave the image data untouched.  (This should disable the display filter 
 for existing images, since they are presumably using a different profile.)

So say I open an image with a color profile, and then load a
second image with a different profile. If I now decide to do the
above, what do we do to the first image?

1) We stop using the profile for the first image (and if the
image window is open, this will obviously change the visual
representation of the image), but keep it attached to the image
so that we can re-save it with the image at save time

2) We stop using the profile and propose the dialog with the 4
options the next time the image is activated (basically allowing
us to change the working colorspace on demand, but this could get
annoying, I guess)

3) Something else I hadn't thought of?

 - the user just needs to be made aware that colour-space transformations 
 are a destructive change, and have an opportunity to avoid them.

That sounds sane. I'm not quite sure how it would be implemented,
but it probably involves having a color profile parasite attached
to an image, with some kind of configuration parameter for the
working colorspace and the monitor profile.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi,

David Neary [EMAIL PROTECTED] writes:

 So say I open an image with a color profile, and then load a
 second image with a different profile. If I now decide to do the
 above, what do we do to the first image?
 
 1) We stop using the profile for the first image (and if the
 image window is open, this will obviously change the visual
 representation of the image), but keep it attached to the image
 so that we can re-save it with the image at save time

That doesn't sound feasible to implement. How would the other image
get notified about this change? There isn't any notification about
parasite changes.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread David Neary
Hi,

Sven Neumann wrote:
 David Neary [EMAIL PROTECTED] writes:
  1) We stop using the profile for the first image (and if the
  image window is open, this will obviously change the visual
  representation of the image), but keep it attached to the image
  so that we can re-save it with the image at save time
 
 That doesn't sound feasible to implement. How would the other image
 get notified about this change? There isn't any notification about
 parasite changes.

Yeah - fair point. The changing colorspace has to get taken into
account next time we activate the image, then - and we're back to
option 2.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread Alastair M. Robinson
Hi Dave,
David Neary wrote:
So say I open an image with a color profile, and then load a
second image with a different profile. If I now decide to do the
above, what do we do to the first image?
1) We stop using the profile for the first image (and if the
image window is open, this will obviously change the visual
representation of the image), but keep it attached to the image
so that we can re-save it with the image at save time
I think this is the best bet - disable the colour-management filter for 
any images that don't use the current working profile.

2) We stop using the profile and propose the dialog with the 4
options the next time the image is activated (basically allowing
us to change the working colorspace on demand, but this could get
annoying, I guess)
The easiest option is to provide a simple plugin that adds a couple of 
menu entries - for example:
Image - Colour Management - Convert to working profile
and
Image - Colour Management - Use as working profile

That sounds sane. I'm not quite sure how it would be implemented,
but it probably involves having a color profile parasite attached
to an image, with some kind of configuration parameter for the
working colorspace and the monitor profile.
I'm not 100% sure, but I think the TIFF plugin already attaches embedded 
profiles as a parasite, so they're preserved when the image is saved 
again.  If so, we have a lead to follow!

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-09 Thread William Skaggs

It really isn't all that complicated.  Here is all you need to do
(this is basically what Sven outlined with a couple of extra details.)

1) Gimp uses the same color space internally for all images.  This
   could be either sRGB or a user-selected one (in which case it is
   specified by a preference).

2) Gimp permits the use of a monitor profile to color-correct the
   display.  A conversion is done between the working colorspace and
   the monitor colorspace -- the user is asked to choose the intent
   of the conversion as a preference (the normal choice would be
   perceptual, but people setting things up for printing would
   sometimes make other choices).

3) When you open an image, if it does not have any color profile info,
   it is assumed to be in Gimp's working colorspace.  If it does, then
   you are asked to choose between two options:

   a) convert it to Gimp's working colorspace.  If you choose this,
   then you are asked to choose the conversion intent.  

   b) use the RGB values from the image, without any correction.

   Whatever is done, a parasite is attached to the image describing
   it.

4) When you save an image, you have the option of converting it to a
   different colorspace and/or attaching a color profile if the file
   format supports it.


It is a bad idea to change the working colorspace based on the image.
Users need to be able to form an understanding of the relationship
between what they see on the screen and the pixel values in the image.
It will drive people nuts if 255,255,255 looks gray at one time and
white at another.  That's what will happen if the working colorspace
is flopping around all the time.

Best,
  -- Bill
 

 
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Dave Neary

Hi Alastair,

I'm no colourspace expert (far from it), but there were a couple of things which
I spotted in this which prompted questions.

Quoting Alastair M. Robinson [EMAIL PROTECTED]:
 In the first method, is what I believe is what PhotoShop uses (and what
 I think Sven proposed):  When an image is loaded, scanned or whatever,
 it is converted from its source colour space into a working colour
 space (sRGB, AdobeRGB, etc.).  Of course, the source colour-space and
 working colour-space can be the same.  The advantage of this method is
 that the working data is always normalised, so plugins and the like
 have perceptually identical results, whatever the image's native
 colour space.
 
 The workflow for an sRGB Image might be:
 
 Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save
 (convert back to AdobeRGB)

Yes, this is what was discussed at the conference, with one important
difference. We don't convert back to AdobeRGB or whatever at save time, we
simply save the working image data, with the sRGB color profile.

 Personally, I don't think this method is appropriate for the GIMP until
 such time as we  have support for 16-bit or float pixels, because if we
 convert from the source space to a working space with only 8 bits per
 sample we're going to lose some information through quantization errors.

I see your point. Perhaps there could be some kind of pre-loading where we apply
the color profile in floating-point, and quantise afterwards? Just thinking out
loud, this may be completely unfeasible.

 The second method, which I think we should use for the time being, is
 just to keep track of the source profile for each image (and have a
 user-selectable default profile - sRGB, AdobeRGB or whatever).  

snip

 The equivalent workflow would be:
 Image (tagged with AdobeRGB) - Working data (8-bit RGB, unmodified) -
 Editing - Save (AdobeRGB)

How does this fit in with display calibration? If we work on the unmodified
image data as we read it in, then on what data should the monitor's calibration
profile work during projection? Should it work on the raw RGB data, or should we
apply the input profile at projection time? Would a color profile be a per-layer
thing? 

I think these are the kinds of issues that Sven thought about before, and they
make adding color management considerably more complicated. I think that the
simplicity of applying a color profile on imput and not having to worry about it
in the rendering code outweighs the down side of any quantisation that occurs. 

 In short, though, if we use this method, we don't need to agree on what
 to call our working space, because it will simply be whatever is
 appropriate for the image being edited!

I think this is probably a very bad idea.

Cheers,
Dave.

-- 
Dave Neary
Lyon, France
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi,

Alastair M. Robinson [EMAIL PROTECTED] writes:

 There are as I understand it, two possible ways of dealing with colour
 profiles.
 
 In the first method, is what I believe is what PhotoShop uses (and what
 I think Sven proposed):  When an image is loaded, scanned or whatever,
 it is converted from its source colour space into a working colour
 space (sRGB, AdobeRGB, etc.).  Of course, the source colour-space and
 working colour-space can be the same.  The advantage of this method is
 that the working data is always normalised, so plugins and the like
 have perceptually identical results, whatever the image's native
 colour space.
 
 The workflow for an sRGB Image might be:
 
 Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save
 (convert back to AdobeRGB)
 
 Personally, I don't think this method is appropriate for the GIMP until
 such time as we  have support for 16-bit or float pixels, because if we
 convert from the source space to a working space with only 8 bits per
 sample we're going to lose some information through quantization errors.
 
 The second method, which I think we should use for the time being, is
 just to keep track of the source profile for each image (and have a
 user-selectable default profile - sRGB, AdobeRGB or whatever).  This
 source profile should be user-changable (so the user can tag a scanned
 image with the scanner's profile, for example), and just needs to be
 accessible to the proof and image-saving code.

 The equivalent workflow would be:
 Image (tagged with AdobeRGB) - Working data (8-bit RGB, unmodified) -
 Editing - Save (AdobeRGB)

This is also what I originally proposed at GIMPCon. I have then been
told that this would be the wrong thing to do and that we should
convert the image on load. Now that you backed up my original proposal
I tend to agree with you that converting the image data is not
feasible as long as we work with 8bit per channel.

 Colour-choosing is less-predictable (though no less than at
 present), since the RGB values selected are in a variable colour
 space.  Since we're unlikely to get a PanTone colour-selector any
 time soon, this shouldn't be an issue.  The ultimate solution here
 is to have a colour-profile attached to the colour-selector, and
 simply transform the selected colour to the current image's profile.
 The colour-selector's profile is probably as close as we need to get
 at the moment to a working profile.

Color-correcting the color-selectors is of course a must. We have put
the color display filter architecture into libgimpwidgets to be able
to implement this. It shouldn't be too hard and could be achieved for
GIMP 2.2.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Wed, 7 Jul 2004, Alastair M. Robinson wrote:

 Sven Neumann wrote:
 
  Well, we have only one internal color space. We just need to agree on
  what we want to call it...
 
 In the first method, is what I believe is what PhotoShop uses (and what
 I think Sven proposed):  When an image is loaded, scanned or whatever,
 it is converted from its source colour space into a working colour
 space (sRGB, AdobeRGB, etc.).  Of course, the source colour-space and
 working colour-space can be the same.  The advantage of this method is
 that the working data is always normalised, so plugins and the like
 have perceptually identical results, whatever the image's native
 colour space.
 
 The workflow for an sRGB Image might be:
 
 Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save
 (convert back to AdobeRGB)
 
 Personally, I don't think this method is appropriate for the GIMP until
 such time as we  have support for 16-bit or float pixels, because if we
 convert from the source space to a working space with only 8 bits per
 sample we're going to lose some information through quantization errors.
 

 Whatever you do, you will have to make a compromise. The question is,
what is the best compromise. I'm very far from being an expert in this
area, but I'll try to put in some thoughts.
 You are worried about quantization errors during the conversion, but if 
you do the conversion in 16 bit or more I think you will not have much 
problems. In the littlecms site I found a command line program that does 
the colorspace conversion with very high accuracy. Check 
http://www.littlecms.com/newutils.htm#icctrans (This command line program 
does compute colorspace conversion based on icc profiles. Additionally, it 
can show XYZ and Lab values of PCS, and up to 16 bits of precision (48, 64 
bits per pixel)). So, we even have example code ready for the conversion.
 The bigger problem we will have when converting colorspaces, is the
limited gamut of sRGB in comparison with the source colorspace. For
example, if we convert from CMYK to sRGB, then almost any color with CMYK
values in the range C90, M10, Y10, will have no sRGB counterpart. Would
it be feasible to switch from sRGB to something better? Maybe AdobeRGB? I 
found usefull the
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when 
comparing color spaces.
 Keep in mind though, that if we change the internal color space from sRGB
to something else there must be an option for the user to save his image
in sRGB (and maybe that should be the default on many cases). sRGB is the 
best option when someone tries to view an image in a computer monitor with 
no color profiling.
 As for the proposed conversion on save to the starting colorspace, I 
completely dissagree. I don't see any reason to introduce more errors 
coming from a less than optimal conversion.
 What I think best is: Image (Any space) - Working data in Internal 
gimp colorspace (sRGB or better something else) - Editing - Save (user 
selectable space; defaulting, at least for the xcf format, to the internal 
gimp colorspace)

 The question is: Are all these feasible for the 2.2 release? (which can
be trivially converted to: Is there anyone willing to work on that?)

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Jean-Christophe Dubacq
On Thu, Jul 08, 2004 at 05:47:56PM +0300, Steve Stavropoulos wrote:
  As for the proposed conversion on save to the starting colorspace, I 
 completely dissagree. I don't see any reason to introduce more errors 
 coming from a less than optimal conversion.
  What I think best is: Image (Any space) - Working data in Internal 
 gimp colorspace (sRGB or better something else) - Editing - Save (user 
 selectable space; defaulting, at least for the xcf format, to the internal 
 gimp colorspace)

But one could want to make operations using specific profiles. I mean,
addition is clearly not the same in CMYK or in sRGB, and marginally
different in other color spaces. I do not develop for the Gimp, I am
even partially color blind (which is why I read stuff about color spaces), 
but I think operations should be done in  the image color space. Which
means we have to keep track of an image color space.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread William Skaggs


Alastair M. Robinson wrote:
 In short, though, if we use this method, we don't need to agree on what
 to call our working space, because it will simply be whatever is
 appropriate for the image being edited! 

Dave Neary wrote:
 I think this is probably a very bad idea. 

I agree with Dave on this one.  Here is just one example of the sort
of nasty thing that can happen if different images use different color
spaces, with corresponding display filters:  You could have two 
two-layer images, A and B, such that:

(1) Layer A1 is visually identical to layer B1.
(2) Layer A2 is visually identical to layer B2.
(3) When layers 1 and 2 are composited in Add mode, the two images
look different.

This can happen because of the nonlinearity in color profiles.

It would be a real can of worms not to use the same color space
internally for all images -- losses in conversion are not an important
enough factor to overcome this.  (But there is a reasonably strong case
for allowing choice as to which color space is used internally.)

Best,
  -- Bill


 

 
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Thu, 8 Jul 2004, Jean-Christophe Dubacq wrote:

 But one could want to make operations using specific profiles. I mean,
 addition is clearly not the same in CMYK or in sRGB, and marginally
 different in other color spaces.

 Gimp uses only one internal colorspace, 8bit RGB and I don't see that
changing any time soon. So, you will never make operations in CMYK.
 The whole point with colorspaces is to have acurate colors. If you work 
in a colorspace with a wide enough gamut you are ok. That's why photoshop 
uses internally Adobe RGB 1998 independently of the images original color 
space.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi,

William Skaggs [EMAIL PROTECTED] writes:

 I agree with Dave on this one.  Here is just one example of the sort
 of nasty thing that can happen if different images use different color
 spaces, with corresponding display filters:  You could have two 
 two-layer images, A and B, such that:
 
 (1) Layer A1 is visually identical to layer B1.
 (2) Layer A2 is visually identical to layer B2.
 (3) When layers 1 and 2 are composited in Add mode, the two images
 look different.
 
 This can happen because of the nonlinearity in color profiles.

I fail to see what would be bad about this behaviour.

 It would be a real can of worms not to use the same color space
 internally for all images -- losses in conversion are not an
 important enough factor to overcome this.  (But there is a
 reasonably strong case for allowing choice as to which color space
 is used internally.)

For now we can only use the same color space internally since we are
not going to make all operations aware of color management. Beware
that we are discussing a short-term solution here with the right fix
waiting right around the corner (GEGL). So the only places that would
care about the color profile would be some save and load plug-ins and
display filters.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Sven,
Sven Neumann wrote:
This is also what I originally proposed at GIMPCon. I have then been
told that this would be the wrong thing to do and that we should
convert the image on load. Now that you backed up my original proposal
I tend to agree with you that converting the image data is not
feasible as long as we work with 8bit per channel.
Is there a transcript of these discussion available anywhere?
I'd certainly be interested to hear all the counter-arguments :)
Color-correcting the color-selectors is of course a must. We have put
the color display filter architecture into libgimpwidgets to be able
to implement this. It shouldn't be too hard and could be achieved for
GIMP 2.2.
The colour selectors are perhaps one of the trickier aspects of my 
proposal; for their RGB values to be meaningful, the transform applied 
to the colour selector would need to change to reflect the current 
image's profile.

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Dave,
Dave Neary wrote:
Yes, this is what was discussed at the conference, with one important
difference. We don't convert back to AdobeRGB or whatever at save time, we
simply save the working image data, with the sRGB color profile.
OK - I agree that converting back to the original space is in most 
situations unneccessary.

I see your point. Perhaps there could be some kind of pre-loading where we apply
the color profile in floating-point, and quantise afterwards? Just thinking out
loud, this may be completely unfeasible.
Assuming we're using lcms, the internal conversion will be applied in 
full precision - the problem is that the destination data, by necessity 
of the GIMP's current limitations, must be 8-bit RGB.  Converting 8-bit 
RGB data from one profile to another will not be a 1:1 mapping, so some 
colour information will be lost - I haven't yet conducted empirical 
tests for the severity of this effect, but I suspect that the 8-bit 
source data will be downgraded to something like 7 - 7.25 bit.  For me, 
seeing as 8-bit RGB is already inadequate for smooth subtle gradients 
(cf. my gradient dither patch of a few months back) this is 
unacceptable.  I concede, however, that not everybody will see it this way!

How does this fit in with display calibration? If we work on the unmodified
image data as we read it in, then on what data should the monitor's calibration
profile work during projection? Should it work on the raw RGB data, or should we
apply the input profile at projection time? Would a color profile be a per-layer
thing? 
First of all, a profile on its own is worthless for rendering accurate 
colour - they must be used in pairs, source and destination, to create a 
colour transform.  Thus, if the GIMP is using sRGB internally, then at 
projection time you feed the RGB image data through an sRGB-Monitor 
Profile transformation.  If instead you're using the unmodified RGB data 
from the original file, you just use an Image Profile - Monitor Profile 
transform instead.  (If the source image has no profile of it's own, 
then you can just tag it with a default profile.)

In short, projection your way looks like this:
Image (Source Profile) - Internal data (sRGB) - Screen (Monitor Profile)
Two transformations, first from Source Profile to sRGB, secondly from 
sRGB to the Monitor's profile.  This would work very nicely if the 
internal data could be stored in 16-bit or float precision.  Because it 
can't we lose precision.

My way looks like this:
Image (Source Profile) - Internal data (Source Profile) - Screen 
(Monitor Profile)
Just one transformation directly from the source profle to the screen 
profile, and more importantly, no destructive change to the raw image data.

I don't think it would be feasible to make the profile a per-layer 
thing.  I personally consider per-image to be the best solution, as long 
as there's some way of warning the user if they're copying and pasting 
between images with mismatched profiles.

I think these are the kinds of issues that Sven thought about before, and they
make adding color management considerably more complicated. I think that the
simplicity of applying a color profile on imput and not having to worry about it
in the rendering code outweighs the down side of any quantisation that occurs. 
I'll conduct some tests some time and try and figure out just how bad 
these quantisation errors could be.  I can certainly see the appeal of a 
simplistic approach, but if a little extra effort can prevent 
unnecessary destructive changes to the image data, I think it's worth 
exploring.

I think this is probably a very bad idea.
Could you expand on why you think this?  Confusion?  Difficulty of 
implementation?  Something else?

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Steve,
Steve Stavropoulos wrote:
 Whatever you do, you will have to make a compromise. The question is,
There we are in full agreement :)
 You are worried about quantization errors during the conversion, but if 
you do the conversion in 16 bit or more I think you will not have much 
problems. In the littlecms site I found a command line program that does 
the colorspace conversion with very high accuracy. Check 
I'm not worried about the conversion so much as the fact that the
limited precision of the destination data (8-bit RGB) will cause us to
lose colour information.  A conversion of 8-bit data between two RGB
profiles will not be a 1:1 mapping, so the converted data will not use
the full dynamic range that 8-bit RGB can provide.  Since the dynamic
range of 8-bit RGB is already severly limited, I consider impairing it
further to be unacceptable.
 The bigger problem we will have when converting colorspaces, is the
limited gamut of sRGB in comparison with the source colorspace. For
example, if we convert from CMYK to sRGB, then almost any color with CMYK
values in the range C90, M10, Y10, will have no sRGB counterpart. Would
it be feasible to switch from sRGB to something better? Maybe AdobeRGB? I 
found usefull the
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when 
comparing color spaces.
If the GIMP is going to hand off the colour-matching work to littlecms,
then using a different profile is as trivial as providing the filename
of AdobeRGB instead of sRGB!
 Keep in mind though, that if we change the internal color space from sRGB
to something else there must be an option for the user to save his image
in sRGB (and maybe that should be the default on many cases). sRGB is the 
best option when someone tries to view an image in a computer monitor with 
no color profiling.
Absolutely - though under my proposal, if an sRGB image is loaded, then
for that image sRGB *is* the working space.
 As for the proposed conversion on save to the starting colorspace, I 
completely dissagree. I don't see any reason to introduce more errors 
coming from a less than optimal conversion.
Agreed.  Subconsciously, I suppose I'd considered it good manners to
save a modified image in the same colour space it started in, but you're
right, this is not necessary.
All the best
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi William,
William Skaggs wrote:
(1) Layer A1 is visually identical to layer B1.
(2) Layer A2 is visually identical to layer B2.
(3) When layers 1 and 2 are composited in Add mode, the two images
look different.

This can happen because of the nonlinearity in color profiles.
I can see that this would happen; I don't, however, consider that to be 
a major problem, because you'd be able to see with more accuracy than at 
present what the result would be!

It would be a real can of worms not to use the same color space
internally for all images -- losses in conversion are not an important
enough factor to overcome this.  (But there is a reasonably strong case
for allowing choice as to which color space is used internally.)
I beg to differ!
A silently applied destructive change to the image data is in my opinion 
a very important factor!

All the best,
--
Alastair M. Roobinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread William Skaggs

Alastair M. Robinson writes:

 I beg to differ!

 A silently applied destructive change to the image data is in my 
 opinion a very important factor! 

It should definitely not be silently applied.  When you open an image
that uses a different colorspace from the standard one, you should
get a dialog that asks whether you want to (1) convert to Gimp's
working space, or (2) use the RGB values without conversion.  If
you convert, then you should be asked to choose a conversion intent.
Nothing should happen without the user's knowledge.

For users who don't want to deal with these things, it may be useful
to have a preference which, if enabled, turns off colorspace conversions
and all queries related to them.

Best,
  -- Bill
 

 
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread David Neary
Hi Alastair,

Alastair M. Robinson wrote:
 Dave Neary wrote:
 Assuming we're using lcms, the internal conversion will be applied in 
 full precision - the problem is that the destination data, by necessity 
 of the GIMP's current limitations, must be 8-bit RGB.  Converting 8-bit 
 RGB data from one profile to another will not be a 1:1 mapping, so some 
 colour information will be lost - I haven't yet conducted empirical 
 tests for the severity of this effect, but I suspect that the 8-bit 
 source data will be downgraded to something like 7 - 7.25 bit.

I may be misunderstanding things, but if the conversion from the
source colourspace to sRGB is done in lcms losslessly, then all
we're losing is the out-of-gamut colours from the colourspace
conversion. And, of course, the cost of discarding precision in
the data we get after the application of the profile. But I think
we still get the full 8 bits of data (they may not have the exact
colours in the source file, though).

 First of all, a profile on its own is worthless for rendering accurate 
 colour - they must be used in pairs, source and destination, to create a 
 colour transform.  Thus, if the GIMP is using sRGB internally, then at 
 projection time you feed the RGB image data through an sRGB-Monitor 
 Profile transformation.

Yes, but since this profile is applied once, on the projection
drawable, as the final step, its application doesn't present any
problems. But I see what you mean - we can go from the source
colourspace directly to the monitor's with one transformation.
This, however, poses problems for say the checkerboard pattern
(which will be transformed differently with different source
profiles), and for any occasion where different profiles get
mixed (cut  paste operations, for example).

I would have thought you would still have to have the 2 profiles
applied though... I'm sure I just don't know how lcms works.

 I'll conduct some tests some time and try and figure out just how bad 
 these quantisation errors could be.

Great - quantitative data will really help.

 I can certainly see the appeal of a 
 simplistic approach, but if a little extra effort can prevent 
 unnecessary destructive changes to the image data, I think it's worth 
 exploring.

Sure. 

 I think this is probably a very bad idea.
 
 Could you expand on why you think this?  Confusion?  Difficulty of 
 implementation?  Something else?

The this was referring to a passage that you cut - I think it
is probably a bad idea to have lots of image data in different
colorspaces. I can't put my finger on why, but I just have this
feeling that we will end up with a certain amount of confusion
when it comes to colour stuff (as you pointed out, the colour
picker is a good example, so is cut  paste).

I'm more than willing to defer to the many experts we have,
though. I wish I knew enough about the subject to consider myself
one.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi,
David Neary wrote:
I may be misunderstanding things, but if the conversion from the
source colourspace to sRGB is done in lcms losslessly, then all
we're losing is the out-of-gamut colours from the colourspace
conversion. And, of course, the cost of discarding precision in
the data we get after the application of the profile. But I think
we still get the full 8 bits of data (they may not have the exact
colours in the source file, though).
As a (somewhat extreme) analogy, imagine applying a lightening gamma 
curve to an 8-bit data set (0,1,2,3,4.253,254,255) you'd end up with 
not all codes being used at the dark end and codes being used multiple 
times at the light end - something like (0,2,4,6,7  
254,254,255,255).  I.e. there are missing codes at the dark end, and 
reused codes at the light end, due to the limited dynamic range of the 
destination space.  The problem I'm talking about will be something 
vaguely similar; there will likely be missing and reused codes in the 
working space.

Yes, but since this profile is applied once, on the projection
drawable, as the final step, its application doesn't present any
problems. But I see what you mean - we can go from the source
I wasn't suggesting this was a problem, merely trying to explain that 
profiles are only meaningful when used in pairs.  People talk about 
applying a profile to an image; usually what they mean is applying a 
transformation between profiles to an image.  It's an important distinction.

colourspace directly to the monitor's with one transformation.
This, however, poses problems for say the checkerboard pattern
(which will be transformed differently with different source
profiles), and for any occasion where different profiles get
mixed (cut  paste operations, for example).
It will indeed - I had already mentioned the cut-and-paste case as a 
possible pitfall.  I hadn't considered the checkerboard pattern, but I'm 
not totally convinced that this is a critical problem!

I would have thought you would still have to have the 2 profiles
applied though... I'm sure I just don't know how lcms works.
Yes, you need 2 profiles - the key is that you don't use profiles 
directly, you use transformations built from a pair of profiles.

The proposed method of using a standard working space involves three 
profiles (and hence two transformations linking them) - the image's own 
profile, the internal working space profile and the monitor profile.

The this was referring to a passage that you cut - I think it
is probably a bad idea to have lots of image data in different
colorspaces. I can't put my finger on why, but I just have this
feeling that we will end up with a certain amount of confusion
when it comes to colour stuff (as you pointed out, the colour
picker is a good example, so is cut  paste).
I can certainly understand your gut feeling, and agree to a certain 
extent.  The thought of destructive modification to the source data in 
just loading it makes me marginally queasier though!

I agree that copy-and-paste is a major potential pitfall, and will 
require at least a warning on mismatched profiles, and at best an option 
to convert as part of the paste operation.

I'm more than willing to defer to the many experts we have,
though. I wish I knew enough about the subject to consider myself
one.
I'm no expert either (expert: n. from X, meaning unknown, and Spurt, 
meaning a drip under pressure!), but I have used colour profiles outside 
of the usual PhotoShop setting, and am just anxious that any colour 
management abilities the GIMP should sprout will be usuable for 
pre-press work in my job!

All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi,

Alastair M. Robinson [EMAIL PROTECTED] writes:

 The colour selectors are perhaps one of the trickier aspects of my
 proposal; for their RGB values to be meaningful, the transform applied
 to the colour selector would need to change to reflect the current
 image's profile.

I am afraid that this is not possible simply because the color
selector is not associated with an image. All we can do is to correct
the color selector using the monitor profile.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Thu, 8 Jul 2004, Alastair M. Robinson wrote:

 I'm not worried about the conversion so much as the fact that the
 limited precision of the destination data (8-bit RGB) will cause us to
 lose colour information.  A conversion of 8-bit data between two RGB
 profiles will not be a 1:1 mapping, so the converted data will not use
 the full dynamic range that 8-bit RGB can provide.

 That's exactly why we need the internal 8bit RGB colorspace used by gimp
to be the widest possible. If the internal colorspace is wide enough then 
you won't notice any lost colors during the conversion. I don't know how 
much or how little these looses are, but photoshop works internally with 
adobe rgb 98 and no one complains about that. It seems that for practical 
use even the conversions to and from CMYK will be ok.
 The specifications of color spaces and the gamut projections on 
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think 
will be of great help.


  Since the dynamic
 range of 8-bit RGB is already severly limited, I consider impairing it
 further to be unacceptable.
 

 I don't think that we will have much lost gamut if we work in a 
wide-gamut internal color space. But again, I'm not an expert...

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Steve,
Steve Stavropoulos wrote:
 That's exactly why we need the internal 8bit RGB colorspace used by gimp
to be the widest possible. If the internal colorspace is wide enough then 
you won't notice any lost colors during the conversion. I don't know how 
I'm not actually talking about gamut clipping, I'm talking about an 
effective loss of colour depth through quantization errors.  I'm about 
to run some experiments, so I can hopefully provide some concrete 
illustrations, or eat humble pie, as may be appropriate!

much or how little these looses are, but photoshop works internally with 
adobe rgb 98 and no one complains about that. It seems that for practical 
use even the conversions to and from CMYK will be ok.
Photoshop can get avoid this issue by using 16-bit / float values to 
hold internal data.  We can't (yet).

 The specifications of color spaces and the gamut projections on 
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think 
will be of great help.
Yes indeed, I'll digest that information in due course...
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-08 Thread Tor Lillqvist
  I am afraid that this is not possible simply because the color
  selector is not associated with an image. All we can do is to correct
  the color selector using the monitor profile.

You mean that the colour selector would implicitly always be sRGB? I'm
afraid that's not a good idea.

Assume GIMP uses Sven's original idea (i.e. Alastair's preferred
method) where images keep their original colour space. Say a user is
working on an image in some colour space with a much larger gamut than
sRGB. If the colour selector allows only sRGB colours to be selected,
the most blue colours he can select have the B value 255.  When
converted to the image's wide-gamut colour space, the colour will have
significantly less B value. There won't be any way to select the
colours that are out of the colour selector's sRGB gamut.

I don't know what the solution is. Maybe some way to (temporarily)
associate an invokation of the colour selector with a specific image?
An entry in the Image menu Select colour in image's colour space?
What does Potatoshop do?

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-07 Thread Alastair M. Robinson
Hi,
(Second try, this time sent to the list at large.  Brains where art thou!)
Sven Neumann wrote:
Well, we have only one internal color space. We just need to agree on
what we want to call it...
My two-penneth (as author of the separate plugin, and a day-to-day user
of the GIMP in a pre-press environment):
There are as I understand it, two possible ways of dealing with colour
profiles.
In the first method, is what I believe is what PhotoShop uses (and what
I think Sven proposed):  When an image is loaded, scanned or whatever,
it is converted from its source colour space into a working colour
space (sRGB, AdobeRGB, etc.).  Of course, the source colour-space and
working colour-space can be the same.  The advantage of this method is
that the working data is always normalised, so plugins and the like
have perceptually identical results, whatever the image's native
colour space.
The workflow for an sRGB Image might be:
Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save
(convert back to AdobeRGB)
Personally, I don't think this method is appropriate for the GIMP until
such time as we  have support for 16-bit or float pixels, because if we
convert from the source space to a working space with only 8 bits per
sample we're going to lose some information through quantization errors.
The second method, which I think we should use for the time being, is
just to keep track of the source profile for each image (and have a
user-selectable default profile - sRGB, AdobeRGB or whatever).  This
source profile should be user-changable (so the user can tag a scanned
image with the scanner's profile, for example), and just needs to be
accessible to the proof and image-saving code.
The equivalent workflow would be:
Image (tagged with AdobeRGB) - Working data (8-bit RGB, unmodified) -
Editing - Save (AdobeRGB)
The advantage is that the image data doesn't have to be transformed
between profiles (so we need the facility to do this manually, should
the user need it), but there are some disadvantages:
The effects of some plugins will look different depending on the image's
colour space.  (GFlare's flares, for example, will look slightly
different applied to an sRGB image compared with an AdobeRGB image...).
Colour-choosing is less-predictable (though no less than at present),
since the RGB values selected are in a variable colour space.  Since
we're unlikely to get a PanTone colour-selector any time soon, this
shouldn't be an issue.  The ultimate solution here is to have a
colour-profile attached to the colour-selector, and simply transform the
selected colour to the current image's profile.  The colour-selector's
profile is probably as close as we need to get at the moment to a
working profile.
You would have to convert between colour spaces when copying and pasting
between images with different profiles.  (Ideally a warning with yes/no
buttons.  I personally wouldn't want this done silently, because again
it would introduce quantization errors with 8-bit data).
In short, though, if we use this method, we don't need to agree on what
to call our working space, because it will simply be whatever is
appropriate for the image being edited!
Hope this little essay is some help!
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-06 Thread Sven Neumann
Hi,

Tor Lillqvist [EMAIL PROTECTED] writes:

 Er, what's linear about sRGB? It's gamma encoded (and that's a good
 thing). Doesn't the term linear in the context of colour spaces mean
 one with components that are linear in intensity, i.e. a linear
 transformation of the CIEXYZ colour space, which sRGB isn't. Or am I
 confused?

It's probably me who's confused. I think I picked up that term at
GIMPCon and probably misunderstood it or ripped it out of context.

 I don't know, maybe we should also allow other (more wider gamut)
 internal working colour spaces than sRGB?

Well, we have only one internal color space. We just need to agree on
what we want to call it...


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer