Retina Display Vs Normal Display Color Difference

Retina display VS normal display color difference

Make sure none of your image files has an embedded color profile. This can be tricky. For Adobe software, this page is helpful:

http://bjango.com/articles/photoshop/

How do wide gamut color images look on a regular display?

In a color-managed workflow the input source profile will be converted to the display profile to display images regardless of whether the input is sRGB or something wider like AdobeRGB. If the input space is smaller than the display space then there should not be any change in the perceived color. If the input space is larger, then the conversion will use some sort of rendering intent to try to map (or clip) the gamut of the input space to the screen space.

The reason the sRGB images look different than the wider profile images is because the gamut of your monitor is different than sRGB. Regular gamut monitors are not sRGB monitors - they might be similar, but there are not the same. If you are using a relatively new monitor, theres a good chance that it's gamut will extend beyond sRGB in certain areas. So when you convert from a wide space to your screen's space you'll likely see colors that are still out of the sRGB gamut, but within your display's

Does the Retina display eliminate the need for anti-aliasing?

There's no question at all - you still need to do antialiasing mathematics, because of the complexity of curves, second order curves, intersecting curves, and different types of joins.

(Note too that, very simply, since this question appeared two years ago. Retina displays are now ubiquitous and - indeed - antialiasing is, in fact, done everywhere on every Retina display.)

Sure, straight lines (perhaps at 45 degrees) may conceivably test as well in A/B tests. But just look at a shallower line, or a changing differential.

And wait - there's a knock-down argument here............

Don't forget that you can display typography really, really small on a retina display!!!

One could say that you need antialiasing, whenever letter are less than (let's say) 50 pixels high. Thus if you had a crappy 10 dot per inch display ... but the letters were 80 feet high (8000 pixels high) you would NOT need antialiasing. We've just proved you "don't need" antialiasing on a 10 ppi display.

Conversely, let's say Steve's next display has 1000 pixels per inch. You would STILL need antialiasing for very small type -- and any very small detail -- that is 50 pixels or less!

Furthermore: don't forget that the detail in type ... which is a vector image ... is infinite!

You might be saying, oh the "body" of a baskerville "M" looks fine with no antialiasing, on a retina display. Well, what about the curves of the serifs? What about the chipping on the ends of the serifs? And so on down the line.

Another way to look at it: ok, on your typical Mac display, you don't need antialiasing on flat lines, or maybe 45degree lines. further, on a retina display you can get away with no atialiasing on maybe 22.5 degree lines, and even 12.25 degree lines.

But so what? If you add antialiasing, on a retina display, you can successfully draw ridiculously shallow lines, much shallower than on for example a pre-retina MacBook display.

Once again as in the previous example, say the next iPhone has one zillion pixels per inch. Still, adding antialiasing will let you have EVEN SHALLOWER good-looking lines -- by definition, yes, it will always make it look better because it will always improve detail.

Note that the "eye resolution" business from the magazine articles is total and complete nonsense.

Even on say 50 dpi displays, you're only seeing a fuzzy amalgam created by the mathematics of the pixel display strategy.

If you don't believe this is so, look at this writing right now on your Mac, and count the pixels in the letter "r". Of course, it's inconceivable you could do that!! You could maybe "resolve" pixels on a 10 dpi display. What matters is the mathematics of the fuzz created by the display strategy.

Antialiasing always creates "better fuzz," as it were. If you have more pixels to begin with, antialiasing just gives even better again fuzz. Again, simply put under consideration even smaller features, and of course you'd want to antialias them.

That seems to be the state of affairs!

Tile size, retina vs non-retina, iPad vs iPhone

1. I usually try to make my games for iPad screen aspect where I'm making sure that the important elements are in a smaller Safe Zone. And the UI can be anchored on specified distance from the edges. Then for iPhone screen aspect I crop a small portion of the screen and layout the UI accordingly.

So if you are working in landscape here are the sizes you need to support:
480x320 - iPhone (0.5)
960x640 - iPhone Retina (1)
1024x768 - iPad (1)
2048x1736 - iPad Retina (2)

The number in brackets indicate the scale. I just like picking iPad (1024x768) for my ingame units. At this point I have all textures in 3 sizes, since I'm using OpenGL I use different mipmaps for each resolution I need. My texture loading function can skip mipmap levels so that on devices that I don't need high res I safe memory and loading time.

1. Depends if you need to click on individual tiles. In case you need to I'll suggest using 64x64 on iPhone (480x320) 256x256 on iPad Retina (2048x1736). Having all your art in power of 2 is always good. If the size is too large then consider 48x48 for iPhone and 192x192 for iPad Retina. If your game requires you can have smaller tiles but consider having larger active zone around the entities that you have to click (hopefully not every tile will be clickable).

Retina Display background-size: cover

Make the images approximately the resolution of the device. You will likely want to adjust a bit for browser/webclip chrome so the final image size will be a bit different.

See Custom Icon and Image Creation Guidelines for more information.

Additional Background

Retina display devices have a devicePixelRation of 2 - which is the ration of physical pixels to device independent pixels. From quirks mode:

Dips are the abstract pixels that are used to feed information to the
width/height media queries and the meta viewport device-width. They
are best explained by taking a look at the difference between retina
and non-retina devices.

Taking the iPad as an example, if you were to set the viewport to device-width you would end up with (Safari always uses DIPS - see quirksmode):

               DIPS        Physical
               --------   ---------
non-retina:    768x1024    768x1024
    retina:    768x1024   1536x2048

You layout your markup based on DIPS but use images based on the physical pixels (x2 in the case of retinal displays).

Another way to look at this is: since the rule of thumb for retina is 2x the size of an non-retina image, use 2x (768x1024) for retina or: 1536x2048

Also, beware of the real-estate taken up by browser chrome. For example, the status bar takes up 20px from the overall screen.

how retina display is concerned with my css and psd's

For high-resolution screens like retina you may use media queries to provide alternative sprites and images for better results or just let it upscale by its pixel ratio. useful stuff to read https://www.leemunroe.com/designing-for-high-resolution-retina-displays/

UIImage get retina size

UIImage has a scale property that you can use.

UIImage * refimg = [UIImage imageNamed:@"people-there.png"];
NSLog(@"SIZE: %f", refimg.scale * refimg.size.height);

---

Related Topics