[Color Picker] Configurable color formats

[ghost]

Configurable color formats: let the user create custom color formats so they have the complete freedom to create something custom. It would be nice to re-sort the list or to set a format as the default copy-to-clipboard. The format editor would live in Settings.

Pending work from #5379

[Aaron-Junker]

Do you mean for example something like:

red: %r, blue: %b and green: %g

[ghost]

Yes

[niels9001]

@martinchrzan proposed to make these color formats like the PowerToys plug-ins. Contributors can create their own plug-ins that would include all the color conversions. These formats / plug-ins can then be enabled/disabled in Settings, similar to what we currently have.

[htcfreek]

@martinchrzan proposed to make these color formats like the PowerToys plug-ins. Contributors can create their own plug-ins that would include all the color conversions. These formats / plug-ins can then be enabled/disabled in Settings, similar to what we currently have.

Sounds like a great idea. So we don't have any problems with the different ways of conversation.

I think these formats (plugins) should be available in the copy to clipboard and the editor feature.

[micahmo]

@martinchrzan proposed to make these color formats like the PowerToys plug-ins. Contributors can create their own plug-ins that would include all the color conversions. These formats / plug-ins can then be enabled/disabled in Settings, similar to what we currently have.

I'm not familiar with PowerToys plugins... Does this mean that a separate module would have to be written every time someone wants a custom format?

I see custom formats as a very powerful feature. For example, any time I work in a different programming language, I'd like to be able to copy a color to the clipboard in the syntax of that language (like the example in the original post). If a separate plugin has to be written for custom formats, it doesn't help end users who can't either write a plugin themselves or happen to find one that already meets their criteria. Aside from general extensibility, it's practically not much better than hard-coding additional formats into the base application (to the end user).

Hopefully I am misunderstanding the idea. :)

[martinchrzan]

Well it is better in the case that we cannot hardcode milion different formats that people might want. We want to have 2 approaches - either simple snippet as in the original suggestion, so you can format string but you are limited with RGB/HSV numbers. If that is not enough and you need to do some transformation, we can provide plugins - we give you a skeleton project, you just fill in the logic, build and drop that dll in. We could add this scripting experience directly inside the editor, but that sounds like an overkill to build and validate some code inside our application (but not impossible)

[micahmo]

Totally agreed on the extensibility of plugins. I'm just thinking about a user who wants a quick and dirty format without much work. I'm guessing that snippets would cover the vast majority of these cases.

If it's within the scope of the project, supporting both approaches would be awesome! I would vote to prioritize snippets. :)

Thanks!

[Crissov]

I've suggested an approach with predefined codes for parameters and number-types before:

Number formats

• percentages with and without percent sign %% and as either integer %P or floating point number %p.
• floats in the range [0.0, 1.0] with %0. or without leading zero %.
• uppercase [0-9A-F] or lowercase [0-9a-f] single %H / %h or double hexadecimal digits %X / %x Color Picker: Hex toggle between upper and lowercase (and 3-digit notation) #5455
• 8-bit integers [0, 255] %i or [16,240] %I, possibly 10-bit %0 and 12-bit integers [Color Picker] Beyond sRGB #5422 or turned into flats with the respective precision
• angles with %D or without %d degree sign ° or symbol (CSS: deg)
• angle in radians %r (CSS: rad), possibly with a factor of π incorporated %R
• angle in partial turns %t (τ, CSS: turn)
• closest X11/CSS/SVG color name %n, possibly other palettes (e.g. spot colors, Pantone, Crayola, HKS, RAL)

Color spaces and models

• sRGB representations: RGB %R/%G/%B, HSL, HSV, HSI, HWB %H/%S/%s/%l/%V/%I/%W/%B
• optional alpha transparency %A or opacity %a
• wide-gamut RGB [Color Picker] Beyond sRGB #5422 %r/%g/%b: CIE, Adobe, ProPhoto/ROMM, DCI, UHD/Rec.2020/2100, ECI
• CIELab Lab color picker #5440 (1931) %L/%?/%?, LCH %c/%h, Luv (1976) %u/%v, xyY, XYZ %x/%y/%z/%Y
• YUV, YCbCr/PbPr
• CMYK, CcMmYK, CMYKOG via ICC device or interchange (e.g. Fogra51) profiles
• …

Presets

%1 through %9 are just shortcuts to the most frequently used combinations of generic % + number format + component.

[Jay-o-Way]

Does anybody have an estimate if and when this might be implemented?

[htcfreek]

Does anybody have an estimate if and when this might be implemented?

I think whe someone has the time to implement it. I think if you want to work on it, then you can do this.

[NeilSayok]

This is a very good Idea, would love to see in future releases

[donlaci]

Hi everybody,
I've started to work on this issue or better new feature.
I would like to collect ideas about the parametrisation.
What is proposed in the example video - is too few, I think. In a programming world when there is a “custom” possibility than it should allow every possible parameter.
I have extracted from the other color formats the possible parameters, I mean which pop up in the predefined formats. You can find it in the following table. Also added the format, like hex or decimal or percent.

<style> </style>

	byte (0..255)	int	hex	float	percent
Red	X		X
Green	X		X
Blue	X		X
Alpha	X		X
Cyan					X
Magenta					X
yEllow					X
blackKey					X
Hue		double rounded to int
Saturation					X
bRightness					X
Intensity					X
Lightness				X	X
valUe??? (part of the HSV format)					X
Whiteness					X
blackNess					X
chrOmaticity a					X
chromaTicity b					X
X		double rounded to int
Y		double rounded to int
Z		double rounded to int
Decimal value		X

We could allow every parameter in every format with 2 characters after the % character. First is the parameter identifier, second the format, for example %Rb could mean R as red and b as byte format. In the first column, where there are the possible parameters, I have selected a distinct uppercase ‘identifier’ for every parameter, for the formats the b (byte), i (int), h (hex), f (float) and p (percent) could do.
Some examples: %Mh --> Magenta in Hex format, %If --> Intensity in float format.
Eventually every parameter could have its default format and it would be enough to write %R for red (byte) value or %S for saturation (percent value).
With longer identifiers (like %Sat for example) the 'format string' would be more readable, on the other hand many people like type less...

What is your opinion?

Thanks and best regards,

Laszlo

[Crissov]

I proposed a different two-character variable system before.

It’s important to note that almost every component may occur with and without a prefix or, more often, a suffix (i.e. usually a unit symbol, but also # for hexcodes).

Hexadecimal digits may be upper or lowercase, come in nibbles or octets.

Hues are almost always angles, often specified in unit-less degrees, but possibly in radians or something else.

Many other components are either percentages or look like ones: 1.0, 1,0, 100, 100%, but sometimes values outside the zero-to-one range occur.

CMYK should not be supported, because the algorithm used is harmful trash.

CSS prefers OKLab now, which isn't supported here yet.

You’ll quickly run out of single-letter component identifiers.

[jaimecbernardo]

The code for this issue has been released in 0.65. Please update PowerToys to the latest version:
https://github.com/microsoft/PowerToys/releases