From owner-png-list@dworkin.wustl.edu Wed Oct 1 03:19:38 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id DAA20583 for ; Wed, 1 Oct 1997 03:19:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id DAA17217 for png-list-outgoing; Wed, 1 Oct 1997 03:09:28 -0500 Received: from jabba.ivab.se (jabba.ivab.se [193.180.173.30]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id DAA17212 for ; Wed, 1 Oct 1997 03:09:20 -0500 Received: from arnold.image.ivab.se (arnold.image.ivab.se [193.180.173.119]) by jabba.ivab.se (8.8.5/8.8.5) with SMTP id KAA31503 for ; Wed, 1 Oct 1997 10:04:52 +0200 (MET DST) Received: from fl-pc.image.ivab.se by arnold.image.ivab.se; (5.65v3.2/1.1.8.2/16Nov95-0104AM) id AA28240; Wed, 1 Oct 1997 10:04:37 +0200 Message-Id: <9710010804.AA28240@arnold.image.ivab.se> From: "Fredrik Lundh" To: "PNG List" Subject: Re: PNG and JPEG-LS Date: Wed, 1 Oct 1997 10:05:50 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1008.3 X-Mimeole: Produced By Microsoft MimeOLE Engine V4.71.1008.3 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn wrote: >Also, we must restrict ourselves to lossless methods. Why's that? If the PNG framework is so good so you want to use it with more compression methods, why not add at least baseline JPEG, G4, and uncompressed storage too, so it can be used for most main- stream purposes? IMHO, the moment you add one more compression method to PNG, you break its most important feature; namely that there is only one PNG version; all decoders are able to handle all PNG files (1). Giving up that with the argument "but it's still lossless" sounds a little odd in my ears, really. Let's keep PNG exactly as it is, please! Cheers /F 1) ok, applications are pretty likely to mess up on things like gamma and transparency, but that's really a different issue. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Oct 1 10:37:05 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id KAA26920 for ; Wed, 1 Oct 1997 10:37:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA23077 for png-list-outgoing; Wed, 1 Oct 1997 10:17:36 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA23071 for ; Wed, 1 Oct 1997 10:17:32 -0500 Received: by NetGSI.com (8.7.5/-A/UX-AMR-1.0) id LAA22991; Wed, 1 Oct 1997 11:12:50 -0400 Message-Id: <1.5.4.32.19971001151120.006941c4@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Oct 1997 11:11:20 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG and JPEG-LS Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:05 AM 10/1/97 +0100, you wrote: >Glenn wrote: >>Also, we must restrict ourselves to lossless methods. > >Why's that? If the PNG framework is so good so you want to use it >with more compression methods, why not add at least baseline JPEG, >G4, and uncompressed storage too, so it can be used for most main- >stream purposes? Because we don't want any confusion about the promise that PNG is lossless. If we include JPEG as a compression method, someone down the line is going to save their original artwork, medical image, or whatnot, with a lossy compression method, and then come whining to us that their original image can't be recovered. I was in favor of uncompressed storage, too, but [rightfully] lost that argument. It's been pointed out that you can get that anyway by setting the zlib/deflate flags. You can also get it if you want by using a private compression_method that just copies the raw data, but we don't want to put such a method in the spec because again, naive users would put uncompressed images on the web and blame us for the resulting huge file sizes. > >IMHO, the moment you add one more compression method to PNG, >you break its most important feature; namely that there is only one > PNG version; all decoders are able to handle all PNG files (1). Yes. >Giving >up that with the argument "but it's still lossless" sounds a little odd >in my ears, really. As Lee, Adam and tom have said, we'd only be interested if there were an enormous advantage to be gained. As I said, it's OK to experiment and find out if there is an enormous advantage. 20-30 percent savings in file size isn't enormous. 90 percent would be interesting. So would the various schemes in comp.compression that reduce images down to one or two bytes, if they weren't scams. > >Let's keep PNG exactly as it is, please! I happen to like it a lot the way it is. Making changes to make it incrementally better won't convince anyone to move from what they consider to be a more stable image format. > >Cheers /F > >1) ok, applications are pretty likely to mess up on things like gamma >and transparency, but that's really a different issue. > > >-- >Send the message body "help" to png-list-request@dworkin.wustl.edu > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 2 07:50:22 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id HAA21879 for ; Thu, 2 Oct 1997 07:50:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA07639 for png-list-outgoing; Thu, 2 Oct 1997 07:36:24 -0500 Received: from kukulkan.fri.uni-lj.si (kukulkan.fri.uni-lj.si [193.2.73.131]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA07633 for ; Thu, 2 Oct 1997 07:36:12 -0500 Received: (from aleksj@localhost) by kukulkan.fri.uni-lj.si (8.7.3/8.7.3) id NAA00823 for png-list@dworkin.wustl.edu; Thu, 2 Oct 1997 13:31:24 +0100 (MET) From: Alex Jakulin Message-Id: <199710021231.NAA00823@kukulkan.fri.uni-lj.si> Subject: Re: PNG and JPEG-LS To: png-list@dworkin.wustl.edu Date: Thu, 2 Oct 97 13:31:24 MET In-Reply-To: <199710012105.OAA29523@jupiter.colossus.net>; from "Lee Daniel Crocker" at Oct 1, 97 2:02 pm Mailer: Elm [revision: 70.85] Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Let me first explain that integration of JPEG-LS is merely a possibility which is to be thought about. For example, JPEG-LS is even not cast to iron yet. That's why it makes sense to explore the possibility now (or decide that it is not worth bothering at all), as JPEG-LS could itself be altered in order to simplify integration into frameworks like PNG. As a coauthor, it is definitely not my interest to break it or ruin its reputation. That's why any updates must not to be performed before PNG is better established than it is now. This can well take two or more years. This will also require positive feedback from W3 and IETF. Certain mission critical applications would consider an ISO standard preferable to an open standard. For example US military is considering using JPEG-LS and same might well be true for several more applications. The wrapper (or image protocol) is less mission critical, but does the world really need both SPIFF and PNG? Again, updating PNG is a long-term transition. Releasing the decoders a year or more before the encoders is a concrete attempt of solving some problems involved with it. Lee wrote: > Actually, I was a bit mistaken: it's better in compression speed as > well, but I don't think that matters to a communication standard. The > important features are fidelity of information, speed of transmission > (which includes both compressed size and speed of decoding), ease of > implementation, and universality. PNG has much higher fidelity of data, > faster decoding, easier implementation, and is more universal. JPEG-LS is significantly simpler, better explained, runs significantly faster at compression, slightly slower at decompression, and almost always yields better compression on smooth images (by 5%-20%) than deflate+adaptive filtering, but it exploits color channel coherency worse than PNG (but still yielding better results). Here we're comparing JPEG-LS with the deflate+adaptive filtering compression method used in PNG which was admittedly an engineering trade-off solution. And yet adaptive filtering+deflate performs better than JPEG-LS in many situations in addition to being more robust (when dealing with granular and noisy images). PNG and JPEG-LS are not the same. I doubt that a widespread standard in the lossless photographic image compression domain outperforming JPEG-LS by more than 5%-10% will emerge in the next 4 years. And JPEG-LS itself is not finished anyway. Yes, JPEG-LS does support 16 bit color channels. Near lossless mode is absolutely nothing more than quantizing the input image, fixing a few parameters (which get stored in the header), and then performing the identical procedure as in the lossless mode. Currently JPEG-LS does not support alpha channels, etc. This could be solved in a rather simple way. > What you propose does not "add" to PNG, it diminishes it. Since > the information that can be encoded in the JPEG-LS chunk the same as > what would have otherwise been encoded in the standard chunk, you > have essentially removed all of the image data from the view of those > who have invested time and efort into developing software to read it. JPEG-LS does not have a higher level wrapper. They currently recommend SPIFF (which has been modified to support JPEG-LS) and if we do something about it, they might also recommend PNG. Yes there is some redundancy involved (a few bytes) if the IDAT stream is to be ISO-compliant, and no, this is not necessarily a bad thing. > Trust me...after a few years, users will kiss our feet for being the > only format they can /rely/ on, precisely because we resited the > temptation to be on the edge, and use the latest of everything. Why > do you think ZIP has taken over the world when ARJ and Yabba outperform > it? Because a ZIP file is a ZIP file, everywhere in the world. Users > won't even notice a 20% size saving; hell, they hardly ever notice a > 50% savings. They certainly will notice "Sorry, I can't read this file." And yet ZIP survived the transition from implode/explode to inflate/deflate. I got more information about the patent restrictions: > > Gadiel, > > > > I got feedback from the rest of the PNG group. The most important > > requirement is a *permanent* license for free use. Is there a document > > which we could refer to? > > The exact "terms and conditions" of the license, as well as the mechanisms > for obtaining it, are still under formulation. But I understand the intent > is to give a permanent, free license for implementations of JPEG-LS. Also, > the mechanism should be very simple (e-mail, internet, or such). > Hopefully, all this will be resolved before the JPEG meeting in Sydney > next month. The only documents that I am aware of are the letters of intent > from HP and Mitsubishi, and the ISO/SC29/WG1 resolutions acknowledging them. > > --Gadiel > > Gadiel Seroussi Email: seroussi@hpl.hp.com > Hewlett Packard Laboratories Phone: (650)857-6343 > 1501 Page Mill Road Fax: (650)852-3791 > Palo Alto, CA 94304 Regards, Alex -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 2 17:07:40 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id RAA09076 for ; Thu, 2 Oct 1997 17:07:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA15802 for png-list-outgoing; Thu, 2 Oct 1997 17:03:00 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA15797; Thu, 2 Oct 1997 17:02:55 -0500 Received: by NetGSI.com (8.7.5/-A/UX-AMR-1.0) id RAA02671; Thu, 2 Oct 1997 17:58:06 -0400 Message-Id: <1.5.4.32.19971002215638.006b1d14@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Oct 1997 17:56:38 -0400 To: png-implement@dworkin.wustl.edu, png-list@dworkin.wustl.edu From: CiEBV@aol.com (by way of Glenn Randers-Pehrson ) Subject: PNG, MNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hallo, we are the developpers of an imaging program Photo Line 32. Here we support the PNG format. But we have problems in saving RGB-pictures with alpha in the PNG format. We use the png library to handle the files. Until now, we did the following: set: info_ptr->color_type = PNG_COLOR_TYPE_RGB_ALPHA; and write: RGBA data But this doesn't work. Can you help us? We think PNG doesn't support CMYK-images, is this correct? Since we support animated GIF's as well, we think we should also support MNG. Is there also a library for MNG? Gerhard Huber [CiEBV@aol.com] You can get Photo Line 32 from: http://members.aol.com/ciebv -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 2 17:19:34 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id RAA09603 for ; Thu, 2 Oct 1997 17:19:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA15935 for png-list-outgoing; Thu, 2 Oct 1997 17:13:08 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA15929 for ; Thu, 2 Oct 1997 17:13:03 -0500 Received: by NetGSI.com (8.7.5/-A/UX-AMR-1.0) id SAA03252; Thu, 2 Oct 1997 18:08:15 -0400 Message-Id: <1.5.4.32.19971002220646.006bbb5c@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Oct 1997 18:06:46 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: Re: PNG, MNG Cc: CiEBV@aol.com Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 11:39 PM 10/1/97 -0400, Gerhard Huber wrote: >Hallo, > >we are the developpers of an imaging program Photo Line 32. [...] >We think PNG doesn't support CMYK-images, is this correct? That is correct, although you could easily extend PNG with a private critical chunk (e.g. CmYK) to do so, if the files are going to remain under your control, and will only be processed with your in-house applications. Be sure not to allow such files to be publicly posted, however, because PNG-compliant viewers will be required to reject them when they encounter the unknown critical chunk. It is highly unlikely that the PNG group would approve a public CMYK chunk. >Since we support animated GIF's as well, we think we should also support MNG. >Is there also a library for MNG? There's no public library for MNG. And, unfortunately, I don't think anyone is working on one. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 3 03:59:46 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id DAA28487 for ; Fri, 3 Oct 1997 03:59:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id DAA22795 for png-list-outgoing; Fri, 3 Oct 1997 03:57:00 -0500 Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id DAA22788 for ; Fri, 3 Oct 1997 03:56:55 -0500 Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id DAA00693 for ; Fri, 3 Oct 1997 03:52:04 -0500 (CDT) Received: from sjx-ca65-14.ix.netcom.com(206.217.121.78) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma000663; Fri Oct 3 03:51:16 1997 Received: by CORUISK with Microsoft Mail id <01BCCF9F.0052D730@CORUISK>; Fri, 3 Oct 1997 01:52:27 -0700 Message-ID: <01BCCF9F.0052D730@CORUISK> From: John Bowler To: "'PNG List'" Subject: RE: PNG and JPEG-LS Date: Fri, 3 Oct 1997 01:52:06 -0700 Encoding: 188 TEXT, 171 UUENCODE X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The HP paper which compares PNG to JPEG-LS (http://www.hpl.hp.com/loco/PNGcomp.pdf) raises some interesting questions. So far as I can see this paper is the basis for the claim, repeated by several people, that JPEG-LS is "about 4 times faster " and compresses "smooth (photographic) images" "about 5%-20% better than deflate." The actual claims made in the paper are "a 3:1 [speed] ratio for the specific implementations tested" and "[better] in compression and significantly [better] in encoding speed for the main types of images targeted". (This latter statement is made without qualification with regard to the implementations they were using, but they don't explicitly suggest elsewhere that the conclusions generalise beyond those implementations). The target images are, from the standard "continuous-tone greyscale, or colour digital still images." Ok, so this is clearly verifiable, at least in principle. I used the ColorSet from the BragZone collection of images - this consists of 5 digitised "real world" images (photographs) and three compositions (they aren't computer generated in the ray tracing sense - they are the kind of thing you might expect from users of programs like Painter.) I compared the HP demo program ("locoe") running in its default settings (which seem to be optimal for both speed and compression in this case) against what is pretty much "example.c" from libpng hacked to read a Win32 BMP file. Those images suggest, with the *default* libpng compression behaviour, times of up to 6x and compressed file sizes up to 10% bigger. *However* the non-photographic images consistently ended up smaller (frymire was 40% of the size of the locoe output). What is more the results between files in terms of both time and (particularly) compression show enormous variation. Locoe achieves between 1.57 and 5.20bps (in this context a sample is one R, G or B value - so an uncompressed file is 8bps - I follow the form in their paper). It achieves between 1.34 and 2.72 microseconds per sample - much less variation but still a factor of 2. If you move from the default settings (adaptive filtering, compression level 6 I believe - they were apparently using a buggy version of pnmtopng) the speed/compression performance changes (no surprise there :-) Taking the apparently extreme approach of using compression level 1 and no filtering causes the compression times to vary from 51%(frymire) to 120%(lena) of the locoe times. Although the compressed sizes are all larger the non-photographic images show relatively little increase. The consistent "bad" thing to do is to remove the adaptive filtering on the photographic images, this seems to consistently cost around 1bit per sample - lena goes up to ~7.5bps (hardly any compression!) With this code I was unable to test the result of forcing a single filter - e.g. Paeth - this may well improve performance without hitting the compression as much. I give a full set of results below. So what is the conclusion? I would expect that comparison of an algorithm designed for a particular class of image against a more general purpose one would give better results on the target images and worse on the others. I was somewhat surprised to find that JPEG-LS cannot cope with the non-photographic images as well as PNG, but maybe I misunderstand the intent of the description in the standard. I think their point is proved - JPEG-LS is better for photographs - but people need to bear in mind that qualification. On the matter of speed the conclusion is much less clear. Anyone reading the paper will understand that it was testing a particular implementation, but it needs to be stressed just how big an effect this can have. Certainly the tables below show that Zlib compression level and adaptive filtering have an enormous effect on execution time (32:1 for clegg) and a much smaller effect on compression (0.92:1 in the same case, 1.6:1 in the worst case of turning off filtering on peppers). Someone who cares about speed would not use compression level 6 (except by accident :-) It is difficult to see how any meaningful statement about speed can be made. JPEG-LS is not faster than PNG/deflate at the same "compression level" for these photographic images - because PNG does not achieve that compression level! Likewise for images at which PNG is better than JPEG-LS it is possible to run *this implementation* of PNG faster than *this implementation* of JPEG-LS and still get better compression. Statements about speed must be qualified in the same ways as those about compression. John Bowler The following data was gathering on a 120MHz Pentium with 128MByte of main memory and 512k of second level cache. The system was running NT4.0 USSP3+IE4.0. Commands were run from the command prompt. Internal timing was used, the method used by locoe is unknown, that used by the PNG test program was GetProcessTimes - user and kernel times were combined. locoe was "Compiled Jul 28 1997 16:42:00" output was always line interleaved. Sample interleaved processing seemed to produce results which were maybe 20% bigger and took maybe 20% longer (PNG is always sample interleaved.) libpng version was 0.88 (! an accident, however I don't think the adaptive filtering has been changed significantly - someone might want to retest...) All commands were run at least 4 times each, although the standard deviation is not in the tables below it did not exceed a couple of percent of the values. *NOTE* that the pairs of columns contain the bps figure first then the time figure. In each level: bits-per-sample time-per-sample (in microseconds) The bps figures *include* file format overhead - they are simply file size divided by number of samples. Adaptive filtering name size LOCO level 1 level 3 level 6 level 9 monarch 1179648 3.76 2.44 122% 143% 118% 218% 111% 638% 111% 903% lena 786432 4.53 2.49 117% 151% 117% 177% 106% 291% 106% 287% tulips 1179648 4.18 2.50 119% 154% 117% 212% 110% 493% 110% 580% sail 1179648 5.20 2.72 103% 145% 103% 183% 105% 325% 105% 332% serrano 1498278 1.57 1.25 66% 156% 60% 172% 54% 259% 52% 1622% clegg 2148960 2.43 2.07 83% 107% 80% 139% 76% 391% 75% 2670% frymire 3706170 2.02 1.34 51% 144% 46% 156% 41% 233% 40% 1480% peppers 786432 3.92 2.44 122% 156% 120% 221% 110% 550% 110% 585% No filtering name size LOCO level 1 level 3 level 6 level 9 monarch 1179648 3.76 2.44 155% 101% 152% 113% 153% 134% 152% 133% lena 786432 4.53 2.49 161% 120% 161% 122% 165% 134% 165% 131% tulips 1179648 4.18 2.50 160% 113% 160% 117% 163% 134% 163% 132% sail 1179648 5.20 2.72 120% 104% 119% 113% 124% 135% 124% 135% serrano 1498278 1.57 1.25 56% 56% 48% 67% 37% 139% 36% 371% clegg 2148960 2.43 2.07 81% 57% 81% 66% 79% 94% 79% 101% frymire 3706170 2.02 1.34 43% 51% 37% 59% 28% 121% 26% 764% peppers 786432 3.92 2.44 173% 114% 173% 120% 176% 135% 176% 137% The same results in bpp and microseconds throughout: Adaptive filtering name size LOCO level 1 level 3 level 6 level 9 monarch 1179648 3.76 2.44 4.62 3.50 4.48 5.33 4.20 15.59 4.18 22.06 lena 786432 4.53 2.49 5.34 3.78 5.32 4.42 4.84 7.26 4.84 7.16 tulips 1179648 4.18 2.50 5.01 3.85 4.92 5.29 4.63 12.31 4.62 14.48 sail 1179648 5.20 2.72 5.40 3.96 5.38 4.98 5.49 8.85 5.49 9.06 serrano 1498278 1.57 1.25 1.03 1.95 0.95 2.14 0.85 3.24 0.82 20.22 clegg 2148960 2.43 2.07 2.03 2.22 1.97 2.89 1.85 8.13 1.84 55.41 frymire 3706170 2.02 1.34 1.04 1.93 0.95 2.10 0.84 3.13 0.82 19.85 peppers 786432 3.92 2.44 4.80 3.82 4.71 5.40 4.35 13.41 4.35 14.27 No filtering name size LOCO level 1 level 3 level 6 level 9 monarch 1179648 3.76 2.44 5.85 2.47 5.72 2.76 5.76 3.28 5.76 3.26 lena 786432 4.53 2.49 7.32 3.01 7.31 3.06 7.49 3.35 7.49 3.29 tulips 1179648 4.18 2.50 6.73 2.83 6.69 2.93 6.84 3.35 6.84 3.30 sail 1179648 5.20 2.72 6.29 2.83 6.24 3.10 6.48 3.68 6.48 3.68 serrano 1498278 1.57 1.25 0.88 0.71 0.76 0.84 0.58 1.74 0.57 4.62 clegg 2148960 2.43 2.07 1.99 1.20 1.98 1.38 1.93 1.96 1.93 2.10 frymire 3706170 2.02 1.34 0.88 0.68 0.75 0.80 0.58 1.63 0.54 10.25 peppers 786432 3.92 2.44 6.81 2.80 6.78 2.93 6.91 3.31 6.91 3.35 begin 600 WINMAIL.DAT M>)\^(AP(`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$ MD 8`D $```$````0`````P``, ,````+``\.``````(!_P\!````00`````` M``"!*Q^DOJ,0&9UN`-T!#U0"`````%!.1R!,:7-T`%--5% `<&YG+6QI``,P M`0```!L```!P;F# $````%````4TU44 `````>`!\,`0```! ```!J8F]W;&5R0&%C;2YO ME2 Q'SWG%$ @3R%5>7(5Y!S $8ZO'N 6,2.O`X)' M"=%K)27?%C$ESAI1)O\#@E0(<"4ELQI1)*C8QA"NXWR Q-5TM M=S&$+PLY&F\@%O<.D!WI(:!_V04#\!Q'W(O:W,.4&OO=-_;=>]OO#,"@A,08VD@?=%/9]\/WU/;X(`@, %$ (P+8%@`V$Z MA2WP;XFP4W5B:@60@G2)L$1A=&4Z:.3_+8&"3X-?A&^%?&2P<#,.(;]]T6RV M#E"&WX?OB/92:X'Y%P$@2' A!)!HY!\!BX]_C)^-KVK_CN\/@9J "-!B^0JP M=#A[G@^0>'"1CY*6YYL0DZ +4'DO@7"-\ L1_905P8G2B72*J3V ]V4OHZ2:PSFC[Z3_DH>JP/!$;V-U!X ", 70@3"_ M?P:B]'_E"B"L6'^!4Z. _0(@9TSS$Q"8@&1@`9%DD.<``+%RL61E;0M1BL"I M$(@Q,S1 @#-&8@-^]$K9 L74,P;T1(+L"L8'T M;F$'@""\,;%RLS$ZD+ Y.3,Q.H&Q&&^3P7]GP1<@L-%BQK&^;F3 3>#0 M!(!DO< @$O/S`( %D&QVU1D MP)004,X@"K#($ 7 =V@-X(%0#P6@LM *P >14$Y'( '!,"!*4$5'+4P%!? H M^Z!T<#HO+[)W`) N: M0`,$N_I$V+PD`!: O_R'^DBYP\&1F*2" \ 0`!Y'- M,-^_08DATS&_P7!A<0I0O\'Q$.!S+B &`/]P@'!,,'E]<"!)_H A@1-P$X!T M__Y `O#]U 9!!B 3@'UA!D'/QR$&\[W "W!M+ *0>2#G<""*P&?@8GD%T9/! M,;']R!!OM&$(< 8@BK#_AP9!SB(>H+X@F%$@-/]0%0/_!1!D8!JP'J +0 5 MN5#^@W?^X0+2"U%S&H#*\(%0*/N!0,KP;X$3S: "@+1 @0`W_O >H SP(@N$ M'J U)?HMF[ E#,&[L+*A!\(A@4/3L<$80>7%H%C:ALK&M\@9!_Q2C-6 *4 NB!"#)4!PS!&+[(O,(@6>>LO]A!P(8;V3 =0DP M=],Q('L0;B$(<&+W"[$FDWVA)\L`:##+X,V@XW_P'*%S=67VP)0'W#L"3\26=*02Q_6(@5!_6 M^_[1"'!FB8$7A+X0N5">LI8B*O$#T7684',MP3#W:" KH$W@>Q (\0<"/T!-85,NX?4OUT* \5HQ MPM)19)#ZH/\; 4`7=HD/YL&;$? MY0ZI+A -`PI03D'O_H/-T'_Q&2(H)I/^T2A2__Z2F& 5D2NT".(4]8#P"3#_ M^V"XH!WC3F"3\3SR0J0&\]_(DA^B!B%P82R =120>U/_*)&*42_$.6%*\!^B M2X .\M\4<9B >0" P0-C+@* !7)__J0YE/VAN6 .0$FV]$ B^0&"92("@<3P M;A(4XG_P_P+PT[4%T;*@;B% `?XT!>'O, '_<+NPSB!P# $4`0>B_PN0#G$> M) T:&W(4\S92?7'_0.$DT,B@*9'^, IQ!D)8X-NRH DP;=50@5 B:#"_,/TX MXF,,\#J#F(":T'!A"F">8WD`)0,^\5)1(%?(H/0S,CL`3?VPG^ X\1*NORST M( ,I10AP)&,'`BJ[`?>OP-.UNP`J5Q8:^KNP"F"?R% S$0HQ#!,?L75P_U*\ M-G@-#!YA65$;X7K^\?M?Y+!P)0

U /P$L`!,"]7&1(MQ"3LETR!P)N?;#^ M+0ZZ']8]9:WQ'*'&L0CQ7U_A#C#)4)C -7 H.H!Y_\V0%=&>H +P>(!BD$=# M891_:/9-8\X@F&!#<2X@$JQ7_U3E#D!&A?[A@)$"\!%1)N#_'9!9,S8Q%0'" MD!1Q'[%1P_\,`@T##J#VP!@7XA6'%XL+12NP;" M,<)2"'#_0 >Q0G*!?RLP1>(UT1'AQ/!@O@9!./]UDHE0!8"VU ;SQR(4Y6A MV_W$+B))=L%SSRZS8 T#_#(N]Y!(`2>3 M,]1_WT %$/J@![$?L7\P$JQ)WQ_ 1]/!02_(3M\H^Q"N0/^O8UE!T=$G4QKZ MF,-@, 5Q_[NPF("8T47V)N/,@4+2'))_)S-8<2>@*6 VXQMC29)NOFW!,%=1 M`H 7E1:P+QKZ__WQQR(9X,YQ_F"K@3_R9)#]*3%R.(&3\01(6'_('$'Q&2?6M9QPD%@R_&O"LXAL7(4LA6*!;\_\],Q3!!8!H@GE@P=(E$RF"_VS('Z+'(453=N%/D6&! MA\3[/.$2<&<$L$J@RT#^<#SU_\]P)L(T`TG!J,&/6B,&_D#_3W.97P515<*# MWBN@J+*#`?]/$#.Q+N$?L6T(>W%9C03A^U36*KP_.2(_0$\06&!(=?\*4_Z4 MI< \)!'AR5"O,/MP_PI032#W4!OR'E7?0' 8"!+_@9$?ME1'WT!L M)"J\(G/_@3P3D"0TE0,Y#W,+\< MH),(4T4(Y8?OQ_XER*)4`C^!1$ D2E=#_& #GD*8!DH&#[2)C'=#N`/_& M$B?!D+%!<7'"L.)OD!G@_XOAO;$AV0&*[K)0T12B`#&_VYG10H,@&8$1I=21 M+Q(5_S>R^XE"PQTJ__/,,:0)CSU((H(@V!"6K_Y'* M75 ?L1*"#(H:3QM?'&__T)9OPH*DR^+*5?H9`#()9O\!;%7 *9%0T> E1$C[ MPVB /S(PU%(LU GT(WI9G$IO^FC$($)CL&>Q69Y[TGMB_XOB\W SD&AS5&"1 M8JE56( QG)%-2'K4@-;Q:76'32!;TYR0.$U">0W1_XTA44#?4DR!FQ%U$YR0 MV?"_XL)_XXDE"K!5X*4&\R M`'"/L8 ABL,:`M\ZATMQ-B),LJYP=,X"2M+_G0!18%]1B^*S(SZAJS+B,7^W M0;+ .>,$TFHT52%Y8&O]TF!WZP'Q8SL&GR(2@K0#ZTS&:()'MT!0?["/X/IP M_E1?8WL`23)28TIP_D")8?]?5(K#2W%BL,4QO#UJ-&B"VB(U\7!Z05A@2@DA M+\"IE[ Y.73P,?R0-/=0_# P5K!JE&ASQ$ GHUUP_^712L/E(=LQ`#)W%4=H M3++?/V*+XE!25]0X(615T&SH?T_TBL/5))RA8J528V) ;__9\$QH\-"006?1 M%S5&E7<&OT=I!Q'YIR!N)^Y# MV>3S7_1C;6+K;=&0%&19E5SP0;7!Q2#_X&.LLWCB`(3?@)[PZ(*F`?NG@[0" MA07-GI RH38/\8'_Y2'M$1]!FG/F$!<`JS#$0/>>N=C6UY%V@?4,%?M5\$O_ MK>'F, *$!')Z`8P@PS!G0/^ND8TB__"/X-<(>(.>4&L@+?H!('`6% YY [,VXO,"80/^*DKF.>4)'*;FT>D&8R[8"0A!5E]119T`#Y51V6%\L]EA3$]#3^^#@H2&EV:$S#.$O8F0A,P^.5%%R!"= M`+50+Y$Q-X@Y-C13@#,N-X>CV#(N-'9RG($R3H"*\J0T,XM4,3B+4S*,-2>) MH)N@@X(V,XS,.3#/B\!"UJ[RV6$W.(G@]T!;`$ TT#6&HXJA.8OD-Y>+5)N1 MD1LWD74P-HQ4]CF1]9-F.)%P447^(%(@WVP1B90\(O&F:0U.$YP446N4&=$,)$5B=,U+BZ BF0W9Y ADS*+ MQ30UDP6+Q3C]B\4PGE3W0)Y6G]7W0)LWC__PR*#28(N1.3@RC]#=_&$U12"* M\IS -8UCDW3[D<&3=#:9I)+!BT28%4RP^C67I#6+1$4QBS%11??3OXQSB?") MT#3PBJ&0A3"C$]^?19-!D72;$:04,Y>DBD WI 2KL(U$-YY43+ V-UN;)S<0 M>=^ 0:$SK< V[XFPJ0*!<*,D,XK3D>6+D=68)#2C_32P=3*A,)FT_Z3VB?"; M)_^UC\>*(/L`BF__I#DN<8Q4C*":/)<@FCV>4/U13$[/TH)O@W^$CX6?AJ__ MA[^(SXG?D92>5I'UIN7"T/^+Q9!PBU2P`,4,LO&.[X__WY$$KQ"W6\J(BT4V MGE7&YO_,EXU E1^6+Y5=CY_Z%_HH^CDZ1UW0?#(*0$K;#7K$7>I:NF,ZPV-\XGJ"__J3ZP M=:,`I 3C1J/FPO"D!/XYI?7E1L32K?^O#XK3B[7_L%??%J9U1+&D!;@UK:#D MY7_#$,@&;T]P78"OM*^UOC?_B\:8)?+&RQ:L)=EG],>1/@;^[_[T/OA__OR_ /\%/ MPE^*/330IW"?\_^7%330"4&:TJ_P!?,TT)S4WY'0D&"1`L^WJ:$VR!_)+_^1 M`POQBM/#40NFG6,+<1'E^CB*TS>

&1`PIQ!?,N<*_P!/(*=O^+H N!U'_5CQ@5LV *M D@WPNUEK,7X0NE MD/0X%W4?)GXY#AC;'Z+]HN".L*,D.?^CDS6P(_2V((N@)!07A,-0_W9C4T*U MU#6PBS#@W^'OHQ/_J:&0A8LP(Y4I12A HR07A-\?H*N@*U6P%!TA,>7@H!SJS[#9 M<*MD+3'[-^H,<3>Z;P&?`J\#OP3/_P7?!N\'_PD/BL35X!>$MB'_HQ/5X)U4 MG3$=U8I$)=$+I?]%]PX_#T^0]!,P$=0R4!<$_TH!%Q638!+TD/0R4#@T3 CO M&( 4?Q6/ES,VG4"0A9] _4_T-I$#MB P=% P,?8X-/U2.3 :OQO/G6-0,!B$ M4+C?)?0R44_E"Y0R4#:6LUAJ]R#O(?\D!3B6LR;@-S1=$=] 4S'6)N";`*,D M-UY&HQ/O"G(G+R@_HQ4Y*T4,E1ZU_Z_A7L4P="/10%,P5C%2+6__+G\E!ES% M601=$5Q&,85>MO\9!%Z1BM0FX3.6^)_YK^_/_S0_M=M2,3Y3*Q%/YI:U4=;O MD^!,13Y3=$DU_N__^&T_$VY,=T9]`'I ``,`$! ``````P`1$ `````>`$(0 M`0````$``````````P" $/____] ```": "" &``````# ````````1@````!4A0```0````4````X+C R M``````,`)X (( 8``````, ```````!&``````&%````````"P`P@ @@!@`` M````P ```````$8`````#H4````````#`#& "" &``````# ````````1@`` M```1A0````````,`,X (( 8``````, ```````!&`````!B%````````'@!" M@ @@!@``````P ```````$8`````-H4```$````!`````````!X`0X (( 8` M`````, ```````!&`````#>%```!`````0`````````>`$2 "" &``````# M````````1@`````XA0```0````$`````````'@`]``$````%````4D4Z( `` ,```#``TT_3<``*0P ` end -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 3 11:04:47 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id LAA12084 for ; Fri, 3 Oct 1997 11:04:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA27552 for png-list-outgoing; Fri, 3 Oct 1997 10:55:16 -0500 Received: from gntcompaq.gintic.ntu.ac.sg (gntcompaq.gintic.gov.sg [155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA27547 for ; Fri, 3 Oct 1997 10:55:09 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BCD057.0B0A7C60@gntcompaq.gintic.ntu.ac.sg>; Fri, 3 Oct 1997 23:49:52 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: PNG and JPEG-LS Date: Fri, 3 Oct 1997 23:49:50 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List John wrote: >If you move from the default settings (adaptive filtering, compression >level 6 I believe - they were apparently using a buggy version of >pnmtopng) the speed/compression performance changes (no surprise there >:-) He John, remind: there were never buggy versions of pnmtopng, only, maybe, maybe, maybe some versions that needed some further optimization !!! ;-) [skipping lots of good measurable comparisons, thanks] OK, time for some comments. First of all I agree completely that adding a second compression should only be done when it really gives substantial improvement. In this there is no such thing as backwards compatibility, only "this compression format is not supported ...", or still my favorate error message of all times (I think from Win3.11): "to prevent any loss of data your system will be rebooted", which then indead happened after you pressed the any-key :-). And when we then talk about _substantial_ savings, then I 100% agree with John that it should be savings for the images and usages targeted by the format. IMHO that means for GIF/PNG type of images: 1. size of the image comes ofcourse first, being a format for images that float over the web 2. but photographic images are not that relevant, because for that purpose the comparison should be with JPEG 3. _de_compression time is important, not compression time; for any image the latter is happening at least 100 times more often done then the former 4. improvements on any of these of around 20% is not significant; changing the standard should only happen with at least 50% improvements So in one sentence, a new compression method is possible when it scores better on the compression ratio of non-photograhic images and has better decompression times. Both of these appear not to be the case with JPEG-LS. Which makes that I really feel that "the world is not waiting for this". But OK, who am I ? Then one more question to the makers of JPEG-LS as well as the makers of "normal" JPEG, is there a real reason why this new compression method uses the JPEG name? Is there any similarity in the way the compression is done? Or is this more a "marketing issue". Willem PS1. How do we get Netscape to follow MS in supporting IMG-tag based PNG? PS2. I really think we should brandmark the current libpng as a 1.zero.something version! PS3. The first two PS's could well be inter-related :-) > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 3 11:35:13 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id LAA13147 for ; Fri, 3 Oct 1997 11:35:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA27922 for png-list-outgoing; Fri, 3 Oct 1997 11:25:39 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA27917 for ; Fri, 3 Oct 1997 11:25:29 -0500 Received: by grommit.inria.fr (8.8.6/8.8.5) id SAA26849 for png-list@dworkin.wustl.edu; Fri, 3 Oct 1997 18:20:36 +0200 (MET) Date: Fri, 3 Oct 1997 18:20:36 +0200 (MET) From: Chris Lilley Message-Id: <9710031820.ZM26847@grommit.inria.fr> In-Reply-To: Willem van Schaik "RE: PNG and JPEG-LS" (Oct 3, 11:49pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: PNG List Subject: libpng version (was Re: PNG and JPEG-LS) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Oct 3, 11:49pm, Willem van Schaik wrote: > PS1. How do we get Netscape to follow MS in supporting IMG-tag based > PNG? > PS2. I really think we should brandmark the current libpng as a > 1.zero.something version! > PS3. The first two PS's could well be inter-related :-) Could well be. I had an enquiry from a large computer-related company whose name doesn't start with M or N ;-) about the status of libpng and what was the deal about the <1.0 version number. They ended up using zlib but not using libpng; zlib is of course at version > 1.0 So, what remains to be done to move a library which seems to have been sitting 0.9 < x <1.0 for some time. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 3 11:42:26 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id LAA13456 for ; Fri, 3 Oct 1997 11:42:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA28015 for png-list-outgoing; Fri, 3 Oct 1997 11:36:24 -0500 Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA28010 for ; Fri, 3 Oct 1997 11:36:20 -0500 Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id LAA04888 for ; Fri, 3 Oct 1997 11:31:26 -0500 (CDT) Received: from sjx-ca9-01.ix.netcom.com(199.182.128.33) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma004616; Fri Oct 3 11:30:00 1997 Received: by CORUISK with Microsoft Mail id <01BCCFDF.17C9F7A0@CORUISK>; Fri, 3 Oct 1997 09:31:14 -0700 Message-ID: <01BCCFDF.17C9F7A0@CORUISK> From: John Bowler To: "'PNG List'" Subject: Stupid attachment on my message RE: PNG and JPEG-LS Date: Fri, 3 Oct 1997 09:20:03 -0700 Encoding: 4 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Ignore the stuff attached to my previous message, it is just another copy of the same thing as a Word document - an error on my part. My apologies. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Oct 4 11:34:20 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id LAA19644 for ; Sat, 4 Oct 1997 11:34:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA12753 for png-list-outgoing; Sat, 4 Oct 1997 11:34:19 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA12748 for ; Sat, 4 Oct 1997 11:34:15 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id JAA18530; Sat, 4 Oct 1997 09:29:17 -0700 (PDT) Date: Sat, 4 Oct 1997 09:29:17 -0700 (PDT) Message-Id: <199710041629.JAA18530@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: Re: PNG and JPEG-LS From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> Why do you think ZIP has taken over the world when ARJ and Yabba outperform >> it? Because a ZIP file is a ZIP file, everywhere in the world. Users >> won't even notice a 20% size saving; hell, they hardly ever notice a >> 50% savings. They certainly will notice "Sorry, I can't read this file." > And yet ZIP survived the transition from implode/explode to inflate/deflate. I'm probably a bit better qualified to comment on this point than either of you are... Without undue modesty, the two primary reasons the zip format became and remains the standard are (1) PKZIP was the best and fastest archiver available for many years, and (2) Info-ZIP provided free and pretty fast ports (in both directions) to more operating sys- tems than any other archiver in the world--even Zoo, I think. The ports helped ensure that site owners (Simtel, Garbo, Hobbes, Walnut Creek, UUnet, Wuarchive, etc.) stuck with the format, to the point where it's now extremely entrenched. No doubt it will be superseded someday, but that will take a while. As for the transition: yes, it was survivable, but it was still quite painful. Even today, more than half a decade later, we still get the occasional query about "unknown compression method," where the method in question is deflate. I'd say the really painful part lasted a good three years or so. (Tom may have some comments about progressive JPEG, too.) But I'm all for experiments and testing, as long as the test files are either not called "PNG" or don't escape onto the network. A "JNG" interim format with compression method 1, modified signature, and eventual support by libpng might never be merged with PNG on its own merits, but it could possibly merge if and when an even better third method came along (say, something that's really good at doing palette images or general graphics). Btw, keep in mind that the ISO's revision period is five years after the release of the (ISO) standard, so assuming that happens to PNG, it would be at least 2003 before they officially sanctioned any extensions. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Oct 4 11:42:07 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id LAA19825 for ; Sat, 4 Oct 1997 11:42:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA12824 for png-list-outgoing; Sat, 4 Oct 1997 11:43:04 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA12819 for ; Sat, 4 Oct 1997 11:43:01 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id JAA20124; Sat, 4 Oct 1997 09:38:03 -0700 (PDT) Date: Sat, 4 Oct 1997 09:38:03 -0700 (PDT) Message-Id: <199710041638.JAA20124@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: Re: libpng version (was Re: PNG and JPEG-LS) From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> PS1. How do we get Netscape to follow MS in supporting IMG-tag based >> PNG? As someone noted, PNG is native in MSIE 4.0. As someone else noted (and as I've documented in at least a couple of places on the web site), S&G are working with Netscape to include their PNG Live code native in "the next" version of Navigator. I don't know if that means 4.1 or 5.0, but at least we know S&G have a pretty good handle on how to do PNG (with the exception of background color, ahem...). >> PS2. I really think we should brandmark the current libpng as a >> 1.zero.something version! Some may recall my suggestion along those lines 9 months ago... :-) We're closer, but I've seen a few 0.96 patches come through and no 0.97 yet. (To be honest, I'd be willing to call 0.97 1.0 instead; what the heck.) > So, what remains to be done to move a library which seems to have been > sitting 0.9 < x <1.0 for some time. I'm sure Andreas would appreciate help with integrating and testing-- he's perhaps too conscientious a tester himself. I have no more time than he does, or I would have volunteered long ago. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Oct 4 12:54:46 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id MAA21251 for ; Sat, 4 Oct 1997 12:54:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA13338 for png-list-outgoing; Sat, 4 Oct 1997 12:53:44 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA13331 for ; Sat, 4 Oct 1997 12:53:41 -0500 Received: by NetGSI.com (8.7.5/-A/UX-AMR-1.0) id NAA31902; Sat, 4 Oct 1997 13:48:42 -0400 Message-Id: <1.5.4.32.19971004174712.006a1c30@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 04 Oct 1997 13:47:12 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG and JPEG-LS Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 09:29 AM 10/4/97 -0700, greg wrote: >But I'm all for experiments and testing, as long as the test files are >either not called "PNG" or don't escape onto the network. A "JNG" interim >format with compression method 1, modified signature, Didn't we have this discussion before? Either you or I wanted to call experimental files "NNG" for "nonportable network graphics" but then we decided any legal PNG file should be called PNG and have the PNG signature; that non-standard but legal ones should have a private critical chunk very early in the stream so decoders could recognize them and reject them with an appropriate message. An interim test version *must* use a compression method number that is 128 or higher, not 1. Only after we register a new compression method (assuming we can get a quorum) would it become method "1". Not allowing them to escape onto the network is a good idea. But it'll happen. glennrp -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Oct 4 13:48:31 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id NAA22293 for ; Sat, 4 Oct 1997 13:48:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA13690 for png-list-outgoing; Sat, 4 Oct 1997 13:41:24 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA13685 for ; Sat, 4 Oct 1997 13:41:21 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id LAA12262 for png-list@dworkin.wustl.edu; Sat, 4 Oct 1997 11:36:23 -0700 (PDT) Date: Sat, 4 Oct 1997 11:36:23 -0700 (PDT) Message-Id: <199710041836.LAA12262@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: Re: PNG and JPEG-LS From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: >>But I'm all for experiments and testing, as long as the test files are >>either not called "PNG" or don't escape onto the network. A "JNG" interim >>format with compression method 1, modified signature, Glenn replied: > Didn't we have this discussion before? Either you or I wanted to call > experimental files "NNG" for "nonportable network graphics" but then Yes, we got shouted down by Tom and others. I still don't agree, and I probably should have mentioned that this was my personal opinion... > An interim test version *must* use > a compression method number that is 128 or higher, not 1. Only after > we register a new compression method (assuming we can get a quorum) > would it become method "1". Only if it claims to be a PNG file. A file with signature "JNG" could use any compression method number it wants. > Not allowing them to escape onto the network is a good idea. But it'll > happen. This is primarily why I was never convinced by the "one PNG size fits all" arguments. Individual companies' special-purpose critical chunks aren't likely to escape and aren't likely to become widespread even if they do escape. But a semi-official, experimental new compression method with reasonably better results on some files will be treated just like the PKZIP 1.93a beta was: "good enough" to use publicly, resulting in pre- cisely the kind of mess we've just been arguing about. It won't be quite as bad as an officially blessed PNG standard with two compression methods, but it will be enough to annoy lots of people and give PNG a patina of untrustworthiness. The worst part about it is that there's absolutely nothing to be gained by calling the new format "PNG" before the experimentation phase is com- plete. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 5 09:38:07 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id JAA16748 for ; Sun, 5 Oct 1997 09:38:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA23613 for png-list-outgoing; Sun, 5 Oct 1997 09:32:19 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA23608 for ; Sun, 5 Oct 1997 09:32:14 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id KAA09528 for ; Sun, 5 Oct 1997 10:27:11 -0400 (EDT) To: PNG List Subject: Re: PNG and JPEG-LS In-reply-to: Your message of Sat, 4 Oct 1997 09:29:17 -0700 (PDT) <199710041629.JAA18530@shell.wco.com> Date: Sun, 05 Oct 1997 10:27:11 -0400 Message-ID: <9526.876061631@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs writes: > As for the transition: yes, it was survivable, but it was still quite > painful. Even today, more than half a decade later, we still get the > occasional query about "unknown compression method," where the method > in question is deflate. I'd say the really painful part lasted a good > three years or so. (Tom may have some comments about progressive JPEG, > too.) Yes, progressive JPEG has been and still is a compatibility nightmare. It's now more than 2 years since the public release of the IJG implementation, but there are still a lot of programs that don't cope. That experience hasn't left me looking forward to introducing any incompatible improvements in PNG. regards, tom lane organizer, Independent JPEG Group -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 5 15:34:09 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id PAA23824 for ; Sun, 5 Oct 1997 15:34:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA26904 for png-list-outgoing; Sun, 5 Oct 1997 15:25:26 -0500 Received: from raid2.fddi.phoenix.net (alpha400.phoenix.net [207.43.3.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA26897 for ; Sun, 5 Oct 1997 15:25:21 -0500 Received: from 199.3.232.2.phoenix.net (dial63.phoenix.net [205.241.121.77]) by raid2.fddi.phoenix.net (8.8.5/8.6.12) with SMTP id PAA32275 for ; Sun, 5 Oct 1997 15:33:15 -0500 (CDT) Message-Id: <199710052033.PAA32275@raid2.fddi.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-list@dworkin.wustl.edu Date: Sun, 5 Oct 1997 15:20:07 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG and JPEG-LS Priority: normal References: Your message of Sat, 4 Oct 1997 09:29:17 -0700 (PDT) <199710041629.JAA18530@shell.wco.com> In-reply-to: <9526.876061631@sss.pgh.pa.us> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Here's my two cents worth. PNG was created in an intense flurry of activity by a capable team on the heels of the Unisys LZW patent announcment. A good (not perfect) spec was created that was a big advance over the patent-encumbered GIF. But for a variety of reasons acceptance was slow (implementation is harder than GIF, the popularity of the horrible web page animated GIFs etc. etc.) We are now at the point where we have the possibility of getting to a critical mass of acceptance. PNG is now supported by IE explorer and ipso facto is supported by Windows 98. I believe it is also supported by Office 97. Netscape is reportedly on the way. IMHO this is exactly not the time to be considering extensions or changes to PNG. PNG's acceptance in the wider community is still not completely secure. Even though PNG appears to be on the brink of acceptance by the major web players, application support of some PNG features is still problematic. For example, PaintShopPro *still* crashes when reading perfectly legal PNGs created by POV-Ray that have multiple IDAT chunks. Gamma support is problematic by many apps. We should be worried about raising the quality of PNG support, and winning over applications that haven't yet implemented PNG. If we hit the industry with a major addition the the spec that requires evryone's implementation to change, we'd be adding confusion at exactly the wrong time. I would never want to stand in the way of progress, but for strategic reasons I have to side with those who are cautious on this issue. This is not the time to make changes or additions to the PNG spec. Tim -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 5 16:16:56 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id QAA24715 for ; Sun, 5 Oct 1997 16:16:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA27217 for png-list-outgoing; Sun, 5 Oct 1997 16:06:53 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA27205; Sun, 5 Oct 1997 16:06:05 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA00585; Sun, 5 Oct 1997 15:00:57 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199710052100.PAA00585@enel.ucalgary.ca> Subject: Re: libpng version (was Re: PNG and JPEG-LS) To: png-list@dworkin.wustl.edu Date: Sun, 5 Oct 1997 15:00:57 -0600 (MDT) Cc: png-implement@dworkin.wustl.edu (PNG Implementation) In-Reply-To: <199710041638.JAA20124@shell.wco.com> from "Greg Roelofs" at Oct 4, 97 09:38:03 am X-Mailer: ELM [version 2.4 PL25-U] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg writes: > Some may recall my suggestion along those lines 9 months ago... :-) We're > closer, but I've seen a few 0.96 patches come through and no 0.97 yet. > (To be honest, I'd be willing to call 0.97 1.0 instead; what the heck.) > > > So, what remains to be done to move a library which seems to have been > > sitting 0.9 < x <1.0 for some time. > > I'm sure Andreas would appreciate help with integrating and testing-- > he's perhaps too conscientious a tester himself. I have no more time > than he does, or I would have volunteered long ago. To be honest, I've been doing a rather poor job, if any, of upgrading libpng to the 1.0 level. I originally took over libpng maintenance from Guy from the perspective of a user of the library who wanted bugs to be fixed, when I realized that nothing was being done by Guy's end for a new release. Unfortunately, now that I've started a new job, bought a house, got engaged, and am planning for the wedding this spring, I have come to the conclusion that I'm just never going to "get around to" releasing a new version of libpng. My work with PVMPOV, and later POV-Ray itself, which originally spurred my interest in libpng, has also dried up. I recently read Eric S. Raymond's paper on the develpment methods of freeware software, including Linux, entitled "The Cathedral and the Bazaar" . In it, he says that an important part of a freeware project is that once you stop working on it, you should find someone who will continue your work. This is my invitation to anyone reading who would be interested in doing the bit of work needed in shaping libpng from the current 0.96 release into the 1.0 release. To be honest, not very much work needs to be done at the present time. A few bugs exist in the current version that keep getting reported: the "wrong version check", compiler warnings for the DEC compiler because of 16-bit function arguements, some type mismatches shown up by the DEC compiler, and memory leaks from some of the text handling functions. I have patches or detailed reports for all of them that can be sent on. I would really prefer that someone take this on as a long-term project, but even releasing the 1.0 version is a significant step that needs to be done ASAP. This isn't to say that I won't try to contribute as I can, it's just that I've found I'm better off working on a whole bunch of projects by contributing from the fringes as I can, rather than leading a single project. Cheers, Andreas -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 5 19:03:21 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id TAA28004 for ; Sun, 5 Oct 1997 19:03:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA28274 for png-list-outgoing; Sun, 5 Oct 1997 18:16:03 -0500 Received: from boutell.com (boutell.com [206.125.69.81]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA28269 for ; Sun, 5 Oct 1997 18:15:59 -0500 Received: from vader.boutell.com by boutell.com (8.8.5/8.7.3) with ESMTP id QAA20832 for ; Sun, 5 Oct 1997 16:29:48 -0700 Received: from localhost (boutell@localhost) by vader.boutell.com (8.8.5/8.7.3) with SMTP id QAA14113 for ; Sun, 5 Oct 1997 16:12:07 -0700 Date: Sun, 5 Oct 1997 16:12:06 -0700 (PDT) From: Thomas Boutell To: PNG List Subject: Re: PNG and JPEG-LS In-Reply-To: <199710052033.PAA32275@raid2.fddi.phoenix.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Pick a newsgroup and rescue it: http://www.boutell.com/boutell/usenet.html On Sun, 5 Oct 1997, Tim Wegner wrote: > IMHO this is exactly not the time to be considering extensions or > changes to PNG. PNG's acceptance in the wider community is still not > completely secure. Even though PNG appears to be on the brink of > acceptance by the major web players, application support of some PNG > features is still problematic. For example, PaintShopPro *still* > crashes when reading perfectly legal PNGs created by POV-Ray that > have multiple IDAT chunks. Gamma support is problematic by many apps... I agree wholeheartedly. This is *not* the time to be making changes to PNG, particularly changes involving valid PNG images that existing correctly written viewers won't be able to display. It's just not a smart idea if we want wide acceptance for PNG. If you've got the energy to think about New Things, work on finalizing libpng 1.0, or the MNG specification, or a MNG library! MNG needs new energy, PNG needs an air of maturity. -T -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Oct 6 07:09:01 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id HAA13571 for ; Mon, 6 Oct 1997 07:09:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA05541 for png-list-outgoing; Mon, 6 Oct 1997 06:55:42 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA05536 for ; Mon, 6 Oct 1997 06:55:32 -0500 Received: by NetGSI.com (8.7.5/-A/UX-AMR-1.0) id HAA08906; Mon, 6 Oct 1997 07:50:19 -0400 Message-Id: <1.5.4.32.19971006114848.00675b18@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 06 Oct 1997 07:48:48 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: New Energy for MNG, Air of Maturity for PNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 04:12 PM 10/5/97 -0700, Thomas wrote: >If you've got the energy to think about New Things, work on finalizing >libpng 1.0, or the MNG specification, or a MNG library! MNG needs new >energy, PNG needs an air of maturity. MNG will get new energy when I get my hands on an SGI again--hopefully fairly soon. I'm planning to rework ARL viewpng to use X instead of IRISGL library routines, and to make it completely MNG-conforming (I hadn't finished writing the PAST chunk implementation and a couple of other minor things when I left ARL). The spec still needs a little more work, but I didn't get any response to my pleas for comments in April or since then. Another thing we need is a 1.0 version of the PNG extensions document. I can take that on if tom doesn't want to. It needs to include the sRGB and sPLT chunks. We also approved pCAL as a "scientific visualization" chunk, but since pCAL was the only sci-vis chunk approved, should we also put it in a sci-vis chapter of the extensions document? It looks kind of silly all alone in the Scientific Visualization Chunks document (which I had thought was also going to contain fALS, xSCL, and ySCL). glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 7 12:21:46 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id MAA03731 for ; Tue, 7 Oct 1997 12:21:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA25188 for png-list-outgoing; Tue, 7 Oct 1997 12:06:45 -0500 Received: from boutell.com (boutell.com [206.125.69.81]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA25180 for ; Tue, 7 Oct 1997 12:06:36 -0500 Received: from vader.boutell.com by boutell.com (8.8.5/8.7.3) with ESMTP id KAA28855 for ; Tue, 7 Oct 1997 10:19:50 -0700 Received: from localhost (boutell@localhost) by vader.boutell.com (8.8.5/8.7.3) with SMTP id KAA14686 for ; Tue, 7 Oct 1997 10:01:45 -0700 Date: Tue, 7 Oct 1997 10:01:45 -0700 (PDT) From: Thomas Boutell To: png-list@dworkin.wustl.edu Subject: Permission (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by swrinde.nde.swri.edu id MAA03731 Is there a license for these images already that we can just point this fella to perhaps? -T Pick a newsgroup and rescue it: http://www.boutell.com/boutell/usenet.html ---------- Forwarded message ---------- Date: Tue, 7 Oct 1997 15:28:54 +0000 (GMT-2:18) From: Davide Cavagnino To: png-info@uunet.uu.net Subject: Permission CAVAGNINO DAVIDE Dipartimento di Informatica Università degli Studi di Torino C.so Svizzera 185 10149 Torino Italy tel. + 39 11 7429229 fax + 39 11 751603 e-mail: davide@di.unito.it Dear PNG group, I've downloaded some images in the ftp database ftp.funet.se for use in a compression algorithm I've developed for my PhD thesis. I would publish them in my written dissertation, that will be distributed, without profit, to the principal italian Universities. I will specify the origin of the images, and the use I'll make will not damage your reputation. Please send me a written permission by mail and a copy of the written permission by fax for speeding up my work. Send me the origin of the images you want to be published (dolphins,skyvase, impossible). For any further explanations please contact me at my e-mail address. I thank you for your collaboration, Yours sincerely, Davide Cavagnino -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 9 12:30:55 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id MAA15328 for ; Thu, 9 Oct 1997 12:30:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA27959 for png-list-outgoing; Thu, 9 Oct 1997 12:26:32 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA27954 for ; Thu, 9 Oct 1997 12:26:26 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id NAA28922 for ; Thu, 9 Oct 1997 13:20:59 -0400 (EDT) Received: by grommit.inria.fr (8.8.6/8.8.5) id TAA16061 for png-group@w3.org; Thu, 9 Oct 1997 19:20:53 +0200 (MET) Date: Thu, 9 Oct 1997 19:20:53 +0200 (MET) From: Chris Lilley Message-Id: <9710091920.ZM16059@grommit.inria.fr> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: png-group@w3.org Subject: QuickTime 3.0 has PNG support (official) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List There is now a feature list of supported formats for QT3.0, which includes PNG. http://quicktime.apple.com/qt30/specsheet/qt3fact1.html Greg, I think this is more substantial than the current "strategic directions" link, could you update the link on http://www.wco.com/~png/pngapmi.html -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 9 18:38:36 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id SAA18788 for ; Thu, 9 Oct 1997 18:38:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA02746 for png-list-outgoing; Thu, 9 Oct 1997 18:34:29 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA02741 for ; Thu, 9 Oct 1997 18:34:25 -0500 From: 8Any@yt8ri.com Received: from mail.mitsuyoshiusa.net (mail.mitsuyoshiusa.net [204.157.32.56]) by www10.w3.org (8.8.5/8.7.3) with SMTP id TAA01690 for ; Thu, 9 Oct 1997 19:28:54 -0400 (EDT) Received: from @onallthe.net [207.205.130.245] by mail.mitsuyoshiusa.net (SMTPD32-4.02) id A8261E0106; Thu, 09 Oct 1997 19:26:30 EDT To: Any@Domain.com Subject: Candy is Dandy, Flowers are fine...Mars is marvelous! Message-Id: <199710081930.e-mail@@onallthe.net.com> Received: (from uudp@lcllhost!) by in2.i_b_m.net (8.6.9/8.6.9) id CFF569794 for ; Sun, 18 May 1997 01:12:39 GMT Received: from tomsnet!.com (mh.tomsnet!.com [100.301.57.69]) by m4.tomsnet!.com (8.6.12/8.6.12) with ESMTP id PAA21932 Received: from reb50.rs40_date.net (root@reb50.rs_date.net [289.36.1.176]) by tomsnet!.com (8.6.12/8.6.12) with ESMTP id PBA023891 for ; Received: (from capt_domo@lclhost!) by pc.spark_er.net (8.7.3/6.7.3) id CFF34285 for planet_oreo_horizon; Sat, 17 May 2001 20:12:58 -0500 (CDT) Received: from emoose.mail.n_bot.com (emoose.mx.n_bot.com [198.81.11.42]) by md.s#parpnet.net (8.7.4/8.7.3) with ESMTP id RAC035940 for ; Received: from clift.b89_crost.com (clift.b89_crost.com [199.3.12.256]) by dot.2_bycentric.net (8.8.5/04/01 3.26)) id LAT131787; Received: from spr_most.bix.45neter!.com(204.332.183.71) by hars11.ix.45neter!.com via smapt (V1.3) id smr0029301; Content-Type: text/html; charset=us-ascii Date: Thu, 9 Oct 97 19:27:23 EDT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >>>>>>>>>>>>>>>>>>>>>>>>> -oOo- <<<<<<<<<<<<<<<<<<<<<<<<< Know somebody who has a birthday coming up soon? Need a unique gift to surprise a loved one? Keeping your eyes open for an anniversary gift? >>>>>>>>>>>>>>>>>>>>>>>>> -oOo- <<<<<<<<<<<<<<<<<<<<<<<<< *** Give A "Land Claim" On The Planet MARS! *** Sound too incredible to be true? Believe It - It Is True!!! http://www.martianconsulate.com/ "Land Claims on MARS!" Is this for real? YES! The Martian Consulate, L.L.C. maintains a list of Deed Claimants in its Official Registry protected securely in Geneva, Switzerland. Registrants' names, addresses, "claim" coordinates and serial numbers are recorded, and by a trust established by The Martian Consulate, L.L.C., will be presented to a legitimate government on Mars when such a government is established! Register a loved one today! Each Registrant receives a beautiful 11" x 14" Certificate of Deed Registration and a Survey of Plat (a map which pinpoints a claim location on Mars), and an optional hand addressed gift card. Claim are 1 square mile, and are priced at US$29.95 for a single claim, $46.95 for a dual claim, and $59.95 for three claims! Your satisfaction is 100% guaranteed, and we stand behind our Certificates with a thirty day, money back, no-question, no hassle guarantee! http://www.martianconsulate.com/ "Land Claims on MARS!" Thousands of individuals from more than twenty-two countries on four continents have already discovered this fun, unique gift! Please drop by our web site today to learn more! http://www.martianconsulate.com/ "Land Claims on MARS!" And visit our site often to find out more about our new Martian Consulate Jumbo 15 oz. (440mL) Coffee Mugs, as well as our upcoming golf shifts, cool tie-dye T's and custom embroidered baseball caps! -- The Martian Consulate, 21st Century Space Novelties -- >>>>>>>>>>>>>>>>>>>>>>>>> -oOo- <<<<<<<<<<<<<<<<<<<<<<<<< -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 9 20:17:53 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id UAA19141 for ; Thu, 9 Oct 1997 20:17:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA03613 for png-list-outgoing; Thu, 9 Oct 1997 20:19:53 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA03606 for ; Thu, 9 Oct 1997 20:19:40 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id SAA17684; Thu, 9 Oct 1997 18:14:12 -0700 (PDT) Date: Thu, 9 Oct 1997 18:14:12 -0700 (PDT) Message-Id: <199710100114.SAA17684@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: Re: QuickTime 3.0 has PNG support (official) From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Greg, I think this is more substantial than the current "strategic > directions" link, could you update the link on > http://www.wco.com/~png/pngapmi.html Just did, but I used the main specsheet page since that's even more substantial. Thanks for the link, Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 10 17:00:12 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id RAA04524 for ; Fri, 10 Oct 1997 17:00:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA18724 for png-list-outgoing; Fri, 10 Oct 1997 16:47:27 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA18716 for ; Fri, 10 Oct 1997 16:47:11 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id OAA06592 for ; Fri, 10 Oct 1997 14:41:38 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Fri, 10 Oct 1997 14:41:38 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Re: PNG and JPEG-LS In-Reply-To: <199710041629.JAA18530@shell.wco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List This discussion touches on some tricky issues -- how to compare compressors usefully, and how to choose the best compressor for various image classes. I am working on a paper comparing five lossless image compression systems, so I will contribute by $0.02 here. (The paper will appear in the Proceedings of Electronic Imaging '98.) Here is an outline of the rest of this message: A. Responses to prior messages regarding PNG and JPEG-LS 1. Compression ratio comparison 2. Running time comparison B. Experimental environment I used to gather results 1. Test images 2. Software 3. Hardware/OS C. Compression Performance: PNG, JPEG-LS, LZ77, LZW, and GIF 1. Compression ratios for non-color-mapped images 2. Compression ratios for color-mapped images 3. Running times for compression of non-color-mapped images 4. Running times for compression of color-mapped images ******************************************************************************* A. Responses to prior messages regarding PNG and JPEG-LS A.1 Compression ratio comparison: JPEG-LS versus PNG Alex Jakulin got the ball rolling with: > For smooth (photographic) images [JPEG-LS] performs about 5%-20% better than > deflate. Adam M. Costello wrote: > [JPEG-LS yields] a modest improvement in size. Lee Daniel Crocker countered: > [JPEG-LS] is not superior, except in one respect: compressed size (and > even that I haven't seen any reliable numbers on). It's worse > in every other respect. With photographic compound images (that is, continuous-tone images with superimposed text or separate regions of text), I found JPEG-LS yielded compression ratios (CRs) that were about 5% - 6% better than PNG, and about 17% - 22% better than LZ77 (in the form of the unix program gzip). So JPEG-LS gives a bit more compression with images containing large photographic regions. However, the story is different with text-only images and computer graphics. LZ77 performed quite well on complex computer graphics which had thousands of colors; PNG also did quite well, even though it could not run in indexed-color mode; both compressed these images far more than JPEG-LS did. JPEG-LS can also take advantage of color mapping: convert an input image into a mapped image + color palette, then compress the mapped image with JPEG-LS (or gzip, or another compressor). JPEG-LS compressed one of the simple graphic images, "chef", better using color mapping than PNG did. A.2 Running time comparison: JPEG-LS versus PNG Alex Jakulin wrote: > [JPEG-LS is] about 4 times faster at compression than PNG, and slightly > slower at decompression. Adam M. Costello wrote: > Benefits [of JPEG-LS]: Much faster compression. Lee Daniel Crocker wrote: > Actually, I was a bit mistaken: [JPEG-LS] is better in compression speed as > well. ... > PNG has much higher fidelity of data, faster decoding, ... John Bowler wrote: > On the matter of speed the conclusion is much less clear. Anyone reading > the paper [comparing JPEG-LS and PNG, available from HP's web site] will > understand that it was testing a particular implementation, > but it needs to be stressed just how big an effect this can have. Lee, could you clarify what you mean when you write that PNG has a "much higher fidelity of data"? Running times are very difficult to analyze credibly, as John Bowler pointed out, so any timing data should be taken with a bag of salt. With the JPEG-LS and PNG converters I used, JPEG-LS compresses photographic compound images in about 40% - 50% the time that PNG takes, and compresses complex graphics in about 25% the time that PNG takes. With text-only images and simple graphic images, JPEG-LS compresses far more quickly than PNG, taking 3% - 9% the time that PNG took. (The color mapping that the PNG converter used for these images may have contributed a large overhead in the running time.) The PNG converter I used decompresses some photographic images more quickly than JPEG-LS (and one more slowly), and decompresses complex graphics more slowly. JPEG-LS in sample-interleaved mode decompressed text and simple graphics in 21% - 42% the time that PNG took. John Bowler wrote: > [With JPEG-LS], sample interleaved processing seemed to produce results > which were maybe 20% bigger and took maybe 20% longer (PNG is always sample > interleaved.) I find sample interleaving always produces better compression than line-interleaving. In my data, with photographic images, sample interleaving was slower during compression than line interleaving, but was faster with text and simple graphics. B. Experimental Environment B.1 Test Images The test images are in portable pixmap (PPM) format. In this format, three eight-bit color channels (red, green, blue) are interleaved as follows {r1, g1, b1, r2, g2, b2, ... }. # image name columns rows unique file size description colors [bytes] 1 womanCmpnd 2048 2560 98442 15728657 Photographic image with superimposed text 2 cafeCmpnd 2048 2560 362992 15728657 Photographic image with superimposed text 3 toolsCmpnd 1981 2689 262573 15980744 Photographic image with region of black/white text 4 text 1981 2689 2 15980744 Black and white computer- generated text 5 textColor 1981 2689 14 15980744 Computer-generated text, letters alternating colors 6 face 2105 2235 51 14114042 Simple computer-generated clip-art graphic 7 chef 2065 3306 20 20480687 Simple computer-generated clip-art graphic 8 ferrariCutaway 3306 1566 2640 15531605 Complex computer-generated graphic 9 harleyRed 3306 1977 1706 19607903 Complex computer-generated graphic B.2 Software - gzip version 1.2.4, compression setting 6 (slightly biased toward high compression at the expense of speed) - compress version 70.2; 14-bit dictionary used for color-mapped data - locoe and locod versions 0.75 for all images except color-mapped ferrariCutaway and harleyRed; plane-interleaved mode for color-mapped data - loco16e and loco16d versions 0.81X for color-mapped ferrariCutaway and harleyRed images; plane-interleaved mode for these color-mapped images - pnmtopng and pngtopnm versions 2.31 with zlib version 0.89 and libpng version 0.89c, compression setting 7 (slightly biased toward high compression), adaptive filtering; according to the manual for the PNG converter, the software could run much faster with a bit of code optimization - ppmtogif and giftoppm versions 10Dec91. - Proprietary software to produce palette images with RGB or luminance sorting. RGB ordering sorts entries canonically according to red levels primarily, with green levels breaking ties in red values, and blue values breaking ties in green values. Luminance sorting involves converting RGB values to luminance, then using the resulting value to order palette entries. - Proprietary software to produce palette images using the merge heuristic described by Memon and Ayalur. Two color-mapped images (ferrariCutaway and harleyRed) require more than 8 bits per graylevel, since they have more than 256 colors; the software for the merge heuristic cannot do this, so N/A for merge mode with these images. Compression ratios reflect the overhead of the file formats used. Compression ratios of color-mapped images compressed with JPEG-LS, gzip, and compress do not include the overhead of the palettes, but do include overhead of the compression file formats used. Note that the size of the palettes is very small compared with the amount of pixel data for these images. Timing information was from single runs of the programs, using the unix program 'time'; multiple runs were found not to deviate significantly in elapsed CPU time. B.3 Hardware/OS Hewlett-Packard 9000/750 running HP-UX 9.03 C. Compression Performance C.1 Compression ratios for non-color-mapped images COMPRESSION RATIOS ACHIEVED BY LOCO (JPEG-LS), GZIP (LZ77), COMPRESS (LZW), AND PNG # image name /-LOCO modes-\ gzip PNG samp line pln ------------------------------------------------------------------------------ 1 womanCmpnd 1.9 1.9 1.9 1.5 1.8 2 cafeCmpnd 1.8 1.8 1.8 1.5 1.7 3 toolsCmpnd 4.1 3.9 3.9 3.2 3.9 4 text 58.8 32.2 32.1 63.3 mapped 5 textColor 28.7 26.9 28.0 63.6 mapped 6 face 48.8 43.8 44.9 123.9 mapped 7 chef 97.1 80.9 81.3 137.1 mapped 8 ferrariCutaway 5.9 5.9 5.9 22.5 17.0 9 harleyRed 7.8 7.6 7.6 25.6 18.9 # image name /---- compress, bits per dictionary entry ----\ 9 10 11 12 13 14 15 16 ------------------------------------------------------------------------------ 1 womanCmpnd 0.9 1.0 1.1 1.2 1.3 1.3 1.4 1.5 2 cafeCmpnd 0.9 1.0 1.1 1.1 1.2 1.2 1.2 1.3 3 toolsCmpnd 2.0 2.2 2.4 2.5 2.6 2.7 2.8 2.9 4 text 39.9 49.9 56.0 60.8 63.2 67.2 71.3 73.8 5 textColor 22.1 35.5 41.1 44.8 47.8 49.6 50.5 52.0 6 face 7.1 29.0 42.7 60.5 76.4 90.5 95.9 98.0 7 chef 17.4 58.7 85.6 110.9 128.7 138.9 144.2 140.4 8 ferrariCutaway 1.8 2.9 5.2 7.2 8.8 10.3 11.6 12.5 9 harleyRed 2.5 3.9 6.2 8.3 9.9 11.7 13.4 14.7 C.2 Compression ratios for color-mapped images COMPRESSION RATIOS OF COLOR-MAPPED IMAGES # image name PNG GIF /---- LOCO -----\ gzip compress rgb lum merge rgb rgb ------------------------------------------------------------------------------- 4 text 130.3 94.5 97.0 97.0 97.0 90.2 97.9 5 textColor 91.4 68.8 81.1 80.6 85.8 89.5 71.2 6 face 192.0 149.2 149.4 145.4 182.0 178.4 159.5 7 chef 205.2 189.5 232.6 233.7 253.2 202.6 199.6 8 ferrariCutaway N/A N/A 9.9 10.2 N/A 26.6 13.3 9 harleyRed N/A N/A 13.5 13.8 N/A 30.9 15.8 C.3 Running times for compression of non-color-mapped images RUNNING TIMES FOR COMPRESSION AND DECOMPRESSION WITH LOCO, GZIP, COMPRESS, AND PNG [SECONDS OF CPU TIME] # image name /-------- LOCO modes -------\ gzip PNG sample line plane comp. dec. comp. dec. comp. dec. comp. dec. comp. dec. ------------------------------------------------------------------------------- 1 womanCmpnd 78.4 80.1 57.2 67.9 46.4 51.1 65.2 11.2 161.4 44.7 2 cafeCmpnd 75.9 77.2 55.9 66.2 45.4 49.5 61.2 10.8 136.1 46.4 3 toolsCmpnd 36.4 36.8 33.4 41.1 22.5 24.1 39.0 6.7 94.4 40.7 4 text 7.7 7.4 16.6 22.6 5.6 5.4 24.7 3.3 mapped 5 textColor 8.0 7.8 16.1 22.2 5.4 5.0 20.7 3.3 mapped 6 face 5.4 5.0 13.1 18.2 3.3 2.8 16.6 3.0 mapped 7 chef 6.6 6.2 18.2 25.3 3.9 3.0 25.7 4.4 mapped 8 ferrariCutaway 22.1 22.3 23.8 30.3 13.3 13.8 24.2 3.7 75.8 37.8 9 harleyRed 25.3 25.5 28.3 36.6 15.0 15.6 27.6 4.7 93.4 49.1 # image name /--- compress, bits per dictionary entry ----\ 9 10 11 12 comp. dec. comp. dec. comp. dec. comp. dec. ------------------------------------------------------------------------------- 1 womanCmpnd 43.2 30.0 40.9 28.0 38.3 29.4 35.3 23.2 2 cafeCmpnd 42.5 29.5 40.6 27.6 38.5 25.3 36.8 23.5 3 toolsCmpnd 26.5 17.7 24.5 16.5 23.8 15.5 21.9 14.3 4 text 11.3 7.1 10.3 7.0 9.9 7.0 9.8 6.9 5 textColor 12.3 7.5 10.6 7.3 10.0 7.2 10.3 7.1 6 face 12.8 8.6 9.4 6.4 8.9 6.3 9.1 6.2 7 chef 16.4 10.1 13.2 8.9 12.1 8.7 12.6 8.5 8 ferrariCutaway 28.3 19.4 21.9 13.7 17.2 10.3 14.7 9.3 9 harleyRed 29.5 19.0 24.1 15.1 20.3 12.4 17.8 11.3 # image name /--- compress, bits per dictionary entry ----\ 13 14 15 16 comp. dec. comp. dec. comp. dec. comp. dec. ------------------------------------------------------------------------------- 1 womanCmpnd 34.2 22.1 31.7 20.0 30.5 19.6 34.8 18.0 2 cafeCmpnd 36.2 22.6 33.5 21.5 32.5 20.6 37.9 19.5 3 toolsCmpnd 21.5 14.0 20.3 13.4 20.1 13.1 23.0 13.8 4 text 10.1 7.0 10.0 7.0 10.2 7.2 10.8 7.4 5 textColor 10.3 7.1 10.0 7.1 10.2 7.2 11.5 7.3 6 face 9.6 6.1 10.9 6.1 11.2 6.2 15.2 6.6 7 chef 13.1 8.7 13.6 8.8 14.1 9.0 15.8 9.2 8 ferrariCutaway 13.1 8.6 12.5 8.3 12.9 8.4 16.2 8.4 9 harleyRed 16.1 10.7 15.4 10.2 15.9 10.3 18.6 10.2 C.4 Running times for compression of color-mapped images RUNNING TIMES [CPU SECONDS] # image name PNG GIF comp. dec. comp. dec. ------------------------------------------------------------------------------- 4 text 56.8 17.8 32.4 17.0 5 textColor 39.4 23.8 32.4 17.0 6 face 35.7 20.4 28.4 14.7 7 chef 52.2 29.3 41.3 21.2 -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 10 17:34:27 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id RAA04719 for ; Fri, 10 Oct 1997 17:34:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA19165 for png-list-outgoing; Fri, 10 Oct 1997 17:26:41 -0500 Received: from mercury.colossus.net ([207.33.41.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA19159 for ; Fri, 10 Oct 1997 17:26:36 -0500 Received: by mercury.colossus.net id PAA06816 for png-list@dworkin.wustl.edu..passed.censor; Fri, 10 Oct 1997 15:20:58 -0700 X-Authentication-Warning: mercury.colossus.net: lcrocker set sender to lcrocker@piclab.com using -f Received: by mercury.colossus.net id PAA06808 for png-list@dworkin.wustl.edu; Fri, 10 Oct 1997 15:20:55 -0700 Message-Id: <199710102220.PAA06808@mercury.colossus.net> Subject: Re: PNG and JPEG-LS To: png-list@dworkin.wustl.edu Date: Fri, 10 Oct 1997 15:20:55 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: from "Theodore Goodman" at Oct 10, 97 02:41:38 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > However, the story is different with text-only images and computer > graphics. LZ77 performed quite well on complex computer graphics > which had thousands of colors; PNG also did quite well, even though it > could not run in indexed-color mode; both compressed these images far > more than JPEG-LS did. I don't understand what you mean by "could not run in indexed-color mode". Do you mean that your PNG software did not support that mode, and if so, why not? > JPEG-LS can also take advantage of color mapping: convert an input image > into a mapped image + color palette, then compress the mapped image > with JPEG-LS (or gzip, or another compressor). JPEG-LS compressed one > of the simple graphic images, "chef", better using color mapping than > PNG did. Again, I don't understand the comparison here. Is it to a colormapped PNG or not? If so, were the compression and filtering settings of PNG optimal for the image? Please provide more details; without such rigor, a simple comparison of the output of two programs only displays the functionality of those two programs, not the potential of the underlying technology. > Lee, could you clarify what you mean when you write that PNG has a "much > higher fidelity of data"? Alpha channel, gamma correction, 16-bit samples, physical size info, colorimetry info, other extensions. Whatever you wanted to know about the source image, PNG can tell you. I think only TIFF surpasses PNG in that regard. SPIFF has some of those features now, too. > [sample set] All of these images are very large. Most images transmitted over the web are much smaller and have fewer colors; you might include a more diverse sample set for a better comparison. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 10 18:38:00 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id SAA05113 for ; Fri, 10 Oct 1997 18:38:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA20025 for png-list-outgoing; Fri, 10 Oct 1997 18:14:14 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA20020 for ; Fri, 10 Oct 1997 18:14:09 -0500 Received: by NetGSI.com (8.7.5/-A/UX-AMR-1.0) id TAA26581; Fri, 10 Oct 1997 19:08:30 -0400 Message-Id: <1.5.4.32.19971010230658.006bd0e0@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Oct 1997 19:06:58 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG and JPEG-LS Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 03:20 PM 10/10/97 -0700, Lee wrote: >[Theodore wrote:] >> However, the story is different with text-only images and computer >> graphics. LZ77 performed quite well on complex computer graphics >> which had thousands of colors; PNG also did quite well, even though it >> could not run in indexed-color mode; both compressed these images far >> more than JPEG-LS did. > >I don't understand what you mean by "could not run in indexed-color >mode". Do you mean that your PNG software did not support that mode, >and if so, why not? Evidently he meant that since there were more than 256 colors he couldn't use indexed-color PNGs. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 10:08:38 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id KAA08333 for ; Tue, 14 Oct 1997 10:08:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA10877 for png-list-outgoing; Tue, 14 Oct 1997 10:01:53 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10868 for ; Tue, 14 Oct 1997 10:01:47 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id HAA00129; Tue, 14 Oct 1997 07:54:31 -0700 (PDT) Date: Tue, 14 Oct 1997 07:54:31 -0700 (PDT) Message-Id: <199710141454.HAA00129@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: IE 4.0 still hosed, sigh From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Well, I had really expected to be able to update my IE 4.0 PNG entry in *some* respect, but unfortunately the release still has all the same bugs as the betas. In particular: - full RGBA: nice job, but composes against a gray background, not the actual page background - RGBA-palette: atrocious--uses binary transparency and sets the threshold at 254, apparently - OBJECT support: still bogus--picks native JPEG or GIF instead of native PNG, even when the OBJECT PNG is the outermost one; still gives doubled images (one red X, one "real" but with scroll bars(??)) All of these problems are painfully obvious on my "miscellaneous PNGs" page, http://www.wco.com/~png/pngs.html . The large RGBA-palette snakes image damn near disappears due to the threshold problem... In addition, it appears that even some simple binary-transparency palette images get a gray background in some cases, even though the IE default is white; this shows up in the NeXT icons on my copy of the PngSuite page (pngsuite.html), which has no explicit background color. I haven't yet observed progressive display of Adam7 images, but that may be included. If someone does a definitive test, please let me know. Sigh... Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 12:14:15 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id MAA09581 for ; Tue, 14 Oct 1997 12:14:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA12712 for png-list-outgoing; Tue, 14 Oct 1997 12:09:02 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA12706 for ; Tue, 14 Oct 1997 12:08:57 -0500 Received: by grommit.inria.fr (8.8.6/8.8.5) id TAA02110 for png-list@dworkin.wustl.edu; Tue, 14 Oct 1997 19:02:52 +0200 (MET) Date: Tue, 14 Oct 1997 19:02:52 +0200 (MET) From: Chris Lilley Message-Id: <9710141902.ZM2108@grommit.inria.fr> In-Reply-To: Greg Roelofs "IE 4.0 still hosed, sigh" (Oct 14, 7:54am) References: <199710141454.HAA00129@shell.wco.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: PNG List Subject: Re: IE 4.0 still hosed, sigh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Oct 14, 7:54am, Greg Roelofs wrote: > I haven't yet observed progressive display of Adam7 images, but that may > be included. If someone does a definitive test, please let me know. They appear to work (replicating method). I don't have a slow server to test if it displays all the passes -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 14:51:10 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id OAA11100 for ; Tue, 14 Oct 1997 14:51:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA14694 for png-list-outgoing; Tue, 14 Oct 1997 14:40:58 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA14689 for ; Tue, 14 Oct 1997 14:40:54 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id MAA25718 for ; Tue, 14 Oct 1997 12:34:50 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Tue, 14 Oct 1997 12:34:49 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Re: PNG and JPEG-LS In-Reply-To: <199710102220.PAA06808@mercury.colossus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Theodore Goodman wrote: > > However, the story is different with text-only images and computer > > graphics. LZ77 performed quite well on complex computer graphics > > which had thousands of colors; PNG also did quite well, even though it > > could not run in indexed-color mode; both compressed these images far > > more than JPEG-LS did. On Fri, 10 Oct 1997, Lee Daniel Crocker responded: > I don't understand what you mean by "could not run in indexed-color > mode". Do you mean that your PNG software did not support that mode, > and if so, why not? In the lines that Lee Daniel Crocker quoted from my original message, I referred to complex graphics which had thousands of colors. (See also the detailed description of the images in my original message, giving the exact numbers of colors.) The PNG format does not support indexed color modes with more than 256 colors; the largest palette in PNG has 8 bits. So it is not possible to compress these images losslessly with PNG using color palettes. Theodore Goodman wrote: > > JPEG-LS can also take advantage of color mapping: convert an input image > > into a mapped image + color palette, then compress the mapped image > > with JPEG-LS (or gzip, or another compressor). JPEG-LS compressed one > > of the simple graphic images, "chef", better using color mapping than > > PNG did. Lee Daniel Crocker responded: > Again, I don't understand the comparison here. Is it to a colormapped > PNG or not? If so, were the compression and filtering settings of PNG > optimal for the image? The comparison was to a color-mapped PNG image. In my original message (part C.2, "Compression ratios for color-mapped images"), I gave a table of compression ratios produced by color-mapped PNG and other color-mapped compression schemes. There you will find, for example, that color-mapped PNG compressed the "chef" image to a ratio of 205, whereas color-mapped JPEG-LS achieved a ratio of 253. On the other hand, PNG outperformed the other schemes on other images. The PNG settings I used for compression and filtering are given in my original message (part B.2 "Software"), where I wrote that I used compression setting 7 in the pnmtopng software, and adaptive filtering. (Note that the 1-bit grayscale image "text", and all of the color-mapped images used only filter type 0, which is the default filter for color-mapped images in the pnmtopng software.) Lee Daniel Crocker wrote: > All of these images are very large. Most images transmitted over > the web are much smaller and have fewer colors; you might include a > more diverse sample set for a better comparison. As Lee Crocker points out, I did not analyzing WWW graphics. I am focusing on high-resolution images. Both PNG and all of the other compression schemes I examined are flexible enough to be used with a variety of imagery, ranging from low-resolution web graphics to high-resolution images for high-quality printing. This is not to dismiss the importance of screen-resolution imagery for the web. But we have seen low-resolution images examined extensively on this list and elsewhere. For example, on HP's web site you can find a comparison between PNG and JPEG-LS (http://www.hpl.hp.com/loco/), using the Lossless JPEG image test set which includes some high-resolution images and plenty of low-resolution images. John Bowler recently posted compression ratios for several images, including lots of screen-resolution images such as "lena" and "peppers" (which have dimensions 512 x 512) and a few bigger images. My contribution is to examine compound imagery, text, and simple graphics, and highly complex graphics, all at high resolutions. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 15:32:36 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id PAA11646 for ; Tue, 14 Oct 1997 15:32:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA15297 for png-list-outgoing; Tue, 14 Oct 1997 15:24:15 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA15292 for ; Tue, 14 Oct 1997 15:24:10 -0500 Received: by grommit.inria.fr (8.8.6/8.8.5) id WAA02506 for png-list@dworkin.wustl.edu; Tue, 14 Oct 1997 22:18:14 +0200 (MET) Date: Tue, 14 Oct 1997 22:18:14 +0200 (MET) From: Chris Lilley Message-Id: <9710142218.ZM2504@grommit.inria.fr> In-Reply-To: Theodore Goodman "Re: PNG and JPEG-LS" (Oct 14, 12:34pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: PNG List Subject: Re: PNG and JPEG-LS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Oct 14, 12:34pm, Theodore Goodman wrote: > The PNG settings I used for compression and filtering are given in my > original message (part B.2 "Software"), where I wrote that I used > compression setting 7 in the pnmtopng software, I find it odd that you did not use compression level 9, if the intent was to compare what each method could acheive. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 16:57:45 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id QAA12568 for ; Tue, 14 Oct 1997 16:57:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA16049 for png-list-outgoing; Tue, 14 Oct 1997 16:30:45 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA16023 for ; Tue, 14 Oct 1997 16:30:39 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id OAA26209 for ; Tue, 14 Oct 1997 14:24:45 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Tue, 14 Oct 1997 14:24:44 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Re: PNG and JPEG-LS In-Reply-To: <9710142218.ZM2504@grommit.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Tue, 14 Oct 1997, Chris Lilley wrote: > I find it odd that you did not use compression level 9, if the intent was to > compare what each method could acheive. The comparison included both the compression ratios and the running times for each compression system. While a higher compression setting in PNG can produce a bit more compression, it would also take more time to run. If anything, it would be nice to see the PNG converters running faster. (I am working on a message to ask folks on the PNG list about some speed issues.) -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 17:19:23 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id RAA13019 for ; Tue, 14 Oct 1997 17:19:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA16788 for png-list-outgoing; Tue, 14 Oct 1997 17:20:55 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA16783 for ; Tue, 14 Oct 1997 17:20:51 -0500 Received: by grommit.inria.fr (8.8.6/8.8.5) id AAA03189 for png-list@dworkin.wustl.edu; Wed, 15 Oct 1997 00:14:56 +0200 (MET) Date: Wed, 15 Oct 1997 00:14:56 +0200 (MET) From: Chris Lilley Message-Id: <9710150014.ZM3187@grommit.inria.fr> In-Reply-To: Theodore Goodman "Re: PNG and JPEG-LS" (Oct 14, 2:24pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: PNG List Subject: Re: PNG and JPEG-LS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Oct 14, 2:24pm, Theodore Goodman wrote: > On Tue, 14 Oct 1997, Chris Lilley wrote: > > > I find it odd that you did not use compression level 9, if the intent was to > > compare what each method could acheive. > > The comparison included both the compression ratios and the running times > for each compression system. While a higher compression setting in PNG > can produce a bit more compression, it would also take more time to run. Yes. The compression in PNG is deliberately asymmetric, because images on the W3b are written once and read millions of times. > If anything, it would be nice to see the PNG converters running faster. It would, but not at the expense of compression efficiency. > (I am working on a message to ask folks on the PNG list about some speed > issues.) Making things faster at the same compression is always interesting, though such optimisations may not be portable. That is part of ther value that implementors can add. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 17:59:08 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id RAA13292 for ; Tue, 14 Oct 1997 17:59:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA17218 for png-list-outgoing; Tue, 14 Oct 1997 18:00:13 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA17213 for ; Tue, 14 Oct 1997 18:00:09 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id PAA26803 for ; Tue, 14 Oct 1997 15:54:12 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Tue, 14 Oct 1997 15:54:11 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: PNG conversion speed/optimization Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The man pages for pnmtopng and pngtopnm indicate that the programs could be much faster with a bit of code optimizing. What optimizing could be done to speed up the converters? Would anyone familiar with the code be willing to hazard an estimate of the speed increase possible with a bit of code tuning? One possible optimization for the PNG library occurs to me. I don't know whether this is valid, but it has to do with the application of gamma when none is specified in the PNG file. If a PNG file does not contain a gamma value, does no gamma calculation occur, or is the gamma assumed to be 1.0 and the graylevels get raised to the power 1.0 (ie, an unnecessary floating point operation for each sample)? -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 18:01:35 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id SAA13318 for ; Tue, 14 Oct 1997 18:01:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA17172 for png-list-outgoing; Tue, 14 Oct 1997 17:55:39 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA17167 for ; Tue, 14 Oct 1997 17:55:33 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id PAA26765 for ; Tue, 14 Oct 1997 15:49:38 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Tue, 14 Oct 1997 15:49:38 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Palettes in pnmtopng Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In pnmtopng, how are color maps ordered? I took a brief look at the palettes produced for a few images and did not notice any obvious patterns in their ordering. I would like to try using palettes that I have generated separately, which may lend themselves to the use of filtering. Currently, pnmtopng defaults to filter type 0 with color-mapped images. Does anyone have suggestions regarding how to modify pnmtopng to use specified palettes for generating PNG files? -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 18:27:58 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id SAA13503 for ; Tue, 14 Oct 1997 18:27:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA17423 for png-list-outgoing; Tue, 14 Oct 1997 18:17:41 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA17418 for ; Tue, 14 Oct 1997 18:17:38 -0500 Received: by grommit.inria.fr (8.8.6/8.8.5) id BAA03309 for png-list@dworkin.wustl.edu; Wed, 15 Oct 1997 01:11:43 +0200 (MET) Date: Wed, 15 Oct 1997 01:11:43 +0200 (MET) From: Chris Lilley Message-Id: <9710150111.ZM3307@grommit.inria.fr> In-Reply-To: Theodore Goodman "Palettes in pnmtopng" (Oct 14, 3:49pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: PNG List Subject: Re: Palettes in pnmtopng Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Oct 14, 3:49pm, Theodore Goodman wrote: > I would like to try using palettes that I have generated separately, > which may lend themselves to the use of filtering. Currently, > pnmtopng defaults to filter type 0 with color-mapped images. Does > anyone have suggestions regarding how to modify pnmtopng to use > specified palettes for generating PNG files? It's an option on ppmquant, you can point to any other image that has the right palette and get quantised to that palette rather than an adaptive one. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 18:38:28 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id SAA13578 for ; Tue, 14 Oct 1997 18:38:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA17569 for png-list-outgoing; Tue, 14 Oct 1997 18:35:24 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA17564 for ; Tue, 14 Oct 1997 18:35:21 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA14316; Tue, 14 Oct 1997 17:29:21 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199710142329.RAA14316@enel.ucalgary.ca> Subject: Re: PNG conversion speed/optimization To: png-list@dworkin.wustl.edu Date: Tue, 14 Oct 1997 17:29:21 -0600 (MDT) In-Reply-To: from "Theodore Goodman" at Oct 14, 97 03:54:11 pm X-Mailer: ELM [version 2.4 PL25-U] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Theodore writes: > The man pages for pnmtopng and pngtopnm indicate that the programs > could be much faster with a bit of code optimizing. What optimizing > could be done to speed up the converters? Would anyone familiar with > the code be willing to hazard an estimate of the speed increase > possible with a bit of code tuning? In the more recent libpng versions (0.95 maybe, and 0.96), there is some optimization done in the filter selection code so that a filter is discarded if it is already worse than the current best filter. There is also experimental "filter weighting" which will aid in the selection of filters based on how long it takes for DECODING that filter. This is obviously important for WWW graphics. I have never seen any quantatative work on how these optimizations speed up encoding and decoding of images. I don't think any serious profiling of libpng itself has been done, but I know that most of the encoding time is inside zlib, and not libpng. I also know that from previous tests of libpng/zlib, that the optimal time/size tradeoff is at zlib compression level 6. For many images there is a small increase in compression at higher levels, but usually at a large increase in compression time. In some instances, compression level 9 actually resulted in reduced compression, because more bits are spent looking for distant matches, and this ends up reducing the overall compression. > One possible optimization for the PNG library occurs to me. I don't know > whether this is valid, but it has to do with the application of gamma when > none is specified in the PNG file. If a PNG file does not contain a gamma > value, does no gamma calculation occur, or is the gamma assumed to be 1.0 > and the graylevels get raised to the power 1.0 (ie, an unnecessary > floating point operation for each sample)? The libpng code currently assumes that for images where PNG gamma * screen gamma within 5% of 1.0, we will not do gamma correction. This avoids needless loss on the image where people use gammas of 2.2 and 0.45 (or their reciprocals) for gamma values without enough precision. Cheers, Andreas (still looking for a replacement maintainer of libpng) -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 20:08:29 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id UAA13941 for ; Tue, 14 Oct 1997 20:08:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA18748 for png-list-outgoing; Tue, 14 Oct 1997 20:10:18 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA18739 for ; Tue, 14 Oct 1997 20:10:15 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA20827; Tue, 14 Oct 1997 21:04:19 -0400 Message-Id: <1.5.4.32.19971015010247.006cb454@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Oct 1997 21:02:47 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: Palettes in pnmtopng Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 03:49 PM 10/14/97 -0700, Theodore wrote: >I would like to try using palettes that I have generated separately, >which may lend themselves to the use of filtering. Currently, >pnmtopng defaults to filter type 0 with color-mapped images. Does >anyone have suggestions regarding how to modify pnmtopng to use >specified palettes for generating PNG files? I don't think it would be a good idea to modify pnmtopng that way, because quantization to another palette is a lossy operation. It would IMO be much better to do the lossy quantization separately, such as with the netpbm pnmquant program. pnmquant [options] < image.ppm | ppmtopng > image.png glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 20:15:37 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id UAA13989 for ; Tue, 14 Oct 1997 20:15:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA18669 for png-list-outgoing; Tue, 14 Oct 1997 20:02:25 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA18664 for ; Tue, 14 Oct 1997 20:02:22 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id UAA20464; Tue, 14 Oct 1997 20:56:21 -0400 Message-Id: <1.5.4.32.19971015005448.006c0a74@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Oct 1997 20:54:48 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG conversion speed/optimization Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 05:29 PM 10/14/97 -0600, you wrote: >Theodore writes: > >> One possible optimization for the PNG library occurs to me. I don't know >> whether this is valid, but it has to do with the application of gamma when >> none is specified in the PNG file. If a PNG file does not contain a gamma >> value, does no gamma calculation occur, or is the gamma assumed to be 1.0 >> and the graylevels get raised to the power 1.0 (ie, an unnecessary >> floating point operation for each sample)? The behavior is undefined by the spec and decoders are free to do what they want. The least expensive choice is to simply dump the raw RGB data to the display. > >The libpng code currently assumes that for images where PNG gamma * screen >gamma within 5% of 1.0, we will not do gamma correction. This avoids >needless loss on the image where people use gammas of 2.2 and 0.45 (or >their reciprocals) for gamma values without enough precision. It wouldn't be "a floating point operation for each sample" would it? Doesn't libpng build a lookup table? That's how it's done in ARL viewpng (which also skips building a gamma correction table when file_gamma is unknown and when file_gamma * viewing_gamma is close to 1.0) Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 23:25:42 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id XAA14997 for ; Tue, 14 Oct 1997 23:25:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA20858 for png-list-outgoing; Tue, 14 Oct 1997 23:19:58 -0500 Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA20853 for ; Tue, 14 Oct 1997 23:19:45 -0500 Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id XAA13518; Tue, 14 Oct 1997 23:13:42 -0500 (CDT) Received: from sjc-ca6-02.ix.netcom.com(207.94.249.194) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma013503; Tue Oct 14 23:13:32 1997 Received: by CORUISK with Microsoft Mail id <01BCD8E6.06B823A0@CORUISK>; Tue, 14 Oct 1997 21:13:32 -0700 Message-ID: <01BCD8E6.06B823A0@CORUISK> From: John Bowler To: "'PNG List'" , "'Theodore Goodman'" Subject: RE: Palettes in pnmtopng Date: Tue, 14 Oct 1997 20:49:21 -0700 Encoding: 34 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >In pnmtopng, how are color maps ordered? I took a brief look at the >palettes produced for a few images and did not notice any obvious >patterns in their ordering. I believe the standard PPM technique is to build a table by scanning the bitmap - so the order of entries in the palette is some function of the order in the image. Using PPM is a bad way of doing this experiment - much better to use PGM (i.e. grey levels) and ignore the palette. I.e. you produce a "grey scale" bitmap which is really just the indices of the palette entries then compress that. This way you get useful size figures and control exactly what order the "palette entries" are in (you don't get useful images, but the point is to work out how PNG behaves when the palette is carefully controlled, not to actually implement something which does this...) >I would like to try using palettes that I have generated separately, >which may lend themselves to the use of filtering. Currently, >pnmtopng defaults to filter type 0 with color-mapped images. Does >anyone have suggestions regarding how to modify pnmtopng to use >specified palettes for generating PNG files? I did try a simple bigram sorting of the palette at one time. I didn't see any significant improvement, however I also believe that I failed to force libpng to use the filters (i.e. force the "sub" filter) so my experiment was somewhat broken. If you want to do this the trick is to drive libpng directly by some program which allows precise control over what happens. If you do that you *can* use PNG for palette images with >256 colors (up to 65536) by using color type 0 explicitly. Of course the palette has to be stored elsewhere but, for an embedded use of PNG (where the data never escapes from the system) this is perfectly OK. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 23:27:33 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id XAA15017 for ; Tue, 14 Oct 1997 23:27:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA20871 for png-list-outgoing; Tue, 14 Oct 1997 23:21:03 -0500 Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA20866 for ; Tue, 14 Oct 1997 23:20:57 -0500 Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id XAA22439; Tue, 14 Oct 1997 23:14:56 -0500 (CDT) Received: from sjc-ca6-02.ix.netcom.com(207.94.249.194) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma022361; Tue Oct 14 23:13:38 1997 Received: by CORUISK with Microsoft Mail id <01BCD8E6.0AF9C4F0@CORUISK>; Tue, 14 Oct 1997 21:13:39 -0700 Message-ID: <01BCD8E6.0AF9C4F0@CORUISK> From: John Bowler To: "'PNG List'" , "'Theodore Goodman'" Subject: RE: PNG conversion speed/optimization Date: Tue, 14 Oct 1997 21:13:22 -0700 Encoding: 70 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List From: Andreas Dilger [SMTP:adilger@enel.ucalgary.ca] >I don't think any serious profiling of libpng itself has been done, but >I know that most of the encoding time is inside zlib, and not libpng. Of course serious profiling has been done :) It's just that those of us who have done it aren't necessarily in a position to release the results... Anyway, the basic statement "most of the encoding time is in zlib" is fundamentally correct - _tr_tally if I remember correctly. This reflects compression level 6 and a set of images which tend to favour palette mapped ones - and this means that the effect of the adaptive filtering is not necessarily taken into account as much as it should be. The filtering *does* appear on the profile some times. In particular photographic images tend to end up using Paeth and tend to be relatively uncompressible (see my previous figures). Uncompressible images take proportionally less time in Zlib - even at higher compression levels. The Paeth filter also hits the performance in the decoder - again zlib still predominates, but an image with a lot of Paeth starts to show decoder peaks in the unfiltering code. That code can be speeded up, but as with all optimisations the speed up is not portable - there are very different balances between register use and the cost of memory access on different machines. >I also know that from previous tests of libpng/zlib, that the optimal >time/size tradeoff is at zlib compression level 6. I've seen the bug reports which say things like "this reduction in performance is totally unacceptable". The world contains a whole lot of people who need to compress very fast, even if it costs space, PNG works for those people too, but the compromises are different. The optimum is a function of both the input data and the system in which PNG is used - so a discussion which places as high an emphasis on speed as either Theodore's or the HP paper does, I feel, require a different compromise. (Z_BEST_S PEED - compression level 1 - at least.) >Theodore writes: >> One possible optimization for the PNG library occurs to me. I don't know >> whether this is valid, but it has to do with the application of gamma when >> none is specified in the PNG file. If a PNG file does not contain a gamma >> value, does no gamma calculation occur, or is the gamma assumed to be 1.0 >> and the graylevels get raised to the power 1.0 (ie, an unnecessary >> floating point operation for each sample)? > >The libpng code currently assumes that for images where PNG gamma * screen >gamma within 5% of 1.0, we will not do gamma correction. This avoids >needless loss on the image where people use gammas of 2.2 and 0.45 (or >their reciprocals) for gamma values without enough precision. I don't think gamma correction is an issue here - the pnmtopng code is not, so far as I know, doing any such correction and, as Glenn points out, the LUT implementation which everyone uses costs a memory access, no more. That *is* significant in many applications, but there are lots of other memory accesses in libpng which can be eliminated by reducing the generality of the code. Because the compression code is separate (Zlib) it looks like some (many?) people doing commercial implementations are actually using their own PNG implementation layer on top of Zlib. libpng is clearly more general than most people need - it has to be general to meet the requirements of as many people as possible (the feature trap - you add things which only 5% of the users use because the total of those 5%'s is >50% of the users). For that reason putting libpng into an experiment which includes speed has to be done very carefully - certainly "prof" or vtune or something like it should be used to ensure that significant time is *not* being spent inside libpng. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 23:46:51 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id XAA15223 for ; Tue, 14 Oct 1997 23:46:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA21116 for png-list-outgoing; Tue, 14 Oct 1997 23:43:40 -0500 Received: from gntcompaq.gintic.ntu.ac.sg (gntcompaq.gintic.gov.sg [155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id XAA21111 for ; Tue, 14 Oct 1997 23:43:36 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BCD967.2A3EAA20@gntcompaq.gintic.ntu.ac.sg>; Wed, 15 Oct 1997 12:37:57 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: IE 4.0 still hosed, sigh Date: Wed, 15 Oct 1997 12:37:55 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris wrote: > >I don't have a slow server to test if it displays > all the passes > Try the PngSuite in Singapore. From Europe, via the USA to the far east, it must be slow enough :-) Pick your time, because any hour of the day it is somewhere on the world between 9 and 5. http://mht3.gintic.gov.sg:8000/pngsuite/pngsuite.html and for a larger interlaced image: http://mht3.gintic.gov.sg:8000/pingpong/pingpong_logo.html >Willem -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 23:51:16 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id XAA15245 for ; Tue, 14 Oct 1997 23:51:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA21161 for png-list-outgoing; Tue, 14 Oct 1997 23:48:38 -0500 Received: from gntcompaq.gintic.ntu.ac.sg (gntcompaq.gintic.gov.sg [155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id XAA21156 for ; Tue, 14 Oct 1997 23:48:35 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BCD967.DE9050F0@gntcompaq.gintic.ntu.ac.sg>; Wed, 15 Oct 1997 12:42:59 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: PNG conversion speed/optimization Date: Wed, 15 Oct 1997 12:42:58 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Theodore wrote: >The man pages for pnmtopng and pngtopnm indicate that the programs >could be much faster with a bit of code optimizing. What optimizing >could be done to speed up the converters? Would anyone familiar with >the code be willing to hazard an estimate of the speed increase >possible with a bit of code tuning? The remark of optimization is already a very old one put in by Alex, where I don't know what points he was thinking off. So maybe I better take that remark out of the man-pages, which doesn't mean that all suggestions for optimization welcome. I personally don't see that many corners to be cut without at the same time losing functionality. Willem -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 14 23:53:44 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id XAA15265 for ; Tue, 14 Oct 1997 23:53:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA21245 for png-list-outgoing; Tue, 14 Oct 1997 23:53:57 -0500 Received: from gntcompaq.gintic.ntu.ac.sg (gntcompaq.gintic.gov.sg [155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id XAA21240 for ; Tue, 14 Oct 1997 23:53:52 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BCD968.9BCCD5D0@gntcompaq.gintic.ntu.ac.sg>; Wed, 15 Oct 1997 12:48:17 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: Palettes in pnmtopng Date: Wed, 15 Oct 1997 12:48:15 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Theodore wrote: >In pnmtopng, how are color maps ordered? I took a brief look at the >palettes produced for a few images and did not notice any obvious >patterns in their ordering. This is out of my head, but I think we 100% relied on how the pnm libraries are building the palettes. >I would like to try using palettes that I have generated separately, >which may lend themselves to the use of filtering. Currently, >pnmtopng defaults to filter type 0 with color-mapped images. Does >anyone have suggestions regarding how to modify pnmtopng to use >specified palettes for generating PNG files? The current way is that you image should be preprocessed such that it contains the right (number of) colors for the palette building. The ordering of the palette, resp. the use of an external palette should not be that difficult to tackle, but before I would include it, I would like to see some proof of better performance. Pnmtopng has by now become quiet complex, so adding features should really bring benefits. Remind, it is a generic tool. Willem -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Oct 15 00:41:30 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id AAA15531 for ; Wed, 15 Oct 1997 00:41:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA21955 for png-list-outgoing; Wed, 15 Oct 1997 00:42:06 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA21950 for ; Wed, 15 Oct 1997 00:42:02 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id WAA25799; Tue, 14 Oct 1997 22:36:05 -0700 (PDT) Date: Tue, 14 Oct 1997 22:36:05 -0700 (PDT) Message-Id: <199710150536.WAA25799@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: RE: Palettes in pnmtopng From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >>In pnmtopng, how are color maps ordered? I took a brief look at the >>palettes produced for a few images and did not notice any obvious >>patterns in their ordering. > This is out of my head, but I think we 100% relied on how the pnm > libraries are building the palettes. I'm pretty sure that's true, too. I added some code to reorder RGBA palettes so that there were no unnecessary "A" entries, but I think you chose to leave that out of the latest release. > The current way is that you image should be preprocessed such that > it contains the right (number of) colors for the palette building. The > ordering > of the palette, resp. the use of an external palette should not be that > difficult to tackle, but before I would include it, I would like to see > some > proof of better performance. Peter Deutsch claimed some improvements by ordering on the basis of the pairwise histogram (he actually tested GIF), but I never got around to reproducing his tests myself. I'm still quite curious about it... Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Oct 15 07:31:35 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id HAA18090 for ; Wed, 15 Oct 1997 07:31:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA25382 for png-list-outgoing; Wed, 15 Oct 1997 07:33:53 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA25377 for ; Wed, 15 Oct 1997 07:33:50 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA12324; Wed, 15 Oct 1997 08:27:51 -0400 Message-Id: <1.5.4.32.19971015122616.006bd398@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Oct 1997 08:26:16 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: RE: Palettes in pnmtopng Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 12:48 PM 10/15/97 +0800, Willem wrote: >Theodore wrote: > >>In pnmtopng, how are color maps ordered? > before I would include it, I would like to see some > proof of better performance. A couple of years ago I tried sorting the palette in descending order of frequency. It had no noticeable effect that I could detect. It may have improved the filtering somewhat for filter_types other than "none", but since filter_type "none" was best for indexed-color images it didn't help make the files smaller. But note that I didn't do extensive tests with this due to unpromising initial results. glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Oct 15 08:57:07 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id IAA19071 for ; Wed, 15 Oct 1997 08:57:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA25968 for png-list-outgoing; Wed, 15 Oct 1997 08:45:14 -0500 Received: from kukulkan.fri.uni-lj.si (kukulkan.fri.uni-lj.si [193.2.73.131]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA25962 for ; Wed, 15 Oct 1997 08:45:08 -0500 Received: (from aleksj@localhost) by kukulkan.fri.uni-lj.si (8.7.3/8.7.3) id OAA05289 for png-list@dworkin.wustl.edu; Wed, 15 Oct 1997 14:39:07 +0100 (MET) From: Alex Jakulin Message-Id: <199710151339.OAA05289@kukulkan.fri.uni-lj.si> Subject: RE: Palettes in pnmtopng To: png-list@dworkin.wustl.edu Date: Wed, 15 Oct 97 14:39:06 MET In-Reply-To: <1.5.4.32.19971015122616.006bd398@netgsi.com>; from "Glenn Randers-Pehrson" at Oct 15, 97 8:26 am Mailer: Elm [revision: 70.85] Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > >>In pnmtopng, how are color maps ordered? > > > before I would include it, I would like to see some > > proof of better performance. > > A couple of years ago I tried sorting the palette in > descending order of frequency. It had no noticeable > effect that I could detect. It may have improved the > filtering somewhat for filter_types other than "none", > but since filter_type "none" was best for indexed-color > images it didn't help make the files smaller. But > note that I didn't do extensive tests with this due to > unpromising initial results. Nasir Memon (who later coauthored CALIC with Wu) did some research on palette ordering with the old lossless JPEG. He claimed up to 20% improvements (if I remember correctly), and he was using simulated annealing which is too slow for practical use. His results were based on smooth photographic images. I'm not sure if any of that work found its way into CALIC. Peter Deutsch was sorting by pairwise occurrance frequency - the two colors that were most frequently next to another were put together in the palette, etc. Tom Lane suggested ordering by luminance. I was too experimenting with a more complex ordering algorithm (the details of which I have forgotten by now :), but it didn't make much difference with the non-smooth images I was testing it on. In all, one could get some extra compression by ordering an unordered palette, but this would only apply for smooth (photographic) images which are often better left in continuous RGB. Most sharp graphic images are often BETTER off nonfiltered. The PNG spec allows filtering on colormapped images, so there is some space for potential improvement, but all this ordering business would help JPEG-LS more than it would help PNG. Regards, Alex -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 17 14:35:00 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id OAA04083 for ; Fri, 17 Oct 1997 14:34:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA18639 for png-list-outgoing; Fri, 17 Oct 1997 14:30:08 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA18632 for ; Fri, 17 Oct 1997 14:30:02 -0500 Received: from infomail.infowatch.net (host-32-96-48-103.mia.bellsouth.net [32.96.48.103]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id PAA15849 for ; Fri, 17 Oct 1997 15:23:47 -0400 (EDT) X-Authentication-Warning: www10.w3.org: Host host-32-96-48-103.mia.bellsouth.net [32.96.48.103] claimed to be infomail.infowatch.net Received: from infomail.infowatch.net ([32.96.48.103]) by infomail.infowatch.net (Post.Office MTA v3.1 release PO205e ID# 0-0U10L2S100) with SMTP id BDK67 for ; Fri, 17 Oct 1997 03:25:34 -0400 To: png-group@w3.org From: info@infowatch.net (Info Desk) Subject: Advertisement: Website Hosting Date: Fri, 17 Oct 1997 03:25:34 -0400 Message-ID: <19971017071034231.BDK67@infomail.infowatch.net> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List portable network graphics, ------------------------------------------------------------------------ The following material may be of interest to you. If it isn't, we apologize for any inconvenience. ------------------------------------------------------------------------ http://www.infowatch.net InfoWatch would like to introduce our complete Hosting and Promotional service. FOR ONLY $29.95 PER MONTH ! * 30 MB (megabytes) of disk space * 1000 MB = 1 GB (gigabyte) of data transfer per month * 8 E-mail accounts * Access to your account anytime via the Web Control Panel * MS Front Page * Unlimited FTP updates * Personal CGI directory for your own scripts (or use ours) * Advanced web statistics analyzer program * E-mail forwarding, auto responders, and vacation reply * Domain name registration (www.yourname.com) * Register your domain with over 250 search engines - FREE! * Friendly customer support If for any reason you are not satisfied with InfoWatch's service after 30 days, we will transfer you back to your original host and pay any transfer fees. http://www.infowatch.net info@infowatch.net -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 19 13:20:09 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id NAA00875 for ; Sun, 19 Oct 1997 13:20:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA15734 for png-list-outgoing; Sun, 19 Oct 1997 13:22:07 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA15729 for ; Sun, 19 Oct 1997 13:22:03 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id LAA00706 for ; Sun, 19 Oct 1997 11:15:41 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Sun, 19 Oct 1997 11:15:40 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Question: -force in pnmtopng Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List What are the effects of using the -force option in the pnmtopng program? I am compressing PGM files of color indices, so I use -force to tell pnmtopng not to calculate new palettes. But I wonder what other effects the -force option has. The pnmtopng man page says it "limits the optimizations of pnmtopng", so I wonder what advantages I am losing by using this option. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 19 15:03:03 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id PAA03120 for ; Sun, 19 Oct 1997 15:03:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA16736 for png-list-outgoing; Sun, 19 Oct 1997 15:03:19 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA16731 for ; Sun, 19 Oct 1997 15:03:14 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id MAA01537 for ; Sun, 19 Oct 1997 12:56:45 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Sun, 19 Oct 1997 12:56:44 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Question: error in zlib / pngcheck Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List During one of my experiments, I ran pngcheck on a PNG file using the -vv option and got an error. I created the PNG file with the following command: pnmtopng -verbose -force -filter 3 -compression 4 foo.pgm The PNG file was about the size I expected it to be. When I ran pngcheck on it, the dump file looked okay. However, pngcheck put this on stderr: zlib: inflate (first loop) error = -5 I have run hundreds of other experiments using the same software without encountering any errors. What does the error mean? (I still have the PNG file if you want to try it.) Versions: - PNGcheck, version 1.98-grr3 of 21 June 1997 - zlib 1.0.4 patched - pnmtopng 2.36 - libpng 0.96 - Running on HP-UX 10.20 -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Oct 19 23:24:28 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id XAA16165 for ; Sun, 19 Oct 1997 23:24:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA21344 for png-list-outgoing; Sun, 19 Oct 1997 23:25:42 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA21339 for ; Sun, 19 Oct 1997 23:25:37 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id VAA04075; Sun, 19 Oct 1997 21:19:12 -0700 (PDT) Date: Sun, 19 Oct 1997 21:19:12 -0700 (PDT) Message-Id: <199710200419.VAA04075@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: Re: Question: error in zlib / pngcheck From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > The PNG file was about the size I expected it to be. When I ran pngcheck > on it, the dump file looked okay. However, pngcheck put this on stderr: > zlib: inflate (first loop) error = -5 It's entirely possible that I've still got a bug in the zlib part of pngcheck. I won't be able to look at this until after Halloween, but I'll do my best to track it down then. Assuming the PNG file isn't too big, you can either mail it to me or arrange to ftp it somewhere. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Oct 20 00:11:01 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id AAA17601 for ; Mon, 20 Oct 1997 00:11:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA21851 for png-list-outgoing; Mon, 20 Oct 1997 00:10:18 -0500 Received: from gntcompaq.gintic.ntu.ac.sg (gntcompaq.gintic.gov.sg [155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id AAA21823 for ; Mon, 20 Oct 1997 00:10:02 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BCDD58.82271070@gntcompaq.gintic.ntu.ac.sg>; Mon, 20 Oct 1997 13:03:06 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: Question: -force in pnmtopng Date: Mon, 20 Oct 1997 13:03:05 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List OK, roughly the following: - converting into palette - downscaling the number of colors - converting monochrome ppm's into grayscale - converting alpha mask to transparency index Willem ----- > Theodore wrote > >What are the effects of using the -force option in the pnmtopng >program? >I am compressing PGM files of color indices, so I use -force to tell >pnmtopng not to calculate new palettes. But I wonder what other >effects >the -force option has. The pnmtopng man page says it "limits the >optimizations of pnmtopng", so I wonder what advantages I am losing by >using this option. > > > > > >-- >Send the message body "help" to png-list-request@dworkin.wustl.edu > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Oct 20 12:55:21 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id MAA12692 for ; Mon, 20 Oct 1997 12:55:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA29177 for png-list-outgoing; Mon, 20 Oct 1997 12:41:20 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA29172 for ; Mon, 20 Oct 1997 12:41:16 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id KAA12289; Mon, 20 Oct 1997 10:34:47 -0700 (PDT) Date: Mon, 20 Oct 1997 10:34:47 -0700 (PDT) Message-Id: <199710201734.KAA12289@shell.wco.com> To: tbtf@fenris.imagiware.com Subject: Re: TBTF for 10/20/97: In a twist Cc: png-list@dworkin.wustl.edu From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > =2E.Followup: Alta Vista indexes more (again) > TBTF for 8/11/97 [16] noted that the Alta Vista service seemed to be > further limiting the number of pages it indexed (or, at any rate, re- > ported) for some Web sites, particularly smaller ones. I'm pleased > to note that the ceiling has now lifted. Well, for some, maybe. It would appear that they've simply shuffled the columns in their bookkeeping--when I checked my own URL in August (www.wco.com/~png/), about a dozen out of 73 showed up; today only one Linux-related page did. As a result, not one page of the Portable Network Graphics home site is indexed any more. So much for the W3C's very first Recommendation, eh? -- Greg Roelofs newt@pobox.com http://pobox.com/~newt/ Newtware, Info-ZIP, PNG Group, U Chicago, Philips Research, ... -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Oct 20 14:37:20 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id OAA16168 for ; Mon, 20 Oct 1997 14:37:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA01110 for png-list-outgoing; Mon, 20 Oct 1997 14:28:01 -0500 Received: from netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA01105 for ; Mon, 20 Oct 1997 14:27:57 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id PAA07801; Mon, 20 Oct 1997 15:21:28 -0400 Message-Id: <1.5.4.32.19971020191952.0067e664@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 1997 15:19:52 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: TBTF for 10/20/97: In a twist Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:34 AM 10/20/97 -0700, Greg wrote: >when I checked my own URL in August [with AltaVista] >(www.wco.com/~png/), about a dozen out of 73 showed up; today only one >Linux-related page did. Hotbot (www.hotbot.com) today indexes 28 pages at www.wco.com that contain the word "png". ..\glennrp -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Oct 20 14:59:36 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id OAA16933 for ; Mon, 20 Oct 1997 14:59:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA01490 for png-list-outgoing; Mon, 20 Oct 1997 14:58:36 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.10.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA01485 for ; Mon, 20 Oct 1997 14:58:33 -0500 Received: by grommit.inria.fr (8.8.6/8.8.5) id VAA23045 for png-list@dworkin.wustl.edu; Mon, 20 Oct 1997 21:52:04 +0200 (MET) Date: Mon, 20 Oct 1997 21:52:04 +0200 (MET) From: Chris Lilley Message-Id: <9710202152.ZM23043@grommit.inria.fr> In-Reply-To: Greg Roelofs "Re: TBTF for 10/20/97: In a twist" (Oct 20, 10:34am) References: <199710201734.KAA12289@shell.wco.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: PNG List Subject: Re: TBTF for 10/20/97: In a twist Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Oct 20, 10:34am, Greg Roelofs wrote: > Well, for some, maybe. It would appear that they've simply shuffled > the columns in their bookkeeping--when I checked my own URL in August > (www.wco.com/~png/), about a dozen out of 73 showed up; today only one > Linux-related page did. As a result, not one page of the Portable > Network Graphics home site is indexed any more. So much for the W3C's > very first Recommendation, eh? HotBot returned 23 pages which contain a link to http://www.wco.com/~png None of them actually *on* wco.com HotBot advanced search on PNG excluding "numismatics" and "papua" yielded 3588 hits -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 93 65 79 87 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Oct 20 16:22:36 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id QAA19794 for ; Mon, 20 Oct 1997 16:22:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA02746 for png-list-outgoing; Mon, 20 Oct 1997 16:08:25 -0500 Received: from shell.wco.com (shell.wco.com [199.4.94.16]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA02741 for ; Mon, 20 Oct 1997 16:08:21 -0500 Received: (from png@localhost) by shell.wco.com (8.8.5/8.8.5/WCO-18jul97) id OAA24183; Mon, 20 Oct 1997 14:01:51 -0700 (PDT) Date: Mon, 20 Oct 1997 14:01:51 -0700 (PDT) Message-Id: <199710202101.OAA24183@shell.wco.com> To: png-list@dworkin.wustl.edu Subject: Re: TBTF for 10/20/97: In a twist From: Greg Roelofs Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I should have included some context for png-list folks: the original news item in Tasty Bits from the Technology Front (TBTF, www.tbtf.com) noted that AltaVista was limiting the number of indexed URLs from any given domain, with negative consequences for folks from aol.com and the like (indeed, for nearly any site catering to personal web pages). Today's item noted that the restriction seems to have been lifted. Here's a chunk of today's article that I didn't quote the first time around, including the URL for the original report: site 8/97 10/97 -------------- ----- ------- fas.org 40 16035 epic.org 40 992 vtw.org 40 168 cdt.org 40 336 patents.com 40 452 polymer.com 40 74 polymers.com 40 332 pureatria.com 40 706 tbtf.com 40 519 internic.net 41 24601 privacy.org ~ 79 238 harvard.net ~ 616 731 eff.org ~ 911 28535 microsoft.com ~ 1854 111904 w3.org ~ 3905 185051 netscape.com ~ 4517 66630 sun.com ~ 4831 109931 geocities.com ~ 14427 358912 yahoo.com ~ 32582 2671157 stanford.edu ~ 49274 837292 aol.com ~ 78651 381923 [16] http://www.tbtf.com/archive/08-11-97.html#Tavs Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 00:35:16 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id AAA01115 for ; Tue, 21 Oct 1997 00:35:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA08654 for png-list-outgoing; Tue, 21 Oct 1997 00:31:29 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA08649 for ; Tue, 21 Oct 1997 00:31:25 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id WAA15655 for ; Mon, 20 Oct 1997 22:24:54 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Mon, 20 Oct 1997 22:24:54 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: pnmtopng/pngtopnm problem with 16-bit files Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I'm having trouble converting either to PNG from 16-bit PGM files in raw (P5) format. (In this format, each sample is represented by two bytes in the PGM file, as opposed to the P2 format which expresses the numerical value of each sample in base ten ASCII separated by spaces.) First few lines of original PGM file (after converting from P5 format to P2 format): P2 3306 1566 65535 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 First few lines of PGM file after pnmtopng operating on P2-format file, followed by pngtopnm: P2 3306 1566 65535 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 So pnmtopng doesn't like 16-bit P5 format. It would be nice to be able to use P5 format, though: the original of this file is 10.4 megabytes in P5 format, and 23.4 megabytes in P2 format. Is this a known bug? Is there a workaround? Versions: - zlib 1.0.4 patched - pnmtopng 2.36 - libpng 0.96 - Running on HP-UX 10.20 -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 00:52:11 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id AAA01479 for ; Tue, 21 Oct 1997 00:52:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA08772 for png-list-outgoing; Tue, 21 Oct 1997 00:50:05 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA08767 for ; Tue, 21 Oct 1997 00:50:02 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id WAA15744 for ; Mon, 20 Oct 1997 22:43:32 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Mon, 20 Oct 1997 22:43:32 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: pnmtopng - rescaling problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Compressing 8-bit PGM files, I ran into this bug. I have a couple of images that need at least 8 bits per pixel to represent them in PNG. For example, one image has 20 colors, with values 0 through 19. Another has 51 colors with values 0 through 50. In the PNM header, if I set maxval to 19 for the first image, then run pnmtopng on it using -force (no palettes), pnmtopng reports that it is rescaling the values, and I get a file of only zeros. The command I used was: pnmtopng -verbose -force -filter 2 -compression 3 foo.pgm > foo.png However, if I set maxval to 255, pnmtopng does not rescale the graylevels, and I also get a correct output file. That's the last bug for today! -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 00:54:42 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id AAA01530 for ; Tue, 21 Oct 1997 00:54:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA08809 for png-list-outgoing; Tue, 21 Oct 1997 00:55:34 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA08804 for ; Tue, 21 Oct 1997 00:55:31 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.8.5/8.6.9) with ESMTP id WAA15461 for ; Mon, 20 Oct 1997 22:48:59 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Oct 1997 22:49:58 -0800 To: PNG List From: Dave Martindale Subject: Re: pnmtopng/pngtopnm problem with 16-bit files Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 22:24 -0700 20/10/97, Theodore Goodman wrote: >I'm having trouble converting either to PNG from 16-bit PGM files in raw >(P5) format. (In this format, each sample is represented by two bytes in >the PGM file, as opposed to the P2 format which expresses the numerical >value of each sample in base ten ASCII separated by spaces.) The PBMPLUS and NETPBM packages simply do not support RAW format with a maxval greater than 255 (i.e. more than 1 byte per sample). I've extended my copy of NETPBM to handle 16-bit data, and I'm sure other people have done the same. Plus I've written code that directly reads and writes P5 format with 2-byte data values. It's not difficult, once you decide how to deal with byte order issues. But the fact remains that this is a non-standard extension. Worse, various PBMPLUS-based programs don't give an error message when they encounter a raw file with maxval >= 256, even though they cannot read the file correctly. Given this state of the world, it's not surprising that pnmtopng doesn't handle it correctly either. It *should* be fixed to complain that it can't handle the input file correctly. It's probably not that difficult to make it work "properly", but there is a problem in the definition of "properly": Since extensions to PBM to handle 2-byte raw values are essentially all "private hacks", there is no guarantee that my 16-bit P5 file looks like your 16-bit P5 file. All such files are non-portable. Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 04:52:03 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id EAA06686 for ; Tue, 21 Oct 1997 04:52:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA10624 for png-list-outgoing; Tue, 21 Oct 1997 04:41:51 -0500 Received: from gntcompaq.gintic.ntu.ac.sg (gntcompaq.gintic.gov.sg [155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id EAA10619 for ; Tue, 21 Oct 1997 04:41:47 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BCDE47.AD7A77E0@gntcompaq.gintic.ntu.ac.sg>; Tue, 21 Oct 1997 17:35:09 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: pnmtopng/pngtopnm problem with 16-bit files Date: Tue, 21 Oct 1997 17:35:07 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Theodore wrote: > >So pnmtopng doesn't like 16-bit P5 format. It would be nice to be >able to use P5 format, though: the original of this file is 10.4 >megabytes in P5 format, and 23.4 megabytes in P2 format. I will (in couple of weeks) have a look at this. It has probably to do with settings in pbm-lib (like BIGGRAYS, or something similar). Probably not a big problem to solve. Just slipped my tests. >Is this a known bug? Is there a workaround? > Yes there is a workaround: use P2 format :-) and 23Mb doesn't matter if you store the image in PNG format. Willem W i l l e m v a n S c h a i k --------------------------------------------------------------------- Gintic - NTU mailto:willem@gintic.gov.sg Singapore http://mht3.gintic.gov.sg:8000/wwwillem.html >---------- >From: Theodore Goodman[SMTP:tgoodman@cse.ucsc.edu] >Sent: Tuesday, 21 October, 1997 13:24 >To: PNG List >Subject: pnmtopng/pngtopnm problem with 16-bit files > >I'm having trouble converting either to PNG from 16-bit PGM files in >raw >(P5) format. (In this format, each sample is represented by two bytes >in >the PGM file, as opposed to the P2 format which expresses the numerical >value of each sample in base ten ASCII separated by spaces.) > >First few lines of original PGM file (after converting from P5 format >to >P2 format): >P2 >3306 1566 >65535 >2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 >2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 >2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 2639 > > >First few lines of PGM file after pnmtopng operating on P2-format file, > >followed by pngtopnm: >P2 >3306 1566 >65535 >10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 >79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 >10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 79 10 > >So pnmtopng doesn't like 16-bit P5 format. It would be nice to be >able to use P5 format, though: the original of this file is 10.4 >megabytes in P5 format, and 23.4 megabytes in P2 format. > >Is this a known bug? Is there a workaround? > >Versions: - zlib 1.0.4 patched > - pnmtopng 2.36 > - libpng 0.96 > - Running on HP-UX 10.20 > > > > >-- >Send the message body "help" to png-list-request@dworkin.wustl.edu > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 10:23:00 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id KAA15656 for ; Tue, 21 Oct 1997 10:23:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA13918 for png-list-outgoing; Tue, 21 Oct 1997 10:21:06 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA13909 for ; Tue, 21 Oct 1997 10:21:00 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA17935 for ; Tue, 21 Oct 1997 11:14:24 -0400 (EDT) To: PNG List Subject: Re: pnmtopng/pngtopnm problem with 16-bit files In-reply-to: Your message of Mon, 20 Oct 1997 22:49:58 -0800 Date: Tue, 21 Oct 1997 11:14:24 -0400 Message-ID: <17933.877446864@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave Martindale writes: > Since extensions to PBM to handle 2-byte raw values are essentially > all "private hacks", there is no guarantee that my 16-bit P5 file > looks like your 16-bit P5 file. All such files are non-portable. Dave is correct that the released versions of pbmplus/netpbm only permit raw ppm and pgm files to have 1 byte per sample. FWIW, Jef Poskanzer told me several years ago that he intended to release an update that would also allow 2 byte/sample raw files (permitting maxvals 256-65535 to be supported in raw format), using LSB-first storage of each sample. On the strength of his promise I extended the JPEG tools to use that format for 12-bit JPEG data. I haven't seen any new release from him though, and I think he's lost interest in the C version of pbmplus; he's doing Java stuff these days. I have no idea how many of the other private hacks for this purpose chose LSB-first, and how many chose MSB-first because they didn't check with Jef :-( Bottom line is that 16-bit ppm/pgm is not portable and is likely to confuse tools that haven't been specially modified. regards, tom lane organizer, Independent JPEG Group -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 10:37:34 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id KAA16124 for ; Tue, 21 Oct 1997 10:37:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA14198 for png-list-outgoing; Tue, 21 Oct 1997 10:34:58 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA14193 for ; Tue, 21 Oct 1997 10:34:53 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id LAA17986 for ; Tue, 21 Oct 1997 11:28:19 -0400 (EDT) To: PNG List Subject: Re: pnmtopng - rescaling problem In-reply-to: Your message of Mon, 20 Oct 1997 22:43:32 -0700 (PDT) Date: Tue, 21 Oct 1997 11:28:19 -0400 Message-ID: <17984.877447699@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Theodore Goodman writes: > Compressing 8-bit PGM files, I ran into this bug. I have a couple of > images that need at least 8 bits per pixel to represent them in PNG. > For example, one image has 20 colors, with values 0 through 19. Another > has 51 colors with values 0 through 50. PNG doesn't support maxvals that aren't a power-of-2-less-1. Thus, pnmtopng assumes that the right thing for it to do is to rescale your 20-gray-level or 51-gray-level PGM into a 256-gray-level PNG. That *is* the right thing for it to do if your data actually represents grayscale data with a peculiar number of levels between black and white. If your data is 8-bit grayscale but just happens not to have anything except very dark tones, then the correct PGM representation of it is with maxval=255. maxval indicates the white level, not the color of the brightest pixel that the image happens to contain. If these things are in fact palette-based images then you should be presenting them in a format that reflects the fact. I'm not sure what other interpretation you may be expecting the data to have, but pnmtopng is behaving as it should given the normal assumptions about what a PGM file represents. > In the PNM header, if I set maxval to 19 for the first image, then run > pnmtopng on it using -force (no palettes), pnmtopng reports that it is > rescaling the values, and I get a file of only zeros. On the other hand, if you got zeroes out from this rescale operation, that *does* sound like a bug in the rescaling code. It should not have produced zeroes. regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 21 11:35:19 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id LAA17486 for ; Tue, 21 Oct 1997 11:35:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA15344 for png-list-outgoing; Tue, 21 Oct 1997 11:26:09 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA15339 for ; Tue, 21 Oct 1997 11:26:06 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.8.5/8.6.9) with ESMTP id JAA28558 for ; Tue, 21 Oct 1997 09:19:31 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Oct 1997 09:20:33 -0800 To: PNG List From: Dave Martindale Subject: RE: pnmtopng/pngtopnm problem with 16-bit files Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >I will (in couple of weeks) have a look at this. It has probably to do >with settings in pbm-lib (like BIGGRAYS, or something similar). >Probably not a big problem to solve. Just slipped my tests. BIGGRAYS, when defined, uses 16-bit storage for gray level and colour values internally, and enables reading and writing ASCII files (P2 and P3) with maxval up to 65535. It does *not* make raw files (P5 and P6) handle more than one byte per sample. That requires some additional code in the low-level routines. When I extended my copy of NETPBM to do this, I decided to use big-endian byte order, because that is already a standard for TCP/IP data. It also happens to be the native byte order for all of the machines that I currently work on. Thus, my extensions picked the opposite byte order of Tom's, and our files would be incompatible with each other. (I did attempt to send mail to the NETPBM mailing list about this, but the list processor rejects email from people who are not subscribed to the list. So I just picked a convention on my own). Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Oct 24 21:13:43 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id VAA04405 for ; Fri, 24 Oct 1997 21:13:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA09580 for png-list-outgoing; Fri, 24 Oct 1997 21:14:07 -0500 Received: from zircon.cse.ucsc.edu (zircon.cse.ucsc.edu [128.114.134.155]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA09575 for ; Fri, 24 Oct 1997 21:14:04 -0500 Received: from localhost (tgoodman@localhost) by zircon.cse.ucsc.edu (8.6.10/8.6.12) with SMTP id TAA18725 for ; Fri, 24 Oct 1997 19:07:12 -0700 X-Authentication-Warning: zircon.cse.ucsc.edu: tgoodman owned process doing -bs Date: Fri, 24 Oct 1997 19:07:12 -0700 (PDT) From: Theodore Goodman To: PNG List Subject: Re: pnmtopng - rescaling problem In-Reply-To: <17984.877447699@sss.pgh.pa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Theodore Goodman writes: > > Compressing 8-bit PGM files, I ran into this bug. I have a couple of > > images that need at least 8 bits per pixel to represent them in PNG. > > For example, one image has 20 colors, with values 0 through 19. Another > > has 51 colors with values 0 through 50. ... > > In the PNM header, if I set maxval to 19 for the first image, then run > > pnmtopng on it using -force (no palettes), pnmtopng reports that it is > > rescaling the values, and I get a file of only zeros. Tom lane wrote: > On the other hand, if you got zeroes out from this rescale operation, > that *does* sound like a bug in the rescaling code. It should not have > produced zeroes. Exactly. I believe this is a bug because, regardless of the interpretation of the pixel values, rescaling from a greylevel gamut of 0-19 to a new gamut of 0-255 should not produce a file of all zeros when the original file had pixels of all values ranging from 0 through 19. I would expect, for example, original pixel value 19 to be rescaled to 255, not 0. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Oct 28 02:44:56 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id CAA19922 for ; Tue, 28 Oct 1997 02:44:55 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA25539 for png-list-outgoing; Tue, 28 Oct 1997 02:44:35 -0600 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA25528 for ; Tue, 28 Oct 1997 02:43:57 -0600 Received: from ns.owlseye.com (ns.owlseye.com [198.240.0.102]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id DAA21618 for ; Tue, 28 Oct 1997 03:36:40 -0500 (EST) Received: (from owl@localhost) by ns.owlseye.com (8.7.4/8.7.3) id DAA03111; Tue, 28 Oct 1997 03:20:36 -0500 (EST) Date: Tue, 28 Oct 1997 03:20:36 -0500 (EST) Message-Id: <199710280820.DAA03111@ns.owlseye.com> From: owl@secretwebsite.com To: png-group@w3.org Subject: Is Your Web Site A Secret? Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Alta Vista, BC Internet, BizCardz Business Directory, BizWeb, Excite, Galaxy, HotBot, Infoseek, InfoSpace, Jayde Online Directory, JumpCity JumpLink, Linkcentre Directory, LinkMonster, Lycos, Magellan, Manufacturers Information Network, Net Happenings, Net Mall, Net-Announce, New Page List, New Riders WWW Yellow Pages, Northern Light, One World Plaza, Open Text Web Index, PageHost A-Z, PeekABoo, Project Cool, Scrub The Web, Seven Wonders, Sserv, Starting Point, The Galactic Galaxy, The Weekly Bookmark, True North,TurnPike, Unlock:The Information Exchange, Web 100, Web Crawler, Web Walker, Web World Internet Directory, WebVenture Hotlist, What's New, WhatUSeek, Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW Worm, YelloWWWeb, Your WebScout HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl@secretwebsite.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (SE7O22) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system, and send you a proof. After we process any corrections, we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===Web Promotions=====Press Releases=====Link Exchanges========= Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye@secretwebsite.com -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 30 00:32:38 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id AAA17742 for ; Thu, 30 Oct 1997 00:32:38 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA00399 for png-list-outgoing; Thu, 30 Oct 1997 00:34:06 -0600 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA00388 for ; Thu, 30 Oct 1997 00:34:00 -0600 From: mark1@octet.com Received: from ns3.octet.com (ns3.octet.com [204.107.183.3]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id BAA06362 for ; Thu, 30 Oct 1997 01:26:39 -0500 (EST) Received: (from uucp@localhost) by ns3.octet.com (8.8.6/8.8.3) id BAA16918; Thu, 30 Oct 1997 01:06:58 -0500 (EST) Date: Thu, 30 Oct 1997 01:06:58 -0500 (EST) Message-Id: <199710300606.BAA16918@ns3.octet.com> Received: from dialup211.octet.com(204.107.183.211) by ns3.octet.com via smap (V2.0) id xma026894; Wed, 29 Oct 97 23:18:38 -0500 To: mark1@octet.com Subject: FREE ADVICE BY MASTER PSYCHIC / FREE CALL Comments: Authenticated sender is X-UIDL: 55853944587397694948695155291378 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hear a gifted psychic speak your fortune and future on 1-800-711-7814, our special samples line where you can try a psychic reading free. Don't take the word of others - see for yourself just how accurate they are !!!!! Adults over 18 only Dial 1-800-711-7814 - totally free -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 30 13:38:16 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id NAA07121 for ; Thu, 30 Oct 1997 13:38:16 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA08321 for png-list-outgoing; Thu, 30 Oct 1997 13:22:57 -0600 Received: from boutell.com (boutell.com [206.125.69.81]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA08302 for ; Thu, 30 Oct 1997 13:22:41 -0600 Received: from vader.boutell.com by boutell.com (8.8.5/8.7.3) with ESMTP id LAA07140 for ; Thu, 30 Oct 1997 11:37:18 -0800 Received: from localhost (boutell@localhost) by vader.boutell.com (8.8.5/8.7.3) with SMTP id LAA20586 for ; Thu, 30 Oct 1997 11:14:11 -0800 X-Received: from boutell.com (root@boutell.com [10.1.1.1]) by vader.boutell.com (8.8.5/8.7.3) with ESMTP id KAA20015 for ; Thu, 30 Oct 1997 10:54:02 -0800 X-Received: from mail3.netcom.com by boutell.com (8.8.5/8.7.3) with ESMTP id LAA07007 for ; Thu, 30 Oct 1997 11:06:18 -0800 X-Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail3.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.01)) with ESMTP id KAA09661 for ; Thu, 30 Oct 1997 10:38:29 -0800 (PST) X-Received: from juliet.logica.com by relay1.UU.NET with SMTP (peer crosschecked as: juliet.logica.com [193.133.30.5]) id QQdnnm02138; Thu, 30 Oct 1997 13:38:37 -0500 (EST) X-Received: by juliet.logica.com; id SAA10484; Thu, 30 Oct 1997 18:38:21 GMT Message-Id: <199710301838.SAA10484@juliet.logica.com> X-Received: from morden.logica.co.uk(158.234.16.197) by juliet.logica.com via smap (g3.0.3) id xma010463; Thu, 30 Oct 97 18:37:49 GMT From: "Andrew" To: Subject: Ratings Systems Date: Thu, 30 Oct 1997 18:36:08 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ReSent-Date: Thu, 30 Oct 1997 11:14:06 -0800 (PST) ReSent-From: Thomas Boutell ReSent-To: png-list@dworkin.wustl.edu ReSent-Message-ID: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have just been reading your PNG spec and wondered if you had considered adding either specific chunks (eg rtng) or text chunks with known keywords to encode the adult rating schemes in use? You have already included a "Warning" text chunk but I assume this to be textual rather than to carry the systems in use (eg PICS). I'm sure codes could be assigned to the current systems in use and a decoder *could* offer warnings if working in a retricted environment where it does not recognise the system in use or does not find an encoding. Regards Andrew C-Side Software Ltd -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Oct 30 16:43:08 1997 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.6/8.8.5) with SMTP id QAA16908 for ; Thu, 30 Oct 1997 16:43:08 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA12217 for png-list-outgoing; Thu, 30 Oct 1997 16:44:23 -0600 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA12212 for ; Thu, 30 Oct 1997 16:44:19 -0600 Received: by INET-01-IMC with Internet Mail Service (5.0.1459.27) id ; Thu, 30 Oct 1997 14:36:56 -0800 Message-ID: <71F299426E8CCF11B05600805F6809DF013BC184@CUP-01-MSG> From: John Bowler To: PNG List Subject: RE: Ratings Systems Date: Thu, 30 Oct 1997 14:39:26 -0800 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > From: Andrew [SMTP:andrew@c-side.demon.co.uk] >I have just been reading your PNG spec and wondered if you had considered >adding either specific chunks (eg rtng) or text chunks with known keywords >to encode the adult rating schemes in use? This suffers from the same problems as the "fingerprint/signature" proposals: 1) The information isn't very useful in the image - it's much more useful on the *reference* to the image (like the image "signature" an application or user needs the information when considering to obtain the image, not afterward.) In this case this is particularly important as the mere download of an image might be grounds for legal action. 2) The PNG data cannot be authenticated in isolation - as a minimum some other, separate, key is required to validate the image securely. If such a key exists then it does not seem unreasonable to assume that the rating can be associated with the key (it all depends, of course, where the trust comes from.) Consequently embedding a rating within a PNG is only likely to be useful as a storage convenience - just as embedding a signature within a PNG might be a good way of holding the signature in some applications. Even this is, I suspect, unlikely to prove useful - MSOffice keeps image signatures in a header in front of the image data (in the binary file format) because it happens to be much more convenient to have it there. John Bowler >You have already included a "Warning" text chunk but I assume this to be >textual rather than to carry the systems in use (eg PICS). I'm sure codes >could be assigned to the current systems in use and a decoder *could* offer >warnings if working in a retricted environment where it does not recognise >the system in use or does not find an encoding. >Regards >Andrew >C-Side Software Ltd -- Send the message body "help" to png-list-request@dworkin.wustl.edu