« first day (300 days earlier)      last day (668 days later) » 
08:00 - 21:0021:00 - 00:00

08:12
@troy_s seems like the UI of displaycal has been updated again when moving to 3.2. The main interface seems to be the same, but menus have been rearranged. It does make sense what they did, but causes even more work for you when updating the post :(
 
4 hours later…
12:24
@sambler please show how to remove the icosphere shape mesh from here so I can accept, thanks.
@sambler also please suggest something here - see attached .blend file. I've tried this but I get 50% transparency no matter what I try.
@sambler - ignore 2nd one (about OSL transparency) I've found the little button to check in the render menu. :) Beautiful! But please help getting rid of that icosphere? Also please edit the question so i can change to upvote?
 
2 hours later…
14:56
@aliasguru Hello!
@aliasguru Yes. Florian changes things quite a bit.
@aliasguru I actually shipped him a list of changes for the 3D LUT panel quite a long time ago, as many of the terms and settings were rather strange at the time.
He also added spi3d on my request.
 
4 hours later…
18:45
@troy_s mangling colors after mangling Alpha
@aliasguru Greets sir. How are you?
Let me try to get this slide finished and see what you think.
@troy_s Great, thanks, hope you are fine too!
@troy_s very curious to see it
@aliasguru I'm sort of trying to lay a slide presentation together for something I've been plotting for a "Hitchiker's Guide to Digital Colour" PDF thing.
4
@aliasguru This is sort of a slide show of stuff that was prompted by your discussions around colour management etc. The core foundational principles are identical, so it is worth a small presentation.
@troy_s I've tested the "Apply as a Look" approach in the company today. While it works in terms of how much it is altering intensities and colors, I've noticed that a) the .icc Profile I fed into Photoshop does not provide expected results, and b) very likely I need to do the profiling of the monitors again. Or finally, myself, to see what's going wrong.
@troy_s sounds super cool! Thanks!
@troy_s My suspicion is that especially when generating the .icc files, something went wrong. So before I proceed, I rather do the whole process again, to make sure any further work is not based on half knowledge about the topic before.
@aliasguru Apply as look in Photoshop?
@aliasguru Bear in mind that the whole confusion of the division between calibration (1D curves) and characterization / profiling (3D LUT) can compound your issues. Calibration, if done and embedded in an ICC via the VCGT tag, is 'invisible' to the system as it were, buried in the Video Card.
@aliasguru The Characterization then lives "under" that. If your ICC has both in it, or if you generate a 3D LUT out of an ICC and use both components, you can very quickly end up in a double up nightmare.
18:54
@troy_s Yes, I noticed you state that explicitly on your answer here blender.stackexchange.com/questions/31068/… And I'm pretty sure we DID do the calibration, unlike you suggested in your answer.
Example: You have calibration curves and characterization in the ICC. You "bake" that into the RGB encoded file. Result? If you are on the machine you currently are running the ICC, you end up with both the curves from the calibration baked into it and you already have the curves on the card displayed.
@aliasguru As you can see, it is painfully logical and rather trivially simple to grasp, unless you ignore all of the CM stuff and are pressing magic buttons. (Most default consumer grade stuff is magic button)
@aliasguru I am not against calibration curves, but they should be treated very carefully when you are in a mixed production pipeline.
(for reasons you probably can see now.)
@troy_s That means that Calibration would always be baked into the sRGB values?
@aliasguru If you are applying it as a "look" in Photoshop, I suspect the values end up baked in. I also doubt that you get the granular control that you do with DisplayCAL (that permits you to either put it in or not, up to you)
Ok. Let's try this first run of the first intro part.
@aliasguru Try this goo.gl/slides/m8hg6c
Does that work?
Hrm... need to figure out a way to show the actual slides. LOL
@troy_s I'm in the Q&A session
@troy_s you want to publish it to anyone or share it explicitly?
I just dropped it. Hold on. Looking into Hangouts presentation. Otherwise it is hard for me to control it.
It can be shared as needed really. I'm not quite finished with the hardware section.
19:06
@troy_s That will be awesome!
@GiantCowFilms Got it. Not in chrome oddly. Only via app.
@aliasguru Ok. Let's try this. You have a Hangouts Handle?
@troy_s huh? We have handlebars for motorbikes in the studio, but Hangouts Handles?
@troy_s reminds me of the Eddie Izzard Darth Vader lego video
That letting you see it?
19:11
@troy_s Hangouts Plugin is installed, I propably need to restart the browser
Odd.
back in a minute
@GiantCowFilms Feel free to join it. Interested to hear your thoughts on how I've chosen to forward the basic concepts.
@troy_s do see a slide
Yay. Can you hear me?
I can hear you. LOL.
I hear the music that is.
19:13
@troy_s I don't have audio on my machine activated
Ok. That's fine. Feel free to mute your audio then.
@troy_s My GF is reading :)
Ask a question in the QA just to make sure it works.
Gist of it is that we need to be clear what we are trying to accomplish.
@aliasguru If something isn't clear, ask it in the questions or here. There I get a record.
hold on
@aliasguru Holding.
19:18
@troy_s just asked a sample question to check if it works
Yep. Works. Nice to be able to answer in the goddamn thing.
@troy_s please proceed
LOL
Anyways, you seeing animations on your end?
It should be animating, in presenter view it isn't showing it.
@aliasguru So that is the intro gist for calibration and profiling.
@aliasguru Which is more or less a bit of a revelation for anyone that has been imaging for a long time; not many people understand that the RGB lights are arbitrary.
@aliasguru According to the ICC, those three things I described: Chromaticity of each of the three lights, Chromaticity of the white point (aka achromatic colour), and transfer characteristic is mandatory before you can utter the much confused term colour space
@troy_s when you say "we don't know what color an RGB triplet is", are you referring to the display hardware limitations?
If you have three values, you don't have any of those.
@aliasguru Given any RGB triplet, alone, no matter how precise (135.18348447436 for example), you simply don't know what it means.
Clear?
If we know we have an sRGB display, we know several things immediately:
19:23
ah ok, now I get the message
t is "sRGB" which typically means "very close to the specification. What does this mean though?:
1) We know that the lights are 709 lights for red, green, and blue.
2) We know that the white point, if it is a quality display, should match the specification. That means that the "achromatic" value (R=G=B) should be the colour that matches D65 (there is some nuance here, but later)
3) We know that the intensity curve should be damn close to sRGB. (In practice, most displays are a flat power function 2.2 due to likely cost issues. Again, the proper sRGB transfer characteristic is a two part function, with a linear toe.)
When we say then, "I have a wide gamut display", what does it mean?
@aliasguru Your turn. :)
(With an sRGB display, our RGB encoded values take on meaning. It isn't until we identify some critical aspects of the colour space that we can actually give meaning to the encoded values.)
Again, no matter how seductive 124812.1, 838118.12431444, and 9.83858588 look, the bottom line is that those three values alone, with no further metadata, are absolutely meaningless.
@troy_s Well as far as I got it, the Wide Gamut offers a larger range of possible intensities and colors, even values outside the sRGB spec.
@aliasguru Essentially what Wide Gamut means is nothing.
@troy_s a different transfer function is needed to replicate sRGB on that
@aliasguru All we sort of kind of sort of know is that the three lights at each pixel are very likely quite a different colour from say, 709 lights.
@aliasguru Possibly. In the case of Apple's newer P3 displays, the transfer function is in fact identical to sRGB's EOTF.
@aliasguru The key point to take note of is that at the core, the lights are different at each pixel.
That means that we don't really know what the hell it is doing until we put a colorimeter or spectro on it.
And that also leads to a very powerful observation:
@aliasguru What happens if you use a viewer to display an sRGB image on a random wider-than-709 gamut display?
What are you seeing when you dump the values to the display?
19:31
@troy_s also human perception is relative
1) The encoded values are displayed as sRGB.
@troy_s :)
2) The encoded values are dumped and you see the display's colour, effectively making the encoded values be interpreted as the display's colour space.
3) You see an sRGB, just more saturated
@troy_s BTW, the guide has to say don't panic on the cover. It will be necessary.
LOL
@GiantCowFilms It's been a remarkably challenging process to try and break it down for a typical imager. I've settled on what I just showed @aliasguru by starting with, ironically, a single light that is 'white'.
@aliasguru What do you think the answer is 1, 2, 3?
19:34
@troy_s 2)
@aliasguru Which of course you get at this point. Now ask... if you render using a wider set of primaries, or your image is encoded as AdobeRGB or ACES or something, and you are viewing on an sRGB display, what are you seeing?
@aliasguru The real test is the following question: If you take that Quato display and properly set up a proper colour managed view transform, and put it directly beside a decent quality and profiled sRGB display, and we display a 709 based render on it, the images shown on both should end up being:
@troy_s I would expect slight to heavy color shifts
1) Very similar, but the Quato wide gamut will have a more saturated appearance.
2) Completely different, the Quato is a wide gamut.
3) Very similar, but the colours will be shifted slightly on the Quato
4) Identical in every way shape and form
@troy_s I'd expect 1) if both are set up correctly
Actual answer is 4
19:37
@troy_s Trouble is, exactly this we didn't manage so far LOL
709 content must be transformed on the Quato. That means that our RGB encoded values are different for the Quato, to emulate / simulate / display 709 lights.
@aliasguru I'd strongly suspect that the issue is purely knowledge.
@troy_s which is done with a View Transform?
If you don't know the expectations, it is very hard to really understand the goal.
@aliasguru In Blender or other 3D LUT based imaging applications, yes. I'd put it on a unique view or even a Look.
@troy_s My first time with a wide gamut, so not sure yet about the possibilities :)
A wide gamut display can only really spread its wings when using RGB encoded data that is designed wide gamut.
That would mean say, rendering in a reference space that uses different lights from sRGB / 709.
Or taking a photo that is not transformed to 709, but rather in some other wider gamut.
19:40
@troy_s So in our case, where we're only targeting print and web. does wide gamut make any sense?
If you think about the basics of the lights - they never change colour, only intensity.
Yes.
Wide gamuts offer a number of advantages even if you are only using small gamut volumes.
For one, you get to see all of that smaller gamut. Many "sRGB" displays aren't able to display the full volume.
@troy_s that's the "I can do 89% of sRGB space" figure DisplayCal gives me?
Second, you can emulate print more accurately. This is challenging because of the limited reflectance of print work compared to display light emission, but the result, if you avoid windows and other UI elements, is that your eye will adapt and you get a pretty good idea of a proof.
@aliasguru Bingo.
Colour is a volume... if you think of it as being a bunch of values in 3D Euclidean space, you can outline the perimeter in an absolute model and compare it to another space.
That complex hull will overlap, exceed, or not quite reach.
@troy_s Now it makes sense that our proofing department uses them
(Think of a 3D mesh that you distort in some way)
@aliasguru Many times there is horrific colour management knowledge at play, so the people go Buy the best damn display we can get!
Then go and view sRGB imagery direct on the mega-gamut display.
You can guess the head slap.
It is one of those cases where without knowledge, the higher quality gear actually hurts you.
19:44
@troy_s We tried that. I like pink.
MacOS is sometimes seen as a magic bullet that insulates you from all of this, but as you have seen with Blender (and Nuke, and Houdini, and a plethora of other applications) it simply cannot.
I call it the triangle of colour critical work... you need hardware, software, and most importantly knowledge.
Again, the basics are deadly simple. It's three lights, a white point, and a transfer curve.
(Essence: When someone says RGB they really aren't telling you anything about the colour space, only the colour encoding model)
Guess what? The same ridiculous crap happens with CMYK.
"How do I convert from my RGB to CMYK?
"Oh use this web app called RGB2CMYK!"
RGB triplet: We have NO clue what red, green, light it is, no clue what white point (really a byproduct of RGB in most instances), and no clue of transfer.
CMYK? Worse!
1) NO clue what each ink colour is.
2) NO clue how the inks combine on the paper.
@troy_s no clue about paper
3) NO clue what paper is at work, and how it results in mixing.
4) NO clue about illuminant.
So when we go from 709 RGB light image, say sRGB encoded, to paper...
@troy_s dont't forget 5) Print Shop has no clue about Color Management themselves
We need to know all of that... oh ... wait there is more!
5) TAC - Total Area Coverage. Ink is liquid. If you saturate the paper with liquid, you destroy things. How much ink you put on it also changes how the resultant colour ends up.
6) BPC - black point compensation. Blacks in many paper formats aren't as rich. If you do a brute force conversion, you can end up with your greyscale ramming into the floor of the black, which is above the floor of the black in RGB. BPC does a nonlinear curve gracefully down to it.
So CMYK is like RGB - utterly stupidly meaningless term.
Idiots preach it.
"I need to have CMYK workflow in my editing application."
Really what they are saying is "I'm a completely clueless donkey"
19:49
You're on a spree :)
Imagine controlling arbitrary ink output for a printer on your display. Think about that.
:)
Anyways, the display situation is very manageable, but only with a good healthy dose of basics, which you now have I'd say.
I'd start with a baby step, maybe trying to get one of the not-quite-colour-critical displays to display reliable sRGB. Some of the LG newer models are very damn good at sRGB specification.
@troy_s Starting with it, confident that some day I'll be illuminated. In sRGB or any other way.
If you do intend to tackle the Quatos, be aware of the wider gamut primary issue with colorimeters. Can be worth it to grab an inexpensive Spectro.
@troy_s Does the i1 allow me to profile it in wide gamut mode? Or should I stick with sRGB emulation?
These are the cheapest spectros you can buy, with the upside of being able to proof paper. bhphotovideo.com/c/product/555132-REG/…
@aliasguru Try it.
@aliasguru That i1 is best in breed in that class.
I would not be surprised if it delivered very acceptable results.
Easiest method is to use a nice test pattern, say 75% bars etc.
Set up a nice clean view transform for each
and do a side by side with say, two or three sRGB displays.
Betting the deviations would be very minor.
In many instances, you have worse deviations because of knowledge gaps.
Also note that many UIs and OSes are crap at wide gamut, so you for example, end up with really crappy dayglo and wrong colours in say, Blender.
(Worth banging on them as I've been harping about colour managing the fscking UI forever, but no one gets it.)
As of right now, in 2016, Apple has a pretty tight handle on the UI side, but many apps don't have it. Qt shits the bed for example.
19:56
@troy_s I'll give it a shot tomorrow, starting with sRGB emulation mode, to see where this is going
@troy_s Who in the Blender community is actually firm at these topics?
@troy_s I mean, from the coders side
@aliasguru Remember that the goal is such that an sRGB image on a pristine sRGB display would end up identical to the other.
@aliasguru Even if in fully wide gamut mode, that test image should end up identical if you have nailed it.
@troy_s Will be a very interesting experiment
@aliasguru Uh... very few. Lukas Stockner seems to be the only folk that I can speak with on it.
@troy_s Andrew Price was also asking a question about the filmic transforms in the Cycles Roadmap presentation
@aliasguru I'd suggest that you try to make sure that you aren't being crippled by things like the OS. For example, is the OS loading some calibration curves? Are they always on? Are they sometimes dropped due to a driver?
@aliasguru I saw that. I'm not much of an evangelist nor proponent. I'd prefer that the passionate imagers that have experience discover it. Every studio peep I've encountered started like this. Typically a "Whoa" email.
20:00
@troy_s That's a topic in itself. So many places to actually mess it up completely.
@aliasguru My goal has always been to help the damn imagers elevate their work, and spend less time fixing broken things.
@aliasguru In my experience, of the two sort of "classes" of imagers, the ones that are most receptive and in fact excited about the view transforms, already have a bunch of experience under their belt. Typically, not surprisingly, they are at a studio or working in a group such as yours.
@troy_s Is there a single application that just does it right?
@aliasguru Those folks get it immediately. They can spot the nuance and all of the bits the concepts bring to the table. Immediately.
@aliasguru Depends what "Right" is. All of the industrial software titles do it properly if you have the knowledge. Resolve, Nuke, Houdini, etc.
The thing is, it doesn't take much to do it right. Boils down to exactly 1 rule: Let go of what you think RGB is.
That extends to:
1) Don't Google on StackExchange for how to convert RGB to [insert whatever other model here]
2) Don't make assumptions about RGB. Cycles has issues in that both the 8 bit textures and internally, the black body for example, assume 709 lights. This breaks Cycles for alternate references.
@troy_s So did Joe when he saw the transforms. For others who were dealing less with hacking the lights, the purpose wasn't that clear. At first they see it as a "ok, it looks different" thing. But the influence it has on lighting decisions is massive.
(Lukas has a patch in the pipe that fixes this)
@aliasguru Huge. Joe probably also would see a huge gain in his work time dedicated to getting things right as opposed to trying to kludge crap.
20:04
@troy_s Would be interesting to see. He nails imagery blazing fast already :)
@aliasguru I'd also add that having grown up with photography, we have learned to read photographic imagery a certain way. That means a gabundle of very nuanced details (see email about the bathroom) that sum up to an overall experience.
@aliasguru Sure. He'd probably notice it on things like paint almost immediately.
Paint is tricky as the glossy layer / under layer / etc.
Having a decent view transform can really help there.
Also, the view transform is actually more helpful to those folks that don't think it is.
Because many of the things they may have been hacking on in compositing come for free.
Have you seen Alex Fry's ACES presentation?
@troy_s not yet
While it is ACES, which is a fully canned protocol with all of this baked in, it is very relevant to all imagers.
There is a part where he discusses Guardians of Ga'hoole, and discussing the levels between the hot sun sky and a white object.
He also demonstrates how imagery falls apart very well.
Anyways, point is, it has a bunch of very interesting elements that are relevant to a proper view transform.
@troy_s so he's also using EXR_linearize? :D
@troy_s One thing that came up today when comping in Nuke was: When to apply the Filmic Transforms in the tree? Only at the very end? At the beginning? Anywhere? In Blender it's at the end, but what if I just want to tune this damn neon orange?
@aliasguru The generic concept stuff starts at around 5:40 youtube.com/watch?v=vKtF2S7WEv0#t=5m40s
@aliasguru View transforms are always at the end.
@aliasguru The ACES protocol, as per HPD (the fellow that designed the OCIO transforms) suggests that manipulations should be done on the scene data.
@aliasguru So if you were doing an animation, I'd suggest that you follow a traditional post production workflow, which would mean to model render light using scene thinking. That is, keep the shots as "scene" with your rough looks in Looks to help aid artists with overall look, but render to what amounts to a "raw photo"
@aliasguru Leave the final finishing grade for grading, long after the whole piece is completed.
As in: Keep your damn looks out of your compositing chain.
Don't mix and match them. Don't bend the compositing to a look.
Save it for a grade. Isolate the process between what is "in camera" and what is "post processing grade"
(It's also time saving.)
@aliasguru Make sense?
So when you are delivering the work, in final, the View transform is always applied at the tail end, baking in the look etc.
20:14
@troy_s makes sense this way.
@aliasguru It might seem like an odd division, but it will save an imager tremendous time and bring better creative choices.
@aliasguru The nature of using View / Looks is that they aren't baked into the data. This frees up the imager to focus on whatever they are doing, without worrying about the look.
Conversely, when you say, jam a bunch of grading nodes into your chain, muddling up what is in the camera scene versus creative look, your encoded values lose meaning.
@troy_s Grading is something we don't really do (yet). Our imagery so far has been in the context of boring studio shot work. Of course, in comp, sometimes you can't help tweaking.
(Part of that is in Alex Fry's presentation.)
@aliasguru Right but even there, grading happens.
Your render would be like a raw photo of the motorbike. The grade should have time allocated strictly to adjusting the saturation / colour / roll offs etc.
If you manage to keep a nice clean division between the scene data and your reference space, versus the grading, you get much for free.
For example, all of your colours are aligned in the the reference. That means you can have full paint set or whatever, constant in the reference.
No tweaking, twiddling, cheating shaders.
@troy_s true, in that sense we actually do something like it. But we're not like "let's try to achieve a certain mood in the scene by grading". It doesn't go that far
(In Alex Fry's presentation, he uses a Color Checker (aka Macbeth) chart as a quickie way to test that his real-world camera encoded values make the transform into the reference space perfectly.)
@aliasguru Except even a "That's a great looking studio motorcycle shot" actually has that grading aspect to it; it's a convention.
So it's there, just not sort of glaringly obvious as "We are now grading."
But you might find that a slight division there can help things.
(or at least, fix situations where your composites are going sideways or sucking up time, where a nice division between the scene and the grade streamlines things.)
Photography can be mixed and matched very easily with proper pipeline concerns.
Etc.
Hilarious.
Google has apparently put two and two together. I am now getting a non-stop barrage of Chrome colour management bug updates.
20:22
@troy_s Now, for me it's relatively easy to get confirmation on thoughts or theories about what profiles and hardware is doing to my colors (or worse: my Alpha). I can ask you. But where did you go when looking for the source of things?
Clearly someone at Google realized what Apple's move to P3 has for implications on their browser. Sad.
@aliasguru I'm embarassed to say this...
@aliasguru First I started with "Oh fuck that thing I just took to broadcast has FRINGING!" or "Oh fuck, what is that nasty ass effect there?"
That starts the rabbit hole dive. Being rather stubborn, and having studied photography / art and design at school, it was logical that I'd dive deeper and not be satisfied with "Just do this in application Y" because well, I was using many tools.
While it started with cross application needs and output, I learned eventually that there are maybe three people that have a clue as to what the hell they are talking about.
I researched things online extensively, which leads to more confusion, because frankly, no one covers the very low basic concepts that make the whole thing so much easier to grasp. I'm convinced it is because no one really steps back to ask "Yo, what are RGB values?" (Hence I typically start there)
So when I started to have enough loose understanding (you start with Nuke's horrible terminology of "sRGB as a colourspace" even though they mean EOTF typically)
@troy_s and there is so much misinformation around
I was able to begin to spot what seemed to be entirely illogical conclusions. Example might be... "Ok I get linear... but I have a spot meter and when I linearize my sRGB image I don't get uh... spot meter values!"
So eventually you finally realize that the essence of your confusion is A) crap some idiot said that was utterly wrong B) a conflating of models.
When I discovered that visual effects world (aka motion picture film production) already had tackled these issues, it became clear who to listen to.
Anyways, who did I ask?
Jeremy Selan (developer of OCIO at the time)
Charles Poynton (he helped me with where the hell the 601 primaries came from. What a nightmare)
And even Mark Fairchild (who is a damn gentleman and a scholar and helped me understand how the hell the original CIE 1931 experiment worked, which was damn mind bending to me until he explained it, graciously.)
Later I discovered Thomas Mansencal, who is a mind numblingly talented imager, in addition to being a colour nerd.
@aliasguru So to answer you, I gave up. I went to the folks that I knew weren't bullshitters.
@aliasguru Even though you have really only been focusing on the subject for a short term, do the following:
Google sRGB vs AdobeRGB
The top two hits at Google, the TOP TWO, are uh...
I dare you to look at the first two images.
@aliasguru Can you see the problem? This is the first paragraph, and the person who is graciously explaining AdobeRGB and sRGB to random internet person, linked via top two hits, is utterly and completely wrong.
@troy_s The image above explains it pretty well. Both images contain only three colors, however, the colors shown in the AdobeRGB scale have more differential between them. This means photos taken in the AdobeRGB color space will have more vibrancy in their colors, whereas sRGB will traditionally have more subtle tones. In situations where you're photographing strong color tones, sRGB may need to dull them out to accommodate, whereas AdobeRGB is able to display those colors with more accuracy.
Then look at his conversion.
OMFG
@aliasguru Right. So tell me what he completely failed to do?
Or understand.
20:34
@troy_s Why should one color space be more vibrant than the other? Or more accurate?
How should those two strips look if the proper transform was applied to them?
exactly the same
@aliasguru (He really doesn't understand the basics.)
@aliasguru Exactly.
@aliasguru IT GETS BETTER
Want to know the most ironic part?
Only if you start randomly converting one to the other, you run into bogus
This is particularly hilarious...
So he chose some red swatches right?
The AdobeRGB specification (rumour / legend has it) was a boo boo
That is, TWO of the THREE lights are identical to 709.
The blue? Identical.
The green is the ONLY light that is different coloured / saturated.
The red?
There's the irony.
The red light in AdobeRGB is identical in colour. Both red and blue are.
20:36
also in intensity mapping?
So that image you picked? Oh... guess what... If you put AdobeRGB next to sRGB, they are identical.
No.
Transfer curve in AdobeRGB is not the same.
Slightly different.
So if I asked "What has a larger gamut, sRGB or 709?"
The answer is that the volume of colours they can represent when mixed, is identical. They differ only in transfer functions.
(which with quantization can lead to a different range of colours. Some rounding might make some mixtures impossible in one compared to the other, but in terms of total volume of the 3D hull, they are identical.)
Going back in my memory, at design school I vagely remember to have been told similar things. I mean, thinks like "AdobeRGB is better than sRGB" and so on
AdobeRGB has a much more saturated green light, so you can express more saturated colours in that mix axis.
sRGB is a standard RGB color space created cooperatively by HP and Microsoft in 1996 for use on monitors, printers and the Internet, and subsequently standardized by the IEC as IEC 61966-2-1:1999. sRGB uses the ITU-R BT.709 primaries, the same as are used in studio monitors and HDTV, and a transfer function (gamma curve) typical of CRTs. This specification allowed sRGB to be directly displayed on typical CRT monitors of the time, a factor which greatly aided its acceptance. Unlike most other RGB color spaces, the sRGB gamma cannot be expressed as a single numerical value. The overall gamma ...
xyY is an absolute color model which is how you and I can communicate colour.
It is a scaled version of XYZ, which is basically a three light model as well.
Difference is, it is absolute.
Note how AdobeRGB lists the following:
Red 0.6400 0.3300
Green 0.2100 0.7100
Blue 0.1500 0.0600
White 0.3127 0.3290
sRGBx 0.6400 0.3000 0.1500 0.3127
y 0.3300 0.6000 0.0600 0.3290
Y 0.2126 0.7152 0.0722 1.0000
See 0.64, 0.33 for red on both? Identical colours.
blue? 0.15, 0.06
Identical.
That tells us that two of the three lights in the encoding are identical. If we only had two lights, those two lights would be able to mix along the red-blue axis with identical colour gamuts.
Humpf Honestly, couldn't read these diagrams or values without your explanations (yet)
Only the Green is a different colour - AdobeRGB green is located at 0.21 / 0.71, while sRGB's is .3/0.6
There's a book marked bit here for you to read if you want to understand XYZ. Let me find it.
(again, not hard if you understand the basics)
@aliasguru I'm happy I bookmarked it to save me the explanation. Complete with questions! chat.stackexchange.com/transcript/34814?m=32098701#32098701
XYZ is a very easy thing to grasp if you understand how they tested it.
What you end up with is a meaningful way to discuss colour. If you and I say xy coordinates, it means exactly one precise colour.
xy is scaled XYZ, which means that no matter how infinite XYZ could extend out, xy ends up being a scaled two axis mapping.
@aliasguru I'm reasonably sure that if you read that page of thread, you can understand what that xyY chart means. The triangles are the positions of the lights relative to the other lights. The colour of the chart is just a rough guide, because obviously, you can't really display the colours beyond sRGB on an sRGB display.
@aliasguru What you end up with understanding is that the "red" in R, the "green" in G, and the "blue" in B are the tips of that triangle. That's a precise, absolute map of what colour those lights are and how they relate (linearly!) to other lights.
20:54
@troy_s The z-Axis, so the one we're looking down at, represents intensity?
@aliasguru Frequently you will also see "dots" in the middle of the triangle that represent the position of their convergence (if they abide by R=G=B == "achromatic"). That means that position is the colour of the white.
Exactly.
Down and bent.
(The basis vectors for XYZ are not orthogonal.)
@troy_s never saw this before. Saw a lot of these charts, not making any sense to me. But this gives a better idea (not saying I understood it fully yet)
@aliasguru Focus on how the experiment happened.
They put a swatch in front of the observers, split in half. One half with a colour.
@troy_s with the imaginary colors
"Dial in the colour using our three lights."
Some of the swatches couldn't be matched, so the researchers added some of the complimentary colour light to the swatch colour, reducing the saturation (pulling it towards achromatic)
Then they mixed.
The result is the curves chart.
Plotted as 2D, you see that horseshoe shape.
With Z extending upwards towards us.
The reason it is bent is that Y actually represents luminance.
Not Z.
When the researchers decided to rename the three light model, they picked XYZ, and they added in the unique thing of keeping "visual energy" or "visual luminance" isolated along an axis, which is Y.
So greeny yellowy cyany colours are much more visually luminous than say, reddish, which is still more visually luminous than blueys.
The xyY map (again x and y denoting scaled versions of XY) is a bent and shifted view of the XYZ coordinate system, with the axes flayed and bent to be 90 degrees.
08:00 - 21:0021:00 - 00:00

« first day (300 days earlier)      last day (668 days later) »