I'm working on a web application that will allow users to upload profile pictures (avatars, basically). These images will be no bigger than 100 x 100 pixels and will be pictures of peoples' faces.
We want to allow the user to upload various image formats, but we also want to convert them all to the same image format. What would be the best image format for size, quality, etc.?
Edit
In this case, size is more important than quality, but not by much.
For faces, JPEG is your best bet. Even a relatively high quality JPEG image will be significantly compressed relative to the alternatives.
The JPEG format (and the way its compression works) was designed for "natural" images like photographs. (The alternatives, primarily GIF and PNG, work better for computer graphics, diagrams, etc.)
All that said, you should try it. Take a couple of example photos, convert them to the various image formats, and see how they compare (with apologies for the subject matter! 8-)
JPEG, 6,668 bytes:
(source: entrian.com)
PNG, 31,651 bytes:
(source: entrian.com)
I think JPG is best for avatars, I cant find a need for transparency.
JPG will be ok for photographs and will be overdo for graphics, but it's not a huge size overhead for 100x100
With an image of such limited size, and considering the profile pictures will most likely be a natural image JPEG is most certainly the way to go.
PNG works great when handed a very repetitive pattern. Computer generated graphics like screenshots, gradients. There are a couple of filters that increase the effectiveness of the deflate, however due to the losless nature of PNG, you will almost never get similar compression ratio's on these kinds of images.
Related
I'm writing an astronomy application using Apple's SceneKit and want to provide a skybox of stars to surround a planet.
I have found a large JPEG (8192x4096) with suitable content but my "camera" field of view (10 degrees) magnifies the skybox image background enough to cause serious loss of resolution. In short, it doesn't look good .. here's a screenshot showing blurry stars:
https://ramsaycons.com/screenshots/SkyBoxRes.png
One solution for greater fidelity would be, I imagine, to use a resolution independent 'material' image like a PDF, but SceneKit doesn't support PDF 'materials'.
Or, I could find, or build, a better or bigger image for the skybox material. For example, a (32768x16384) would look better, at the cost of a massive image ~ the 'small' one I'm using now is nearly 8MB already.
Another option would be to move closer to the planet and widen the field of view, but I don't want to move the camera so close (specifically, because I want it 'above' geosynchronous objects in my model).
This code-less question feels not quite appropriate for StackOverflow, but my reading of related Q&A's here reveals a knowledge of clever SceneKit tricks I wouldn't have thought off .. maybe there's a trick for me out there!
I would like to convert png file(transparent icon) to WPF "path data".
Any idea how to get single wpf path data from .png icon.?
There is no direct way to do it. A PNG file is a raster format (i.e. it stores the colour of each pixel in the image). WPF Path Data is a vector format (i.e. it stores the image as geometric drawing instructions). If you are unsure what this means, see here for more info.
Vector can be converted to raster (at a set size), but raster cannot be obviously converted to vector (which is what you want).
The only way to try and convert raster to vector, with varying results, is to "trace" the raster image to guess what the equivalent geometric vector instructions might possibly be. The ability to trace a raster image accurately is directly proportional to its pixel dimensions and complexity of graphics. So tracing a [presumably] small icon might not be possible at all.
If I were faced with your problem, I would get as high a quality PNG image as possible, import it into Adobe Illustrator, use the Illustrator tracing tools to trace the image, and finally export the result of the trace to XAML (using something like http://www.mikeswanson.com/xamlexport/).
If you are looking for runtime tracing, this is something I have not come across. Given the massively varying tracing parameters which are required for different styles of raster images, I don't suppose it would even be realistically possible.
Good luck.
I understand gamma topic but maybe not 100% and
want to ask somebody to answer and clarify my
doubts.
As I understand
there is a natural linear color space where color
with value 100 is exactly four times brighter then color
with value 25 and so on (it would be good to hold and
process color images in that format/space
when you will copy such linear light image onto
device you would get wrong colors becouse generally
some medium values would appear to dark sou you
generally need to rise up this middle values by something
like x <- power(x, 1/2.2) (or something)
this is reasonably clear, but now
are the normal everyday bitmap or jotpeg images
gamma precomputed ? If they are when i would do
some things al blending and so should i do some
inverted-gamma to boath them to convert them to
linear then add them and then gamma-correct them
to result?
when out of scope would apperr it is better co cut
colors or resacle it linearly into more wide range or
something else?
tnx for answers
There's nothing "natural" about linear color values. Your own eyes respond to brightness logarithmically, and the phosphors in televisions and monitors respond exponentially.
GIF and JPEG files do not specify a gamma value (JPEG can with extra EXIF data), so it's anybody's guess what their color values really mean. PNG does, but most people ignore it or get it wrong, so they can't be trusted either. If you're displaying images from a file, you'll just have to guess or experiment. A reasonable guess is to use 2.2 unless you know the file came from an Apple device, in which case use 1.0 (Apple devices are generally linear).
If you need to store images accurately, Use JPEG from a camera with good EXIF data embedded for photos, and maybe something like TIFF for uncompressed images. And use high-quality software that understands these things. Unfortunately, that's pretty rare and/or expensive.
As I said on the title.
I just want to know which is better between using image files and drawing vector shapes (or path).
I know that using vector is better for appearance but what about performance.
And if this depends on cases. Can anyone explain.
(This question may include WP7, Silverlight, WPF or even in general cases.)
Here is a general answer to compare pros/cons of Bitmap (what I think you mean by "image file") vs. Vector.
Bitmap-based images (gif, tiff, jpeg, png, bmp) are essentially the concept of mapping colours (and other data such as alpha layer) to a pixel grid. Different file formats offer variations of what is supported and levels of compression but this is the high-level concept. The complete map of pixels and data is stored in the file as a matrix/table.
Vector-based images, as you say, are path based. Instead of storing information by pixels, the file format will store geometric points and data.
The pros for bitmaps are:
They usually render faster than a vector. This is because there is minimal computation involved in presenting the image (just take the pixel map and display).
They handle "photographic" content better than a vector.
They are more portable than vector. GIF, JPEG, PNG, BMP are more standard than any vector format (where usually Adobe has the market)
The cons for bitmaps are:
They don't scale without degradation (pixelization)
Manipulation (i.e. resizing, blurring, lighting, etc) of a bitmap is more processor expensive than a vector
The files are usually much larger than vector-based files
The pros for vectors are:
Flexible for scaling and manipulation
Smaller file formats than vector
Ideal for print and animation (i.e. manipulating a shape to produce the animation effect)
The cons for vectors are:
Render time, depending on the complexity of the vector, can be longer
Portability most formats are highly proprietary
Work for "graphic" based images but not useful for photorealism
Hope this helps.
Jeremiah Morrill gave a great overview of WPF rendering that basically shows a vector will always be more expensive to render than an image. Basically an image gets treated as a directx texture...no matter the size, scaling or whatever, there is a set constant cost for rendering an image. As Jer's overview shows, even the simplest vector image takes a number of operations to render in WPF. The moral of the story is that when giving an option, go for the image instead of vector.
Based on our experience with Windows Phone 7 (Non-mango) apps, we find using Images instead of using drawing produces a far more responsiveness hence UX Performance for continuous animation in pages. (YMMV)
I would initially say that images render faster than vectors. The complexer the vector, more time it takes to render. The bigger the image, more time to render.
I'm going to speculate that (in Silverlight terms) most of the current video hardware is capable of directly handling the images rendering getting so a boost in the performance. I'm not sure if calculations for vectors can be done at video hardware level.
From the point of view of Windows Phone 7, you'll typically get faster rendering of images/bitmaps rather than paths/vectors. As a general rule for mobile development, due to the constrained resources on the device and the increased need to consider performance, if you can do something once, such as preparing an image, at design (or compile) time that definitely preferable to doing it multiple times on each client.
Be very careful of applying rules across platforms (WPF, Silverlight & WP7) as they are used for different things in different situations and are under different constraints. Things you have to consider on the phone may not be as much of an issue in a WPF app running on an high powered PC.
When designing a website, what do you consider the best image format to use for a particular task?
I always find myself in a dilemma when trying to figure out what format to use for a specific task...like for example, should I use .jpg all round? or, when and why should I use a .png?
For example, taking Amazon's website, they use .jpg for product images (Example), .gif for this transparent pixel (Example) and .png for their CSS Sprites (Example)
On the other hand, Play.com use a .gif for their website logo (Example), but use .jpg for their website products (like Amazon) (Example) and as far as their main page goes, they dont have any .pngs on it.
So what formats should I use for my websites? and why should I use them?
[UPDATE]
Thanks CruellO for this link for explaining the differences, and also Dustin for giving reasons on what to use.
You should be aware of a few key factors...
First, there are two types of compression: Lossless and Lossy.
Lossless means that the image is made smaller, but at no detriment to the quality. Lossy means the image is made (even) smaller, but at a detriment to the quality. If you saved an image in a Lossy format over and over, the image quality would get progressively worse and worse.
There are also different colour depths (palettes): Indexed color and Direct color.
With Indexed it means that the image can only store a limited number of colours (usually 256) that are chosen by the image author, with Direct it means that you can store many thousands of colours that have not been chosen by the author.
BMP - Lossless / Indexed and Direct
This is an old format. It is Lossless (no image data is lost on save) but there's also little to no compression at all, meaning saving as BMP results in VERY large file sizes. It can have palettes of both Indexed and Direct, but that's a small consolation. The file sizes are so unnecessarily large that nobody ever really uses this format.
Good for: Nothing really. There isn't anything BMP excels at, or isn't done better by other formats.
GIF - Lossless / Indexed only
GIF uses lossless compression, meaning that you can save the image over and over and never lose any data. The file sizes are much smaller than BMP, because good compression is actually used, but it can only store an Indexed palette. This means that there can only be a maximum of 256 different colours in the file. That sounds like quite a small amount, and it is.
GIF images can also be animated and have transparency.
Good for: Logos, line drawings, and other simple images that need to be small. Only really used for websites.
JPEG - Lossy / Direct
JPEGs images were designed to make detailed photographic images as small as possible by removing information that the human eye won't notice. As a result it's a Lossy format, and saving the same file over and over will result in more data being lost over time. It has a palette of thousands of colours and so is great for photographs, but the lossy compression means it's bad for logos and line drawings: Not only will they look fuzzy, but such images will also have a larger file-size compared to GIFs!
Good for: Photographs. Also, gradients.
PNG-8 - Lossless / Indexed
PNG is a newer format, and PNG-8 (the indexed version of PNG) is really a good replacement for GIFs. Sadly, however, it has a few drawbacks: Firstly it cannot support animation like GIF can (well it can, but only Firefox seems to support it, unlike GIF animation which is supported by every browser). Secondly it has some support issues with older browsers like IE6. Thirdly, important software like Photoshop have very poor implementation of the format. (Damn you, Adobe!) PNG-8 can only store 256 colours, like GIFs.
Good for: The main thing that PNG-8 does better than GIFs is having support for Alpha Transparency.
Important Note: Photoshop does not support Alpha Transparency for PNG-8 files. (Damn you, Photoshop!) There are ways to convert Photoshop PNG-24 to PNG-8 files while retaining their transparency, though. One method is PNGQuant, another is to save your files with Fireworks.
PNG-24 - Lossless / Direct
PNG-24 is a great format that combines Lossless encoding with Direct color (thousands of colours, just like JPEG). It's very much like BMP in that regard, except that PNG actually compresses images, so it results in much smaller files. Unfortunately PNG-24 files will still be much bigger than JPEGs, GIFs and PNG-8s, so you still need to consider if you really want to use one.
Even though PNG-24s allow thousands of colours while having compression, they are not intended to replace JPEG images. A photograph saved as a PNG-24 will likely be at least 5 times larger than the equivalent JPEG image, with very little improvement in visible quality. (Of course, this may be a desirable outcome if you're not concerned about file size, and want to get the best quality image you can.)
Just like PNG-8, PNG-24 supports alpha-transparency, too.
JPEGs are for photos. I see JPEGs with text in them occasionally and they just look awful. Text is best for text, otherwise use PNG.
If it's not a photo, but you want a graphic of it, use a PNG. A PNG is almost always smaller than the equivalent gif and will not lose quality like a JPEG file. A PNG equivalent of a JPEG will typically be a lot larger (assuming it's photorealistic). There may be times where this is still desirable.
PNG does allow for 8-bits of transparency, but if you have to support IE, you'll find that they continually refuse to support that correctly. They do support a single bit of transparency in an 8-bit image (essentially the same as gif) as far as I know. There are also numerous hacks to get 8-bit transparency to work in IE. I've never bothered, myself.
In summary:
Photos → jpg
!Photos → png
PNG can be used when:
You need transparency (either 1-bit or alpha transparency)
Lossless compression will work well (such as a flat-style icon or logo)
JPEG can be used when:
Lossless compression will not work well (such as a photograph)
GIF can be used when:
Animation is necessary, and video is not possible (though you should really try and use video; animated GIFs are poor quality and very inefficient)
Despite myths to the contrary, PNG outperforms GIF in all like for like comparisons. PNG is capable of every image mode of GIF apart from animation, and when using the same image mode, PNG will have better compression due to its superior DEFLATE algorithm compared to LZW. PNG is also capable of additional modes that GIF cannot do, such as 24 bit color, and multi-bit transparency (alpha transparency). Note that multi-bit transparency used to be a problem back when people used IE6.
PNG modes include (this is just a small subset)
Palette colour of 2 to 256 colors (like GIF)
Palette colour of 2 to 256 colors, with transparent color (like GIF)
True color (24 bit color)
True color with alpha channel (24 bit color + 8 bit transparency)
For best compression in PNG for the web, always use a palette mode. If you find PNG files are larger than the equivalent GIF files, then chances are you're saving the PNG in 24 bit color and the GIF in palette mode (because saving a full color GIF always requires translation to palette mode). Try converting the image to palette mode before saving in both cases.
PNG also has other modes such as palette color with alpha transparency in the palette. Modes such as this work in browsers but software like Photoshop have (or once had) problems with creating or working with them due to not supporting those image modes.
If you are storing or presenting a large number of images the new Google WebP format might be worth considering as it is 25% smaller than PNG/JPG.
Note this is not supported by all browsers at the moment.
NB. This came out in 2010 after this question was posted.
JPEG FILE FORMAT
Great for images when you need to keep the size small
Good option for photographs
Bad for logos, line art, and wide areas of flat color
GIF FILE FORMAT
Great for animated effects
Nice option for clip art, flat graphics, and images that use minimal colors and precise lines
Good option for simple logos with blocks of colors
PNG FILE FORMAT
Lossless
Excellent choice when transparency is a must
Good option for logos and line art
Not supported everywhere
You can see this infographics for more detailed information, Image File Types: When to use JPEG, GIF & PNG