I created a black and white collage consisting of a number of images - but saved the file as 1280*1024 - ideally encompassing that rez of a screen.
The issue is, would it be wiser to have the background scale, and stretch the images in the case of a larger screen or should I have it repeat so as not to lose resolution, and have smaller screens cropped from some of the background?
Thanks for any insight!
I personally don't think scaling an image up is ever an option. It's incredibly noticeable, and it doesn't look good. I would recommend using a background image that at least works on 1920 x 1080, and gracefully fade out the image on the edges or tiles well so if someone sees the page on an even larger screen, there aren't strong lines on the edges of the background.
If you are concerned about the bandwidth involved in large images, check out CSS3 Media Queries. All mobile browsers support this CSS3 module, and it will allow you to target certain resolutions and send them smaller images (both in dimensions and file size).
If your image does tile well, I would recommend going with the smallest pattern, and letting css do the repetition for you. There's no point in pushing more pixels down the pipe than necessary.
It's up to the user really but they obviously can't make that decision. I'd scale it but that's not as easy as tiling it. I've never successfully scaled a background image.
It will also depend on your preference.
Are you okay with having a stretched image as a background, in case the user has a larger screen? If yes, then by all means set the background image to stretch. Or, are you more keen on preserving the integrity of the image? In the latter case, it's much better to have the image tile.
If you're interested in creating a full page background image, try one of these techniques found on CSS Tricks: "Perfect Full Page Background Image".
Related
I've got a couple questions about the use of images in a html document that I couldn't find an answer for.
Why is the standard 12x12 / 24x24 / 48x48 / 96x96 /... and not 8x8 /
16x16 / 32x32 / 64x64 / ... ?
Why is a 130x130px image resized to 50x50px by the browser (by
setting its width/height in the html doc) going to be more blurry
than a 100x100 image resized to 50x50 ? (is it just easier for the
browser to divide the size by 2 ?)
Is there a specific resolution for images that is worth using over another to be
more 4k friendly ? For instance using 384x384px images instead of
96x96 for 4K screen owners ?
1. Why are there icon size standards?
First of all there are no "standard" sizes for icons but it is always a good idea to create icons with a equal ratio = square images. That does not mean you are not allowed to break the rules, but it depens for which medium you are creating the icons. Android using a differend base size then iOS, because they need to support different resolutions. For desktop it is always good to start from a scale of 16px as a base. reference for icon sizes
2. Why get images blurry when resizes?
Image you are the browser and you need to repaint your 120x120px pixel image into an 50x50 canvas. The problem you face right now is that you need to decides on several point which color to choose especially on edges? What the browser does ist to mix up colors for edges where he knows there is not more enoug space to display it crisp. This is causing the "blurry" effect. No think about resizing the 120x120 to the half. Thats a lot more easier because you dont need to mix colors anymore. Or in more technical term:
Well rastered images when scaled in either direction are going to have some anomalies. When you make them bigger, it’s obvious – things get pixelated quickly. When you shrink them down, whatever is rendering it has to guess on what pixel goes where. https://css-tricks.com/forums/topic/scaling-down-images-with-css-makes-them-blurry/#post-188194
3. Are there a specific resolution for images
Thats basicly a very good question and opens the topic of "responsive" Images. As you know the pixen density on 4k Monitors / Smartphones is a lot higher then on regular screen. The fact that images cannot scale the informations by themself makes them pixelated when enlarged and blurry when shrinked. Best case would be to use SVG as often as you can, icons are best usecase for icons. Normally just putting the bigges image online would do the task, but performancewise it would be catastrophical. If you want to master this topic I can give you some good links to dive in:
https://css-tricks.com/optimizing-large-scale-displays/
https://css-tricks.com/responsive-images-css/
Hope thats answers, at least, a bit of your worries :)
On a webpage I am rendering a collection of images. Some images are portrait orientation, some are landscape, all are larger than the desired render size.
I want to display these images in a gallery of neat, uniformly sized, square thumbnails.
How can I do thus using only CSS?
I would like to avoid a javascript library if possible. I don't need to select a part of the image to display, just any central-ish square area.
I've seen this question asked elsewhere, but have not yet found an answer that seems to work with all orientations (e.g., portraits may get correctly cropped/resized, landscapes do not).
You could still use server side technology to resize the image via cURL; however, that is neither here nor there. One thing to understand, CSS is not really a programming language, as in, it cannot make decisions or do any real math, so we can't make dynamic decisions with just CSS.
That being said, you could create divs for your gallery, and use CSS to set the background image to the desired image. In CSS3 there is a property called background-size. You can set the size in pixels manually, but it will not maintain aspect ratio that way, so it will probably look awful. Setting the background-size: cover will scale the image so that it completely fills the background area while cutting off the excess. Setting background-size: contain will scale the image so that it maintains its original aspect ratio and fills the background without cutting off the image. Here is a little code that kind of explains how to use it. jsFiddle
EDIT: I forgot to mention that this solution will only work in IE9+ (should work fine in FF, Chrome and Safari)
I suggest having a div wrap the images. You can specify a width and height on this wrapper with a overflow:hidden.
See this:
http://real-sense.com/index.php?option=com_content&view=article&id=106
The set of vertical images on the right are being resized using CSS
.thumbnail-product-resize
{
width:144px;
height : auto;
}
Does anyone know how to do this in a cleaner way so I don't lose quality on the image?
I mean that if I had resized the image using photoshop, the text won't appear as blurry as it does here.
Tested in FF
Thanks
The quality of your images will depend on the original size of the image you use. If have a large image with good quality, say of size 400x500, and it is then resized in the HTML to 80x100, it will still be a 400x500 image. However you can only fit a certain number of pixels on a smaller image of 80x100, so this bigger image has to be sampled. This means that an average is taken of pixels and then made to represent a 80x100 size image.
If you want a more definite result you can change to original size of the image to 80x100. This will probably give you better results.
Once upon a time browser image resizing gave truly heinous results due to the unsophisticated nearest neighbor technique they used to scale images. Now they usually perform filtering when scaling and there isn't that much difference between in-browser resizing and resizing in Photoshop.
The real advantage to scaling an image before serving it to the client is that you aren't forcing the download of large images when they aren't necessary. Depending on the size of your images, this can significantly reduce your page load times.
One final thing to consider is that more and more people have devices with "retina" displays. For those users scaling the image before serving it will result in much less crisp images.
Here's an in-depth comparison of the image scaling methods used by various browsers: http://entropymine.com/resamplescope/notes/browsers/
Even if you had done this in photoshop those images you have would still appear pretty much the way do just now.
FYI you don't need to include height:auto in your CSS above.
Best bet would be to create a seperate set of thumbnails (using photoshop) which maybe just show a portion of the image.
Loading the thumbnails and resizing them with css the way you are doing is bad practice as you are still having the user download the large images first.
It is impossible to shrink an image without loosing quality unless it is an vector-image. That would mean that you'd have to use SVG. And considering the images displayed I don't think you wan't to do that.
Also you mentioned the cleaner way to do it, use photoshop or something similar.
When I'm scaling down big images using canvas and drawImage method, the result is far from perfect.
Compare this images. Left one is actually the canvas with scaled image and the right one is a desirable result. Original of this images is 1600x900 photo. Scale goes from original size to 200x113.
When original image have less width and height or scaling ratio more (ie 0.5 - 0.9), then all fine. But I need to get my users ability to resize big images and make nice thumbnails.
I tried to scale image with multiple small steps (for example 1600px -> 1000px -> 500px -> 200px), the result was better, but it's very bad for perfomance, so I refused this.
If achievement of my goal using HTML5 and canvas now isn't possible, is there any chance that in future it will? I'm just thinking whether should I refuse HTML5 technology and make uploading on ActionScript or keep trying (or waiting) to do this with HTML5? I like HTML5 and actually I don't want to leave such a friendly technology.
The left image was scaled down using a more-primitive form of re-sampling or interpolation. This may be entirely due to how the browser's rendering engine happens to scale images, with the results varying from browser to browser.
If it's an option, one approach where you have full control over the resulting image quality is to upload the image, scale it on the server, and then download it back to the client.
Another approach is to use a JS library to resample the image on the client side. Not sure how practical that is.
I was wondering if anyone has done any tests with background images. We normally create a background that repeats at least in one direction (x or y or both).
Example
Let's say we have a gradient background that repeats in X direction. Gradient height is 400px. We have several possibilities. We can create as small image as possible (1 pixel width and 400 pixels high) or we can create a larger image with 400 pixels height.
Observation
Since gradient is 400 pixels high we probably won't choose GIF format, because it can only store 256 adaptive colours. Maybe that's enaough if our gradient is subtle, since it doesn't have that many, but otherwise we'll probably rather store image as a 24-bit PNG image to preserve complete gradient detail.
Dilemma
Should we create an image of 1×400 px size that will be repeated n times horizontally or should we create an image of 100×400 px size to speed up rendering in the browser and have a larger image file size.
So. Image size vs. rendering speed? Which one wins? Anyone cares to test this? With regards to browser rendering speed and possible small image redraw flickering...
The rendering speed is the bottleneck here, since bigger tiles can be put into the browser's cache.
I've actually tried this for the major browsers, and at least some of them rendered noticeably slow on very small tiles.
So if increasing the bitmap size does not result in ridiculously big file sizes, I would definately go with that. Test it yourself and see. (Remember to include IE6, as still many people are stuck with it).
You might be able to strike a good balance between bitmap size and file size, but in general I'd try 50x400, 100x400, 200x400 and even 400x400 pixels.
I found out that there may be a huge difference in the rendering performance of the browser, if you have a background-image with width of 1px and repeating it. It's better to have a background-image with slightly larger dimensions. So a image with a width of 100px performs much better in the browser. This especially comes into play when you use a repeated background-image in a draggable layer on your website. The drag-performance is pretty bad with an often-repeated background-image.
I'd like to point out that for the cost of sending down an extra few rows (1-2 only example here) .8k - 1.6kb (if you can get away with 8-bit) more like 2.4kb - 4.0kb for 24bit
2 pixel columns more means the required iterations required to blit the background in is cut down to 1/3 for up to 1.6kb (8-bit) or 4kb (24bit)
even 1 extra column halves the blitting required down to half the element width.
If the background's done in less than a second for a 56.6k modem I reckon it's lean enough.
If small dimensions of an image have a negative impact on rendering, I'm sure any decent browser would blit the image internally a few times before tiling.
That said, I tend not to use 1 pixel image dimensions, so I can see the image clearly without resizing it. PNG compression is good enough to handle this at very little cost to file size, in most situations.
I'd put money on the bottleneck being the image download rather than the rendering engine doing the tiling, so go for the 1 pixel wide option.
Also the 24-bit PNG is redundant since you're still only getting 8 bits per channel (red, green and blue).
I generally prefer to go in between, 1pixel wide will probably make your gradient seem a bit unclear but you can do something like 5pixel width which gives enough room to the gradient to maintain consistency and clarity across the page.. but I would suggest you can add more patterns and images to a single image and then use background positioning(css sprites) to position them because download a single image of say 50kb would take less time comapared to 5 40kb images since the browser makes fewer requests to the server...
I have not benchmarked this but I'd bet that on most modern computers the rendering won't be an issue whereas you always want to save on on the image download time. I often go for the 1px type of graphics.