I'm looking for software to create PNG8 format transparent images as per this article.
NOTE: I need a Linux solution myself, but please submit answers for other OSes.
pngquant does a good job of converting to PNG8 while preserving full transparency.
If you're size-conscious, you may also be interested in pngcrush, which can usually (losslessly) compress PNG files quite a bit.
I also needed a Linux solution and found pngnq to do a pretty good job. It seems to be designed specifically for creating 8-bit PNG images with alpha channels.
apt-get install pngnq # If on Ubuntu/Debian
For Mac: ImageOptim and ImageAlpha are GUIs that run pngcrush, pngquant, and various other normally command-line compression utilities. http://pngmini.com/
The link you provided references ImageMagick, which is an excellent toolkit for manipulating images on Linux.
Ah, if I remember correctly, when I have read this article some months ago, pngquant hadn't a Windows version. I see it has one now. So I tried it, and pngnq too.
The latter seems to do a slightly better job on the IceAlpha.png test image (from libpng.org), at the cost of a slightly bigger image (it can be post-processed with pngcrush or pngout anyway).
The dithering algorithms (the two of pngquant, the only one of pngnq) are different, and it might be worth having both tools, converting images with all algorithms and see what looks the best.
For the record, on the Windows side, IrfanView (4.10) displays these images very well (using the transparency level on each palette entry) while XnView (1.85.1) and GIMP (2.4) apply only a full transparency/opaque display, à la GIF: the light bulb given as an example in the linked article has a transparent background around it, but the orange part is fully opaque.
And the excellent utility TweakPNG shows we have a PLTE (palette, 222 entries) chunk and a tRNS (alpha values for palette colors, 222 entries) chunk. Even more, it allows to edit each palette entry, color and alpha level. It might be an interesting complementary tool for this format.
Note on IrfanView support: if it handles PNG8 correctly for transparency, it doesn't handle gamma information in PNG files: on the toucan image or the ping-pong image, I had to apply a gamma of 2.4 to get similar (lighter) colors.
Note also that IrfanView does an awful job of converting 32-bit PNG images to 256, allowing only one transparent color, which looks bad if full color was dithered!
I see that the GIMP manual states: "his “PNG8” format, like GIF, uses only one bit for transparency; only two transparency levels are possible, transparent or opaque. "
while the ISO/W3C standard states:
"The tRNS chunk specifies either alpha values that are associated with palette entries (for indexed-colour images) or a single transparent colour (for greyscale and truecolour images).". The PNG specification 1.2 added: "Although simple transparency is not as elegant as the full alpha channel, it requires less storage space and is sufficient for many common cases."
It looks like the unique transparent color is more implemented than the full transparency palette, alas. At least browsers get it right.
It depends on what exactly your original images look like.
If your images already contain 256 or fewer colors (RGBA values), you need only look at pngout (Windows) (Linux/BSD/Mac OS X ports), which you should already be using to optimize your PNG images anyway. It can't quantize images, but it can save them as 8-bit, including alpha transparency. Just pass in the /c3 (or -c3 on Linux et al.) color option to force it to save the image as PNG8.
If your images do contain more than 256 colors, you have a few more, but all less than perfect options:
Adobe Fireworks is probably the best option in terms of the resulting image quality. It will do the job if you only need to convert a few images, or if you don't mind relying on Fireworks to do the batch processing. I did find that it sometimes somehow limits the number of colors in the palette, creating a worse quality image than necessary. I don't know if that's perhaps a bug in CS3 that's been fixed in CS4.
If you're not on Windows or OS X this obviously isn't an option, and buying Fireworks just for this probably isn't worth it either.
The only alternatives I know of are the already mentioned pngquant and pngnq. I've had better luck with pngnq, but that's probably just going to depend on which quantization strategy works best on the files you're working with.
Unfortunately, I've noticed that neither of them work very well with small amounts of transparency (say, an opaque image with transparent, rounded corners).
I recommend "The GIMP" as it is possible to output in PNG8 and supports Linux/Windows. If you want a quick Windows-only solution, I also recommend IrfanView.
Microsoft Windows: Ultimate Paint (freeware and shareware
versions are available).
Both versions can save as an 8 bit transparent PNG image.
It can also save as a 4 bit PNG (16 colours). This cuts the
file size in half compared to 8 bit.
Input formats include BMP, GIF, ICO, JPG/JPEG and PNG.
The freeware edition of Ultimate Paint Standard 2.88 LE can
be downloaded directly from
http://www.ultimatepaint.com/up.zip (1.7 MB).
Related
I have been looking at SVGKit and I am finding conflicting ideas. Some say it's slower than PNG and others saying it is fast.
I was hoping to get a recommendation and which route I should take. When I am exporting my vector graphics to PNG for display, would it not make sense to use an SVG instead ?
Of course this gives the added value that it remains a vector.
Or is it still recommended in exporting everything to a PNG ?
You might consider the middle-way introduced in Xcode 7. Here you add your assets to the project as vector images (PDF) and at build-time Xcode automatically generates the PNGs in all needed sizes (1x, 2x, 3x).
Personally, I only use SVGs when necessary, like if I need to be able to change the color of the (parts of the) image. I believe there can be a performance hit when resizing vector images at run-time, although Android uses vectors as default, so it might be insignificant.
SVG is most resource intensive and can be used if you need to display something that can be zoomed in and out while PNG should be preferred for most UI graphics (logos, icons, etc.), as it is crisp yet remains lightweight and fast to display so there is no way to compare SVG with PNG in term of Performance.
if you are going after a Crystal clear images you can use pdf based graphics, which are supported by Xcode Using Vector Images in Xcode
if you still need to implement SVGKit i always suggest using some tools (like SVGCleaner) to clean and simplify SVG in order to enhance performance.
I have a question about png-8 vs png-24 usage vs Xcode's built in "image compressor".
Some images converted to png-8 are just fine saved like that, because difference between png-24 version can't be noticed easily. But some images have to be stored as png-24 so that quality remains at high level... Same image is about 3 times smaller when saved like png-8, so I guess there would be some benefits in memory consumption when using png-8 vs png-24. But what I am not sure is:
Does iOS "likes" more png-24 ?
Are there any problems with using png-8 instead of png-24 in iOS and what is a preferred choice ?
What are benefits to optimize image in PS (or some program like TexturePacker) when COMPRESS_PNG_FILES in Xcode is set to YES because I suppose Xcode in some way overwrites our optimization done in PS?
What actually Xcode does when optimizing images?
I know that just letting Xcode to do what it suppose to do is probably more than enough, especially for newer devices with enough memory and cpu power, but I am curios what's happening "under the hood" and is it wasting of time doing optimization in Photoshop?
Does iOS "likes" more png-24?
iOS certainly likes its images to be close to its own hardware format (see below). However, it may not presume a certain format, or convert images at will. This would mean that the default postprocessing could convert images from palettized (8-bit) to true-color images, and that would be destructive if the application expects its images to contain a palette. There are many good & proper uses of palettized images.
Are there any problems with using png-8 instead of png-24 in iOS and what is a preferred choice?
Color depth - higher is better, for some kinds of images (but not all). Size - smaller is better (and for deciding when, you are on your own). Other than Sangony states, the PNG specification is generous enough to allow more than a single bit of alpha even in indexed mode. That is, the usual RGB palette may also be RGBA, including alpha. I am not aware of any "problems" with more common PNG formats, or even the uncommon ones.
What are benefits to optimize image in PS (or some program like TexturePacker) when COMPRESS_PNG_FILES in Xcode is set to YES because I suppose Xcode in some way overwrites our optimization done in PS?
Photoshop is not extremely good at optimizing PNGs, but then again it's certainly not one of the worst. pngcrush (the original) is written specifically to try and squeeze the very last byte out of a PNG -- but at its highest setting, it can really take a while to do so. I may have used Apple's modified pngcrush unknowingly, since it is "on" by default; I have not found such a huge delay when compiling code, so Apple's default may be not the highest possible setting. This suggests that manually running pngcrush could be worth the time, in which case you definitely do not want XCode to undo it.
What actually Xcode does when optimizing images?
The most visible 'optimizations' are: switching storage order from RGB to BGR and discarding the alpha channel by premultiplying it with the color channels. See also my earlier answer.
The storage order thingy is, presumably, optimal for the default target devices (iPads, iPhones). Premultiplying alpha is a common method of optimizing, because then it takes less calculations to display the images in real time. (There are some disadvantages to it as well.)
Without any exact measurements, one can only speculate if these optimizations really matter on modern hardware. All internal conversions to 'display' format may very well be cached as quickly as possible.
Xcode uses PngCrush behind the scenes to optimize .png files. Here is also a good blog post that can answer your questions.
Aside from the available colors between PNG8 and PNG 24, the main difference is the the transparency aspect.
PNG8 alpha can sometimes be somewhat jagged in appearance whereas PNG24 is much smoother. If alpha is not a concern for you and the image looks good enough, then PNG8 is probably the way to go.
PNG8 Alpha
PNG24 Alpha
Guys i have 2 images one with CMYK color model and other with sRGB.. I would like to find out which color model is better to use while dealing with image processing like resizing, cropping, color filling etc..
Thanks in advance guys.. !
CMYK color space is used for print, (s)RGB is used for screens (web, monitors, tvs etc). If one were to open a CMYK document in a viewer/program that doesn't support the color profile (which is not uncommon, since CMYK isn't as widely supported as RBG) the colors would appear to be extremely over-saturated. If you are altering the images for use on the web, or in an application, I would highly recommend that you use some variant of RGB.
In short, neither is really better than the other in general, it all depends on where you will be using the images (apples and oranges, comes to mind). CMYK is better for print, and (s)RGB is better for screens.
UPDATE in response to OP's comment:
Just to be clear (forgive me if you already know this) color space/profiles do not affect the resolution of an image, they only affect how the colors are handled/encoded. Resolution is only affected by file dimensions, DPI/PPI (dots/pixels per inch) and compression.
UPDATE 2 in response to OP's comment:
I'm not familiar with "Imagemagick", but in general, I can tell you that I've converted thousands of documents to RGB from CMYK (and vise versa) and never noticed any degradation in quality, when the file is viewed in a program that supports the color profile. The only exception is when converting to CMYK FROM RGB, it is possible to lose a wee bit of vibrancy (due to the fact that CMYK is a smaller color space. Like I said before, if by "quality" you mean "resolution" the color profile won't effect it, the image won't suddenly lose clarity, when switching color profiles. Let me know if you have any other questions.
Neither is "better" for these purposes. In general you should use the color space/model that best aligns with your output device, like CMYK for paper and sRGB for screen, but for manipulations (such as resize, crop) they are the same.
the best is sRGB because is larger and the color are better preserved. AdobeRGB is even better. But remember that if you want to distribute you graphic image you have to know what kind of device will be used to print/view. You may use also a AdobeRGB but when you print it, you'll be sad, because many colors of AdobeRGB cannot be seen on a paper.
Cheers
For a dynamic imaging application I'm building, I have to take an image created by a rendering package and place it in an InDesign file. Because it needs to be CMYK with transparency, TIFF is the only possible format to use. The difficulty I'm having is that the renderer is generating an image with an unassociated alpha channel, which InDesign seems to have trouble understanding.
I'm working with the renderer manufacturer to see if they can change their output format, but in the mean time I would like to find some automated workflow to convert a CMYK TIFF with unassociated alpha to have associated (premultiplied) alpha.
I tried using GraphicsMagick's command-line tool (which would be easily scriptable), but the closest I could get simply forced the TIFF flag to get written as premultiplied--it didn't actually perform the premultiplication. The effect is a working alpha but with washed out color:
gm -convert <infile> -define tiff:alpha=associated <outfile>
Does anybody have other suggestions on how to achieve this conversion? My primary requirement is that it needs to be automatable in a Linux server environment, ideally via either scripting or a PHP library (since that's already being used elsewhere in the workflow), but I'm flexible on the PHP bit.
Edit:
For reference here are the two files (42MB each):
Original TIFF with unassociated alpha
Modified TIFF from GM with pseudo-associated alpha and washed out color
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)