Photoshop having issues retaining specific color values...

[Under S.]

Hi! Hope y'all had amazing holidays.

First, let's establish that the foreground color picker doesn't seem to have any issues remembering specific shades. For instance, if I choose hue/saturation/brightness levels of 218/72/70, those are the exact numbers I'll see when I next click the foreground color picker.

Easy-peasy.

But when I try applying that same color to a line object (like a simple rectangle), hitting OK and re-opening that dialog reveals the color has slightly shifted. Not by much, and not randomly either : every time I try entering 218/72/70 (aka HEX 3261b3) it consistently shifts to 218/69/68 (HEX 3662ae). 

I understand that PS isn't Illustrator and doesn't treat colors the same way (it interprets pixels), but if the foreground color picker can remember 3 specific values in the working file, why can't line objects created by Photoshop itself? At the very least, why not retain them during the creation process, even if the final output will be an interpretation? I even tried switching to PANTONE library values, and it's not remembering those either (presumably because the slight "color shifts" are just enough to cause PS confusion about what exact PANTONE I'm targeting).

Am I just coloring these objects the wrong way?

Currently, I color line objects by double-clicking the tiny thumbnail on the left of that layer (which pulls up color picking options). Would I be better off coloring via live FX, maybe? [NOTE: Figured I'd just try it while typing this, and I can confirm that the color shifts there too; so it's pretty much everywhere except the foreground color picker dialog, which seems to be the only one retaining the precise numeric HSB values I entered, and the same HEX every time I go in there.]

These color shifts aren't big enough for the naked eye to notice, so I can live with them if I have to. But if there's a way to make all these dialogs remember specific HSB values instead of re-interpret colors every time they're pulled up, I'd love to know.

Just once, I'd like the HEX value I assigned to a rectangle to still be there when I go back in to verify the color.

Is this a pipe dream given how PS works?

Should I just live with the shifts as long as I'm working in PS?

[Cynetix]

A couple of things I would like you to check:

1) Your colour space, are you working in, say Adobe RGB, a some smaller subset or something else entirely?

2) How are you checking the colour?

I can't quite tell from your description how you are checking the colour. If you are using the colour picker remember that it can be set to take an average across several pixels. So, if you are targeting a small set of pixels, for instance a low resolution line, it could be catching the aliased pixels which would shift the values you are sampling. If you have the colour picker set to a single pixel then you might not be hitting the right pixel in an aliased set of pixels. In fact, if the line is so low res then what you are explaining could happen as none of the pixels may be correct, instead the average may be an interpretation (like you suggest).

If you create a large block of colour and sample that right in the middle, is that the correct RGB values?

Pictures could tell us more, please provide us with screen shots of you creating the object, with the entered values, and then you checking them.

At the end of the day, and you sort of acknowledge this in your post, if you're designing for screen it's never going to look the same across the board anyway. So as long as it "looks right" then I wouldn't get too hung up on the precision...but it would be nice to get to the bottom of it 🙂

[melissapiccone]

Not clear on what you are doing, but if you are using the eyedropper tool to select your color, what do you have the sample size set to? I'm guessing it is giving you an average or your color is not all one solid color.

[D Fosse]

Jpeg?

The jpeg compression will often shift values slightly. The compression algorithm compresses the chroma component much more aggressively than the luminance component.

[davescm]

There is something very wrong here.

The RGB values and Hex values should be the same numbers as decimals in RGB and converted to base 16 for Hex

So RGB 218/72/70 = Hex da4846.   (not Hex 3261b3 which is RGB 50/97/179)

Similarly RGB 219/69/68 = Hex db4544  (not Hex 3662ae which is RGB 54/98/174)

What colour that represents will depend on the colour space i.e. those same numbers will look different in different colour spaces. You may get a shift due to colour spaces if you try and use out of gamut colours but you should also see a warning of that.

If those Hex numbers and RGB numbers are as you show on your system I would do a preference reset. If they match as I describe but you see a shift then please tell us what color space you are using.

Dave

Edit : Sorry - I've just realised you were using HSB not RGB - ignore my comments above

[Test Screen Name]

I see you're working in HSB. HSB doesn't really exist, and certainly can't be stored in an image. It is immediately turned into RGB. When the RGB is turned back to HSB, the answer may not be exactly the same (since, multiple RGB values may map to the same HSB value, or vice versa).

[Under S.]

This is the best explanation I've seen for what's happening. But what's the solution?

Say I have the exact color I want to "cement" in front of me in the traditional PS Color Picker; and it reads as HSB 218/72/70, aka HEX 3261b3, aka RGB 50/97/179, aka Lab 41/6/-49, aka CMYK 85/66/0/0 (these are ALL the non-library numerics provided by the PS Color Picker for that specific shade of blue).

When I save and go back, the color shifts slightly. Most won't see the difference, but I do. When I then manually "fix" the numeric values (whether HEX or HSB) back to what I put in, I can SEE the color shifting back to where it should be. It's very subtle, but of course the numbers confirm that the difference isn't in my head. 

I'm just trying to keep it on that specific shade I want and it won't. Do I need to focus on Lab, RGB or CMYK values to achieve this? I just assumed ALL these values shift with the HSB/HEX, and that there was a better way to assign a specific color that won't shift.

Thanks!

PS: Working in 8-bit CMYK (US Web Coated SWOP v2) if that helps. I'm trying to create a very specific gradient and this blue is one of the stop colors. Unfortunately, I can't get one stop color to stop shifting, let alone two. (But the issue has nothing to do with gradients, I troubleshot the issue with this single flat color on a rectangle and it still happens.)

[D Fosse]

OK, two things: Please forget HSB. It's relative to absolutely everything, the variables are too many to mention. You simply cannot establish a consistent procedure using HSB. It's all to the wind. Use RGB numbers in a defined color space! That's sRGB, Adobe RGB, etc. It's the only way to work on firm ground.

Second, CMYK also changes the rules because you need to consider gamut clipping. You always need to consider gamut clipping, but especially in CMYK. The gamut boundaries are significantly different.

That blue color is probably just out of gamut in US Web Coated (SWOP). I say probably because there's no way to know, when starting from random HSB numbers. I have no idea what color space your original file is in, and so it's impossible to know what those numbers actually refer to.