Default contrast / saturate

[adria-boada]

Hi,

I have been playing with --contrast and --saturate options, but I cannot find the "default" value. I would like to start with the "default" value (as if the option were not set) and then add or subtract contrast / saturation. It looks like these options create a substantially different palette.

Not sure but looking at #65 it appears that the default is None, while specifying an option applies a float value?

Maybe print saturation / contrast used during logs of "[I] colors" or "[I] theme", or otherwise specify it in the --help section?

[eylles]

okay, took me a while to begin answering this, the default saturation is none, or 0.0, tho due to how the internal function that handles the saturation from the --saturate flag works:

pywal16/pywal/colors.py

Lines 184 to 191 in d1ff9b9

	def saturate_colors(colors, amount):
	"""Saturate all colors."""
	if amount and float(amount) <= 1.0:
	for i, _ in enumerate(colors):
	if i not in [7, 15]:
	colors[i] = util.saturate_color(colors[i], float(amount))
	return colors

only values above 1.0 from the command line actually do something, i do know for certain the actual function doing the job:

pywal16/pywal/util.py

Lines 344 to 353 in d1ff9b9

	def saturate_color(color, amount):
	"""Saturate a hex color."""
	r, g, b = hex_to_rgb(color)
	r, g, b = [x / 255.0 for x in (r, g, b)]
	h, l, s = colorsys.rgb_to_hls(r, g, b)
	s = amount
	r, g, b = colorsys.hls_to_rgb(h, l, s)
	r, g, b = [x * 255.0 for x in (r, g, b)]
	return rgb_to_hex((int(r), int(g), int(b)))

can do take values less than 1.0 so tomorrow will start a new branch exploring uncapping that value.

now contrast is a bit more complex of a function:

pywal16/pywal/colors.py

Lines 194 to 286 in d1ff9b9

	def ensure_contrast(colors, contrast, light, image):
	"""Ensure user-specified W3 contrast of colors
	depending on dark or light theme."""
	# If no contrast checking was specified, do nothing
	if not contrast or contrast == "":
	return colors
	# Contrast must be within a predefined range
	if float(contrast) < 1 or float(contrast) > 21:
	logging.error("Specified contrast ratio is too extreme")
	return colors
	# Get the image background color
	background_color = util.Color(util.image_average_color(image))
	background_luminance = background_color.w3_luminance
	# Calculate the required W3 luminance for the desired contrast ratio
	# This will modify all of the colors to be brighter or darker than the
	# background image depending on whether the user has specified for a
	# dark or light theme
	try:
	if light:
	luminance_desired = (background_luminance + 0.05) / float(
	contrast
	) - 0.05
	else:
	luminance_desired = (background_luminance + 0.05) * float(
	contrast
	) - 0.05
	except ValueError:
	logging.error("ensure_contrast(): Contrast valued could not be parsed")
	return colors
	if luminance_desired >= 0.99:
	print("Can't contrast this palette without changing colors to white")
	return colors
	if luminance_desired <= 0.01:
	print("Can't contrast this palette without changing colors to black")
	return colors
	# Determine which colors should be modified / checked
	# ! For the time being this is just going to modify all the colors except
	# 0 and 15
	colors_to_contrast = range(1, 15)
	# Modify colors
	for index in colors_to_contrast:
	color = util.Color(colors[index])
	# If the color already has sufficient contrast, do nothing
	if light and color.w3_luminance <= luminance_desired:
	continue
	elif color.w3_luminance >= luminance_desired:
	continue
	h, s, v = colorsys.rgb_to_hsv(
	float(color.red), float(color.green), float(color.blue)
	)
	# Determine how to modify the color based on its HSV characteristics
	# If the color is to be lighter than background, and the HSV color
	# with value 1 has sufficient luminance, adjust by increasing value
	if (
	not light
	and util.Color(
	util.rgb_to_hex(
	[
	int(channel * 255)
	for channel in colorsys.hsv_to_rgb(h, s, 1)
	]
	)
	).w3_luminance
	>= luminance_desired
	):
	colors[index] = binary_luminance_adjust(
	luminance_desired, h, s, s, v, 1
	)
	# If the color is to be lighter than background and increasing value
	# to 1 doesn't produce the desired luminance, additionally decrease
	# saturation
	elif not light:
	colors[index] = binary_luminance_adjust(
	luminance_desired, h, 0, s, 1, 1
	)
	# If the color is to be darker than background, produce desired
	# luminance by decreasing value, and raising saturation
	else:
	colors[index] = binary_luminance_adjust(
	luminance_desired, h, s, 1, 0, v
	)
	return colors

but it defines a range of contrast values from 1 to 21, will add it to the experimente to see if it is a good idea to uncap that value or at least expand the range to include 0.

[eylles]

branch is up on #175 but needs more work before a merge, all feedback is welcome.

[eylles]

sorry, took more time than i wanted to get back to this.

the behaviour that pywal uses is probably not the most intuitive, i was quite wrong with some assumptions and was punching out values and code without thinking, anyway will elaborate on this later and see if there's a way to improve the behaviours.

[adria-boada]

Don't worry, I also forgot to get back to you, take your time!

I will report what I have found using the master branch.

As a heads-up, I know nothing about colour theory, contrast or saturation, so I have made sure to add some question marks to my writing.

About --saturate:

I have tried setting --saturate and I have found that the option is doing something (for me) between -1.0 and 1.0. Values below -1.0, e.g. --saturate -3.5 return ValueError: non-hexadecimal number found in fromhex() arg at position 0 and set very strange colours. Negative values bigger than -1.0 set the "negative" colours (idk?). --saturate 0.0 sets black and white. Higher than 0.0 is more colourful/saturated (???). Higher than 1.0 is expected behaviour, which is what I get without setting --saturate at all. --saturate 1.0 and --saturate 1.1 give different results. Bigger than 1.0 positive --saturate values do not change the colours.

So there is a wide array of possible outcomes for saturate.

Maybe the behaviour changes between backends? I think I am using image-magick, although I have not declared it with --backend.

[adria-boada]

About --contrast :

For me it does something around 1.0 <= contrast <= 4.9. Below 1.0 (including negative values) the preview looks unchanged. At 1.0 the two middle colours (color3 / colour4 counting from colour0) start to change noticeably. I have both blue. Also colour8 from --cols16 , a grey, but other greys don't seem to change as much. The change starts to become dramatic at 3.0. At --contrast 4.9 all colours are white. At --contrast 5.0 it resets back to the original colours, as if it were doing nothing.

In order of increasing --contrast: 0.0, 0.99, 1.0, 3.0, 4.9.

Higher than 4.9 (I have tried 5.0, careful with decimals in there) yields the same as 0.0. See how 0.0 and 0.99 are the same, different from 1.0.

[eylles]

to expand on the reason why the behaviour of saturate is so inconsistent

every single one of the 16 colors produced by pywal in 16 colors mode has it's own saturation value, the saturate_color function just naively changes whatever the saturation value of the color was for the passed one, such function is okay for internal use if misnamed as a better name would be replace_saturation.

for the "external" use (as in the saturation change managed by the --saturate flag) a more intuitive behaviour may be that the passed value is added to the color's saturation value, thus needing a new function something like an add_saturation that does check that the range of saturation is capped within the range of the hsl color space (-100 to 100), i think that would be the solution for saturation as that will (to some degree) preserve the relative differences in saturation between colors while making --saturate 0 be the default value of saturation.

contrast i will need more time to fully understand and internalize how that function works and what it is actually doing.

[eylles]

forgot to push this PR yesterday, this should address the saturation flag and provide a more intuitive behaviour, please take your time, feedback is greatly appreciated

#179