I'm working on the image compression techniques and analyzing the best algorithms that could produce smaller output within 100 ms or lesser for images of resolution 1920 * 1080 on a laptop with octa core processor for transmission through the network.
I had been using GDI+ and CxImage libraries for image compression, through JPG or PNG compression techniques that gives me the output image within around 30 ms for JPG and around 70 ms using PNG for colorful images, time taken is pretty good but the compressed data size is much higher in size if I go for better quality.
Then I came across google's WebP format. I tried it using libWebP with VC++. The quality and the compression rate is really awesome but the time taken is is much higher than I expected. It takes more than 300 ms and sime times even more than 1 second if I set true for alpha filtering and alpha compression.
Here are my WebpConfig settings
m_webp_config.quality = 50;
m_webp_config.alpha_quality = 0;
m_webp_config.lossless = false;
m_webp_config.method = 3;
m_webp_config.alpha_compression = false;
m_webp_config.alpha_filtering = false;
m_webp_config.autofilter = false;
m_webp_config.filter_sharpness = false;
m_webp_config.filter_strength = 0;
m_webp_config.filter_type = 0;
m_webp_config.use_sharp_yuv = false;
And sometimes I get black images whenever I capture command prompt or notepad++ (I suspect that the problem is with those images with lot of text data but the same is not true with web pages that has huge amount of text)
Am I doing anything wrong with the WebPConfig ? Is there a way to optimize it?.
I didn't find much documentation and any forums that can give me some idea with these problems.
Any help would be appreciated. Thanks in advance.
Try lossless compression? There can be modes of lossless that are faster than the lossy.
If you are in control of the compression and decompression, split the image into 256x256 squares and compress and send them separately. That way you can not only parallelize the computation, but also interleave some of the transmission to happen during the compression, which may simplify your time budgeting for the compression computation.
If you reduce the 'method' value, you will generally find a faster WebP compression. For lossless, you need to reduce BOTH method and quality, they control the same thing in a complicated manner. For lossless, try quality 20 and method 1 (or perhaps there is a 0 method, too, don't remember).
I'm using GraphicsMagick in node.js and I have lots(thousands) that I need to optimize as much as possible. Each one is 250*250 PX and I need to make them 50*50 but this is the easy part.
The problem is how to optimize them too.
By optimizing them I mean make them into jpeg or png(which ever is smaller) and lower the quality(if needed) and other things...
my code so far...
gm(temp_location + file_name)
.gravity('Center')
.extent(50, 50)
.noProfile()
.write(new_location + "s"+name, function (err) {});
so any suggestion on how to make the image any smaller?
any suggestion is appreciated
For JPEG (which is most suitable for photos and other natural images), lowering the quality (which means image quality) will help. Try -quality 40 or less.
For PNG (which is most suitable for line art), limiting the colors to 254 or fewer and increasing the quality (which actually means compression level) might help. For PNG with a limited number of colors, use a "quality" that is an even multiple of 10, because the second digit specifies the PNG filter method which should be "0" which means no filtering. Try -quality 90.
A complement to the above answer, concerning GIF format optimization.
GraphicsMagick documentation is very clear regarding JPEG or PNG compression however when outputting GIF files (this is my case...), these compression functions do not seem to apply.
I managed to reduce my GIF output file size by 52% by using this code:
var gm = require('gm');
gm()
.in(input_filename1)
.in(input_filename2)
.bitdepth(8)
.colors(192)
.dither(false)
.filter('Point') // filter before resize to have a 'sharp big pixels' aspect
.antialias(false)
.resize(magnify_factor*size_x, magnify_factor*size_y, "!")
.write(output_filename, function (err) {
if (!err) console.log('gif file created!');
});
Here are other functions I tried but seemed to have no effect when dealing with GIFs
.limit("disk", "500KB")
// this limits resource used but does not limit the output filesize
.quality(10)
.compress('LZW')
I have milions of .PNG images which all have same colors. I would like to use this knowledge in order to save some space in following manner: Force all files to use same palette and store only IHDR and IDAT section and use same PLTE for all files. I would then inject PLTE when image is requested. As this is not trivial i am asking is this is sound approach? Is there some obstacle that i missed? Is there another approach for this problem? Initial observation is that this would save ~15% of storage.
Examle how much space is saved for single image if PLTE section is not storred:
Encode your images in grayscale format (instead of pal indexed). Keep your palette in single separate file.
On image request change fromat back to indexed palette and inject palette entries.
That looks a cost too high (developing a software to store and rebuild invalid PNG files) to gain too little. It sounds also strange that you have "millions" of images with the "same colours" - what does the later mean? do they really have the same palette (up to 256 colors)? If to "force a common palette" you have to sacrifice quality, wouldn't be more efficient to store them in JPEG.
Also, the images must be quite small if stripping the palette gives you 15% of gain. In that case, a more practical approach (especially if the files have the same size, in pixels) would be to store groups of them tiled together in a single PNG image, similar as CSS sprites.
I need to edit a png image,by giving it border and drop shadow effect. But the final size of the edited image is too high to use for a mobile app .I know that size of jpeg is less compared to that of png.So i convert that image to jpeg and tried to give drop shadow and border effect.But that image is not having transparent background..Is their any other methods to accomplish this using jpeg?
Another option is to try either ImageOptim for losseless compression, or its lossy cousin, ImageAlpha.
ImageOptim tries a series of lossless algorithms to shrink a PNG and selects the smallest result of the bunch. It has taken 25% to 50%+ of quite a few of our images.
ImageAlpha, on the other hand, is lossy and can further crunch the image, with results more like JPEG but without losing Alpha.
You would also do well to disable PNG compression in Xcode as shown here, with additional details here.
What #minitech wanted to say is not about scaling, it's about file compression. jpg and png files usually have some data that could be removed from the file. There are some compression methods to reduce file size (note that is size in kbs, not in scale measurement). Jpg images can reduce file size by reducing image quality, too.
If you want another file type that accepts transparency, there are the gif format, which gives you a smaller file, but have some drawbacks, like a lack of alpha channel (variable transparency). Check this link for more details: http://www.w3.org/QA/Tips/png-gif
There are a couple of online file compressors. If you want to compress png files, you could try using http://tinypng.org/
No, jpeg image wont support transparency.But you can change the white background coming along with jpeg image
This question already has answers here:
What are the different usecases of PNG vs. GIF vs. JPEG vs. SVG? [closed]
(14 answers)
Closed 9 years ago.
I'm using ImageMagick to convert some files from one format to another. I was always under the impression that .png files were supposed to be as big/small as .jpg if not smaller, and definitely smaller than .gif.
However when I run
convert photo.jpg photo.png
The files I'm getting out is about 6 times bigger than the original jpg.
Original jpg is a regular photo about 300x500 px, 52 kb. Output is a proper png of the same dimensions, but size is about 307 kb?
Does anyoone know what the hack is going on? Am I doing something wrong?
P.S.:
I tried both on Debian and Windows with the same results.
P.P.S.:
Also when I add resize option to this and resize to 10000 x 10000. Converting and resizing to jpg takes a few seconds, but it works, if I do the same of png, I jsut strt running out of memory altogether
P.P.P.S.:
For people who keep marking this question as duplicate of PNG vs. GIF vs. JPEG vs. SVG - When best to use? . Please read carefully and understand the question. It's not a duplicate, since this question asks' about files produced programmatically with specific application (image magick). The question you marking as duplicate, is asking which image format is better to use on the web. Two DIFFERENT questions.
The key thing to note here is that each image file format is best for specific purposes.
JPEG stands for “Joint Photographic Experts Group.” That right there should tell you that the .JPG file format is optimized for photographs. It doesn’t work so well for line-art, logos, gradient or tiled / patterned backgrounds, and the like. .JPG’s DCT (Discreet Cosine Transform) artifacts (the “blocky” artifacts we all know and loathe) are much more noticeable with line art and logos than with photos.
PNG has replaced GIF for everything that GIF was ever good for, except one, and that only because no clear standard has emerged: animations. Animated .GIFs are well known on the Web. There are two competing standards for animated .PNGs: APNG and MNG.
APNG is supported in most modern browsers, and is also fully backwards compatible (the file extension is .PNG, not .APNG, and if any program that can display .PNGs but doesn’t know APNG is “fed” an APNG, it will display either a stand-in image of the developer’s choice, or the first frame of the animation if no such stand-in was provided — as far as the older program is concerned, it’s just an ordinary single-frame .PNG with that one image in it — the rest is safely ignored). Gecko (FF, etc.) and Presto (Opera) support it natively, and Google Chrome (using Webkit) can with an add-on.
MNG has the backing of the actual PNG-format development team, but is its own format and is not backwards compatible, but is more powerful and flexible. Right now, only KHTML-based browsers (Konquerer) support it: not Trident (IE), Gecko, Webkit (Chrome, Chromium, Safari), nor Presto.
PNG does everything (except animations unless enhanced with APNG) that GIF does, and better. All else being equal, a .PNG will almost always be smaller than a .GIF at the same resolution and bit depth. Like .GIF, .PNG can support color depths up to 8 bits per pixel in indexed-color (paletted) mode, but unlike .GIF (yet like .JPEG) it also supports direct-color mode at 24 bits per pixel.
In either mode it can add 8 bits of alpha transparency, unlike .GIF (which can only do indexed color transparency [pick a color out of the palette to be replaced with 100% transparency, aka invisibility] — .PNG can do that, too). Alpha transparency produces much better results than indexed transparency, because the pixels can be partially transparent, whereas with indexed transparency (the only kind available in .GIF) your choices are either opaque or invisible. This makes for “halos” around non-rectangular objects when placed against background colors other than the one the .GIF or indexed .PNG was originally “matted” against. It also inhibits being able to do effects such as glows, drop shadows, and, of course, see-through colored objects (without dithering). Alpha transparency can do all of those things with ease, against almost any background (glows would be largely invisible on a white background, and drop shadows would be invisible on black, but you know what I mean).
Yes, you can do 8-bit alpha transparency in an indexed-color .PNG! And guess what? Even Microsoft Internet Explorer 6 can display those just fine, complete with transparency! It’s only the 32-bit .PNGs (24-bit RGB color + 8-bit alpha) that IE6 choked on and displayed as gray!
The most well-known program that can export PNG8 (indexed color) with alpha transparency is Adobe (formerly Macromedia) Fireworks. The Photoshop “Save for Web and Devices” (at least as of CS3) could not do that, despite having basically lifted the feature from Fireworks when Adobe bought out Macromedia. It can save PNG8, but only with indexed-color transparency.
Anyway, full 32-bit (or even 24-bit) PNGs will be pretty large, though usually much smaller than the nearest equivalent .BMP or .TGA or uncompressed .TIFF or some such (unless you’re trying to do a photograph with it — that’s what JPEG is for!). It will usually be somewhat smaller even than .RLE (losslessly compressed .BMP) or losslessly compressed .TIF, all else being equal.
Unlike most of these other formats, PNG also supports 48-bit RGB color, with optional 16 bits of alpha transparency, for extremely high quality (much higher than most monitors can display). These are best used as an intermediate storage format, to retain information from a high bit depth scanner or camera (RAW mode) or some such. Their file sizes would be quite large, despite the lossless compression.
One thing that .PNG cannot currently do is handle non-RGB color spaces such as CMYK or L*a*b.
In short:
For photographs, use .JPG.
For line art and logos of limited color, use indexed-color .PNG (PNG8), with alpha transparency if needed.
For line art and logos of extensive color (e.g. lots of gradient fills, metallic chrome-type reflection effects, etc.), use direct-color .PNG (PNG24) with alpha if needed, if you want the best quality or need transparency (and don’t mind it not working in IE6 or use one of a variety of IE6 workarounds for transparent PNGs), and don’t mind the larger files and bandwidth usage. Otherwise, use .JPG, but be aware that the quality will be degraded. You may need to crank the JPEG quality up pretty high, especially for logos or other graphics with “text” in them, which would reduce your file size savings.
For non-Flash/Silverlight/video/HTML5 Canvas animations, .GIF if the main choice at present, but be prepared to switch to APNG (I don’t think MNG is going to beat it, despite the more official support from the JPEG developers).
JPG is a lossy compression algorithm while PNG is a lossless one.
This fact alone will (in general) make JPG images smaller than PNG ones. You can tweak the compression ratios for each format, so it could also be that you're not compressing your PNG files as much as your JPG ones.
For a photographic image saving as JPG will usually produce a smaller file than PNG as there's more noise or randomness in the image for the compression to work with. Images created by graphic art tools will tend to have more hard edges and areas of solid colour which will compress better in PNG.
If you have text in your image then PNG is going to produce a better quality image as the harder edges of the characters won't be blurred like they would be if JPG is used.
GIF is smaller because it's based on an colour palette (of 256 colours) rather than the separate RGB values for each pixel (or group of pixels) in JPG and PNG.
The PNG format can provide images of 24 bits per pixel or 8 bits per pixel. JPG is a 24 bit format, but it uses lossy compression to reduce the file size significantly. PNG and GIF both use lossless compression, but GIF only works with 8 bits so it requires your image to have 256 colors or less - this often results in a grainier picture.
Try the -colors and -dither options in ImageMagick to reduce the number of bits in your PNG output. At that point it should be comparable to the GIF file size. If you need to reduce it further, there are utilities to optimize the PNG.
The .jpeg file format is a lossy format, it throws information away. Which makes for good compression ratios. The .gif file format is not lossy but loses other information, it only supports 256 colors. The .png file format is not lossy and preserves the color range.
It depends on the kind of image. JPEG's lossy compression works very well on images with lots of color gradients (i.e. photos).
Try it on an image consisting of areas with the same color separated by sharp edges (screenshots are good, unless they show a photo desktop background, and the fancy window borders and task bar of Vista and Windows 7 also tend to mess this up). JPEG is bad at that kind of thing, and you'll probably find PNG to compress better (probably better than GIF too).
Replying to :
Does anyone know what the hack is going on? Am I doing something wrong?
yeah I study this, you aren't doing nothing wrong, you produced 8-bit/color RGB PNG
I solve it with reduce or compress png with pngnq ( http://pngnq.sourceforge.net/ ) that produce 8-bit/color colormap PNG.
pngnq seems to me the most improved project, since is a fork of others like pngquant etc, and is normally in main stream of Linux distros so I just do this:
convert photo.jpg png:- | pngnq -s 1 > photo.png
For the last upvoter (2016): pngnq as been deprecated in favor of pngquant (https://github.com/pornel/pngquant)