Color meter / screen color picker

[crutkas]

There are many times where you have to figure out what color something is on the screen. It would be great if there was a tool to do this which could quickly be invoked.

This tool is directly built into the mac

Things it could display:

• Hex
• RGB would be helpful.

Bonus points:

• Having it go into the DOM and extract out Alpha/exact color or if it was maybe doing something like Acrylic.
• History of past colors

[niels9001]

A native colorpicker would be super helpful for (front-end) developers and designers. Here's a UX concept with an article that explains some of the details: https://medium.com/@Niels9001/a-fluent-color-meter-for-powertoys-20407ededf0c

Description	Priority
Colorpick any color from any application on the screen	Should
Display Hex color code	Should
Display RGB color code	Should
Copy to clipboard	Should
History of earlier selected colors	Could
Customizable color formats / snippets	Could
Show range of colors related to the selected color	Could
Allow for tweaking of colors (e.g. changing brightness)	Could

One idea I had was to make the color codes configurable in the Settings screen: developers could define their own color snippets so it's useful for any coding language.

WinUI code of the concept is available here: https://github.com/niels9001/ColorPickerUX

[crutkas]

Big q is how do we do the sampling and then bubble that back to the control

[crutkas]

From issue #4403, @martinchrzan has a possible base. I know our interns also had two possible bases as well. https://github.com/martinchrzan/ColorPicker

@martinchrzan, lets sync!

[crutkas]

@martinchzan, crutkas@microsoft.com is my email.

[niels9001]

Updated my earlier comment with an updated requirements list and new UX mock-up.

[andreas-schwanke]

This PowerToy would enable many people to do their tasks with a really good tool!

[NeelAPatel]

This is a really well made concept, I hope this can be made and implemented soon! Super useful!

Might i suggest adding a way to edit the colors after selecting?
And maybe being able to save some colors into a pallette memory, and then changing their overall brightness and such.

[niels9001]

This is a really well made concept, I hope this can be made and implemented soon! Super useful!

Might i suggest adding a way to edit the colors after selecting?
And maybe being able to save some colors into a pallette memory, and then changing their overall brightness and such.

Something like this?

[billhenn]

An app like this would prevent me from having to keep Photoshop open all the time to screenshot something, paste in the screenshot, zoom in, use eye dropper, open the color dialog, and copy the hex code. What a tedious process. I love this app concept idea, and it's beautiful to boot.

[martinchrzan]

@BillHenning Before we have that in PowerToys you can already use my tool to simplify exactly your workflow - https://github.com/martinchrzan/ColorPicker

[Ziilongg]

I am so excited! Simple, beautiful and smooth! I am pretty sure this is the only color picker I have been looking for for a long time. Looking forward to seeing it in future PowToys!
In addition, could you please consider adding the function of color name recognition in the future? Provide help for some people with color recognition disabilities.

[Jay-o-Way]

An app like this would prevent me from having to keep Photoshop open all the time to screenshot something, paste in the screenshot, zoom in, use eye dropper, open the color dialog, and copy the hex code. What a tedious process. I love this app concept idea, and it's beautiful to boot.

Ha ha, I use Paint for that. But okay, that is also the same load of manual work 😕 Not even mentioning converting hex to RGB or something.

[Jay-o-Way]

In addition, could you please consider adding the function of color name recognition in the future? Provide help for some people with color recognition disabilities.

You mean something like this? https://en.wikipedia.org/wiki/Web_colors

[htcfreek]

@niels9001
Your concept looks great. But I ask me, "why do you show different colours in the colour bar in the top and which of them is the scanned colour"?

[crutkas]

@niels9001
Your concept looks great. But I ask me, "why do you show different colours in the colour bar in the top and which of them is the scanned colour"?

Idea is a history of past items.

[niels9001]

@htcfreek The vertical list are the previously picked colors.

The horizontal bar includes the picked color (the large one in the middle) and additional colors that would fit in the palette. This can be helpful in situations where you e.g. want to pick a color for a button but want to have a slightly darker tone as well (for the hover or pressed state). You can see other apps doing this, but definitely a 'nice to have' for this feature request.

[NeelAPatel]

Great concept @niels9001 !
Just one last concept improvement and I think we have a solid MVP concept :D

I think the selected color (middle "large" bar) should have some indicator at the top and bottom to signify its the color you picked for visual clarity, just a simple line will do. No line on the left and right of it still lets you compare colors easily.

[mdtauk]

Selected Indicator could match the Navigation view

[martinchrzan]

I just created a PR for new Color Picker module, taken from my project - https://github.com/martinchrzan/ColorPicker

I suggest a following approach and UX changes to the solution proposed by @niels9001:

1. Now we have a simple color picker which I consider already very useful and can be released as the first version.
2. Next, I can start to integrate @niels9001 concept with following changes:

• Most of the time, I (probably not just me) just need to copy some color from a screen - the current implementation allows me to do that very easily - press an activation shortcut, find the color, click - done! (color is copied in the clipboard).
  Therefore I would find it unnecessary time consuming to open this color editor, click that I want to pick colors (this editor might be in a way sometimes, so I would need to move that window) or start configuring already picker color - it is sometimes too many clicks.
  For this reasons I suggest we have an option in the settings like (with a more sensible description :)):

User can choose:

• Follow the current behavior (quick) - open color picker, click to copy
• New behavior (more customizations) - activation shortcut opens the editor as @niels9001 suggested where you can decide to start picking a color or do any other configurations

If this sounds good to you, I can start integrating @niels9001 concept in a suggested way.

[niels9001]

@martinchrzan Awesome :)! Are you planning to use WinUI/XAML Islands for this? This might be a nice start to transition towards WinUI 3 when rolling out later this year and we get a lot for free: theming support, nicely styled controls etc.

Agree with the colorpicker mode - it would be nice to have a 'quick mode' vs. opening the editor.

For the window getting into the way, here's possible solution:

• Shortcut to bring up the colorpick window.
• Click on the colorpick button. Windows disappears and mouse turns into the colorpicker.
• Pick color, on mouse button release the window opens up again.
• Clicking X would close the window.

I'm happy to contribute on this for anything XAML related. Above concept is entirely built in UWP/WinUI so we could re-use some XAML).

I'll put in some work to mock-up the settings based on your suggestion. I think using the same logic like we do with ImageResizer could be very powerful to create custom code snippets.

[martinchrzan]

Absolutely! It is WPF currently, but we can bring XAML Islands or WinUI (however I am not sure about the stability of WinUI 3.0, guys on Build said that it should not be used in a production this year, but we can definitely experiment with that)

Yes. that would work.
One more comment, I noticed in your concept, that you are picking colors when you release the button, we might want to change it to a behavior which I am using - you see the color preview all the time and only one mouse click will select/copy it. If you have to hold your mouse button while picking the color, it will cause lot of other interactions in the system - like dragging stuff around, selecting items, text etc in the apps from where you are picking the color.

These are just details, otherwise it looks great! I hope to start looking into it later next week.

[crutkas]

I would suggest pure WinUI not an island here for perf startup reasons.

[htcfreek]

What do you think about having a small arrow ^ or dot • under and above the scanned colour to mark it as the detected colour?

Like this:

          ↓
---- ---------- ----
          ↑

[htcfreek]

User can choose:

• Follow the current behavior (quick) - open color picker, click to copy
• New behavior (more customizations) - activation shortcut opens the editor as @niels9001 suggested where you can decide to start picking a color or do any other configurations

@niels9001, @martinchrzan
What about having both methods (copy and colour editor) available at the same time? When the user press left mouse button the colour gets copied and if the user press shift + left mouse button the colour editor get opened.
This can be another option to choose and maybe the default behaviour too.

[htcfreek]

@martinchrzan I added a settings mock-up to my original mock-up to explore the how to create and update snippets. https://github.com/niels9001/ColorPickerUX.

These would save to the settings file and synced with the color picker window for easy copy-to-clipboard. The markup is similar to what we now have in ImageResizer.

Thoughts?

@niels9001 @martinchrzan

• The idea to let the users add own snippets is good. But we should split them into groups like colour type and code snippets.
  Or will the snipped only be used for code snippets?

• Could we have a setting to let the user choose the default format (RGB, HEX, ...) used for copy to clipboard?

[niels9001]

![Colorpicker_Twitter]

What do you think about having a small arrow ^ or dot • under and above the scanned colour to mark it as the detected colour?

Like this:

          ↓
---- ---------- ----
          ↑

I think, for a first version we'd be good with just a single color since generating a palette would involve some algoritms to pick logical shades. This proposal for the Windows Community Toolkit tweaked the design a bit, might be useful here as well:

User can choose:

• Follow the current behavior (quick) - open color picker, click to copy
• New behavior (more customizations) - activation shortcut opens the editor as @niels9001 suggested where you can decide to start picking a color or do any other configurations

@niels9001, @martinchrzan
What about having both methods (copy and colour editor) available at the same time? When the user press left mouse button the colour gets copied and if the user press shift + left mouse button the colour editor get opened.
This can be another option to choose and maybe the default behaviour too.

Feels complex to me. We could have two toggles: 'Copy to clipboard' (true/false) and 'Open editor' (true/false). If we are supporting multiple color formats we need to ask the user which format they want to copy to clipboard.

@martinchrzan I added a settings mock-up to my original mock-up to explore the how to create and update snippets. https://github.com/niels9001/ColorPickerUX.
These would save to the settings file and synced with the color picker window for easy copy-to-clipboard. The markup is similar to what we now have in ImageResizer.
Thoughts?

@niels9001 @martinchrzan

• The idea to let the users add own snippets is good. But we should split them into groups like colour type and code snippets.
  Or will the snipped only be used for code snippets?
• Could we have a setting to let the user choose the default format (RGB, HEX, ...) used for copy to clipboard?

Maybe snippets is not the best word here. It's basically a format you can define yourself. Could be code, could be a just the RGB or HEX values. Or, if you have some proprietary way you want to format the code - this solution will support all variants, which is nice IMO.

[htcfreek]

![Colorpicker_Twitter]

What do you think about having a small arrow ^ or dot • under and above the scanned colour to mark it as the detected colour?

Like this:

          ↓
---- ---------- ----
          ↑

I think, for a first version we'd be good with just a single color since generating a palette would involve some algoritms to pick logical shades. This proposal for the Windows Community Toolkit tweaked the design a bit, might be useful here as well:

Not sure if the bold bar indicates that this is the detected colour. But it can indicate that this is the main colour and the others are generated based on the main colour.

User can choose:

• Follow the current behavior (quick) - open color picker, click to copy
• New behavior (more customizations) - activation shortcut opens the editor as @niels9001 suggested where you can decide to start picking a color or do any other configurations

@niels9001, @martinchrzan
What about having both methods (copy and colour editor) available at the same time? When the user press left mouse button the colour gets copied and if the user press shift + left mouse button the colour editor get opened.
This can be another option to choose and maybe the default behaviour too.

Feels complex to me. We could have two toggles: 'Copy to clipboard' (true/false) and 'Open editor' (true/false). If we are supporting multiple color formats we need to ask the user which format they want to copy to clipboard.

With two toggles we could get in trouble wen both are set to true. The the trop down is good.

My intention was that I generally need to copy the colour but sometimes I need more options when I developing. So then I would click Shift+Mouse button to get your editor window instead of copy the colour code.

@martinchrzan I added a settings mock-up to my original mock-up to explore the how to create and update snippets. https://github.com/niels9001/ColorPickerUX.
These would save to the settings file and synced with the color picker window for easy copy-to-clipboard. The markup is similar to what we now have in ImageResizer.
Thoughts?

@niels9001 @martinchrzan

• The idea to let the users add own snippets is good. But we should split them into groups like colour type and code snippets.
  Or will the snipped only be used for code snippets?
• Could we have a setting to let the user choose the default format (RGB, HEX, ...) used for copy to clipboard?

Maybe snippets is not the best word here. It's basically a format you can define yourself. Could be code, could be a just the RGB or HEX values. Or, if you have some proprietary way you want to format the code - this solution will support all variants, which is nice IMO.

Then we need categories if you want to split the colour picker ui into a list for colour and one for every code type or maybe "custom code snippets".

[martinchrzan]

@htcfreek suggestion does not have to be complex, we can always copy on left mouse click, but when you hold shift it will also open the editor (and copy the color as well) - with that we wouldn't need any setting at all and user wouldn't need to choose if they want to use "quick" or "configuration" mode for the color picker. That might be even better approach as you wouldn't have to go setting if you want to change the mode sometimes.

Regarding those snippets:
I was a little confused about where are these snippets used. Maybe we should call them something like "color format/representation/..." as a "snippet" would indicate some script that is executed (at least to me).

We might want to indicate somehow, which format will be used (some default) if you use just copying files without opening the editor.

There are also some restrictions regarding the color format. I am for example unable to get Alpha for the color as it would require some crazy algo which would look inside the app where you point at to grab the color. As there are tons of different technologies to draw stuff on your screen I deem this close to impossible.

[mdtauk]

Some thoughts for a possible future expansion...

ColourPalettes.Analagous
              .Monochromatic
              .Complimentary
              .SplitTriad

etc

You could include a tab for generated Palettes using colour math and colour theory, similar to Adobe Color.

[martinchrzan]

@mdtauk I am not sure if this goes to the same direction as an idea behind this tool.
My understanding was to have a simple and quick tool where you can just grab a color on your screen and use it. Now we are getting into building a new Photoshop :)

[htcfreek]

Regarding those snippets:
I was a little confused about where are these snippets used. Maybe we should call them something like "color format/representation/..." as a "snippet" would indicate some script that is executed (at least to me).

@martinchrzan
They meant also code snippets.
In @niels9001' mockups you can see the code examples for c#, ...

[mdtauk]

@mdtauk I am not sure if this goes to the same direction as an idea behind this tool.
My understanding was to have a simple and quick tool where you can just grab a color on your screen and use it. Now we are getting into building a new Photoshop :)

Fair enough!

[niels9001]

@htcfreek suggestion does not have to be complex, we can always copy on left mouse click, but when you hold shift it will also open the editor (and copy the color as well) - with that we wouldn't need any setting at all and user wouldn't need to choose if they want to use "quick" or "configuration" mode for the color picker. That might be even better approach as you wouldn't have to go setting if you want to change the mode sometimes.

Regarding those snippets:
I was a little confused about where are these snippets used. Maybe we should call them something like "color format/representation/..." as a "snippet" would indicate some script that is executed (at least to me).

We might want to indicate somehow, which format will be used (some default) if you use just copying files without opening the editor.

There are also some restrictions regarding the color format. I am for example unable to get Alpha for the color as it would require some crazy algo which would look inside the app where you point at to grab the color. As there are tons of different technologies to draw stuff on your screen I deem this close to impossible.

Good comments - I agree, let's leave out Alpha (for now). Or at least default it to '1' at always.

We could maybe use the Windows Snip model (try Windows+Shift+S)?

• Hit keystroke to start colorpicking
• Pick color
• Notification shows what color was selected and in what format it was copied to your clipboard.
• Clicking the notification would open the 'editor'.

Holding shift while colorpicking would open the editor and would not show a notification?

[htcfreek]

@htcfreek suggestion does not have to be complex, we can always copy on left mouse click, but when you hold shift it will also open the editor (and copy the color as well) - with that we wouldn't need any setting at all and user wouldn't need to choose if they want to use "quick" or "configuration" mode for the color picker. That might be even better approach as you wouldn't have to go setting if you want to change the mode sometimes.

Regarding those snippets:
I was a little confused about where are these snippets used. Maybe we should call them something like "color format/representation/..." as a "snippet" would indicate some script that is executed (at least to me).

We might want to indicate somehow, which format will be used (some default) if you use just copying files without opening the editor.

There are also some restrictions regarding the color format. I am for example unable to get Alpha for the color as it would require some crazy algo which would look inside the app where you point at to grab the color. As there are tons of different technologies to draw stuff on your screen I deem this close to impossible.

Good comments - I agree, let's leave out Alpha (for now). Or at least default it to '1' at always.

We could maybe use the Windows Snip model (try Windows+Shift+S)?

• Hit keystroke to start colorpicking
• Pick color
• Notification shows what color was selected and in what format it was copied to your clipboard.
• Clicking the notification would open the 'editor'.

Holding shift while colorpicking would open the editor and would not show a notification?

Why so complicated?
In @martinchrzan's we have the following behaviour:

1. Press shortcut to enter detect mode. (In detect mode you can zoom. - That's q great feature.)
2. Press mouse button to copy colour to clipboard.
   (Here we could have shift+mouse button to open edit window instead.)

[niels9001]

@htcfreek Sure, we'd need to be clear what format/snippet is currently selected and is copied to the clipboard. That's currently missing. But we can probably state that in the settings.

[htcfreek]

@htcfreek Sure, we'd need to be clear what format/snippet is currently selected and is copied to the clipboard. That's currently missing. But we can probably state that in the settings.

@niels9001, I have read your comment before to fast and didn't see the last sentence.

In general the idea with the notification including colour and format sounds good to me. Then the user knows that colour is copied. But we should have a button to open editor or write "click to open in editor" within the notification.

[NeelAPatel]

@martinchrzan I took a look at your gif demo and I wanted to bring some things to light that can be an improvement to your colorpicker as well as its implementation here:

• Not immediately obvious how big of an area will zooming in captures, having a square hover around with cursor as its center will help. Currently all you see is a cursor and then zoom in will capture an area of screen.
• Consider allowing changing the size of the square as well?

Thought process:
trigger ColorPick => Zoom to select area capture size => click to select => zoom to increase granularity of capture => click to actually select the color

I feel like its possible to condense this process into a 'trigger => select' two click process but that can be saved for later.

(hopefully i can learn the code stack and eventually contribute to powertoys one day!)

[martinchrzan]

@NeelAPatel you should try it to, to see the interaction :)

You always see the color of a pixel you are currently hovering, if you like it, just click - if you cannot hit the exact pixel immediately, scroll and a small area around the pixel you are trying to hit will become bigger. You always do only one mouse click, this is the fastest approach.

Why do you need to know what will be the size of a zoom area before you zoom? When you are zooming it means that you want to pick precise pixel around your cursor - currently, it is a 50px square around your cursor that you can zoom in. If you want to zoom some different part of your screen, just unzoom (mouse scroll opposite direction) where you are currently, move your cursor and zoom again.

[niels9001]

@crutkas Would it make sense to create a specification for this feature (not sure if it's already there) like there is for Launcher and KBM?

I know there's some work going on already - but it might streamline the discussion a bit and have some definitions of things we want to target for 1.0. Happy to work on that.

[Rubenzoom]

It would be nice to have a color spectrum wheel/square like this one:

[crutkas]

@crutkas Would it make sense to create a specification for this feature (not sure if it's already there) like there is for Launcher and KBM?

I know there's some work going on already - but it might streamline the discussion a bit and have some definitions of things we want to target for 1.0. Happy to work on that.

Wouldn’t hurt but this was supposed to be a v2 item. I just don’t have cycles to create it for next few months.

[Crissov]

All the mockups and examples in here apparently assume 8bit sRGB. Wider gamuts and higher bit depths are becoming more normal these days and should be supported from the start.

Also, CSS has a lot more notations on offer: RGB, HSL, HWB, Lab, LCH.

Please note that some terms, e. g. hue H and saturation S, are used by different notations or color models with slightly different meanings and values.

[crutkas]

@niels9001 / @martinchrzan we should create a new issue for the updated UX for picker as this issue has been resolved

[crutkas]

We just released 0.20 and this should be resolved there. Please try it out.

[htcfreek]

We just released 0.20 and this should be resolved there. Please try it out.

Rigth. But I think we should let it open to not loose the ideas for optimizations.

[crutkas]

@htcfreek, we xref and directly comment about them in the issue. Issues have to be tangibly closable.