1882: "Color Models"

This forum is for the individual discussion thread that goes with each new comic.

Moderators: Moderators General, Prelates, Magistrates

sonar1313
Posts: 78
Joined: Tue Mar 05, 2013 5:29 am UTC

Re: 1882: "Color Models"

Postby sonar1313 » Thu Aug 31, 2017 2:49 am UTC

Old Bruce wrote:Naming colours... I submit for your consideration: Wine dark sea.
What the fuck?


A question that people have been asking (almost verbatim, really) ever since Homer was translated into English. Maybe before; Greek is notorious for having concepts that translate poorly out of Greek, as Biblical scholars have long since found out. And there are hundreds of different answers. The one I like best is that the Greeks generally ordered colors from light to dark rather than using the visible spectrum or any other more modern discovery or construct. This article (https://www.laphamsquarterly.org/sea/winelike-sea) rambles, but the core concept seems to be:

Rather than being ignorant of color, it seems that the Greeks were less interested in and attentive to hue, or tint, than they were to light. As late as the fourth century BC, Plato named the four primary colors as white, black, red, and bright, and in those cases where a Greek writer lists colors “in order,” they are arranged not by the Newtonian colors of the rainbow—red, orange, yellow, green, blue, indigo, violet—but from lightest to darkest.


So to Homer and his readers, dark blue and dark red (Greek red wine was indeed very dark) would've been similar enough that everyone would've got it.

User avatar
Old Bruce
Posts: 57
Joined: Tue Jun 28, 2016 2:27 pm UTC

Re: 1882: "Color Models"

Postby Old Bruce » Thu Aug 31, 2017 3:31 pm UTC

sonar1313 wrote:
Old Bruce wrote:Naming colours... I submit for your consideration: Wine dark sea.
What the fuck?


A question that people have been asking (almost verbatim, really) ever since Homer was translated into English. Maybe before; Greek is notorious for having concepts that translate poorly out of Greek, as Biblical scholars have long since found out. And there are hundreds of different answers. The one I like best is that the Greeks generally ordered colors from light to dark rather than using the visible spectrum or any other more modern discovery or construct. This article (https://www.laphamsquarterly.org/sea/winelike-sea) rambles, but the core concept seems to be:

Rather than being ignorant of color, it seems that the Greeks were less interested in and attentive to hue, or tint, than they were to light. As late as the fourth century BC, Plato named the four primary colors as white, black, red, and bright, and in those cases where a Greek writer lists colors “in order,” they are arranged not by the Newtonian colors of the rainbow—red, orange, yellow, green, blue, indigo, violet—but from lightest to darkest.


So to Homer and his readers, dark blue and dark red (Greek red wine was indeed very dark) would've been similar enough that everyone would've got it.

A very sincere Thank You.

User avatar
Steve the Pocket
Posts: 644
Joined: Mon Apr 23, 2007 4:02 am UTC
Location: Going downtuuu in a Luleelurah!

Re: 1882: "Color Models"

Postby Steve the Pocket » Fri Sep 01, 2017 5:25 am UTC

See also: this video from Vox explaining how this phenomenon tends to happen in the early stages of any civilization.
cephalopod9 wrote:Only on Xkcd can you start a topic involving Hitler and people spend the better part of half a dozen pages arguing about the quality of Operating Systems.

Baige.

pernishus
Posts: 19
Joined: Thu Jan 29, 2015 2:38 pm UTC

Re: 1882: "Color Models"

Postby pernishus » Wed Sep 06, 2017 12:27 pm UTC

I propose that it's time to replace ROY G BIV with ROY G CIV. The last three colors should clearly be Cyan, Indigo, Violet; there is not a clear difference between blue and indigo, but cyan can be easily distinguished from indigo. And I'm sure Roy would be fine sharing the name of a terrific video game series.

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 2467
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1882: "Color Models"

Postby Soupspoon » Wed Sep 06, 2017 12:35 pm UTC

"Richard Of York Gave Cattle In Vain"? Naw. Doesn't work.

:P

User avatar
Pfhorrest
Posts: 3898
Joined: Fri Oct 30, 2009 6:11 am UTC
Contact:

Re: 1882: "Color Models"

Postby Pfhorrest » Wed Sep 06, 2017 3:38 pm UTC

It should really be ROY G CAB is you want a properly-balanced spectrum by modern color theory. Hue angles 0, 30, 60, 120, 180, 210, and 240; red, orange, yellow, green, cyan, azure, blue.
Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
The Codex Quaerendae (my philosophy) - The Chronicles of Quelouva (my fiction)

pernishus
Posts: 19
Joined: Thu Jan 29, 2015 2:38 pm UTC

Re: 1882: "Color Models"

Postby pernishus » Thu Sep 07, 2017 12:59 pm UTC

Pfhorrest wrote:It should really be ROY G CAB is you want a properly-balanced spectrum by modern color theory. Hue angles 0, 30, 60, 120, 180, 210, and 240; red, orange, yellow, green, cyan, azure, blue.


Where is purple/violet in your model?

User avatar
Old Bruce
Posts: 57
Joined: Tue Jun 28, 2016 2:27 pm UTC

Re: 1882: "Color Models"

Postby Old Bruce » Thu Sep 07, 2017 2:23 pm UTC

pernishus wrote:
Pfhorrest wrote:It should really be ROY G CAB is you want a properly-balanced spectrum by modern color theory. Hue angles 0, 30, 60, 120, 180, 210, and 240; red, orange, yellow, green, cyan, azure, blue.


Where is purple/violet in your model?

It/they don't really exist outside of our brains/minds.

User avatar
Flumble
Yes Man
Posts: 1943
Joined: Sun Aug 05, 2012 9:35 pm UTC

Re: 1882: "Color Models"

Postby Flumble » Thu Sep 07, 2017 2:28 pm UTC

pernishus wrote:
Pfhorrest wrote:It should really be ROY G CAB is you want a properly-balanced spectrum by modern color theory. Hue angles 0, 30, 60, 120, 180, 210, and 240; red, orange, yellow, green, cyan, azure, blue.


Where is purple/violet in your model?

Violet (as the spectral colour) is not part of the colour wheel whereas purple (as a mixture of blue and red) is not part of a rainbow.*
Also, where do you fit black, gray and white?

*as long as a refraction of red does not overlap with another refraction of blue, which I'm not sure of.

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 2467
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1882: "Color Models"

Postby Soupspoon » Thu Sep 07, 2017 3:37 pm UTC

Going with 100% Saturation and Value, and every 10° Hue, I'm subjecting myself to a self-imposed form of the Colour Survey, for your delight and delectation! ROYGBIV names (or recently given variants) are given unambiguously, the rest fill in as parenthesised, and some of those are easier than others.

000° - Red
010° - (orangey red)
020° - (redey orange)
030° - 'Orange' (noting that Orange isn't so easy to tie down in RGB space)
040° - (peachy?)
050° - (lemony?)
060° - Yellow
070° - (nearly banana)
080° - (lime)
090° - (spring onion)
100° - (or maybe this one)
110° - (that's the noted problem with greens)
120° - Green
130° - (miles and miles of bloody* green!)
140° - (bluegrass?)
150° - (a certain kind of tropical atoll sea-green)
160° - (not green, temptwd to say 'early cyan')
170° - (sky blue)
180° - Cyan
190° - (horizon blue)
200° - (air-forcey)
210° - Azure (mucky light-blue watercolour?) (7F instead of 80!)
220° - (overdiluted dark-blue watercolour wash)
230° - (royal blue?) (2B instead of 2A!)
240° - Blue
250° - (???)
260° - (mauvine?)
270° - (fuchsia bud) (the darker centre to the fuchsia flower's petals)
(275°ish - a bright version of Indigo)
280° - (a planty purple)
290° - (fushcia!)
300° - Magenta (or an unoversaturated version of Violet)
310° - (some kind of pink)
320° - (fresh guts)
330° - (I want to say 'hernia', but I don't know why)
340° - (suppressed pink)
350° - (near as damnit red)
360° - Red again!

I tried to work Lavender in, but its distance from the optimal saturation was just awkward.

Regarding colour-models, the colour picker (with which I converted HSV coordinates to RGB ones) disagreed over 2A/2B hex values at 120° degrees points around the circle, and 7F vs 80 at different trifurcated vectorings. I can't be bothered to look whether that might be rounding errors, or model adjustment.

Maybe doing it with chromosensitivity altering the saturations, the Indigo in ROYGBI will be markedly spiralled in?

* - Vulcan, obviously

User avatar
Pfhorrest
Posts: 3898
Joined: Fri Oct 30, 2009 6:11 am UTC
Contact:

Re: 1882: "Color Models"

Postby Pfhorrest » Thu Sep 07, 2017 3:54 pm UTC

Might've been better to work in increments of 15° as that would give you all the quaternary colors.

There's a bunch of names for ternary colors you have on the list that you could've used too:
30 Orange you have
90 is Chartreuse
150 is Spring (Green)
210 Azure you have
270 is Violet (as far as color wheels go at least)
330 is Rose

Also, I'll just leave this little toy I made a while back here if anyone finds it amusing:

http://geekofalltrades.org/_misc/colors/index.php
Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
The Codex Quaerendae (my philosophy) - The Chronicles of Quelouva (my fiction)

User avatar
da Doctah
Posts: 803
Joined: Fri Feb 03, 2012 6:27 am UTC

Re: 1882: "Color Models"

Postby da Doctah » Thu Sep 07, 2017 5:39 pm UTC

Pfhorrest wrote:There's a bunch of names for ternary colors you have on the list that you could've used too:
30 Orange you have
90 is Chartreuse
150 is Spring (Green)
210 Azure you have
270 is Violet (as far as color wheels go at least)
330 is Rose


Most of those aren't colors, they're other things that at least tend to have characteristic colors: orange is a fruit, chartreuse is a liqueur, azure is a rock. Most of the others (as is typical) are flowers.

User avatar
Pfhorrest
Posts: 3898
Joined: Fri Oct 30, 2009 6:11 am UTC
Contact:

Re: 1882: "Color Models"

Postby Pfhorrest » Thu Sep 07, 2017 5:52 pm UTC

Be that as it may, those are the standardized names for those colors.
Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
The Codex Quaerendae (my philosophy) - The Chronicles of Quelouva (my fiction)

Mikeski
Posts: 869
Joined: Sun Jan 13, 2008 7:24 am UTC
Location: Minnesota, USA

Re: 1882: "Color Models"

Postby Mikeski » Thu Sep 07, 2017 9:28 pm UTC

da Doctah wrote:chartreuse is a liqueur

Two liqueurs: Green Chartreuse and Yellow Chartreuse. Per wikipedia, the color is named for the green one.

So a color is named for something that requires a different color's name as a descriptor.

User avatar
da Doctah
Posts: 803
Joined: Fri Feb 03, 2012 6:27 am UTC

Re: 1882: "Color Models"

Postby da Doctah » Thu Sep 07, 2017 10:47 pm UTC

Mikeski wrote:
da Doctah wrote:chartreuse is a liqueur

Two liqueurs: Green Chartreuse and Yellow Chartreuse. Per wikipedia, the color is named for the green one.

So a color is named for something that requires a different color's name as a descriptor.


In how many colors is Midori made?

User avatar
gmalivuk
GNU Terry Pratchett
Posts: 25783
Joined: Wed Feb 28, 2007 6:02 pm UTC
Location: Here and There
Contact:

Re: 1882: "Color Models"

Postby gmalivuk » Fri Sep 08, 2017 12:16 am UTC

Pfhorrest wrote:It should really be ROY G CAB is you want a properly-balanced spectrum by modern color theory. Hue angles 0, 30, 60, 120, 180, 210, and 240; red, orange, yellow, green, cyan, azure, blue.
Hue angles correspond to how our eyes see color, not to the spectrum.
Unless stated otherwise, I do not care whether a statement, by itself, constitutes a persuasive political argument. I care whether it's true.
---
If this post has math that doesn't work for you, use TeX the World for Firefox or Chrome

(he/him/his)

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Thu Sep 21, 2017 5:05 pm UTC

I am a against-color-profiles camp person. They are somewhat fine for screen calibration maybe but I am against attaching color profile to video/image files unless the image file is going into print and not for any other purpose.

Just like dictating one single device-pixel-perfect web layout is wrong as it disregards people are viewing in various screen size and shape (and dpi's and viewing distances), dictating an absolute physical color to the viewers is also wrong. Screen colors are never absolute physically. Some people like their screen brighter, some like it to be darker; some like the color more saturated and some like less. So any color specified in a file can only be a relative spot within the color space of display devices. Forcing absolute values makes no sense at all.

Even the gamma curve dictation is wrong too. Some may like dark-but-exactly-black to look black if their screens can't show their difference, some may like to squeeze/stretch things a bit so that dark details and white details (for the white-but-not-exactly-white case) look clearer in their poor screens for their poor eyes.

If a web-friendly file format must put in color profile, it should at least set "follow however the browser screen want to decode #abcdef in whichever devices" the default color profile, and then mandate it to all such file editor program to save that way by default.

User avatar
J the Ninja
Posts: 716
Joined: Tue Dec 30, 2008 9:08 pm UTC
Location: Portland, USA
Contact:

Re: 1882: "Color Models"

Postby J the Ninja » Fri Sep 22, 2017 6:37 pm UTC

billyswong wrote:I am a against-color-profiles camp person. They are somewhat fine for screen calibration maybe but I am against attaching color profile to video/image files unless the image file is going into print and not for any other purpose.

Just like dictating one single device-pixel-perfect web layout is wrong as it disregards people are viewing in various screen size and shape (and dpi's and viewing distances), dictating an absolute physical color to the viewers is also wrong. Screen colors are never absolute physically. Some people like their screen brighter, some like it to be darker; some like the color more saturated and some like less. So any color specified in a file can only be a relative spot within the color space of display devices. Forcing absolute values makes no sense at all.

Even the gamma curve dictation is wrong too. Some may like dark-but-exactly-black to look black if their screens can't show their difference, some may like to squeeze/stretch things a bit so that dark details and white details (for the white-but-not-exactly-white case) look clearer in their poor screens for their poor eyes.

If a web-friendly file format must put in color profile, it should at least set "follow however the browser screen want to decode #abcdef in whichever devices" the default color profile, and then mandate it to all such file editor program to save that way by default.


If you want to apply additional transforms on top of the baseline colors, go right ahead. That’s no reason not to still tag what they are supposed to be. If anything, that gives you a consistent base to start with. Without a color profile, telling a computer “decode #abcdef” is as meaningless as going into a paint store and insisting that you want “full red” and refusing to elaborate on that.
Shishichi wrote:Applies a sexward force to counter the sexpression effect that Forward Advection can apply to fluid density, particularly along sextainer boundaries. In this way, the sextribute attempts to conserve the overall fluid volume ensuring no density loss.
(he/him/his)

User avatar
Soupspoon
You have done something you shouldn't. Or are about to.
Posts: 2467
Joined: Thu Jan 28, 2016 7:00 pm UTC
Location: 53-1

Re: 1882: "Color Models"

Postby Soupspoon » Fri Sep 22, 2017 7:06 pm UTC

Yeah, but #abcdef is a pale bluish/cyanish colour, not full red by any measure...

;)

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Sat Sep 23, 2017 3:04 am UTC

J the Ninja wrote:
billyswong wrote:I am a against-color-profiles camp person. They are somewhat fine for screen calibration maybe but I am against attaching color profile to video/image files unless the image file is going into print and not for any other purpose.

Just like dictating one single device-pixel-perfect web layout is wrong as it disregards people are viewing in various screen size and shape (and dpi's and viewing distances), dictating an absolute physical color to the viewers is also wrong. Screen colors are never absolute physically. Some people like their screen brighter, some like it to be darker; some like the color more saturated and some like less. So any color specified in a file can only be a relative spot within the color space of display devices. Forcing absolute values makes no sense at all.

Even the gamma curve dictation is wrong too. Some may like dark-but-exactly-black to look black if their screens can't show their difference, some may like to squeeze/stretch things a bit so that dark details and white details (for the white-but-not-exactly-white case) look clearer in their poor screens for their poor eyes.

If a web-friendly file format must put in color profile, it should at least set "follow however the browser screen want to decode #abcdef in whichever devices" the default color profile, and then mandate it to all such file editor program to save that way by default.


If you want to apply additional transforms on top of the baseline colors, go right ahead. That’s no reason not to still tag what they are supposed to be. If anything, that gives you a consistent base to start with. Without a color profile, telling a computer “decode #abcdef” is as meaningless as going into a paint store and insisting that you want “full red” and refusing to elaborate on that.

It has always been this "meaningless" in reality. Owner of the monitor/computer decide how red a "full red / #ff0000" is his/her monitor. If one's screen set the maximum brightness to be below the range of your color profile embed in file, A sane person will expect a light gray in your file to be displayed dimmer than his maximum white, not the other way around nor a forced plateau until a not-so-light gray.

Stop refusing to face the difference of painting/printing and screen/monitor. (In the case of projector, "full black / #000000" is often just a dark gray since most room don't go totally dark when using the projector. The projector manufacturer can't even embed a meaningful color-profile in their product to satisfy you guys' wants.)

I will even rather say .png files supporting color profile embed is a flaw, as it give artists false hope that they can exercise their control-freak madness. HTML, if you really want to insist one, say they use sRGB color space in the spec, but almost all non-artists rationally expect if they tune their screen to be more color-saturated than sRGB, a webpage will look more color-saturated than sRGB.

User avatar
Steve the Pocket
Posts: 644
Joined: Mon Apr 23, 2007 4:02 am UTC
Location: Going downtuuu in a Luleelurah!

Re: 1882: "Color Models"

Postby Steve the Pocket » Sat Sep 23, 2017 4:15 pm UTC

I think the problem with embedded color profiles is that what they're designed to do and what they actually do are two completely different things. Their purpose is to override the limitations of the monitor. But they don't. In fact, most of the time they do the exact opposite. If I've adjusted my monitor so the desktop wallpaper and icons and other UI elements look right, images with embedded profiles are almost invariably going to look wrong, and vice versa. I'm sure in artists' wildest fantasies, I'd be able to open up a window with an sRGB-encoded PNG inside, and fiddle with the settings on my monitor to my heart's content—brightness, contrast, color balance, whatever—and everything behind the window will change but the contents of the window will not. Same with enabling things like f.Lux or Night Mode. But the world doesn't work that way, and I'm pretty sure it shouldn't, for the same reason that I don't want the paint on my walls to magically stay the exact same color and brightness regardless of whether I have the lights on or not.
cephalopod9 wrote:Only on Xkcd can you start a topic involving Hitler and people spend the better part of half a dozen pages arguing about the quality of Operating Systems.

Baige.

speising
Posts: 2066
Joined: Mon Sep 03, 2012 4:54 pm UTC
Location: wien

Re: 1882: "Color Models"

Postby speising » Sat Sep 23, 2017 8:18 pm UTC

No, the purpose of a color profile is to define specific colors. A coordinate is useless without a coordinate system.

User avatar
J the Ninja
Posts: 716
Joined: Tue Dec 30, 2008 9:08 pm UTC
Location: Portland, USA
Contact:

Re: 1882: "Color Models"

Postby J the Ninja » Sun Sep 24, 2017 9:00 pm UTC

Steve the Pocket wrote:I think the problem with embedded color profiles is that what they're designed to do and what they actually do are two completely different things. Their purpose is to override the limitations of the monitor. But they don't. In fact, most of the time they do the exact opposite. If I've adjusted my monitor so the desktop wallpaper and icons and other UI elements look right, images with embedded profiles are almost invariably going to look wrong, and vice versa


That's because your operating system has a shitty color management implementation. In a world where color profiles work as intended, your wallpaper and icons and other UI elements will all have been color managed as well, so EVERYTHING is transformed from the space they were authored in to your monitor space. If you prefer, you can just define "monitor space" as sRGB (this is the default anyway) then make your adjustments on top of that. Not only do you still get your adjustments, but they are now CONSISTENT because all items have been converted to the same starting space.

I'm sure in artists' wildest fantasies, I'd be able to open up a window with an sRGB-encoded PNG inside, and fiddle with the settings on my monitor to my heart's content—brightness, contrast, color balance, whatever—and everything behind the window will change but the contents of the window will not. Same with enabling things like f.Lux or Night Mode. But the world doesn't work that way, and I'm pretty sure it shouldn't, for the same reason that I don't want the paint on my walls to magically stay the exact same color and brightness regardless of whether I have the lights on or not.


No, f.lux is SUPPOSED to override the profile! You get everything consistently in sRGB, then skew the white point on top of that. That's the entire point! You are not supposed to have non-managed items to being with! This is where almost all the complaints about color management come from: people trying to find workarounds for software that implements it badly or not at all, then they get angry when their workarounds fail with software that does it correctly. I understand that's annoying sometimes, but ignoring color management is not going to ever solve this.

In fact, as HDR and wider color spaces such as DCI P3 get more mainstream, this is going to get a lot worse. Up until now, most monitors (aside from some high-end content creation displays) were ostensibly trying to be sRGB displays, and almost all desktop content as authored to be viewed on an sRGB display. Once you're in HDR-land, neither of those assumptions holds anymore. You're never going to get consistent color saturation if you have a mix of P3 and sRGB elements going into your screen and are making zero effort to try make them all consistent before pushing them to the display.


_____


billyswong wrote:It has always been this "meaningless" in reality. Owner of the monitor/computer decide how red a "full red / #ff0000" is his/her monitor. If one's screen set the maximum brightness to be below the range of your color profile embed in file, A sane person will expect a light gray in your file to be displayed dimmer than his maximum white, not the other way around nor a forced plateau until a not-so-light gray.

Stop refusing to face the difference of painting/printing and screen/monitor. (In the case of projector, "full black / #000000" is often just a dark gray since most room don't go totally dark when using the projector. The projector manufacturer can't even embed a meaningful color-profile in their product to satisfy you guys' wants.)

I will even rather say .png files supporting color profile embed is a flaw, as it give artists false hope that they can exercise their control-freak madness. HTML, if you really want to insist one, say they use sRGB color space in the spec, but almost all non-artists rationally expect if they tune their screen to be more color-saturated than sRGB, a webpage will look more color-saturated than sRGB.


Ok, great. So you've adjusted your monitor so full green (let's use float colors for the sake of clarity here, and say G=1.0) is a shade of green you enjoy. Now, you have two images of a green forest, one in sRGB and one in ProPhoto. Which should give your chosen green? If you just pick one particular space, chances are you'll perceive the saturation as being fucked up on the other one. The only way to make it so both give your chosen green is to tag what space they were in, convert them to the space you were looking at when you chose that "favorite green" and THEN feed them to your monitor. If you like being accurate to what the content creator intended, you can calibrate so "chosen green" actually is sRGB green. If you like some other green, you can add that on top of the profile (as noted in my other reply, the easiest way to do that is usually to set the monitor space as being sRGB in software, then adjust green within the monitor OSD settings)
Shishichi wrote:Applies a sexward force to counter the sexpression effect that Forward Advection can apply to fluid density, particularly along sextainer boundaries. In this way, the sextribute attempts to conserve the overall fluid volume ensuring no density loss.
(he/him/his)

User avatar
Xanthir
My HERO!!!
Posts: 5212
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: 1882: "Color Models"

Postby Xanthir » Mon Sep 25, 2017 6:31 pm UTC

Jumping to browsers for a moment, it's actually CSS that says everything is sRGB by default. spec Images are meant to respect their embedded profile if specified; otherwise we assume the colors are in sRGB.

J is right in all the details - color management has been such a shitshow for so long that people have done all sorts of hacks and workarounds, and then gotten angry at programs that are actually managing color correctly. We recently dodged a bullet with Chrome/Linux on some Gnome platforms, precisely because of complaints about color management due to people working around bad stuff. Luckily we were able to convince each other that the Eye Of Gnome program is correctly color-managed, and we're okay with matching that and just telling people to fix their shit when they complain. ^_^
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
Reka
Posts: 147
Joined: Thu Sep 20, 2012 10:21 pm UTC

Re: 1882: "Color Models"

Postby Reka » Tue Sep 26, 2017 10:21 pm UTC

ucim wrote:Does anybody remember Front Page?

(slinks out)

My work here is done.

Jose

I use FrontPage every day. I'm not sure what your point is.

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Wed Sep 27, 2017 6:15 pm UTC

Xanthir wrote:Jumping to browsers for a moment, it's actually CSS that says everything is sRGB by default. spec Images are meant to respect their embedded profile if specified; otherwise we assume the colors are in sRGB.

J is right in all the details - color management has been such a shitshow for so long that people have done all sorts of hacks and workarounds, and then gotten angry at programs that are actually managing color correctly. We recently dodged a bullet with Chrome/Linux on some Gnome platforms, precisely because of complaints about color management due to people working around bad stuff. Luckily we were able to convince each other that the Eye Of Gnome program is correctly color-managed, and we're okay with matching that and just telling people to fix their shit when they complain. ^_^

I don't think J is right in all the details... even if color management being shitish is merely an implementation issue, OS is not the major criminal here. It is hardware limitation. Computer screen signal was transmitted in analog 0.0 to 1.0 at first and a fixed 8-bit/color granularity later in DVI cable. There is no way for a traditional screen to display 2 photos side by side, with one in no-color-profile/default-virtual-sRGB and another one in HDR wide-gamut "correctly". 8-bit granularity is not suitable for wide-gamut anyway.

J the Ninja wrote:Ok, great. So you've adjusted your monitor so full green (let's use float colors for the sake of clarity here, and say G=1.0) is a shade of green you enjoy. Now, you have two images of a green forest, one in sRGB and one in ProPhoto. Which should give your chosen green? If you just pick one particular space, chances are you'll perceive the saturation as being fucked up on the other one. The only way to make it so both give your chosen green is to tag what space they were in, convert them to the space you were looking at when you chose that "favorite green" and THEN feed them to your monitor. If you like being accurate to what the content creator intended, you can calibrate so "chosen green" actually is sRGB green. If you like some other green, you can add that on top of the profile (as noted in my other reply, the easiest way to do that is usually to set the monitor space as being sRGB in software, then adjust green within the monitor OSD settings)

Let say a monitor is set to show the brightest green it can physically afford for the traditional no-color-profile/default-virtual-sRGB forest picture, which is set as wallpaper. When one open your ProPhoto forest picture, how should the monitor respond? Suddenly the wallpaper go dull to make your ProPhoto picture greener in comparison? Plateau your ProPhoto green from very-green to not-so-green all as 100% green of the monitor?

Now let say the monitor is set to be a lot dimmer then it maximal brightness (as the jPad user may be using it in bed at night). Your ProPhoto HDR forest picture included a super shiny sun. When the user open your file, how should the monitor respond? Tune everything else to be lower contrast? Scale up the super white (as this time the monitor is capable now) and risk blinding the user's eyes in surprise?

User avatar
Xanthir
My HERO!!!
Posts: 5212
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: 1882: "Color Models"

Postby Xanthir » Wed Sep 27, 2017 9:55 pm UTC

billyswong wrote:
Xanthir wrote:Jumping to browsers for a moment, it's actually CSS that says everything is sRGB by default. spec Images are meant to respect their embedded profile if specified; otherwise we assume the colors are in sRGB.

J is right in all the details - color management has been such a shitshow for so long that people have done all sorts of hacks and workarounds, and then gotten angry at programs that are actually managing color correctly. We recently dodged a bullet with Chrome/Linux on some Gnome platforms, precisely because of complaints about color management due to people working around bad stuff. Luckily we were able to convince each other that the Eye Of Gnome program is correctly color-managed, and we're okay with matching that and just telling people to fix their shit when they complain. ^_^

I don't think J is right in all the details... even if color management being shitish is merely an implementation issue, OS is not the major criminal here. It is hardware limitation. Computer screen signal was transmitted in analog 0.0 to 1.0 at first and a fixed 8-bit/color granularity later in DVI cable. There is no way for a traditional screen to display 2 photos side by side, with one in no-color-profile/default-virtual-sRGB and another one in HDR wide-gamut "correctly". 8-bit granularity is not suitable for wide-gamut anyway.

You're correct in the last sentence; you're wrong in the preceding part of the paragraph. There's nothing preventing displaying both a wide-gamut and sRGB image at the same time. Handling wide color spaces well does require more than 8 bits, and doing that in a way that preserves performance and doesn't blow out memory usage is A Hard Problem (I've spent quite a bit of time talking with our implementors at Chrome about this exact subject...). But if you're okay with more bits per channel, then mixing color spaces Just Works and everything's fine, assuming everybody's handling spaces correctly and the hardware is calibrated correctly.

Let say a monitor is set to show the brightest green it can physically afford for the traditional no-color-profile/default-virtual-sRGB forest picture, which is set as wallpaper. When one open your ProPhoto forest picture, how should the monitor respond? Suddenly the wallpaper go dull to make your ProPhoto picture greener in comparison? Plateau your ProPhoto green from very-green to not-so-green all as 100% green of the monitor?

Now let say the monitor is set to be a lot dimmer then it maximal brightness (as the jPad user may be using it in bed at night). Your ProPhoto HDR forest picture included a super shiny sun. When the user open your file, how should the monitor respond? Tune everything else to be lower contrast? Scale up the super white (as this time the monitor is capable now) and risk blinding the user's eyes in surprise?

You're trying to display an out-of-gamut color for your monitor's current configuration. There are several methods of handling this, all shitty in their own ways, but they're at least standardized. (The "plateau" method is one of them.)

This isn't the fault of color spaces.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Thu Sep 28, 2017 1:46 am UTC

Aha Xanthir we are getting on the same page nearly now. Where is the amazing monitor that can handle both right, traditional desktop defined in virtual sRGB and wide-gamut HDR files, simultaneously? When you wrote "this isn't the fault of color spaces", it is similar to marxists saying "this isn't the fault of communism" when all communist countries in history look like some sort of authoritarian hell until they give up communism.

EDIT: I wrote "virtual sRGB" because monitors sold nowadays don't implement sRGB by default. If one want #ffffff white in a non HDR color profile to represent a typical paper white, then monitors need to build in a tri-color light sensor to dynamically tune itself in accordance to the ambient environment. If non HDR color profiles actually assume #ffffff white as some absolute luminescence, then implementing a monitor to always follow any standard color profile will be against consumers' interest, as one will want the monitor set to be brighter for outdoor sunny day and darker at night or indoor.

Kit.
Posts: 1020
Joined: Thu Jun 16, 2011 5:14 pm UTC

Re: 1882: "Color Models"

Postby Kit. » Fri Sep 29, 2017 10:20 am UTC

billyswong wrote:Aha Xanthir we are getting on the same page nearly now. Where is the amazing monitor that can handle both right, traditional desktop defined in virtual sRGB and wide-gamut HDR files, simultaneously? When you wrote "this isn't the fault of color spaces", it is similar to marxists saying "this isn't the fault of communism" when all communist countries in history look like some sort of authoritarian hell until they give up communism.

So, am I a marxist if I say that monitors are not supposed to handle files, and that desktops and files are suposed to have already been converted into the same color space at the videocard output layer?

As to the gamma... you might like to check this.

x7eggert
Posts: 72
Joined: Tue May 13, 2014 6:55 pm UTC

Re: 1882: "Color Models"

Postby x7eggert » Fri Sep 29, 2017 5:30 pm UTC

billyswong wrote:Aha Xanthir we are getting on the same page nearly now. Where is the amazing monitor that can handle both right, traditional desktop defined in virtual sRGB and wide-gamut HDR files, simultaneously?


It's the OS' task to transform sRGB and HDR to "that's what I need to send to the monitor in order to make it display everything correctly". To achieve that, you need to create a constant environment and calibrate your screen.

OTOH, nowadays most designers will say F' that and put dark gray text on medium gray background for me to read.


PS, putting color profiles into graphics make sense if you just adjust the color curves from one source (instead of repeatedly mapping a range of colors to one value). E.g. Your scanner might give you 8 bit, but if you'd map it to sRGB, you get 192 colors. Putting a color profile would give you 256 colors and by using a graphics editor, you would be able to see them all and apply a different color curve. OK, it would make sense if common graphics editors implemented that.

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Sat Sep 30, 2017 6:25 am UTC

Kit. wrote:
billyswong wrote:Aha Xanthir we are getting on the same page nearly now. Where is the amazing monitor that can handle both right, traditional desktop defined in virtual sRGB and wide-gamut HDR files, simultaneously? When you wrote "this isn't the fault of color spaces", it is similar to marxists saying "this isn't the fault of communism" when all communist countries in history look like some sort of authoritarian hell until they give up communism.

So, am I a marxist if I say that monitors are not supposed to handle files, and that desktops and files are suposed to have already been converted into the same color space at the videocard output layer?

As to the gamma... you might like to check this.

Thanks to sRGB spec being written for CRT monitors and what we have today are almost always LCD monitors, the concept of safe color space has become a failed dream. We have to choose between either getting some colors clipped, de-saturate the whole scene, or pretend the LCD works as "sRGB" and let the colors shift.

Speaking of gamma, I have nothing against gamma curve itself. A 16-bit per channel image file will want to encode things in linear gamma and the gamma of course ought to be written within the file.

Kit.
Posts: 1020
Joined: Thu Jun 16, 2011 5:14 pm UTC

Re: 1882: "Color Models"

Postby Kit. » Mon Oct 02, 2017 10:50 am UTC

billyswong wrote:Thanks to sRGB spec being written for CRT monitors and what we have today are almost always LCD monitors, the concept of safe color space has become a failed dream.

This site requires JavaScript for no apparent reason.

sRGB has never been "safe". It was too broad for cheap consumer-grade CRTs and too inadequate for prepress.

billyswong wrote:We have to choose between either getting some colors clipped, de-saturate the whole scene, or pretend the LCD works as "sRGB" and let the colors shift.

Incompatibilities of color gamuts of different devices cannot be and aren't solved by a "standard" color space, that's what render intents are for. And yes, it is possible to use different render intents together when rendering "desktops" and wide-gamut graphics onto the same surface of the output device.

But for that, you need your sources to be color profiled.

billyswong wrote:Speaking of gamma, I have nothing against gamma curve itself. A 16-bit per channel image file will want to encode things in linear gamma and the gamma of course ought to be written within the file.

The main problem with "linear gamma" is that linear operations on linearly encoded light intensity values do not look "linear" to a human eye. They introduce unintended visible artifacts.

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Mon Oct 02, 2017 4:10 pm UTC

Kit. wrote:
billyswong wrote:Speaking of gamma, I have nothing against gamma curve itself. A 16-bit per channel image file will want to encode things in linear gamma and the gamma of course ought to be written within the file.

The main problem with "linear gamma" is that linear operations on linearly encoded light intensity values do not look "linear" to a human eye. They introduce unintended visible artifacts.

Wait! Your own link earlier just showed me these
Image Image,
illustrating how doing gradient without converting to linear gamma first lead to incorrect blending. The tradition of encoding photos in non-linear gamma is all about fitting in CRT monitors' native behaviour (which help when computers are a lot less powerful than today) and linear 8-bit encoding being not enough for representing dark regions properly. In fact, OpenEXR, an image format designed for HDR, store each channel in 16-bit float linearly.

Kit. wrote:
billyswong wrote:Thanks to sRGB spec being written for CRT monitors and what we have today are almost always LCD monitors, the concept of safe color space has become a failed dream.

This site requires JavaScript for no apparent reason.

sRGB has never been "safe". It was too broad for cheap consumer-grade CRTs and too inadequate for prepress.

Hmmm I am quite sure sRGB is designed for CRT monitors. No way could it be too broad. In the original proposal (http://www.ami.imaging.org/site/PDFS/Pa ... 9/2233.pdf), Microsoft and HP were very confident that "Most computer monitors are similar in their key color characteristics—the phosphor chromaticities (primaries) and transfer function". By design all CRT monitors should be able to calibrate to sRGB.

I double checked the site I linked. It uses Javascript for jquery. Some of the graphs in webpage auto-round-robin or swap-when-hover.

Kit. wrote:
billyswong wrote:We have to choose between either getting some colors clipped, de-saturate the whole scene, or pretend the LCD works as "sRGB" and let the colors shift.

Incompatibilities of color gamuts of different devices cannot be and aren't solved by a "standard" color space, that's what render intents are for. And yes, it is possible to use different render intents together when rendering "desktops" and wide-gamut graphics onto the same surface of the output device.

But for that, you need your sources to be color profiled.

Okay after the whole week of studying so many color space related stuff, I am convinced by you guys to change my stand. But I still disagree with what most files do today - encode a perfect fit color space without also encoding the render intent. As you also agree, there are (now) no "safe" color space for digital/print displays. No monitors nowadays work in sRGB exactly, nor AdobeRGB, nor Rec.2020, nor ProPhoto (which is physically impossible anyway). What we should have done is to assume that all non-color-managed stuff will be rendered using the "full" gamut of the display/printing device in use, while color-managed files should encode both the color space AND the render intent, in effect a formula for how to display/print your file in ANY devices, no matter how narrow/wide gamut they are. Then the viewers' machine can compute from what their devices are capable of to reach an answer on how the color-managed files should be transcoded to printers/monitors.

billyswong
Posts: 41
Joined: Mon Nov 16, 2009 3:56 pm UTC

Re: 1882: "Color Models"

Postby billyswong » Mon Oct 02, 2017 4:30 pm UTC

BTW, I found that ProPhoto RGB is a stupid color space that should not have existed or become this popular. It is not fitting any particular film or digital sensor parameters (else it would have been good for doing white balance stuff). It is not fitting all encodable color to real color (else it would have been a candidate for monitor gamut goal). It is not fitting all real color to encodable color (else it would have been future-proof and fit for long term storage, like ACES2065-1). It is not fitting legacy 8-bit-per-channel file/transmission format (because of the risk of banding). Duh.

User avatar
orthogon
Posts: 2690
Joined: Thu May 17, 2012 7:52 am UTC
Location: The Airy 1830 ellipsoid

Re: 1882: "Color Models"

Postby orthogon » Mon Oct 02, 2017 4:33 pm UTC

billyswong wrote:Wait! Your own link earlier just showed me these


I long since lost any comprehension of what y'all are talking about, but goddammit those zigzag pictures need a trigger warning. I guess one is supposed to be more "correct" than the other, but they both make my eyes hurt, not to mention inducing mild nausea...
xtifr wrote:... and orthogon merely sounds undecided.

User avatar
Pfhorrest
Posts: 3898
Joined: Fri Oct 30, 2009 6:11 am UTC
Contact:

Re: 1882: "Color Models"

Postby Pfhorrest » Mon Oct 02, 2017 6:05 pm UTC

orthogon wrote:goddammit those zigzag pictures need a trigger warning. I guess one is supposed to be more "correct" than the other, but they both make my eyes hurt, not to mention inducing mild nausea...

Not sure if this is hyperbole or not, but if not, can someone explain the psychology/physiology behind this reaction? Because I've never experienced anything quite like that and I can't really wrap my head around it. Is it maybe related to people who have seizures from flashing images?
Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
The Codex Quaerendae (my philosophy) - The Chronicles of Quelouva (my fiction)

User avatar
orthogon
Posts: 2690
Joined: Thu May 17, 2012 7:52 am UTC
Location: The Airy 1830 ellipsoid

Re: 1882: "Color Models"

Postby orthogon » Mon Oct 02, 2017 6:43 pm UTC

Pfhorrest wrote:
orthogon wrote:goddammit those zigzag pictures need a trigger warning. I guess one is supposed to be more "correct" than the other, but they both make my eyes hurt, not to mention inducing mild nausea...

Not sure if this is hyperbole or not, but if not, can someone explain the psychology/physiology behind this reaction? Because I've never experienced anything quite like that and I can't really wrap my head around it. Is it maybe related to people who have seizures from flashing images?

I wasn't being completely serious, but it was nudging into the "uncomfortable" range. However, as I mentioned in the previous thread, I'm not feeling 100% at the moment, so the images probably just aggravated or drew my attention to existing symptoms. Which do you find most surprising? The pain behind the eyes or the nausea? The former feels a bit like the way a bright light hurts, whilst the latter feels a bit like motion sickness, which feels like it arises from the way the highly contrasting colours appear to dance around relative to one another. But, as I say, I think I'm oversensitive to everything right now.
xtifr wrote:... and orthogon merely sounds undecided.

Kit.
Posts: 1020
Joined: Thu Jun 16, 2011 5:14 pm UTC

Re: 1882: "Color Models"

Postby Kit. » Thu Oct 05, 2017 7:51 pm UTC

billyswong wrote:
Kit. wrote:The main problem with "linear gamma" is that linear operations on linearly encoded light intensity values do not look "linear" to a human eye. They introduce unintended visible artifacts.

Wait! Your own link earlier just showed me these

Yes, you are correct here. I was thinking about something else: about perceived non-linearity of linear gradients.

Kit. wrote:
billyswong wrote:sRGB has never been "safe". It was too broad for cheap consumer-grade CRTs and too inadequate for prepress.

Hmmm I am quite sure sRGB is designed for CRT monitors. No way could it be too broad.

It is designed for monitor phosphors (although even then sRGB, P22 and Trinitron have slightly different primaries). However, due to several different effects (from electron backscattering to miscompensation of Earth's magnetic field) the electrons in cheap or untuned monitors might be partly hitting the "wrong" phosphors, reducing the color gamut.

Kit. wrote:Okay after the whole week of studying so many color space related stuff, I am convinced by you guys to change my stand. But I still disagree with what most files do today - encode a perfect fit color space without also encoding the render intent.

If these are input files, that's fine: the recording device does not know your intent.

Kit. wrote:What we should have done is to assume that all non-color-managed stuff will be rendered using the "full" gamut of the display/printing device in use, while color-managed files should encode both the color space AND the render intent, in effect a formula for how to display/print your file in ANY devices, no matter how narrow/wide gamut they are.

If you are at the output stage of your workflow, yes.

However, if you, for example, are working with raw 3-CCD input, it would be foolish to assume that it would match the color profile of whatever device someone will use to display this image later.

billyswong wrote:BTW, I found that ProPhoto RGB is a stupid color space that should not have existed or become this popular. It is not fitting any particular film or digital sensor parameters (else it would have been good for doing white balance stuff). It is not fitting all encodable color to real color (else it would have been a candidate for monitor gamut goal). It is not fitting all real color to encodable color (else it would have been future-proof and fit for long term storage, like ACES2065-1). It is not fitting legacy 8-bit-per-channel file/transmission format (because of the risk of banding). Duh.

It covers all of the Pointer’s gamut (every possible reflective non-luminescent surface color), and is still somewhat acceptable for a 8-bit-per-channel output. And by the way, when it appeared (in about 2000), 8-bit-per-channel wasn't yet "legacy".

pernishus
Posts: 19
Joined: Thu Jan 29, 2015 2:38 pm UTC

Re: 1882: "Color Models"

Postby pernishus » Fri Oct 06, 2017 12:29 pm UTC

Soupspoon wrote:"Richard Of York Gave Cattle In Vain"? Naw. Doesn't work.

:P


Perhaps Richard of York was trying to help out some vegetarians suffering through a famine?

User avatar
Steve the Pocket
Posts: 644
Joined: Mon Apr 23, 2007 4:02 am UTC
Location: Going downtuuu in a Luleelurah!

Re: 1882: "Color Models"

Postby Steve the Pocket » Sun Oct 08, 2017 12:29 am UTC

Soupspoon wrote:"Richard Of York Gave Cattle In Vain"? Naw. Doesn't work.

:P


Could be "gave chase in vain". Actually makes more sense for people who would not consider "gave battle" to be appropriate grammar.
cephalopod9 wrote:Only on Xkcd can you start a topic involving Hitler and people spend the better part of half a dozen pages arguing about the quality of Operating Systems.

Baige.


Return to “Individual XKCD Comic Threads”

Who is online

Users browsing this forum: No registered users and 34 guests