3.5 years later… I’m having the same problem as @Webdeersign and it’s driving me nuts.
I have a defined color palette and these colors just don’t seem to hold.
For example: #FF5A00 – I’ve asked a lot of people and they all say it’s an orange color (and so does encycolorpedia.com), it doesn’t seem to be relevant but I will come back to that.
So in RW, Stacks5 and Foundation or Source I select from my palette #FF5A00, using the color picker shows me that the small box in the stack settings has indeed #FF5A00 in it. A container using the color as background shows in the preview window something very very different: color picker identifies it as #EB4426. That color is according to my guinea pigs red (and encycolorpedia.com agree with them). The same red appears when published.
As I’m working with a client and they’re using PMS for print, their printers were so kind to convert the values (with calibrated monitors and such) as close as possible, a HEX palette for me to use.
But when I show them what I have, they freak out as “it’s red and not orange”. They’ve spent a lot of their marketing budget on the colors, branding, printing and what not, so yeah I can explain until I see in the face, to them it’s important.
So I opened Blocs… made a page used the #FF5A00 color: orange!
When I check with web inspector I see that #FF5A00 is ‘translated’ to rgb(255, 90, 0); (and the same values I find on encycolorpedia.com) .
But when I check the RW page: rgb(255, 45, 0).
I understand that how colors appear on the screen are depending on numerous factors, but what I don’t understand is why that same color in the settings is correct but when published not. And that a different program does properly display the correct color.
I’ve had it with a dark grey color as well. A SVG file with a hex background color that looks nothing like the container background where it’s supposed to blend in.
I’m looking for a way how to fix this, quickly and easily. Rewriting everything in CSS code hasn’t my preference. I’d rather rebuild it in Blocs.
As you have noticed, Blocs treats colours correctly. In fact nearly every other creative App does this too. It is no coincidence that they create their own Picker system and do not use the buggy crappy Apple one.
I set all of my colours in the Source Container Base Custom Code area by writing code to set my colours so I know they will be correct.
It always surprises me that this topic is not brought up more often, but I suspect most Weavers don’t notice it and wouldn’t know how to check it anyway.
The issue is that after an event, the colour you add can become corrupted. The event appears to be using the colour picker to pick a colour. After that event, other colours become corrupted until you restart your Mac. This is of course a common event when trying to match colours.
That’s correct.
Apparently one needs a master degree in Apple’s colorpicker for it to work. I thought I had figured it out: when using the ‘color sliders’ next to the drop down (selected RGB sliders) is a circle with three dots in it. It shows a drop down with color profiles. On my M1 MBP I selected the same as my display profile: 'Generic RGB. And then i started adding the hex values, enter to confirm and then drag and drop to the tray below. That worked. Until it doesn’t… While experimenting I had another successful attempt, but that was that the profile matched the profile of my display (Color LCD). For some weird reason that didn’t hold during reboot/restart of RW.
Do I have an alternative? YES! ColorPicker Plus and ProPicker.
I installed Pro Picker first and did that with Homebrew.
And ColorPicker Plus I just copied to ~/Library/ColorPickers.
Pro Picker does not allow hex values as input, but keeps the RGB values consistent.
ColorPicker Plus is older, but it does have hex values and allow to copy a selection of different color values (hex, rgb, hsv, hsl)
The first restart of RW after copying ColorPicker Plus cleared also the Pro Picker tab. After restarting again it just showed up.
I do have ‘allow applications downloaded from: anywhere’ enabled in system settings (privacy & security).
The first time it takes a while when clicking on the color box in a RW/stacks setting, but then the color picker shows up.
Edit: and Gary mentioned it already; in case of an event (using the color picker) weird things happen. So stay of the eye droper tool with the basic macOS color picker 😃
Edit two/too: ColorPicker Plus uses the SRGB IEC61966-2.1 profile. Pro Picker uses Generic RGB.
Generic RGB is what we webdesigners are looking for. The eye dropper gets influenced by whatever stuff is going on with the screen, so that tool is a no-no for me.
I’ve noticed it on several occasions - the first time was when I could not get Seams to work correctly; the colors absolutely would not match up no matter what I tried. I can’t remember what I finally did to rectify the issue, but I think I ditched the stack and used a different solution entirely. It was extremely frustrating.
And this is the point, really. If Stacks Pro is going to position itself as a professional tool — and it should — it needs its own colour picker that does not recalibrate colours. The recalibration of colours by the Apple picker has always been super-annoying, and no serious creative tools use it.
I’m not sure though that the calibration explanation is the correct explanation of the problem.
As I recall this bug, once the event occurs that triggers the bug, if you drag a colour or enter a hex value into the Stacks colour well or hex box, the hex code displayed is correct. The bug is that when that page is published or previewed, the hex code is altered slightly and using Inspecter will show a different hex colour code that the hex colour code entered in the stack.
I’ve been fiddling with this and, like I said jokingly one needs a master degree, as it’s beyond obvious. But here’s how I get this working:
Click the circle with the dots (upper right corner)
Select ‘generic rgb’
Enter values or use color selector, but do NOT use the eye dropper
3a. Hit enter so the value sticks
Drag the color from large box left, to drawer with smaller boxes.
Repeat for other colors (optional)
Starting with what you already have doesn’t produce constant results as it’s the profile that needs to be set first.
When selecting a color In the stack settings:
Click the colored box
Color picker opens
Click the color from drawer (or perform steps 1 to 3 from above and then click the large box once).
Click again the colored box in the stack settings to lock
Do NOT use the eye dropper.
The eye dropper tool will switch the color profile to sometimes the same as the ‘display’ profile, sometimes as the other ‘display’ profile (fP3 or something) and sometimes a random profile. I haven’t figured that out as it requires a full doctorate degree (or it’s bugged).
Could you give this a go @Webdeersign, see if it works for you too? If it does, then the ‘generic rgb’ is key (and the fact that it’s not sticking).
I think you are barking up the wrong tree here. Don’t use the RW colour picker and set colours not set by colour variables using code, and you will not be aware if this bug is triggered or not.
I understand your position in this. As a professional you want consistent and reliable procedures and results. You have found an alternative and reliable way. Though, aren’t you just a little bit curious to see if my steps would get you to an consistent outcome?
I’ve been experimenting with the way you suggested. I’m not sure how I could use ‘named’ colors? For example ’accent’, do you redefine it? Or do use I just define a class, like ‘myorange’ plus assign it a background color, and then use that as custom class instead of ALL the settings where I would normally use the setting ‘accent’ as color?
OK, I’ve just tested this using css custom properties. I defined a color and a class:
:root {
--orange: #FFA500;
}
.orange {
background-color: var(--orange)
}
And then applied it to a ‘Useful Stack’ on a blank theme Stacks page in RW.
Inspecting it with the magnifying glass from the Apple color picker in RW, it registers the color as #FFA51D. Color Slurp shows the same thing. Exporting the page and inspecting the code shows --orange: #FFA500. But examining the page in Chrome with ColorZilla shows… #FFA51D!
But here is where it really gets weird. If I create a new colour variable — --tangerine — and give it a value of #FFA51D, and then make a copy of the Useful Stack just below the first, and apply this new colour to the second stack, then…
the two stacks are exactly the same colour!
(Since there is no space between them, there is just a bigger area of the same orange.)
What’s more, the color pickers see the second stack as being #FFA51D too.
Note that you’re using a different color that the orange one that I was using: FFA500 vs FF5A00.
That’s the calibration at work (and all the other stuff like True tone etc), the color you’re sampling is what your screen is outputting, not what is coded.
FFA500 with the eye dropper becomes F2A93B on my mbp (NOT properly calibrated and all bells and whistles for auto brightness , true tone etc. are on).
F2A93B becomes F2A943.
FFA500 vs FFA51D, but also F2A93B vs F2A943 – It’s a slight difference but depending on ones eyes as I can actually see the difference. For real! this is personal, not objective stuff. It’s like color blindness: one of my car doors was repainted and I thought it was a job well done. A friend of mine then asked me when I was going to get my door painted. I asked him: “Why, it was just done?” He could distinct those colors and I couldn’t (and clearly the painter at the garage neither).
Anyway, we all can agree that the macos eye dropper tool is not to be used for finding out what color someone used on a webpage, photo, anywhere for that matter. Right?
Coding, as suggested by Gary and your example, shows that that works.
I had consistent results now too with the macOS color picker, IF (yeah, a big big IF) one sets the “Generic RGB” profile before entering the color values.
After a bit of experimentation, switching the profile of my MacBook display in System Preferences to ‘Colour LCD’ gets the Apple picker working as it should be, showing the same hex references as were coded. It may not be what anyone else sees (for that we can always preview with different profiles) but it gets around the nightmare of colour matching in RW.
In my system settings I too have ‘colour lcd’. And what about the color profile in the color picker? That’s the one I meant. Can you just ignore that, because that I can’t.
When the System Profile is changed to ‘Colour LCD’, the picker profile doesn’t seem to make any difference. What’s more, when it’s used it seems to go back to its default settings. But whatever it is set to, it seems to recognise colours as what they were set to be, if the System Profile isn‘t changing them.
Yes, that’s when using the eye dropper.
However, when you set the profile (in color picker) and it’s not ‘generic rgb’ then you’ll end up with “other than intended results” on the web page.
