: Best resolutions for display on the web for high resolution image? I have a RAW image taken with a Canon 5D, so the image's resolution is 5,616 × 3,744. I am going to display a different

@Holmes874

You export them at the pixel dimensions you want. Then, for retina displays, you save a copy at quadruple that size, i.e. twice the number of pixels in each direction.

So, if you want a 400x400 image, export it at that size (ppi setting is irrelevant) and then export an 800x800 version for retina displays.

Vote Up Vote Down

@Gail6891361

I don't have solid information on this so I am not sure this qualifies as an answer, but min-device-pixel-ratio appears to be a "flag", like dpi BUT it does not get stored with the image, it is a capability flag of hardware.

An image gets stored by breaking up the image into a grid, where each grid cell is called a pixel (and each pixel is a number represented as a byte). The width and height are also specified as flags: the software reads the bytes as one long chain of numbers, and merely chooses the position of a pixel as it renders, based upon counting and the width/height flags.

At some point, someone decided to specify the ipod screen as a fixed size and the pixel (a discrete number) needed to became flexible somehow. Basically, this means that for the same "visual space" in a pixel ratio 2 device, an image made for 'normal' use needs to be stretched to fit, and stretching tends to look horrible.

The short of it all is that if you envision an image being a certain size for your viewport (say 100px wide), then for a pixel ratio 2 device, you need to provide a copy that is 200px wide. This is so that the pr2 device won't need to stretch the 100px image to fit the same visual space.

The easiest thing to do is to craft everything for PR2 (i.e. make all your images 2x the pixel dimensions that you need) and specify the sizes in css/html. This means you are wasting bandwidth for non-PR2 users, but you only maintain one set of images.

The other way is to work with 2x the pix dimensions, and export a half-size set with a special naming convention such as Yisela suggested. Sometimes this is not acceptable: scaling can blur items especially non-vector type and you will need to work with two versions of the same image, however most of the time there will be no problem.

As far as EXACTLY how big your images should be, this is not an answer that can be given. Your list is a list of min-widths, so your image sizes should be sized based upon the overall size of your site, less margins.



( One wonders what they were smoking when they decided to specify pixels as flexible, since the viewport and display resolutions are also flexible. )

Vote Up Vote Down

@Radia289

The web standard for (non-mobile) images was 72 pixels per inch (according to comments there is non, or if it is it should be 96). At this resolution images will render nicely, as long as they are of good quality, and should not appear pixelated or distorted. Well, as long as they have the same size of their container. Please correct me if I'm wrong, I always assumed this but I've never worked with such high quality images.

When working for mobile, you need to consider the pixel ratio, so instead of 1=1 (something like 'one physical pixel per pixel space'), you have 2=1 (2 pixels in 'the space of 1 pixel'). My images are usually double the size for mobile (and I call them name@2x.jpg as a convention).

Now, about the actual size. It really depends on how you are going to display them. If you want your images to stretch to fullscreen, you will need to provide very big ones that will look good in all the new big monitors. If they will be inside a container, then they only need to be the size of the container (960 x 800px container = 960 x 800px image).

I've never tried that script so I'm not sure how it loads the images, but it looks like it's calling all of them on document load. If that's the case, a mobile device will have to read and download every single one of them just to just show the small one. This will not only be slow as hell (specially if you have a gallery), but will consume lots of bandwidth. But I'm not sure if that's the case here, so check that.

Vote Up Vote Down