Friday Facts #320 - Color correction
Re: Friday Facts #320 - Color correction
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.
Re: Friday Facts #320 - Color correction
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.
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.
Re: Friday Facts #320 - Color correction
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).
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.
-
- Fast Inserter
- Posts: 137
- Joined: Wed Sep 20, 2017 5:45 pm
- Contact:
Re: Friday Facts #320 - Color correction
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
Re: Friday Facts #320 - Color correction
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.
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.
Re: Friday Facts #320 - Color correction
NERRRRRRRRRRRRRRRRRDTynach 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.
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
I have mods! I guess!
Link
Link
Re: Friday Facts #320 - Color correction
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
How about having an control under graphics configuration options to allow the user to configure the intensity / degree / brightness proposed colors.
Hiladdar
Re: Friday Facts #320 - Color correction
Of course those heavily polluted areas tend to be the most frequently visited, contraindicting the changes somewhat. Maybe something in between can be found.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).
-
- Burner Inserter
- Posts: 19
- Joined: Sun Mar 31, 2019 10:49 pm
- Contact:
Re: Friday Facts #320 - Color correction
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!
Re: Friday Facts #320 - Color correction
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: Friday Facts #320 - Color correction
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.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.
Also if you think nature starts out dirty and gloomy, you probably live too close to civilization.
Re: Friday Facts #320 - Color correction
The night is a bit too ultramarine blue now. Add a little green to the mix, it will look much better.
Re: Friday Facts #320 - Color correction
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).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).
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 have mods! I guess!
Link
Link
- Deadly-Bagel
- Smart Inserter
- Posts: 1498
- Joined: Wed Jul 13, 2016 10:12 am
- Contact:
Re: Friday Facts #320 - Color correction
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.
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.
Re: Friday Facts #320 - Color correction
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.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.
I have mods! I guess!
Link
Link
Re: Friday Facts #320 - Color correction
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."
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."
Re: Friday Facts #320 - Color correction
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.Tynach wrote: ↑Sat Nov 09, 2019 10:53 amA 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!
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.
Re: Friday Facts #320 - Color correction
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.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).
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))
Code: Select all
#define xyzToRgb(space)\
inverse(rgbToXyz(space))
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 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.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 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.
Re: Friday Facts #320 - Color correction
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.posila wrote: ↑Sun Nov 10, 2019 9:41 amLUTs 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.Tynach wrote: ↑Sat Nov 09, 2019 10:53 amA 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!
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 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.
Re: Friday Facts #320 - Color correction
As someone who very strongly dislikes all of the changes proposed in this FFF, please make this optional.
Also #giveTynachajob
Also #giveTynachajob