Currently the png images used in the application do not show up crisp and clear. There is clearly a resolution issue. We tried to change the resolution of the images like in page.setImage from 32x32 to even 128x128. The higher the resolution, the worse the images actually look.
In native iOS the resolution of the images used for retina displays are defined by a naming convention, like icon.png and icon#2x.png, which has double the resolution.
Tried that as well, knowing there is no documented evidence that this should work.
Any words of wisdom?
Thanks!
Vincent
This is planned for a future release. The API (based on SWT) does currently not support multiple images with different resolutions to be set on a single widget.
(I apologize if this belongs in stackexchange.com - I'm not sure how to tell)
I am a big fan of the dot language and want to adopt a language for my more complex diagramming needs (e.g. software architecture graphics, business school papers, personal notes etc.) and want something that is a good compromise on these:
1) Relatively easy to read and understand (like dot), and not too verbose. So far my research has shown that there is no clear favorite.
2) Easy to tweak by hand (i.e. in a text editor). The initial drawing can be done in a graphics package but if you just want to change some text or a color, it should be easy to do with plain text *NIX tools. So that rules out Flash.
3) It won't fall out of favor one day and risk being a waste of effort and I'd need to migrate my diagrams to some other format.
I'm put off by Metapost because it looks complicated, but I'm not sure if SVG is being obsoleted and Adobe are putting all their investment into Flash.
1) Relatively easy to read and understand (like dot), and not too verbose. So far my research has shown that there is no clear favorite.
dot's more high-level than SVG is; last I checked, SVG was one of dot's output formats.
2) Easy to tweak by hand (i.e. in a text editor). The initial drawing can be done in a graphics package but if you just want to change some text or a color, it should be easy to do with plain text *NIX tools.
Handwritten SVG is fairly easy to edit in a text editor, much like handwritten HTML.
Computer-generated SVG is fairly irritating to edit in a text editor, much like Word-generated HTML.
3) It won't fall out of favor one day and risk being a waste of effort and I'd need to migrate my diagrams to some other format.
All current browsers have SVG support, including IE.. As far as I can tell, SVG is a relatively safe graphics format to write in.
I'm put off by Metapost because it looks complicated, but I'm not sure if SVG is being obsoleted and Adobe are putting all their investment into Flash.
Adobe's interest is fairly irrelevant at this point. You may be thinking of a time when Adobe's SVG plugin was the only way to view SVG, but those days are long gone (and the plugin is defunct). These days, SVG is fairly well supported in browsers, at least for static images. Additionally, the SVG-related technologies that browsers support has been steadily increasing in all browsers over the past few years (it's a complex spec), and I see no reason why SVG support would stall or reverse.
SVG has been a W3C recommendation since 2001 and modern browsers have supported it for years, IE recently joined in. As of now all major browser vendors are working in the direction of expanding their support.
Alot of info can be found here: http://caniuse.com/#cats=SVG
As far as I know SVG is a feature of HTML 5. So,if you use SVG there is a chance that it will not work in some old browsers. But, I think the world(all browsers) is moving to HTML 5.
Are SVG graphics a viable option for an in-browser game, with a google-maps style interface? This would involve zooming in/out, and scrolling in two dimensions over a very large distance.
For example, the client might request some area to be drawn in from the server -- and rather than the server returning a generated image for that section, it would return a series of gzipped SVG images and their locations in the requested area. Then the user could zoom in and out without grabbing new "tiles" from the server, since SVGs are scalable.
Would this be better than generating pngs or jpegs and sending back tiles? Would it perform well if there were many clients requesting images all over the place? Would it perform well on the client? What are the downsides to this approach?
In my experienced. The downside is the achievable level of detail using SVG is lower than lossy image compression like jpeg and png. I had difficulties getting all my vector graphics to play nicely with each other. If your artists are comfortable with working in SVG then this may not be an issue. Another note is that SVG compatibility may very between browsers. For instance I'm not sure which browsers support SVG. Webkit does, and I think Firefox does mostly, but I'm fairly sure IE is out of the picture, so to speak.
Overall SVG will put higher demands on client machines and lower demands on your servers. Calculating hundreds of SVG images is a lot more work than arranging PNGs.
In really depends on your game. If you are writing Chess, it would probably work fine. If you want to do something more complex in real time( E.G. a 2d side scrolling game), I have no clue.
using this SVG clock in Raephael as an Example. I am running Chrome on Windows and periodically different bars "twitch" and "reset for a second"
Edit
I just saw this first person SVG Demo So it can be done.
I'm starting to venture out from using jpeg and gif files to png, I was wondering if there were any standards for using png beside IE's lack of support for it. I also want to know if there was any current articles about setting I should be using when optimizing for web? Right now I'm using photoshop to do this, should I be using firework instead?
Which optimizations you use depends on the type of image. If your image contains only few colors, you might use png-8, otherwise you may need png-24. Same goes for the use of transparency/alpha blending.
The Photoshop save for web-feature does a fine job, but when your website has a lot of visitors, you may benefit from using PNGCrush for further compressing your images. You can use the YSlow plugin for FireFox to test how much bandwidth you can save by crushing your images.
Also, you can make use of CSS-sprites if your design allows it. This can result in less (but larger) images and therefore less requests and sometimes less bandwidth. But this doen't depend on the type of images you use.
Png is supported by IE, by the way. Only the alpha-transparency is not supported by IE 6, but there are CSS/Javascript trics to work around that, although they do not work for background images.
I wouldn't quit using jpg. Jpg is very useful when it comes to pictures. Png files are convenient for small images like buttons, graphical elements, and for images with large plain areas, like screenshots.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
When doing small icons, header graphics and the like for websites, is it better to use GIFs or PNGs?
Obviously if transparency effects are required, then PNGs are definitely the way to go, and for larger, more photographic images I'd use JPEGs - but for normal web "furniture", which would you recommend and why? It may just be the tools I'm using, but GIF files usually seem to be a bit smaller than a comparible PNG, but using them just seems so 1987.
As a general rule, PNG is never worse, and often better than GIF because of superior compression. There might be some edge cases where GIF is slightly better (because the PNG format may have a slightly larger overhead from metadata) but it's really not worth the worry.
It may just be the tools I'm using, but GIF files usually seem to be a bit smaller than a comparible PNG
That may indeed be due to the encoding tool you use.
/EDIT: Wow, there seem to be a lot of misconceptions about PNG file size. To quote Matt:
There's nothing wrong with GIFs for images with few colours, and as you have noticed they tend to be smaller.
This is a typical encoding mistake and not inherent in the format. You can control the colour depth and make the PNG file as small. Please refer to the relevant section in the Wikipedia article.
Also, lacking support in MSIE6 is blown out of proportion by Chrono:
If you need transparency and can get by with GIFs, then I'd recommend them because IE6 supports them. IE6 doesn't do well with transparent PNGs.
That's wrong. MSIE6 does support PNG transparency. It doesn't support the alpha channel (without a few hacks), though but this is a different matter since GIFs don't have it at all.
The only technical reason to use GIFs instead of PNGs is when use need animation and don't want to rely on other formats.
The W3C mention 3 advantages of PNG over GIF.
• Alpha channels (variable
transparency),
• Cross-platform gamma correction
(control of image brightness) and
color correction
• Two-dimensional interlacing (a
method of progressive display).
Also, have a look at these resources for guidance:
PNG v's GIF (W3C Guidance)
PNG FAQ
Wow, I'm really suprised with all the wrong answers here. PNG-8 will always be smaller than GIF when properly optimized. Just run your PNG-8 files through PngCrush or any of the other PNG optimization routines.
The key things to understand:
PNG8 and GIF are lossless <= 256 colors
PNG8 can always be smaller than GIF
GIF should never be used unless you need animation
and of course,
Use JPG for black&white or full color photographic images
Use PNG for low color, line art, screenshot type images
The main reason to use PNG over GIF from a legal standpoint is covered here:
http://www.cloanto.com/users/mcb/19950127giflzw.html
The patents have apparently expired as of 2004, but the idea that you can use PNG as open-source over GIF is appealing to many people.
(png open source reference: http://www.linuxtoday.com/news_story.php3?ltsn=1999-09-09-021-04-PS)
Be careful of color shifts when using PNG. This link gives an example, and contains many more links with further explanation:
http://www.hanselman.com/blog/GammaCorrectionAndColorCorrectionPNGIsStillTooHard.aspx
GIF images are not subject to this problem.
I don't think it makes a lot of difference (customers don't care). Personally I would choose PNGs because they are a W3C standard.
Be cautious with the PNG transparency effects: they don't work with IE6.
For images on the web, each format has its pros and cons. For photograph-type images (ie lots and lots of colours, no hard edges) use a JPEG.
For icons and the like, you have a choice between PNG and GIF. GIFs are limited to 256 colours. PNGs can be formatted like GIFs (ie 256 colours, with 1-bit transparency that will work in IE6), but for small images they're slightly larger than GIFs. 24-bit PNGs support both a large gamut, and alpha transparency (although it's troublesome in IE6).
PNGS are your only really sensible choice for things like screenshots (ie, both lots of colours and hard edges), and personally, that's what I stick with most of the time, unless I have something for which JPEG is more suitable (like a photo).
Indexed PNG (less than 256 colors) is actually always smaller than gif, so I use that most of the time.
For computer generated graphics (i.e. drawn by yourself in Photoshop, Gimp, etc.) JPG is out of the question, because it is lossy - i.e. you get random gray pixels. For static images, PNG is better in every way: more colors, scalable transparency (say, 10% transparent, .gif only supports 0% and 100%), but there is a problem that some versions of Internet Explorer don't do PNG transparency correctly, so you get flat non-transparent background that looks ugly. If you don't care about those IE users, go for PNG.
BTW, if you want animations, go for GIF.
PNG is a 100% replacement for GIF files and is supported by all web browsers you are likely to encounter.
There are very, very few situations where GIF would be preferable. The most important one is animation--the GIF89a standard supports animation, and virtually every browser supports it, but the plain old PNG format does not--you would need to use MNG for that, which has limited browser support.
Virtually all browsers support single-bit transparency in PNG files (the type of transparency offered by the GIF format). There is a lack of support in IE6 for PNG's full 8-bit transparency, but that can be rectified for most situations by a little CSS magic.
If your PNG files are coming out larger than equivalent GIF files, it is almost certainly because your source image has more than 256 colors. GIF files are indexed to a maximum palette of 256 colors, while PNG files in most graphics programs are saved by default in a 24-bit lossless format. If file size is more important than accurate colors, save the file as an 8-bit indexed PNG and it should be equivalent to GIF or better.
It is possible to "hack" a GIF file to have more than 256 colors using a combination of animation frames with do-not-replace flags and multiple palettes, but this approach has been virtually forgotten about since the advent of PNG.
A major problem with GIFs are that it is a patent-encumbered format (EDIT: This is apparently no longer true). If you don't care about that, feel free to use GIFs. PNGs have a lot more flexibility over GIFs, particularly in the area of colorspace, but that flexibility often means you'll want to "optimize" the PNGs before publishing them. A web search should uncover tools for your platform for this.
Of course, if you want animation, GIF is the only way to go, since MNG was basically a non-starter for some reason.
"It may just be the tools I'm using, but GIF files usually seem to be a bit smaller than a comparible PNG, but using them just seems so 1987."
It probably is your tools. From the PNG FAQ:
"There are two main reasons behind this phenomenon: comparing apples and oranges (that is, not comparing the same image types), and using bad tools." continued...
But you could always try saving as both (using the same colour depth) and see which comes out smaller.
Of course, if you want to standardise on one graphic format for your site, PNG is likely to be the best one to use.
Personally I use gif's quite a bit for my images, as they work everywhere, obviously your transparency limitation is one key element that would direct someone towards a specific format.
I don't see any downfalls to using gif's.
If they get smaller and you have nothing to gain from using the features PNG offers (which is alpha channel transparency and more than 256 colors) then I see no reason why you should use PNG.
gif files will tend to be a little smaller since they don't support a transparency alpha channel (and maybe for some other reasons). Personally, I don't feel the size difference is really worth worrying about nearly as much as it used to. Most people are using the web with some sort of broadband now, so I doubt they will notice a difference.
It's probably more important to use the type of images that your manipulation tools work best with.
Plus, I like the ability to put an image on any background and have a drop shadow work, which points me more towards the png format.
I usually use gif's because of the size, but there is also png-8 which is 256 colours as well.
If you need fancy semi-transparent stuff then use png-24.
I usually use the 'save for web' feature in photoshop, which lets you fiddle with filetype, number of colours etc and see the result before you save. Of course I would use the smallest possible which still looks good in my eyes.
I use jpg for all non-transparent images. You can control the compression, which I like. I found this web site that compares the two. jpg is smaller and looks better.