Friday Facts #320 - Color correction

Regular reports on Factorio development.
User avatar
Lubricus
Fast Inserter
Fast Inserter
Posts: 237
Joined: Sun Jun 04, 2017 12:13 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by Lubricus » Sat Nov 09, 2019 5:28 pm

I don't care so much about the theme of the game for me it's more important that stuff is easy to discern and that Factorio is a happy place to be in. So i like the changes. I would like if you thought more about how stuff loks more zoomed out because i rarely zoom in so much.

bobucles
Smart Inserter
Smart Inserter
Posts: 1591
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by bobucles » Sat Nov 09, 2019 5:34 pm

I'm actually digging the new night time look. It needs to be compared with some light sources in the picture, of course. Obvious sources of light include lamps for that cool glow and furnaces for that warm glow, but could there be a bit more in the way of sparky bits? For example if you've ever played with the old tiny race cars that get powered from the track, those things were amazing in the dark. Their flimsy brush motors and connections made tons of sparks so you could practically see them run across the track. A factorio equivalent might have inserters or assemblers flashing in the night, erupting with a rare spark effect as their internal machinery goes to work. A train that slams its brakes might drop a few sparks from the wheels. These tiny light sources would be too tiny to be seen during the day, instead pushing the night layer away from the desaturated "dark" table towards the more colorful "light" table. Fake HDR lighting. They would be strictly cosmetic of course and miiiight be medically hazardous, but it'd probably look cool.

Be sure to revisit the night vision upgrade! NV goggles completely destroy the artwork that goes into the night layer, and they are available very early in the game. The artistic landscape of night disappears too quickly. Instead, hook players up with a torch lantern upgrade. The default flashlight is pretty feeble, so a suit upgrade should upgrade by giving more range and a much wider field of illumination.

Impatient
Filter Inserter
Filter Inserter
Posts: 354
Joined: Sun Mar 20, 2016 2:51 am
Contact:

Re: Friday Facts #320 - Color correction

Post by Impatient » Sat Nov 09, 2019 6:02 pm

I am ambivalent about these changes.

I like the bright and colorful nature. Maybe I will like the tweak of the night colors as well, I will see. Also daytime being bright is a good thing for me. ... Although, a lovely bright day may not be always something a player would expect, after making quite an impact on the environment of the planet. ...

... I think, in general I agree with those who have wished for more contrast between a healthy looking nature and areas exploited and polluted by the player. The factory looking like a gumball candy machine breaks the narrative for me a bit. The narrative of a ruthless alien, that crash landed and stranded on the planet and exploits its nature and resources without a dime of care for the environment.

Factory damaging acid rain and darker/greyer daytime colors in areas with a lot of pollution in the air (also impacting solar panel output and player health?), or ground tiles shifting their color palette into the grey once polluted - like the trees dieing - would support that narrative better.

I know factorio isn't a environment simulator but a logistics game. Still, that area has some nice opportunities for some cause-effect game mechanics, which could make it more challenging in a diversified way (meaning, not an immediate logistics problem to solve but long term decisions and impact).
Last edited by Impatient on Sat Nov 09, 2019 6:22 pm, edited 2 times in total.

theolderbeholder
Long Handed Inserter
Long Handed Inserter
Posts: 97
Joined: Wed Sep 20, 2017 5:45 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by theolderbeholder » Sat Nov 09, 2019 6:12 pm

I like it, it looks better on both my displays. Which are both a bit old, so the lack of overdrive might help in this case

User avatar
oniakki
Manual Inserter
Manual Inserter
Posts: 4
Joined: Wed Jun 29, 2016 11:24 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by oniakki » Sat Nov 09, 2019 6:14 pm

I'm in the not a fan camp myself, looks like someone cranked up the saturated way too far, will definitely increase eye strain for me over long play sessions.

On the plus side the easier to see cliffs on the map are nice, and the blue shift during the night also looks pretty good.

Honktown
Fast Inserter
Fast Inserter
Posts: 183
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Friday Facts #320 - Color correction

Post by Honktown » Sat Nov 09, 2019 7:42 pm

Tynach wrote:
Sat Nov 09, 2019 10:53 am
It would be a crime for me not to respond to this Friday Facts. Not only do I both love Factorio and use a calibrated monitor (and own my own colorimeter), but I've also spent the past few years writing colorspace conversion and manipulation code in GLSL, for fun.

A LUT is certainly one way to go about creating a difference between day and night, but I'm not convinced it's the best way to do it - especially when the transition from one to the other is gradual over a length of time. The use of a LUT implies you're wanting to avoid converting to and from linear light values for blending (because literally everything else would be a super inexpensive matrix multiply against the RGB values), but... It's incorrect to blend between plain RGB values and the RGB values those translate to when using the LUT, without converting both sides of the LUT into linear light values for the blend between them!

Yes, it very well might look good enough to blend between not using a LUT and using the LUT. But consider this example:

Say we have a dull red color, #B05A44, and we want to pretend to adapt the white point from a more bluish one (I found somewhere that old Sony CRT monitors had a white point with xy chromaticity coordinates of 0.283, 0.298, and that's roughly also somewhere along the 'daylight' variation of the blackbody radiation curve, so lets just use that) to D65, and then reduce the luminosity to 1/8th of its former value.

After converting the sRGB color above into a linear light value, performing both operations, and then turning it back into an sRGB color, we get #3F1E1A This is the color that winds up in our LUT to replace the above dull red color. It's much darker, and slightly bluer.

So, what about at the halfway point? For fairness (to the extent of being unfair, which I'll get to in a moment), lets try a few times at the linear light side of the comparison so that the final green channel value is the same as the 'naive' blending approach (where the naive approach just takes a direct average of the two RGB values).

Turns out, the naive approach of blending the two values together results in #773C2F... But the result should be something closer to #783C2E.

Not a major difference, mind you, but as the differences between the two colors grow, so does the difference in how they blend. Already we have a slight difference in hue between the two values.

Furthermore, this is specifically adjusting things so that the green channel is equal in both... And that's a pretty artificially skewed test. All pixels on the screen have to be darkened by the same amount, and you won't be adjusting it slightly to match a target green channel value for every single pixel. That'd be silly. The real halfway point when blending via linear light, turns out to be #663227 That's first converting sRGB's halfway point (127.5 out of 255) to linear light, and using that (about 0.214) as the factor instead of 0.5. Otherwise, the value turns out to be much brighter. When matching greens, I had to use a value of roughly 0.36.
NERRRRRRRRRRRRRRRRRD

Also, where did you learn these things? This sounds interesting. I've seen a bit on color spaces when it came to monitors, and YPbPr vs RGB, but that's as much as I know

Hiladdar
Fast Inserter
Fast Inserter
Posts: 112
Joined: Mon May 14, 2018 6:47 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by Hiladdar » Sat Nov 09, 2019 9:23 pm

Some like the color changes, some don't. Also everyone has different settings on their displays as well is different hardware. Personally on my system, for example, I like the orange trees, but dislike the blue ones in the new color.

How about having an control under graphics configuration options to allow the user to configure the intensity / degree / brightness proposed colors.

Hiladdar

conn11
Fast Inserter
Fast Inserter
Posts: 106
Joined: Wed Sep 14, 2016 5:02 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by conn11 » Sat Nov 09, 2019 9:27 pm

Impatient wrote:
Sat Nov 09, 2019 6:02 pm
...
Factory damaging acid rain and darker/greyer daytime colors in areas with a lot of pollution in the air (also impacting solar panel output and player health?), or ground tiles shifting their color palette into the grey once polluted - like the trees dieing - would support that narrative better.

I know factorio isn't a environment simulator but a logistics game. Still, that area has some nice opportunities for some cause-effect game mechanics, which could make it more challenging in a diversified way (meaning, not an immediate logistics problem to solve but long term decisions and impact).
Of course those heavily polluted areas tend to be the most frequently visited, contraindicting the changes somewhat. Maybe something in between can be found.

LiquidInsight
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Mar 31, 2019 10:49 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by LiquidInsight » Sat Nov 09, 2019 10:55 pm

I first looked at this FFF on my phone, and was disappointed. The new colors looked worse than the old. But, then I booted up my PC and learned that my phone screen is really crappy. The update looks great on my PC -- I can't wait to get my hands on it!

Tynach
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sun Aug 21, 2016 9:22 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by Tynach » Sat Nov 09, 2019 11:26 pm

Honktown wrote:
Sat Nov 09, 2019 7:42 pm
NERRRRRRRRRRRRRRRRRD

Also, where did you learn these things? This sounds interesting. I've seen a bit on color spaces when it came to monitors, and YPbPr vs RGB, but that's as much as I know
When I was a kid, I saw the same image being displayed on two different computer monitors when I was at school, and wondered if there was a way to adjust the picture on one of them so that they'd match.

Fast forward to today, and I'm an unemployed programmer with waayyy too much free time, and I found out I knew enough math to mostly follow along with articles like this one (as well as various Wikipedia articles, but it was that article which let me actually use the info on Wikipedia), which led to my first real attempt to do what I'd wanted to as a kid.

Sort of. What sparked off that shader was someone claiming to be accurately portraying how old CRT monitors displayed color by doing some simple operations, and I believed their claims to be incorrect. Hence I used some (probably dubious, to be honest) data I found for the colorimetric properties of an old Sony CRT monitor, and made that shader with the bits of knowledge I learned from the articles I'd read. I chose GLSL because it operates on a per-pixel basis by default (which is what I wanted), and since I already knew about the Shadertoy website, I knew I could then send links to what I made to the people making the claim (and they could see how I was doing it and independently verify every operation).

The thing is, however, that at the time I had no way of verifying my code was correct. It looked good, and the result looked convincing, but my own display was not calibrated or anything. Still, happy that I actually made something that appeared to work and agreed with various online calculators, I kept going. I found the CVRL website with data on how human vision worked, and how the biological aspects connect to display colorimetry. I found articles discussing color blindness, tone mapping, and so on... And at each turn I'd make a new shader or three testing things out (my stuff with tone mapping is not yet public, because it sorta mixes a bunch of things together and I want to instead make it so it just showcases the tonemapping and that's it).

I'm still unemployed and have way too much free time, but at least I'm keeping my programming skills exercised and building up a portfolio. I've also used some money I got from a temporary job at a call center, to buy myself a colorimeter (and two 'factory calibrated' monitors... Which turned out to not be terribly well calibrated, but at least now I can easily fix that).

bobucles
Smart Inserter
Smart Inserter
Posts: 1591
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by bobucles » Sat Nov 09, 2019 11:49 pm

I think, in general I agree with those who have wished for more contrast between a healthy looking nature and areas exploited and polluted by the player.
A good way to do that is to make healthy nature brighter. That increases the level of contrast for when pollution drags it back down again. That way it looks better up front, good for that shiny first impression, and it improves the aesthetic flow as a way of showing the game progression later on.

Also if you think nature starts out dirty and gloomy, you probably live too close to civilization.

Agamemnon
Burner Inserter
Burner Inserter
Posts: 11
Joined: Fri Jun 29, 2018 9:48 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by Agamemnon » Sun Nov 10, 2019 12:22 am

The night is a bit too ultramarine blue now. Add a little green to the mix, it will look much better.

Honktown
Fast Inserter
Fast Inserter
Posts: 183
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Friday Facts #320 - Color correction

Post by Honktown » Sun Nov 10, 2019 12:39 am

Tynach wrote:
Sat Nov 09, 2019 11:26 pm
When I was a kid, I saw the same image being displayed on two different computer monitors when I was at school, and wondered if there was a way to adjust the picture on one of them so that they'd match.

Fast forward to today, and I'm an unemployed programmer with waayyy too much free time, and I found out I knew enough math to mostly follow along with articles like this one (as well as various Wikipedia articles, but it was that article which let me actually use the info on Wikipedia), which led to my first real attempt to do what I'd wanted to as a kid.

Sort of. What sparked off that shader was someone claiming to be accurately portraying how old CRT monitors displayed color by doing some simple operations, and I believed their claims to be incorrect. Hence I used some (probably dubious, to be honest) data I found for the colorimetric properties of an old Sony CRT monitor, and made that shader with the bits of knowledge I learned from the articles I'd read. I chose GLSL because it operates on a per-pixel basis by default (which is what I wanted), and since I already knew about the Shadertoy website, I knew I could then send links to what I made to the people making the claim (and they could see how I was doing it and independently verify every operation).

The thing is, however, that at the time I had no way of verifying my code was correct. It looked good, and the result looked convincing, but my own display was not calibrated or anything. Still, happy that I actually made something that appeared to work and agreed with various online calculators, I kept going. I found the CVRL website with data on how human vision worked, and how the biological aspects connect to display colorimetry. I found articles discussing color blindness, tone mapping, and so on... And at each turn I'd make a new shader or three testing things out (my stuff with tone mapping is not yet public, because it sorta mixes a bunch of things together and I want to instead make it so it just showcases the tonemapping and that's it).

I'm still unemployed and have way too much free time, but at least I'm keeping my programming skills exercised and building up a portfolio. I've also used some money I got from a temporary job at a call center, to buy myself a colorimeter (and two 'factory calibrated' monitors... Which turned out to not be terribly well calibrated, but at least now I can easily fix that).
Re: unemployed. I know that feeling. EE and a programming job that stopped paying (literally), which forced me to go on unemployment unless the state could've made them pay in time. I was kinda hoping you were using some tutorials or even a book... the shadertoy website looks very interesting. Much easier than coding a desktop application. I forked a mod after the author was rude and ended up banging out a more thorough version, spending up to 10+ hours a day coding. Should add it to my resume, as well as "Lua scripting". Back to colors, IPS/PLS and IPS-like panels came down in cost so much in recent years, with better response times. Once I had one I had trouble dealing with TN panels (especially the garbage view angles/off-contrast).

Once I got on the shadertoy site I looked for a colorblind shader:
https://www.shadertoy.com/view/MdSGRW

I wonder if I can apply it to everything. Might be a bit enlightening.

User avatar
Deadly-Bagel
Smart Inserter
Smart Inserter
Posts: 1495
Joined: Wed Jul 13, 2016 10:12 am
Contact:

Re: Friday Facts #320 - Color correction

Post by Deadly-Bagel » Sun Nov 10, 2019 2:17 am

While we're on the subject of night, can we consider increasing the light level that nightvision toggles? Currently there's a weird time of day where it's too dark to see comfortably, but nightvision hasn't enabled itself.

We can mod this, but it'd be nicer to have a slider in the options or something.
Money might be the root of all evil, but ignorance is the heart.

Honktown
Fast Inserter
Fast Inserter
Posts: 183
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Friday Facts #320 - Color correction

Post by Honktown » Sun Nov 10, 2019 2:45 am

Deadly-Bagel wrote:
Sun Nov 10, 2019 2:17 am
While we're on the subject of night, can we consider increasing the light level that nightvision toggles? Currently there's a weird time of day where it's too dark to see comfortably, but nightvision hasn't enabled itself.

We can mod this, but it'd be nicer to have a slider in the options or something.
A gradual fade-in would be nice, and maybe a little icon or something to indicate it somewhere. I honestly have trouble telling the day/night cycle on occasion because the coloring and brightness aren't too much different after you've been playing for hours. At most sometimes I notice a 'snap' in the graphics when night-vision kicks off, and to me it usually looks like it's going from brighter to dimmer, so I think night is starting.

ohAitch
Manual Inserter
Manual Inserter
Posts: 3
Joined: Sat Apr 23, 2016 2:01 am
Contact:

Re: Friday Facts #320 - Color correction

Post by ohAitch » Sun Nov 10, 2019 6:02 am

Really not a fan of the color changes - was looking over them, they felt like they were slightly pushing it but basically acceptable, then remembered to turn off Night Shift and was subjected to the plastic candyland experience others are bemoaning in this thread. It's a fun look, but completely at odds with the spirit of the game.

On the topic of night shift, while the blue tint is subtle, of all hues it is a strange choice: our eyes perceive blue over red or green as a sign of sun, daytime, awakeness. Tools like f.lux readjust monitors to reduce the amount of blue at night-time(it's 10PM where I'm writing this), to reduce internet-induced insomnia; making everything blue sets a mood, but similarly that mood is not "it is currently night."

posila
Factorio Staff
Factorio Staff
Posts: 3988
Joined: Thu Jun 11, 2015 1:35 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by posila » Sun Nov 10, 2019 9:41 am

Tynach wrote:
Sat Nov 09, 2019 10:53 am
A LUT is certainly one way to go about creating a difference between day and night, but I'm not convinced it's the best way to do it - especially when the transition from one to the other is gradual over a length of time. The use of a LUT implies you're wanting to avoid converting to and from linear light values for blending (because literally everything else would be a super inexpensive matrix multiply against the RGB values), but... It's incorrect to blend between plain RGB values and the RGB values those translate to when using the LUT, without converting both sides of the LUT into linear light values for the blend between them!
LUTs were chosen for their convenience. Artists can take screenshot in raw colors, stick identity LUT to a corner and modify the screenshot in Photoshop until they have a look they like and then put the resulting LUT back into the game. I don't know if Photoshot can spit out matrix representing color transformations that were made to the picture.

You a have a good point with blending in sRGB vs. linear RGB. In general, working with sRGB as if it was linear color space does not create much issues (there are some - for example lot of smoke sprites overlapping makes the smoke darker around borders than its in the center), but I have not considered it might cause much more severe errors when doing color grading with LUTs. It's worth looking into.

Tynach
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sun Aug 21, 2016 9:22 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by Tynach » Sun Nov 10, 2019 9:50 am

Honktown wrote:
Sun Nov 10, 2019 12:39 am
Re: unemployed. I know that feeling. EE and a programming job that stopped paying (literally), which forced me to go on unemployment unless the state could've made them pay in time. I was kinda hoping you were using some tutorials or even a book... the shadertoy website looks very interesting. Much easier than coding a desktop application. I forked a mod after the author was rude and ended up banging out a more thorough version, spending up to 10+ hours a day coding. Should add it to my resume, as well as "Lua scripting". Back to colors, IPS/PLS and IPS-like panels came down in cost so much in recent years, with better response times. Once I had one I had trouble dealing with TN panels (especially the garbage view angles/off-contrast).
I just have an AAS degree in 'computer programming' from a community college.. And it took me a really long time to get because of mental disorders I only got help with starting when I was 24 or so. So I don't have much when it comes to credentials on paper, and with no prior actual job experience in the field I basically have a very short resume that most of the time gets filtered out automatically, so never gets seen by an actual human being. Now I'm 29 and still living with parents.

The first link I provide (labeled with the text 'this one'; which doesn't really do it justice, as it is a great article) is the closest I've ever seen to a 'tutorial' for this sort of thing. The thing is, most of the material talking about this talks about it in terms of the math and physics sides, and most things talking about the code either talk about 'good enough' approximations and how to make code that cheats and doesn't do most of the math, or instead are documentation files for existing libraries - and for open source ones, that means the 'tutorial' would be 'read the code'.

The first link I gave is a rarity. It walks through the math in theoretical terms, then walks through an example, and then at the end gives actual code one could use to implement it all. It even gives the code in chunks, explaining what each part does - relating it to the more math-oriented stuff at the beginning of the article.

I will note, however, that the things in the article turn out to be easier than their code portrays, if you use GLSL. GLSL has built-in vector and matrix types, and also has built-in support for matrix multiplication and even matrix inversion. The only thing it really lacks that is used in that article is an easy way to make a diagonal square matrix out of a vector - so that's something I fill in with a preprocessor directive (so that I can use it to create 'const' variables whose values are calculated ahead of time, so aren't being recalculated every frame for every pixel).

I end up using another preprocessor directive to generate an RGB→XYZ conversion matrix (that way they too can be generated once when the shader gets compiled by the GPU driver):

Code: Select all

#define rgbToXyz(space)\
	(space.primaries*diag(inverse((space).primaries)*(space).white))
And for xyzToRgb():

Code: Select all

#define xyzToRgb(space)\
	inverse(rgbToXyz(space))
And to actually use them to perform a conversion:

Code: Select all

// Rough approximation of the linear-light version of the 'dull red' from the other post; values are on a scale of 0 to 1
vec3 color = vec3(0.43415, 0.10224, 0.057805);
color = conversionMatrix*color;
I have a barebones version that doesn't use preprocessor directives (as they're sorta hacky) here if you want a simple example. More complex examples are actually my color blindness stuff, and speaking of that...
Honktown wrote:
Sun Nov 10, 2019 12:39 am
Once I got on the shadertoy site I looked for a colorblind shader:
https://www.shadertoy.com/view/MdSGRW

I wonder if I can apply it to everything. Might be a bit enlightening.
I wouldn't use that example. There's no gamma correction, so you won't get accurate results. Furthermore, they don't show how they derive those matrices, and they don't even use matrices at all for some reason. The main thing that GLSL does to make life easier for this, they reinvent themselves for no reason. And just now I tested their code with some color blindness test images I have, and predictably, those filters don't even work for the purpose they exist for.

I have two main color blindness shaders. The first one is similar to the one you linked to, except it provides only 4 views. The other views, however, can be simulated by clicking and dragging to change how strong the color blindness is. Clicking in the middle should give normal vision, clicking to the left simulates varying degrees of color blindness (and the furthest left column of pixels gives you full dichromacy simulation), and clicking to the right attempts to help 'correct' color blindness for people with anomalous trichromacy (as opposed to full dichromacy). Though I'll warn you, the method I use for this 'correction' is dubious. Don't trust it.

The other one is an interactive spectral simulation of color blindness. It uses approximated curves for the spectral sensitivities of the 3 types of cones in the human eye, and gives a rough estimation of how those spectral sensitivities shift for people with anomalous trichromacy, and full dichromacy. It cycles through an animation of the 3 main types (prota, deuta, and trita), though if you pause the shader as it's animating a certain type, you can then click and drag the mouse to see a specific weighting. Click again on the far left column to let it go back to its animated cycle, and unpause for it to actually animate again. You could click without pausing, but then it'll every once in a while switch color blindness types on you without any indication it's going to.

Those two shaders showcase a number of more advanced techniques I use. The second one, in particular, I made sure to document as much as possible - with lots of code comments and whatnot for everything. I often open it up in another tab just so I can get bits and pieces of it for other shaders.

Oh, and you can use this Chrome extension or this Firefox extension to test your own images on Shadertoy. You can't save shaders with them (you can only use the preset textures, or generate your own custom texture in a buffer), but I find it useful for things like testing color blindness filters.

Tynach
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sun Aug 21, 2016 9:22 pm
Contact:

Re: Friday Facts #320 - Color correction

Post by Tynach » Sun Nov 10, 2019 10:02 am

posila wrote:
Sun Nov 10, 2019 9:41 am
Tynach wrote:
Sat Nov 09, 2019 10:53 am
A LUT is certainly one way to go about creating a difference between day and night, but I'm not convinced it's the best way to do it - especially when the transition from one to the other is gradual over a length of time. The use of a LUT implies you're wanting to avoid converting to and from linear light values for blending (because literally everything else would be a super inexpensive matrix multiply against the RGB values), but... It's incorrect to blend between plain RGB values and the RGB values those translate to when using the LUT, without converting both sides of the LUT into linear light values for the blend between them!
LUTs were chosen for their convenience. Artists can take screenshot in raw colors, stick identity LUT to a corner and modify the screenshot in Photoshop until they have a look they like and then put the resulting LUT back into the game. I don't know if Photoshot can spit out matrix representing color transformations that were made to the picture.

You a have a good point with blending in sRGB vs. linear RGB. In general, working with sRGB as if it was linear color space does not create much issues (there are some - for example lot of smoke sprites overlapping makes the smoke darker around borders than its in the center), but I have not considered it might cause much more severe errors when doing color grading with LUTs. It's worth looking into.
I was thinking more from a programming perspective. With matrix transformations and the like, you can apply a different white point for each light - so fire can light things up with orange and red hues, a green light can actually glow green, and moonlight more bluish.

I admit, I hadn't even thought about it from the perspective of artists and modders, and there I admit I agree... It's only more convenient to use matrix math for weirdos like me who get giddy with excitement about being able to apply arbitrary colorspace conversions on things. For everyone else, a LUT is much more convenient, and weirdos like me can still generate our own LUTs using our matrix math and Linear RGB→XYZ→LMS→Von Kries Transformation→XYZ→Linear RGB matrix math stuff.

But yeah, there might be some weirdness in the blending between the two that might be a good idea to look into. It might overall not cause a bad result, but it very well might cause a technically incorrect result. Ultimately however, that's up to you guys to decide if it's worth it. As it is, I should get to bed and stop rambling on the Internet.

Decus91
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Nov 10, 2019 10:03 am
Contact:

Re: Friday Facts #320 - Color correction

Post by Decus91 » Sun Nov 10, 2019 10:10 am

As someone who very strongly dislikes all of the changes proposed in this FFF, please make this optional.

Also #giveTynachajob

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users