15

I know that if you want to scale-up an image, then a SVG is a wise choice.

However, my situation is that I have icons that I want users to be able to upload via a CMS. SVGs are just that bit trickier to create, and so jpg,gif or png seems the ideal format for admins.

If uploaded the same or larger than the display size, and kept in the right ratio, can jpgs, gifs or pngs be as high quality as a SVG when reduced in size?

My assumption would be that browsers need to antialiase a svg below a certain size too, so they are likely to blur just as much as any other format, although gifs do seemingly blur more.

  • 4
    A good question but I believe the answer is "it depends on the browser". – usr2564301 Apr 19 '16 at 13:13
7

(Note: please read the OP's own answer before this one, since my answer is a comment on the OP's investigation)

This is a known issue of Android Chrome. On some of their builds they disabled anti aliasing causing the vector shapes to be rendered with crisp edges. The reason for this was to reduce the overload created by anti aliasing calculations. Due to complains they released an update that should have enabled anti aliasing back.

There are several threads in Stack Overflow discussing this issue. Here is one of them:
https://stackoverflow.com/questions/19875908/vectors-poorly-displayed-on-chrome-for-android-canvas

I could not find a reference to the same problem on IPod Touch Safari but probably it is safe to extrapolate and assume the problem is the same.

There are ways to try to force the anti aliasing even when it is disabled, such as this trick which basically adds a bit of padding around the element causing the browser for some reason to apply anti aliasing. You can also try to set the shape-rendering attribute of the element to something different than crisp-edges and see if the browser honours it.

  • Adding -webkit-backface-visibility: hidden means that the non-svgs blur on the iPod in exactly the same way as the svgs, and that answers my question - ie there is no need to pick one over the other when scaling down. Oddly the Android fix doesn't seem to standardise rendering behaviour on my version of Android Chrome / native broswer, but that's a different issue. Thanks for your help. – Richard B Apr 19 '16 at 16:42
13

I have just run a test and the only difference appears to be on mobile browsers.

I created a 990 x 900px image of the Twitter icon (that icon seems far too detailed a design for good scaling, so good for this test). I saved this as SVG, JPG, GIF, Transparent GIF (just the bird shape, no background colour, instead adding this with CSS), PNG, transparent PNG.

I then shrunk these down to 15px, 25px, 50px, 100px and 150px.

Here's the results in Firefox: enter image description here

Here's the results in Chrome: enter image description here

If we zoom into a screengrab of the smallest results so that we can see what pixels are being generated, then Firefox (top) is slightly darkening the edges on the non-transparent versions, but all other results are very similar.

enter image description here

However, on an IPod Touch Safari browser, the SVG version seems quite blurred, and the others quite pixelated:

enter image description here

A similar result is also seen on Android Chrome. I have not taken a screenshot of this.

I wonder if the reason for this could be something to do with pixel density, which is the main difference in display, though that would make more sense to me if all images were handled differently on mobile, rather than just the SVG one.

If someone can explain why this is the case, then I'll transfer the accepted answer tick. Otherwise, I gues the TL;DR answer is that it depends if you prefer blurred or pixelated icons (or to make lots of icons at pixel perfect sizes for your responsive breakpoints).

edit: I've since observed that svgs are usually far clearer on apple devices - the twitter bird may have been too detailed for this to show up in my tests above, so feel that they are the right format to use for icons.

  • SVG is rendered at display time and can benefit from AA, the others are fixed resolution and the only AA they can have is render 2x; blur; and reduce, which is not really going to help except in "descreening" situations. For the SVG, a fixed AA method (like across the board simple 4x FSAA) is going to be over-aggressive when you only have 8px width, and down-sampling always results in some blur. – Yorik Apr 19 '16 at 21:39
  • Note that the type of scaling and resampling is software implementation dependent. Most go for "fast" or "balanced" instead of Quality. – Yorik Apr 19 '16 at 21:41
3

There is a very important distinction between vector images and bitmap images. Vector images, if we simplify a bit, are rendered by the client while bitmap images are being rendered by you.

This means that the application your sending the image to has more say into how it behaves. The end result is that you have following downsides:

  • It takes more resources to make the image presentable
    • In this case the rendered might opt to drop quality because it does not have enough resources to do it better.
  • Each imaging system has its own set of quirks and flaws
    • Makes it harder to be consistent
    • You get the problems of a programmer

On the other hand there are some benefits of this:

  • The image can be freely scaled and have more manipulative options.
    • This is simply a result of the job done in the clients end so they can spend more time on computing pixels to gain a bigger picture if you send elements it knows how to scale.
  • The data in many cases is smaller than the pixel image (though it does not have to be)

There not much you can do if a system has a buggy renderer. Your giving end application a choice and they can use that choice to make bad decisions.

Which is better

It depends on how well you can render your image and how much bandwidth you have at your disposal. It is certainly possible to do a better render than what the browsers do. Not really surprising one can do a better job than Illustrator also. But then you lose all the benefits of having a deferred rendering.

There is a third option.

If your not satisfied with the results you can always try to make your own rendering engine. With platforms that support webgl you can. See here for a example. But this is pretty hardcore and does not save you form implementation details.

2

(Not enough points to comment on Richard B's answer directly yet.)

To answer your question Richard B, We often see this effect on elements needing anti-aliasing on lower-powered hardware. This even happens on rounded-cornered DOM elements, when anti-aliasing is reduced or removed from those environments.

At our company, we have some cases where we use lower power hardware, and started encountering this "extremely jagged edged shapes" issue. We had disabled/reduced the amount of anti-aliasing to improve performance. This is likely the same reason your tests on mobile returned the results they did.

  • Makes sense as a reason. Shame SVGs don't seem to have consistency with other image types, though. – Richard B Apr 19 '16 at 21:23
  • 1
    @RichardB, Well, they're sort of different from regular images. You can actually interact with them as if they were DOM nodes. Their paths and shapes receive events and CSS properties just like real DOM nodes, so if my understanding is correct, they follow the same rendering path as other nodes and it makes sense in this context. Images are rasterized boxes and go through a different rendering channel, sometimes even carving out space on the GPU. – Brak Apr 19 '16 at 22:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.