My app creates NSImages by compositing various other NSImages together. The original images are loaded from files using [NSBitmapImageRep imageRepWithContentsOfFile:]. The final image is then displayed on the screen.
A few 10.6 customers have reported that the image they see (sometimes) has shifted colors. Specifically, all of the bright colors look dull and washed out. Blue seems to be shifted in the purple direction.
I know this must have something to do with NSImage or NSBitmapImageRep's handling of colorspaces, gamma, or ColorSync? I know there were gamma changes in Snow Leopard.
Does anyone know where I should start? It's hard to troubleshoot because I can't reproduce the problem, but I can see form the customers' screenshots that the colors aren't right.
Anyone seen this before?
Blue seems to be shifted in the purple direction.
This is a bug in Snow Leopard. Anything approximately blue drawn in Generic RGB gets color-incorrected to approximately purple. You can even see this in the menu highlights.
http://boredzo.org/screenshots/SnowLeopard-PurpleIsTheNewBlue-MenuSelections.png http://boredzo.org/screenshots/SnowLeopard-PurpleIsTheNewBlue-MenuSelections.png
(If you don't believe that that's purple, break out DigitalColor Meter. It's most purple near the bottom of the gradient.)
I filed a bug report: x-radar://problem/7542845. I included plenty of photographic and videographic evidence, which you can see in the OpenRadar copy. I invite you to file a duplicate.
It doesn't happen for everybody; if the above image looks fine for you, watch the video, which has the red-shift baked in from the video conversion and shows the difference in DCM.
Snow Leopard changed the default gamma: http://support.apple.com/kb/HT3712
Related
I've been trying to create icons without transparent backgrounds, but I keep getting strange results. For example, when I make icons with white backgrounds, their bottom rows will wind up with yellow pixels.
Steps to reproduce:
Create a square PNG file with solid white.
Right-click on any application and select Get Info.
Click-and-drag the PNG file to the application's icon in the upper-left.
Notice the icon has a strip of yellow pixels on the bottom.
I was having trouble creating Finder icons to match the macOS aesthetic, so as a test, I tried making icons without transparency. But then I ended up with a new problem.
It sounds like what you're talking about is a quirk with the Apple Icon Image format. If you read the Wikipedia entry on ICNS files there is this known issue: "if the last value is a repeating byte (see Compression). Potentially, up to 130 pixels can lack the blue channel value." So, in RGB, if you remove B, you get yellow, which is likely what you're seeing.
I am working with SVG the first time and came across this problem:
I am using some SVGs for icons and everything works fine - except for one icon that renders incorrectly in Firefox on Windows. Firefox on OS X however renders it just fine.
Here is an anonymized version of the header I am placing SVG icons in:
http://files.uiux.de/140618_header/
That problem persists regardless if I use the Sprite utilized in the above example or if I use separate files for each icon.
Here are two screenshots of the render-issue I am experiencing. The problem is that little 'dent' on the lower end of that earphone:
We've saved those SVGs in Illustrator and used SVG 1.1 as export-setting.
Can someone point out what the problem seems to be here?
I'm not seeing that error in the sample header when I look at it with my version of FF (30).
It looks to me as if the artifact/'dent' you are seeing is caused by the left-most column of pixels of the envelope icon next to the phone in the sprite sheet. You can tell if you zoom up the image.
What I do, to make sure things like this don't happen, is to not put icons hard up next to each other in the spritesheet. Leave a few pixels gap between them.
I have an UIImageView with a brown image that will not always reach the top part. The UIImage view is inside a white UIView.
So, because the top part of the image is a linear brown color, I said I will make the UIView underneath it the same brown color, and the user will not see where the image ends. So far, so good.
My problem is, when I pick the color in the top part of the image, the color picker picks a more darker color than actually is there :(
Before I click the color picker:
After I click the color picker:
How comes ?
Just wanted to elaborate upon the accepted answer with some screenshots.
If you want to match RGB values between Photoshop and Xcode exactly (without conversion between colorspaces) then you need to save your images in generic RGB and enter any dropper values using the generic RGB colorspace.
When you choose "Save for Web & Devices" from Photoshop, uncheck the "Convert to sRGB" box.
In Xcode, click the colorspace popup in the color picker and choose "Generic RGB", then enter the red, green and blue values from Photoshop, NOT THE HEX VALUE as this reverts back to the sRGB colorspace for some reason (be careful not to tab to the hex field either, as that also changes the colorspace to sRGB).
More info here, including how to match screenshots.
I've managed to find out a solution/explanation (tho I'm still confused) in this answer: https://stackoverflow.com/a/9203647/460750
Basically, what I did to solve my issues, was to choose from the RGB "types" select (that little square under the color picker) the Apple RGB option, and enter the R, G and B values manually, instead of using the picker.
Odd...
Its because the component numbers don’t spec a color. We also need to know the color space which xCode uses. Colorspace which encodes or decodes is available in the drop down left to the RGB slider.
By default xCode chooses the "Generic RGB" and that is what UIColor uses spec color from RGB. If we use magnifying glass, it will change to "Device RGB” space and that is based on your current screen.
So “sRGB" or "Adobe RGB" would be the better or close to what you want if you are using the magnifying glass to pick a color.
I think Generic RGB also works.
the trick is you need to enter number of R G B manually
after change the RGB mode in dropdown list
Odd... (too)
UPDATE 10.10.4
I had this issue as well, I reported it to Apple, and it seems to have been solved on 10.10.4 (it was related to the color picker itself, not to Xcode/IB)
Can someone else confirm it?
This is an old question, but it was important for me to add some info.
The only method that has been working for me accurately over the years was to not use PS's Color Picker, but use macOS' built-in "Digital Color Meter".
It's bundled with every installation of macOS and the RGB values emitted from there with "Generic RGB" always reproduce the correct color in Xcode Storyboards.
For some reason the selected tab on TextMate is almost un-noticeable, I really cannot make it out, they all look the same to me. When I switch tab I notice it changing color, so I guess it's very very very slightly different, but that doesn't help much.
I've been having this problem for a while, but IIRC it worked fine some times ago — I've no idea what happened to trigger this change.
TextMate 1.5.10, OSX 10.6.8
Any idea?
Your screenshot looks normal to me.
Check your monitor’s “brightness” and “contrast” settings, and possibly your color profile (System Preferences → Displays → Color). On a flat-panel display, there may be a setting which will over-brighten the input signal, causing the top end of the range (light gray to white) to be clipped, so that it is all white (just like overexposure in a camera). There is no good reason to do this ordinarily, especially with a digital input signal, so you should adjust the settings to avoid clipping.
Here’s an image of a black-to-white gradient with a gray border. If a large portion of the left end looks flat white, then you are having that problem.
I built a very simple application with nothing but a single NSTextView in it in xcode / interface builder. I've done nothing to the text view other than change the font face to "Arial" and increase the font size. However, it looks a lot less bold on OS X 10.5 than it does on 10.7. What's going on here?
(10.5 in the top window, 10.7 in the bottom window)
I've tested with Helvetica and got the same results, so it's not something to do with this specific font.
If you enlarge that image enough, you'll see color fringing on the 10.7 sample. This indicates that the text was rendered with subpixel antialiasing, more specifically, using a RGB subpixel ordering. The 10.5 sample uses grayscale antialiasing. While it is generally a good idea to use subpixel rendering, it can look bad on low-resolution screens or CRTs, and it can't be used in a multi-monitor setup where there is more than one subpixel arrangement to contend with. This means that some users will have subpixel rendering enabled for their system, and some won't. Don't try to circumvent that setting in any way, either by overriding the system preference for font smoothing, or by pre-rendering the text into an image. Users are far more likely to notice the one app whose text looks wrong on their system than they are to notice the difference in rendering between two different machines.