It is currently March 28th, 2024, 8:57 am

fading trough 3 colors... how to do it?

Get help with creating, editing & fixing problems with skins
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: fading trough 3 colors... how to do it?

Post by Yincognito »

brax64 wrote: August 7th, 2020, 10:06 pm[...] the lua code is made by, try to guess..., jsmorley! :great:
I didn't even have to guess, actually... :p
Joking aside, it looks amazing, and what's even more amazing is how simple such a great effect is done. If I'm not mistaken, it's just a simple gradient between different saturations / brightness of a color. :jawdrop
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: fading trough 3 colors... how to do it?

Post by jsmorley »

The advantage to HSB as I see it is that it is more intuitive, more how humans think about color.

The example often given is if you have a table top, and it is mahogany, it is presumably some kind of redish, brown color. Now, if you hold your hand between the light and the table, does the color change? I would argue that a human would say no. The part where the shadow is is still exactly the same color, just a bit darker. That is where HSB makes sense. An HSB color is always just one "color", there is no need to "mix" red, green and blue in your head (which by the way nobody can actually do) to arrive at the color you want. The colors in HSB are just a single "hue", which is a value in degrees on a 360° color wheel. Then you apply "saturation" (a 0-100 percentage of the amount of hue applied, think "richness") and "brightness" (a 0-100 percentage of dark and light applied).

color-wheel.png


https://learnui.design/blog/the-hsb-color-system-practicioners-primer.html

The other advantage, in my view, is that the 360° color wheel makes calculating a desired "hue", pretty simple compared to mixing red, green, blue.

At its most basic, "transitioning" between two colors is just one formula on one value. The "hue". Just move that around the 360° hue circle as desired.

It's not something that is desirable in all cases, as the formulas to convert back and forth between RGB and HSB, while standard, and easy to "blackbox", are not entirely trivial. For a color picker though, I would always prefer doing that in HSB.
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: fading trough 3 colors... how to do it?

Post by Yincognito »

jsmorley wrote: August 8th, 2020, 1:05 am The advantage to HSB as I see it is that it is more intuitive, more how humans think about color.

The example often given is if you have a table top, and it is mahogany, it is presumably some kind of redish, brown color. Now, if you hold your hand between the light and the table, does the color change? I would argue that a human would say no. The part where the shadow is is still exactly the same color, just a bit darker. That is where HSB makes sense. An HSB color is always just one "color", there is no need to "mix" red, green and blue in your head (which by the way nobody can actually do) to arrive at the color you want. The colors in HSB are just a single "hue", which is a value in degrees on a 360° color wheel. Then you apply "saturation" (a 0-100 percentage of the amount of hue applied) and "brightness" , (a 0-100 percentage of dark and light applied).


color-wheel.png



https://learnui.design/blog/the-hsb-color-system-practicioners-primer.html

The other advantage, in my view, is that the 360° color wheel makes calculating a desired "hue", pretty simple compared to mixing red, green, blue.

It's not something that is desirable in all cases, as the formulas to convert back and forth between RGB and HSB, while standard, and easy to "blackbox", are not entirely trivial. For a color picker though, I would always prefer doing that in HSB.
So hue is basically the ROYGBIV thing? :o That I'm familar with, it's one of the first things I learned in my drawing classes at school. Regarding the mixing of RGB in your head, once you know how it works (some color combinations are quite logical, like magenta, cyan, others not so much, like yellow, orange, even green seems like a secondary color naturally since it can be drawn on paper by placing yellow on blue) it isn't that hard to mix it in your head, IMHO. It also goes well with the notion that all colors combined are white and no colors combined is black. But yeah, the color wheel is probably easier to grasp, especially in the case of secondary and tertiary colors, once you know the direction in which colors are placed one after another.

Thanks for the clarification and the details - much appreciated. ;-)
User avatar
jsmorley
Developer
Posts: 22628
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: fading trough 3 colors... how to do it?

Post by jsmorley »

Yeah, for color picking, I certainly prefer HSB over RGB.

I find that if I want a color like the blue below, Just scrolling the "hue" until I get the color I want is a lot more intuitive than changing both green and blue to get there.


1.jpg


And if I want to "desaturate" it some, to lessen the "richness" of the blue, using "saturation" for that makes sense to me. The resulting RGB hardly makes any human sense at all. Adding "red" to it to lighten it just isn't intuitive to me at all. I understand the math, given that in RGB "all colors equal white" and "no colors equal "black", but it's just not how I picture colors. I see no trace of red in that color. I see no trace of green in that color. I see no trace of any colors other than a single light-blue color, or "hue".


2.jpg


Now, Rainmeter speaks in RGB, and that's fine, it's how most "computer programs" deal with color. 256*256*256 works well for the 16,777,216 colors supported on your monitor, and it's a fact that physically, pixels are made up by mixing red, green, and blue "dots". I'm only saying that for "finding" a desired color to use, I would never think in terms of RGB. I"m delighted to "use" the resulting RGB, not that I have any choice, but it's not how I would "get there".
User avatar
eclectic-tech
Rainmeter Sage
Posts: 5380
Joined: April 12th, 2012, 9:40 pm
Location: Cedar Point, Ohio, USA
Contact:

Re: fading trough 3 colors... how to do it?

Post by eclectic-tech »

In addition to the examples given, I would also suggest looking at a the Color Blending with Multiple Scales script by HakShak.
HakShak wrote: -- BlendColor is a LUA script for processing multiple color scales to output
-- RGBA notation within Rainmeter INIs.

--Each scale is composed of "Start Percentrage, End Percentage, Start Color Value, End Color Value" notation
--e.g.: Fade a color in gradually over 100% would be "0,100,0,255"

--You can add more scales via a pipe '|' delimiter
--The below examples are the equivalent of "0,100,0,255"
--"0,50,0,128|50,100,128,255"
--"0,25,0,64|25,50,64,128|75,50,128,192|75,100,192,255"

--There is no limit to how many scales provided per option
--Only RedScale, BlueScale, GreenScale, and AlphaScale options are available.

--The measure fed to the script must have a MinValue and MaxValue set as it is based on percentages.
This is a versatile script to control color blending based on percentage values.

** EDIT: ADDED AN EXAMPLE SKIN AND THE SCRIPT **

Here is an example using the desired red at 0, to green at 50, and to blue at 100. It uses just one script measure and is driven by a loop measure.
blendcolor.gif

Code: Select all

; ========= Skin Settings ==========
[Rainmeter]
Update=100
AccurateText=1
DynamicWindowSize=1
Group=#RootConfig#

LeftMouseUpAction=[!TogglePauseMeasure m100]

; ========= Measures ==========
[m100]
Measure=Loop
StartValue=0
EndValue=100
InvertMeasure=0
MinValue=0
MaxValue=100
IfCondition=m100=100
IfTrueAction=[!SetOption m100 InvertMeasure 1]
IfCondition2=m100=0
IfTrueAction2=[!SetOption m100 InvertMeasure 0]

[BlendColorMeasure]
Measure=Script
ScriptFile=BlendColor.lua
MeasureToBlend=m100
RedScale=0,50,255,0|50,100,0,0
GreenScale=0,50,0,255|50,100,255,0
BlueScale=0,50,0,0|50,100,0,255
AlphaScale=0,100,255,255

; ========= Meters ==========
[MeterBar]
DynamicVariables=1
Meter=Image
MeasureName=m100
X=0
Y=0
W=100
H=100
SolidColor=[&BlendColorMeasure]

[String]
Meter=String
MeasureName=m100
FontColor=255,255,255
StringEffect=Shadow
StringAlign=CenterCenter
X=50
Y=50
BlendColor.lua

Code: Select all

-- BlendColor is a LUA script for processing multiple color scales to output
-- RGBA notation within Rainmeter INIs.

--Each scale is composed of "Start Percentrage, End Percentage, Start Color Value, End Color Value" notation
--e.g.: Fade a color in gradually over 100% would be "0,100,0,255"

--You can add more scales via a pipe '|' delimiter
--The below examples are the equivalent of "0,100,0,255"
--"0,50,0,128|50,100,128,255"
--"0,25,0,64|25,50,64,128|75,50,128,192|75,100,192,255"

--There is no limit to how many scales provided per option
--Only RedScale, BlueScale, GreenScale, and AlphaScale options are available.

--The measure fed to the script must have a MinValue and MaxValue set as it is based on percentages.

--Scales support variables, however, scales are only evaluated at startup.
--So dynamic variables will not be updated. (This support could be added, but doesn't make practical sense.)

--The below example will keep the color green until 50%, then fade green down to 0 from 50% to 75%.
--It also fades red in starting at 50% and makes sure it's full red from 75% to 100%
--It also keeps the alpha level at 64 from 0-50%, then fades more in from 50-100%

--[ExampleColorMeasure]
--Measure=Script
--ScriptFile=BlendColor.lua
--MeasureToBlend=SomeMeasureWithMinMaxSet
--RedScale=50,75,0,255|75,100,255,255
--GreenScale=0,50,255,255|50,75,255,0
--AlphaScale=0,50,64,64|50,100,64,255

--Using this measure is as simple as:
--LineColor=[ExampleColorMeasure]


function Initialize()
	RedScale = load_scales('RedScale')
	GreenScale = load_scales('GreenScale')
	BlueScale = load_scales('BlueScale')
	AlphaScale = load_scales('AlphaScale')
end

function Update()
	local inputMeterName = SELF:GetOption('MeasureToBlend')
	local inputMeter = SKIN:GetMeasure(inputMeterName)
	local meterValue = inputMeter:GetRelativeValue() * 100

    local red = multi_scale_color(meterValue, RedScale)
    local green = multi_scale_color(meterValue, GreenScale)
    local blue = multi_scale_color(meterValue, BlueScale)
    local alpha = multi_scale_color(meterValue, AlphaScale)
    
    --Simplify since Color::MakeARGB doesn't really care about decimals
    --Also makes printing these less painful to look at
    red = math.floor(red + 0.5)
    green = math.floor(green + 0.5)
    blue = math.floor(blue + 0.5)
    alpha = math.floor(alpha + 0.5)

    local result = red .. ',' .. green .. ',' .. blue .. ',' .. alpha

	return result
end

function load_scales(scaleOption)
	local scaleString = SELF:GetOption(scaleOption)
	scalestring = SKIN:ReplaceVariables(scaleString)
	local result = {}
	for i in string.gmatch(scaleString, "([^|]+)") do
		local scale = {}
		for x in string.gmatch(i, "([^,]+)") do
			local number = tonumber(x)
			if number == nil then
				disable_me()
				error('Value in ' .. scaleOption .. ' option is not a number. Expecting number within group "' .. i .. '" at "' .. x .. '"')
			end

			table.insert(scale, number)
		end
		table.insert(result, scale)
	end

	return result
end

function scale(value, oldMin, oldMax, newMin, newMax)
	local oldRange = oldMax - oldMin
	local newRange = newMax - newMin
	local scaled = (((value - oldMin) * newRange) / oldRange) + newMin
	return scaled
end

--Expects lower percentage bound, upper percentage bound, lower color bound, upper color bound
function multi_scale_color(percentage, colorScaleTable)
	if type(colorScaleTable) ~= 'table' then
			disable_me()
			error('"' .. colorScaleTable .. '" is not a table.')
	end

	for i, value in ipairs(colorScaleTable) do
		if type(value) ~= 'table' then
			disable_me()
			error('Value (' .. value ..') at key ' .. i .. ' is not a table.')
		end

		if table.getn(value) ~= 4 then
			disable_me()
			error('Four values are required in the table, key ' .. i .. ' has only ' .. table.getn(value) .. ' values.')
		end

		if percentage >= value[1] and percentage <= value[2] then
			return scale(percentage, value[1], value[2], value[3], value[4])
		end
	end

	--Nothing was found to do
	return 0
end

function disable_me()
	SELF:Disable()
	print('Disabling Measure: ' .. SELF:GetName())
end
User avatar
brax64
Posts: 172
Joined: July 8th, 2018, 8:05 pm

Re: fading trough 3 colors... how to do it?

Post by brax64 »

jsmorley wrote: August 8th, 2020, 1:57 am Yeah, for color picking, I certainly prefer HSB over RGB.

I find that if I want a color like the blue below, Just scrolling the "hue" until I get the color I want is a lot more intuitive than changing both green and blue to get there.
...
I'm only saying that for "finding" a desired color to use, I would never think in terms of RGB. I"m delighted to "use" the resulting RGB, not that I have any choice, but it's not how I would "get there".
So if I understood correctly I may "imagine" colors described as "point in space" contained in a 256x256x256 cube where X is hue, Y is saturation and Z is brightness...
That sound nice and clear.... at least in my head... :lol:
One thing I'm not sure about tho...
The "alpha" channel still apply? Because if it does It will destroy may "cubic" vision 'cause now I've to add a 4th dimension in the game and it's not nice! :rolmfao:
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: fading trough 3 colors... how to do it?

Post by Yincognito »

jsmorley wrote: August 8th, 2020, 1:57 amNow, Rainmeter speaks in RGB, and that's fine, it's how most "computer programs" deal with color. 256*256*256 works well for the 16,777,216 colors supported on your monitor, and it's a fact that physically, pixels are made up by mixing red, green, and blue "dots". I'm only saying that for "finding" a desired color to use, I would never think in terms of RGB. I"m delighted to "use" the resulting RGB, not that I have any choice, but it's not how I would "get there".
Yep, I understand what you mean, it's logical any way you look at it. The advantage of HSB is that is pretty much "linear" in its components, while RBG is, if I can say so, more about "color combinatorics". While for primary colors (i.e. R,G,B) and those in between (i.e. R+G,R+B,G+B) everything is simple in both systems, I guess the difficulty comes when talking about colors made of combinations of all 3 colors. The saturation thing is not complicated to understand in RGB (might be more complicated to apply it in practice though), just change the RGB components to fade into grey aka "flatten" them to reach R128,G128,B128; the brightness thing is even simpler, just proportionally change the RGB components towards black or white. Making a little comparison, I guess it's just like trying to understand or use the base 2 or base 16 systems (that a computer "understands" best) as humans - it can be uncomfortable, especially if the complexity increases (just like when talking about finding colors made of combinations of all 3 colors in RGB instead of going humanly simple with HSB).
User avatar
balala
Rainmeter Sage
Posts: 16109
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: fading trough 3 colors... how to do it?

Post by balala »

Yincognito wrote: August 7th, 2020, 10:18 pm Ok, so I looked over your code and I found "validating" the colors and the associated formulas in the SolidColor quite ingenious - very nicely done. I would probably be a bit concerned about the length of the option as it makes it harder to understand for most folks like you said, but I understand why it was necessary in your implementation.
Thank you. Yes, the length of the code is quite great and I'm gonna increase it even more. I have ideas about how the code should be improved, because as said, it definitely has to be improved. A little bit later today I'm gonna post an improved code.
Probably a lua implementation should reduce the length of the code, but right now I'm not entering into this approach. Not because I couldn't do it, I just feel it can be done without a script.
Yincognito wrote: August 7th, 2020, 10:18 pm One more thing, since we're at it and we're sharing opinions: while your code indeed doesn't need modifications when adding or removing less than 11 colors, it does need adding to the formula in the SolidColor option if the number of colors goes beyond 10. That's not to say that it's wrong or anything like that, but my initial aim was to "make and forget" the code / skin, so that whenever I want a different number of colors to transition through I'd only have to input the "color stops" and "hit play", so to speak.
I'm not sure it can be done with native Rainmeter code. My guess is that a lua script would be needed in such a case (however maybe I am wrong).
Yincognito wrote: August 7th, 2020, 10:18 pm All in all, a great alternative to have. I liked the validation and the formula most and how they implicitly set the number of color automatically. A bit unfortunate that the length of the whole thing got bigger as a result, but then, someone else might very well find similar "quirks" in my code as well, if they're being picky, LOL.
Probably for a general user, who is just using the written code, this is not too important (I guess).
Yincognito wrote: August 7th, 2020, 10:18 pm The imprtant thing is that it works flawlessly and that's all your credit, of course. :thumbup:
Thank you for the appreciations. :great:
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: fading trough 3 colors... how to do it?

Post by Yincognito »

balala wrote: August 8th, 2020, 10:14 amI'm not sure it can be done with native Rainmeter code. My guess is that a lua script would be needed in such a case (however maybe I am wrong).
It's already done in mine - I only have to:
- add (or remove, although this works by lowering IdMax as well) the RGB components for a "color stop"
- change IdMax accordingly (i.e. if I have or want to use 7 colors, IdMax would be 7-1=6)
That's all. It works with an unlimited number of colors, in theory.

So the only sort of "laborious" thing one needs to do in my skin is adding the "color stops", as changing a single variable, i.e. IdMax, is just modifying a parameter, after all. But then, that is a required thing to do in every implementation and can easily be solved by having some InputText interactive approach anyway.

EDIT: Just realized that maybe you were talking about doing the "unlimited colors" thing in your code, not mine. If that's the case, you might be right about being a bit short in options when it comes to dynamically modify a complex option. Although, if I think about it, you could build the string/text of the SolidColor option automatically first, and then just apply it to SolidColor through a !SetOption or !SetVariable.
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: fading trough 3 colors... how to do it?

Post by Yincognito »

dvo wrote: August 7th, 2020, 9:50 pm shapes is from the last year or so before that it was all image ...shapes could result in flashings in skins so i pref. images .. :D
and if you really wanna go slow and see my stutter just install magicks meter and let it check a lot of times ...in a minute for getting the youtube image and text and creating the images.. :jawdrop
Yeah, but that's the thing, I'm not looking to so slow and see stutter on my system, I want to avoid it. :D Now on the other hand, if one wants to determine a program (including Rainmeter) to be slow and stutter at all costs, it can obviously be done - but then, why even trying, right? :???:
Post Reply