sRGB color support in NS port

sRGB color support in NS port

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

Some time ago Steve Purcell reported an issue with hex colour rendering on OS X (http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html). While nothing was changed in Emacs, many OS X users apply a patch similar to this one https://gist.github.com/purcell/3858136 (an older version of the patch is used by homebrew) to get the desired behaviour. I wonder if we cannot finally include the aforementioned patch or conditionnaly allow the use sRGB colour via a build option (like —with-srgb).

--  
Cheers,
Bozhidar


[-- Attachment #2: Type: text/html, Size: 808 bytes --]

Re: sRGB color support in NS port

[Steve Purcell]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On 20 Dec 2013, at 17:41, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> Some time ago Steve Purcell reported an issue with hex colour rendering on OS X (http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html). While nothing was changed in Emacs, many OS X users apply a patch similar to this one https://gist.github.com/purcell/3858136 (an older version of the patch is used by homebrew) to get the desired behaviour. I wonder if we cannot finally include the aforementioned patch or conditionnaly allow the use sRGB colour via a build option (like —with-srgb).


That would be great, and I’d be happy to do whatever is necessary to help this become a reality, e.g. contributor agreements etc.

I’ve just updated the gist to reflect the latest cleanly-applying version of the patch.

The current defaults on OS X make little sense IMO, and result in inaccurate colours for pretty much everyone AFAICT.

My understanding is that everyone who cares about colour accuracy on OS X builds his Emacs with an sRGB patch of some sort. As for making this a build option, I don’t even think the non-sRGB colours should be an option on OS X, though I can’t speak for the whole NS platform.

-Steve

[-- Attachment #2: Type: text/html, Size: 1901 bytes --]

Re: sRGB color support in NS port

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Hello.

20 dec 2013 kl. 18:41 skrev Bozhidar Batsov <bozhidar@batsov.com>:

> Some time ago Steve Purcell reported an issue with hex colour rendering on OS X (http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html). While nothing was changed in Emacs, many OS X users apply a patch similar to this one https://gist.github.com/purcell/3858136 (an older version of the patch is used by homebrew) to get the desired behaviour. I wonder if we cannot finally include the aforementioned patch or conditionnaly allow the use sRGB colour via a build option (like —with-srgb).

There was no real argument for a change in that thread, except do the same as web browsers, which is dubious.  That has not changed AFAIK.

There is a compability concern, GNUStep runs on X11.  So both those should display the same color.  I don't know if they do now, but it could be an argument for a change.

	Jan D.



[-- Attachment #2: Type: text/html, Size: 1646 bytes --]

Re: sRGB color support in NS port

[Eli Zaretskii]

> From: Steve Purcell <steve@sanityinc.com>
> Date: Fri, 20 Dec 2013 18:04:46 +0000
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> On 20 Dec 2013, at 17:41, Bozhidar Batsov <bozhidar@batsov.com> wrote:
> 
> > Some time ago Steve Purcell reported an issue with hex colour rendering on OS X (http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html). While nothing was changed in Emacs, many OS X users apply a patch similar to this one https://gist.github.com/purcell/3858136 (an older version of the patch is used by homebrew) to get the desired behaviour. I wonder if we cannot finally include the aforementioned patch or conditionnaly allow the use sRGB colour via a build option (like —with-srgb).
> 
> 
> That would be great, and I’d be happy to do whatever is necessary to help this become a reality, e.g. contributor agreements etc.

The patch is just 4 lines, so it doesn't need any legal paperwork.

> My understanding is that everyone who cares about colour accuracy on OS X builds his Emacs with an sRGB patch of some sort. As for making this a build option, I don’t even think the non-sRGB colours should be an option on OS X, though I can’t speak for the whole NS platform.

Can you (or someone else) please explain the difference between these
two alternatives?

Re: sRGB color support in NS port

[Jan Djärv]

Hello.

20 dec 2013 kl. 19:13 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Steve Purcell <steve@sanityinc.com>
>> Date: Fri, 20 Dec 2013 18:04:46 +0000
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> 
>> On 20 Dec 2013, at 17:41, Bozhidar Batsov <bozhidar@batsov.com> wrote:
>> 
>>> Some time ago Steve Purcell reported an issue with hex colour rendering on OS X (http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html). While nothing was changed in Emacs, many OS X users apply a patch similar to this one https://gist.github.com/purcell/3858136 (an older version of the patch is used by homebrew) to get the desired behaviour. I wonder if we cannot finally include the aforementioned patch or conditionnaly allow the use sRGB colour via a build option (like —with-srgb).
>> 
>> 
>> That would be great, and I’d be happy to do whatever is necessary to help this become a reality, e.g. contributor agreements etc.
> 
> The patch is just 4 lines, so it doesn't need any legal paperwork.
> 
>> My understanding is that everyone who cares about colour accuracy on OS X builds his Emacs with an sRGB patch of some sort.

Your understanding is not fact.

>> As for making this a build option, I don’t even think the non-sRGB colours should be an option on OS X, though I can’t speak for the whole NS platform.

It must be an option.  The patch uses colorWithSRGBRed, which isn't availiable on OSX < 10.7.
sRGBColorSpace isn't available on OSX 10.4, which Emacs still supports.
Are you proposing ditching earlier OSX versions than 10.7?

	Jan D.

Re: sRGB color support in NS port

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

On Friday, December 20, 2013 at 8:55 PM, Jan Djärv wrote:
> Hello.
>  
> 20 dec 2013 kl. 19:13 skrev Eli Zaretskii <eliz@gnu.org (mailto:eliz@gnu.org)>:
>  
> > > From: Steve Purcell <steve@sanityinc.com (mailto:steve@sanityinc.com)>
> > > Date: Fri, 20 Dec 2013 18:04:46 +0000
> > > Cc: emacs-devel <emacs-devel@gnu.org (mailto:emacs-devel@gnu.org)>
> > >  
> > > On 20 Dec 2013, at 17:41, Bozhidar Batsov <bozhidar@batsov.com (mailto:bozhidar@batsov.com)> wrote:
> > >  
> > > > Some time ago Steve Purcell reported an issue with hex colour rendering on OS X (http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-05/msg00077.html). While nothing was changed in Emacs, many OS X users apply a patch similar to this one https://gist.github.com/purcell/3858136 (an older version of the patch is used by homebrew) to get the desired behaviour. I wonder if we cannot finally include the aforementioned patch or conditionnaly allow the use sRGB colour via a build option (like —with-srgb).
> > >  
> > >  
> > > That would be great, and I’d be happy to do whatever is necessary to help this become a reality, e.g. contributor agreements etc.
> >  
> > The patch is just 4 lines, so it doesn't need any legal paperwork.
> >  
> > > My understanding is that everyone who cares about colour accuracy on OS X builds his Emacs with an sRGB patch of some sort.
>  
> Your understanding is not fact.
>  
> > > As for making this a build option, I don’t even think the non-sRGB colours should be an option on OS X, though I can’t speak for the whole NS platform.
>  
> It must be an option. The patch uses colorWithSRGBRed, which isn't availiable on OSX < 10.7.
An option will do. Or maybe this could be automatically enabled for anyone using OS X 10.7+ (which would be the vast majority of OS X users). I can’t think
of a reason why someone who could use the sRGB colours would opt not to do so.
> sRGBColorSpace isn't available on OSX 10.4, which Emacs still supports.
> Are you proposing ditching earlier OSX versions than 10.7?
>  
>  

This is obviously not on the table since 10.5 was the last version to support PowerPC and I guess some people are still using Power Macs.
> Jan D.
>  
>  



[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

Re: sRGB color support in NS port

[Steve Purcell]

On 20 Dec 2013, at 18:55, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>> From: Steve Purcell <steve@sanityinc.com>
>>> My understanding is that everyone who cares about colour accuracy on OS X builds his Emacs with an sRGB patch of some sort.
> 
> Your understanding is not fact.


Agreed. It would be nice to do a survey sometime.



> 
>>> As for making this a build option, I don’t even think the non-sRGB colours should be an option on OS X, though I can’t speak for the whole NS platform.
> 
> It must be an option.  The patch uses colorWithSRGBRed, which isn't availiable on OSX < 10.7.
> sRGBColorSpace isn't available on OSX 10.4, which Emacs still supports.
> Are you proposing ditching earlier OSX versions than 10.7?


No, in that case an option is clearly the better choice. But it should likely be enabled by default when supported:

In Windows, sRGB is the default color space [1], and sRGB is also the most widely-used standard color space on OS X. This presumably means that when people on those platforms pick RGB colors which they would like Emacs to reproduce, the hex values they obtain and use are for sRGB. (When picking colors on X, results will vary due to the patchy color management.)

And in any case, Generic RGB is not an “absolute color space” [2], meaning that its values have no correspondence with absolute well-defined colours, so telling a host OS to just display a given generic RGB colour is going to result in OS-dependent mapping into an absolute color space, which may or may not be sRGB. Better then, I would think, to just handle colors as sRGB throughout where possible.

-Steve


[1] http://msdn.microsoft.com/en-us/library/windows/hardware/gg487409.aspx
[2] https://en.wikipedia.org/wiki/Absolute_color_space

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

commit 3b63b2c6e9e93adab09eace60750ed981a8e528f
Author: Steve Purcell <steve@sanityinc.com>
Date:   Sat Dec 21 11:44:12 2013 +0000

    Treat hex colors as sRGB under OS X >= 10.7

diff --git a/src/nsterm.m b/src/nsterm.m
index 733c05a..0c79186 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1373,6 +1373,13 @@ ns_fullscreen_hook (struct frame *f)
     Color management
 
    ========================================================================== */
+#if defined(NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7
+#define NS_COLOR_FROM_RGB(r, g, b) [NSColor colorWithSRGBRed: r green: g blue: b alpha: 1.0]
+#define NS_COLOR_AS_RGB(c) [c colorUsingColorSpace: [NSColorSpace sRGBColorSpace]]
+#else
+#define NS_COLOR_FROM_RGB(r, g, b) [NSColor colorWithCalibratedRed: r green: g blue: b alpha: 1.0]
+#define NS_COLOR_AS_RGB(c) [c colorUsingColorSpaceName: NSCalibratedRGBColorSpace]
+#endif
 
 
 NSColor *
@@ -1551,7 +1558,7 @@ ns_get_color (const char *name, NSColor **col)
 
   if (r >= 0.0F)
     {
-      *col = [NSColor colorWithCalibratedRed: r green: g blue: b alpha: 1.0];
+      *col = NS_COLOR_FROM_RGB(r, g, b);
       unblock_input ();
       return 0;
     }
@@ -1583,7 +1590,7 @@ ns_get_color (const char *name, NSColor **col)
   }
 
   if (new)
-    *col = [new colorUsingColorSpaceName: NSCalibratedRGBColorSpace];
+    *col = NS_COLOR_AS_RGB(new);
   unblock_input ();
   return new ? 0 : 1;
 }
@@ -1624,7 +1631,7 @@ ns_color_to_lisp (NSColor *col)
           return build_string ((char *)str);
         }
 
-    [[col colorUsingColorSpaceName: NSCalibratedRGBColorSpace]
+      [NS_COLOR_AS_RGB(col)
         getRed: &red green: &green blue: &blue alpha: &alpha];
   if (red ==green && red ==blue)
     {
@@ -4252,10 +4259,9 @@ ns_term_init (Lisp_Object display_name)
             name = SSDATA (XCAR (color));
             c = XINT (XCDR (color));
             [cl setColor:
-                  [NSColor colorWithCalibratedRed: RED_FROM_ULONG (c) / 255.0
-                                            green: GREEN_FROM_ULONG (c) / 255.0
-                                             blue: BLUE_FROM_ULONG (c) / 255.0
-                                            alpha: 1.0]
+                  NS_COLOR_FROM_RGB(RED_FROM_ULONG (c) / 255.0,
+                                    GREEN_FROM_ULONG (c) / 255.0,
+                                    BLUE_FROM_ULONG (c) / 255.0)
                   forKey: [NSString stringWithUTF8String: name]];
           }
         [cl writeToFile: nil];

Re: sRGB color support in NS port [PATCH]

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

The patch looks good to me. Users of OS X 10.7+ will get proper colours and
the rest (using older OS X or GNUStep) won't be affected by the change.


On 21 December 2013 16:10, Steve Purcell <steve@sanityinc.com> wrote:

> commit 3b63b2c6e9e93adab09eace60750ed981a8e528f
> Author: Steve Purcell <steve@sanityinc.com>
> Date:   Sat Dec 21 11:44:12 2013 +0000
>
>     Treat hex colors as sRGB under OS X >= 10.7
>
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 733c05a..0c79186 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -1373,6 +1373,13 @@ ns_fullscreen_hook (struct frame *f)
>      Color management
>
>
> ==========================================================================
> */
> +#if defined(NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED >=
> MAC_OS_X_VERSION_10_7
> +#define NS_COLOR_FROM_RGB(r, g, b) [NSColor colorWithSRGBRed: r green: g
> blue: b alpha: 1.0]
> +#define NS_COLOR_AS_RGB(c) [c colorUsingColorSpace: [NSColorSpace
> sRGBColorSpace]]
> +#else
> +#define NS_COLOR_FROM_RGB(r, g, b) [NSColor colorWithCalibratedRed: r
> green: g blue: b alpha: 1.0]
> +#define NS_COLOR_AS_RGB(c) [c colorUsingColorSpaceName:
> NSCalibratedRGBColorSpace]
> +#endif
>
>
>  NSColor *
> @@ -1551,7 +1558,7 @@ ns_get_color (const char *name, NSColor **col)
>
>    if (r >= 0.0F)
>      {
> -      *col = [NSColor colorWithCalibratedRed: r green: g blue: b alpha:
> 1.0];
> +      *col = NS_COLOR_FROM_RGB(r, g, b);
>        unblock_input ();
>        return 0;
>      }
> @@ -1583,7 +1590,7 @@ ns_get_color (const char *name, NSColor **col)
>    }
>
>    if (new)
> -    *col = [new colorUsingColorSpaceName: NSCalibratedRGBColorSpace];
> +    *col = NS_COLOR_AS_RGB(new);
>    unblock_input ();
>    return new ? 0 : 1;
>  }
> @@ -1624,7 +1631,7 @@ ns_color_to_lisp (NSColor *col)
>            return build_string ((char *)str);
>          }
>
> -    [[col colorUsingColorSpaceName: NSCalibratedRGBColorSpace]
> +      [NS_COLOR_AS_RGB(col)
>          getRed: &red green: &green blue: &blue alpha: &alpha];
>    if (red ==green && red ==blue)
>      {
> @@ -4252,10 +4259,9 @@ ns_term_init (Lisp_Object display_name)
>              name = SSDATA (XCAR (color));
>              c = XINT (XCDR (color));
>              [cl setColor:
> -                  [NSColor colorWithCalibratedRed: RED_FROM_ULONG (c) /
> 255.0
> -                                            green: GREEN_FROM_ULONG (c) /
> 255.0
> -                                             blue: BLUE_FROM_ULONG (c) /
> 255.0
> -                                            alpha: 1.0]
> +                  NS_COLOR_FROM_RGB(RED_FROM_ULONG (c) / 255.0,
> +                                    GREEN_FROM_ULONG (c) / 255.0,
> +                                    BLUE_FROM_ULONG (c) / 255.0)
>                    forKey: [NSString stringWithUTF8String: name]];
>            }
>          [cl writeToFile: nil];
>
>

[-- Attachment #2: Type: text/html, Size: 3701 bytes --]

Re: sRGB color support in NS port [PATCH]

[Jan Djärv]

Hello.

This has been done in another way in trunk.
Customize ns-use-srgb-colorspace to use sRGB.  Default is to use calibrated space.

Note that images still don't use sRGB color space.  Nor do they with the patch below.
Also, this is not what the documentation says is the right way to display colors on OSX.

	Jan D.


21 dec 2013 kl. 15:10 skrev Steve Purcell <steve@sanityinc.com>:

> commit 3b63b2c6e9e93adab09eace60750ed981a8e528f
> Author: Steve Purcell <steve@sanityinc.com>
> Date:   Sat Dec 21 11:44:12 2013 +0000
> 
>    Treat hex colors as sRGB under OS X >= 10.7
> 
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 733c05a..0c79186 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -1373,6 +1373,13 @@ ns_fullscreen_hook (struct frame *f)
>     Color management
> 
>    ========================================================================== */
> +#if defined(NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_7
> +#define NS_COLOR_FROM_RGB(r, g, b) [NSColor colorWithSRGBRed: r green: g blue: b alpha: 1.0]
> +#define NS_COLOR_AS_RGB(c) [c colorUsingColorSpace: [NSColorSpace sRGBColorSpace]]
> +#else
> +#define NS_COLOR_FROM_RGB(r, g, b) [NSColor colorWithCalibratedRed: r green: g blue: b alpha: 1.0]
> +#define NS_COLOR_AS_RGB(c) [c colorUsingColorSpaceName: NSCalibratedRGBColorSpace]
> +#endif
> 
> 
> NSColor *
> @@ -1551,7 +1558,7 @@ ns_get_color (const char *name, NSColor **col)
> 
>   if (r >= 0.0F)
>     {
> -      *col = [NSColor colorWithCalibratedRed: r green: g blue: b alpha: 1.0];
> +      *col = NS_COLOR_FROM_RGB(r, g, b);
>       unblock_input ();
>       return 0;
>     }
> @@ -1583,7 +1590,7 @@ ns_get_color (const char *name, NSColor **col)
>   }
> 
>   if (new)
> -    *col = [new colorUsingColorSpaceName: NSCalibratedRGBColorSpace];
> +    *col = NS_COLOR_AS_RGB(new);
>   unblock_input ();
>   return new ? 0 : 1;
> }
> @@ -1624,7 +1631,7 @@ ns_color_to_lisp (NSColor *col)
>           return build_string ((char *)str);
>         }
> 
> -    [[col colorUsingColorSpaceName: NSCalibratedRGBColorSpace]
> +      [NS_COLOR_AS_RGB(col)
>         getRed: &red green: &green blue: &blue alpha: &alpha];
>   if (red ==green && red ==blue)
>     {
> @@ -4252,10 +4259,9 @@ ns_term_init (Lisp_Object display_name)
>             name = SSDATA (XCAR (color));
>             c = XINT (XCDR (color));
>             [cl setColor:
> -                  [NSColor colorWithCalibratedRed: RED_FROM_ULONG (c) / 255.0
> -                                            green: GREEN_FROM_ULONG (c) / 255.0
> -                                             blue: BLUE_FROM_ULONG (c) / 255.0
> -                                            alpha: 1.0]
> +                  NS_COLOR_FROM_RGB(RED_FROM_ULONG (c) / 255.0,
> +                                    GREEN_FROM_ULONG (c) / 255.0,
> +                                    BLUE_FROM_ULONG (c) / 255.0)
>                   forKey: [NSString stringWithUTF8String: name]];
>           }
>         [cl writeToFile: nil];

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

On 21 Dec 2013, at 16:16, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello.
> 
> This has been done in another way in trunk.
> Customize ns-use-srgb-colorspace to use sRGB.  Default is to use calibrated space.


I appreciate you taking the time to commit those changes.


> 
> Note that images still don't use sRGB color space.  Nor do they with the patch below.


No, and of course that is correct.


> Also, this is not what the documentation says is the right way to display colors on OSX.


That’s actually not at all clear to me from the docs: I haven’t found anything which says that programs may only accept from users hex colour literals in the calibrated RGB space.  The docs appear to simply say that that is the space to use within NS programs for shuffling R, G and B values around.  What we’re talking about here is how to interpret user colour input, and how to display colours back to the user as RGB triplets.

To be useful, the user-oriented RGB notation should presumably denote colours which will be displayed consistently on all machines. For that to be even be possible, those colours must be in an absolute and standard colour space.

On Windows, the RGB colour literals will be assumed to be coordinates within its default sRGB space. On OS X, emacs will claim that they are in the vague “calibrated” space, which is not sRGB, so they will automatically look different between the two platforms. This seems like a shortcoming to me, and it’s not clear to me that making the color space a user preference is the correct fix, at least if the default is the calibrated space.

But maybe I've missed something and/or my logical understanding of the situation is flawed, and I’d be happy to find out how. :-)

Cheers,

-Steve

Re: sRGB color support in NS port [PATCH]

[Jan Djärv]

Hello.

21 dec 2013 kl. 18:37 skrev Steve Purcell <steve@sanityinc.com>:

> On 21 Dec 2013, at 16:16, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
> 
>> Also, this is not what the documentation says is the right way to display colors on OSX.
> 
> 
> That’s actually not at all clear to me from the docs: I haven’t found anything which says that programs may only accept from users hex colour literals in the calibrated RGB space.  The docs appear to simply say that that is the space to use within NS programs for shuffling R, G and B values around.  What we’re talking about here is how to interpret user colour input, and how to display colours back to the user as RGB triplets.
> 

They don't say "may only", but suggests calibrated color space to overcome differences between monitors.
Two different monitor should in theory display the same sRGB color the same.  In practice this is seldom so.  So you calibrate each monitor individually to get the same color.


> To be useful, the user-oriented RGB notation should presumably denote colours which will be displayed consistently on all machines. For that to be even be possible, those colours must be in an absolute and standard colour space.

This only applies if all display devices output sRGB the same.  They don't.  Also, sRGB has a limited color range, some wants to go beyond this range (gaumut I think it is called).  Adobe has some RGB color spaces that contains more colors than sRGB for example.

> 
> On Windows, the RGB colour literals will be assumed to be coordinates within its default sRGB space. On OS X, emacs will claim that they are in the vague “calibrated” space, which is not sRGB, so they will automatically look different between the two platforms. This seems like a shortcoming to me, and it’s not clear to me that making the color space a user preference is the correct fix, at least if the default is the calibrated space.

Well, OSX doesn't use \ in paths like Windows either, not does it use 16 bit chars in API:s and a bunch of other differences.  Saying X does something, therefore we must do like X is a nonsense argument.

	Jan D.

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

Hi Jan,

On 21 Dec 2013, at 18:10, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello.
> 
> 21 dec 2013 kl. 18:37 skrev Steve Purcell <steve@sanityinc.com>:
> 
>> On 21 Dec 2013, at 16:16, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 
>> 
>>> Also, this is not what the documentation says is the right way to display colors on OSX.
>> 
>> 
>> That’s actually not at all clear to me from the docs: I haven’t found anything which says that programs may only accept from users hex colour literals in the calibrated RGB space.  The docs appear to simply say that that is the space to use within NS programs for shuffling R, G and B values around.  What we’re talking about here is how to interpret user colour input, and how to display colours back to the user as RGB triplets.
>> 
> 
> They don't say "may only", but suggests calibrated color space to overcome differences between monitors.
> Two different monitor should in theory display the same sRGB color the same.  In practice this is seldom so.  So you calibrate each monitor individually to get the same color.


Yes, I understand calibration well, and that is certainly necessary in order to get reliable results. But it is orthogonal to this issue.

If I enter a hex colour value into, say, Photoshop or a web page, I know what colour space it is in, because it is defined.  What colour space are hex colours in Emacs in?  The current answer is, “whatever the host OS likes to work with”.

My view is that we can do better: this is an opportunity to settle on a consistent answer, by defining the reference colour space for Emacs’ RGB literals. And sRGB is the obvious choice, because it is already the standard for Windows and the Web, with the only (widely-accepted) limitation being that certain narrow ranges of colours displayable by extra-wide-gamut monitors are outside the sRGB space.

> 
>> To be useful, the user-oriented RGB notation should presumably denote colours which will be displayed consistently on all machines. For that to be even be possible, those colours must be in an absolute and standard colour space.
> 
> This only applies if all display devices output sRGB the same.  They don't.  Also, sRGB has a limited color range, some wants to go beyond this range (gaumut I think it is called).  Adobe has some RGB color spaces that contains more colors than sRGB for example.


If you have colours specified in sRGB, then they *will* display identically on any calibrated monitor with a colour profile, to the maximum extent possible on that hardware.


>> 
>> On Windows, the RGB colour literals will be assumed to be coordinates within its default sRGB space. On OS X, emacs will claim that they are in the vague “calibrated” space, which is not sRGB, so they will automatically look different between the two platforms. This seems like a shortcoming to me, and it’s not clear to me that making the color space a user preference is the correct fix, at least if the default is the calibrated space.
> 
> Well, OSX doesn't use \ in paths like Windows either, not does it use 16 bit chars in API:s and a bunch of other differences.  Saying X does something, therefore we must do like X is a nonsense argument.


That summary of my argument does not accurately reflect the point I was making.

This seems like an opportunity to do something that helps colours *actually look the same* across platforms, because the current situation only guarantees that they will look different.

-Steve

Re: sRGB color support in NS port [PATCH]

[David De La Harpe Golden]

On 21/12/13 17:37, Steve Purcell wrote:

> On Windows, the RGB colour literals will be assumed to be coordinates within its default sRGB space.
 > On OS X, emacs will claim that they are in the vague “calibrated” 
space, which is not sRGB, so
 > they will automatically look different between the two platforms. 
This seems like a shortcoming to
 > me, and it’s not clear to me that making the color space a user 
preference is the correct fix, at
 > least if the default is the calibrated space.


> But maybe I've missed something and/or my logical understanding of the
 > situation is flawed, and I’d be happy to find out how. :-)
>

Well, doesn't change things much, but I'm not sure "[Apple] Generic RGB" 
is as vague as you think. No, it's not the same as either historical 
"Apple RGB" or of course sRGB, but doesn't quite look to me like it's 
just some "a generic RGB color space" in the sense the wikipedia 
absolute colorspaces article you previously linked meant. [1][2]

But Emacs is presently primarily a (coding-friendly) text-editor 
(leaving aside recent discussions about wysiwig word processing).  So 
sRGB, whatever its failings, seems fairly adequate for emacs' normal 
duties. sRGB is obviously fine for ordinary text-editing and coding, you 
don't need wide gamut for a few different syntax highlights, and it's 
actively beneficial for the webdev guys.  And cross-platform consistency 
of emacs color themes might be something a lot of users want.

If emacs devs were to just up and declare:

"""On color-management-capable platforms, where possible emacs shall 
default to sRGB for interpretation of rgb triples without any explicit 
color space declaration."""

(and maybe a related: """emacs will adopt the static list of 
HTML/CSS/SVG named-color definitions where applicable, superseding any 
historical X11/emacs named-color definitions  - and user-defined 
named-colors on platforms that support them (i.e. X11) - where they 
clash""" [3][4])

...that's a reasonable enough project decision if you ask me. Not sure 
I'd bother even including an option to switch the default color space 
for such unqualified triples to anything else (just maybe note that at 
some future date a larger component value range may become valid, for 
scRGB).

But do bear in mind X11 has history here. The full X11 color 
specification string syntax that is fundamentally where emacs gets its 
notions of how to interpret color specifications has long included 
support for explicitly device-independent colors with a color space 
qualification prefix like e.g. "CIEXYZ:x/y/z".   Though no-one ever 
added support for "srgb:r/g/b" to date which is a shame, and it may be 
difficult to find X people who care to do so now, with so many treating 
X as legacy and looking to Wayland (and I imagine that'll almost 
certainly default to sRGB, though haven't checked).

Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all 
_explicitly defined_ to be in the vague device-dependent space in the 
X11 syntax (man XParseColors). So if emacs DOES decide the above, X11 
color handling code will need work: X11 emacs wouldn't be able to just 
hand off all color strings to X11 for resolution any more, it would have 
to treat color-space-unqualified triples (and perhaps named colors) 
differently to X11 itself.

(The alternative, changing ns/mac and w32 to treat #RRGGBB as 
device-dependent and require explicit color space prefixing for anything 
else for full "feature"-compatibility with X11, doesn't seem all that 
attractive, but would also be consistent... I mention it for completeness)




[1] https://developer.apple.com/library/mac/qa/qa1430/_index.html
[2] https://github.com/gnachman/iTerm2/pull/149

[3]http://en.wikipedia.org/wiki/Web_color
[4]http://en.wikipedia.org/wiki/X11_color_names

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

Hi David,

On 21 Dec 2013, at 20:26, David De La Harpe Golden <david@harpegolden.net> wrote:
> But Emacs is presently primarily a (coding-friendly) text-editor (leaving aside recent discussions about wysiwig word processing).  So sRGB, whatever its failings, seems fairly adequate for emacs' normal duties. sRGB is obviously fine for ordinary text-editing and coding, you don't need wide gamut for a few different syntax highlights, and it's actively beneficial for the webdev guys.  And cross-platform consistency of emacs color themes might be something a lot of users want.


Yes, there are a *lot* of themes out there, and some of the most popular contain outrageous and unreliable hacks to compensate for the inconsistent interpretation of rgb literals on different emacs platforms:

https://github.com/sellout/emacs-color-theme-solarized/blob/master/solarized-definitions.el#L43

Others assume (more sanely) that OS X users have an sRGB patch compiled into their emacs, so that the theme will look the same as on Windows, which is (as you note) the only other major emacs platform to consistently handle plain #RRGGBB colours.


> If emacs devs were to just up and declare:
> 
> """On color-management-capable platforms, where possible emacs shall default to sRGB for interpretation of rgb triples without any explicit color space declaration."""
> 
> (and maybe a related: """emacs will adopt the static list of HTML/CSS/SVG named-color definitions where applicable, superseding any historical X11/emacs named-color definitions  - and user-defined named-colors on platforms that support them (i.e. X11) - where they clash""" [3][4])
> 
> ...that's a reasonable enough project decision if you ask me. Not sure I'd bother even including an option to switch the default color space for such unqualified triples to anything else (just maybe note that at some future date a larger component value range may become valid, for scRGB).


Yes, I also believe such a declaration would be extremely helpful, and a big improvement on the current situation.


> But do bear in mind X11 has history here. The full X11 color specification string syntax that is fundamentally where emacs gets its notions of how to interpret color specifications has long included support for explicitly device-independent colors with a color space qualification prefix like e.g. "CIEXYZ:x/y/z".   Though no-one ever added support for "srgb:r/g/b" to date which is a shame, and it may be difficult to find X people who care to do so now, with so many treating X as legacy and looking to Wayland (and I imagine that'll almost certainly default to sRGB, though haven't checked).


Yes, it does look like Wayland plan to default to sRGB:

http://www.chaosreigns.com/wiki/Wayland_design_documents_and_drawing


> Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all _explicitly defined_ to be in the vague device-dependent space in the X11 syntax (man XParseColors). So if emacs DOES decide the above, X11 color handling code will need work: X11 emacs wouldn't be able to just hand off all color strings to X11 for resolution any more, it would have to treat color-space-unqualified triples (and perhaps named colors) differently to X11 itself.


Right, so in summary, without any immediate changes emacs on X11 would be unaffected by any standardisation on sRGB, but over time further work could be undertaken on that platform to ensure that those “plain” RGB colour specs are interpreted as well-defined sRGB colours.  Makes sense.


> (The alternative, changing ns/mac and w32 to treat #RRGGBB as device-dependent and require explicit color space prefixing for anything else for full "feature"-compatibility with X11, doesn't seem all that attractive, but would also be consistent... I mention it for completeness)


Agreed.

-Steve

Re: sRGB color support in NS port [PATCH]

[Stephen J. Turnbull]

David De La Harpe Golden writes:

 > But Emacs is presently primarily a (coding-friendly) text-editor 
 > (leaving aside recent discussions about wysiwig word processing).  So 
 > sRGB, whatever its failings, seems fairly adequate for emacs' normal 
 > duties.

+1

Please, let's stop trying to make core Emacs suitable for tasks that
other projects have spent man-decades (in some cases, man-centuries)
on.

 > If emacs devs were to just up and declare:
 > 
 > """On color-management-capable platforms, where possible emacs shall 
 > default to sRGB for interpretation of rgb triples without any explicit 
 > color space declaration."""
 > 
 > (and maybe a related: """emacs will adopt the static list of 
 > HTML/CSS/SVG named-color definitions where applicable, superseding any 
 > historical X11/emacs named-color definitions  - and user-defined 
 > named-colors on platforms that support them (i.e. X11) - where they 
 > clash""" [3][4])

+0.9  IWBNI Emacs also provided a way to get the effect of the old
names.  I doubt anybody is going to notice the difference between sRGB
and RGB (except maybe themers who are matching WMs that use a
different color space).  But if names conflict, anything can happen.
(It was years before I realized that "cyan" was on the G side of B,
and a bit embarrassing when my nose was rubbed in the fact. :-)

 > Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all 
 > _explicitly defined_ to be in the vague device-dependent space in the 
 > X11 syntax (man XParseColors).

I think the thing to do here is to steal "#RGB" for sRGB, and provide
a trivial textual translator for those strings, plus one that reads in
rgb.txt as device-dependent.

 > (The alternative, changing ns/mac and w32 to treat #RRGGBB as 
 > device-dependent and require explicit color space prefixing for anything 
 > else for full "feature"-compatibility with X11, doesn't seem all that 
 > attractive, but would also be consistent... I mention it for
 > completeness)

It doesn't seem very future-proof.

Steve

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

On 22 Dec 2013, at 00:31, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> David De La Harpe Golden writes:
> 
>> If emacs devs were to just up and declare:
>> 
>> """On color-management-capable platforms, where possible emacs shall 
>> default to sRGB for interpretation of rgb triples without any explicit 
>> color space declaration."""
>> 
>> (and maybe a related: """emacs will adopt the static list of 
>> HTML/CSS/SVG named-color definitions where applicable, superseding any 
>> historical X11/emacs named-color definitions  - and user-defined 
>> named-colors on platforms that support them (i.e. X11) - where they 
>> clash""" [3][4])
> 
> +0.9  IWBNI Emacs also provided a way to get the effect of the old
> names.  I doubt anybody is going to notice the difference between sRGB
> and RGB (except maybe themers who are matching WMs that use a
> different color space).  But if names conflict, anything can happen.
> (It was years before I realized that "cyan" was on the G side of B,
> and a bit embarrassing when my nose was rubbed in the fact. :-)
> 
>> Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all 
>> _explicitly defined_ to be in the vague device-dependent space in the 
>> X11 syntax (man XParseColors).
> 
> I think the thing to do here is to steal "#RGB" for sRGB, and provide
> a trivial textual translator for those strings, plus one that reads in
> rgb.txt as device-dependent.



So given the general tone of support for treating #RGB as sRGB, can we (as a first small step) agree to enable Jan’s new sRGB option for NS by default?

-Steve

Re: sRGB color support in NS port [PATCH]

[David De La Harpe Golden]

On 22/12/13 00:31, Stephen J. Turnbull wrote:

 > +0.9  IWBNI Emacs also provided a way to get the effect of the old
 > names.

Not impossible, one could imagine a list of resolvers, or a scope prefix.

Though bear in mind there are apparently (sayeth wikipedia) only ~4 real 
conflicts (though I suppose not rare colors: gray, green, maroon, 
purple) [1] (at least ignoring user-defined named colors), so it may not 
be worth it, especially as you could still set the x-like color by rgb 
triple.

 >   > Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all
 >   > _explicitly defined_ to be in the vague device-dependent space in the
 >   > X11 syntax (man XParseColors).
 >
 > I think the thing to do here is to steal "#RGB" for sRGB,

Well, what's more important...  That #0DEA84 is the same color on 
x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...

Mind you, I do now belatedly recall: last I heard/understood of plans in 
the area (some time ago now), was that a color-managing compositor 
plugin component of the "new" color management stack [2] would "soon" 
mean that any such x11 nominally-device-dependent rgb colors presented 
by said-new-stack unaware clients _would_ nonetheless ultimately tend to 
end up being interpreted as sRGB on x11 too (!), despite my earlier 
claims & their historical definition. Though I don't know how widely 
adopted that infrastructure is yet [3].

[1] http://en.wikipedia.org/wiki/X11_colors#Color_name_clashes
[2] http://www.oyranos.org/compicc/
[3] http://sourceforge.net/p/oyranos/feature-requests/2/#d625

Re: sRGB color support in NS port [PATCH]

[Jan Djärv]

Hello.

22 dec 2013 kl. 22:20 skrev David De La Harpe Golden <david@harpegolden.net>:

> Well, what's more important...  That #0DEA84 is the same color on x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...

Given that mac/ns/w32 is not free software, and xterm/xclock and so on is, I'd say the latter.

	Jan D.

Re: sRGB color support in NS port [PATCH]

[David De La Harpe Golden]

On 22/12/13 21:32, Jan Djärv wrote:
> Hello.
>
> 22 dec 2013 kl. 22:20 skrev David De La Harpe Golden <david@harpegolden.net>:
>
>> Well, what's more important...  That #0DEA84 is the same color on x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...
>
> Given that mac/ns/w32 is not free software, and xterm/xclock and so on is, I'd say the latter.
>

Well, nitpick: ns as in the quietly-still-alive gnustep is free? (does 
look like gnustep is growing srgb support [1]).

And I did leave out "and web browsers", some of 'em are free.

[1] 
https://github.com/gnustep/gnustep-opal/blob/master/Headers/CoreGraphics/CGColorSpace.h#L69

Re: sRGB color support in NS port [PATCH]

[Jan Djärv]

Hi. 

> 22 dec 2013 kl. 23:41 skrev David De La Harpe Golden <david@harpegolden.net>:
> 
>> On 22/12/13 21:32, Jan Djärv wrote:
>> Hello.
>> 
>>> 22 dec 2013 kl. 22:20 skrev David De La Harpe Golden <david@harpegolden.net>:
>>> 
>>> Well, what's more important...  That #0DEA84 is the same color on x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...
>> 
>> Given that mac/ns/w32 is not free software, and xterm/xclock and so on is, I'd say the latter.
>> 
> 
> Well, nitpick: ns as in the quietly-still-alive gnustep is free? (does look like gnustep is growing srgb support [1]).

GNUStep is free software. As it uses X11, it too would be better off showing colors as xterm and friends. But as you say, it doesn't support sRGB anyway. 

     Jan D. 

Re: sRGB color support in NS port [PATCH]

[Stephen J. Turnbull]

David De La Harpe Golden writes:

 > Well, what's more important...  That #0DEA84 is the same color on 
 > x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...

They're both pretty unimportant, actually.  What's more important is
that it give similar results to web browsers and office suites, but
even that is not all that big a deal.

As for free software, supporting free software is indeed important,
but it seems to me that adopting a widespread standard that gives
users an experience consistent with other modern apps doesn't conflict
with that.

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

On 23 Dec 2013, at 12:42, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> David De La Harpe Golden writes:
> 
>> Well, what's more important...  That #0DEA84 is the same color on 
>> x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...
> 
> They're both pretty unimportant, actually.  What's more important is
> that it give similar results to web browsers and office suites, but
> even that is not all that big a deal.
> 
> As for free software, supporting free software is indeed important,
> but it seems to me that adopting a widespread standard that gives
> users an experience consistent with other modern apps doesn't conflict
> with that.


Agreed. So can we please enable the new sRGB option on NS by default, then?

Colours won’t match between platforms with it disabled anyway, so there’s nothing to lose in enabling it, and it would also help pave the way for standardisation on sRGB across platforms.

-Steve

Re: sRGB color support in NS port [PATCH]

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Tue, Dec 24 2013, Steve Purcell wrote:

> Agreed. So can we please enable the new sRGB option on NS by default, then?
>
> Colours won’t match between platforms with it disabled anyway, so there’s
> nothing to lose in enabling it, and it would also help pave the way for
> standardisation on sRGB across platforms.

I also think it's a good idea. If you have a patch I can review and
commit I'd be glad to do so, Steve.

-- 
Julien Danjou
;; Free Software hacker ; independent consultant
;; http://julien.danjou.info

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

On 26 Dec 2013, at 09:45, Julien Danjou <julien@danjou.info> wrote:

> On Tue, Dec 24 2013, Steve Purcell wrote:
> 
>> Agreed. So can we please enable the new sRGB option on NS by default, then?
>> 
>> Colours won’t match between platforms with it disabled anyway, so there’s
>> nothing to lose in enabling it, and it would also help pave the way for
>> standardisation on sRGB across platforms.
> 
> I also think it's a good idea. If you have a patch I can review and
> commit I'd be glad to do so, Steve.


Thanks to Jan’s work, it's just a matter of setting ns-use-srgb-colorspace to YES instead of NO in src/nsterm.m. Corresponding patch is below:




83c87170d77b1b8db17eb6a7c1f18d5e33d62e17 HEAD master
Author: Steve Purcell <steve@sanityinc.com>
Date:   Thu Dec 26 12:08:20 2013 +0000

    Enable ns-use-srgb-colorspace by default
    
    https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00706.html

2 files changed, 2 insertions(+), 2 deletions(-)
 etc/NEWS     | 2 +-
 src/nsterm.m | 2 +-

	Modified   etc/NEWS
diff --git a/etc/NEWS b/etc/NEWS
index 5aedab6..03ea2e4 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1248,7 +1248,7 @@ Customize `ns-use-native-fullscreen' to change style.  For >= 10.7
 native is the default.
 
 ** OSX >= 10.7 can use sRGB colorspace.
-Customize `ns-use-srgb-colorspace' to change style.  nil is the default.
+Customize `ns-use-srgb-colorspace' to change style.  t is the default.
 Note: This does not apply to images.
 
 \f
	Modified   src/nsterm.m
diff --git a/src/nsterm.m b/src/nsterm.m
index f2aef42..07f52c0 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -7648,7 +7648,7 @@ Default is t for OSX >= 10.7, nil otherwise. */);
      doc: /*Non-nil means to use sRGB colorspace on OSX >= 10.7.
 Note that this does not apply to images.            
 This variable is ignored on OSX < 10.7 and GNUStep.  Default is nil. */);
-  ns_use_srgb_colorspace = NO;
+  ns_use_srgb_colorspace = YES;
 
   /* TODO: move to common code */
   DEFVAR_LISP ("x-toolkit-scroll-bars", Vx_toolkit_scroll_bars,

Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

On 26 Dec 2013, at 12:12, Steve Purcell <steve@sanityinc.com> wrote:

> Thanks to Jan’s work, it's just a matter of setting ns-use-srgb-colorspace to YES instead of NO in src/nsterm.m. Corresponding patch is below:



Oops, missed a docstring. Here’s a better patch:


fb80128e4ab8d1884a25b89a9ee5b166cd8595a5 HEAD master
Author: Steve Purcell <steve@sanityinc.com>
Date:   Thu Dec 26 12:08:20 2013 +0000

    Enable ns-use-srgb-colorspace by default
    
    See thread https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00706.html

2 files changed, 3 insertions(+), 3 deletions(-)
 etc/NEWS     | 2 +-
 src/nsterm.m | 4 ++--

	Modified   etc/NEWS
diff --git a/etc/NEWS b/etc/NEWS
index 5aedab6..03ea2e4 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1248,7 +1248,7 @@ Customize `ns-use-native-fullscreen' to change style.  For >= 10.7
 native is the default.
 
 ** OSX >= 10.7 can use sRGB colorspace.
-Customize `ns-use-srgb-colorspace' to change style.  nil is the default.
+Customize `ns-use-srgb-colorspace' to change style.  t is the default.
 Note: This does not apply to images.
 
 \f
	Modified   src/nsterm.m
diff --git a/src/nsterm.m b/src/nsterm.m
index f2aef42..635f579 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -7647,8 +7647,8 @@ Default is t for OSX >= 10.7, nil otherwise. */);
   DEFVAR_BOOL ("ns-use-srgb-colorspace", ns_use_srgb_colorspace,
      doc: /*Non-nil means to use sRGB colorspace on OSX >= 10.7.
 Note that this does not apply to images.            
-This variable is ignored on OSX < 10.7 and GNUStep.  Default is nil. */);
-  ns_use_srgb_colorspace = NO;
+This variable is ignored on OSX < 10.7 and GNUStep.  Default is t. */);
+  ns_use_srgb_colorspace = YES;
 
   /* TODO: move to common code */
   DEFVAR_LISP ("x-toolkit-scroll-bars", Vx_toolkit_scroll_bars,