I'm trying to understand how to calculate just how much bigger to make images for 'Retina' quality screens. I understand that the general answer is just 'x2' but it's never explained why this is.
For example, let's take a MacBook Air vs. the new MacBook Pro Retina.
Resolution
MacBook Air - 1440 x 900
MacBook Pro - 2560 x 1600 (this is not simply 'x2', it is x1.77 greater)
PPI
MacBook Air - 128
MacBook Pro - 227 (again this is not simply 'x2', it is x1.77 greater).
Can someone answer, is it simply just a general rule to make things 'x2' or whether that is actually the dimensions needed?
I'd really like this explained rather than just a simple Yes / No. Thanks
The "×2" is simply a rough guideline.
On a "normal" computer monitor (96 dpi), a 200x200 pixel picture would be about 2" wide on the screen, while on a Macbook Pro it would be just under 1". So in order to get the same physical width, it would have to be approximately 2 times as large in terms of pixels.
Related
I'm trying to record our software in Chrome's mobile device emulator. The resolution for the hypothetical device is 1080 x 1920 (vertical orientation). I would like to be able to just record the emulation screen at full resolution. I know I could record my entire screen and just crop for the window showing the software, but then it does not record at the proper 1080 x 1920 resolution and looks blurry. Does anyone have any methods for recording just the emulation screen at full size?
Essentially, I want to record the red boxed area in full resolution (which should be 1080 x 1920)
Chrome Screen Emulation Window
Thank you in advance!!
well, you can't "record" it in 1920/1080 because it literally isn't in that resolution. those pixels don't exist.
A few ideas come to mind -
Record on a 4k (or higher) monitor, the same area will have more
pixels.
if you don't have one handy (and have an nvidia graphics card):
try using Dynamic super resolution
Literally rotate you display and record it in the correct orientation ("portrait"). it will be able to occupy MUCH more screen area, and the cropped-out area will be significantly smaller. therefore, the video dimensions will still be large.
Move away the console (un-dock or just close), make sure the emulator is taking up as much space as possible.
Verify you're recording (and editing and exporting) in the highest resolution possible. that's how it looks like in obs studio:
Maybe use a Virtual Machine if you don't wanna mess up your desktop environment?
from UIImage reference:
#property(nonatomic, readonly) CGSize size
The dimensions of the image, taking orientation into account.
Discussion
In iOS 4.0 and later, this value reflects the logical size of the image and is measured in points. In iOS 3.x and earlier, this value
always reflects the dimensions of the image measured in pixels.
What's the difference between pixels and points in iOS?
A pixel on iOS is the full resolution of the device, which means if I have an image that is 100x100 pixels in length, then the phone will render it 100x100 pixels on a standard non-retina device. However, because newer iPhones have a quadrupled pixel density, that same image will render at 100x100 pixels, but look half that size. The iOS engineers solved this a long time ago (way back in OS X with Quartz) when they introduced Core Graphics' point system. A point is a standard length equivalent to 1x1 pixels on a non-retina device, and 2x2 pixels on a retina device. That way, your 100x100 image will render twice the size on a retina device and basically normalize what the user sees.
It also provides a standard system of measurement on iOS devices because no matter how the pixel density changes, there have always been 320x480 points on an iPhone screen and 768x1024 points on an iPad screen.*
But at the same time, you can basically disregard the documentation considering that retina devices were introduced with iOS 4 at a minimum, and I don't know of too many people still running iOS 3 on a newer iPhone. But if such a case arises, your UIImage would need to be rendered at exactly twice its dimensions in pixels on a retina iPhone to make up for the pixel density difference.
*Starting with the iPhone 5, the iPhone's dimensions are now no longer standardized. Please use the appropriate APIs to retrieve the screen's dimensions or use layout constraints.
The Ultimate Guide To iPhone Resolutions
These guys did an awesome job, take a look here — The Ultimate Guide To iPhone Resolutions.
Using data from http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions I set up the formula sqrt(pointWidth^2+pointHeight^2)/diagonalInches to figure out how many points each phone displayed per inch.
Results:
iPhone 2G, 3G, 3GS, 4, 4s = 164.825201164068082 Points Per Inch
iPhone 5, 5s = 162.9846618550346903
iPhone 6 = 162.8061416117083255
iPhone 6 Plus = 153.535954278463216
As you can tell a point is roughly the same size on each phone. Using the same webopage, you can set up the same formula with the pixel values, and you'll notice large irregularities due to higher pixel densities on the newer phones.
iOS pixels, points, units
We should review them in context of
coordinate systems
absolute and relative positioning
Differences
pixels(absolute) - pixel-based coordinate systems of current screen. Is used in very specific cases. For example CGImage (The width/height, in pixels, of the required image), CGContext
points(virtual pixels, logical pixels)(absolute) - default Point-based coordinate systems. It is a kind of density independent pixel - dp in Android.
units - unit coordinate systems(relative). From 0.0 to 1.0. For example CALayer.anchorPoint
[iOS Frame vs Bounds]
I don't quite understand what the window.devicePixelRatio value is, and how it dictates what size image (2x, 3x, etc) I need for that device.
For instance, on an iMac 5K Retina (Late 2015), I'd expect the pixel ratio to be at least 3 or so, but it's actually 2, the same as an iPad Air and iPhone 6s. Does that mean it prefers a 2x bitmap? 3x?
devicePixelRatio is the ratio between physical pixels and device-independent pixels (dips) on a given device. You can think of dips as what the display "acts" like.
For example: a non-retina 27" iMac has a width of 2560 physical pixels. Everything is displayed 1:1, so it's also 2560 dips wide, so the devicePixelRatio is 1.
On your retina 27" iMac, the width is 5120 physical pixels. But the display "acts" like it's only 2560 pixels wide, so that everything is shown at the same physical size as the non-retina iMac. Therefore, it's still 2560 dips wide, so the devicePixelRatio is 2 (5120 / 2560), and you would serve 2x images.
(You can look up what the dips values are for your system – if you have a retina display – by going to System Preferences > Displays > Display and switching the Resolution toggle to Scaled, then hovering over the different options. For Default, on the 5K iMac, it'll say "Looks like 2560 x 1440").
To date, standard practice for graphics destined for Retina displays is still to provide an image that's twice the usual, non-Retina size.
Reminder: it is good "bandwidth hygiene" to serve an image only as large as needed for the current user's device size and resolution. Solutions to that are outside the scope of this question.
I'm writing Windows Phone 8.1 application (I don't care about tablets and desktops in this case) and I'm not sure which screen size psds should I ask from a graphic designer?
I have read design guidlines for Windows Phone 8.1, I get the system of scaling images and their name convention, but I haven't found the advice which screen sizes should I consider in real?
I got a psd from graphic designer in size 720x1280 and there is a background image. Is it enough?
If I get it right, Nokia Lumia 1520 has a screen resolution 1920 x 1080 so I need also that size, right?
How scaled psds do you usually get from a graphic designer for Windows Phone?
Thank you
Windows (Phone) uses a scale factor depending on the pixel density (DPI) of the device. Therefore, there is no default resolution any longer.
Screens with high DPI get a high Scale Factore applied, so all resources are scaled up together with the (all vector based) UI.
Image assets get automatically scaled up, but you can add the scaled items by hand for better results.
So the answer to your question probably is: Yes, it is enough, but you can add additional higher resolution assets for better results.
Also, Phone Store apps allow you to create bundles, containing only the assets for the device you install the app on (if it is installed from the store), so you don't need to care about package/download size.
See:
Quickstart: Using file or image resources
Guidelines for scaling to pixel density
It depends on whether you are building for Silverlight or Windows XAML.
For Silverlight, all phones are considered to be 480 x 800 pixels (for 15:9 devices) or 480 x 854 pixels (for 16:9 devices). The platform will map each of those effective pixels to either 1, 1.5, 1.6, or 2.25 physical pixels depending on the actual resolution of the panel (WVGA, 720p, WXGA, or 1080p). So all UI designs should be built for 480px wide, but you can build higher-resolution assets if needed.
For Windows XAML apps, the story is more complicated. The effective resolution of phones ranges from 384 x 640 up to around 450 x 800 (and possibly higher), based mostly on the physical size of the device. Scale factors range from 1.0 to upwards of 2.4, and each effective pixel is "bigger" in terms of actual physical size compared to Silverlight pixels.
There is more information in my //build talk
I must be super behind or just super new to the retina displays on MBPs but designing a site for it is just odd. I get that the resolution is 2560x1600 on this 13 inch MBP. So why is chrome only seeing 1296px wide? I feel really silly for even asking but I couldn't ask google the right question to get any real solutions to my question.
The Macbook Pro is one of the devices with a pixel density of 2. This means it packs 2560 (2560 = 1280 * 2) by 1600 (800 * 2) of screen on a 1280x800 physical screen.
Read this Wikipedia list of displays by pixel density.
When designing a site, look at media queries to handle these differences. Here is one relevant question.