Computer Color is Broken - a short video on colors, displays, Photoshop, and blurring
ngon master
[ame]
http://www.youtube.com/watch?v=LKnqECcg6Gw[/ame]
Note: Somethings are a bit too simplified or off to people that are really read up on color space, gamma, linear vs nonlinear, etc.
http://www.youtube.com/watch?v=LKnqECcg6Gw[/ame]Note: Somethings are a bit too simplified or off to people that are really read up on color space, gamma, linear vs nonlinear, etc.
Replies
It's not a gamma setting.
Though interesting thing is if you apply a gamma transform of 2.2 using an exposure adjustment layer it fixes it.
Really everything handled in software should be linear, and all gamma conversions should be on the graphics card. All this baking in gamma curves is horribly convoluted and dumb.
EDIT:
So paintstorm is actually gamma correct. Cool!
I just tried it out and the blending is perfect.
Blur colors without changing luminance?
For the sake of clarity :
Oddly enough, while it seems to work fine for painting ... it doesn't seem to affect the smudge tool (at least in CS5). Can't have everything I guess !
I would't recommend using lab for painting though. Photoshop does all sorts of cheats to make lab seem like it's as intuitive to grasp as rgb by for example, converting your colours to srgb before slotting them into the blending modes(multiply, in lab, is supossed to result into pure blue instead of black).
See if you can get linear 16bit rgb if you have the ram to spare(for Krita they take up 2x the amount of ram, no clue for PS). Working in linear does have it's disadvanatges, as opacity can feel really unwieldy, but the pretty radiometrically correct colours are worth it.
edit: okay, this is really annoying me: Muzz, how exactly are you checking this if you are colour blind? Because I know how I would be checking it, and one of them is mixing screen red with screen blue, if linear pretty magenta purple, if not, muddy dark reddish purple, but I am not sure if that is a method you could rely on(not knowing the specifics of your colourblindness)
But the other methods, namely mixing black with white, and seeing what percentage gray is coming out, is actually somewhat annoying to experience for painters... I am just really curious.
Colour blindness is only really a problem at lower saturation. (i have Moderate Deuteranomaly, or common red/green and blue/purple mixup)
Painting in lab is horrible btw. I agree. It's a mathematial construct designed for the widest colour gamut possible, and is usually used in programming as a transform step.
There is no reason to paint with it.
---
I actually made a tutorial talking about calculating luminance values for painters, and how it isn't a linear thing.
http://muzzfayce.tumblr.com/post/101657302329/the-shading-algorithm-for-painters-lighting-technical
One of the major hurdles to this sort of teaching though is gamma. As a painter, if i want to be technically correct, i need to apply gamma transforms to the elements in the image that im using the math on. Because everything else in the image as far as i understand is actually in gamma space in Photoshop already.
Then again this is all nit picky stuff, and to improve it, i doubt many people would conciously notice, though their experience would be slightly nicer.
Oh, btw Muzz, and anyone else reading the thread. The sRGB TRC is not baked into the calculations or even the file for that matter. It's used in the interpretation of the colours. So if you have any given image in sRGB with an sRGB TRC, and you assign(not convert) it an sRGB colour space with a linear TRC, the colours will look radiometrically right.
Manipulating the interpretation is the whole idea that OCIO runs on, and if it didn't work, a whole lot of VFX industry professionals would have a problem.
EDIT: In fact, if you do linearise the TRC before doing colour maths, you ARE baking in the TRC. After that, you can only rely on colour conversion to switch from sRGB TRC to linear TRC. So it may be a better idea to work in 16 bit linear to begin with, especially if there's a CM like OCIO in between
Using LAB mode however does fix it for guassian blur too.
it doesn't in CC either
cool thread, i've had no idea about that checkbox either! It makes for more interesting color blending with the paintbrush! Thanks for this!
It doesn't seem to do the gamma correction.
I wonder if the Harmony version of ToonBoom is also like this. This would mean that there's a lot of broadcast shows (Adventure Time, Gravity Falls etc.) that are being rendered this way, and that it ultimately does not make a significant difference.
The gamma compensated way feels as if you're painting with "light" (additive colours).
The standard way (the uncompensated, or "incorrect"), seems more like it's pigment or real paint (subtractive colours). When you do a red wash over green with watercolour, the edges get dark:
- - - - - - - - - -
This is a very thorough article on the subject, with visual comparisons:
http://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html
Some more comparisons:
http://scanline.ca/gradients/
It's very subjective what is the best, though I know there's painters out there who prefer working in linear because that keeps the luminosity of their colours easily in tact. Others instead have become so used to compensating for it, that it makes no difference.
It is, and I am repeating myself, something to take into consideration when dealing with hdr or something that does a lot of colour maths(like, you know, 3d renderers, though those are often smart enough to use sRGB images correctly if you tell them it's one)
I just learned something mind blowing today...
Also just basically echoing Wolthera here but color blending is definitely nicer this way (as long as you're in 16 bit) but the opacity control sucks.
Edit: Actually it appears smudge may only work provided you separate your colors onto different layers.
I was nowhere near colour savy enough back when I used PS CS2, so I don't actually know how to change the icc profile there, but you should be able to look it up fairly easily, I imagine
If so...
Could somone point me there?
Coming from traditional media years before I considered painting would really be possible on computers it at first took me a long time to wrap my head around using sliders or simply droplet selecting hue value and sat.
And what was a correct blend between two colors is different when considering the medium ( light thru light mix vs light reflecting pigment mix ). Where equal amounts of a a primary colors compliment will give you grey and depending on what side of that balance u choose gives u the temperature sophistication depending how good of an eye u have.
Sort of miss the alchemy of mixing pigments dancing between warm and cool greys by using a colors compliment.
Edit:
Ahh I c Kryzon aready posted an example...
however in your example i am willing to bet:
because the pigments are in a wash they simply get darker in the grey mix because u go from semi-transparent "wash" pigment doubled by the additional colors pigment.
If u look at opaque ( acrylic/oils ) examples of green and red ( primary and it's compliment to get grey ) I do not think the grey band will be as dark as the grey band in the OP video. ( The artifact from the math compression leveraging values the human eye can see )
Although it does eerily resemble the same ugly mess u can get from traditional media ( like if u try to airbrush green over red )
In color management preferences there is a "view transform" box and above that a "rendering space" options.
i found this after maya lt 2016 told me to change it to stingray. This just applies to the view port so i'm not sure if thats what you're looking for XD.
Maybe there's something similar for rendering?
Hmm, this has been contrary to my experiments with photoshop.
I guess i would ask the question.
Is the scale of 0-255 interpreted as linear? I'd imagine it would have to be.
Also if the data is not baked in. Then why even have a gamma number in the first place? I mean, if everything is linear then the interpretation should always be according to the monitor, so why would you ever want there to be different gammas on different images?
No, the scale of 0 to 255 is not interpreted as linear to the DISPLAY. It is interpreted agnostic internally. So when you have two layers, and you multiply them, so for example, red and grey:
This operation is exactly the same in linear and non-linear space. However, in a linear space Dark Red looks like a lighter colour than in sRGB, because it's values are interpreted to correspond to a lighter colour.
Why even have Gamma? Because of humans. Computers are used by humans, so displays are optimised for them.
As humans are better at distinguishing the difference between darker colours, it's most efficient for displaying purposes to have a log applied to the TRC. If you take a 8bit linear image and start working in colours below 20% brightness, you'll quickly notice that it'll band really really badly. As consumer displays have been 8 bit for a very long time now, having linear space as the regular would mean that no one would enjoy having a dark wallpaper, or watching The Dark Knight, or even play horror games because of the banding everywhere.
However, the TRC itself is only meta-data, usually part of an embedded ICC profile, and if there's no ICC profile, the computer will assume it's sRGB with an sRGB TRC.
If you have something like Nuke, or Natron, or anything else that uses OCIO, you should be able to stick an 8bit image with the ugly borders on blurry edges, have it be interpreted as Linear, and outputted as sRGB and it'll convert the image to have none-ugly borders.
Mind you, as artists are used to compensating for an sRGB TRC, they'll intuitively bake in the TRC. At that point the only option for going to linear is conversion.
Of course i know what gamma is and how the maths work. I'm just talking about implementation.
The question is that if the rgb scale is internally linear, why would the blending algorithms ever have a chance of being wrong? Because gamma is just a way of transforming the linear scale to being human literate on a monitor.
Why would you ever want any calculation in the image creation process ever have gamma corrected numbers for anything other than output.
At the least, that's why Adobe Photoshop probably does it. I imagine it went like this:
Customer: Adobe, why can't I have linear blending?
PS engineer: Well, if you go 16bit, you can have it and it won't look ugly.
Customer: But then my images take up twice as much ram! I don't have that much ram, there must be another way! Make it work!
PS engineer: Uhm... well, we could optionally linearise the numbers before doing the blending.
Customer: If you technobabble thing makes it work, do it!
At the least, I am inferring this because Adobe Photoshop also turns the blending modes sRGB before applying them in LAB, and this one is NOT optional. (Like I said before, multiply in LAB ultimately turns things bright blue, not black like in RGB)
Really depends on how long this box has been around, a decade back having an image that takes up 1gig of ram suddenly take up 2gig may have been a bit much for your average photoshopper.
EDIT: When people tell you photoshop is full of legacy code, they mean these kind of things. And PSD. Mostly PSD though.
I am on Maya 2015.
I believe that drop down isn't available till 2015 extension 1 ( part of the new color management updates )
Was hoping there was a similar color setting like in photoshop that affected color blends ( as 3d texture paint and paint effects give the same artifacts by default )
Last I heard on the Mudbox forums ( 2012 ) the same was true for Mudbox?
( though I sort of remember some kind of tonemapper hack/workaround back then? )
As Maya is listed at the end of the video as including a solution ( not by default )...
I was hoping for a setting or perhaps a buried env variable fix?
I did find this though...
http://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-F7A7FC66-4D36-4544-9DBD-24FA35C66C2C-htm.html
as for mudbox i also have no clue, some people say it's already linear but exports non-linear?
From what I've read, in the case of alpha blending, it's because the colours being blended are not linear. These RGB values that we select to paint are not linear.
When we want a linear gradient of value, this is what we expect:
But monitors don't work that way, they have a nonlinear response.
When we add energy to a pixel in a monitor display in constant increments, we don't see a constant increment in brightness. For a monitor display, if you add x energy you get x²⋅² brightness coming to your eye:
In order to get a gradient that looks linear, like that first one, the computer internally maps the values in a way that makes the darker values spread further, to compensate exactly for this behaviour of the display.
Because of this, the colours are also made nonlinear -- in the inverse way in relation to the monitor display -- for this to work.
The smart algorithms will 'compensate' for this way that computer colours made more space available for darker values and will convert them back to the corresponding linear values when the calculations are being done.
The naive algorithms don't do any compensation. The colours used are straight from the computer colour space which has that bigger presence of darker values, so the result will tend to darkness. Non-linear values are being used in a linear formula (the alpha blending formula).
I'm not sure if all the blending modes in addition to alpha need correction (like add, multiply etc.), but I'd guess they do.
EDIT: Corrected some.
EDIT: Corrected some more.
It's a little tricky, but generally it's because of pipelines and how users experience it.
Thing is, when you have a file that is two layers, and the same file, but merged, these two files should act and look exactly the same, right?
So if we stick them into OCIO or a similar tool, the values will be interpreted correctly right?
But if you have the 'smart' algorithm blending those layers, the second, merged image, will have the gamma operation baked into it. The values will not be blended through means, but will also have this gamma operation in their blending.
So if we now stick our layered image and our flattened image into OCIO, the output colours will be different, because we can still work around the layered image's 'smart' blending, but not that of the merged image any more.
Colour Management, due to being highly reliant on maths, is really sensitive to a single operation more or less, so hence most people dealing with that stuff prefer naive algorithms from the program itself, and work in a linear or non-linear space explicitly. The bugs involved with 'smart' algorithms tend to be too tricky to deal with(and devastating in an automated pipeline...)
It's similar to that argument from the banded normal map thread on why it's not worth going 32bit: 16 bit is enough, and converting from 32bit int to 8bit requires that you press a bunch of toggles correctly, so there's too much room for error.
While you could argue for choice, I am similarly not seeing why, if you want linear space blending, you don't work in 16bit linear and avoid having arcane 'smart' operations happening all over the place.
If you are a amateur artist on tumblr with your first wacom and only 2gig of ram on your laptop, okay, I get why you can't afford 16bit images. I doubt most people here are facing that same issue.
It makes a difference when photoshop is doing a real-time mix (eg opacity through layers) and does not make any difference to baked or tool-derived values. If you disable 'sample all layers' and smudge a top layer over a different coloured lower layer, gamma correct mixing will work.
That photoshop trick is interesting, but after doing some quick tests, it seems the issue(s) seen without "Blend RGB Colors Using Gamma" checked are only really very noteworthy if you're blending starkly different colors with a very soft brush.
If I'm using a soft brush to blend anything, it's probably blending a moderate change among a surface of colors that are fairly similar, or at least within a certain range. Either that or it's to apply a slight change at a low opacity, and the issue doesn't really seem to present itself in that instance. Least not nearly as noticeable. Also, because of the drastic performance difference in working with brushes containing a crap ton of different values (very soft, fading) compared to a brush with a lot of noise, but very few values (only stark black/white), I generally wind up using hard brushes of different textures for blending.
Still, interesting. I'll have to play around with it a bit more. Thanks for sharing.