Jump to content

Talk:PNG/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Abbreviation meaning

According to Richard Stallman, the meaning of PNG stands for PiNG is not GIF. This is mentioned in the article as not official, but n source is mention ed. This claim is since it does use the gzip-compression instead of the lzw-algorithm as used in the GIF standard. Many references to this can be found on the internet. G Braad 1 January 2007

Multimedia Wiki

Could some of the authors contribute to the wiki.multimedia.cx PNG article? I have copy pasted some sections from wikipedia, and am unsure if it is acceptable on second thought. This was done solely by me, not the maintainer, and if it is incorrect I apologize and will remove them. Dcsmith77 02:56, 21 October 2006 (UTC)

About copying from Wikipedia: you can copy any page from Wikipedia (or even the whole lot, like answers.com.... but there are some conditions. The license is the GNU Free Documentation License (GFDL). I'm not an expert, but the general rules are:
  • You can quote a few lines, just like you can for anything (fair use). If you do this, place it in quotes and say it comes from Wikipedia.
  • You can copy whole pages (or the whole of Wikipedia), if you say it's copied from Wikipeda and say that it (and any modifications you make) are GFDL licensed, and provide a link to the GFDL. For example, answers.com says: "This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article 'PNG'".
Full, agonising discussions are at Wikipedia:Copyright. --h2g2bob 03:56, 21 October 2006 (UTC)

Internet Explorer 7

(Your Standard Anti-Troll-War Discl: I hate working with IE 6/XHTML/CSS2-combination and I can only hope that IE 7 will be an improvement, etc. But.)

The Web browser support for PNG section contains the following: Internet Explorer 7 has limited support for PNG transparency. It displays the wrong colors within images and thus does not have 100% compatibility.

Is this a piece of fact or simply Criticism of Internet Explorer? ;) I think there are at least two totally different things mixed here into one line:

First, IE 7 has a new PNG alpha channel engine [1]. Is it limited? If yes, then what are the limits? Facts, please.

I am not aware of any limitations or errors; it appears to pass all of my test cases. But note that the combination of alpha and gamma is quite tricky, and I have not tested that. (There would seem to be little purpose to it at this point; see below.) -- Roelofs 08:38, 22 December 2006 (UTC)

Second, I think the wrong colors in Internet Explorer's PNG images is due to the fact that it has a native PNG engine instead of "the almost standard" libpng [2]. Results are different than with libpng, but is it wrong or not, that is a complex question [3].

No, IE7's gamma support is demonstrably wrong. The argument goes like this: HTML colors are recommended to be in the sRGB color space. CSS colors are required to be sRGB. (sRGB is defined to have gamma 2.2.) Legacy web-page designs used unlabelled GIFs and JPEGs in combination with HTML and CSS colors and matched them by eye; ergo, unlabelled images, including PNGs, should similarly be considered sRGB for the sake of backward compatibility (which virtually all browser-vendors deeply care about). Immediate corollary: any browser that gamma-corrects unlabelled PNGs in a manner different from PNGs containing an sRGB chunk, an sRGB iCCP chunk, or a gAMA 1/2.2 chunk is in error. Any browser that gamma-corrects the latter three categories of PNGs in a manner different from HTML and/or CSS colors is in error. IE7 treats PNGs with gAMA chunks inconsistently with its treatment of HTML and CSS colors; ergo, it's broken. (It also doesn't support color correction at all.) [4] -- Roelofs 08:38, 22 December 2006 (UTC)

(By the way: a quick fix to the gamma correction problem is to optimize all layout PNG's for web use by stripping out all unnecessary PNG chunks -- including the color correction data.)

That works only on systems approximating sRGB (which, admittedly, is most of them these days). Doing so on a Mac (at least, older models), an SGI workstation, or a NeXT cube would probably be a mistake. -- Roelofs 08:38, 22 December 2006 (UTC)

Now if we combine this all -- does IE 7 has 100% compatibility with PNG or not? It can handle both binary transparency and alpha channels, alpha channel mixing, and (a bit unrelated to the transparency) gamma adujstment that is different than with libpng. Remember that libpng is not the PNG standard [5][6], it is only one way to interprete these images.

On the other hand, libpng was written and is maintained by those who wrote the specification; that is not true of MSIE. ;-) In any case, I modified the wording in this section earlier this evening, and I included a link to my screenshots/analysis page. -- Roelofs 08:38, 22 December 2006 (UTC)

-- Talamus 01:24, 4 September 2006 (UTC)

All I know is that PNGs (transparent or not) never seem to match the background color I put them on in IE7. They always seem slightly too dark, which makes an ugly blocky image where a nice transparent image is supposed to be. That doesn't sound like 100% compatability to me. --68.92.63.48 16:56, 25 December 2006 (UTC)

Converting

Juuitchan wants to convert some BMP images to PNG for an article. Anyone willing to help out here?

For easily manipulating images in pre-determined ways (changing attributes, converting to other formats, resizing, etc.) my favourite toolset is ImageMagick. It's free software and runs on most common operating systems. -- Bignose

Most modern raster graphics tools understand PNG (those that don't aren't worth using), but some understand the format better than others. Also, people sometimes forget that PNG has got 8bpp and 16bpp modes, which are complete overkill for most maps and flags and such. PNG Tips for Cartoonists is an introduction to PNG for comics artists, but most of the article contains pretty useful information for Wikipedians too. The tool mentioned in the article, pngcrush, really does squeeze the last bits out of your PNG files and comes recommended.--user:Branko

If he can put them somewhere I can access them (like FTPing them to ftp.piclab.com:/incoming), I'll do the job. If he wants to do it himself, I recommend Paint Shop Pro from http://www.jasc.com . --LDC

Papua New Guinea

Might need to disambiguate this from Papua New Guinea at some point —Mulad, May 29, 2003

seems someone did that a while ago now. Plugwash 22:51, 5 August 2005 (UTC)

License

Does anyone know what license PNG is released under? For all the talk of the GIF proprietary format and Unisys's reneging on allowing opensource developers to use it, the article does not mention what licence PNG is.

A document telling about the licence of PNG on the offical website ( http://www.libpng.org/pub/png/src/libpng-LICENSE.txt ) does not seem to indicate that its opensource. --user:ShaunMacPherson

I think this question confuses a few different concepts: it doesn't make sense to talk about the "license" of PNG. PNG is a specification, not software. In other words, it's not a program, it's just a list of guidelines of what a PNG file should look like. Terms like "open-source" and "closed-source" don't make sense. The important point for a specification is that it be open and not patented (which is the case for PNG). Now, once developers are given a specification, then they can write specific implementations of it, which can be either open- or closed-source. The link you gave refers not to PNG itself but to a specific implementation of the standard, "libpng". And in fact if you read the licence carefully, although it does not use the words "open source" as such, it says:
Permission is hereby granted to use, copy, modify, and distribute this source code, or portions hereof, for any purpose, without fee [...]
So it is open source. But not all implementations necessarily have to be (although right now in practice everybody just uses libpng). Hope this clears things up. --Shibboleth 04:00, 31 Aug 2004 (UTC)
Actually, everyone very much doesn't use libpng. IE probably doesn't, since it doesn't do pngs properly. Photoshop doesn't either, since it even in newer versions uses some otherworldly bulky method which mostly gives crappy results. I'm sure everyone agrees that these two make "everyone" a too strong word. ; ) 130.232.120.145 20:02, 22 Mar 2005 (UTC)
that license that was linked (which is for libpng not the png spec itself) seems to be a fairly standard 3 clause BSD/MIT with a load of explanitory details and authorship information around it.Plugwash 23:41, 25 May 2005 (UTC)
The real problem with GIF has to do more with patents than with copyright and closed source. The patent is not on the GIF format per se, but on a compression algorithm (LZW) that the format optionally uses, which until recently required a license from Unisys to implement. This license cost what I remember as being a relatively nominal fee, but Unisys could have at any time changed the terms, and open source developers didn't like the idea of being beholden to Unisys for what they saw as no good reason. The patent has expired, but PNG is still considered a technically superior format in many ways, so that even if GIF hadn't been encumbered, it would still be worthwhile to switch to PNG. grendel|khan 14:32, 2005 May 26 (UTC)

Compare two PNGs

Does anyone know how to tell whether two PNG images are the same image, i.e. all pixels identical? If there's no transparency, one can convert to PNM and use pnmpsnr. But in general? dbenbenn | talk 21:37, 3 Jun 2005 (UTC)

Bah. Apparently I'll have to learn the PNG format and write my own program. dbenbenn | talk 21:40, 18 Jun 2005 (UTC)
i've written a png writer but i've never attempted a reader, sorry. Plugwash 22:02, 18 Jun 2005 (UTC)
Can't you just convert to RGB or RGBA with ImageMagick's convert program, then do diff --brief on the result? Ojw 00:31, 15 August 2005 (UTC)

Bitdepth and other jargon

Is bitdepth, used here, the same as Color depth? I've wikilinked "bitdepth", but this is the only place that term appears, so if it's the same as "color depth", maybe it should be standardized? I don't know much about image formats, so I won't make the change. CDC (talk) 2 July 2005 17:43 (UTC)

the term bitdepth is actually used in at least 3 places. (once in a table twice in the body text). i'll try and improve the workding but its rather meaningless to talk about the color depth of an individual channel especailly if the thing being reffered to is a greyscale image or an alpha channel. Plugwash 3 July 2005 20:37 (UTC)

Transparency

IE doesn't support transparent png.' There is some merit to this. IE cannot resolve this issue if an image is contained in an <object> tag. =Nichalp «Talk»= July 4, 2005 10:16 (UTC)

As the article stands, we have "Misconception: Internet Explorer not supporting transparent PNGs. (This is untrue; Internet Explorer supports binary transparency in PNGs, just like with GIF, but lacks support for alpha channels.)", which sounds rather odd.

If you take a transparent PNG and put it on a coloured web page, Internet Explorer will display it with a grey background. To me, this indicates that IE doesn't support transparent PNGs, or at least, that we can't just say "It's untrue that IE doesn't support transparent PNGs" (which may be pedantically correct but misleading).

For example, if you want an antialiased graphic that blends with the background of your website, you can't do it in IE (at least not without your users' installing extra features onto their browser, or using ActiveX hacks). Admittedly you can't do it in GIF either, but it still means that IE is the only major browser not to support 'normal' PNG transparency, which is probably worth mentioning in this section. Ojw 11:54, 27 July 2005 (UTC)

PNG has mutliple transparancy mechanisms as described in the techical details in the article. IE supports some of them but not others. The ones it supports can do everything that gif transparancey does. The ones it doesn't support can't be done in either gif or jpeg either so do not provide reasons not to use png. Plugwash 22:08, 29 July 2005 (UTC)
IE supports binary transparancey with no problems in both indexed and truecolor images but composes the alpha channel in truecolor images with one against a fixed background color and renders partially transparent pixels in indexed color images as fully transparentPlugwash 22:08, 29 July 2005 (UTC)
OK, let's say you have a valid transparent PNG, and you put it on a webpage because a comment like yours indicates that "MSIE supports transparency", and "It's a prevalent but untrue myth that IE doesn't support transparency". The image will still be opaque, and fuck-up your website for IE users by displaying a solid-colour background where it should be transparent. Writing an article about PNG and IE without mentioning that the two are incompatible is not a good idea, although admittedly it only affects IE users so theoretically I don't care. Ojw 22:38, 29 July 2005 (UTC)
I've reworded it a bit now. The fact remains that IE supports BINARY TRANSPARENCY with png (all color varieties) which is all that any other format common on the web offers. Plugwash 23:48, 29 July 2005 (UTC)
There is a slight mistake. IE only supports binary transparency in palette-based PNGs (or indexed, those that imitate GIF), but not in truecolor and grayscale ones. And for palette-alpha ones, any transparent entry of the palette, whatever its degree of opacity, is treated as fully transparent (only opaque values are displayed correctly). That's why only binary transparency works.
Coming back to truecolor and grayscale images, there's a way, at least, to display a PNG of that type against a user-defined color background instead of Windows's default one (light gray or whatever). This can be done by adding a 'bKGd' chunk. TweakPNG is an excellent tool for this, as it's really easy to use thanks to its GUI (it works under Windows 9x/NT/2000/XP).
By the way, Jason Summers' PNG transpency test page is a good way to check what kind of transparency such browser does or doesn't. Dioxaz 19:24, 21 October 2005 (UTC)
true binary transparency in truecolor images works just fine in IE here are you sure that your truecolor test image is specifying a single transparent color rather than using an alpha channel? Plugwash 20:08, 21 October 2005 (UTC)
I'm sure that J. Summers' test is one of the most accurate I could see till now. Take a look at this (one of the numerous sprite-sheet pages of one of my websites). This image is truecolor with a tRNS chunk. Normally, you shouldn't see the blue background (0 0 255) as it's specified as the transparent color in my tRNS chunk. But it appears that in my version of IE (6.0.2900.2180.xpsp_sp2_gdr.050301-1519IS), the blue background is effectively here while in other browsers, it is clearly transparent. If you see this image transparent in your version of IE, please make me a screenshot. ;) Dioxaz 23:58, 21 October 2005 (UTC)

I am having major issues making my black backgrounds transparent. It shows up on my IE browser as transparent but they are not truly alpha transparent or whatever it's called. What can I do to make my images be truly transparent? EJRS 07:30, 17 December 2006

Metadata

Does anyone have any idea what all gratis software are available to write metadata into a PNG file? =Nichalp «Talk»= July 4, 2005 10:20 (UTC)

GIMP 2.2 has, I am told, a full metadata editor plugin. I'm testing it out at this point; I'll follow up here once I've figured it out. grendel|khan July 4, 2005 19:09 (UTC)
Okay, I can't seem to find it, if it's in there. Must not be included in the latest Windows version. There's an EXIF browser you can get for it, or a much, much more full-featured one which happens not to be fully implemented yet, but is in the GIMP CVS and scheduled for release along with 2.3.0, it seems. grendel|khan July 4, 2005 20:03 (UTC)
Here's something to read metadata... grendel|khan July 4, 2005 19:25 (UTC)
Okay, I got it for sure this time. Use PNGCRUSH; it reads and writes tEXt, iTXt, zTXt and pretty much every other kind of chunk. Use pngcrush -v -n file.png to get the metadata. grendel|khan July 4, 2005 20:09 (UTC)
Thanks, but I couldn't fully run the win32 version I downloaded. I copied it into the system32 folder, but 'pngcrush' seemed to be a non existant file. :( =Nichalp «Talk»= July 9, 2005 06:05 (UTC)
I've used pngcrush (on linux and windows) and it works great, both for reading and writing metadata. If you run it without any arguments, it will tell you the syntax. For example, to insert an uncompressed itxt chunk after the idat data you would use pngcrush -itxt a your_keyword_here you_textual_data_here input_file.png outputfile.png eck
Hey people, this is forgetting about TweakPNG from Jason Summers. Not only it can display all metadata contained in PNG files, but it can also edit them and add new text chunks, and really easily. Dioxaz 18:57, 21 October 2005 (UTC)

popularity of png

well for starters a google search for gif returns an order of magnitude more results than png secondly from just generally browsing the web gif still seems to be seen a lot more than png. I'm sure you could find other sources if you looked hard enough. saying gif is more popular than png is like saying IE is the most popular web browser its so obviously true that it doesn't really need a source. Plugwash 19:51, 2 August 2005 (UTC)

OK, I don't mind that GIF is more popular, was just writing a 'note to self' that it would be a better article if we said how much more popular with a link to someone who's done a survey.
We also have "GIF is still more widely used than PNG mainly due to misconceptions or ignorance", the bold bit being new. Again, is that really what they say in encyclopedias?
Even if it's only google, as you say:
  • Results for "site logo" in GIF format: 491 [7]
  • Results for "site logo" in PNG format: 1770 [8]
(that wasn't a rigged test, b.t.w. I just searched for the first phrase that came into my mind related to images, and was fully expecting it to support your theory) The google image search numbers for that example are 569,000 GIF, 14,000 PNG. Searching for "gif png popularity" doesn't reveal anything more authoratative than this very wikipedia article.
Ojw 22:57, 2 August 2005 (UTC)
There are only two good reasons for using gif over png animation (and lets be honest most images on the web are not animated) and supporting very old browsers (which i highly doubt most website coders code for in other ways). That just leaves misconceptions ("png is larger than gif" is scarily common, so is thinking that browser spport for PNG is much worse than it really is) and ignorance (not knowing what png is and why they should use it) Plugwash 00:15, 21 October 2006 (UTC)

Filesize

Think it might have been me who wrote this, but "When making comparisons between the size of PNG and GIF files some people mistakenly compare a true color PNG file with a 256-color GIF file and conclude that GIF files are smaller than "the same" image in PNG format." - surely if you convert GIF to PNG the PNG will be almost as small (because it only uses 256 colours, so compresses well), whereas if you save some other format to both GIF and PNG, the GIF gets downsampled but the PNG retains additional information not available in the GIF. Maybe we need to reword that somehow... Ojw 23:41, 2 August 2005 (UTC)

Just tested this using a 420x300 image with lots of colour in: (all non-transparent with no optional metadata)

  • PNG, truecolor: 146KB
  • GIF, 256-colour: 66KB
  • PNG, 256-colour: 58KB

So if you opened a GIF and saved it as PNG, it would be a smaller file with the same amount of information in. Ojw 23:54, 2 August 2005 (UTC)

I think that depends on the image itself. An extensive study of this would be very interesting, though. Wouter Lievens 12:02, 14 August 2005 (UTC)
yes a 256 color png will contain the exact same information as a 256 color gif and will almost certainly be smaller provided a reasonable png encoder is used.
Sure you can create contrived test cases where gif beats png but i've never heared of a real life image where this applies. Plugwash 12:25, 14 August 2005 (UTC)
Maybe we could nominate (say) 3 images, then for each row in our comparison of graphics file formats page, list the filesize of each image with a note about how much information (if any) was lost while saving (maybe with a closeup of the compression artefacts). e.g.:
  • A photograph of a natural scene, or a satellite photo
  • A screenshot, logo, or something with blocks of colour
  • A monochrome image (e.g. something from a NASA probe)
  • A rendered scene, or something with lots of colour gradients
Only problem is whether that comes under Wikipedia:No original research Ojw 12:35, 14 August 2005 (UTC)

Intro paragraph

"but it is often spelt out possibilly to avoid confusion with the internet tool ping"

What is the phrase trying to say? (i.e. could someone reword it to make sense, as I'm not 100% sure what the meaning is supposed to be)

-- Matthew0028 13:02, 14 August 2005 (UTC)

It's trying to say that it's often spelt out: pee en jee. --Zundark 18:24, 14 August 2005 (UTC)
I think it means: "It's often pronounced 'P. N. G.'. One reason for so doing is that the word "PNG (pronounced 'ping')" might be mistaken for the word "ping" (which is a UNIX command/program/protocol, among other things)".

Just noticed: you might want to put a note into ping (disambiguation) if people will be calling it that, and someone looks up the Ping graphics format on wikipedia to see what it is... Ojw 18:38, 14 August 2005 (UTC)

Seeking backwards

It depends on how techincal we wan't to get. Saying that IDAT contains the image data implies that there can only be one IDAT chunk. After saying there can be multiple IDAT chunks there needs imo to be some insight into why and the only reason that makes sense is to allow a large image to be written bit by bit without the need to seek backwards.

Of what relevance is the Windows Picture and Fax Viewer link to this article?

If we linked instead to Comparison of image viewers, that would probably give a good description of which image viewers support PNG. Ojw 21:19, 17 September 2005 (UTC)

Colour/color

Someone just changed all instances of "colour" to "color", marking it as a "minor" change. However, wikipedia style seems to be that articles should be left in the language (US/UK/CA) that they were originally written in, rather than changing things just for the sake of making the article americanized.

"If an article is predominantly written in one type of English, aim to conform to that type rather than provoking conflict by changing to another.".

Ojw 20:19, 21 September 2005 (UTC)

Gamma correction

Removed this from "Reasons why people use GIF":

  • PNG images use something called gamma correction, which is designed to compensate for the fact that not all monitors display the same color the same way. For example, what a webpage may define as "blue" may appear as one shade on one monitor (or OS) and another shade on another monitor. This is a wonderful concept, except for the fact that other graphics and stylings may end up not being the same shade as the adjusted png image. A designer may specify both a PNG and the page background to be a specific shade of blue, but the PNG may use its gamma correction and automatically display itself as a slightly different shade than the background. For designers, who often value consistency, this is unnacceptable.

Not terribly technically coherent, and incomplete. The explanation seems to confuse gamma and colour space (and PNG supports both gamma and colour space specification). Saying PNG "uses gamma correction" is a bit confused. But further, those features are all optional. If you want a "plain" PNG whose pixel values go through unprocessed, like a GIF, you just don't specify gamma or colour space. Alternatively, on the web, mark the image as sRGB, which is how web colours and GIFs should be treated. And if you still have problems, then in effect the complaint boils down to "some apps don't support PNG as well as GIF". --KJBracey 08:44, 15 December 2005 (UTC)

It is my understanding that gamma correction is only used on systems with a calibrated gamma profile, otherwise executing a correction would be useless guesswork. Dread Lord CyberSkull ✎☠ 07:39, 31 December 2005 (UTC)
Not so. Even if a system has no colour profile or specific gamma profile support, then you still need to handle the gAMA chunk just to make PNG files with different gAMA values appear consistent. A typical handling would be to display PNG files without a gAMA chunk, or with the gAMA value 1/2.2 unaltered (on the assumption that a typical computer, in the absence of other info, uses the sRGB colour space). PNGs with a gAMA chunk with a different value need to be lightened or darkened. Part of the PNG test suite tests this by presenting the same image encoded with different gAMA chunks. All versions need to look identical.
So implementing PNG forces you to make some sort of decision as to what your native gAMA value is. Choosing 1/2.2, the sRGB value, is no worse guesswork than the "guesswork" of displaying a GIF or PNG with unaltered pixel values. And it is definitely the right thing to do if you pass through HTML pixel colours unaltered, as the HTML specs specify that HTML colour values are sRGB. --KJBracey 09:57, 1 January 2006 (UTC)

POV tagged

This article is pretty obviously pro-PNG (and also a nice example of Wikipedia being "the encyclopedia Slashdot built"). Could you guys try to tone down the cheerleading a bit? Both "Comparison" sections do not belong here at all, since any comparison requires personal (i.e. POV) interpretation and constitutes original research by the contributors. Neither are appropriate in any encyclopedia, including Wikipedia. —Preceding unsigned comment added by 68.169.62.96 (talk • contribs) 18:48, 2005 December 28

Have to disagree there - the choice of different formats for different types of image is not POV - it is well known that JPEG is better for photos (which the comparison STATES and is not therefore PNG cheerleading as you suggest) since it was designed for that purpose, and GIF is better for 'graphical' images (ie drawings rather than photos) - and since PNG is intended as a replacement for GIF it stands to reason that PNG would be better than JPEG for the same types of image that GIF is better than JPEG Cynical 23:09, 30 December 2005 (UTC)
I'm sorry, but I can see nothing untrue in the small comparison section. Nor do I see any POV, as it is limited to several facts. The JPEG comparison, while much more verbose is quite true as well. JPEG does suffer from those problems and PNG is unsuited for photography or very high resolution type images. Furthermore your opening statement, containing what looks like an adversarial statement, only serves to invite further mud slinging. Please keep criticisms constructive. Dread Lord CyberSkull ✎☠ 07:37, 31 December 2005 (UTC)
Agreed: the section as it stands is written in a fair, factual, and neutral way. I'm removing the POV tag. —Lowellian (reply) 15:29, 1 January 2006 (UTC)

"pngs not gif"

any sources for this claim or is it just heresay. if the latter then its getting reverted. Plugwash 22:50, 6 January 2006 (UTC)

scaling problems.

I have found that when using some PNG images, when they are shown at a lower size in an article, the automatically generated lower-sized version is much larger in filesize. This certainly happens with Image:TerraNovabox.png. The image is 28kb, and has a resolution of 259x301 pixels. When shown in the Terra Nova: SFC article at 250px, the resulting file is 119kb, over 4 times the original filesize. As such, I showed it at the original size in the article (9 extra pixels in width doesn't really affect infobox) Why does this happen? If it helps, I'm running IE 6 (though this seems a server-side issue), and I converted the image from GIF to PNG in Paint Shop Pro 7. I have not put the file through any optimisers.--Drat (Talk) 02:17, 17 January 2006 (UTC)

Imagemagick upconverts the image to RGB before doing any scaling. unfortunately it doesn't have any system built in to decicide if it should convert back to 256 color or not so the result is that all scaled images are RGB color. Also the very process of scaling can introduce a flood of extra color transisitions round edges that the compression system used in PNG doesn't like. Plugwash 02:56, 17 January 2006 (UTC)
Very interesting, thanks. Is there a warning about this anywhere? If there isn't, there should be. I'm on 512k ADSL, and it's annoying. I'd hate to think what it's like for 56k'ers.--Drat (Talk) 03:02, 17 January 2006 (UTC)
Sometimes you want a thumbnail to have more colours - especially when the image is black and white. I have proposed to developers that Mediawiki add a feature for explicitly specifying the colour count for a thumbnail, and it performs palette selection and reduction automatically. But I haven't entered a bug for this yet and it certainly hasn't been added yet. In the meantime, if you really have a filesize problem, simply upload a second thumbnail version of the image (on the Wikipedia where the article using it lives, not Commons), crosslink the two, and put a big bold notice explaining its purpose. I've done this in the past with some of my images. Deco 05:39, 24 January 2006 (UTC)
http://bugzilla.wikimedia.org/show_bug.cgi?id=1757 Plugwash 12:45, 24 January 2006 (UTC)

PNG can be truecolor

So I'm removing the part about PNG not being truecolor. It says on the PNG website, and Adobe Photoshop (among many other image editing tools) can save to 24-bit (truecolor) PNG. —Last Avenue (talk) (contribs) 00:58, 12 February 2006 (UTC)

The note you are refering to was actually talking about GIF supporting more than 256 colors (which it does, but almost nothing supports it), not saying that PNG doesn't support true color. Qutezuce 01:23, 12 February 2006 (UTC)
Supports is quite a stretch, its more fair to say its possible to abuse its multi-image features to get more than 256 colors in your image. feel free to reword it if you can do so without making it too lengthly. Plugwash 01:30, 12 February 2006 (UTC)
Huh? I'm confused. Difference between revisions. Either that, or the comment doesn't actually relate to the text? —Last Avenue (talk) (contribs) 17:25, 12 February 2006 (UTC)
Nothing on the page or in that revision said anything about PNG not supporting true color. I think you must have misinterpreted it. The stuff that was in the HTML comment in the article was actually about GIF's "support" of more than 256 colors. Qutezuce 20:03, 12 February 2006 (UTC)
The comment says:
Gif article contridects this. I know its very rare for a more then 256 colour png but possible I think.
Then, part of the text says:
  • PNG gives a much wider range of color depths than GIF (truecolor compared to 256-color)[citation needed]
Why would citation be needed if the article says GIF has 256-color? And why the strange comment? Did the author of the comment mean gif but typed PNG? —Last Avenue [talk | contributions] 01:19, 14 February 2006 (UTC)
My apologies, whenever I read that comment my mind substituted GIF for PNG there because there isn't really any doubt about PNG supporting more than 256 colours. I believe the author of the comment intended to write GIF, not PNG. Qutezuce 03:06, 14 February 2006 (UTC)

Exif

"That said, PNG does not support Exif image data from sources such as digital cameras, which makes it problematic for use amongst amateur and especially professional photographers."

Sure png doesn't call the feature exif but it certainly supports storage of arbitary name-value pairs which is what exif data basically consists of. Plugwash 17:05, 5 June 2006 (UTC)

PNG vs. TIFF and PSD for image editing

Since PNG is a lossless image format and it compresses better than TIFF does (and apparently better than PSD, if my test is accurate), could it be used for image editing? I'm not talking about a total replacement. There are probably limitations and problems with using PNG this way. However, would the average user be better off using PNG instead of TIFF when editing images? Photoshop won't let me save an image as a PNG, except as a copy (or a JPEG). However, it will let me save it as a TIFF or PSD, presumably since there is no loss of data. I did a test on a 5.9 MB JPEG image. I saved it as a TIFF and got an image size of 26.2 MB and as a PNG, which gave an image size of 12.2 MB (47% of 26.2). It did take longer to save the file as a PNG, though (10 seconds or so compared to a second or two). A table of the size with the different formats is below. Unfortunately, the image was too wide to save it as a PICT.

  • JPG 5.9 MB (original)
  • GIF 5.2 (just for the hell of it)
  • JP2 7.7 (highest quality lossy)
  • JP2 10.7 (lossless)
  • PNG 12.2
  • PDF 21.4 (highest quality lossy)
  • PSD 25.8
  • TIFF 26.2
  • BMP 26.2
  • Photoshop 2.0 26.2
  • Photoshop Raw 26.2
  • PDF 39.6 (no compression)
  • Photoshop EPS 44.3

It looks like JP2 lossless is the best if you want the smallest file size and lossless compression. PNG isn't much bigger and might be more compatible. PSD, TIFF, BMP, Photoshop 2.0 and Raw are about the same in file size, so I guess it depends which has the features you need, like PSD which supports layers and stuff, and whether there is a compatibility issue. PDF, of course, is not the way to go when you want a small file size, losslessly or otherwise, and neither is EPS.

I'm suprised that the JP2 lossless is so small, less than double (the comparison might be screwed up since it was saved as a regular JPG first, though) and it is even less of a step up from the highest quality lossy JP2. If it becomes widely supported, perhaps it would be better just to use JP2 lossless as the format for the final image, rather than the highest lossy setting. JP2 lossless or RAW could be used in the camera and PSD could be used while editing, if necessary. -- Kjkolb 20:50, 3 July 2006 (UTC)

For the home editor using a basic tool PNG is ideal, pros may find its limited color depth support and lack of things like layers an issue though. Plugwash 21:13, 3 July 2006 (UTC)

Color depth

The chart at PNG#Color depth makes it seem like PNG is limited to 16 bits per pixel, but PNG#Technical comparison with GIF says, "PNG gives a much wider range of color depths than GIF (truecolor up to 48-bit compared to 256-color), allowing for greater color precision, smoother fades, etc." Is this an error or is it talking about different things? Also, in the post above, Plugwash says that PNG has limited color depth support. Is the lack of support in the PNG format itself or is it in programs that create PNGs? What color depth are PNGs limited to, due to the format and/or application support? -- Kjkolb 08:00, 11 July 2006 (UTC)

PNG is limited to 16 bits per channel, as the table at PNG#Color depth says. But there can be as many as 4 channels (red, green, blue and alpha) with 16 bits each, which gives 64 bits per pixel. --Zundark 08:32, 11 July 2006 (UTC)
The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was no move. -- tariqabjotu (joturner) 01:29, 11 August 2006 (UTC)

move PNG to Portable Network Graphics

PNG should be moved to Portable Network Graphics as PNG is an abbreviation which can refer to other things such as Papua New Guinea most notably. Although its quite an insignificant country, the PNG abbreviation is still attributed to it. Anyhow, the article should be titled with its full name rather than its abbreviation. -- Zondor 06:20, 5 August 2006 (UTC)

  • Support due to association with Papua New Guinea ("Many acronyms are used for several things; naming an article with the full name helps to avoid clashes," see WP:NCA). Dekimasu 10:41, 6 August 2006 (UTC)
    • From WP:NCA: "Avoid the use of acronyms in page naming unless the term you are naming is almost exclusively known only by its acronyms and is widely known and used in that form (NASA, SETI, and radar are good examples)." The format is almost exclusively known as PNG, he country is almost exclusively known by it's name. --LorianTC 11:09, 6 August 2006 (UTC)
  • Oppose. PNG is the primary name of the image format (indeed, the expanded form was a back formation), whereas it isn't that of the country. And the article has a "for other uses of PNG" link at the top. The SVG example above is interesting; I'd counter by saying that I see it spelled out far more than PNG ever is, presumably because its full name is a useful descriptor, with it being important that it's "scalable" and "vector". "Portable" and "network" is not a very useful descriptor in practice... --KJBracey 14:28, 7 August 2006 (UTC)
  • Oppose. See GIF, JPEG, APNG, MNG, PCX, XBM, XPM (image format), XCF, etc etc. In fact, Scalable Vector Graphics and Windows bitmap should be moved to SVG and BMP (image format), respectively. - Sikon 15:25, 7 August 2006 (UTC)

I think we can peobably finish this vote now with no page move... --LorianTC 16:15, 7 August 2006 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

PNGs not loading in IE 4 or 5

How about the problem with PNGs not loading in IE 4 or 5, despite the alleged basic support? This is not about the transparency issue but getting them to load at all. Is there any information on this? I have searched the Net and have not found information anywhere. Surely there must be a plugin or workaround to fix this. Stovetopcookies 18:10, 24 August 2006 (UTC)

  • It is because Microsoft think they are the greatest and they don't care about properly implementing or implementing at all some standards. Take CSS for exemple: pages that were passing W3C validation for (X)HTML, and CSS were showing perfectly in Opera, and Mozilla Firefox were a disaster in IE version < 7. SOMNIVM 08:26, 26 February 2007 (UTC)

Still unanswered

9 times out of 10, if someone searches for this topic and winds up here, they need to know basic information. The info here now is super thorough, complex, and way over our heads! The folks putting this together failed in that they never told what a png file is and how to use it. Way too technical - I still don't know how to print, view, or imbed on my website! Can & should I convert it to a more standard file extension? —Preceding unsigned comment added by Genihanna (talk • contribs)

The intro pretty clearly states what png is and why it was created
"PNG (Portable Network Graphics) is a bitmap image format that employs lossless data compression. PNG was created to both improve upon and replace the GIF format with an image file format that does not require a patent license to use."
If those words don't mean anything to you then i'd suggest reading the linked articles as you will not be able to understand the differences between image formats without a grasp of them.
As to your other questions you have to realise that wikipedia is not a howto guide. It is not our purpose to go telling users how to use specific applications to perform specific tasks on files. Any decent image editor will support loading and saving png files. There is nothing special about embedding a png in a web page it is just the same as any other image format. Plugwash 00:04, 21 October 2006 (UTC)

Color Question - LAB/RGB/ 8/16 bit

Hey, I realize that this is not exactly the forum for this question, but I am looking for a relatively obscure answer that no one has been able to help me with so far. I'm trying to make stimulus for a psych experiment using CIE space, so I made it in photoshop with LAB color, a CIE space, but I can't save it as anything but a Tiff which most other applications won't load. I can save it as an 8-bit LAB color tiff, which will sort-of load, or a 16-bit RGB color .PNG file, which will load. The problem is that the two look very different, and I dont know which is closer to the true 16-bit LAB color. Any ideas? thanks and sorry for posting a somewhat irrelevant question here. Oh, to clarify, The program I am using (SuperLAB 4.0) only supports .bmp,.png,.tif, and .jpg. Photoshop does .tif just fine, but it looks like SuperLAB, along with most other programs, can't handle LAB color in 16 bits. The Image quality doesn't matter much, its a simple line drawing, but the color is super-important. I need LAB Cyan to look as close as possible to what it really is, so is 8 bit LAB (tiff) closer than 16 bit RGB (ping)? I also have the option of an 8 bit RBG jpeg, but im guessing thats a joke. Thanks again

i'd imagine 8 bit per channel lab color would be more likely to be indistinguishable than 16 bit "RGB" but i'm no expert. Plugwash 23:44, 20 October 2006 (UTC)

Interlacing

"However, as a 7-pass scheme, it tends to reduce the data's compressibility more than simpler schemes." Is this accurate? Based on the context, this seems to be saying the opposite. Is this an unintentional double-negative? ("reducing compressability" would mean it can't be compressed as well) BeboGuitar 00:49, 11 November 2006 (UTC)

It is true that adding Adam7 interlacing to a PNG will increase its file size in most cases. I've never seen Adam7 interlacing decrease the file size of a PNG. It also seems to take longer to save PNGs using Adam7 interlacing than without. The interlacing feature in GIFs doesn't increase the file size nearly as much as the interlacing feature in PNGs, and in some cases interlacing doesn't increase the file size at all in GIFs. Jecowa 12:36, 11 November 2006 (UTC)
interlacing is a compromise, you send the raw image data in a different order which allows a low res version to be constructed quickly but in doing so you reduce the compressibility of the data. Generally the more passes you have the bigger the affect on compressibility. Its a balance, is having low res information availible to the user quickly more important than the overall download time and if so how low res is low res, png decided on a 7 pass system proposed by a mailing list member at the time which was iirc based on some rough tests with imagemaps. Now we are stuck with that scheme. Plugwash 17:57, 12 November 2006 (UTC)
But there's no point optimising an interlace system for low file size. You already have a low file size choice - don't interlace. If you want to interlace, it makes sense to choose an interlace system that gets something recognisable up quickly. And the PNG scheme is very good at that; much, much better than GIF by an order of magnitude. And the extra file size cost isn't much. --KJBracey 21:09, 12 November 2006 (UTC)

Merging the libpng article

(I guess no one has discussed it yet as per discussion request.) Rather than have a stub article for libpng, I agree with merging the libpng article into this one. 2*6 02:42, 6 January 2007 (UTC)

If no comments in next couple of days, I'll go ahead and merge. 2*6 12:35, 12 January 2007 (UTC)
Without any concurrence from anyone, I decided I'm not comfortable doing the merger, although I still think it is good idea. I noticed as I started merging that zlib has its own article, which is what made me hesitate now. – 2*6 13:20, 16 January 2007 (UTC)

Oppose The article is about the PNG image format. libpng is just one implementation of a library supporting PNG - it is not an fundamental part of PNG itself. Also having libpng in a separate article allows it to be covered in more detail. –GrahamStw 18:18, 17 January 2007 (UTC)

Oppose. (No way, Jose). Isn't the article "PNG" complex enough, without adding "libpng" details? Can you imagine checking a larger tech article for anti-PNG vandalism? No, don't merge, but consider duplicating the verified information into many other articles to avoid the impact of technical vandalism, then just link them with "see-also" to give the readers a chance to notice vandalism that doesn't jive between the articles. I'm not illustrating such vandalism, but just imagine slight changes, and that's what other tech articles have faced. Clever people can repair technical articles by comparing duplicated writings. Oppose. Oppose. Oppose. Duplicate. Duplicate. -Wikid77 22:15, 21 January 2007 (UTC)

Oppose. Although related, libpng is another subject. Why don't we put cucumber in water as 98% of the cucumber is water? SOMNIVM 08:47, 26 February 2007 (UTC)

Oppose. It's good to have one article about PNG for non-programmers and another for programmers. BTW, GrahamStw makes a very good point about libpng not being the only decoder around: by a nice coincidence, I just downloaded this one. CWC 20:05, 27 March 2007 (UTC)

Oppose. It doesn't really belong here, and it deserves its own article anyway. (And isn't it time this poll was closed?) --Zundark 15:20, 29 March 2007 (UTC)

Well, that's 5 saying "Oppose" (6 if you count User:Dozen's comment from 16 January 2007) to 0 who support. So I've WP:BOLDly closed the poll and removed the merge tags. Cheers, CWC 17:19, 29 March 2007 (UTC)

Added 3 greyscale images

I added 3 greyscale images to the "Color depth" section. I'm not sure it is the best spot for them. Also, if others feel they are not useful, I would not object to them being removed from the article. 2*6 12:35, 12 January 2007 (UTC)

PDF image to lowest-kilobyte PNG for wikipedia, wikimedia

Can someone provide some links at the bottom of the article page that explains how to copy the many charts, graphs, etc. found in PDF files to lowest-kilobyte PNG files for use in wikipedia and wikimedia?

Currently I copy a PDF image and paste it into the freeware called IrfanView.

IrfanView 3.99 now has PNGOUT. But I can't find any simple non-technical (I REPEAT!!! NON-TECHNICAL) help anywhere for PNGOUT in IrfanView in order to get the smallest-kilobyte high-quality PNG.

IrfanView is an immensely-popular image viewer, editor, converter. Because it is SIMPLE to use. And incredibly easy to install. Both the main program and the combined plugin file. Some simple instructions for using Irfanview to create PNG image files could help wikimedia in a serious way to get more low-kilobyte png images uploaded. When I paste an image directly from a PDF file to IrfanView I can then convert it to any number of image formats.

I used IrfanView to convert a PDF image to a gif image. The PDF image came from this U.S. Bureau of Justice Statistics PDF from the federal government (thus it is public domain):

I uploaded the 20-kilobyte gif image to here:

It is used in this wikipedia page:

I can't get anything less than a 37-kilobyte png image for that 479-pixel-wide image. I tried all the different compression levels in the first level of PNG options. I haven't tried the other PNGOUT options, because they are complex and bewildering.

I have read there can be low-kilobyte png images of the same quality as gif files, but have seen no proof. I would like to see a 20 kilobyte version of the above-mentioned image at 479 pixels wide.

So if someone could install IrfanView and figure this out for me, I will pass the instructions around wikipedia and wikimedia. --Timeshifter 09:26, 15 January 2007 (UTC)

Timeshifter, I like IrfanView also. I have v3.70. When I read in the GIF and write it back out as PNG, it shrinks from 20,296 butes to 15,859 bytes. The only way I can end up with a larger PNG than GIF is if I convert the 256-color GIF to a 16-million color PNG. In that case, IrfanView writes out a 29,877 byte image. My version doesn't have a special PNGOUT feature, PNG is simply one of numerous formats it uses, both for reading and writing.
Let me note that IrfanView sometimes does not produce size-optimized PNG images. When minimum file size is really important, run IrfanView's output image thru pngcrush. In this particular case, pngcrush only saved 300 bytes, though.
Proof that PNG is better than GIF? -- USA_Prisoners_1995_to_2005.png (feel free to use :) – 2*6 11:43, 15 January 2007 (UTC)
If you would like me to upload this to Wiki myself, I will. Since you weren't asking for help with the article, just the image, I chose not to upload it then edit the article with new image. Also, I mean no offense by putting it in a "Junk" directory at my site -- that is simply a place I can put stuff and delete later without bothering to check what I'm deleting. – 2*6 12:07, 15 January 2007 (UTC)
(edit conflict) I suspect that your PNGs are 24-bit (though you didn't post an example, so this is just a guess). Try converting the GIF to PNG - this should give you an 8-bit PNG, and it should be smaller than the GIF (and exactly the same quality). --Zundark 13:24, 15 January 2007 (UTC)
Thank you both for the info and effort. Hold off, 2*6, on the upload though on the png image. I may upload a larger size image if the png thumbnail problem has been fixed. Has the problem with png thumbnail images been fixed yet? I picked the current size so that if it was ever converted to png it could be used full-size and fit in wikipedia articles OK with text flowing around the image. But if I uploaded a larger size, and used thumbnails in the article, then that could be a problem with png images. Because the thumbnails can end up using many more kilobytes paradoxically. Something to do with thumbnail compression by wikipedia using too many colors?
I was wondering if you could install the latest version of IrfanView and the plugin packet, and then try converting directly from the Table 1 image in the PDF file. I set the PDF file to 86.9% size in Adobe reader. That creates a 479-pixel-wide image. Copy and paste into IrfanView. Save as PNG until you see the advanced PNGOUT options. There I seem to be able to get a 15 KB image by selecting "palette" or "gray". I could really use another set of eyes on those PNGOUT options. I turned off compression while using the palette or gray option. I figure it is best to convert directly from pdf to png, rather than from pdf to gif to png. Am I correct? I assume IrfanView uses 24-bit unless I pick palette or gray. I want to write this out for complete newbies, so if we are all seeing the same version of IrfanView that would help a lot.
I have read that PNG is better than GIF, and I will take other people's word for that. But this wikipedia png thumbnail compression problem negates those benefits in my opinion. Gif images seem to compress fine for wikipedia thumbnails. I only got broadband a few months ago. I had dialup before that. Most people are still using dialup and for them a high-kilobyte png thumbnail image really slows down page loading. I think wikimedia should reconsider its ban (?) on gif uploading. I believe wikipedia still allows gif uploading. I must have gotten the gif image to wikimedia before the ban. Is it possible to upload both a thumbnail and full-size version of a png image to wikimedia or wikipedia, and then have the article set up to load the small-kilobyte thumbnail, and then be clickable to pull up the full-size version of the image? I want to put this info in a how-to page also. --Timeshifter 14:39, 15 January 2007 (UTC)
Ok, in the next couple days I'll install the latest IrfanView and test from the source PDF. I'm guessing that the image within the PDF is probably a full-color JPEG image (24 bits per pixel). Since GIF only supports a maximum of 8 bits, it was automatically compressed. Since PNG supports 24, you have to select palette or gray to to output an 8-bit image. I'm not sure what the "PNG thumbnail" issue is. I know for very large images (greater than around 3500 pixels square), Wiki won't make a thumbnail, but there aren't a lot of images that big on the web. My Wikimedia Commons Gallery contains such an image, though. :) I don't believe it is possible yet to have a smaller pre-compressed thumbnail permanently assigned to a large image (at least, I don't know how if it is possible). – 2*6 16:24, 15 January 2007 (UTC)
Thanks. There is more info on the PNG autoscaler thumbnailer problem here:
Wikipedia talk:Preparing images for upload - See the PNG sections.
I use "zoom to" from the view menu to put in 86.9% for the document size. Then I use the the snapshot tool from the tools menu in Adobe Reader to select the Table 1 image. In the latest version of Adobe Reader just selecting something automatically puts it in the clipboard. Then I paste it into Irfanview with the paste command from its edit menu. The PNG autoscaler paradoxically creates higher-kilobyte thumbnails and midsize png images for use on wikipedia pages. Many more kilobytes than the original png image in many cases. So I will probably reload the Table 1 image at the same size since it will not need to be scaled down for use on the wikipedia page. Text will still flow around it. --Timeshifter 04:41, 16 January 2007 (UTC)
I downloaded and installed IrfanView 3.99 and new plugins. However I am unable to open the original PDF. Apparantly I would need to install GhostScript also, which I haven't needed before. Regarding PNG thumbnails, if the wiki software insists on turning every PNG into a 24-bit version, even if it starts out at 8 or 2 bits/pixel, there isn't much we can do. Hopefully they'll fix the thumbnail maker so as to preserve original uploaded depth. It's hard for me to imagine as a programmer why they wrote it they way they did. -- —The preceding unsigned comment was added by Dozen (talk • contribs) 00:21, 17 January 2007 (UTC)
I use Adobe Reader to view the PDF. Is GhostScript a way to view a PDF file within IrfanView? --Timeshifter 09:12, 17 January 2007 (UTC)

I think that if you use an 8-colour or even 4-colour PNG, you will get an even smaller file size. However, a better idea would be to convert that image to an SVG image because it only contains text and lines. SVG will give you the smallest filesize because you can just embed text within SVG images, and there sure won't be 20 KB of text in that image. Inkscape is a capable SVG editor, but it doesn't win in the looks department.--IE 12:59, 16 January 2007 (UTC)

Hmm. SVG. Does it have the autoscaler problem at wikipedia for thumbs and midsize versions of the image? I thought SVG was for some kind of scalable graphics? I did not know it could be used with text. Could you create an SVG version and tell me if it is as sharp as the PNG or GIF versions. How many kilobytes, too. IrfanView does not convert to SVG. --Timeshifter 13:22, 16 January 2007 (UTC)
SVG. Does it have the autoscaler problem at wikipedia for thumbs and midsize versions of the image?
Unfortunately, yes I think so. The Wikimedia servers render SVG images to 24-bit PNGs - probably because most browsers don't support natively viewing the SVG type at the moment. If your browser natively supports SVG (Firefox and Camino do, and Safari development version), then you can click on the SVG image in an article, then click on the link to the actual SVG file, then your browser will display the SVG (otherwise it will just download the SVG file). --IE 16:33, 16 January 2007 (UTC)
I have MSIE 7 installed along with Firefox 2. Can MSIE 7 show SVG images? Earlier you mentioned text in SVG images. I am assuming you mean that one would have to type in the text. Not just use and convert a gif or png image with text? --Timeshifter 09:15, 17 January 2007 (UTC)
I am seeing SVG images in Firefox 2, but not in MSIE 7. This page for example: http://en.wikipedia.org/wiki/Scalable_Vector_Graphics - I was fooled at first by the png images substituted by wikipedia on the article page and on the image page. --Timeshifter 18:39, 17 January 2007 (UTC)
To be honest, I think you're going about this the wrong way. Whatever the size of the SVG, you don't really need to worry about it that much IMHO. You should just choose the best format for your image, in this case it is SVG and use it. Let the software handle stuff as it should and if there is a problem, bug the devs about it. BTW, there is no such thing as a 479 pixel SVG since SVG doesn't have pixels 203.109.240.93 11:54, 27 January 2007 (UTC)
In Firefox when I right-click an SVG image and look at its properties I see pixels for height and width.
I don't know if the table can be made into an SVG image because I don't know how the text is incorporated in the table in the PDF file. How does PDF store such a table? Is it an image? Is it text converted into an image by PDF readers? Table 1 is the one being discussed from this PDF file: http://www.ojp.usdoj.gov/bjs/pub/pdf/pjim05.pdf
Can anybody create an SVG image directly from Table 1 in the PDF file? --Timeshifter 23:34, 27 January 2007 (UTC)

Converting to PNG

Would anyone be able to transfer [[Image:WPFSlogo.jpg]] to a PNG with a transparent background? I guess I don't have the skill. --Daysleeper47 20:16, 31 January 2007 (UTC)

It has a transparent background in commons:Image:WPFSlogo.png. The JPEG is compressed and has artifacts. Would you be able to get a lossless (not a JPEG) version of this image? It would make the image higher in quality. Jecowa 20:54, 31 January 2007 (UTC)
I did not create it. Bobanny created it but wasn't sure how to make it transparent. He created it as jpg. I will chat with him and see what he can do. Thanks for the help Jecowa. --Daysleeper47 21:44, 31 January 2007 (UTC)
Also, how do I reconcile the fact that I created an image with the same name only on en.wiki which is different from the one which Bobanny created? When I apply the image to articles, the en.wiki image appears, not the Commons image. --Daysleeper47 21:53, 31 January 2007 (UTC)

Redirect

PNG redirect should be to the country. Sad mouse 04:07, 12 March 2007 (UTC)

Don't be silly. Nobody would say he went to pee-en-jee for the holidays. Shinobu 19:08, 26 August 2007 (UTC)

PNGs and thumbnails?

On other Wikis, I have tried to make thumbnails of some PNG-files, but it doesn't work very well. Unlike gif or jpg, for some reason the png's color depth gets decreased to just nuances of a particular color, i.e. if the background is green, the whole image turns into shades of green. Why does this happen, and is it some way one could get around it? 惑乱 分からん * \)/ (\ (< \) (2 /) /)/ * 15:44, 28 May 2007 (UTC)

23-Aug-2007: Some versions of some browsers have trouble displaying PNG files (but not GIF or JPEG). See alpha/gamma color problems displaying PNG in IE7 (above): Internet Explorer 7. For Wiki (as of 2006 to August 2007), the Wiki thumbnail resizing software still displays GIF files 3x times faster than PNG (and JPEG 5x to 21x times faster than PNG). Even though PNG files store as slightly (5%-25%) smaller than GIF, the PNG files expand to a whopping 3x times the size of the tiny GIF thumbnails, clogging the transfer of Wikipedia or Wikimedia Commons PNG thumbnails. The Wiki problem is typically massive PNG-thumbnail gigantism: some PNG thumbnails have displayed 21x (twenty-one) times (painfully) slower than same-size JPEG images. I've been waiting since mid-2006 for the Wiki-PNGs to thumbnail faster, but the Wiki software is not improving that fast. Those bizarre Wiki-PNG thumbnails are much (often 8x times) larger than the original PNG stored image. People who don't study Wiki performance have been shocked at the massive Wiki-PNG thumbnails, perhaps because equivalent GIFs & JPEGs were deleted when auto-converted to PNG, and the deleted original GIF/JPEGs were no longer there for comparisons. Also, some people who convert to PNG have been censoring Wiki information about slow PNG performance & blurry results. -Wikid77 07:05, 23 August 2007 (UTC)
That rant didn't answer his question, nor was it anywhere as convincing as a good full writeup somewhere. I guess when the Illuminati are actively censoring you, though...--Prosfilaes 10:32, 23 August 2007 (UTC)
Archive 1
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:PNG/Archive_1&oldid=1137066275"