The images are really blurry if you use resize an image, for example showing a small image with resized dimensions, like;
<img src="largeimage.jpg" width=30 height=30 \>
Its not blurry in other browsers, but in Chrome, its so blurry.
I have looked at in www.twitter.com , their new design has lots of resized images and somehow, they have managed to clear blur in resized images. I have tried these;
image-rendering: crisp-edges;
image-rendering: pixelated;
But unfortunately, it doesn't solve the problem.
Below is a comparison. On the left, you can see that it is quite blurry, compared to that on the right:
What is the correct way to do that ?
Have you tried this? :)
filter: blur(0);
-webkit-filter: blur(0);
transform: translateZ(0);
-webkit-transform: translateZ(0);
I've noticed that Chrome does a better job when you resize an image at a certain percentage. For example, if you resize a 375px image to 100, it gets blurry, but if you resize 200 to 100, it does a better job because it's a nice even 50% scale.
Without an editable test environment, I'm not sure if that would fix it for you, but it's worth a shot.
I understand that this is an old post and things might have changed since then; thus, I am posting this for future readers who might come accross this question.
You could set image-rendering to pixelated, in order to preserve the original pixelated form. The below should work as expected on Chrome (and Opera) browser as well.
img {
image-rendering: pixelated;
}
As per the documentation:
pixelated
Using the nearest-neighbor algorithm, the image is scaled up to the next integer multiple that is greater than or equal to its original size, then scaled down to the target size, as for smooth. When scaling up to integer multiples of the original size, this will have the same effect as crisp-edges.
I've just had this issue in a WordPress gallery with six images using WEBP files. One image was sharp the others slightly blurry in Chrome etc. but ok in Firefox. I cropped the five to the exact size of the sharp image which was 1200 x 650px and replaced the 'blurry' ones in the gallery with the newly cropped versions. They are all displaying ok now.
Some crops just shaved as little as 4 pixels from the depth.
Related
I've developed a simple click game where you click an image and it gets replaced by another image. The first image is faded out and the next image is faded in using jQuery/animate/toggle.
After each animation the anti-aliasing on all images is lost for a second. It then reapplies anti-aliasing to all images.
Is it possible to force anti-aliasing constantly or force it to refresh faster so there's no time where images are not anti-aliased?
For me, in an embedded WebKit on Mac OS X, using this (non-standard) CSS works to preserve the antialiasing of images during CSS animations:
img {
image-rendering: optimizeQuality;
}
This may not work for other browsers, of course. The mozilla.org site claims that this behave as an alias of 'auto' but it definitely changes the behaviour in WebKit.
Please have a look at this: http://www.eymy.nl
The transition works smoothly in all browsers, but becomes jerky in Safari when the images are scaled down (when the window height is smaller than 1227 pixels, which is the 100% height of the images). In other words, Safari cannot handle this transition together with scaling.
My guess is that it CAN, but needs different code. I tried different slideshow scripts and the results are always the same, the moment the images are scaled (down OR up) the transition in Safari becomes jerky.
Any advice will be greatly appreciated!
I'm using Chrome and Safari on a i7 MacBook Air and it was smoother in chrome. After the first image loaded in Safari which was choppy it looked OK. Since this seems like an issue of images loading before they are animated I would suggest preloading them. This is usually done in the body tag with JavaScript or you can also use CSS. See this page for ways to preload images.
Scroll through the images in Firefox (tested on v. 26) and you notice if you look to the right that the image stretches one pixel (or so) after its .src has been changed. This behaviour only occurs in Firefox and if the width of the image is increased or decreased by 1px (through web console), the behaviour disappears... I know that the image is bigger than the width I set but it still doesn't explain the behaviour and why it's only occuring at a very specific width (after all, image is still resized in browser if I increase or decrease the width by 1px as well but then the behaviour disappears). Works perfect in Opera, Chome, Safari and IE...
http://www.mosaikdesign.se/galleri_.php
Anyone?
I spent some time researching this and they way I see it, it's a bug.
I filed a bug report at Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=953364
I also made a thorough test page for those interested in studying this behaviour: http://www.blackwinged-angel.com/bugs/index.html
And finally, the fix:
-Set css property image-rendering on the image to something else than auto (optimizequality, optimizespeed, -moz-crisp-edges). It's claimed in the documentation that optimizequality and optimizespeed are the same as auto (https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering) but they do result in different downscaling algorithms being used (see my link for proof). However, this fixes the problem.
-Use image sizes where images are only upscaled, not scaled at all or check the resulting downscaling since it only applies to certain sizes of the containing element in relation to certain actual image sizes, not all.
Again folks, this only applies to Firefox, was tested on Firefox 26, applies to downscaling images on-the-fly in the browser by styling img (and possibly other) elements with width and height and it's not consistent (just happens at about roughly 30% of tested downscalings on a specific image for me).
I have a sprite that animates using a sprite sheet. He is only 16x16, but I want to scale him up to around 64x64 in all its pixel-y goodness!
The results are terrible, of course the browser is anti aliasing it. :/
Thanks!
EDIT:
No css needed, here is my draw function.
function drawSprite(offsetx:number,offsety:number,posx:number,posy:number){
ctx.drawImage(img, offsetx*32, offsety*32, 32, 16, posx*32, posy*8, 128, 32);
}
See it kinda working here (codepen)
In case someone ever stumbles upon this again (like me), Webkit supports a -webkit-optimize-contrast value for image-rendering, which (currently) is an implementation of the nearest neighbor upscaling. It can be applied to both images and canvases.
Here's an example of how it goes.
.nn128 {
width: 128px;
height: 128px;
image-rendering: -moz-crisp-edges;
image-rendering: -webkit-optimize-contrast;
}
<canvas class="nn128" width="16" height="16"></canvas>
<img src="path/to/small/image.png" alt="Small image" class="nn128">
With this setup, both WebkitSafari and Gecko/Firefox will enlarge the 16x16 canvas space and the small image to 128x128 with the nearest neighbor algorithm.
UPDATE The answer initially stated that Webkit browsers supported this; in fact, as of 2011-12-24, it works with Safari on Mac OS and Chrome on Mac OS, but not with Chrome one Windows (Safari on Windows was not verified), as stated on Issue 106662 of the Chromium bug tracker. Lexically, Chrome on Windows will accept the -webkit-optimize-contrast value in a CSS style sheet, but it won't have any effect. It is my expectation that it will work someday, and this method will be the right way to get nearest neighbor upscaling, but for now, using this method means Windows Chrome users will have to live with the blurriness.
In Firefox you can use this:
canvas {
image-rendering: -moz-crisp-edges;
}
But as far as I know for every other browser you are pretty much out of luck. One way around this perhaps is to scale up your sprite to 64x64 in Photoshop (or whatever), then use it scaled down in canvas. This way at least the image will not get blurry when "scaled up". It still won't exactly give you the pure mode7 like goodness of nearest neighbor though.
You could write your own scaling code using the imageData object. You will be incurring a significant performance penalty in doing so, but for a 16x16 image, it might not be that significant.
Here's the problem. I have an image:
<img alt="alttext" src="filename.jpg"/>
Note no height or width specified.
On certain pages I want to only show a thumbnail. I can't alter the html, so I use the following CSS:
.blog_list div.postbody img { width:75px; }
Which (in most browsers) makes a page of uniformly wide thumbnails, all with preserved aspect ratios.
In IE6 though, the image is only scaled in the dimension specified in the CSS. It retains the 'natural' height.
Here's an example of a pair of pages that illustrate the problem:
The list, which should show thumbnails
A single blog post, which shows the full-size image.
I'd be very grateful for all suggestions, but would like to point out that (due to the limitations of the clients chosen platform) I'm looking for something that doesn't involve modifying the html. CSS would also be preferable to javascript.
EDIT: Should mention that the images are of different sizes and aspect ratios.
Adam Luter gave me the idea for this, but it actually turned out to be really simple:
img {
width: 75px;
height: auto;
}
IE6 now scales the image fine and this seems to be what all the other browsers use by default.
Thanks for both the answers though!
I'm glad that worked out, so I guess you had to explicitly set 'auto' on IE6 in order for it to mimic other browsers!
I actually recently found another technique for scaling images, again designed for backgrounds. This technique has some interesting features:
The image aspect ratio is preserved
The image's original size is maintained (that is, it can never shrink only grow)
The markup relies on a wrapper element:
<div id="wrap"><img src="test.png" /></div>
Given the above markup you then use these rules:
#wrap {
height: 100px;
width: 100px;
}
#wrap img {
min-height: 100%;
min-width: 100%;
}
If you then control the size of wrapper you get the interesting scale effects that I list above.
To be explicit, consider the following base state: A container that is 100x100 and an image that is 10x10. The result is a scaled image of 100x100.
Starting at the base state, the
container resized to 20x100, the
image stays resized at 100x100.
Starting at the base state, the
image is changed to 10x20, the image
resizes to 100x200.
So, in other words, the image is always at least as big as the container, but will scale beyond it to maintain it's aspect ratio.
This probably isn't useful for your site, and it doesn't work in IE6. But, it is useful to get a scaled background for your view port or container.
Well, I can think of a CSS hack that will resolve this issue.
You could add the following line in your CSS file:
* html .blog_list div.postbody img { width:75px; height: SpecifyHeightHere; }
The above code will only be seen by IE6.
The aspect ratio won't be perfect, but you could make it look somewhat normal.
If you really wanted to make it perfect, you would need to write some javascript that would read the original picture width, and set the ratio accordingly to specify a height.
The only way to do explicit scaling in CSS is to use tricks such as found here.
IE6 only, you could also use filters (check out PNGFix). But applying them automatically to the page will need javascript, though that javascript could be embedded in the CSS file.
If you are going to require javascript, then you might want to just have javascript fill in the missing value for the height by inspecting the image once the content has loaded. (Sorry I do not have a reference for this technique).
Finally, and pardon me for this soapbox, you might want to eschew IE6 support in this matter. You could add _width: auto after your width: 75px rule, so that IE6 at least renders the image reasonably, even if it is the wrong size.
I recommend the last solution simply because IE6 is on the way out: 20% and going down almost a percent a month. Also, I note that your site is recreational and in the UK. Both of these help the demographic lean to be away from IE6: IE6 usage drops nearly 40% during weekends (no citation sorry), and UK has a much lower IE6 demographic (again no citation, sorry).
Good luck!