From owner-png-list@ccrc.wustl.edu Tue Sep 1 13:45:14 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA19090 for ; Tue, 1 Sep 1998 13:45:13 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA19484; Tue, 1 Sep 1998 13:35:43 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA19480; Tue, 1 Sep 1998 13:35:41 -0500 Received: (qmail 21653 invoked from network); 30 Aug 1998 22:10:08 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 30 Aug 1998 22:10:08 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id PAA07403 for ; Sun, 30 Aug 1998 15:09:05 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id PAA19565 for png-list@ccrc.wustl.edu; Sun, 30 Aug 1998 15:09:33 -0700 Date: Sun, 30 Aug 1998 15:09:33 -0700 Message-Id: <199808302209.PAA19565@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: PNG approval process (was Re: gIFa chunk proposal) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List [Longish, but the first half is historical; the last half or so is "real."] I wrote: >>I also think we need to talk about the registration process before any >>new chunk or spec vote comes up; the fact that a generally well-supported >>and innocuous chunk like iCCP barely passed according to the proposed >>voting procedures suggests that (1) the procedure needs to be rethought >>and (2) a chunk like this [gIFa] has no prayer of being accepted. A little background, once more: Tom Lane first proposed (in early September 1996) some basic guidelines about voting that later got semi-enshrined in the png-registration-19960926 document. Since then we've basically followed the rules described therein despite the fact that the document was never approved according to its own procedures. The basic justification for the rules was something like this: - There should be a way to approve extensions to the spec in such a way that (1) everyone knows that a vote is going on, (2) everyone knows exactly what is being voted on and whether they're considered to have voted, and (3) the voting doesn't drag on forever and ever. - Complete implementations as proof of concept and desirability would be ideal, but such things are impractical in most cases. Instead we'll settle for a consensus of "knowledgable PNG experts." The first item led to the two-week discussion period, the two-week voting period and the distinctive format for the subject-line and body of a VOTE message. The second item resulted in the six-month rule (to ensure "expertness") and the 10-YES and 2:1-YES:NO rules (to ensure con- sensus). All three rules also served to discourage slam-bang approval of special-interest chunks pushed by some third-party group with an agenda. (I don't recall if that was explicitly noted as a goal or not.) The choice of the number 10 in the 10-YES rule was based on the observation that there were roughly two dozen or more people posting to the main PNG lists at the time. I haven't checked to be sure, but my impression is that there are fewer than one dozen doing so now. (We've got the list archives available, so both numbers could be checked exactly.) OK, enough background. Glenn replied to my message quoted above: > The same discussion occurred after the pCAL vote. We talked about > a yes=5+2*no and (yes=2*no AND yes >=7) to pass. > My feeling is that they all leave something to be desired. I particularly > don't like the resulting "silent no". There's no motive for someone > against the chunk to vote "NO", and then when the vote reaches 10-0 > they might not want to cast the first NO when 5 more are required to > overturn the thing. I'd rather see a scheme that encourages people to vote. > Like a simple > yes > 3*no to pass. > It's true that under this scheme, 1-0 would pass, but if only > one person cared to vote yes, surely someone would umph themselves > and vote no, and then 3 more YES votes would be needed. My feeling is that it all comes down to what we feel is "consensus," given a group whose active members may increase or decrease over time but whose numbers have definitely decreased significantly since the 1996 discussions. The 2:1 condition seems reasonable, but maybe 3:1 would be better; does a 6-to-3 vote really count as consensus? I'm not sure. Leaving the ratio aside for now, the raw count and qualifications are more worrisome to me. With regard to the latter, I recognize that the six-month rule makes objectivity simple, but a rule (or guideline) that eliminates folks who are demonstrably experts on the basis of their PNG programming records seems a bit extreme. On the other hand, someone who merely replaces a call to "GIFImageProducer" with one to "PNGImageProducer" in a Java program does not instantly become a PNG expert. So maybe a reasonable compromise would be simply to reduce the six-month rule to three or four months. Or we could go by when someone joined one of the non-announce PNG lists (as opposed to first posted); I've got records of that going back at least a year or two. It seems to me that 5 votes should be a hard minimum regardless of how many people have posted to the lists recently; if only four or fewer can be bothered to vote, then we probably don't have much of a PNG group any more. Perhaps we should simply scale the 10-vote 1996 guideline by the ratio of posters in the three months preceding the beginning of the voting period to the posters in the three months prior to Tom's 1996 posting (say, June, July and August of 1996 for simplicity). In the (unlikely) case that the ratio is greater than 1, I don't know if we should cap the requirement at 10 votes or let it increase without bound. I'd be inclined to let it increase, I think. So, to summarize what might make a good straw-man proposal: - 2:1 YES:NO ratio - at least "n" YES votes, where n == 10 * (three-month-before-vote posters) / (J/J/A-1996 posters) - at least 5 votes regardless (YES, NO or ABSTAIN) - voters must have posted to one of PNG/MNG lists at least three months before end of voting period or be generally approved by other eligible voters as "sufficiently expert" - two-week voting period (any provision for vacations?) Thoughts, everyone? Keep in mind that we probably need to be approaching consensus on this by mid-September if we're to get PNG 1.1 approved in time for the ISO to use it--Chris Lilley can confirm or deny the timetable. The gamma clarifications and sRGB are at stake. (iCCP was already formally approved to go into the core spec.) Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 14:19:16 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA19342 for ; Tue, 1 Sep 1998 14:19:15 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA20151; Tue, 1 Sep 1998 14:12:59 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA20142; Tue, 1 Sep 1998 14:12:58 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id MAA20601; Tue, 1 Sep 1998 12:12:37 -0700 (PDT) Date: Tue, 1 Sep 1998 12:12:37 -0700 (PDT) Message-Id: <199809011912.MAA20601@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: PNG approval process (was Re: gIFa chunk proposal) From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs says: > So maybe a reasonable compromise would be simply to reduce the > six-month rule to three or four months. Anywhere between 3 and 6 months is fine with me. > Or we could go by when someone joined one of the non-announce PNG > lists (as opposed to first posted); I prefer first posted. Otherwise people we've never heard of could come out of the woodwork right after a vote is called. > - at least "n" YES votes, where > n == 10 * (three-month-before-vote posters) / (J/J/A-1996 posters) Too complicated. How about this: yes / no >= 2 and yes - no >= 5 So 5-0, 6-1, 8-3, and 12-6 would pass, but 4-0, 6-2, 7-3, and 11-6 would fail. > - voters must have posted to one of PNG/MNG lists at least three > months before end of voting period or be generally approved by > other eligible voters as "sufficiently expert" Too vague, and circular. You're attempting to define concensus in terms of concensus. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 16:30:05 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA20411 for ; Tue, 1 Sep 1998 16:30:04 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA22784; Tue, 1 Sep 1998 16:26:42 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA22780; Tue, 1 Sep 1998 16:26:40 -0500 Received: (qmail 7856 invoked from network); 31 Aug 1998 13:21:08 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 31 Aug 1998 13:21:08 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id GAA08098 for ; Mon, 31 Aug 1998 06:20:03 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id GAA08181 for png-list@ccrc.wustl.edu; Mon, 31 Aug 1998 06:20:35 -0700 Date: Mon, 31 Aug 1998 06:20:35 -0700 Message-Id: <199808311320.GAA08181@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >> Is there a features summary page for mng? I didn't notice one at the >> mng home page. There is a short bulleted list of about 6 items, but I hope >> between that and _War_and_Peace_ there would be a "happy medium". > I would suggest skimming through the spec (at least chapters 4 & 5), > which is what I did to build MNGeye. I don't know of a nice summary > that covers MNG adequately. I've written what I hope is a good one as part of the MNG chapter in my book, but you'll have to wait a few months to see that. ;-) Btw, only one of the four or five messages I sent to wustl.edu yesterday got through, so if this message doesn't make it, just ignore it... Heh. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 16:50:36 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA20576 for ; Tue, 1 Sep 1998 16:50:35 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA23305; Tue, 1 Sep 1998 16:45:16 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA23301; Tue, 1 Sep 1998 16:45:15 -0500 Received: (qmail 19791 invoked from network); 30 Aug 1998 20:46:22 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 30 Aug 1998 20:46:22 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id NAA22842 for ; Sun, 30 Aug 1998 13:45:18 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id NAA17757 for png-list@ccrc.wustl.edu; Sun, 30 Aug 1998 13:45:47 -0700 Date: Sun, 30 Aug 1998 13:45:47 -0700 Message-Id: <199808302045.NAA17757@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: pngextensions-19980828 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn wrote: >>I've posted an updated version of the PNG extensions document >>at ftp://swrinde.nde.swri.edu/pub/png-group/documents >>in files pngextensions-19980828.html, pngextensions-19980828.txt.gz, >>and pngextensions-19980828.ps.gz for review and comment. > That's 19980827... 19980828 exists but I haven't uploaded it yet. > It fixes a few minor formatting glitches, including a missing > '"' mark in line 686 ('') -- this error only affects the HTML > version. I'll wait for your further comments before uploading > a new version. Two items, based on the PostScript version this time: - Under "Redundant equation types," the hyphen after sufficiently is unnecessary. - The first bullet under {X0,X1} (~ next paragraph) is almost incomprehensible--at least, I can't figure out what it's trying to say. At first I thought that one bullet was listing all of the "three things," since its first sentence starts with "First" and has two other pieces connected by "and," the second of which starts with "second." But then I noticed the other two bullets, which seem to be the real numbers two and three, which leaves me mystified as to the meaning behind item number one. It actually seems to be an older, single-bullet version of the list that somehow didn't get cleaned up properly; if so, the first sentence should probably end after "digitizer output." Otherwise it looks pretty good, and the sooner we can move it over to the /pub/png/documents area, the better--I'd like to clean up the top-level PNG page, which currently has nothing to point at for sRGB, iCCP and sPLT. (Come to think of it, I guess that means we should get moving on the 1.1 spec, too. :-) ) This message also serves as a test of ccrc.wustl.edu, which has not responded to one of my administrative messages today. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 18:08:19 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id SAA20882 for ; Tue, 1 Sep 1998 18:08:18 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA25581; Tue, 1 Sep 1998 18:04:39 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA25577; Tue, 1 Sep 1998 18:04:38 -0500 Received: (qmail 29364 invoked from network); 29 Aug 1998 19:58:57 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 29 Aug 1998 19:58:57 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id MAA17375 for ; Sat, 29 Aug 1998 12:57:55 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id MAA09719 for png-list@ccrc.wustl.edu; Sat, 29 Aug 1998 12:58:18 -0700 Date: Sat, 29 Aug 1998 12:58:18 -0700 Message-Id: <199808291958.MAA09719@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Richard W. Franzen wrote: > These are example cases of what I would like to do with the gc16 format. > It _will_ be a part of png-16, and (maybe mng?) and I'm trying to convince > you folks that it's useful, powerful, easy to implement, and sufficiently > backwards compatible to incorporate into the PNG 1.1 specification. I think I can just about guarantee you that *that* won't happen. Even assuming folks were convinced on theoretical grounds (for the record, I'm personally curious but certainly not convinced), there would be a need for experimental results on real images and ideally an implementa- tion or two as well. All of those things take time. On the other hand, the 1.1 spec is constrained by the ISO's timetable, and if I recall correctly, that means it has to be voted on within the next few weeks (although Chris has been fairly quiet about such matters). There are at least two things I'm not convinced about yet: - Backward compatibility: either gc16 defines a new color_type byte, in which case it's 95% incompatible with existing implementations (I'll grant 5% for parsing compatibility); or else it overloads the normal color_type = 0 (grayscale image type) and is flagged via an ancillary chunk. The latter would be a fairly ugly thing to do to a spec that is currently reasonably clean and orthogonal, but, of course, that's what private chunks are for. - Benefits over MNG: the latter would allow 16-bit grayscale with as low as a 1-bit transparent or translucent (but colored) overlay, and the original grayscale image would remain completely unmodified. The overlay would increase the file size some, but it need not be the same size as the primary image, so the difference could be quite small. In any case, I would need to see some real-life images that demonstrated a dramatic improvement in gc16's compression over MNG. So definitely continue working on it, but don't get your hopes up too much for a near-term inclusion in PNG. It's just not obvious that gc16 is useful enough compared with the alternatives. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 18:52:38 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id SAA21009 for ; Tue, 1 Sep 1998 18:52:37 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA26945; Tue, 1 Sep 1998 18:48:18 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA26940; Tue, 1 Sep 1998 18:48:13 -0500 Received: from x9.dejanews.com (ix9.dejanews.com [10.2.1.200]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id SAA30776 for ; Tue, 1 Sep 1998 18:48:08 -0500 Received: (from www@dejanews.com) by x9.dejanews.com (8.7.6/8.6.12) id SAA22148; Tue, 1 Sep 1998 18:48:07 -0500 Message-Id: <199809012348.SAA22148@x9.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Tue, 01 Sep 1998 23:48:06 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.10 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> X-Article-Creation-Date: Tue Sep 01 23:48:06 1998 GMT X-Http-Proxy: 1.0 x9.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.10 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List --------- posting from Chris Lilley ------------------------------------- Date: Sun, 30 Aug 1998 14:47:52 +0200 From: Chris Lilley Subject: Re: suggestion for png 1.1: gc16 To: PNG List Glenn Randers-Pehrson wrote: > > At 12:27 PM 8/29/98 -0400, Richard wrote: > >I work with large 16-bit images > >every. They range in size from 60 megabytes to 1.6 gigabytes. Let's just > >say that expanding them to 48 bits per pixel is not a tenable approach to > >obtaining some color with the images. The proposed gc16 format would be. > > Except that, as has been pointed out by others, the annotations will > wipe out the basic image. Imagine in malpractice court a few years > down the line trying to explain why a tumor wasn't spotted ("It's > under the arrowhead in this image"). I must say that I agree with this analysis. There is a difference between the file format and the frame buffer used to display it. Using a multiple image format for this sort of data has obvious advantages: - the medical image and the colored annotationcan be displayed separately or together - the image and the annotation can each be of any sample depth as required - the annotation need not be the same size as the medical image (there was mention made earlier of tucking the annotations in an unimportant area of the image) - the annotation can be moved relative to the medical image - there can be multiple annotations in different independently switchable layers, for example anonymised data for teaching on one layer and patient identification details on another layer - it is much easier to use standard image processing algorithms to enhance or segment the medical image if it is pure greyscale and does not have annotation pre-composed into it - it fits much better with the lossless philosophy > MNG, with a 16-bit grayscale and a 1- or 2-bit overlay, can accomplish > that without destroying any part of the main image. You could even > have another overlay with a second opinion. Yup. The overlay can be much smaller because the bit depth can be independently chosen and because it need not cover the full image (and need not be at the same spatial resolution?) And of course this approach can be extended, for example multiple images in a timed sequence (abdominal scans with barium meals, isotope tracing in urology studies, marrow scans in radiotherapy for PRV or thyroid tumors, etc) can all be stored together and use an overlay for data that applies to the entire sequence and other overlays for data that only applies to parts of the sequence. -- Chris Lilley, W3C http://www.w3.org/ Graphics and Stylesheets Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris:AT:w3.org 2004 Rt des Lucioles / BP 93 06902 Sophia Antipolis Cedex, France --------- end of post ------------------------------------------- I don't disagree, Chris. MNG is a great format with many powerful and useful capabilities. I've finally gotten around to joining the mpng-list, and may be showing my typing fingers there occasionally. But back to the 'gc16' proposal. GC16 offers to png: - simultaneous deep grey and true color support - true color in a single, 16-bit channel - easy to render - extremely high degree of backwards compatibity - level 0: treat as 16-bit greyscale image (png v1.0 programs) - easy to add support in existing png applications - level 1: treat as 24-bit true color image (viewers) - level 2: treat as 48-bit true color image (image processors) I am aware that PNG needs to avoid "TIFF-ititus" (10+ file formats with one extension, with any given "tiff" program only supporting 3 of them). However, IMHO I believe that gc16 fits naturally into the existing png infrastructure that was established in v1.0. (It simply fills a gap that wasn't noticed the first time around ;-) On a somewhat related note, I see by the adoption rules that are being discussed, I won't be eligible to vote for a few months. That's cool. By extension of that rule, can I make a formal proposal, or does one of the eligible voters need to "make the motion"? -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16Tech.html#gc16 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 19:37:42 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA21145 for ; Tue, 1 Sep 1998 19:37:41 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA27959; Tue, 1 Sep 1998 19:34:53 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA27955; Tue, 1 Sep 1998 19:34:52 -0500 Received: from x9.dejanews.com (ix9.dejanews.com [10.2.1.200]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id TAA31987 for ; Tue, 1 Sep 1998 19:34:52 -0500 Received: (from www@dejanews.com) by x9.dejanews.com (8.7.6/8.6.12) id TAA23368; Tue, 1 Sep 1998 19:34:50 -0500 Message-Id: <199809020034.TAA23368@x9.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Wed, 02 Sep 1998 00:34:49 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.10 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sbru3$i7l$1@nnrp1.dejanews.com> <6sd8ja$5j0$1@nnrp1.dejanews.com> X-Article-Creation-Date: Wed Sep 02 00:34:49 1998 GMT X-Http-Proxy: 1.0 x9.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.10 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------ posted to png-list ------------------------------- Date: Mon, 31 Aug 1998 06:20:35 -0700 From: Greg Roelofs Subject: Re: suggestion for png 1.1: gc16 To: png-list@ccrc.wustl.edu >> Is there a features summary page for mng? I didn't notice one at the >> mng home page. There is a short bulleted list of about 6 items, but I hope >> between that and _War_and_Peace_ there would be a "happy medium". > I would suggest skimming through the spec (at least chapters 4 & 5), > which is what I did to build MNGeye. I don't know of a nice summary > that covers MNG adequately. I've written what I hope is a good one as part of the MNG chapter in my book, but you'll have to wait a few months to see that. ;-) Btw, only one of the four or five messages I sent to wustl.edu yesterday got through, so if this message doesn't make it, just ignore it... Heh. Greg ----------- end of post ------------------------------------------- Have you sold the movie rights, Greg? How about "Godzilla vs MNG", or "Charlie Chan Pings with Ming"? :-) Seriously, I will be interested in buying a copy when it comes out. As far as overviews go, what is the group's opinion of the png-16 overview (linked at bottom of this page)? I know it's not anything that I would publish in a book, but do I explain png-16 in a way that is readable in the international arena and plain makes sense? -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 19:59:26 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA21207 for ; Tue, 1 Sep 1998 19:59:25 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA28508; Tue, 1 Sep 1998 19:58:20 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA28504; Tue, 1 Sep 1998 19:58:19 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id RAA22086; Tue, 1 Sep 1998 17:58:13 -0700 (PDT) Date: Tue, 1 Sep 1998 17:58:13 -0700 (PDT) Message-Id: <199809020058.RAA22086@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List rfranzen@my-dejanews.com says: > - true color in a single, 16-bit channel This is not particularly useful. Images do not originate in a 5.5.5 RGB space. If you're willing to lose information, you should use a lossy format like JPEG. Then you'll have an image that's both better-looking and smaller, compared to gc16. Images that are not suited to JPEG, like line art, tend to be well-suited to indexed color, which again will be better-looking and smaller than gc16. > - simultaneous deep grey and true color support What you are proposing is a cute kludge, but kludges are not in the spirit of PNG. The clean and conceptually simple way to mix gray and color is to compose multiple images. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 19:59:45 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA21216 for ; Tue, 1 Sep 1998 19:59:44 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA28489; Tue, 1 Sep 1998 19:57:37 -0500 Received: from pedigree.cs.ubc.ca by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA28485; Tue, 1 Sep 1998 19:57:31 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id NAA03381 for ; Tue, 1 Sep 1998 13:40:33 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199808302016.UAA16212@heresy.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Sep 1998 12:09:48 -0700 To: PNG List From: Dave Martindale Subject: trying again Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List I wrote the following 5 days ago, but it was never delivered to the list; probably due to the mailing list address moving. Here's another try using the new address From: Dave Martindale Subject: Re: gIFa chunk proposal >I don't know if we in PNG group should be prepared to say that >no one uses GIF89a features. Why did we design the gIF* chunks >in the first place? We thought it would be politically important to be able to say that any GIF could be transformed into a PNG without loss of information. We never intended to support animation, but nobody used it and supporting it would involve completely changing PNG. There were a few other features that nobody used that could be supported easily, so we did - or tried to. Now, it turns out that the one feature we didn't (and couldn't) support - animation - is the main reason that PNG cannot replace GIF, because there are plenty of GIF animations around the web. So PNG is not a general GIF replacement, and we can't make it into one. Given that, I'd rather have a PNG that concentrates on what it does well, and is intended to do: provide lossless storage of images, with enough information to provide correct (or at least the same) display on all platforms. Adding sRGB ad iCCP chunks has been a lot of work, but worth it because they further those goals. Having special-purpose chunks whose only purpose is storing stuff specific to GIF, but of little or no use to anyone else, detracts from those goals. They make the standard a bit bigger and more complex, and make decoders a bit more complex if they want to recognize all registered chunks. Then turn PNG from a standard that stands on its own merits to one that has extra widgets that make sense only in the context of another obsolete file format. So there needs to be a good reason for including them. And I don't think there is sufficient reason. In the case of MNG, if adding a few chunks can allow the statement "we can store any legal GIF", then it's probably worth it. But of all the GIF features that PNG can't support, I think animation is the one that anyone converting GIFs to PNGs feels lacking. If we can't support *that*, I see no point in supporing other features that are much less desired, and in fact apparently never used beyond test images. In fact, some days I'd argue that PNG should be written without a single reference to GIF (except perhaps in a historical section). All its features should be useful and important even if GIF never existed. >Is there anything technically wrong with my proposal to include >sequence numbers in replacements for the gIF* chunks, and alpha >in a replacement for gIFt? Ignore all the discussion about >MNG/GTXT for the moment. That's a separate issue. I don't see anything technically wrong. But I think it's bad to include stuff that's useless, unless there is a good political reason. >This seems to be an appopriate time to fix the chunks: We are >working on PNG-1.1, Greg is writing a book, and I'm polishing up >the extensions document. I would rather describe chunks that >work rather than put in warnings about chunks that don't work. I agree (with someone else) that we can't make the already- registered chunk just vanish, but I like the "deprecated chunks" section. I'd rather explain that a particular chunk was originally intended for GIF conversion, doesn't work in all cases, and its use is now deprecated, than add and explain several new chunks that will never be used. Dave -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 20:18:00 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA21281 for ; Tue, 1 Sep 1998 20:17:59 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA28712; Tue, 1 Sep 1998 20:16:22 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA28708; Tue, 1 Sep 1998 20:16:21 -0500 Received: from x9.dejanews.com (ix9.dejanews.com [10.2.1.200]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id UAA00103 for ; Tue, 1 Sep 1998 20:16:21 -0500 Received: (from www@dejanews.com) by x9.dejanews.com (8.7.6/8.6.12) id UAA24595; Tue, 1 Sep 1998 20:16:20 -0500 Message-Id: <199809020116.UAA24595@x9.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Wed, 02 Sep 1998 01:16:17 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.10 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6s9fle$vgo$1@nnrp1.dejanews.com> <6s9ulh$hau$1@nnrp1.dejanews.com> X-Article-Creation-Date: Wed Sep 02 01:16:17 1998 GMT X-Http-Proxy: 1.0 x9.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.10 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ----------- posted to png-list ----------------------------------- Date: Sat, 29 Aug 1998 12:58:18 -0700 From: Greg Roelofs Add to Address Book Subject: Re: suggestion for png 1.1: gc16 To: png-list@ccrc.wustl.edu Richard W. Franzen wrote: > These are example cases of what I would like to do with the gc16 format. > It _will_ be a part of png-16, and (maybe mng?) and I'm trying to convince > you folks that it's useful, powerful, easy to implement, and sufficiently > backwards compatible to incorporate into the PNG 1.1 specification. I think I can just about guarantee you that *that* won't happen. Even assuming folks were convinced on theoretical grounds (for the record, I'm personally curious but certainly not convinced), there would be a need for experimental results on real images and ideally an implementa- tion or two as well. All of those things take time. On the other hand, the 1.1 spec is constrained by the ISO's timetable, and if I recall correctly, that means it has to be voted on within the next few weeks (although Chris has been fairly quiet about such matters). There are at least two things I'm not convinced about yet: - Backward compatibility: either gc16 defines a new color_type byte, in which case it's 95% incompatible with existing implementations (I'll grant 5% for parsing compatibility); or else it overloads the normal color_type = 0 (grayscale image type) and is flagged via an ancillary chunk. The latter would be a fairly ugly thing to do to a spec that is currently reasonably clean and orthogonal, but, of course, that's what private chunks are for. - Benefits over MNG: the latter would allow 16-bit grayscale with as low as a 1-bit transparent or translucent (but colored) overlay, and the original grayscale image would remain completely unmodified. The overlay would increase the file size some, but it need not be the same size as the primary image, so the difference could be quite small. In any case, I would need to see some real-life images that demonstrated a dramatic improvement in gc16's compression over MNG. So definitely continue working on it, but don't get your hopes up too much for a near-term inclusion in PNG. It's just not obvious that gc16 is useful enough compared with the alternatives. Greg ----------- end of post ------------------------------------------ Greg, Oh well, with a two-week adoption window, I'm pretty sure it won't happen either. (Not in 1.1 anyway!) You were right in an earlier message about your postings being delayed--damn, I wish this e-mail had arrived sooner than this evening. My plan all along is to get png-16 working and proven outside of the formal png infrastructure. The reason I made the suggestion for gc16 ahead of time is that once I got it on paper, I realized it would fit easily within the existing png infrastucture, and with a great degree of backwards compatibity. I don't agree that "overloading" the grey chunk type is ugly; to me it is an elegant solution to simultaneously providing this backwards compatiblity and offering new features. Handling it would not be difficult. As I just posted a few minutes ago, viewing programs could treat it as 24-bit color (decoding both the grey and color to 24-bit RGB), and image-processing programs could treat it as 48-bit RGB (also decoding on the fly). Either type of program could offer the option to save/convert 24- or 48-bit color to gc16. ...but this is a difference of opinion to work out at a later time. So I'll continue working on png-16, with its 16-bit types of fc16, mc16, and gc16. And I'm still very anxious to get some feedback! I know you-all have other things to do, but (except for Gerard) no one has made any general comments in quite a while. You don't even have to post the comments to png-list; just click the dejanews link below and post in the png-16 news group. (It's only available via dejanews; other News carriers do not carry the 'dejanews.' groups.) -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 20:40:56 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA21330 for ; Tue, 1 Sep 1998 20:40:56 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA29157; Tue, 1 Sep 1998 20:39:43 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA29153; Tue, 1 Sep 1998 20:39:40 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id SAA22330; Tue, 1 Sep 1998 18:39:32 -0700 (PDT) Date: Tue, 1 Sep 1998 18:39:32 -0700 (PDT) Message-Id: <199809020139.SAA22330@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: PNG 1.1 proposal draft 1.2.2 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > > * Should we say anything about constructing gamma correction tables > > using fixed-point math? > > We could put it in the "Sample code" section of the extensions > document. We could, but maybe it would be better to leave it as a separate file. gamma-lookup.c is fairly long (244 lines). It provides code for both 16-bit fixed point and 32-bit fixed point, plus test code to compare the accuracy to floating point. It can be easily downloaded, compiled, and run. It can be debugged or enhanced independently of any document. And it's of interest to a very limited audience. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 20:54:09 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA21393 for ; Tue, 1 Sep 1998 20:54:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA29364; Tue, 1 Sep 1998 20:53:12 -0500 Received: from pedigree.cs.ubc.ca by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA29360; Tue, 1 Sep 1998 20:53:11 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id SAA04152 for ; Tue, 1 Sep 1998 18:53:10 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199809012348.SAA22148@x9.dejanews.com> References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Sep 1998 18:50:36 -0700 To: PNG List From: Dave Martindale Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > But back to the 'gc16' proposal. GC16 offers to png: > > - simultaneous deep grey and true color support > - true color in a single, 16-bit channel > - easy to render > - extremely high degree of backwards compatibity > - level 0: treat as 16-bit greyscale image (png v1.0 programs) > - easy to add support in existing png applications > - level 1: treat as 24-bit true color image (viewers) > - level 2: treat as 48-bit true color image (image processors) I'm afraid I remain unconvinced. I'd like to see an example of an image that is better stored as GC16 than any of the existing PNG formats. I don't think the "deep X-ray plus annotations" is convincing, because that (to me) seems like a natural multi-layer image, better stored as MNG or (failing that) a 16-bit greyscale PNG and a separate 8-bit indexed colour PNG overlay. What else is GC16 indisputable good for? Dave -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 21:00:15 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA21428 for ; Tue, 1 Sep 1998 21:00:15 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA29373; Tue, 1 Sep 1998 20:55:30 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA29369; Tue, 1 Sep 1998 20:55:28 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA31940; Tue, 1 Sep 1998 21:55:19 -0400 Message-Id: <1.5.4.32.19980902015104.00fb54b0@netgsi.com> X-Sender: glennrp@netgsi.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Sep 1998 21:51:04 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 11:48 PM 9/1/98 GMT, you wrote: >However, IMHO I believe that gc16 fits naturally into the existing png >infrastructure that was established in v1.0. (It simply fills a gap that >wasn't noticed the first time around ;-) A microscopic gap that requires image-enhanced radiography to detect... > On a somewhat related note, I see by the adoption rules that are being >discussed, I won't be eligible to vote for a few months. That's cool. >By extension of that rule, can I make a formal proposal, or does one >of the eligible voters need to "make the motion"? Anyone can make a proposal. You already have. Only an eligible voter can call for a vote. Someone (usually me) puts the proposal into a final form that we can discuss and vote on, and is ready to be yanked into the appropriate document if passed. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 21:03:45 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA21443 for ; Tue, 1 Sep 1998 21:03:44 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA29529; Tue, 1 Sep 1998 21:01:42 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA29525; Tue, 1 Sep 1998 21:01:41 -0500 Received: (qmail 15000 invoked from network); 2 Sep 1998 02:02:49 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 2 Sep 1998 02:02:49 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id TAA28770 for ; Tue, 1 Sep 1998 19:01:41 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id TAA29674 for png-list@ccrc.wustl.edu; Tue, 1 Sep 1998 19:02:20 -0700 Date: Tue, 1 Sep 1998 19:02:20 -0700 Message-Id: <199809020202.TAA29674@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List [As I hope we've all noticed, my messages finally showed up--in one case more than three days late, argh. Thanks to Adam for discovering the probable cause--wustl.edu changed some mail-related DNS stuff, and my ISP didn't update their own servers or flush their cache until today.] Glenn wrote: >> We could put it in the "Sample code" section of the extensions >> document. > We could, but maybe it would be better to leave it as a separate file. > gamma-lookup.c is fairly long (244 lines). It provides code for both > 16-bit fixed point and 32-bit fixed point, plus test code to compare the > accuracy to floating point. It can be easily downloaded, compiled, and > run. It can be debugged or enhanced independently of any document. And > it's of interest to a very limited audience. The existing pCAL code is at least half that (three or four PostScript pages, I think). I would personally prefer to have all relevant PNG stuff in two documents (spec + extensions), especially given the sample-code section that's already in there. Most people will either use the HTML, which is easily navigable via anchors, or the PostScript as a printed document. If the sample code is really just *way* too long, then I'd rather have a separate sample-code document that contains all of it. But a multi-page version of the extensions doc, analogous to the W3C version of the main spec, would work just as well, I think. Another big benefit of the include-it-in-HTML approach over the dump-it- at-UUNET approach is that it gets replicated as a local file across several mirrors sites and whatnot. And note that the stand-alone, easily compilable *.c version could always be linked as originally envisioned *in addition* to being incorporated into the extensions doc. The con- venient version could then exist at a single site (UUNET) without worrying about network or file-server problems making it unavailable. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 21:15:34 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA21485 for ; Tue, 1 Sep 1998 21:15:33 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA29711; Tue, 1 Sep 1998 21:14:19 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA29707; Tue, 1 Sep 1998 21:14:18 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA00108; Tue, 1 Sep 1998 22:14:18 -0400 Message-Id: <1.5.4.32.19980902021003.00fc9f44@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, 01 Sep 1998 22:10:03 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >As I just posted a few minutes ago, viewing programs could >treat it as 24-bit color (decoding both the grey and color to 24-bit RGB), >and image-processing programs could treat it as 48-bit RGB Surely the image-processing program would be happier with a 16-bit grayscale. And surely you don't really want the image-processor messing with the annotations. I would rather have my yellow sticky annotations fastened on with a light tacking than glued down with epoxy (actually worse than that, you are cutting out a rectangle from your image and fastening in your annotations with black tape). There can be no filesize savings compared to the equivalent MNG which is bound to be smaller even though it contains multiple images, because the two image types will each be compressed in an optimal manner--combining them in the gc16 method will interfere with optimal compression of both. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 21:25:54 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA21511 for ; Tue, 1 Sep 1998 21:25:53 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA29918; Tue, 1 Sep 1998 21:24:52 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA29914; Tue, 1 Sep 1998 21:24:50 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA00535; Tue, 1 Sep 1998 22:24:51 -0400 Message-Id: <1.5.4.32.19980902022035.00fdd3ec@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, 01 Sep 1998 22:20:35 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 06:50 PM 9/1/98 -0700, you wrote: >What else is GC16 indisputable good for? For one thing, it's a lot better than the other two proposals, fc16 and mc16, which are indisputable hodge-podges. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 22:51:10 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA21923 for ; Tue, 1 Sep 1998 22:51:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id WAA01587; Tue, 1 Sep 1998 22:49:57 -0500 Received: from mtiwmhc02.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id WAA01578; Tue, 1 Sep 1998 22:49:54 -0500 Received: from worldnet.att.net ([12.77.243.5]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980902034952.FXAR15069@worldnet.att.net> for ; Wed, 2 Sep 1998 03:49:52 +0000 Message-ID: <35ECBEE7.B6DDD21D@worldnet.att.net> Date: Tue, 01 Sep 1998 23:43:36 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit --------------- post to png-list --------------------------------- Date: Mon, 31 Aug 1998 08:12:23 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List >> One of the objectives you state is to be able to combine deep grey >> with color. You claim that PNG would need 48 bits, which you're >> absolutely correct at. However MNG has quite a nice solution, with >> it's multiple-image format: simply have the grey image on its own >> with 16-bit precision, and overlay it with a smaller indexed-color >> image. Not as an animation but as a single frame! Just like my >> non-moving fish, except that the composite would be created by two >> images. I believe Glenn suggested something like this as well. > > I understand what you mean; it would be rendered as in inset image. This >is a useful approach, and its certainly better than requiring a 48 bpp image! >Still, there are two total images stored, and if both were large, transfer >times and disk space become an issue. The approach is useful when you need >to preserve 100% of the raw data, but often you don't. The overlay image (which can have smaller width and height than the main image, if you like) is likely to occupy a tiny amount of storage relative to the main image, a few kbytes at most if it's a simple annotation (like one of those yellow sticky notes). With MNG, you can peel the note off again and relocate it or toss it. With gc16, if you remove it you've got a black rectangle where it had been. This has nothing to do with the gc16 vs. MNG issue, but your best bet to save space with those radiographs is to process out the noise in the "unused" areas, replacing them with pure gray, black, or white. That ought to cut the filesize of the main image significantly, if you aren't doing that already. Glenn -------------- end of post ------------------------------------------- Excellent idea, Glenn. I'd have to look up an algorithm that would insure that only "useless" black/very-dark_grey around the flesh tissue would get written as black. I wouldn't want to accidentally overwrite any of the analyzable parts! I'm sure that techniques for this are already documented, but I haven't had time to look into them. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16Tech.html#gc16 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 22:54:32 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA21942 for ; Tue, 1 Sep 1998 22:54:31 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id WAA01596; Tue, 1 Sep 1998 22:53:47 -0500 Received: from mtiwmhc02.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id WAA01592; Tue, 1 Sep 1998 22:53:46 -0500 Received: from worldnet.att.net ([12.77.243.5]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980902035345.FZAY15069@worldnet.att.net> for ; Wed, 2 Sep 1998 03:53:45 +0000 Message-ID: <35ECBFD1.97E5DC55@worldnet.att.net> Date: Tue, 01 Sep 1998 23:47:30 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit ---------- posting to png-list ----------------------------- Date: Sun, 30 Aug 1998 14:58:48 +0200 From: Chris Lilley Subject: Re: suggestion for png 1.1: gc16 To: PNG List Richard W. Franzen wrote: > What I am envisioning is a mammogram. 1/3 of the film area is breast > tissue, the rest of the 5000x4000 area is empty space (which, being very close > to black, would compress very well regardless of bit-depth). In this dark, > tissue-free area, the analyzing doctor insets a 1024x768 color image which is > from a report he did on the woman last year. OK. So there are two options: a) convert (or assume it is already 15bit ) the 16bit greyscale to your colorpsace of 15bit grey plus fixed large color pallete. put the 1024x768 image into the black area (making it compress much less well). Only 3.9% of the image contains color, but all of the pixels have been converted to your colorspace b) retain all the 16bit greyscale data, make a MNG with a large 5kx4k, well-compressible 16bit greyscale image and a small, 1024x768 well compressible color image which retains all of its color information too. Option b can be done now with MNG, and displayed using current tools such as MinGeyE or however it is capitalised..;-) Option a requires a new format, or adding a new non-backwards compatible color type to PNG. > (I've been locked in > a grey world for 10 years, and I want to see some yellow SUN!) Have you seen the false-color extension chunk for PNG (and MNG)? -- Chris Lilley, W3C http://www.w3.org/ Graphics and Stylesheets Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris:AT:w3.org 2004 Rt des Lucioles / BP 93 06902 Sophia Antipolis Cedex, France ---------------- end of post ------------------------------------------- MNG offers a lot of capability. No argument! I guess my eyes skimmed past the false-color extension. I remember "true color" and I remember "grey". I'll look it up. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16Tech.html#gc16 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 23:17:53 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA22108 for ; Tue, 1 Sep 1998 23:17:52 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA01947; Tue, 1 Sep 1998 23:16:51 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA01943; Tue, 1 Sep 1998 23:16:50 -0500 Received: from x9.dejanews.com (ix9.dejanews.com [10.2.1.200]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id XAA03455 for ; Tue, 1 Sep 1998 23:16:51 -0500 Received: (from www@dejanews.com) by x9.dejanews.com (8.7.6/8.6.12) id XAA28408; Tue, 1 Sep 1998 23:16:49 -0500 Message-Id: <199809020416.XAA28408@x9.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Wed, 02 Sep 1998 04:16:48 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.243.5 Organization: Deja News - The Leader in Internet Discussion References: <6sds03$r8s$1@nnrp1.dejanews.com> X-Article-Creation-Date: Wed Sep 02 04:16:48 1998 GMT X-Http-Proxy: 1.0 x9.dejanews.com:80 (Squid/1.1.22) for client 12.77.243.5 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List In article <6sds03$r8s$1@nnrp1.dejanews.com>, Gerard Juyn wrote: > Date: Mon, 31 Aug 1998 11:00:48 +0100 > From: "Gerard Juyn" > Subject: Re: suggestion for png 1.1: gc16 > To: png-list:AT:ccrc.wustl.edu > > > From: rfranzen@my-dejanews.com > > Date: Mon, 31 Aug 1998 04:25:15 GMT > > Is there a features summary page for mng? I didn't notice one at the > > mng home page. There is a short bulleted list of about 6 items, but I hope > > between that and _War_and_Peace_ there would be a "happy medium". > > I would suggest skimming through the spec (at least chapters 4 & 5), > which is what I did to build MNGeye. I don't know of a nice summary > that covers MNG adequately. Once you know your way around, MNG is > almost like a programming language, which allows to create the most > fantastic images. > > > I understand what you mean; it would be rendered as in inset image. This > > is a useful approach, and its certainly better than requiring a 48 bpp image! > > Still, there are two total images stored, and if both were large, transfer > > times and disk space become an issue. The approach is useful when you need > > to preserve 100% of the raw data, but often you don't. > > I'm more referring to your example of a large x-ray (or whatever) > where the Physician needs/wants to edit some remark(s) in color. The > remarks are put into an area which is much smaller than the x-ray, > and so, the color-image in the MNG would be small too (MNG does have > offsetting!), and also contain mostly black areas which would > compress extremely well... > > > More complex than my proposal??!? I'll have to read the mng spec now! > > But if my description of color cycling gave you a headache, damn, I'll > > probably have a stroke reading about "PPLT's with delta-values". > > Not really, it's just more complex in its implementation. Whereas > your proposal uses a single cCYC chunk, MNG requires 5! If you look at > the Hello-sample's structure you'll see the PPLT enveloped in a > DHDR/IEND, and that enveloped in a LOOP/ENDL which creates the > cycling-effect. As PPLT changes a palette, it must be enclosed in the > DHDR/IEND (delta-image), to identify the image whose palette it is > changing. (remember it is a multiple image format). The advantage of > the LOOP/ENDL structure is that it may contain any time-delay! > > > PS: http://home.att.net/~rocq/images/pn6Logo.png <-- what do you think? > > Uhm,.... very colorful. Perhaps you've seen the ray-traced PNG-logo's > (which are excellent btw.), so I would politely suggest a bit more > work perhaps :-) :-) > > Gerard (gjuyn:AT:xs4all.nl) > http://www.3-t.com > > -- > Send the message body "help" to png-list-request@ccrc.wustl.edu Gerard, MNG sounds both complex and very flexible. I consider png-16 to be a "single-image" format, though, even if it does do color cycling (its one time-dependent feature). But if mng wishes to encapsulate png-16 as well, then great! Concerning the pn6 logo, right now I only have one graphics program capable of any image-building or enhancement (well, besides msPaint...). I downloaded it from the Net this weekend and I am still learning how to use it. (It is called PhotoLine 4, and can be obtained for 30-day eval from http://www.ciebv.com .) My main computer died, and I'm using a portable that does not have all the tools I'm used to. At any rate, the one part that didn't turn out as expected on the logo is that I used transparency, and Netscape doesn't understand this yet. So where I wanted "transparent to the backdrop", it gets rendered as a kind of cyan. But the logo is using png features such as transparency, and it is only 445 bytes in size! Maybe the RGB border was too much. I should have kept it more subdued. My style is to try to be subtle--I get turned off by the in-your-face-GREATEST-THING-EVER style of building things. At any rate, I agree with you, the logo still needs work... -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 1 23:21:36 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA22130 for ; Tue, 1 Sep 1998 23:21:36 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA02082; Tue, 1 Sep 1998 23:20:19 -0500 Received: from mtiwmhc02.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA02078; Tue, 1 Sep 1998 23:20:18 -0500 Received: from worldnet.att.net ([12.77.243.5]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980902042017.GLTF15069@worldnet.att.net> for ; Wed, 2 Sep 1998 04:20:17 +0000 Message-ID: <35ECC609.CAF3B2F@worldnet.att.net> Date: Wed, 02 Sep 1998 00:14:01 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit --------------- post to png-list --------------------------------- Date: Mon, 31 Aug 1998 08:12:23 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List >> One of the objectives you state is to be able to combine deep grey >> with color. You claim that PNG would need 48 bits, which you're >> absolutely correct at. However MNG has quite a nice solution, with >> it's multiple-image format: simply have the grey image on its own >> with 16-bit precision, and overlay it with a smaller indexed-color >> image. Not as an animation but as a single frame! Just like my >> non-moving fish, except that the composite would be created by two >> images. I believe Glenn suggested something like this as well. > > I understand what you mean; it would be rendered as in inset image. This >is a useful approach, and its certainly better than requiring a 48 bpp image! >Still, there are two total images stored, and if both were large, transfer >times and disk space become an issue. The approach is useful when you need >to preserve 100% of the raw data, but often you don't. The overlay image (which can have smaller width and height than the main image, if you like) is likely to occupy a tiny amount of storage relative to the main image, a few kbytes at most if it's a simple annotation (like one of those yellow sticky notes). With MNG, you can peel the note off again and relocate it or toss it. With gc16, if you remove it you've got a black rectangle where it had been. This has nothing to do with the gc16 vs. MNG issue, but your best bet to save space with those radiographs is to process out the noise in the "unused" areas, replacing them with pure gray, black, or white. That ought to cut the filesize of the main image significantly, if you aren't doing that already. Glenn -------------- end of post ------------------------------------------- Excellent idea, Glenn. I'd have to look up an algorithm that would insure that only "useless" black/very-dark_grey around the flesh tissue would get written as black. I wouldn't want to accidentally overwrite any of the analyzable parts! I'm sure that techniques for this are already documented, but I haven't had time to look into them. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16Tech.html#gc16 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 00:09:18 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id AAA22345 for ; Wed, 2 Sep 1998 00:09:12 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA02788; Wed, 2 Sep 1998 00:04:50 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA02784; Wed, 2 Sep 1998 00:04:49 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id BAA06000; Wed, 2 Sep 1998 01:04:49 -0400 Message-Id: <1.5.4.32.19980902050034.00fb3258@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, 02 Sep 1998 01:00:34 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 11:43 PM 9/1/98 -0400, you wrote: > Excellent idea, Glenn. I'd have to look up an algorithm that would >insure that only "useless" black/very-dark_grey around the flesh tissue >would get written as black. I wouldn't want to accidentally overwrite >any of the analyzable parts! I'm sure that techniques for this are >already documented, but I haven't had time to look into them. I don't know if this is documented, but you could try making a separate copy I(x,y) of your original bitmap original_Intensity(x,y), then running for (k=kmax; k>0; k=k/2) for (all x and y) I(x,y) = MAX(I(x,y), I(x-k,y), I(x+k,y), I(x, y-k), I(x, y+k)); where kmax is some reasonable-sized power-of-two like 256, which would give you 9 iterations (k=2^8 through 2^0). Then a final pass for (all x and y) if(I(x,y) < threshold_Intensity) filtered_I(x,y)=background_Intensity; else filtered_I(x,y) = original_Intensity(x,y); That should preserve the important area plus a halo around it of width in pixels = kmax. Outside the halo, the pixels will be whatever you select for background_Intensity. Select a kmax that is guaranteed to be larger than half the diameter (in pixels) of any dark area in the important part of the image. You will also get a halo around any dust specks that are brighter than threshold_Intensity, so your mileage might vary... Setting background_Intensity = white will let you see those expanded dust specks easily. With the dark noise gone, the image "filtered_I" should compress better than "original_Intensity" I omitted details about finding the starting and ending points for "all x and y" but you get the idea. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 00:47:03 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id AAA22470 for ; Wed, 2 Sep 1998 00:47:03 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA03493; Wed, 2 Sep 1998 00:46:21 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA03489; Wed, 2 Sep 1998 00:46:20 -0500 Received: from x10.dejanews.com (ix10.dejanews.com [10.2.1.201]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id AAA04297 for ; Wed, 2 Sep 1998 00:46:21 -0500 Received: (from www@dejanews.com) by x10.dejanews.com (8.7.6/8.6.12) id AAA14006; Wed, 2 Sep 1998 00:46:19 -0500 Message-Id: <199809020546.AAA14006@x10.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Wed, 02 Sep 1998 05:46:18 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.243.5 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> X-Article-Creation-Date: Wed Sep 02 05:46:18 1998 GMT X-Http-Proxy: 1.0 x10.dejanews.com:80 (Squid/1.1.22) for client 12.77.243.5 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ---------------- posted to png-list --------------------------- Date: Tue, 1 Sep 1998 18:50:36 -0700 From: Dave Martindale Subject: Re: suggestion for png 1.1: gc16 To: PNG List > But back to the 'gc16' proposal. GC16 offers to png: > > - simultaneous deep grey and true color support > - true color in a single, 16-bit channel > - easy to render > - extremely high degree of backwards compatibity > - level 0: treat as 16-bit greyscale image (png v1.0 programs) > - easy to add support in existing png applications > - level 1: treat as 24-bit true color image (viewers) > - level 2: treat as 48-bit true color image (image processors) I'm afraid I remain unconvinced. I'd like to see an example of an image that is better stored as GC16 than any of the existing PNG formats. I don't think the "deep X-ray plus annotations" is convincing, because that (to me) seems like a natural multi-layer image, better stored as MNG or (failing that) a 16-bit greyscale PNG and a separate 8-bit indexed colour PNG overlay. What else is GC16 indisputable good for? Dave ---------------- end of post ---------------------------------- Dave, Well, at least one person featured on the png home pages uses 15-bit RGB for his original art. It is aesthetically frustrating to him that he has to save in a 24-bit format. And it is aesthetically frustrating to me that I don't have the tools to work with my scanned data and color at the same time. Not just for image insets, but for any type of drawing or image enhancement that I would want to do. Maybe even for a low-saturation color logo that was added indelibly to each scan. The frustration is that there are not the tools to work with this. And that intelligent people are telling me "you don't need to do that". Well, I want to. -- Rich ---------------- posted to png-list --------------------------- Date: Tue, 01 Sep 1998 22:20:35 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List At 06:50 PM 9/1/98 -0700, Dave wrote: >What else is GC16 indisputable good for? For one thing, it's a lot better than the other two proposals, fc16 and mc16, which are indisputable hodge-podges. Glenn ---------------- end of post ---------------------------------- Glenn, Cute. (Neither fc16 nor mc16 have been "proposals", though.) For fc16 I have to admit you are accurate. It is a hodge-podge, "and built to stay that way." :-) But for mc16, you are inaccurate. It is the only one of the three formats which is 100% orthagonal. There is just one data type, one fixed mapping from 17.25-bit to 24-bit RGB. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16Tech.html#mc16 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 01:38:30 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id BAA22634 for ; Wed, 2 Sep 1998 01:38:30 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id BAA04263; Wed, 2 Sep 1998 01:37:26 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id BAA04259; Wed, 2 Sep 1998 01:37:25 -0500 Received: from x10.dejanews.com (ix10.dejanews.com [10.2.1.201]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id BAA05456 for ; Wed, 2 Sep 1998 01:37:25 -0500 Received: (from www@dejanews.com) by x10.dejanews.com (8.7.6/8.6.12) id BAA15276; Wed, 2 Sep 1998 01:37:24 -0500 Message-Id: <199809020637.BAA15276@x10.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Wed, 02 Sep 1998 06:37:24 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.243.5 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> X-Article-Creation-Date: Wed Sep 02 06:37:24 1998 GMT X-Http-Proxy: 1.0 x10.dejanews.com:80 (Squid/1.1.22) for client 12.77.243.5 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ----------- posted on png-list --------------------------------- Date: Tue, 1 Sep 1998 17:58:13 -0700 (PDT) From: amc:AT:cs.berkeley.edu (Adam M. Costello) Subject: Re: suggestion for png 1.1: gc16 To: png-list@ccrc.wustl.edu rfranzen@my-dejanews.com says: > - true color in a single, 16-bit channel This is not particularly useful. Images do not originate in a 5.5.5 RGB space. If you're willing to lose information, you should use a lossy format like JPEG. Then you'll have an image that's both better-looking and smaller, compared to gc16. Images that are not suited to JPEG, like line art, tend to be well-suited to indexed color, which again will be better-looking and smaller than gc16. > - simultaneous deep grey and true color support What you are proposing is a cute kludge, but kludges are not in the spirit of PNG. The clean and conceptually simple way to mix gray and color is to compose multiple images. AMC ----------- end of post ---------------------------------------- Adam, As I just posted, some people do original art in 5:5:5 space. So for them, gc16 would not be lossy in any way. In general, though, I have no problem with your viewpoint. 24-bit lossless color is better than 15-bit lossless color (if you started with 24-bit color in the first place). Indexed color and lossy jpeg also have reputable places in the suite of image storage formats. Also I realize that there is no way in a two week period that gc16 could get incorporated in v1.1 of the png spec. So I'll just go back to my original goal, of letting you-all know that a new 16-bit format is being developed, but not ask for any commitment to it until such time as you can see what it actually offers. I respectfully disagree with your assertion, "the clean and conceptually simple way to mix [deep] gray and color is to compose multiple images". From my perspective, the conceptually simple way is to mix deep gray and color. (I wonder if the person who first wanted to put borders around pictures had people telling her, "your picture belongs in one image, and the border belongs in another, geometrically associated, image". She probably just offered the capability as part of her graphics program, and people used it.) Even though the feedback in this public forum tends to be initially negative and/or doubtful, I am getting encouraging feedback via private e-mail. Weird. But it's ok--I'll accept any feedback I can get! -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html PS: (early warning) When you do see png-16 demonstrated in a real app for the first time, "don't wear socks". -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 02:45:38 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id CAA23043 for ; Wed, 2 Sep 1998 02:45:37 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA05365; Wed, 2 Sep 1998 02:41:01 -0500 Received: from pedigree.cs.ubc.ca by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA05353; Wed, 2 Sep 1998 02:41:00 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id AAA17836 for ; Wed, 2 Sep 1998 00:40:42 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199809020546.AAA14006@x10.dejanews.com> References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Sep 1998 00:14:02 -0700 To: PNG List From: Dave Martindale Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > Well, at least one person featured on the png home pages uses >15-bit RGB for his original art. It is aesthetically frustrating >to him that he has to save in a 24-bit format. Can you elaborate more? Does he use 15-bit instead of 24-bit because he prefers 15-bit for some particular reason? Or is it just that he happens to have a 15-bit frame buffer to do his art on? If someone gave him a 24-bit frame buffer, would he continue to work in 15 bits, setting the lower 3 bits of each sample value to zero? And why is it "aesthetically frustrating" to save in 24-bit format? The conversion from 15 to 24 for storage and then from 24 back to 15 again for display should be completely lossless. So is the issue that the 24-bit file (containing 15-bit data) is larger than a file that truly only contained 16 bits per pixel? Is the size after compression that much different for the two cases? Or is it just that 15 bits should be stored in 16 as a matter of principle? > And it is aesthetically frustrating to me that I don't have the >tools to work with my scanned data and color at the same time. Not >just for image insets, but for any type of drawing or image >enhancement that I would want to do. Maybe even for a low-saturation >color logo that was added indelibly to each scan. > > The frustration is that there are not the tools to work with this. >And that intelligent people are telling me "you don't need to do >that". Well, I want to. I don't think people are telling you that "you don't need to" create those images. They're just suggesting that there are better ways, or at least more general ways, to *store* those images than what you are proposing. Dave -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 02:45:52 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id CAA23050 for ; Wed, 2 Sep 1998 02:45:52 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA05360; Wed, 2 Sep 1998 02:41:00 -0500 Received: from pedigree.cs.ubc.ca by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA05352; Wed, 2 Sep 1998 02:40:59 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id AAA17839 for ; Wed, 2 Sep 1998 00:40:44 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199809020637.BAA15276@x10.dejanews.com> References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Sep 1998 00:39:58 -0700 To: PNG List From: Dave Martindale Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List It occurs to me that if I *really* wanted to be able to store images encoded with the proposed fc16, mc16, or gc16 encodings in a single PNG file, this is what I would do: - Propose extending PNG to allow 16-bit indexed-colour images, so the palette could have up to 65536 entries instead of 256. - Propose adding a new pallette type whose entries are 16-bit R, G, B (or RGBA) instead of 8-bit. Then all three of the formats above could be stored as 16-bit indexed- colour images with an appropriate pallette. If I remember correctly which is which, mc16 has only 5 bits maximum for the intensity of any one colour, so only the first change would be needed to accomodate it. But fc16 and gc16 have some values with more than 8 bits of intensity, so both changes would be necessary. The nice thing is that these changes are logical extensions of features already there (though I haven't looked at what sort of changes to the spec and library would be needed to actually accomodate them). And the mechanism is very general - nothing specific to the rather strange fc16 encoding needs to be built into PNG at all, either at the spec level or in the library). Sure, you waste some space writing the same fixed palette to each image file - but for large images this matters little. And you get a very general mechanism that (for example) could also handle images that have been quantized to a custom palette with more than 256 entries. Dave -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 03:23:42 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id DAA23418 for ; Wed, 2 Sep 1998 03:23:42 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA05971; Wed, 2 Sep 1998 03:21:44 -0500 Received: from mercury.colossus.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA05967; Wed, 2 Sep 1998 03:21:43 -0500 Received: (from lcrocker@localhost) by mercury.colossus.net (8.9.1/8.9.1) id BAA25701 for png-list@ccrc.wustl.edu; Wed, 2 Sep 1998 01:21:33 -0700 Message-Id: <199809020821.BAA25701@mercury.colossus.net> Subject: Re: suggestion for png 1.1: gc16 To: png-list@ccrc.wustl.edu Date: Wed, 2 Sep 1998 01:21:32 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199809020637.BAA15276@x10.dejanews.com> from "rfranzen@my-dejanews.com" at Sep 2, 98 06:37:24 am Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > I respectfully disagree with your assertion, "the clean and conceptually > simple way to mix [deep] gray and color is to compose multiple images". From > my perspective, the conceptually simple way is to mix deep gray and color. > (I wonder if the person who first wanted to put borders around pictures had > people telling her, "your picture belongs in one image, and the border > belongs in another, geometrically associated, image". She probably just > offered the capability as part of her graphics program, and people used it.) Actually, the primary reason people spend $600 for Adobe Photoshop when there are dozens of good paint programs for less is because it is the best at doing precisely that: allowing you to compose images in conceptual layers and masks stored independently, then composite them into final images in flexible ways. No Photoshop guru would ever think of making a decorative border or text part of an image; that would ruin her ability to use that same border in a different image, or the same image in a different context. You might find much more receptiveness for a proposal for some method of storing related layers and compositing information for use by such advanced programs. A format that allowed one to store grayscale layers, color layers, text layers, lossy photo layers, and compositing rules in a standard way would be much more useful and in keeping with the spirit of PNG. A nifty hack that does much less at similar conceptual expense is not. -- Lee Daniel Crocker "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 05:03:05 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id FAA23980 for ; Wed, 2 Sep 1998 05:03:04 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id FAA08084; Wed, 2 Sep 1998 05:01:14 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id FAA08080; Wed, 2 Sep 1998 05:01:13 -0500 Received: from x12.dejanews.com (ix12.dejanews.com [10.2.1.203]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id FAA07741 for ; Wed, 2 Sep 1998 05:01:14 -0500 Received: (from www@dejanews.com) by x12.dejanews.com (8.7.6/8.6.12) id FAA05483; Wed, 2 Sep 1998 05:01:12 -0500 Message-Id: <199809021001.FAA05483@x12.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: ic16 (was: suggestion for png 1.1: gc16) Date: Wed, 02 Sep 1998 10:01:11 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.243.53 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Sep 02 10:01:11 1998 GMT X-Http-Proxy: 1.0 x12.dejanews.com:80 (Squid/1.1.22) for client 12.77.243.53 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List -------------- posted to png-list ---------------------------------- Date: Wed, 2 Sep 1998 00:39:58 -0700 From: Dave Martindale Subject: Re: suggestion for png 1.1: gc16 To: PNG List It occurs to me that if I *really* wanted to be able to store images encoded with the proposed fc16, mc16, or gc16 encodings in a single PNG file, this is what I would do: - Propose extending PNG to allow 16-bit indexed-colour images, so the palette could have up to 65536 entries instead of 256. - Propose adding a new pallette type whose entries are 16-bit R, G, B (or RGBA) instead of 8-bit. Then all three of the formats above could be stored as 16-bit indexed- colour images with an appropriate pallette. If I remember correctly which is which, mc16 has only 5 bits maximum for the intensity of any one colour, so only the first change would be needed to accomodate it. But fc16 and gc16 have some values with more than 8 bits of intensity, so both changes would be necessary. The nice thing is that these changes are logical extensions of features already there (though I haven't looked at what sort of changes to the spec and library would be needed to actually accomodate them). And the mechanism is very general - nothing specific to the rather strange fc16 encoding needs to be built into PNG at all, either at the spec level or in the library). Sure, you waste some space writing the same fixed palette to each image file - but for large images this matters little. And you get a very general mechanism that (for example) could also handle images that have been quantized to a custom palette with more than 256 entries. Dave -------------- end of post ----------------------------------------- Dave, !!! Most excellent ideas, Dude! If there were more than a two week window for the 1.1 png spec, I'd propose it right now. Since you didn't give this concept a name, let's call it 'ic16' (indexed color, 16-bit). I would add several pre-defined indexings. Why require a 192 kbyte or 384 kbyte overhead to the image size when you could just specify 'mc16' or 'gc16' or even 'fc06'? (This would be fc16 without Black Magic.) The first two are trivial to build a LUT for, and storing them would be silly. A good case could be made that fc06 is complex enough to require storing, but if a standards body were to define the precise SIH -=> RGB mapping, then it could be calculated rather than stored. (I don't think this will happen in the short term, so my standard American body (flabby) will be defining it. ;-) I'll be adding ic16 to my png-16 documentation soon. The fc16 image type already had a 24- and/or 48-bit indexed palette of about 4000 entries. Your idea is a logical and extremely useful extension of that capability. It was only a few days ago that I realized that png-16 is not a subset of 24-bit RGB, it is a subset of 48-bit RGB. (The mc16 type is fully contained within 24-bit RGB, so it is the exception.) If anyone has looked at my pages lately, you will have noticed that they already refer to indexing of 48-bit RGB. The concept has not fully made it into the docs, but it is "glued in" at several spots. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 08:00:52 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA24534 for ; Wed, 2 Sep 1998 08:00:52 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA10730; Wed, 2 Sep 1998 07:58:09 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA10726; Wed, 2 Sep 1998 07:58:08 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA15088; Wed, 2 Sep 1998 08:58:08 -0400 Message-Id: <1.5.4.32.19980902125354.00fc8a1c@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, 02 Sep 1998 08:53:54 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: ic16 (was: suggestion for png 1.1: gc16) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 10:01 AM 9/2/98 GMT, you wrote: >-------------- posted to png-list ---------------------------------- > > Date: Wed, 2 Sep 1998 00:39:58 -0700 > From: Dave Martindale >Subject: Re: suggestion for png 1.1: gc16 > To: PNG List > > >It occurs to me that if I *really* wanted to be able to store images >encoded with the proposed fc16, mc16, or gc16 encodings in a single PNG >file, this is what I would do: > >- Propose extending PNG to allow 16-bit indexed-colour images, so the > palette could have up to 65536 entries instead of 256. That wouldn't do anything about fc16's color cycling and HSV or whatever encoding or its internal intensity (gamma?) stuff. > >- Propose adding a new pallette type whose entries are 16-bit R, G, B > (or RGBA) instead of 8-bit. > How would this differ from the proposed and rejected fALS/faLT chunk? Had this chunk been approved, you could accomplish gc16 and mc16 with faLT (you'd want to revise gc16 to put the flag bit in the most significant bit, though, to get a more efficient palette). The false-color palette would look like 0 0 0 0 32k-1 64k-1 64k-1 64k-1 32k first overlay color 32k+16k second overlay color 64k third overlay color etc. The overlay colors are at widely spaced intervals so they'd be distinguishable if the faLT chunk were ignored. The true gray would be rendered at half intensity if faLT were ignored. This scheme would still have the disadvantage of overwriting the area covered by the annotations, though, isn't as efficient as writing a 1-byte grYc chunk, and is much less efficient and flexible than using MNG to store the annotations separately from the main image. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 08:08:00 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA24580 for ; Wed, 2 Sep 1998 08:07:59 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA10869; Wed, 2 Sep 1998 08:04:56 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA10865; Wed, 2 Sep 1998 08:04:56 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA15412; Wed, 2 Sep 1998 09:04:56 -0400 Message-Id: <1.5.4.32.19980902130042.00fc8a1c@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, 02 Sep 1998 09:00:42 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: ic16 (was: suggestion for png 1.1: gc16) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 10:01 AM 9/2/98 GMT, you wrote: > > Most excellent ideas, Dude! If there were more than a two week window for >the 1.1 png spec, I'd propose it right now. Since you didn't give this >concept a name, let's call it 'ic16' (indexed color, 16-bit). A similar but better proposal already has a name, faLT (false-color palette). > I would add several pre-defined indexings. Why require a 192 kbyte or 384 >kbyte overhead to the image size faLT would have expressed the palette more efficiently by linear interpolation of missing entries. We debated and tuned faLT for more than a year. When I put it up for a vote, it only attracted two affirmatives and no negatives, so it failed. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 08:12:58 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA24611 for ; Wed, 2 Sep 1998 08:12:57 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA11015; Wed, 2 Sep 1998 08:11:13 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA11011; Wed, 2 Sep 1998 08:11:12 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA15711; Wed, 2 Sep 1998 09:11:13 -0400 Message-Id: <1.5.4.32.19980902130658.00fd7494@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, 02 Sep 1998 09:06:58 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: png-16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 06:37 AM 9/2/98 GMT, you wrote: > Even though the feedback in this public forum tends to be initially >negative and/or doubtful, I am getting encouraging feedback via private >e-mail. Weird. But it's ok--I'll accept any feedback I can get! OK, here's my feedback. Please find another name for your format. "png-16" is apt to confuse people into thinking it's somehow blessed by the PNG development group and the W3C. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 10:18:31 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA25602 for ; Wed, 2 Sep 1998 10:18:31 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA13379; Wed, 2 Sep 1998 10:15:51 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA13375; Wed, 2 Sep 1998 10:15:50 -0500 Received: (qmail 29759 invoked from network); 2 Sep 1998 15:17:00 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 2 Sep 1998 15:17:00 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id IAA12350 for ; Wed, 2 Sep 1998 08:15:51 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id IAA12928 for png-list@ccrc.wustl.edu; Wed, 2 Sep 1998 08:16:34 -0700 Date: Wed, 2 Sep 1998 08:16:34 -0700 Message-Id: <199809021516.IAA12928@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > There can be no filesize savings > compared to the equivalent MNG which is bound to be smaller even > though it contains multiple images, because the two image types > will each be compressed in an optimal manner--combining them in > the gc16 method will interfere with optimal compression of both. Come now, Glenn. You have no proof of that. I'll grant that it's *probably* true, but just as there are certain GIF images that are smaller than PNGs (e.g., some 32- and 64-color ones), I'd bet that there will be cases where gc16 wins over MNG--if only because of its reduced chunk-count. We all need to be a little more careful of making unsubstantiated value judgments, too. "This is better than that" can in most cases be argued both ways, and blanket statements like that contribute to the sometimes less-than-friendly atmosphere that has driven at least a few people off the lists. (This is a common trait in most engi- neering-oriented lists I've seen; people have strong opinions and don't always tone them down before firing. I'm not pointing fingers at any one person, and I've certainly been guilty of it, too--but I'm trying to be nicer. :-) ) Finally, I'd like to request that Chris remind us all of the true timetable for ISO stuff so that we can (if needed) get on with the PNG 1.1 *vote* (as opposed to the final wording-tweaking and font- fixing). Assuming we stick with the freeze + two-week discussion period + two-week voting period procedure, we're talking at *least* a month before it's done. And we haven't yet had much commentary on the deflate-32K issue yet (or does everyone basically agree with Glenn's corrections to my clarifications?). For that matter, we haven't yet concluded the whole voting-procedure question. At a guess, that means 15 October is about the earliest we can realistic- ally expect PNG 1.1 to be approved. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 11:45:01 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA26282 for ; Wed, 2 Sep 1998 11:45:00 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA15362; Wed, 2 Sep 1998 11:39:25 -0500 Received: from pedigree.cs.ubc.ca by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA15356; Wed, 2 Sep 1998 11:39:24 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id JAA02571 for ; Wed, 2 Sep 1998 09:39:19 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <1.5.4.32.19980902125354.00fc8a1c@netgsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Sep 1998 09:39:01 -0700 To: PNG List From: Dave Martindale Subject: Re: ic16 (was: suggestion for png 1.1: gc16) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List People are reading too much into what I wrote. All I mean was that *if* I wanted to add a somewhat strange set of encodings like fc16, mc16, or gc16 to PNG, and I absolutely had to do it with 16-bit stored values, I'd propose extending PNG with 16-in 48-out palettes. My point was not that I actually want to do this - I don't. What I was trying to say is that the complex bit-combining rules of (say) fc16 do *not* belong in PNG itself, but in a lookup table that is associated with the file, either embedded in it or attached somehow. This, at least, is a very general mechanism that requires very little additional code in a PNG file reader (I think). The fALS/faLT chunk would have been a more elegant way of storing the palette, instead of having 2^16-entry tables. Both share the same basic idea: extending indexed colour to 16 bits. But however it would be done, I would definitely *not* have predefined palettes for fc16/mc16/gc16. These are too specific, and probably of too limited usefulness, to officially bless them and write them into the PNG spec (in my opinion). Which brings up a second argument. So far, I've been saying that if these formats are useful at all, the way to implement them in PNG is to use a lookup table. That's a technical issue. There is also the question of whether we *should* do something like this, even if it's perfectly clear how we *can*. For example, look at the 10-bit logarithmic encoding used by the Kodak Cineon system. This was a real encoding in use at the time PNG was designed, and has a number of advantages. It encodes a very large intensity range, as much as negative film can capture, with steps smaller than the eye can see over the whole range, and does it in 30 bits. For some purposes, it's probably the best existing way to store photographic images. But during PNG design discussions, we decided that we would support only one intensity transfer function (a power function specified by gAMA) and only power-of-2 sample widths. The Cineon encoding is excluded by both of these decisions, which is PNG's loss. But PNG gains by controlling the complexity of the spec, and thus the complexity of complete implementations of that spec. We wanted to avoid "TIFF syndrome". So decisions of what to add and what to leave out have to consider this tradeoff. In the case of Cineon, you *can* store the images as PNGs essentially losslessly by expanding them to 48-bit linear. You can't store the original *bits* in PNG, but you can store the *images* without significant loss. The same argument applies to fc16/mc16/gc16: you can store these images in PNG now, using 24- or 48-bit full colour. So is it worth complicating the set of defined encodings? So far, I don't think so. As for the proposed colour cycling, I remain convinced that this doesn't belong in PNG. PNG is a still image standard. PNG images should not move, or appear to move. If I remember correctly, fALS/faLT was proposed as a way of specifying false-colour display of 16-bit grey images. I can easily believe that this mechanism would be more useful than fc16 and friends. I think the proposed chunks died for lack of interest, not technical failings. If someone showed us a working application using these chunks for the display of radiographic information and called for renewed discussion, we might well approve it this time round. Dave -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 11:45:24 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA26291 for ; Wed, 2 Sep 1998 11:45:24 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA15365; Wed, 2 Sep 1998 11:39:25 -0500 Received: from ns.euro.ge.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA15357; Wed, 2 Sep 1998 11:39:24 -0500 Received: from smtp.euro.ge.com ([205.173.90.6]) by ns.euro.ge.com (8.8.8/8.8.8) with ESMTP id QAA12706 for ; Wed, 2 Sep 1998 16:39:21 GMT Received: from atlas.gemse.fr (atlas.eng.euro.med.ge.com [3.45.12.3]) by smtp.euro.ge.com (8.8.8/8.8.8) with SMTP id QAA12577 for ; Wed, 2 Sep 1998 16:38:35 GMT Received: from fats.buc_gemse by atlas.gemse.fr (4.1/SMI-4.1) id AA11700; Wed, 2 Sep 98 17:54:56 +0200 Received: by fats.buc_gemse (SMI-8.6/SMI-SVR4) id RAA14670; Wed, 2 Sep 1998 17:43:35 +0200 Date: Wed, 2 Sep 1998 17:43:35 +0200 Message-Id: <199809021543.RAA14670@fats.buc_gemse> From: Jean-loup Gailly To: PNG List Subject: Re: PNG spec and 32K sliding window In-Reply-To: <1.5.4.32.19980901001859.00fb4f78@netgsi.com> References: <1.5.4.32.19980901001859.00fb4f78@netgsi.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > So "decoders must accept any power-of-two window size from 512 bytes > up to and including 32 kilobytes." Also, the value that encoders write > in the CINFO bits must indicate a window that is equal to or greater than > the window size that they actually used, and not greater than 32 kilobytes. > (It's always OK to write "7", meaning "32 kilobytes".) Just to make Greg happy :-) : Glenn's clarification is fine. Use "32768 bytes" instead of "32 kilobytes" if you want to be extra-precise. Jean-loup -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 13:22:23 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA26992 for ; Wed, 2 Sep 1998 13:22:22 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA18070; Wed, 2 Sep 1998 13:12:55 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA18065; Wed, 2 Sep 1998 13:12:54 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa11208; 2 Sep 98 14:11 EDT Message-ID: <35ED8A42.4AEF5506@alumni.rpi.edu> Date: Wed, 02 Sep 1998 14:11:14 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <199809021516.IAA12928@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Greg Roelofs wrote: > > > There can be no filesize savings > > compared to the equivalent MNG which is bound to be smaller even > > though it contains multiple images, because the two image types > > will each be compressed in an optimal manner--combining them in > > the gc16 method will interfere with optimal compression of both. > > Come now, Glenn. You have no proof of that. I'll grant that it's > *probably* true, but just as there are certain GIF images that are > smaller than PNGs (e.g., some 32- and 64-color ones), I'd bet that > there will be cases where gc16 wins over MNG--if only because of > its reduced chunk-count. OK, agreed. But in the context of 5k x 5k grayscale images with a 1k x 1k inset that should be encoded as indexed-color but is forced to be encoded as 32k color, MNG would win. In small images where 82 bytes of chunk overhead is significant, the single image method could win. Also, if the area in the grayscale that's being replaced with the annotation image is actually dark random noise instead of true black, the gc16 method could appear to win. The only way to find out is to code up a lot of typical images in gc16 and compare them with equivalent multiple-image files, which would provide experience but not proof. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 14:56:15 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA27662 for ; Wed, 2 Sep 1998 14:56:15 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA20172; Wed, 2 Sep 1998 14:53:31 -0500 Received: from inet.htcnet.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA20168; Wed, 2 Sep 1998 14:53:30 -0500 Received: from msftrncs (p166.htcnet.com [199.120.83.166]) by inet.htcnet.com (8.7.3/8.6.9) with SMTP id PAA07620 for ; Wed, 2 Sep 1998 15:03:22 -0500 (CDT) Message-ID: <000e01bdd6ab$5c633880$0100000a@msftrncs.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: 16 bit palette... Date: Wed, 2 Sep 1998 14:53:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-png-list@ccrc.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 OAA27662 I while back, I recommended that PNG might have benefited from a 16bit palette option. Now the idea of FC16 has entered ... Personally, I think FC16 would be too complex to implement myself, and it wouldn't bring any benefit to many systems. Instead, I might comment that the idea of a 16 in 48 out palette system might work. I always felt that PNG should have as much versatility with its palette as it has with its true color modes... so both 16bit palette indices and 48bit palette values seem positive additions to PNG. I would note however, that something needs to be gotten across to the people who write support for PNG into their authoring programs... Just because a file is capable of 16, 256, or 65536 palette entries ... it doesn't have to contain all of them!!! :) Likewise for transparency ... it would be best for format the palette as to make the transparency table as small as possible... Carl Morris -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 19:10:19 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA29290 for ; Wed, 2 Sep 1998 19:10:19 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA26044; Wed, 2 Sep 1998 19:06:02 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA26040; Wed, 2 Sep 1998 19:06:01 -0500 Received: from x10.dejanews.com (ix10.dejanews.com [10.2.1.201]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id TAA24936 for ; Wed, 2 Sep 1998 19:06:02 -0500 Received: (from www@dejanews.com) by x10.dejanews.com (8.7.6/8.6.12) id TAA06068; Wed, 2 Sep 1998 19:06:00 -0500 Message-Id: <199809030006.TAA06068@x10.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: png-16 Date: Thu, 03 Sep 1998 00:05:59 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.116 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Sep 03 00:05:59 1998 GMT X-Http-Proxy: 1.0 x10.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.116 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------ posted to png-list -------------------------------------- Date: Tue, 01 Sep 1998 21:51:04 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List At 11:48 PM 9/1/98 GMT, Rich wrote: >However, IMHO I believe that gc16 fits naturally into the existing png >infrastructure that was established in v1.0. (It simply fills a gap that >wasn't noticed the first time around ;-) A microscopic gap that requires image-enhanced radiography to detect... > On a somewhat related note, I see by the adoption rules that are being >discussed, I won't be eligible to vote for a few months. That's cool. >By extension of that rule, can I make a formal proposal, or does one >of the eligible voters need to "make the motion"? Anyone can make a proposal. You already have. Only an eligible voter can call for a vote. Someone (usually me) puts the proposal into a final form that we can discuss and vote on, and is ready to be yanked into the appropriate document if passed. Glenn ---------------- end of post ----------------------------------------- (HTML test -- sorry if this garbles things up...) That explains it! I work with image enhanced radiography every day. :-)

If it is not already obvious from other posts, I retract the gc16 proposal for png v1.1.

-- Rich
------------ posted to png-list -------------------------------------- Date: Tue, 01 Sep 1998 22:10:03 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 >As I just posted a few minutes ago, viewing programs could >treat it as 24-bit color (decoding both the grey and color to 24-bit RGB), >and image-processing programs could treat it as 48-bit RGB Surely the image-processing program would be happier with a 16-bit grayscale. And surely you don't really want the image-processor messing with the annotations. I would rather have my yellow sticky annotations fastened on with a light tacking than glued down with epoxy (actually worse than that, you are cutting out a rectangle from your image and fastening in your annotations with black tape). There can be no filesize savings compared to the equivalent MNG which is bound to be smaller even though it contains multiple images, because the two image types will each be compressed in an optimal manner--combining them in the gc16 method will interfere with optimal compression of both. Glenn ---------------- end of post ----------------------------------------- When you are beginning analysis on a 5000x6000 by 16 (or 20,000x40,000 by 12) image, you generally choose not to process the whole file at once. You grab a region of interest and process that. If there is more than one ROI, you process as many as you want. You are correct -- an analyst would find little need to apply processing to any areas of annotation. These have probably been reduced in size to such an extent that very little could be gained. It would be assumed that the person who inset the image (watermark, barcode, etc.) already got that part like they wanted.

I have already stated that having the capacity to have "yellow stickies" or associated images/overlays stored with the raw file is a good idea, and I see that this can be done with MNG now. Sometimes, however, you won't need or even want an overlay; in that case png-16 will offer the tools to allow a single, atomic image to be output.

-- Rich
------------ posted to png-list -------------------------------------- Date: Wed, 02 Sep 1998 09:06:58 -0400 From: Glenn Randers-Pehrson Subject: png-16 At 06:37 AM 9/2/98 GMT, Rich wrote: > Even though the feedback in this public forum tends to be initially >negative and/or doubtful, I am getting encouraging feedback via private >e-mail. Weird. But it's ok--I'll accept any feedback I can get! OK, here's my feedback. Please find another name for your format. "png-16" is apt to confuse people into thinking it's somehow blessed by the PNG development group and the W3C. Glenn ---------------- end of post ----------------------------------------- I understand and partially sympathize with your point of view, Glenn. It is a strange world where someone who has been associated with PNG for a long time works on a follow-up format and chooses a name that isn't at all png-like (e.g. Paul Schmidt with '.px') Contrast that with someone like me who one day crawls out of the woodwork like a cockroach and seemingly wants to appropriate other people's work.

Please understand that this is not my goal at all. Png, right now, has already proved extremely beneficial in my field. At last there is a truly common image format that supports deep grey. Tiff has "supported" 16-bit grey for several years, but I'm not sure there are 5 programs in the whole world that support this flavor. (There might be six -- when I informed Ed Hamrick about png-16, he said that if he did add a 16-bit format to VuePrint, it would be TIFF's. :-) So I recognize and definately appreciate the work you-all have done and are doing.

Note that any png-16 program must, by definition, also support png. I.e., a png-16 program can read either '.png' or '.pn6', but a png program needs only to recognize '.png'. I state this in my documentation, but I'll put another notice near the top of the "PNG-16 Overview" page. I will also add a declarative statement that the PNG-16 development is in no way "blessed" by the PNG Development Group or the W3C.

Don't worry about me confusing people. If this is as bad an idea as some of you believe it is, then no programs will support it, and no one will know about it. However, if it is the good idea I strongly believe it to be, then my evil twin has laid out plans to have png-16 fans inundate you-all with requests to adopt it into png proper. Until we build that bridge, though, it does not need to be torn down.
-- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 2 19:31:02 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA29462 for ; Wed, 2 Sep 1998 19:31:02 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA26536; Wed, 2 Sep 1998 19:29:54 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA26532; Wed, 2 Sep 1998 19:29:53 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id RAA24107; Wed, 2 Sep 1998 17:29:52 -0700 (PDT) Date: Wed, 2 Sep 1998 17:29:52 -0700 (PDT) Message-Id: <199809030029.RAA24107@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: PNG 1.1 proposal draft 1.2.4 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Draft 1.2.4 is available from http://www.cs.berkeley.edu/~amc/png/ It incorporates the following suggestions: * A glossary entry for "intensity". * Clarification of the zlib max-32kB window size. * Reference to fixed-point gamma lookup example code in the PNG extensions document. * Recommendation that sRGB and iCCP be inserted alphabetically (although the proposal still has them at the end of chapter 4 because it would be too hard for me to fix all the section numbers). The remaining issues are: * The color handling stuff has barely been touched. Is it still valid under the new model (using the display output as the reference rather than the camera input), or does it need more edits? [I think we're waiting for Dave and/or Chris to comment.] * Should we refer to CIE 122? [This was suggested by Chris, who said he'd look at it and determine if it was relevant.] AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 05:12:46 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id FAA05799 for ; Thu, 3 Sep 1998 05:12:46 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id FAA06614; Thu, 3 Sep 1998 05:11:35 -0500 Received: from Mailer21.slidesource.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id FAA06463; Thu, 3 Sep 1998 05:10:09 -0500 From: aaa3services@mailexcite.com Message-Id: <199809031010.FAA06463@ccrc.wustl.edu> Subject: Do It Yourself or We can Can Do It For You Date: Thu, 3 Sep 1998 01:32:03 Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List DO IT YOURSELF 2 MILLION EMAIL ADDRESS + FULL RAPIDFIRE EMAILER $199.00 5 MILLION EMAIL ADDRESSES + A FULL RAPIDFIRE EMAILER $299.00 25 MILLION EMAIL ADDRESSES + A FULL RAPIDFIRE EMAILER $499.00 RAPIDFIRE IS A WEB MAILER. THE CD CONTAINS THE AMOUNT OF EMAIL ADRESSES + RAPIDFIRE + BONUS This Mailer sends email messages directly to your recipients Mail Server ! Rapid Fire Mail Server works with any Windows 95 or NT computer. It requires no additional hardware or software.The software Delivers each and every message right before your eyes direct to the receipient. Free SOFTWARE RAPIDFIRE (EMAIL BULK MAILER) NETSCAPE 4.05 (WEB BROWSER) IE4.01 (WEB BROWSER) WINZIP (ZIP UTILITY REGISTERED) COOL 3D (3D WEB PAGE PROGRAM WIN95 ONLY) MACAFEE CORP. (ANTIVIRUS PROGRAM WIN95/98 ONLY) NET ACCELARATOR (INTERNET ACCELARATOR) ORGANIZER (SAVE PHONE NUMBERS + ADDRESSES) MY INVOICE (INVOICING SOFTWARE) WSFTP32 (FTP PROGRAM) WINDRENALIN (HARD DRIVE SPEED) WINTUNE (TEST YOUR SYSTEM) (Plus stuff not even on the list) TARGETED MAILING MAILING AVAILABLE AT $199.00 PER 10,000 TARGETED EMAIL LISTS $99.00 PER 10,000 Just give Us a call at 1888-365-0000 ext.1648 WE CAN MAIL 4 U (GENERAL LIST) FIRST TIME CUSTOMER SPECIAL!!! ADVERTISE TO 200,000 PEOPLE FOR $299.00 (SPECIAL) ADVERTISE TO 1 MILLION PEOPLE FOR $999.00 $899.00 (SALE) ADVERTISE TO 3 MILLION PEOPLE FOR $1,995.00 ADVERTISE TO 5 MILLION PEOPLE FOR $2,999.00 ADVERTISE TO 10 MILLION PEOPLE FOR $3,995.00 SERVER INFO AND PRICING IF WE MAIL 4 U 10% DISCOUNT ON ALL PRICES WEB-PAGE HOSTING SET-UP FEE $250.00 (ONE TIME FEE) PER MONTH $250.00 (PER MONTH) DOMAIN Registration FEE $125.00 (ONE TIME FEE) ONE FREE EMAIL ADDRESS 3 MONTH CONTRACT Prefered IF WEB SIGHT HAS PROGRAMS TO DOWNLOAD (CALL US FOR PRICING) TOTAL $625.00 ADDITIONAL EMAIL ADDRESS $15.00(PER MONTH) 2.) TO USE OUR SECURE SERVER YOU should HAVE A 3 MONTH CONTRACT 3.) YOU GET 1 FREE SECURE EMAIL ADDRESS WITH HOSTING. YOU GET 2 CHANGES TO YOUR SIGHT PER MONTH (NO CHARGE) 25.00 EACH ADDITIONAL CHANGE. SERVER INFO AND PRICING IF SOMEONE ELSE DOES YOUR ADVERTISING WEB-PAGE HOSTING SET-UP FEE $500.00 (ONE TIME FEE) PER MONTH $500.00 (PER MONTH) DOMAIN FEE $125.00 (ONE TIME FEE) ONE FREE EMAIL ADDRESS MUST HAVE 3 MONTH CONTRACT IF WEB SIGHT HAS PROGRAMS TO DOWNLOAD (CALL US FOR PRICING) 1.) THERE IS A $50.00 CHARGE FOR EACH ADDITONAL HTML FILE. 2.) TO USE OUR SECURE SERVER YOU MUST HAVE A 3 MONTH CONTRACT 3.) YOU GET 1 FREE SECURE EMAIL ADDRESS WITH HOSTING. YOU GET 2 CHANGES TO YOUR SIGHT PER MONTH (NO CHARGE) 25.00 EACH ADDITIONAL CHANGE. WEB PAGES WEB PAGE EDITING $45.00 PER HOUR (MINIMUM 2 HOURS) WEB PAGE CREATIONS $350.OO MINIMUM (CALL US 4 DETAILS) CGI SCRIPTS $99.00 PER HOUR (2 HOURS MINIMUM) JAVA SCRIPTS $99.00 PER HOUR (2 HOURS MINIMUM) DOMAIN REPOINTING $25.00 ONE TIME WEB PAGE BACKUP $25.00 PER BACKUP (TO CD) Just give Us a call at 1888-365-0000 ext.1648 Member of National Organization of Internet Commerce. To have your name added to our universal remove list please go to remove@noic.org and the name will be added and distributed to all of our members. Or b1services@ mailexcite.com c/o AAA Services 1-888-365-0000 ext. 1648 230 West Hall Avenue PO Box 202 Slidell, LA 70460 08 0-98-3-n c2 D Thank You, And GOD Bless -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 07:17:02 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id HAA06182 for ; Thu, 3 Sep 1998 07:17:01 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA08658; Thu, 3 Sep 1998 07:15:54 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA08654; Thu, 3 Sep 1998 07:15:53 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA32246; Thu, 3 Sep 1998 08:15:48 -0400 Message-Id: <1.5.4.32.19980903121132.009b759c@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, 03 Sep 1998 08:11:32 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: ic16 (was: suggestion for png 1.1: gc16) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 09:39 AM 9/2/98 -0700, Dave wrote: >If I remember correctly, fALS/faLT was proposed as a way of specifying >false-colour display of 16-bit grey images. I can easily believe that >this mechanism would be more useful than fc16 and friends. Look at it this way: fALS/faLT is a general 16-bit palette with some efficiency in encoding (by linear interpolation of missing entries). gc16 is one particular predefined 16-bit palette. gc16 is to faLT as sRGB is to iCCP: gc16 is a way of passing a specific palette or profile by reference instead of by embedding it in the file. The question is whether that fixed 16-bit palette is useful enough to warrant putting advanced knowledge about it into decoders. A nice thing about that particular palette is that decoders that simply show the grayscale will get a reasonable image on-screen. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 10:01:14 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA07694 for ; Thu, 3 Sep 1998 10:01:14 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA11203; Thu, 3 Sep 1998 09:49:46 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA11199; Thu, 3 Sep 1998 09:49:45 -0500 Received: from x6.dejanews.com (ix6.dejanews.com [10.2.1.197]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id JAA04774 for ; Thu, 3 Sep 1998 09:49:46 -0500 Received: (from www@dejanews.com) by x6.dejanews.com (8.7.6/8.6.12) id JAA09978; Thu, 3 Sep 1998 09:49:43 -0500 Message-Id: <199809031449.JAA09978@x6.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: ic16 Date: Thu, 03 Sep 1998 14:49:41 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.40 Organization: Deja News - The Leader in Internet Discussion References: <6sj516$2ea$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 14:49:41 1998 GMT X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.40 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Ref: article <6sj516$2ea$1@nnrp1.dejanews.com> ------------------- posted to png-list ---------------------------- Date: Wed, 2 Sep 1998 00:14:02 -0700 From: Dave Martindale Subject: Re: suggestion for png 1.1: gc16 To: PNG List > Well, at least one person featured on the png home pages uses >15-bit RGB for his original art. It is aesthetically frustrating >to him that he has to save in a 24-bit format. Can you elaborate more? Does he use 15-bit instead of 24-bit because he prefers 15-bit for some particular reason? Or is it just that he happens to have a 15-bit frame buffer to do his art on? If someone gave him a 24-bit frame buffer, would he continue to work in 15 bits, setting the lower 3 bits of each sample value to zero? And why is it "aesthetically frustrating" to save in 24-bit format? The conversion from 15 to 24 for storage and then from 24 back to 15 again for display should be completely lossless. So is the issue that the 24-bit file (containing 15-bit data) is larger than a file that truly only contained 16 bits per pixel? Is the size after compression that much different for the two cases? Or is it just that 15 bits should be stored in 16 as a matter of principle? > And it is aesthetically frustrating to me that I don't have the >tools to work with my scanned data and color at the same time. Not >just for image insets, but for any type of drawing or image >enhancement that I would want to do. Maybe even for a low-saturation >color logo that was added indelibly to each scan. > > The frustration is that there are not the tools to work with this. >And that intelligent people are telling me "you don't need to do >that". Well, I want to. I don't think people are telling you that "you don't need to" create those images. They're just suggesting that there are better ways, or at least more general ways, to *store* those images than what you are proposing. Dave ---------------------- end of post -------------------------------- Dave, I shouldn't speak for someone who has only written me in private e-mail. If he chooses to publicly answer your questions, then that's cool. I acknowledge that a 5:5:5 image stored as a 24-bit png file will compress well. Also I agree that sequences such as 15 -> 24 -> 15 bit RGB transitions should be completely lossless (especially if the png recommendation for bit-field expansion\compression is used: pixOut = pixIn * (2^n_out - 1) / (2^n_in - 1); ). As for speaking for me, I can do that! A lot of it is The Principle of the Thing. That is not totally all, though. I fully expect (but cannot yet demonstrate) that png-16 files, in general, will be significantly smaller than their 24-bit (or 48-bit) png equivalents. There are lots of good techniques already in existence to accomplish much of what I want. Cool. But I will be proceeding with the development of png-16 to make available even more tools. -- Rich ------------------- posted to png-list ---------------------------- Date: Wed, 2 Sep 1998 09:39:01 -0700 From: Dave Martindale Subject: Re: ic16 (was: suggestion for png 1.1: gc16) To: PNG List People are reading too much into what I wrote. All I mean was that *if* I wanted to add a somewhat strange set of encodings like fc16, mc16, or gc16 to PNG, and I absolutely had to do it with 16-bit stored values, I'd propose extending PNG with 16-in 48-out palettes. My point was not that I actually want to do this - I don't. What I was trying to say is that the complex bit-combining rules of (say) fc16 do *not* belong in PNG itself, but in a lookup table that is associated with the file, either embedded in it or attached somehow. This, at least, is a very general mechanism that requires very little additional code in a PNG file reader (I think). The fALS/faLT chunk would have been a more elegant way of storing the palette, instead of having 2^16-entry tables. Both share the same basic idea: extending indexed colour to 16 bits. But however it would be done, I would definitely *not* have predefined palettes for fc16/mc16/gc16. These are too specific, and probably of too limited usefulness, to officially bless them and write them into the PNG spec (in my opinion). Which brings up a second argument. So far, I've been saying that if these formats are useful at all, the way to implement them in PNG is to use a lookup table. That's a technical issue. There is also the question of whether we *should* do something like this, even if it's perfectly clear how we *can*. For example, look at the 10-bit logarithmic encoding used by the Kodak Cineon system. This was a real encoding in use at the time PNG was designed, and has a number of advantages. It encodes a very large intensity range, as much as negative film can capture, with steps smaller than the eye can see over the whole range, and does it in 30 bits. For some purposes, it's probably the best existing way to store photographic images. But during PNG design discussions, we decided that we would support only one intensity transfer function (a power function specified by gAMA) and only power-of-2 sample widths. The Cineon encoding is excluded by both of these decisions, which is PNG's loss. But PNG gains by controlling the complexity of the spec, and thus the complexity of complete implementations of that spec. We wanted to avoid "TIFF syndrome". So decisions of what to add and what to leave out have to consider this tradeoff. In the case of Cineon, you *can* store the images as PNGs essentially losslessly by expanding them to 48-bit linear. You can't store the original *bits* in PNG, but you can store the *images* without significant loss. The same argument applies to fc16/mc16/gc16: you can store these images in PNG now, using 24- or 48-bit full colour. So is it worth complicating the set of defined encodings? So far, I don't think so. As for the proposed colour cycling, I remain convinced that this doesn't belong in PNG. PNG is a still image standard. PNG images should not move, or appear to move. If I remember correctly, fALS/faLT was proposed as a way of specifying false-colour display of 16-bit grey images. I can easily believe that this mechanism would be more useful than fc16 and friends. I think the proposed chunks died for lack of interest, not technical failings. If someone showed us a working application using these chunks for the display of radiographic information and called for renewed discussion, we might well approve it this time round. Dave ---------------------- end of post -------------------------------- Dave, Whether you believe in it or not, thanks! I think that the idea of a format which fully utilizes a 16-bit space to index 48-bit (or 24-bit) images is a Good Idea. Png-16 will have it. Also once I find in the png-list archives Glenn's proposal for fALS\fALT, I expect to implement that as well. (One _big_ advantage to this dejanews approach to tracking a discussion is instantly available indexing. Unless someone can tell me which month/year the fALS\fALT concept was fully laid out, I have to download and read month-by-month the png-list archives.) If fALS\fALT covers the general, indexed case for both 24-bit and 48-bit information, then there will be no need for a separate, "stupid" indexing chunk. Using a smart one that interpolates well is definately preferable! When\if the PNG Development Group chooses to analyze a working implementation of png-16, then the discussions as to adopt pre-defined indexed palettes and color-cycling will be profitable. Right now, it's all virtual, and the only case I can make is "my head thinks it is great". Your skepticism is well placed, understood, and respected. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 10:20:44 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA07911 for ; Thu, 3 Sep 1998 10:20:43 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA11955; Thu, 3 Sep 1998 10:13:57 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA11951; Thu, 3 Sep 1998 10:13:56 -0500 Received: from x6.dejanews.com (ix6.dejanews.com [10.2.1.197]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id KAA05234 for ; Thu, 3 Sep 1998 10:13:57 -0500 Received: (from www@dejanews.com) by x6.dejanews.com (8.7.6/8.6.12) id KAA11156; Thu, 3 Sep 1998 10:13:56 -0500 Message-Id: <199809031513.KAA11156@x6.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Thu, 03 Sep 1998 15:13:55 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.40 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sbru3$i7l$1@nnrp1.dejanews.com> <6sd8ja$5j0$1@nnrp1.dejanews.com> <6si2p4$q3q$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 15:13:55 1998 GMT X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.40 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List In article <6si2p4$q3q$1@nnrp1.dejanews.com> ------------------- posted to png-list ---------------------------- Date: Wed, 02 Sep 1998 01:00:34 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List At 11:43 PM 9/1/98 -0400, Rich wrote: > Excellent idea, Glenn. I'd have to look up an algorithm that would >insure that only "useless" black/very-dark_grey around the flesh tissue >would get written as black. I wouldn't want to accidentally overwrite >any of the analyzable parts! I'm sure that techniques for this are >already documented, but I haven't had time to look into them. I don't know if this is documented, but you could try making a separate copy I(x,y) of your original bitmap original_Intensity(x,y), then running: for (k=kmax; k>0; k=k/2) for (all x and y) I(x,y) = MAX(I(x,y), I(x-k,y), I(x+k,y), I(x, y-k), I(x, y+k)); where kmax is some reasonable-sized power-of-two like 256, which would give you 9 iterations (k=2^8 through 2^0). Then a final pass: for (all x and y) if (I(x,y) < threshold_Intensity) filtered_I(x,y) = background_Intensity; else filtered_I(x,y) = original_Intensity(x,y); That should preserve the important area plus a halo around it of width in pixels = kmax. Outside the halo, the pixels will be whatever you select for background_Intensity. Select a kmax that is guaranteed to be larger than half the diameter (in pixels) of any dark area in the important part of the image. You will also get a halo around any dust specks that are brighter than threshold_Intensity, so your mileage might vary... Setting background_Intensity = white will let you see those expanded dust specks easily. With the dark noise gone, the image "filtered_I" should compress better than "original_Intensity" I omitted details about finding the starting and ending points for "all x and y" but you get the idea. Glenn ---------------------- end of post -------------------------------- Glenn, I'll have to experiment and try this out, Glenn. Thank you very much for posting it. I don't think it will be a "speed demon" on 5000x6000 images, but if it can save significant disk space, the time spent may well be worthwhile. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html <=- !! new disclaimer !! -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 10:52:43 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA08250 for ; Thu, 3 Sep 1998 10:52:42 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA12742; Thu, 3 Sep 1998 10:47:04 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA12738; Thu, 3 Sep 1998 10:47:03 -0500 Received: from x6.dejanews.com (ix6.dejanews.com [10.2.1.197]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id KAA05838 for ; Thu, 3 Sep 1998 10:47:04 -0500 Received: (from www@dejanews.com) by x6.dejanews.com (8.7.6/8.6.12) id KAA11298; Thu, 3 Sep 1998 10:47:02 -0500 Message-Id: <199809031547.KAA11298@x6.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Thu, 03 Sep 1998 15:47:01 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.40 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> <6sip34$kpd$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 15:47:01 1998 GMT X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.40 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------------- posted to png-list ---------------------------- Date: Wed, 2 Sep 1998 01:21:32 -0700 (PDT) From: "Lee Daniel Crocker" Subject: Re: suggestion for png 1.1: gc16 Organization: Piclab (http://www.piclab.com/) To: png-list@ccrc.wustl.edu > I respectfully disagree with your assertion, "the clean and conceptually > simple way to mix [deep] gray and color is to compose multiple images". From > my perspective, the conceptually simple way is to mix deep gray and color. > (I wonder if the person who first wanted to put borders around pictures had > people telling her, "your picture belongs in one image, and the border > belongs in another, geometrically associated, image". She probably just > offered the capability as part of her graphics program, and people used it.) Actually, the primary reason people spend $600 for Adobe Photoshop when there are dozens of good paint programs for less is because it is the best at doing precisely that: allowing you to compose images in conceptual layers and masks stored independently, then composite them into final images in flexible ways. No Photoshop guru would ever think of making a decorative border or text part of an image; that would ruin her ability to use that same border in a different image, or the same image in a different context. You might find much more receptiveness for a proposal for some method of storing related layers and compositing information for use by such advanced programs. A format that allowed one to store grayscale layers, color layers, text layers, lossy photo layers, and compositing rules in a standard way would be much more useful and in keeping with the spirit of PNG. A nifty hack that does much less at similar conceptual expense is not. -- Lee Daniel Crocker "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC ---------------------- end of post -------------------------------- Lee, I recognize that it is often useful to keep all image components separate. Sometimes, though, it is not useful--one might desire that the change be downright indelible, for example. And when Photoshop can process my 20000x40000 by 12-bit greyscale image, I'll give the "toy" a shot... :-) Many folks here have already made me excrutiatingly aware that the MNG format already encapsulates many of the capabilities you would like to see in PNG. Also, Paul Schmidt's '.px' format will pretty much cover the same set of capabilities you mention. My goal is restricted, to offer a format with just _one_image_, in the same spirit that png does now. That format (png-16) will support color within a 16 bits/pixel space. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- http://www.graphicswiz.com/px <=- px format pages -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 11:23:54 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA08656 for ; Thu, 3 Sep 1998 11:23:54 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA13415; Thu, 3 Sep 1998 11:19:33 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA13411; Thu, 3 Sep 1998 11:19:32 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa20534; 3 Sep 98 12:16 EDT Message-ID: <35EEC0F3.9B7F0F95@alumni.rpi.edu> Date: Thu, 03 Sep 1998 12:16:51 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sbru3$i7l$1@nnrp1.dejanews.com> <6sd8ja$5j0$1@nnrp1.dejanews.com> <6si2p4$q3q$1@nnrp1.dejanews.com> <199809031513.KAA11156@x6.dejanews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit > Glenn, > > I'll have to experiment and try this out, Glenn. Thank you very much > for posting it. I don't think it will be a "speed demon" on 5000x6000 > images, but if it can save significant disk space, the time spent may > well be worthwhile. Yeah, maybe. By the way, after you've created the "I" array, run a blur filter over it to get rid of the dust flakes, if you have dusty images, before doing the iterations. It doesn't matter that the turbine or whatever gets blurred, because it's just a working array; you'll be restoring the unblurred original pixels at the end. A bit off-topic for PNG-list at this point, but I don't have instructions for redirecting to your Dejanews forum handy right now. If you want to reply, just reply to the forum and we can pick up the discussion there. I'd be interested in seeing some actual sample images for trying this stuff out myself. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 11:27:40 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA08763 for ; Thu, 3 Sep 1998 11:27:39 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA13580; Thu, 3 Sep 1998 11:24:46 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA13576; Thu, 3 Sep 1998 11:24:45 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa20576; 3 Sep 98 12:24 EDT Message-ID: <35EEC2AB.7ADBD12@alumni.rpi.edu> Date: Thu, 03 Sep 1998 12:24:11 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> <6sip34$kpd$1@nnrp1.dejanews.com> <199809031547.KAA11298@x6.dejanews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit > My goal is restricted, to offer a format with just _one_image_, in the > same spirit that png does now. That format (png-16) will support color > within a 16 bits/pixel space. Well, you don't need a new format to do that. PNG already does, via the private grYc chunk (should be grYC, though) that I posted the other day. Think "PNG is extensible". Just because we will probably not make grYC a public gRYC chunk any time soon doesn't mean it's unusable right now. Start using it, gather some statistics, gain a following. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 11:42:54 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA08984 for ; Thu, 3 Sep 1998 11:42:54 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA13847; Thu, 3 Sep 1998 11:36:23 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA13843; Thu, 3 Sep 1998 11:36:22 -0500 Received: from x6.dejanews.com (ix6.dejanews.com [10.2.1.197]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id LAA07337 for ; Thu, 3 Sep 1998 11:36:22 -0500 Received: (from www@dejanews.com) by x6.dejanews.com (8.7.6/8.6.12) id LAA12631; Thu, 3 Sep 1998 11:36:18 -0500 Message-Id: <199809031636.LAA12631@x6.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: ic16 (was: suggestion for png 1.1: gc16) Date: Thu, 03 Sep 1998 16:36:17 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.40 Organization: Deja News - The Leader in Internet Discussion References: <6sj516$2ea$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 16:36:17 1998 GMT X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.40 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------------- posted to png-list ---------------------------- Date: Wed, 02 Sep 1998 09:00:42 -0400 From: Glenn Randers-Pehrson Subject: Re: ic16 (was: suggestion for png 1.1: gc16) To: PNG List At 10:01 AM 9/2/98 GMT, Rich wrote: > > Most excellent ideas, Dude! If there were more than a two week window for >the 1.1 png spec, I'd propose it right now. Since you didn't give this >concept a name, let's call it 'ic16' (indexed color, 16-bit). A similar but better proposal already has a name, faLT (false-color palette). > I would add several pre-defined indexings. Why require a 192 kbyte or 384 >kbyte overhead to the image size faLT would have expressed the palette more efficiently by linear interpolation of missing entries. We debated and tuned faLT for more than a year. When I put it up for a vote, it only attracted two affirmatives and no negatives, so it failed. Glenn ---------------------- end of post -------------------------------- ------------------- posted to png-list ---------------------------- Date: Wed, 02 Sep 1998 08:53:54 -0400 From: Glenn Randers-Pehrson Subject: Re: ic16 (was: suggestion for png 1.1: gc16) To: PNG List At 10:01 AM 9/2/98 GMT, Dave wrote: > > Date: Wed, 2 Sep 1998 00:39:58 -0700 > From: Dave Martindale >Subject: Re: suggestion for png 1.1: gc16 > To: PNG List > >It occurs to me that if I *really* wanted to be able to store images >encoded with the proposed fc16, mc16, or gc16 encodings in a single PNG >file, this is what I would do: > >- Propose extending PNG to allow 16-bit indexed-colour images, so the > palette could have up to 65536 entries instead of 256. That wouldn't do anything about fc16's color cycling and HSV or whatever encoding or its internal intensity (gamma?) stuff. >- Propose adding a new pallette type whose entries are 16-bit R, G, B > (or RGBA) instead of 8-bit. How would this differ from the proposed and rejected fALS/faLT chunk? Had this chunk been approved, you could accomplish gc16 and mc16 with faLT (you'd want to revise gc16 to put the flag bit in the most significant bit, though, to get a more efficient palette). The false-color palette would look like 0 0 0 0 32k-1 64k-1 64k-1 64k-1 32k first overlay color 32k+16k second overlay color 64k third overlay color etc. The overlay colors are at widely spaced intervals so they'd be distinguishable if the faLT chunk were ignored. The true gray would be rendered at half intensity if faLT were ignored. This scheme would still have the disadvantage of overwriting the area covered by the annotations, though, isn't as efficient as writing a 1-byte grYc chunk, and is much less efficient and flexible than using MNG to store the annotations separately from the main image. Glenn ---------------------- end of post -------------------------------- ------------------- posted to png-list ---------------------------- Date: Wed, 2 Sep 1998 08:16:34 -0700 From: Greg Roelofs Subject: Re: suggestion for png 1.1: gc16 To: png-list@ccrc.wustl.edu > There can be no filesize savings > compared to the equivalent MNG which is bound to be smaller even > though it contains multiple images, because the two image types > will each be compressed in an optimal manner--combining them in > the gc16 method will interfere with optimal compression of both. Come now, Glenn. You have no proof of that. I'll grant that it's *probably* true, but just as there are certain GIF images that are smaller than PNGs (e.g., some 32- and 64-color ones), I'd bet that there will be cases where gc16 wins over MNG--if only because of its reduced chunk-count. We all need to be a little more careful of making unsubstantiated value judgments, too. "This is better than that" can in most cases be argued both ways, and blanket statements like that contribute to the sometimes less-than-friendly atmosphere that has driven at least a few people off the lists. (This is a common trait in most engi- neering-oriented lists I've seen; people have strong opinions and don't always tone them down before firing. I'm not pointing fingers at any one person, and I've certainly been guilty of it, too--but I'm trying to be nicer. :-) ) ... Greg ---------------------- end of post -------------------------------- Greg, Thanks for working to keep things "cool" here. It's obvious that for anyone to stick around and contribute regularly, he needs patience and a big, resilent, ego. I may posess both. Don't worry too much about how I might react to a given post; by now hopefully you can see that unfavorable\doubtful comments about my ideas are accepted gracefully. One of the neat things about this group is that many who disagree with me are able to put aside their fundamental opinion, go into a helpful "what if" mode, and offer useful ideas. Thanks, guys. -- Rich ------------------- posted to png-list ---------------------------- Date: Wed, 02 Sep 1998 14:11:14 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List Greg Roelofs wrote: > > Come now, Glenn. You have no proof of that. I'll grant that it's > *probably* true, but just as there are certain GIF images that are > smaller than PNGs (e.g., some 32- and 64-color ones), I'd bet that > there will be cases where gc16 wins over MNG--if only because of > its reduced chunk-count. OK, agreed. But in the context of 5k x 5k grayscale images with a 1k x 1k inset that should be encoded as indexed-color but is forced to be encoded as 32k color, MNG would win. In small images where 82 bytes of chunk overhead is significant, the single image method could win. Also, if the area in the grayscale that's being replaced with the annotation image is actually dark random noise instead of true black, the gc16 method could appear to win. The only way to find out is to code up a lot of typical images in gc16 and compare them with equivalent multiple-image files, which would provide experience but not proof. Glenn ---------------------- end of post -------------------------------- Glenn, I'm working on design now... -- Rich ------------------- posted to png-list ---------------------------- Date: Thu, 03 Sep 1998 08:11:32 -0400 From: Glenn Randers-Pehrson Subject: Re: ic16 (was: suggestion for png 1.1: gc16) To: PNG List At 09:39 AM 9/2/98 -0700, Dave wrote: >If I remember correctly, fALS/faLT was proposed as a way of specifying >false-colour display of 16-bit grey images. I can easily believe that >this mechanism would be more useful than fc16 and friends. Look at it this way: fALS/faLT is a general 16-bit palette with some efficiency in encoding (by linear interpolation of missing entries). gc16 is one particular predefined 16-bit palette. gc16 is to faLT as sRGB is to iCCP: gc16 is a way of passing a specific palette or profile by reference instead of by embedding it in the file. The question is whether that fixed 16-bit palette is useful enough to warrant putting advanced knowledge about it into decoders. A nice thing about that particular palette is that decoders that simply show the grayscale will get a reasonable image on-screen. Glenn ---------------------- end of post -------------------------------- Glenn, I'll be looking up your fALS/faLT proposal in the png-list archives. Maybe you could just e-mail me a formal draft. It sounds like an excellent idea, and if I had been a voting member of the group, I would have voted YES. All I can do now is incorporate it into png-16. Then there would be a test-bed to demonstrate its usefulness. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 12:00:26 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA09261 for ; Thu, 3 Sep 1998 12:00:17 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA14247; Thu, 3 Sep 1998 11:57:21 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA14243; Thu, 3 Sep 1998 11:57:16 -0500 Received: from x13.dejanews.com (ix13.dejanews.com [10.2.1.204]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id LAA07802 for ; Thu, 3 Sep 1998 11:57:17 -0500 Received: (from www@dejanews.com) by x13.dejanews.com (8.7.6/8.6.12) id LAA21774; Thu, 3 Sep 1998 11:57:15 -0500 Message-Id: <199809031657.LAA21774@x13.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: 16-bit Palette... Date: Thu, 03 Sep 1998 16:57:13 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.40 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Thu Sep 03 16:57:13 1998 GMT X-Http-Proxy: 1.0 x13.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.40 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------------- posted to png-list ---------------------------- Date: Wed, 2 Sep 1998 14:53:29 -0500 From: "Carl Morris" Subject: 16 bit palette... To: "PNG List" I while back, I recommended that PNG might have benefited from a 16bit palette option. Now the idea of FC16 has entered ... Personally, I think FC16 would be too complex to implement myself, and it wouldn't bring any benefit to many systems. Instead, I might comment that the idea of a 16 in 48 out palette system might work. I always felt that PNG should have as much versatility with its palette as it has with its true color modes... so both 16bit palette indices and 48bit palette values seem positive additions to PNG. I would note however, that something needs to be gotten across to the people who write support for PNG into their authoring programs... Just because a file is capable of 16, 256, or 65536 palette entries ... it doesn't have to contain all of them!!! :) Likewise for transparency ... it would be best for format the palette as to make the transparency table as small as possible... Carl Morris ---------------------- end of post -------------------------------- Carl, You can think of the png-16 format as a testbed for these ideas. The fc16 image type won't be too complex to work with; libpn6 will contain tools to convert between 24-bit (and 48-bit) RGB files and the SIH colorspace used by fc16. For the RGB -=> SIH conversion, there will also be an optimization flag that will utilize the 4000 indexed colors of fc16 to supplement the 16-bit SIH coverage of its colorspace. So between fc16, mc16, gc16, and ic16 (maybe soon to be renamed to one of Glenn's names (or maybe 'ic16' could be inclusive of both faLT and fALS)), there will definately be support for indexed palettes. Your point is well taken about only including what is necessary in a given image. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 12:45:55 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA10156 for ; Thu, 3 Sep 1998 12:45:54 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA15398; Thu, 3 Sep 1998 12:41:55 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA15394; Thu, 3 Sep 1998 12:41:54 -0500 Received: from x6.dejanews.com (ix6.dejanews.com [10.2.1.197]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id MAA08713 for ; Thu, 3 Sep 1998 12:41:55 -0500 Received: (from www@dejanews.com) by x6.dejanews.com (8.7.6/8.6.12) id MAA14011; Thu, 3 Sep 1998 12:41:53 -0500 Message-Id: <199809031741.MAA14011@x6.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: png-16 (dejanews & HTML) Date: Thu, 03 Sep 1998 17:41:52 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.197.40 Organization: Deja News - The Leader in Internet Discussion References: <6skmh8$ug5$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 17:41:52 1998 GMT X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 12.77.197.40 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List In article <6skmh8$ug5$1@nnrp1.dejanews.com>, rfranzen@my-dejanews.com wrote: > > (HTML test -- sorry if this garbles things up...) > > > That explains it! I work with image enhanced radiography every day. :-) >

> > If it is not already obvious from other posts, I retract the gc16 proposal > for png v1.1.

> > -- Rich
>
Well, phooie! Apparently DejaNews de-HTML-ulates all postings. It makes sense to prevent, say, the inclusion of pictures of naked ladies within a technical News group (even if those pictures did use the png format :-). But what's wrong with a little bold among friends? They should just garble "IMG", "OBJECT", "SRC", and "EMBED". Of course then they'd have to parse the whole message to determine whether '<' were being used as a less-than or as an HTML tag-introducer. (Why didn't HTML use { .. } for html tags? Braces are certainly a lot less common than less-than's and greater-than's.) -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 13:06:26 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA10424 for ; Thu, 3 Sep 1998 13:06:20 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA15609; Thu, 3 Sep 1998 12:59:39 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA15605; Thu, 3 Sep 1998 12:59:37 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id KAA24706; Thu, 3 Sep 1998 10:59:19 -0700 (PDT) Date: Thu, 3 Sep 1998 10:59:19 -0700 (PDT) Message-Id: <199809031759.KAA24706@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: quotations in replies From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List rfranzen@my-dejanews.com says: [192 lines of quoted material and 9 lines of new content, in a message sent to 91 destinations.] Let's all show some restraint with the quotations, okay? My opinions on the matter are documented at: http://www.cs.berkeley.edu/~amc/soapbox/reply-quotation.html Thanks, AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 14:00:56 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA11000 for ; Thu, 3 Sep 1998 14:00:55 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA16703; Thu, 3 Sep 1998 13:52:07 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA15979; Thu, 3 Sep 1998 13:20:54 -0500 Received: (qmail 8563 invoked from network); 3 Sep 1998 18:22:05 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 3 Sep 1998 18:22:05 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id LAA25219 for ; Thu, 3 Sep 1998 11:20:54 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA00236 for png-list@dworkin.wustl.edu; Thu, 3 Sep 1998 11:21:43 -0700 Date: Thu, 3 Sep 1998 11:21:43 -0700 Message-Id: <199809031821.LAA00236@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: Undeliverable: Re: suggestion for png 1.1: gc16 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List [Alas, the stupid majordomo program intercepted this message, and now those who most needed to see it are unsubscribed. Double bah. I'll cc the four of them separately. --Greg] This is just a last-minute warning in case any Microsoft people *are* getting png-list mail correctly: I have just been spammed by the Microsoft postmaster with more than a dozen completely useless bounce messages, each 20-30K in size. Since there is no useful indication who is actually bouncing, I'm going to unsubscribe all microsoft.com addresses. If you get this message OK, please feel free to resubscribe yourself right away. If you discover this message by looking through the list archives, please tell your pinhead mail admins to fix their mailer bugs. Bah. FYI, I've appended the top part of one of the messages. And I do apologize for the inconvenience. (Douglas Adams would be proud. :-) ) Greg >From <@@ccrc.wustl.edu> Thu Sep 3 10:04:41 1998 Return-Path: <@@ccrc.wustl.edu> From: System Administrator To: owner-png-list@ccrc.wustl.edu Subject: Undeliverable: Re: suggestion for png 1.1: gc16 Date: Thu, 3 Sep 1998 10:00:58 -0700 X-MS-TNEF-Correlator: <2BF7D4F5AFEAD111BC4D00805F57D3980358D510@INET-IMC-01> X-Mailer: Internet Mail Service (5.5.2232.9) Your message To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Sent: Wed, 2 Sep 1998 01:21:32 -0700 did not reach the following recipient(s): /o=MICROSOFT/ou=NORTHAMERICA/cn=RECIPIENTS/cn=415123 on Thu, 3 Sep 1998 10:00:44 -0700 The recipient name is not recognized MSEXCH:MSExchangeMTA:northamerica:SJC-MSG-01 begin 600 winmail.dat M>)\^(CP1`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<` [etc.] -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 14:40:41 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA11801 for ; Thu, 3 Sep 1998 14:40:40 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA17505; Thu, 3 Sep 1998 14:37:08 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA17501; Thu, 3 Sep 1998 14:37:02 -0500 Received: from x8.dejanews.com (ix8.dejanews.com [10.2.1.199]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id OAA11569 for ; Thu, 3 Sep 1998 14:37:03 -0500 Received: (from www@dejanews.com) by x8.dejanews.com (8.7.6/8.6.12) id OAA19697; Thu, 3 Sep 1998 14:37:01 -0500 Message-Id: <199809031937.OAA19697@x8.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Thu, 03 Sep 1998 19:37:00 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.129.18 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sakb3$aee$1@nnrp1.dejanews.com> <6sbrkt$i3s$1@nnrp1.dejanews.com> <6si13m$o7i$1@nnrp1.dejanews.com> <6sip34$kpd$1@nnrp1.dejanews.com> <6smdll$m7t$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 19:37:00 1998 GMT X-Http-Proxy: 1.0 x8.dejanews.com:80 (Squid/1.1.22) for client 12.77.129.18 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------------- posted to png-list ---------------------------- Date: Thu, 03 Sep 1998 12:24:11 -0400 From: Glenn Randers-Pehrson Subject: Re: suggestion for png 1.1: gc16 To: PNG List > My goal is restricted, to offer a format with just _one_image_, in the > same spirit that png does now. That format (png-16) will support color > within a 16 bits/pixel space. Well, you don't need a new format to do that. PNG already does, via the private grYc chunk (should be grYC, though) that I posted the other day. Think "PNG is extensible". Just because we will probably not make grYC a public gRYC chunk any time soon doesn't mean it's unusable right now. Start using it, gather some statistics, gain a following. Glenn ---------------------- end of post -------------------------------- Glenn, For a real testbed of everything I want png-16 to do, I need a different format (.pn6). It will have its own library (libpn6), and applications using it will need the capabilities of zlib, libpng, and libpn6 to be "compliant". I expect not more than 0 existing png apps will adopt features such as SIH colorspace, color cycling, and transparency as a color rather than overlay. At least not until it is proven that this thing is actually useful and meets a common need. In my first app, though, I'll have a conversion capability for the gc16, mc16, and ic16 (faLT\fALS) image types to be output as a .png image, but using the private chunks. I still don't know how many readers will utilize these private chunks, but if you feel that this is one way to legitimacy, I'll give it a shot. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 15:27:11 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id PAA12802 for ; Thu, 3 Sep 1998 15:27:10 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA18188; Thu, 3 Sep 1998 15:13:34 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA18184; Thu, 3 Sep 1998 15:13:24 -0500 Received: from x8.dejanews.com (ix8.dejanews.com [10.2.1.199]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id PAA12581 for ; Thu, 3 Sep 1998 15:13:25 -0500 Received: (from www@dejanews.com) by x8.dejanews.com (8.7.6/8.6.12) id PAA20933; Thu, 3 Sep 1998 15:13:23 -0500 Message-Id: <199809032013.PAA20933@x8.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: png-list clutter and apology Date: Thu, 03 Sep 1998 20:13:22 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.129.18 Organization: Deja News - The Leader in Internet Discussion References: <6sj516$2ea$1@nnrp1.dejanews.com> <6smgi1$pr6$1@nnrp1.dejanews.com> X-Article-Creation-Date: Thu Sep 03 20:13:22 1998 GMT X-Http-Proxy: 1.0 x8.dejanews.com:80 (Squid/1.1.22) for client 12.77.129.18 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List ------------------ posted to png-list ------------------------- Date: Thu, 3 Sep 1998 10:59:19 -0700 (PDT) From: amc:AT:cs.berkeley.edu (Adam M. Costello) Subject: quotations in replies To: png-list@ccrc.wustl.edu rfranzen@my-dejanews.com says: [192 lines of quoted material and 9 lines of new content, in a message sent to 91 destinations.] Let's all show some restraint with the quotations, okay? My opinions on the matter are documented at: http://www.cs.berkeley.edu/~amc/soapbox/reply-quotation.html Thanks, AMC --------------------- end of post -------------------------------- Adam (and other png-list subscribers), I apologize. My focus was on what I wanted to get recorded, and not how rude it would be to the people re-receiving the information. My (lame) excuse is that there are not just the 91 destinations which Adam maintains, but a 92nd destination that I maintain, the png-16 forum at dejanews. To keep things simple (for me), I have been cross-posting all png-16 related messages from the png-list to the png-16 forum. My replies to the messages went two places at once, yours and mine. So from the point of view of the png-16 forum, the citations were not being echoed, they were showing up for the first time in my replies. But from everyone else's point of view, there was tons of repeated info. I'll find a different way to do this. One way that png-list members might help clean things up is to use the png-16 forum for png-16 related posts. If the subject was general enough that you think that png-list members might wish to see it as well, then you could cross-post at the original posting time. If the message is png-16 only, then don't cross-post, and png-list members not interested in png-16 won't see them. So if you want to reply to this message, and not clutter the png-list any more, just click on the DejaNews link below. Hunt for the topic "png-list clutter and apology", click on the message, and this posting will appear there. Hit the [Reply] button on that page, and no one on the png-list will see. If you are not a registered with DejaNews, I think it will intercept your [Reply] request and have you register. Registration is free, and I haven't received any junk e-mail as a consequence of registering. In fact, their e-mail service claims to be "SPAM free", if you get and use one of their addresses. -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 18:20:01 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id SAA14630 for ; Thu, 3 Sep 1998 18:20:01 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA21533; Thu, 3 Sep 1998 18:17:30 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA21529; Thu, 3 Sep 1998 18:17:28 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id TAA24339; Thu, 3 Sep 1998 19:17:22 -0400 Message-Id: <1.5.4.32.19980903231306.00fcf62c@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, 03 Sep 1998 19:13:06 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG spec and 32K sliding window Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 05:43 PM 9/2/98 +0200, Jean-loup wrote: >Glenn writes: > >> So "decoders must accept any power-of-two window size from 512 bytes >> up to and including 32 kilobytes." Also, the value that encoders write >> in the CINFO bits must indicate a window that is equal to or greater than >> the window size that they actually used, and not greater than 32 kilobytes. >> (It's always OK to write "7", meaning "32 kilobytes".) > >Just to make Greg happy :-) : Glenn's clarification is fine. Use >"32768 bytes" instead of "32 kilobytes" if you want to be extra-precise. OK. In fact, maybe we should also add a recommendation that encoders encode the actual window size that the decoder will need, so the decoder doesn't have to request a large buffer when a samll one would suffice. Since the encoder knows the width, height, and bits per pixel before it starts encoding the image data, it can set an upper limit of estimated_window_size = ((bits_per_pixel*width+15)/8)*height; and then encode the next higher power-of-two in the zlib header. If it is a nonstreaming encoder, zlib could keep track of the maximum distance code actually written in the file and report it. Then the calling application (e.g., pngcrush) could go back and compute the smallest windowsize that fits, and encode that into the zlib header bits. I think that distance is available at the places in deflate.c where _tr_tally_dist() is called. max_distance = max(max_distance, s->strstart - s->match_start) + MIN_MATCH; maybe a few bytes more for lookahead and whatnot? Would that work? Would there be a special case when a preset dictionary is present (doesn't affect PNG or MNG)? Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Sep 3 20:06:18 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA15652 for ; Thu, 3 Sep 1998 20:06:18 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA23076; Thu, 3 Sep 1998 19:57:37 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA23072; Thu, 3 Sep 1998 19:57:36 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id UAA28702; Thu, 3 Sep 1998 20:57:37 -0400 Message-Id: <1.5.4.32.19980904005320.00fc2a78@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, 03 Sep 1998 20:53:20 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: NS-4.06 peculiarity with bKGD Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Netscape Communicator 4.06 renders pixels with color {0,0,0} in the bKGD color, despite the fact that nothing in the PNG file says that {0,0,0} is transparent. I observed this in an image with color_type 2. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Sep 4 00:09:50 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id AAA17325 for ; Fri, 4 Sep 1998 00:09:49 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA27700; Fri, 4 Sep 1998 00:08:47 -0500 Received: from pedigree.cs.ubc.ca by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA27696; Fri, 4 Sep 1998 00:08:46 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id WAA11019 for ; Thu, 3 Sep 1998 22:08:40 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199809032013.PAA20933@x8.dejanews.com> References: <6sj516$2ea$1@nnrp1.dejanews.com> <6smgi1$pr6$1@nnrp1.dejanews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Sep 1998 22:08:35 -0700 To: PNG List From: Dave Martindale Subject: Re: png-list clutter and apology Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > So if you want to reply to this message, and not clutter the png-list >any more, just click on the DejaNews link below. Hunt for the topic >"png-list clutter and apology", click on the message, and this posting will >appear there. Hit the [Reply] button on that page, and no one on the png-list >will see. That really isn't very practical for me. I don't normally read news from DejaNews, nor do I use a WWW browser to read news. I read mail that comes to me personally (including via the png-list) and news articles that happen to make it to the university news server. Anything that doesn't appear in one of those two places is a significant extra effort. If it's relevant to PNG, I suggest the discussion continue in the PNG mailing list. And if it isn't relevant to PNG, I don't want to see it. (This is not a comment on the quality of discussion that happens only in the DejaNews group - just a statement that I have too many things competing for not enough time). Dave -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Sep 4 08:46:28 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA21063 for ; Fri, 4 Sep 1998 08:46:27 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA07156; Fri, 4 Sep 1998 08:41:08 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA07152; Fri, 4 Sep 1998 08:41:07 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA17899; Fri, 4 Sep 1998 09:41:01 -0400 Message-Id: <1.5.4.32.19980904133644.00fc2f04@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, 04 Sep 1998 09:36:44 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG spec and 32K sliding window Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 07:13 PM 9/3/98 -0400, I wrote: > max_distance = max(max_distance, s->strstart - s->match_start) > + MIN_MATCH; There's a misplaced ")" that should be moved to the end: max_distance = max(max_distance, s->strstart - s->match_start + MIN_MATCH); Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Sep 4 23:03:07 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA28772 for ; Fri, 4 Sep 1998 23:03:06 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA24296; Fri, 4 Sep 1998 23:01:27 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA24292; Fri, 4 Sep 1998 23:01:18 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id VAA26479; Fri, 4 Sep 1998 21:01:11 -0700 (PDT) Date: Fri, 4 Sep 1998 21:01:11 -0700 (PDT) Message-Id: <199809050401.VAA26479@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: comments on pngextensions-19980830.txt From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Most of these comments pertain to style issues, but some pertain to content. > Name Multiple Ordering constraints > OK? > > oFFs No Before IDAT > pCAL No Before IDAT > sCAL No Before IDAT > sPLT Yes Before IDAT > gIFg Yes None > gIFt Yes None > gIFx Yes None > fRAc Yes None I suggest removing gIFt from this summary and changing the line for gIFg: gIFg No Before IDAT (See also my comments on the GIF section below.) > 4.1. oFFs Image Offset > > The "oFFs" chunk... The ASCII rendering of the main PNG spec does not put quotes around chunk names in situations like this. This comment applies throughout the extensions document, but this is the only time I will mention it. > Image_position, X axis: 4 bytes (signed integer) > Image_position, Y axis: 4 bytes (signed integer) > Unit_specifier: 1 byte > > Both position values are signed. The following values are legal > for the "Unit_specifier": In the main PNG spec, underscores do not appear in chunk field names; they appear only in formulas and example code in the later chapters. Also, in the main PNG spec chunk field names are not surrounded by quotes nor capitalized when they appear in paragraphs. They are treated more like noun phrases than formal names. This comment applies throughout the extensions document, but this is the only time I will mention it. > n bytes: Purpose (Latin-1 text) > > 1 byte: null separator [etc.] In the chunk descriptions in the main PNG spec, and in the older ones in the extensions document, the summary of fields is presented as: Field name: n bytes (format) Any comments that require full sentences are deferred to the paragraphs that follow the field listing. This comment applies to all new chunk descriptions. > 4 bytes: X1 (signed integer) Upper limit of original > sample range. This original sample value is > mapped to the stored sample value > (2^Sample_depth - 1). Must not equal X0. The main PNG spec always says (2^sampledepth)-1 or (2^bitdepth)-1. Notice the lower case, lack of underscore, and grouping. This comment applies several times... > The "Purpose" string must > follow the format of a "tEXt" keyword, i.e., 1-79 printable > Latin-1 characters, without leading, trailing, or consecutive > blanks. We might want to use the wording from iCCP: ...subject to the same restrictions as a tEXt keyword: it must contain only printable Latin-1 [ISO/IEC-8859-1] characters (33-126 and 161-255) and spaces (32), but no leading, trailing, or consecutive spaces. (In the tEXt, zTXt, and iCCP descriptions, "1-79 bytes" appears in the field listing.) > One way the "Purpose" field could be used s to identify > the system of units. Typo: "s" should be "is". > Encoders will usually set "(X0 = 0)" and "(X1 = M)" to indicate > that the stored samples are equal to the original samples. The quotes and parentheses are distracting. > The mapping algorithms are The mapping functions are > Original_sample = > (Stored_sample * (X1 - X0) + M/2) / M + X0 The main PNG spec would not have capitalized Original_sample and Stored_sample. This comment applies many times... > using integer arithmetic, where "(a/b)" means > "(integer(floor(real(a)/real(b))))". Note that this is the same > as the "/" operator in the C programming language when "a" and "b" > are nonnegative, but not necessarily when "a" or "b" is negative. The quotes and outermost parentheses are distracting. This comment applies in several places... If the variable a without quotes is confusing, use capital variables A and B. It would be helpful to use the phrase "round toward negative infinity". > if Equation_type = 0 then I think the main PNG spec would have used English rather than pseudocode: If the equation type is 0 then: foo = bar... If the equation type is 1 then: foo = bar... > SINH(x) = 0.5 * ( EXP(x) - EXP(-x) ) I think I prefer lower case sinh() and exp() and abs(). This comment applies several times... > Pure logarithmic data can be expressed either with either > "Equation_type" 1 or "Equation_type 2": Typo: remove the first "either". > P2 = LOGe(max/min) P2 = max/min I think ln() is more understandable than LOGe(). > Using "Equation_type" 3, floating-point data in the range [- > v0..v1] can be reduced (with loss) to a set of integer samples If possible, inhibit line breaks in situations like this. > P0 = 0.0 > P1 = 1.0e-30 > P2 = 280.0 > P3 = 32767.0 We might want to provide an example of shaving unnecessary bytes: P0 = 0 P1 = 1e-30 P2 = 280 P3 = 32767 On the other hand, maybe it's more important to remind the reader that these are floating-point values. I don't really care. > 4.4. sPLT Suggested Palette I am deliberately not (yet) commenting on this section, because I'm considering writing a patch-style draft that would incorporate sPLT into the main spec, to see what would be required and what that would look like. It can be a separate patch from the gamma-fix patch, because it involves entirely different sections of the spec. > 5.1. gIFg GIF Graphic Control Extension I suggest appending the following paragraph to this section: The GIF specification allows at most one Graphic Control Extension to preceed each graphic rendering block. Because each PNG file holds only one image, gIFg may appear at most once, and must appear before IDAT if present. > 5.2. gIFt GIF Plain Text Extension I suggest inserting: The gIFt chunk was originally provided for backwards compatibility with the GIF89a Plain Text Extension, but gIFt is now deprecated because it suffers from a fundamental design flaw. GIF considers a Plain Text Extension to be a graphic rendering block, just like an image, so a GIF stream containing an image and a Plain Text Extension is really a multi-image stream with ordering issues (like associating each Graphic Control Extension with the proper graphic rendering block). PNG, being a single-image format with no provisions for handling these ordering issues, may contain IDAT or gIFt but not both. IDAT is required, hence gIFt is forbidden. For historical reference, the gIFt specification appears in appendix [deprecated chunks]. The appendix can include an additional remark about the other design flaw--the lack of transparency information in the foreground and background colors. > This chunk was registered with good intentions, on the > understanding that a full specification would be forthcoming in a > timely manner. Implementation and testing of the "fRAc" chunk > have been delayed by unforeseen complications. The PNG > maintainers do not intend to register any other future chunks > until they have been fully specified. This sounds too much like a chastisement. I would replace the whole paragraph with a short statement like: In the future, chunks must be fully specified before they are registered. > 9. Appendix: Sample code The gamma lookup example code can go in a new section 9.2. It is available from http://www.cs.berkeley.edu/~amc/png/gamma-lookup.c. > /* Sample code for the PNG pCAL chunk */ In general, I recommend more white space in the sample code, both horizontal and vertical. In particular, put spaces around all keywords (like "if"), and before left braces, and around assignment and arithmetic operators whenever either side is more complex than a single variable or constant. For example, instead of: > isample=.5+log((physical_value[k] > -p[0])/p[1])*factor; I would write: isample = 0.5 + factor * log((physical_value[k] - p[0]) / p[1]); > unsigned short limit(long low, double x, long high) This function should have a comment saying what it does. Also I find it odd that the limits are longs but the return value is an unsigned short. I think they should be the same type. > if(x < low)return low; > else if (x > high) return high; > else return x; Others might disagree, but I find this more readable: if (x < low) return low; if (x > high) return high; return x; > int pCAL_encode (unsigned short *stored_sample, long n, > float *physical_value, unsigned int m, int equation_type, > long x0, long x1, float *p) It's very rare that I ever see code that uses float (as opposed to double). All the libraries take doubles. I don't know about the relative costs of doing all calculations on doubles vs. doing some on doubles and some on floats and sometimes converting between the two formats. To avoid drawing attention to unimportant things, I think example code should stick to doubles unless it's trying to illustrate an optimization that requires floats. > stored_sample[k]= floor(((osample-x0)*dm > +floor(d/2))/d); This idiom appears several times. There is no need to use floating point when translating between stored samples and original samples, which are both integers. The following function will probably be useful: /* Integer division that rounds downward (toward negative infinity): */ long div_rd(long num, long denom) { long quot = num / denom; long rem = num % denom; if (denom >= 0) { if (rem < 0) return quot - 1; } else { if (rem > 0) return quot - 1; } return quot; } > if (x1 != x0) { [lots of code] > } > else return (-1); /* ERROR, x0 == x1 */ We can reduce the nesting level of all that code in the middle by reversing the sense of the test: if (x1 == x0) return -1; /* ERROR */ [lots of code] By the way, I don't put parentheses around return values because it makes "return" look like a function, which it's not. > * First, the "{X0,X1}" mechanism provides a way to map > stored values back to digitizer output, and to help > recover the original data, losslessly, when the original > range is not a power of two. Sometimes the digitized > values do not have a range that fills the full depth of a > PNG. For example if the full range of an image is 0-800 > and one wants to stretch the contrast and increase the > bit depth to 16 bits, one can do it and leave a record > that this has been done, by setting "X0=0" and "X1=800". > The reason to do this is to know the original granularity > in the data, which is useful at least as a lower limit on > the error in the data. We're not increasing the depth to 16 bits because we "want" to. 8 bits is not sufficient and the next larger legal bit depth is 16. Also, the second case covers stretching an image, so this case should just talk about conforming to PNG's requirements. How about this: * First, X0 and X1 provide a way to recover the original data, losslessly, when the original range is not a power of two. Sometimes the digitized values do not have a range that fills the full depth of a PNG. For example, if the original samples range from 0 (corresponding to black) to 800 (corresponding to white), PNG requires that these samples be scaled to the range 0 to 65535. By recording X0=0 and X1=800 we can recover the original samples, and we indicate the precision of the data. > * A second use is that the "{X0,X1}" parameters can be used > to mark the limited range of an original image that is > contained in the current image. In this scenario there > is an original image that has important detail in a > limited intensity range. The limited range is extracted > and contrast stretched to fill the PNG bit depth. There > is no way in "pCAL" to distinguish these cases but at > least "pCAL" can store the relevant information. People > can distinguish these cases by including a text chunk > labelling the image as original or derived. How about this: * Even if the original data had a range identical to a valid PNG image sample, like 0 (black) to 65535 (white), one might want to create a derived image by stretching the contrast in a limited intensity range containing the important details. For example, we might want to scale the samples so that 46000 becomes 0 (black) and 47000 becomes 65535 (white). As in the previous case, by recording X0=46000 and X1=47000, we can recover the original data samples that fell between 46000 and 47000. > * Finally, "X0" is necessary in several of the equation > types to allow a zero offset. Without it, we'd need an > extra parameter in equation types 1 and 2. I don't buy this. The two mappings are independent. If an offset is needed in the mapping between physical values and original samples, then nothing you do regarding the mapping between original samples and image samples is going to provide it. I recommend removing this paragraph. > Why define integer division ("(a / b)" means > "(integer(floor(real(a) / real(b))))")?. This is different > from many "C" implementations and from all Fortran > implementations, which truncate toward zero. > > We want to avoid any surprises due to differences in "C" > compiler implementations. Also, if we were to depend upon > division truncating toward zero, we'd have to account for a > discontinuity at "Original_sample" value zero. Zero would > represent twice as large a range of physical values: > > * zero would represent (-1+epsilon to 1-epsilon) > * positive n would represent (n to n+1-epsilon) > * negative n would represent (n-1+epsilon to n) > > where "epsilon" is the difference between "n" and the closest > representable real number that is different from "n". But, as > we have defined integer division, all samples represent the > same range: > > * any n represents (n to n+1-epsilon) How about: Why define integer divison to round toward negative infinity? This is different from many C implementations and from all Fortran implementations, which round toward zero. We cannot leave the choice unspecified. If we were to specify rounding toward zero, we'd have to account for a discontinuity at zero. A division by positive d would map 2d-1 values to zero (-(d-1) through d-1) but would map only d values to any other value (for example, 3d through 4d-1 would be mapped to 3). Achieving lossless mappings in spite of this anomaly would be difficult. By the way, I can't verify the claim about Fortran, so I hope someone has looked that up. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 03:31:26 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id DAA00910 for ; Sat, 5 Sep 1998 03:31:25 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA28380; Sat, 5 Sep 1998 03:30:25 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA28376; Sat, 5 Sep 1998 03:30:24 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id EAA26751; Sat, 5 Sep 1998 04:30:23 -0400 Message-Id: <1.5.4.32.19980905082608.00fd7a5c@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, 05 Sep 1998 04:26:08 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: comments on pngextensions-19980830.txt Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 09:01 PM 9/4/98 -0700, Adam wrote: >> The "oFFs" chunk... > >The ASCII rendering of the main PNG spec does not put quotes around >chunk names in situations like this. This comment applies throughout >the extensions document, but this is the only time I will mention it. >> Both position values are signed. The following values are legal >> for the "Unit_specifier": > >In the main PNG spec, underscores do not appear in chunk field names; We can decide how the PNG spec will handle these things. The PNG 1.0 spec uses underscores in the more recently written parts (file_gamma, etc.) The style in the recent version of the extensions document was a result of offline discussion with Greg. Yes, we ought to settle on a consistent style for the entire series, PNG, MNG, and extensions. In the PostScript and HTML, quotation marks aren't needed because field variables are set in a different (monospace) font via the TT tag. There are a lot of possibilities: first character: always uppercase, always lowercase, uppercase only when beginning a sentence. embedded blanks: blank, underscored blank, start subsequent words with uppercase and no blank. quotation marks: single, double, none, angle brackets, French quotes (ASCII 171 and 187), and they could appear only in the ASCII text version or in all versions. Thus, we can have, among others: PostScript/HTML ASCII text bit_depth "bit_depth", 'bit_depth', bit_depth Bit_depth "Bit_depth", 'Bit_depth', Bit_depth Bit_Depth "Bit_Depth", 'Bit_Depth', Bit_Depth Bit depth "Bit depth", 'Bit depth', Bit depth Bit Depth "Bit Depth", 'Bit Depth', Bit Depth bitdepth "bitdepth", 'bitdepth', bitdepth Bitdepth "Bitdepth", 'Bitdepth', Bitdepth BitDepth "BitDepth", 'BitDepth', BitDepth BIT_DEPTH "BIT_DEPTH", 'BIT_DEPTH', BITDEPTH BITDEPTH "BITDEPTH", 'BITDEPTH', BITDEPTH BITDEP "BITDEP", 'BITDEP', BITDEP width "width", 'width', width Width "Width", 'Width', Width WIDTH "WIDTH", 'WIDTH', WIDTH We could, of course, also put quotation marks of one kind or another in the HTML and PostScript. In the PostScript, there are different left and right quotation marks, which don't look too bad, but might be distracting. See MNG PostScript/HTML Draft 46 which has them, and Draft 47, from which I removed them to be consistent with the extensions document. The quotation marks seem to be overkill in the PostScript where the monospace font is clearly different from the regular font. In the HTML, it might look different or nearly the same or exactly the same, depending on the browser and the user's "appearance" settings. In MNG, it's pretty much necessary to set off some of the variable names like do not show to maintain readability. We want to select the most attractive method that is still readable. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 09:56:14 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id JAA03159 for ; Sat, 5 Sep 1998 09:56:13 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA05025; Sat, 5 Sep 1998 09:54:25 -0500 Received: from www10.w3.org by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA05021; Sat, 5 Sep 1998 09:54:24 -0500 From: angeloso@islatortuga.com Received: from server.local.red ([195.77.76.203]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id KAA28602 for ; Sat, 5 Sep 1998 10:54:17 -0400 (EDT) X-Authentication-Warning: www10.w3.org: Host [195.77.76.203] claimed to be server.local.red Received: from angeloso (angel.local.red [10.0.0.2]) by server.local.red (8.9.0/8.9.0) with SMTP id QAA31997; Sat, 5 Sep 1998 16:56:48 +0200 Date: Sat, 5 Sep 1998 16:56:48 +0200 Subject: 3-S, un exito, Y ahora que? Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Apparently-To: Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Como todos sabreis la huelga de ayer fue todo un exito, aunque "algunos" se empeñen en decir que no. Pero una cosa esta clara, exito o no, el caso es que conseguimos que todo el mundo (nunca mejor dicho) se fijase en nosotros. Pero y ahora que? En la huelga, todavia quedan bastantes acciones por realizar, que seran mas o menos efectivas, pero donde mas le duele a Timofonica es en el bolsillo. Recordad la prepotencia de Timofonica, y que esta gente aplicara el dicho de "Gritad, Gritad, pero al final tendreis que pagar". Pero y si en vez de pagarles a ellos, pagamos en otro sitio que tenga validez legal? No te pueden cortar el timofono y de paso, no ingresan esas cantidades en sus arcas. Existe un precendente con la compañia de Aguas de Barcelona, donde los afectados, denunciaron a dicho monopolio, y el juez ordeno que mientras dure el contencioso, el dinero no se entrege a Aguas de Barcelona, sino que se ingrese en una cuenta especial en "La Caixa" destinada a tal fin. En pocos meses se llevan ingresados mas de 1.300 millones que la compañia del Agua no puede ingresar. Pues bien toda esta informacion al respecto y como lo vamos a hacer LEGALMENTE la hemos puesto disponible en la siguiente direccion web http://www.timofonica.com , ademas de unas direcciones e-mail y web donde dirigirse para secundar esto. visitad dicha pagina y unios, en menos de 24 desde la protesta del dia 3, mas de 200 personas, ya se han sumado. Salu2 Angeloso :-D.................... -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 10:49:25 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA03461 for ; Sat, 5 Sep 1998 10:49:25 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA06114; Sat, 5 Sep 1998 10:46:48 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA06110; Sat, 5 Sep 1998 10:46:47 -0500 Received: (qmail 8202 invoked from network); 5 Sep 1998 15:48:01 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 5 Sep 1998 15:48:01 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id IAA19033 for ; Sat, 5 Sep 1998 08:46:46 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id IAA27595 for png-list@ccrc.wustl.edu; Sat, 5 Sep 1998 08:47:46 -0700 Date: Sat, 5 Sep 1998 08:47:46 -0700 Message-Id: <199809051547.IAA27595@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: comments on pngextensions-19980830.txt Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Adam wrote: > In the main PNG spec, underscores do not appear in chunk field names; > they appear only in formulas and example code in the later chapters. > Also, in the main PNG spec chunk field names are not surrounded by > quotes nor capitalized when they appear in paragraphs. They are > treated more like noun phrases than formal names. As Glenn noted, I instigated this change, because multiple conventions were being used across the four documents (PNG, MNG, extensions, scivis) and in some cases within a single document (extensions, at least). Since all of the documents are being revised (scivis via inclusion into exten- sions), this seemed like an excellent time to come up with a uniform scheme. Glenn also noted that there are several options for such a scheme, in- volving underscores, capitalization, and "context-sensitive" quotes, and he brought up the "do not show" variable in MNG. That's a particularly good example, but there are many fields throughout all of the documents that have multi-word names. Since these names are not only used as vari- ables in many places but effectively *are* variables, I very strongly feel that the underscores are required wherever such a field is being referenced in a non-generic way (i.e., allowed values, specific inter- pretation, etc.). This is familiar to most programmers and makes the spec considerably more understandable in places. As for capitalization, I don't care so much about that, but I do think it should be consistent, regardless of where the variable ends up in a sentence. Since most people don't like to start sentences with lowercase words and since leading-uppercase field names were already in use, I suggested we stick with that. Finally, the use of quotes in the ASCII text is necessary in a number of places where single-word variables are used and can be mistaken for English text. As Glenn said (and Adam noted in the case of some inlined equations), quotes in addition to the monospaced font can be somewhat distracting in the PostScript and HTML versions (and were for me), so I suggested that they be removed. This was also an area where the usage was inconsistent across documents. So, to summarize, field names (variables) are currently proposed to look like this: Pixels_per_unit "Pixels_per_unit" Purpose "Purpose" ...where the left column refers to PostScript/HTML (typically Courier font) and the right is the ASCII text version. Note that there are still a few places where the quotes are slightly misplaced; these are simply formatting typos. > The main PNG spec always says (2^sampledepth)-1 or (2^bitdepth)-1. I agree that the placement of the parentheses is better in this case. >> using integer arithmetic, where "(a/b)" means >> "(integer(floor(real(a)/real(b))))". Note that this is the same >> as the "/" operator in the C programming language when "a" and "b" >> are nonnegative, but not necessarily when "a" or "b" is negative. > The quotes and outermost parentheses are distracting. This comment > applies in several places... If the variable a without quotes is > confusing, use capital variables A and B. I don't find the quotes around single-character elements distracting, but if they are to be removed, I'd suggest using v1 and v2 as variable names (or var1 and var2). > I think I prefer lower case sinh() and exp() and abs(). This comment I also prefer those, actually (and ln() as well, except that it can look like 1n or In if not accompanied by parentheses). > On the other hand, maybe it's more important to remind the reader that > these are floating-point values. I don't really care. I think it would be a useful reminder to implementers (especially those at Adobe, ahem) that size matters. I would include both in this one case. > The GIF specification allows at most one Graphic Control Extension > to preceed each graphic rendering block. Because each PNG file > holds only one image, gIFg may appear at most once, and must appear > before IDAT if present. I don't think we can retroactively restrict the count on a chunk that was explicitly allowed to appear multiple times in a previous document. In other words, we can't suddenly redefine certain images that used to be legal as illegal now. Instead, include a similar paragraph that says multiple gIFg's are strongly discouraged. > gIFt but not both. IDAT is required, hence gIFt is forbidden. Again, you can't retroactively illegalize(?) formerly valid PNG images any more than you can unregister formerly valid chunks. It's deprecated; encoders/converters are strongly encouraged never to use it in a PNG stream (although MNG may still be OK); decoders are recommended to ignore it; editors are recommended to drop it. But its use cannot be forbidden. >> This chunk was registered with good intentions, on the >> understanding that a full specification would be forthcoming in a >> timely manner. Implementation and testing of the "fRAc" chunk >> have been delayed by unforeseen complications. The PNG >> maintainers do not intend to register any other future chunks >> until they have been fully specified. > This sounds too much like a chastisement. It was specifically worded to indicate that chastisement is *not* intended ("unforeseen complications"). And I think we *must* say something--the document says you can send e-mail here and get the chunk specification, but you can't, so why is the chunk listed at all? Bad precedent. (Note that I originally suggested striking the entire section; unlike the GIF chunks, there's no way fRAc could ever have been used in a PNG image, so removing it would not invalidate anything.) I have no problem with replacing the final sentence with your suggestion, however: > In the future, chunks must be fully specified before they are > registered. That's better wording, regardless. > In general, I recommend more white space in the sample code, both > horizontal and vertical. Agreed. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 13:33:30 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA04507 for ; Sat, 5 Sep 1998 13:33:30 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA09202; Sat, 5 Sep 1998 13:32:23 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA09198; Sat, 5 Sep 1998 13:32:22 -0500 Received: from x6.dejanews.com (ix6.dejanews.com [10.2.1.197]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id NAA19445 for ; Sat, 5 Sep 1998 13:32:23 -0500 Received: (from www@dejanews.com) by x6.dejanews.com (8.7.6/8.6.12) id NAA10566; Sat, 5 Sep 1998 13:32:22 -0500 Message-Id: <199809051832.NAA10566@x6.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: SIH color space Date: Sat, 05 Sep 1998 18:32:20 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16,comp.graphics.algorithms NNTP-Posting-Host: 12.77.129.32 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sat Sep 05 18:32:20 1998 GMT X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 12.77.129.32 X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List I have made my first pass at the conversion algorithm between SIH (saturation:intensity:hue coded in 16 bits) color space and RGB. If interested, go to: http://home.att.net/~rocq/png16Tech.html#sihDefined Comments\suggestions are welcome. -- -- Rich -- mailto:rfranzen@my-dejanews.com -- http://home.att.net/~rocq/png16.html -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 14:04:45 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA04695 for ; Sat, 5 Sep 1998 14:04:44 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA09677; Sat, 5 Sep 1998 14:03:26 -0500 Received: from mcfs.whowhere.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA09673; Sat, 5 Sep 1998 14:03:21 -0500 Received: from Unknown/Local ([?.?.?.?]) by my-dejanews.com; Sat Sep 5 12:03:10 1998 To: "PNG List" Date: Sat, 05 Sep 1998 12:03:10 -0700 From: "Richard W. Franzen" Message-ID: Mime-Version: 1.0 Cc: angeloso@islatortuga.com X-Sent-Mail: on X-Mailer: MailCity Service Subject: Re: 3-S, un exito, Y ahora que? X-Sender-Ip: 12.77.129.32 Organization: Deja News Mail (http://www.my-dejanews.com:80) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Hmmm, I think something got misdirected to the png-list. But being a curious sort, I always wondered how good the Alta-Vista translation was: ------------ and Alta-Vista translates: ---------- As all sabreis the strike of were everything yesterday a exito, although " some " insist on saying that no. But a clear thing this, exito one or no, the case is that we obtained that everybody (never rather) paid attention to us. But and now that? In strike, todavia is left enough actions to make, that would seran but or less effective, but where but it hurts to him to Timofonica is in the pocket. You remember the great power of Timofonica, and that this people applied the saying of " You shout, You shout, but in the end tendreis that to pay ". But and if instead of paying them, we paid elsewhere that it has legal validity? They cannot cut timofono to you and of step, they do not enter those amounts in its coffers. A precendente with the Water company of Barcelona exists, where the affected ones, denounced this monopoly, and the judge I order that while lasts the contentious one, the money not entreg ... --------- end of 'translation' ------------------ I think I like it better in Spanish. :-) I am not making fun of you Angeloso -- I am making fun of the ability of Alta-Vista to translate, though. Damn, can it be that hard to translate verb tenses correctly? ---------- mas de Alta-Vista ---------------- No estoy haciendo diversión de usted Angeloso -- me estoy riendo de la capacidad de Alta-Vista de traducir, aunque. Maldición, puede ser ése difícilmente para traducir tiempos del verbo correctamente? ------------ fin de traducir ----------------- --- -- Rich -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/pngBase.html On Sat, 5 Sep 1998 16:56:48 angeloso wrote: > >Como todos sabreis la huelga de ayer fue todo un exito, aunque "algunos" se empeñen en decir que >no. Pero una cosa esta clara, exito o no, el caso es que conseguimos que todo el mundo (nunca >mejor dicho) se fijase en nosotros. Pero y ahora que? > >... > >Salu2 >Angeloso >:-D.................... > -----== Sent via Deja News, The Discussion Network ==----- http://www.dejanews.com/ Easy access to 50,000+ discussion forums -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 19:37:01 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA06596 for ; Sat, 5 Sep 1998 19:37:01 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA15262; Sat, 5 Sep 1998 19:35:43 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA15258; Sat, 5 Sep 1998 19:35:42 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id RAA27235; Sat, 5 Sep 1998 17:35:36 -0700 (PDT) Date: Sat, 5 Sep 1998 17:35:36 -0700 (PDT) Message-Id: <199809060035.RAA27235@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: comments on pngextensions-19980830.txt From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs says: > Since these names are not only used as variables in many places > but effectively *are* variables, I very strongly feel that the > underscores are required wherever such a field is being referenced in > a non-generic way (i.e., allowed values, specific inter- pretation, > etc.). Are you sure? I find the PNG spec very readable. Compare these: The unit specifier may have the following values: The unit_specifier may have the following values: "Unit_specifier" may have the following values: To me, the first is significantly easier to read. I suppose that's because I can read the first sentence entirely with my plain-English brain, whereas the other two require my formal/math brain, which exercises more care, which is unnecessary here. (Changing fonts would be just as effective at unnecessarily engaging my formal brain.) Maybe we should treat the field names as English noun phrases (with spaces and optional capitalization) except when they appear in equations, where we use a variable with the same name (lower case with underscores). > As for capitalization, I don't care so much about that, but I do think > it should be consistent, regardless of where the variable ends up in > a sentence. Since most people don't like to start sentences with > lowercase words and since leading-uppercase field names were already > in use, I suggested we stick with that. I agree that beginning a sentence with a lower case letter looks funny, but this can usually be avoided by rearranging the sentence, or beginning with "The". One-letter capital variables like M and X0 look okay to me because they look like mathematical variables. Multi-letter variables look fine when they're all lower case, because they look like code variables. But multi-letter identifiers containing capital letters don't look like variables to me; they look more like data types. And words that aren't proper names but begin with capital letters in the middle of a sentence look just as strange as lower case letters at the beginning. As for whether to quote variable names when they appear inside paragraphs in the ASCII renderings, it is always distracting and usually unnecessary. For example, unit_specifier doesn't need quotes because the underscore is a give-away, and X0=0 and (2^depth)-1 and a/b don't need quotes because the math symbols are give-aways. I bet there will be very few instances where lack of quotes will cause ambiguity, and there might be a way to solve those without imposing distracting quotes throughout the rest of the document. In the HTML version, variable names should be marked like unit_specifier in the usual case where we think of them as programming-language-ish variables, as opposed to mathematical-equation-ish variables. If we ever use the latter, they should be marked like x. For programming-language-ish equations, simply mark the whole equation like so: this_exponent = that_exponent * other_exponent If we ever use math-ish equations, I would just mark the variables: x = y + 1 Chunk names should never use quotes, nor be marked. The Postscript version should probably try to look like a typical rendering of the HTML version. > >> using integer arithmetic, where "(a/b)" means > > ...I'd suggest using v1 and v2 as variable names (or var1 and var2). Or n and d (for numerator and denominator), or i and j, or m and n. > I don't think we can retroactively restrict the count on a chunk > that was explicitly allowed to appear multiple times in a previous > document.... Instead, include a similar paragraph that says multiple > gIFg's are strongly discouraged. Okay. > [gIFt is] deprecated.... But its use cannot be forbidden. Yes, my wording was too strong. My main point was to communicate the logic of why gIFt doesn't belong in a PNG. > And I think we *must* say something--the document says you can send > e-mail here and get the chunk specification, but you can't, so why is > the chunk listed at all? The document doesn't need to say (incorrectly) that you can get the chunk specification today, nor does it need to say why you can't. I think the first paragraph was fine. Look at this: The "fRAc" chunk will describe the parameters used to generate a fractal image. Specifications for the contents of "fRAc" chunks are being developed by Tim Wegner, twegner@phoenix.net. In the future, chunks must be fully specified before they are registered. What more needs to be said? AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 20:44:35 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA06967 for ; Sat, 5 Sep 1998 20:44:35 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA16345; Sat, 5 Sep 1998 20:43:27 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA16341; Sat, 5 Sep 1998 20:43:26 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id SAA27615; Sat, 5 Sep 1998 18:43:20 -0700 (PDT) Date: Sat, 5 Sep 1998 18:43:20 -0700 (PDT) Message-Id: <199809060143.SAA27615@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: comments on pngextensions-19980830.txt From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > In the PostScript and HTML, quotation marks aren't needed because > field variables are set in a different (monospace) font via the TT > tag. The font change is almost as distracting as the quotes. When it's necessary, I recommend using rather than . > In MNG, it's pretty much necessary to set off some of the variable > names like do not show to maintain readability. Ah, I see now why the main PNG spec was able to get away without adorning the field names. All of its field names happen to be noun phrases. "Do not show" is a clause. I suppose the main PNG spec would have called it a visibility flag, or something like that. If you don't want to rename your fields, another way to turn them into nouns is with hyphens. Do-not-show might be easier to read inside a paragraph than do_not_show or "do not show" or "do_not_show". Or maybe the MNG spec doesn't have to use the exact same style as the PNG spec. I want the PNG and PNG Extensions documents to use a single style, but if the MNG and PNG specs would each be most readable using different naming conventions for chunk fields, maybe that's what they should do. It looks like the MNG spec treats its chunk fields like variables to a much greater extent than the PNG spec. It looks like Glenn has assigned *names* to the fields, whereas Tom didn't assign names at all--he described the fields (for example, "Red" and "Alpha for palette index 0" and "Pixels per unit, X axis"). AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 5 20:47:05 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA06986 for ; Sat, 5 Sep 1998 20:47:04 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA16395; Sat, 5 Sep 1998 20:46:21 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA16391; Sat, 5 Sep 1998 20:46:20 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA24917; Sat, 5 Sep 1998 21:46:21 -0400 Message-Id: <1.5.4.32.19980906014204.00ff9034@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, 05 Sep 1998 21:42:04 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: comments on pngextensions-19980830.txt Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 05:35 PM 9/5/98 -0700, you wrote: >As for whether to quote variable names when they appear inside >paragraphs in the ASCII renderings, it is always distracting and usually >unnecessary. For example, unit_specifier doesn't need quotes because >the underscore is a give-away, and X0=0 and (2^depth)-1 and a/b don't >need quotes because the math symbols are give-aways. I bet there will >be very few instances where lack of quotes will cause ambiguity, and >there might be a way to solve those without imposing distracting quotes >throughout the rest of the document. The problem is mainly with single-word variables. One solution is not to have any single-word variables. Use "image_height" instead of "height", for example. This gets rid of the problem of having to do something special to the ASCII versions. I don't have strong feelings about whether they should be capitalized or not. image_height probably looks best to C programmers, but, as you said, sentences should be rearranged to avoid putting them at the beginning. > >In the HTML version, variable names should be marked like >unit_specifier in the usual case where we think >of them as programming-language-ish variables, as opposed to >mathematical-equation-ish variables. If we ever use the latter, they >should be marked like x. We're using the tag for URLs, and they aren't getting quoted in the text version. > >For programming-language-ish equations, simply mark the whole equation >like so: > > this_exponent = that_exponent * other_exponent Those are already marked with

 and that works fine.

>
>If we ever use math-ish equations, I would just mark the variables:
>
>    x = y + 1


>
>Chunk names should never use quotes, nor be marked.

Also, we should avoid putting ancillary chunk names at the
beginnings of sentences, if we don't mark them.  Are you saying
that they shouldn't appear in a special font?

>
>The Postscript version should probably try to look like a typical
>rendering of the HTML version.

It does (actually it looks better than most, I think).

Glenn


--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sat Sep  5 21:13:59 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA07144
	for ; Sat, 5 Sep 1998 21:13:59 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id VAA16790; Sat, 5 Sep 1998 21:13:18 -0500
Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id VAA16786; Sat, 5 Sep 1998 21:13:17 -0500
Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0)
	id WAA25745; Sat, 5 Sep 1998 22:13:18 -0400
Message-Id: <1.5.4.32.19980906020901.00fdb75c@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, 05 Sep 1998 22:09:01 -0400
To: PNG List 
From: Glenn Randers-Pehrson 
Subject: Re: comments on pngextensions-19980830.txt
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

At 06:43 PM 9/5/98 -0700, you wrote:
>Glenn Randers-Pehrson  says:

>If you don't want to rename your fields, another way to turn them into
>nouns is with hyphens.  Do-not-show might be easier to read inside a
>paragraph than do_not_show or "do not show" or "do_not_show".
>

What would you make of

"When show-mode is odd-valued, nothing is displayed"? I think
"when show_mode is odd-valued, nothing is displayed" is less ambiguous.
I don't want people to think they are supposed to subtract "mode"
from "show" and check whether the result is odd-valued.

Glenn


--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sat Sep  5 21:22:45 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA07198
	for ; Sat, 5 Sep 1998 21:22:45 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id VAA17021; Sat, 5 Sep 1998 21:22:01 -0500
Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id VAA17017; Sat, 5 Sep 1998 21:21:47 -0500
Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id TAA27737; Sat, 5 Sep 1998 19:21:41 -0700 (PDT)
Date: Sat, 5 Sep 1998 19:21:41 -0700 (PDT)
Message-Id: <199809060221.TAA27737@u33.CS.Berkeley.EDU>
To: png-list@ccrc.wustl.edu
Subject: Re: comments on pngextensions-19980830.txt
From: amc@cs.berkeley.edu (Adam M. Costello)
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

Glenn Randers-Pehrson  says:

> We're using the  tag for URLs, and they aren't getting quoted in
> the text version.

I used to think that email addresses and URLs should be rendered
specially, but they usually aren't (for example, on TV, on billboards,
and at the bottom of your Netscape window, they always use a
proportional font).  They don't need special rendering, because their
distinctive syntax makes them easily recognizable.  So maybe we should
leave them as normal text in the HTML and Postscript documents.

But I wouldn't be opposed to marking them  or .  The
descriptions of those tags in the HTML 4.0 spec make both sound equally
inappropriate for URLs and email addresses, but they are descended from
the Texinfo tags @code and @samp.  The Texinfo documentation seems to
say that @code is for actual fragments of computer code and variable
names that would appear in computer code, and @kbd is for text that the
reader would type, and @file is for file names, and @samp is a catch-all
for other sorts of literal strings.  (By the way, there is an HTML 
tag, but no  tag.)

> Also, we should avoid putting ancillary chunk names at the beginnings
> of sentences, if we don't mark them.

Yes, that's easy.  The bLAH chunk...

> Are you saying that they shouldn't appear in a special font?

I was saying that, but I now notice that the PNG spec uses  for
chunk names, and it doesn't look bad, so I don't mind if that continues.
Maybe we should use  though.  The HTML 4.0 spec discourages the
use of , , , , and .

AMC

--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sat Sep  5 21:22:54 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA07207
	for ; Sat, 5 Sep 1998 21:22:54 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id VAA17028; Sat, 5 Sep 1998 21:22:15 -0500
Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id VAA17024; Sat, 5 Sep 1998 21:22:14 -0500
Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0)
	id WAA26051; Sat, 5 Sep 1998 22:22:15 -0400
Message-Id: <1.5.4.32.19980906021758.009b7890@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, 05 Sep 1998 22:17:58 -0400
To: PNG List 
From: Glenn Randers-Pehrson 
Subject: Re: comments on pngextensions-19980830.txt
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

At 06:43 PM 9/5/98 -0700, you wrote:
>Glenn Randers-Pehrson  says:
>
>> In the PostScript and HTML, quotation marks aren't needed because
>> field variables are set in a different (monospace) font via the TT
>> tag.
>
>The font change is almost as distracting as the quotes.  When it's
>necessary, I recommend using  rather than .

I haven't seen a browser that rendered them differently.

>
>> In MNG, it's pretty much necessary to set off some of the variable
>> names like do not show to maintain readability.
>
>Ah, I see now why the main PNG spec was able to get away without
>adorning the field names.  All of its field names happen to be noun
>phrases.  "Do not show" is a clause.  I suppose the main PNG spec would
>have called it a visibility flag, or something like that.

We started with visibility and potential visibility but it wasn't as
clear.  do not show is precise.

>
>If you don't want to rename your fields, another way to turn them into
>nouns is with hyphens.  Do-not-show might be easier to read inside a
>paragraph than do_not_show or "do not show" or "do_not_show".
>
>Or maybe the MNG spec doesn't have to use the exact same style as the
>PNG spec.  I want the PNG and PNG Extensions documents to use a single
>style, but if the MNG and PNG specs would each be most readable using
>different naming conventions for chunk fields, maybe that's what they
>should do.  It looks like the MNG spec treats its chunk fields like
>variables to a much greater extent than the PNG spec.  It looks like
>Glenn has assigned *names* to the fields, whereas Tom didn't assign
>names at all--he described the fields (for example, "Red" and "Alpha for
>palette index 0" and "Pixels per unit, X axis").

Sometimes they are names.  We had big debates about filter method and
compression method versus filter type and compression type, for example.

I don't want to introduce ambiguity in the name of producing more
attractive pages (that's not to say that I don't want attractive pages,
though).

Glenn


--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sat Sep  5 22:26:21 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA07644
	for ; Sat, 5 Sep 1998 22:26:20 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id WAA18050; Sat, 5 Sep 1998 22:25:23 -0500
Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id WAA18046; Sat, 5 Sep 1998 22:25:22 -0500
Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id UAA27959; Sat, 5 Sep 1998 20:25:10 -0700 (PDT)
Date: Sat, 5 Sep 1998 20:25:10 -0700 (PDT)
Message-Id: <199809060325.UAA27959@u33.CS.Berkeley.EDU>
To: png-list@ccrc.wustl.edu
Subject: Re: comments on pngextensions-19980830.txt
From: amc@cs.berkeley.edu (Adam M. Costello)
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

Glenn Randers-Pehrson  says:

> > When it's necessary, I recommend using  rather than .
>
> I haven't seen a browser that rendered them differently.

Neither have I, but the intended purpose of HTML is to allow the author
to indicate the structure of the document, not how it is to be rendered.
The rendering decisions are intended to be made by the browser in
consultation with the reader.

, , and  are inconsistent with the philosophy of HTML, and I
think Tim Berners-Lee has regretted including them for a long time.  The
HTML 4.0 spec discourages their use.

Eventually browsers will (hopefully) give their users more control
over rendering (via cascading style sheets), and  provides more
information to the user than .

> I don't want to introduce ambiguity in the name of producing more
> attractive pages...

I agree, precision is more important than appearance.  The PNG spec has
both precision and readability, and I don't want to erode the latter if
we don't have to.  The style of the PNG spec has worked well for the PNG
spec and the PNG extensions document.  It was easy to use that style for
sRGB and iCCP, and I'm sure it will be easy for pCAL, sCAL, and sPLT.
The proposed revisions to the PNG spec and extensions documents apply
to particular sections and leave the others untouched.  Changing the
style would require sweeping edits throughout the entire documents, and
the result of all that effort might be to reduce readability.  And this
might be happening shortly before PNG becomes an ISO standard.

Likewise, changing the style of the MNG spec would require sweeping
edits throughout the entire thing. and might reduce its readability.

Maybe we should keep the PNG style as it is, and MNG should adopt
whatever elements of that style work for it, and not the elements that
don't work for it (like the field naming conventions).

AMC

--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sat Sep  5 22:55:36 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA07792
	for ; Sat, 5 Sep 1998 22:55:36 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id WAA18510; Sat, 5 Sep 1998 22:54:50 -0500
Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id WAA18506; Sat, 5 Sep 1998 22:54:49 -0500
Received: (qmail 29056 invoked from network); 6 Sep 1998 03:56:05 -0000
Received: from unknown (HELO sub.sonic.net) (208.201.224.8)
  by marine.sonic.net with SMTP; 6 Sep 1998 03:56:05 -0000
Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id UAA08901 for ; Sat, 5 Sep 1998 20:54:49 -0700
X-envelope-info: 
Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id UAA15554 for png-list@ccrc.wustl.edu; Sat, 5 Sep 1998 20:55:51 -0700
Date: Sat, 5 Sep 1998 20:55:51 -0700
Message-Id: <199809060355.UAA15554@bolt.sonic.net>
From: Greg Roelofs 
To: png-list@ccrc.wustl.edu
Subject: Re: comments on pngextensions-19980830.txt
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

> Are you sure?  I find the PNG spec very readable.

Good point--I don't recall having readability problems with the core
PNG spec.  What I wrote was based more on my recent in-depth perusals
of the MNG and extensions documents.  The latter was a bit of a hodge-
podge due to all of the different contributors and the huge span of
time between versions, while the MNG document, as you noted, names its
fields differently.

I still think my underscored-variables suggestion (or Glenn's and mine)
is the right way to go for MNG, and I'll have to go back and look over
the extensions document again to see what I think about that.  I have
no problems identifying such things whether they're capitalized or not.
But regardless, if they're written as variable names, they should be
treated as proper nouns--no "the" in front of them.

> As for whether to quote variable names when they appear inside
> paragraphs in the ASCII renderings, it is always distracting and usually
> unnecessary.  For example, unit_specifier doesn't need quotes because
> the underscore is a give-away, and X0=0 and (2^depth)-1 and a/b don't
> need quotes because the math symbols are give-aways.  I bet there will
> be very few instances where lack of quotes will cause ambiguity, and
> there might be a way to solve those without imposing distracting quotes
> throughout the rest of the document.

Any single-word name is potentially ambiguous, and "Purpose" is doubly so.
It's fine with me if they can be extended to two-word names without that
becoming distracting in its own right.  Or they can be abbreviated or
something, I guess.

>     x = y + 1

If  and  are rendered differently, I don't like the suggestion.
(I would guess  becomes  and  becomes , based on pseudo-
TeX intuition.)  Again, all markup is irrelevant in the ASCII version, so
some reasonable substitution may be necessary for inlined references.

> Yes, my wording was too strong.  My main point was to communicate the
> logic of why gIFt doesn't belong in a PNG.

Agreed.

>       The "fRAc" chunk will describe the parameters used to generate a
>       fractal image.  Specifications for the contents of "fRAc" chunks
>       are being developed by Tim Wegner, twegner@phoenix.net.  In the
>       future, chunks must be fully specified before they are registered.

OK, that's good, except it should be `The specification for the contents
of the "fRAc" chunk is being...'

Greg

--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sun Sep  6 17:43:39 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA14840
	for ; Sun, 6 Sep 1998 17:43:39 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id RAA28599; Sun, 6 Sep 1998 17:41:07 -0500
Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id RAA28586; Sun, 6 Sep 1998 17:41:06 -0500
Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0)
	id SAA24073; Sun, 6 Sep 1998 18:41:08 -0400
Message-Id: <1.5.4.32.19980906223651.00fd1a94@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: Sun, 06 Sep 1998 18:36:51 -0400
To: PNG List 
From: Glenn Randers-Pehrson 
Subject: Re: comments on pngextensions-19980830.txt
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

At 07:21 PM 9/5/98 -0700, Adam wrote:

>The HTML 4.0 spec discourages the
>use of , , , , and .

As far as I can tell, KBD is equivalent to TT and would be
appropriate for URLs (I assume cut&paste with the mouse
is equivalent to a keyboard input).

CODE is not appropriate for code because the whitespace gets
lost by the big browsers.  The same goes for SAMP.  I'll stick
with PRE, which they get right.

VAR seems to be appropriate for the variables.  For chunk
names, how about STRONG? or no markup at all?  It's not
necessary because they are easily recognizable as chunknames
because they are either all uppercase or mixed case.  Just
for appearance' sake, STRONG might be appealing.

I looked at the source of the HTML 4.0 document to see how
it handles similar situations.   It uses a confusing set
of  where the class depends on where
the tagname appears in the document.  I would rather stick
with a set of simple tags TT, VAR, CODE, etc., that I can
easily parse when making the tex and txt versions of the
document.  (Maybe there's a keep-it-simple lesson there)

Where it describes the TT tag, it uses TT:

I guess the  business finally wore the authors out.

    :)

Glenn


--
Send the message body "help" to png-list-request@ccrc.wustl.edu

From owner-png-list@ccrc.wustl.edu  Sun Sep  6 19:13:36 1998
Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100])
	by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA15097
	for ; Sun, 6 Sep 1998 19:13:35 -0500 (CDT)
Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id TAA11132; Sun, 6 Sep 1998 19:12:54 -0500
Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27)
	id TAA11128; Sun, 6 Sep 1998 19:12:53 -0500
Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id RAA29039; Sun, 6 Sep 1998 17:12:52 -0700 (PDT)
Date: Sun, 6 Sep 1998 17:12:52 -0700 (PDT)
Message-Id: <199809070012.RAA29039@u33.CS.Berkeley.EDU>
To: png-list@ccrc.wustl.edu
Subject: Re: comments on pngextensions-19980830.txt
From: amc@cs.berkeley.edu (Adam M. Costello)
Sender: owner-png-list@ccrc.wustl.edu
Precedence: bulk
Reply-To: PNG List 

Glenn Randers-Pehrson  says:

> As far as I can tell, KBD is equivalent to TT and would be appropriate
> for URLs (I assume cut&paste with the mouse is equivalent to a
> keyboard input).

Be careful with the word "equivalent".  Most browsers may render them
the same, but they mean different things.  Here's an example of how some
of these tags were intended to be used:

    If you get a Permission denied error, type chmod
    +w filename and press RETURN, then try
    it again.

    Use the setenv command to set your MANPATH
    environment variable.  If it is unset, the default value is
    /usr/man.

> CODE is not appropriate for code because the whitespace gets lost by
> the big browsers.  The same goes for SAMP.  I'll stick with PRE, which
> they get right.

CODE and SAMP are not comparable to PRE.  CODE and SAMP are inline
elements, whereas PRE is a block-level element.  If you're trying to
control line breaks and vertical alignment and indentation, like in a
chunk field listing or a multi-line piece of sample code, then you need
PRE.  If you're mentioning a variable name or a literal string, then
CODE and SAMP are appropriate.

Note that you can use CODE inside PRE:

   do_not_show:    1 byte
   unit_specifier: 1 byte

   int zero(void)
   {
     return 0;
   }
> VAR seems to be appropriate for the variables. Not for programming-language-ish variables. It is intended for metasyntactic variables, like the filename in the example above, i.e. something that is supposed to be substituted with something else. Programming-language-ish variables should be marked with . My reason for suggesting VAR for math-ish variables (which we hardly use in the specs, if at all) is a bit tenuous. Metasyntactic variables are usually rendered in italics (e.g. troff-formatted man pages), and I conjecture that's because people are accustomed to math variables being written in italics. So although HTML provides no markup for math variables, I'm suggesting that VAR is closer than CODE. > For chunk names, how about STRONG? or no markup at all? I would say either SAMP (because they are literal strings that appear in the chunks) or no markup at all. I don't think chunk names warrant "strong emphasis". I use STRONG for things that ought to jump out of the page, things that the reader ought to be able to find quickly. > I looked at the source of the HTML 4.0 document to see how it handles > similar situations. It uses a confusing set of > where the class depends on where the tagname appears in the document. The class attribute is a means of extending HTML. For example, you could use and
[REFERENCE] I have [REFERENCE] Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Sep 25 11:59:23 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA21334 for ; Fri, 25 Sep 1998 11:59:23 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA07751; Fri, 25 Sep 1998 11:53:20 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA07747; Fri, 25 Sep 1998 11:53:19 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id MAA14687; Fri, 25 Sep 1998 12:53:18 -0400 Message-Id: <1.5.4.32.19980925164856.0102d728@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, 25 Sep 1998 12:48:56 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG-1.1 19980924 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 08:33 AM 9/25/98 -0700, you wrote: >> draft-png-1.1-19980924.html >> Have a look. > > Having just written a gamma-aware decoder >(well, two, actually) for the book, I'm not sure I agree with the recom- >mendation to "choose a likely default value" in the absence of any useful >information (10.5). If there is specific information indicating conversion >from GIF, then maybe, but even that is no guarantee--plenty of GIFs (and >JPEGs) have been scanned on Macs. Asking the user is good, but in the >absence of that or any other info, I think the recommendation should be to >leave the pixels alone. > I would recommend assuming sRGB colorspace (i.e., gamma = 0.45455) for images taken off the net and assuming native colorspace (don't do any gamma compensation) for images residing on the local machine. On PC's, that just means "leave the pixels alone", but on Macs and SGIs it means doing something with images off the net, or at least offering the user a choice of using sRGB or local colorspace as the default for unlabeled images. (That's not quite what the sRGB folks want; they want *all* unlabeled images to be assumed to be in sRGB colorspace on all platforms, and I think that's wrong. I think most unlabeled images should be assumed to be in the native colorspace, with unlabeled web images being an exception that should be assumed to be in sRGB.) Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Sep 25 23:16:13 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA27360 for ; Fri, 25 Sep 1998 23:16:13 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA20221; Fri, 25 Sep 1998 23:12:08 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA20217; Fri, 25 Sep 1998 23:12:06 -0500 Received: (qmail 23878 invoked from network); 26 Sep 1998 04:12:07 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 26 Sep 1998 04:12:07 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id VAA24670 for ; Fri, 25 Sep 1998 21:12:07 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id VAA13009 for png-list@ccrc.wustl.edu; Fri, 25 Sep 1998 21:12:06 -0700 Date: Fri, 25 Sep 1998 21:12:06 -0700 Message-Id: <199809260412.VAA13009@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: PNG-1.1 19980924 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >> Having just written a gamma-aware decoder >>(well, two, actually) for the book, I'm not sure I agree with the recom- >>mendation to "choose a likely default value" in the absence of any useful >>information (10.5). If there is specific information indicating conversion >>from GIF, then maybe, but even that is no guarantee--plenty of GIFs (and >>JPEGs) have been scanned on Macs. Asking the user is good, but in the >>absence of that or any other info, I think the recommendation should be to >>leave the pixels alone. > I would recommend assuming sRGB colorspace (i.e., gamma = 0.45455) for > images taken off the net and assuming native colorspace (don't do any gamma > compensation) for images residing on the local machine. On PC's, that > just means "leave the pixels alone", but on Macs and SGIs it means doing > something with images off the net, or at least offering the user a choice > of using sRGB or local colorspace as the default for unlabeled images. > (That's not quite what the sRGB folks want; they want *all* unlabeled > images to be assumed to be in sRGB colorspace on all platforms, and > I think that's wrong. I think most unlabeled images should be assumed > to be in the native colorspace, with unlabeled web images being an > exception that should be assumed to be in sRGB.) I've thought more about this and agree with Glenn (and, in a private message, Adam). It's guessing either way, but the majority of images from the net are likely to be in a PC-like color space (i.e., sRGB), while the majority of (or all?) local images are going to be in the local color space. Some users will view mostly one type of image, some mostly the other type; any single default choice will be bad for at least one of them. Here's the text I wrote for one of the programming chapters: The conditional approach toward gamma correction is on the assumption that guessing incorrectly is more harmful than doing no correction at all; alternatively, the user could be queried for a best-guess value. Note that the current draft of the PNG 1.1 specification, specifically the discussion of the sRGB chunk, disagrees with this approach. Its recommendation is to assume that all unlabelled images exist in the sRGB space, which effectively gives them gamma values of 0.45455. On a PC-like system with no lookup table, the two approaches amount to the same thing: multiply the file gamma of 0.45455 by the display-system exponent of 2.2, and you get an overall exponent of 1.0--i.e., no correction necessary. But on a Macintosh, SGI or NeXT system, the sRGB recommendation would result in additional processing that would tend to darken images. This would effectively favor images created on PCs over (unlabelled) images created on the local system. The upshot is that one is making assumptions either way; which approach is more acceptable is likely to be a matter of personal taste. Given that we're talking about recommendations, not actual specification mandates, I think it would be reasonable at least to mention that there is an opposing viewpoint and that each is appropriate in certain user- dependent situations. Or something like that. Btw, I think I'll add the sRGB version (an "else" clause), but commented out. Assuming I don't forget, anyway. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 06:48:09 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id GAA00301 for ; Sat, 26 Sep 1998 06:48:08 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id GAA28135; Sat, 26 Sep 1998 06:44:56 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id GAA28131; Sat, 26 Sep 1998 06:44:55 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id HAA19891; Sat, 26 Sep 1998 07:44:41 -0400 Message-Id: <1.5.4.32.19980926114019.01033908@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, 26 Sep 1998 07:40:19 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG-1.1 19980924 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 09:12 PM 9/25/98 -0700, Greg wrote: [about images with no color-space chunks] >Given that we're talking about recommendations, not actual specification >mandates, I think it would be reasonable at least to mention that there >is an opposing viewpoint and that each is appropriate in certain user- >dependent situations. Or something like that. If you are writing a browser or a browser-helper, it would make sense to assume sRGB. But if you are writing an image editor or local image viewer, leave the colors alone. If a user takes your editor/viewer and uses it as a browser-helper on a Mac, that's tough. Mac/Next/SGI programmers are supposed to be smart enough not to do anything like that anyhow. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 12:40:09 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA02304 for ; Sat, 26 Sep 1998 12:40:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA03866; Sat, 26 Sep 1998 12:37:57 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA03862; Sat, 26 Sep 1998 12:37:56 -0500 Received: (qmail 307 invoked from network); 26 Sep 1998 17:37:56 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 26 Sep 1998 17:37:56 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id KAA05476 for ; Sat, 26 Sep 1998 10:37:56 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id KAA27200 for png-list@ccrc.wustl.edu; Sat, 26 Sep 1998 10:37:55 -0700 Received: from mail05.rapidsite.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA25185; Sat, 26 Sep 1998 03:58:52 -0500 Received: from www.cloanto.com (207.158.207.191) by mail05.rapidsite.net (RS ver 0.3) with SMTP id 3209 for ; Sat, 26 Sep 1998 04:58:49 -0400 (EDT) Received: by terra.cloanto.com with Internet Mail Service (5.5.1960.3) id ; Sat, 26 Sep 1998 10:58:44 +0200 Message-ID: <3E44162A0A0AD21192A200AA00AD2D73727D@terra.cloanto.com> From: "M. C. Battilana" To: "'PNG List'" Subject: RE: Goals (VOTE: gIFa, gIFc, and gIFp replacement chunks) Date: Sat, 26 Sep 1998 10:58:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Loop-Detect: 1 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Hello all! Please forgive me for not being as up-to-date and deeply inside the technical aspects of PNG and MNG as most of you are. > before anyone has used it. Also, as long as you can't convert a > multi-image GIF to a PNG, I don't think it's important to be able IMHO, this is one crucial aspect on the road of PNG's success. My definition of success here remains the original motivation which inspired PNG: to get rid of the requirement to get a license to use LZW because of GIF and TIFF (which inspired me to write the "Unisys patent" story at http://cloanto.com/users/mcb/). Are we closer to that? I don't think so. To the contrary, speaking strictly about lossless formats, animation support by browsers has increased the appeal of GIF, and new, important imaging and fax applications are even more dramatically increasing the appeal of TIFF. Obviously, for Joe User things would be much easier if he only had to know about a silver bullett called "PNG", instead of "what do I use now: PNG, GIF, TIFF...?" I come from an environment where people constantly ask things like "Shall I save this as PNG, JPEG, GIF, TIFF or [E]PS?", and for some reason they always pick the wrong format, ruining the image or creating something huge and/or which they cannot load anymore. So I would also like to stress the aspect of the beauty of simplicity in the mind of the non-technical user. The fewer formats we end up having, the better. If one format becomes known for lossless capabilities, the other for lossy ones, and the third for animation, that's relatively easy to understand. But if Joe does not understand that "multi-image" = "animation", and that some GIF and TIFF files need to be converted to PNG, but some others can only be stored as MNG, which in turn is not supported by the same programs which support PNG or GIF or TIFF, then we could end up with even more confusion. Can MNG fully replace multi-image GIF and TIFF for the above-described applications, without the exceptions which would mean further excuses for supporting LZW? I would expect so, after all these years of hard work by so many fine people. But maybe you can correct me here (I would be very interested to know, also to update my article). Is MNG easy to implement, for applications which already support PNG and the minimal "animation" features of GIF and/or TIFF? A positive answer to this would leave me very reassured. But if instead zillions of applications were required to extend their current multi-image functionality in order to support MNG, I doubt that these same applications would open up to this new format as an alternative for their needs (which are satisfied by GIF or TIFF). I feel unworthy about posting to this list, because I don't know the answer to this. But, after so much time, I have an uneasy feeling. Can somebody please reassure me, and tell me that yes, now we are getting really close to getting rid of GIF and lossless TIFF, and that I have no reason for being concerned about these things? Thanks! Michael -- http://www.cloanto.it -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 14:01:44 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA02759 for ; Sat, 26 Sep 1998 14:01:44 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA05117; Sat, 26 Sep 1998 13:57:21 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA05113; Sat, 26 Sep 1998 13:57:20 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id OAA00841; Sat, 26 Sep 1998 14:57:17 -0400 Message-Id: <1.5.4.32.19980926185255.0102952c@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, 26 Sep 1998 14:52:55 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: RE: Goals (VOTE: gIFa, gIFc, and gIFp replacement chunks) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 10:58 AM 9/26/98 +0200, you wrote: >Hello all! > >Please forgive me for not being as up-to-date and deeply inside the >technical aspects of PNG and MNG as most of you are. > >> before anyone has used it. Also, as long as you can't convert a >> multi-image GIF to a PNG, I don't think it's important to be able > >IMHO, this is one crucial aspect on the road of PNG's success. My >definition of success here remains the original motivation which >inspired PNG: to get rid of the requirement to get a license to use LZW >because of GIF and TIFF (which inspired me to write the "Unisys patent" >story at http://cloanto.com/users/mcb/). Are we closer to that? I don't >think so. To the contrary, speaking strictly about lossless formats, >animation support by browsers has increased the appeal of GIF, and new, >important imaging and fax applications are even more dramatically >increasing the appeal of TIFF. PNG satisfies the requirement to provide a complete replacement for single-image GIFs. PNG was designed before NETSCAPE single-handedly started support for GIF animation (which is deprecated by the GIF89a spec and can't be done at all under the GIF87 spec). MNG can do anything GIF can, including animations (except for the plain-text extension, if we end up deprecating the gIFt chunk without offering a replacement, gIFa, that I believe works properly). The argument that has been presented against gIFa is that nobody uses the GIF plain-text extension. Another argument is that it discriminates against non-latin alphabets, but it's too complicated to design a decoder for an equivalent chunk that doesn't. >From a browser's perspective, there's no need to have both a PNG decoder and a MNG decoder; the MNG decoder takes care of both, and obviously can handle JPEG as well, if it is able to handle JNG. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 15:08:32 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id PAA03128 for ; Sat, 26 Sep 1998 15:08:31 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA06255; Sat, 26 Sep 1998 15:04:30 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA06251; Sat, 26 Sep 1998 15:04:12 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA03760; Sat, 26 Sep 1998 13:04:07 -0700 (PDT) Date: Sat, 26 Sep 1998 13:04:07 -0700 (PDT) Message-Id: <199809262004.NAA03760@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: RE: Goals (VOTE: gIFa, gIFc, and gIFp replacement chunks) From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List "M. C. Battilana" says: > But if Joe does not understand that "multi-image" = "animation", and > that some GIF and TIFF files need to be converted to PNG, but some > others can only be stored as MNG, which in turn is not supported by > the same programs which support PNG or GIF or TIFF, then we could end > up with even more confusion. Technically, there can be multi-image GIFs that are not animations--they would contain many images that are supposed to be drawn next to and/or on top of each other, like a collage, with no intervening time delay. There are about zero such beasts actually in existence. The PNG extensions document does not say how such multi-image GIFs could be converted to PNG, but one obvious possibility is to create a PNG image that contains the final values of all the pixels. You wouldn't be able to recover the original collage structure from the PNG. As Glenn pointed out, GIF also allows text overlays, and PNG's attempt to support this is broken and about to be deprecated. But this feature of GIF is not well supported and almost completely unused. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 15:59:33 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id PAA03398 for ; Sat, 26 Sep 1998 15:59:28 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA07074; Sat, 26 Sep 1998 15:48:42 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA07070; Sat, 26 Sep 1998 15:48:42 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA04254; Sat, 26 Sep 1998 16:48:41 -0400 Message-Id: <1.5.4.32.19980926204419.01039e60@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, 26 Sep 1998 16:44:19 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: RE: Goals (VOTE: gIFa, gIFc, and gIFp replacement chunks) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 01:04 PM 9/26/98 -0700, Adam wrote: > >Technically, there can be multi-image GIFs that are not animations--they >would contain many images that are supposed to be drawn next to and/or >on top of each other, like a collage, with no intervening time delay. >There are about zero such beasts actually in existence. I think there are considerably more than zero of them. That's how people make more-than-256-color GIFs. >The PNG >extensions document does not say how such multi-image GIFs could be >converted to PNG, but one obvious possibility is to create a PNG image >that contains the final values of all the pixels. You wouldn't be able >to recover the original collage structure from the PNG. That's not the business of PNG extensions but of MNG, which can recover the original structure of the multi-image GIF, whether it be an animation or a collage. If you are willing to lose the structure, you can just capture a screen shot in PNG format. One of the first PNGs that I ever created (arl_logo.png) was one that lost information in that manner. It was converted from an SGI-formatted screen shot of a vector image (a PostScript file). Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 21:06:44 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA05263 for ; Sat, 26 Sep 1998 21:06:43 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA11933; Sat, 26 Sep 1998 21:05:43 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA11929; Sat, 26 Sep 1998 21:05:41 -0500 Received: (qmail 10456 invoked from network); 27 Sep 1998 02:05:41 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 27 Sep 1998 02:05:41 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id TAA07091; Sat, 26 Sep 1998 19:05:41 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id TAA09228; Sat, 26 Sep 1998 19:05:41 -0700 Date: Sat, 26 Sep 1998 19:05:41 -0700 Message-Id: <199809270205.TAA09228@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: PNG-1.1 19980924 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > If you are writing a browser or a browser-helper, it would make sense > to assume sRGB. But if you are writing an image editor or local image > viewer, leave the colors alone. If a user takes your editor/viewer > and uses it as a browser-helper on a Mac, that's tough. Mac/Next/SGI > programmers are supposed to be smart enough not to do anything like > that anyhow. I've written both, sort of, so I did both approaches. For the completely basic viewer, I don't do any correction on unlabelled images. But for the progressive viewer that simulates the code in a web browser, I went with the sRGB recommendation. Both programs include some comments about the choices made. I'm thinking I'll probably release the accompanying source code under a BSDish license, but does anyone know how the Artistic License differs? I don't have a copy of that. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 21:19:10 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA05345 for ; Sat, 26 Sep 1998 21:19:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA12228; Sat, 26 Sep 1998 21:18:05 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA12224; Sat, 26 Sep 1998 21:18:04 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA15065; Sat, 26 Sep 1998 22:18:04 -0400 Message-Id: <1.5.4.32.19980927021343.0102f95c@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, 26 Sep 1998 22:13:43 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: PNG-1.0 draft 19980926 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List I've posted PNG-1.0 draft 19980926 at ftp://swrinde.nde.swri.edu/pub/png-group/documents in four formats: draft-png-1.1-19980926-w3c.ps.gz draft-png-1.1-19980926-w3c.html draft-png-1.1-19980926-rfc.txt.gz draft-png-1.1-19980926-w3c/png.html There are only editorial changes from the previous version based on public and private comments, improving the HTML tagging and cross-referencing, and updating the credits page. Nothing technical that would reset the two-week discussion clock. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Sep 26 23:50:16 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA09817 for ; Sat, 26 Sep 1998 23:50:15 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA14546; Sat, 26 Sep 1998 23:48:58 -0500 Received: from sss.sss.pgh.pa.us by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA14542; Sat, 26 Sep 1998 23:48:54 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA03889 for ; Sun, 27 Sep 1998 00:48:53 -0400 (EDT) To: PNG List Subject: Distribution terms (was Re: PNG-1.1 19980924) In-reply-to: Your message of Sat, 26 Sep 1998 19:05:41 -0700 <199809270205.TAA09228@bolt.sonic.net> Date: Sun, 27 Sep 1998 00:48:53 -0400 Message-ID: <3887.906871733@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs writes: > I'm thinking I'll probably release the accompanying source code under a > BSDish license, but does anyone know how the Artistic License differs? > I don't have a copy of that. Copy attached, from Perl 5.004_04 distribution. Offhand I don't know of anybody but Larry Wall who uses that license, and even he has been stating for the last few Perl releases that you can use Perl under either Artistic License or GNU GPL terms, at your option. If the GPL doesn't seem quite right for your purposes, you might look at how the LGPL (Library GPL) terms differ --- LGPL is intended for chunks of code that will be bundled into other people's applications, whereas GPL only really works right for standalone apps. You could also consider (ahem) the IJG distribution terms, or the zlib terms which seem pretty similar in spirit. The IJG terms predate LGPL, and were invented largely because we didn't like the implications of GPL for a library. Probably if LGPL had existed at the time we would've just used that. (zlib authors care to comment here?) I have nothing against Berkeley terms either, just wanted to point out that there are several popular options. regards, tom lane perl5.004_04/Artistic: The "Artistic License" Preamble The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications. Definitions: "Package" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. "Standard Version" refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder as specified below. "Copyright Holder" is whoever is named in the copyright or copyrights for the package. "You" is you, if you're thinking about copying or distributing this Package. "Reasonable copying fee" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) "Freely Available" means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. 1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers. 2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: a) place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as uunet.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package. b) use the modified Package only within your corporation or organization. c) rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version. d) make other distribution arrangements with the Copyright Holder. 4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following: a) distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version. b) accompany the distribution with the machine-readable source of the Package with your modifications. c) give non-standard executables non-standard names, and clearly document the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. d) make other distribution arrangements with the Copyright Holder. 5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. You may embed this Package's interpreter within an executable of yours (by linking); this shall be construed as a mere form of aggregation, provided that the complete Standard Version of the interpreter is so embedded. 6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whoever generated them, and may be sold commercially, and may be aggregated with this Package. If such scripts or library files are aggregated with this Package via the so-called "undump" or "unexec" methods of producing a binary executable image, then distribution of such an image shall neither be construed as a distribution of this Package nor shall it fall under the restrictions of Paragraphs 3 and 4, provided that you do not represent such an executable image as a Standard Version of this Package. 7. C subroutines (or comparably compiled subroutines in other languages) supplied by you and linked into this Package in order to emulate subroutines and variables of the language defined by this Package shall not be considered part of this Package, but are the equivalent of input as in Paragraph 6, provided these subroutines do not change the language in any way that would cause it to fail the regression tests for the language. 8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package. 9. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission. 10. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. The End -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 06:44:39 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id GAA12466 for ; Sun, 27 Sep 1998 06:44:38 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id GAA21303; Sun, 27 Sep 1998 06:43:29 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id GAA21299; Sun, 27 Sep 1998 06:43:28 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id HAA26054; Sun, 27 Sep 1998 07:43:26 -0400 Message-Id: <1.5.4.32.19980927113903.00c0970c@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: Sun, 27 Sep 1998 07:39:03 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: PNG-1.1 draft 19980926 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 10:13 PM 9/26/98 -0400, I wrote: >I've posted PNG-1.0 draft 19980926 >> PNG-1.1 << Hope that's the only mistake... No, wait, there's at least one other: in the txt version, there's a "#64" that should be "@". Also, Greg has found links to the publishers of some of the references, which I'll include in the next draft. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 08:59:30 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA13175 for ; Sun, 27 Sep 1998 08:59:29 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA23340; Sun, 27 Sep 1998 08:58:35 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA23336; Sun, 27 Sep 1998 08:58:33 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA29192; Sun, 27 Sep 1998 09:58:16 -0400 Message-Id: <1.5.4.32.19980927135353.009dd274@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: Sun, 27 Sep 1998 09:53:53 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG-1.1 draft 19980926 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List NancyRP commented: All abbreviations should be spelled out when they first occur, and they should be included in the glossary if they are used in more than one place. Glossary candidates are GIF, JPEG, TIFF, and RGB. Ones that can be spelled out or explained where they occur include NTSC, CIE, CIE LAB, XYZ (or CIE XYZ), CCD, JFIF, CMYK, and HTTP. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 10:59:01 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA13820 for ; Sun, 27 Sep 1998 10:59:01 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA25364; Sun, 27 Sep 1998 10:58:00 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA25360; Sun, 27 Sep 1998 10:57:55 -0500 Received: (qmail 18993 invoked from network); 27 Sep 1998 15:57:54 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 27 Sep 1998 15:57:54 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id IAA06962 for ; Sun, 27 Sep 1998 08:57:54 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id IAA22490 for png-list@ccrc.wustl.edu; Sun, 27 Sep 1998 08:57:54 -0700 Date: Sun, 27 Sep 1998 08:57:54 -0700 Message-Id: <199809271557.IAA22490@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: Distribution terms (was Re: PNG-1.1 19980924) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >> I'm thinking I'll probably release the accompanying source code under a >> BSDish license, but does anyone know how the Artistic License differs? > Copy attached, from Perl 5.004_04 distribution. Offhand I don't know > of anybody but Larry Wall who uses that license, and even he has > been stating for the last few Perl releases that you can use Perl > under either Artistic License or GNU GPL terms, at your option. Thanks, Tom. I didn't remember that it was so long. My main priority is that it be short :-) and pretty unrestrictive. > If the GPL doesn't seem quite right for your purposes, you might look > at how the LGPL (Library GPL) terms differ --- LGPL is intended for > chunks of code that will be bundled into other people's applications, > whereas GPL only really works right for standalone apps. I thought about LGPL, but it's also quite long, and, of course, the "G" carries a lot of baggage that I'd rather avoid here. > You could also consider (ahem) the IJG distribution terms, or the > zlib terms which seem pretty similar in spirit. Ah, yes, thanks for the reminder. I'll be sure to look at both. That may be just what I want. > Probably if LGPL had existed at the time we > would've just used that. (zlib authors care to comment here?) Note that Mark is no longer on any list but png-announce. > I have nothing against Berkeley terms either, just wanted to point > out that there are several popular options. Thanks again--that's just what I needed. I'll let you know what I decide... Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 11:43:34 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA14228 for ; Sun, 27 Sep 1998 11:43:33 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA26291; Sun, 27 Sep 1998 11:42:33 -0500 Received: from sophia.inria.fr by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA26287; Sun, 27 Sep 1998 11:42:32 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id SAA02834; Sun, 27 Sep 1998 18:42:30 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host clill-pm.inria.fr [138.96.224.138] claimed to be w3.org Message-ID: <360E6B6C.F928CECA@w3.org> Date: Sun, 27 Sep 1998 18:44:28 +0200 From: clilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: PNG List Subject: Re: PNG 1.1 draft 1.2.5 References: <199809222118.OAA21066@u33.CS.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > > Draft 1.2.5 of the PNG 1.1 (gamma handling revision) proposal is > available from: > > http://www.cs.berkeley.edu/~amc/png/ > > New things worth mentioning: > > * In the sRGB section, it used to say that an application that writes > sRGB should also write gAMA and cHRM. Now it says the application > "should also write a gAMA chunk (and perhaps a cHRM chunk)". My > reason for this change is that any decoder that cares enough about > color to use the cHRM chunk will probably start recognizing the sRGB > chunk pretty soon, and cHRM is fairly large. Does anyone object? That seems good reasoning to me, and I do not object. It has taken longer than I expected for even gamma processing to be seen as a normal requirement, and I have not seen much support for cHRM in the last few years. I agree that any application that cares is going to be using a full color management system, and that nowadays that CMS will undountedly be ICC compliant (which was not the case when PNG 1.0 was being designed). -- Chris -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 12:14:21 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA14582 for ; Sun, 27 Sep 1998 12:14:20 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA26888; Sun, 27 Sep 1998 12:13:04 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA26884; Sun, 27 Sep 1998 12:13:02 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA02789; Sun, 27 Sep 1998 13:13:01 -0400 Message-Id: <1.5.4.32.19980927170838.0103b074@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: Sun, 27 Sep 1998 13:08:38 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG-1.1 draft 19980926 [cHRM and XYZ] Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Near the end of section 10.6, we talk about using XYZ in conversion to grayscale. It says, "...Y..., which is a weighted sum of the R G and B values. The weights depend on the monitor type, i.e., the values in the cHRM chunk." The monitor that's mentioned here is the *author's* monitor, right? To display the resulting grayscale properly, you'd also have to take the *viewer's* monitor characteristics into account as well, if the destination of the grayscale image is a monitor. Bottom line: I think the "the monitor type, i.e., the values in the cHRM chunk" could be confusing. I'd write "the author's monitor type, i.e., the values in the cHRM chunk, as well as the chromaticity values for the viewer's monitor." Or something to that effect. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 14:13:33 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA15397 for ; Sun, 27 Sep 1998 14:13:32 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA29054; Sun, 27 Sep 1998 14:12:16 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA29050; Sun, 27 Sep 1998 14:12:14 -0500 Received: (qmail 24626 invoked from network); 27 Sep 1998 19:12:14 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 27 Sep 1998 19:12:14 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id MAA13351 for ; Sun, 27 Sep 1998 12:12:14 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id MAA30732 for png-list@ccrc.wustl.edu; Sun, 27 Sep 1998 12:12:14 -0700 Date: Sun, 27 Sep 1998 12:12:14 -0700 Message-Id: <199809271912.MAA30732@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: PNG 1.1 draft 1.2.5 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Chris wrote: > I agree that any application that cares is going to be using a > full color management system, and that nowadays that CMS will > undountedly be ICC compliant (which was not the case when PNG 1.0 was > being designed). Is that true of Xcms? I've only skimmed through the X11R5-era O'Reilly Xlib reference; it says all the right words, but I didn't look at it in enough depth to really understand what it offers. It would have been nice to include chromaticity support in my demo apps, but the X stuff looks complex enough that I couldn't afford the time. I also figured some of it probably changed in X11R6.x. Speaking of which, what's the ISO schedule? You'll notice I keep asking. :-) Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Sep 27 14:37:11 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA15500 for ; Sun, 27 Sep 1998 14:37:11 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA29433; Sun, 27 Sep 1998 14:35:18 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA29429; Sun, 27 Sep 1998 14:35:17 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id MAA05345; Sun, 27 Sep 1998 12:35:16 -0700 (PDT) Date: Sun, 27 Sep 1998 12:35:16 -0700 (PDT) Message-Id: <199809271935.MAA05345@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: PNG-1.1 draft 19980926 [cHRM and XYZ] From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > Near the end of section 10.6, we talk about using XYZ in conversion to > grayscale. It says, "...Y..., which is a weighted sum of the R G and > B values. The weights depend on the monitor type, i.e., the values in > the cHRM chunk." > > The monitor that's mentioned here is the *author's* monitor, right? > To display the resulting grayscale properly, you'd also have to take > the *viewer's* monitor characteristics into account as well, if the > destination of the grayscale image is a monitor. Yeah, but you're talking about two independent conversions: converting an RGB image to a grayscale image, then converting the grayscale image to RGB space for output to a color display. The paragraph in question is talking only about the first of these conversions, so no viewer's monitor is involved. I don't think the second conversion is worth mentioning here. The reader is being advised how to obtain a grayscale image, and there are any number of things he might want to do with it next. Converting it to RGB is probably one of the less common ones. > Bottom line: I think the "the monitor type, i.e., the values in the > cHRM chunk" could be confusing. Agreed. How about if we simply remove "the monitor type, i.e.,"? AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Sep 28 07:30:04 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id HAA22245 for ; Mon, 28 Sep 1998 07:30:03 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA16381; Mon, 28 Sep 1998 07:26:21 -0500 Received: from sophia.inria.fr by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA16377; Mon, 28 Sep 1998 07:26:15 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id OAA29728; Mon, 28 Sep 1998 14:26:09 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host clill-pm.inria.fr [138.96.224.138] claimed to be w3.org Message-ID: <360F80D9.DB84234D@w3.org> Date: Mon, 28 Sep 1998 14:28:09 +0200 From: clilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: PNG List Subject: Re: PNG 1.1 draft 1.2.5 References: <199809271912.MAA30732@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Greg Roelofs wrote: > > Chris wrote: > > > I agree that any application that cares is going to be using a > > full color management system, and that nowadays that CMS will > > undountedly be ICC compliant (which was not the case when PNG 1.0 was > > being designed). > > Is that true of Xcms? Unlikely; it predates ICC > I also figured > some of it probably changed in X11R6.x. Almost certainly. And, Suns and SGIs use their own CMS (the Kodak one). > Speaking of which, what's the ISO schedule? You'll notice I keep asking. :-) When I decipher enough of the ISOese I will let you know. (I have been out of the office for 3+weeks travelling, preceeded by a month of working full tilt on some W3C specs, followed by a week of jetlag and illness. I'm starting to catch up. Anyone who felt specially ignored - it wasn't just you, it was everybody ;-) -- Chris -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Sep 28 07:44:10 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id HAA22351 for ; Mon, 28 Sep 1998 07:44:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA16426; Mon, 28 Sep 1998 07:33:11 -0500 Received: from sophia.inria.fr by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA16422; Mon, 28 Sep 1998 07:33:10 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id OAA00016; Mon, 28 Sep 1998 14:33:08 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host clill-pm.inria.fr [138.96.224.138] claimed to be w3.org Message-ID: <360F827B.800A4657@w3.org> Date: Mon, 28 Sep 1998 14:35:07 +0200 From: clilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: PNG List Subject: Re: PNG-1.1 draft 19980926 [cHRM and XYZ] References: <1.5.4.32.19980927170838.0103b074@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Glenn Randers-Pehrson wrote: > > Near the end of section 10.6, we talk about using XYZ in > conversion to grayscale. It says, "...Y..., which is a > weighted sum of the R G and B values. The weights depend > on the monitor type, i.e., the values in the cHRM chunk." > > The monitor that's mentioned here is the *author's* monitor, > right? Yes. > To display the resulting grayscale properly, you'd > also have to take the *viewer's* monitor characteristics > into account as well, if the destination of the grayscale > image is a monitor. Only the gamma, not the chromaticity, unless you wantd to alter the white point (warmer/cooler greys) in which case it is arguable whether you are presenting a greyscale image anymore. > Bottom line: I think the "the monitor type, i.e., the values > in the cHRM chunk" could be confusing. I'd write "the author's > monitor type, i.e., the values in the cHRM chunk, as well as > the chromaticity values for the viewer's monitor." Or something > to that effect. To calculate the luminance (Y) only the cHRM values (authors monitor) are required. To *display* the resultng greyscale image, knowledge of the transfer function of the display device is needed. But not all applications will display the image. They may just store it in anothr PNG file, for example (Save as Greyscale). -- Chris -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Sep 28 08:54:07 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA22946 for ; Mon, 28 Sep 1998 08:54:06 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA17582; Mon, 28 Sep 1998 08:40:34 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA17578; Mon, 28 Sep 1998 08:40:32 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA06603; Mon, 28 Sep 1998 09:40:32 -0400 Message-Id: <1.5.4.32.19980928133608.010350f0@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, 28 Sep 1998 09:36:08 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG-1.1 draft 19980926 [cHRM and XYZ] Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 02:35 PM 9/28/98 +0200, you wrote: >Glenn Randers-Pehrson wrote: >> >> Near the end of section 10.6, we talk about using XYZ in >> conversion to grayscale. It says, "...Y..., which is a >> weighted sum of the R G and B values. The weights depend >> on the monitor type, i.e., the values in the cHRM chunk." >> >> The monitor that's mentioned here is the *author's* monitor, >> right? > >Yes. > >> To display the resulting grayscale properly, you'd >> also have to take the *viewer's* monitor characteristics >> into account as well, if the destination of the grayscale >> image is a monitor. > >Only the gamma, not the chromaticity, unless you wantd to alter the >white point (warmer/cooler greys) in which case it is arguable whether >you are presenting a greyscale image anymore. > >> Bottom line: I think the "the monitor type, i.e., the values >> in the cHRM chunk" could be confusing. I'd write "the author's >> monitor type, i.e., the values in the cHRM chunk, as well as >> the chromaticity values for the viewer's monitor." Or something >> to that effect. > >To calculate the luminance (Y) only the cHRM values (authors monitor) >are required. To *display* the resultng greyscale image, knowledge of >the transfer function of the display device is needed. But not all >applications will display the image. They may just store it in anothr >PNG file, for example (Save as Greyscale). Shouldn't we also remark that this calculation has to be done in linear RGB? The whole section 10.6 glosses over the interrelationship of gAMA and cHRM. How about adding a paragraph: >In many cases ... gamma correction alone. Decoders can use the cHRM data for further processing of the image data after they have converted the nonlinear RGB data to linear RGB according to the value of gamma found in the gAMA chunk or implied by the presence of the sRGB chunk. >Decoders can use the cHRM data to transform the image data from linear >RGB to XYZ and thence into a perceptually uniform colorspace such And in your suggested wording above, I'd elaborate even a little more: To calculate the luminance (Y) from the linear RGB values, only the cHRM values (chromaticity values of the author's monitor) are required. To display the resulting grayscale image, knowledge of the transfer function of the output display device is also needed. But not all applications will display the image. They may just store it in another image file, e.g., Save as Grayscale. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Sep 28 11:06:17 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA24135 for ; Mon, 28 Sep 1998 11:06:17 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA20397; Mon, 28 Sep 1998 11:03:51 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA20279; Mon, 28 Sep 1998 11:03:37 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id JAA07085; Mon, 28 Sep 1998 09:03:32 -0700 (PDT) Date: Mon, 28 Sep 1998 09:03:32 -0700 (PDT) Message-Id: <199809281603.JAA07085@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: PNG-1.1 draft 19980926 [cHRM and XYZ] From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > Shouldn't we also remark that this calculation has to be done in > linear RGB? The whole section 10.6 glosses over the interrelationship > of gAMA and cHRM. > > How about adding a paragraph: It looks like you are proposing to copy information from the color tutorial into the encoder color handling section. As it stands, the encoder color handling section (10.6) says *what* the decoder can/should do, but says nothing about *how* it would be done. So someone reading only 10.6 doesn't even have enough knowledge yet to do it wrong. The reader will need to follow the initial reference to the color tutorial, which tells exactly how to do the conversions. > To calculate the luminance (Y) from the linear RGB values, only > the cHRM values (chromaticity values of the author's monitor) are > required. The cHRM values do not necessarily have anything to do with the author's monitor (there may not even be one). The chromaticities may have been derived from a capture device, or they may correspond to a fictional monitor that the encoder thought would most resemble a typical decoder's monitor. > To display the resulting grayscale image, > knowledge of the transfer function of the output display device > is also needed. Does advice on how to display a grayscale image belong in the color handling section? AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 09:28:00 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id JAA05252 for ; Tue, 29 Sep 1998 09:27:59 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA15954; Tue, 29 Sep 1998 09:24:33 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA15950; Tue, 29 Sep 1998 09:24:32 -0500 Received: (qmail 19691 invoked from network); 29 Sep 1998 14:24:09 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 29 Sep 1998 14:24:09 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id HAA16979; Tue, 29 Sep 1998 07:24:08 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA20603; Tue, 29 Sep 1998 07:24:07 -0700 Date: Tue, 29 Sep 1998 07:24:07 -0700 Message-Id: <199809291424.HAA20603@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu, zip-bugs@lists.wku.edu Subject: cdrom.com downtime Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Walnut Creek is upgrading their archive with new RAID 5 equipment that will bring it up to some insanely large number of bytes online. This is currently scheduled to happen on Wednesday (Pacific time), but it may well spill over into Thursday. I don't *think* the web pages will be affected (now that they're on a separate server), but ftp access will definitely be hosed. FYI. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 09:38:01 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id JAA05381 for ; Tue, 29 Sep 1998 09:38:00 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA15979; Tue, 29 Sep 1998 09:27:28 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA15975; Tue, 29 Sep 1998 09:27:27 -0500 Received: (qmail 19749 invoked from network); 29 Sep 1998 14:27:28 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 29 Sep 1998 14:27:28 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id HAA17841 for ; Tue, 29 Sep 1998 07:27:27 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA20675 for png-list@ccrc.wustl.edu; Tue, 29 Sep 1998 07:27:27 -0700 Received: from atlrel1.hp.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id FAA11847; Tue, 29 Sep 1998 05:42:12 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by atlrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id GAA29354 for ; Tue, 29 Sep 1998 06:41:36 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Tue, 29 Sep 1998 04:46:21 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B1016F1524@exchange.boi.hp.com> From: "Stokes, Michael" To: PNG List Subject: RE: PNG-1.1 19980924 Date: Tue, 29 Sep 1998 04:46:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > > If you are writing a browser or a browser-helper, it would make sense > > to assume sRGB. But if you are writing an image editor or local image > > viewer, leave the colors alone. If a user takes your editor/viewer > > and uses it as a browser-helper on a Mac, that's tough. Mac/Next/SGI > > programmers are supposed to be smart enough not to do anything like > > that anyhow. > > I've written both, sort of, so I did both approaches. For the completely > basic viewer, I don't do any correction on unlabelled images. But for the > progressive viewer that simulates the code in a web browser, I went with > the sRGB recommendation. Both programs include some comments > about the choices made. > > I'm thinking I'll probably release the accompanying source code under a > BSDish license, but does anyone know how the Artistic License differs? > I don't have a copy of that. Even from deep in "sRGB land," this is an excellent discussion and summary of the tradeoffs. I'd have to agree with the browser-viewer defaulting to sRGB and the basic-viewing/editor default to local RGB (i.e. no correction). Michael -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 12:34:17 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA07386 for ; Tue, 29 Sep 1998 12:34:16 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA19711; Tue, 29 Sep 1998 12:21:13 -0500 Received: from atlrel1.hp.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA19707; Tue, 29 Sep 1998 12:21:12 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by atlrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id NAA11389 for ; Tue, 29 Sep 1998 13:20:26 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Tue, 29 Sep 1998 11:25:10 -0600 Message-ID: <767BB0EEF3D7D011B8140800099B19B113F20C29@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: PNG 1.1 draft 1.2.7 Date: Tue, 29 Sep 1998 11:25:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List I finally made it through draft 1.2.7 and all of the previous comments on 1.2.6 and such for the last few weeks. Excellent job! A few minors nits 1. In section 13.4 - the gamma of 2.2 in the CRT is actually a combination of the theoretical cathode ray tube response and the real world manufacturing limitations in the tube, beam focus, shadow mask and beam current/phosphor energy conversion. Maybe we could leave off the last phrase ", and has nothing to do with the phosphor." 2. In referencing CIE Technical Report 122 [CIE 122], I would recommend also referencing IEC 61966-3 Colour Measurement and Management in Multimedia Systems and Equipment, Part 3 - Equipment Using Cathode Ray Tubes." They are compatible, with the CIE being a technical report and IEC 69166-3 being an international standard. Maybe we could substitute [CIE 122] with [CIE 122 & IEC 61966-3] and add 61966-3 to the reference list. 3. In referencing HDTV as SMPTE 170M which is an industrial consortia standard, I would recommend referencing ITU-R BT.709-2 which is the actual international standard for HDTV. Michael Stokes Michael_Stokes@hp.com 11311 Chinden Blvd., MS:227 PH:(208)396-4261 Boise, ID 83714 FX:(208)396-5161 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 12:34:22 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA07393 for ; Tue, 29 Sep 1998 12:34:21 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA19705; Tue, 29 Sep 1998 12:21:12 -0500 Received: from atlrel1.hp.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA19700; Tue, 29 Sep 1998 12:21:11 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by atlrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id NAA11891 for ; Tue, 29 Sep 1998 13:20:36 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Tue, 29 Sep 1998 11:25:21 -0600 Message-ID: <767BB0EEF3D7D011B8140800099B19B113F20C27@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: PNG 1.1 draft 1.2.5 Date: Tue, 29 Sep 1998 11:25:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > > I agree that any application that cares is going to be using a > > full color management system, and that nowadays that CMS will > > undountedly be ICC compliant (which was not the case when > PNG 1.0 was > > being designed). > > Is that true of Xcms? I've only skimmed through the > X11R5-era O'Reilly > Xlib reference; it says all the right words, but I didn't > look at it in > enough depth to really understand what it offers. It would have been > nice to include chromaticity support in my demo apps, but the X stuff > looks complex enough that I couldn't afford the time. I also figured > some of it probably changed in X11R6.x. I've talked with the original implementors of Xcms (which predates ICC) and while it is theoretically possible, it is impractical for Xcms to support ICC. On the other hand, it could be made to support sRGB, gAMA and cHRM chunks "relatively" easily. Michael -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 13:06:10 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA07767 for ; Tue, 29 Sep 1998 13:06:10 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA20186; Tue, 29 Sep 1998 12:48:00 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA20179; Tue, 29 Sep 1998 12:47:59 -0500 Received: (qmail 27271 invoked from network); 29 Sep 1998 17:48:00 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 29 Sep 1998 17:48:00 -0000 Received: from bolt.sonic.net (root@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id KAA07765 for ; Tue, 29 Sep 1998 10:47:59 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id KAA26485 for png-list@ccrc.wustl.edu; Tue, 29 Sep 1998 10:05:28 -0700 Date: Tue, 29 Sep 1998 10:05:28 -0700 Message-Id: <199809291705.KAA26485@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: RE: PNG-1.1 19980924 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Michael Stokes wrote: > Even from deep in "sRGB land," this is an excellent discussion and summary > of the tradeoffs. I'd have to agree with the browser-viewer defaulting to > sRGB and the basic-viewing/editor default to local RGB (i.e. no correction). OK, most spiffy. I'll leave it that way, then, and make sure the accompanying chapters are up to date. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 13:57:06 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA08372 for ; Tue, 29 Sep 1998 13:57:06 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA21828; Tue, 29 Sep 1998 13:47:30 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA21824; Tue, 29 Sep 1998 13:47:16 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id LAA08590; Tue, 29 Sep 1998 11:47:01 -0700 (PDT) Date: Tue, 29 Sep 1998 11:47:01 -0700 (PDT) Message-Id: <199809291847.LAA08590@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: PNG 1.1 draft 1.2.7 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List "Stokes, Michael" says: > 1. In section 13.4 - the gamma of 2.2 in the CRT is actually a > combination of the theoretical cathode ray tube response and the real > world manufacturing limitations in the tube, beam focus, shadow mask > and beam current/phosphor energy conversion. Maybe we could leave off > the last phrase ", and has nothing to do with the phosphor." Thanks. I'll also insert the word "mainly": This is mainly due to the physical processes involved in controlling the electron beam in the electron gun. > Maybe we could substitute [CIE 122] with [CIE 122 & IEC 61966-3] and > add 61966-3 to the reference list. We don't yet reference CIE 122. I don't even remember where we were thinking of referencing it. Chris once said he was going to look at it to decide whether a reference to it would be appropriate. Can you give us an abstract of it? > 3. In referencing HDTV as SMPTE 170M which is an industrial consortia > standard, I would recommend referencing ITU-R BT.709-2 which is the > actual international standard for HDTV. We don't ever mention HDTV in the text. The string "HDTV" appears only in the bibliography entry for [ITU-BT709]. The spec currently mentions SMPTE-170M and ITU-BT709 for these purposes: camera transfer functions: old: NTSC current: SMPTE-170M chromaticities: old: NTSC newer: SMPTE-170M current: ITU-BT709 Do you recommend changing any of those? AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 16:39:05 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA10078 for ; Tue, 29 Sep 1998 16:39:05 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA25436; Tue, 29 Sep 1998 16:37:05 -0500 Received: from atlrel1.hp.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA25432; Tue, 29 Sep 1998 16:37:03 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by atlrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id RAA24726 for ; Tue, 29 Sep 1998 17:36:31 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Tue, 29 Sep 1998 15:41:16 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B101462B64@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: PNG 1.1 draft 1.2.7 Date: Tue, 29 Sep 1998 15:41:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > We don't yet reference CIE 122. I don't even remember where we were > thinking of referencing it. Chris once said he was going to > look at it > to decide whether a reference to it would be appropriate. > Can you give > us an abstract of it? My mistake. I will provide a reference in a few days when I get back into the office. Essentially CIE 122 and IEC 61966-3 are CRT characterization and measurement guidelines. > > 3. In referencing HDTV as SMPTE 170M which is an industrial > consortia > > standard, I would recommend referencing ITU-R BT.709-2 which is the > > actual international standard for HDTV. > > We don't ever mention HDTV in the text. The string "HDTV" > appears only > in the bibliography entry for [ITU-BT709]. > > The spec currently mentions SMPTE-170M and ITU-BT709 for > these purposes: > > camera transfer functions: > old: NTSC > current: SMPTE-170M > > chromaticities: > old: NTSC > newer: SMPTE-170M > current: ITU-BT709 > > Do you recommend changing any of those? I would actually recommend the ITU-BT709 chromaticities over the SMPTE-170M, but someone obviously thought otherwise. I'd like to understand why before suggesting one way or the other. The camera transfer functions are identical between the two standards. Michael -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 17:37:04 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA10645 for ; Tue, 29 Sep 1998 17:37:03 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA27153; Tue, 29 Sep 1998 17:35:54 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA27149; Tue, 29 Sep 1998 17:35:31 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id PAA08996; Tue, 29 Sep 1998 15:35:27 -0700 (PDT) Date: Tue, 29 Sep 1998 15:35:27 -0700 (PDT) Message-Id: <199809292235.PAA08996@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: RE: PNG 1.1 draft 1.2.7 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List "Stokes, Michael" says: > > chromaticities: > > old: NTSC > > newer: SMPTE-170M > > current: ITU-BT709 > > I would actually recommend the ITU-BT709 chromaticities over the > SMPTE-170M, but someone obviously thought otherwise. Maybe "newer" vs. "current" wasn't clear. What I meant (and what the spec states) is that SMPTE-170M is newer than NTSC, but ITU-BT709 is the latest word. So if your image comes from new equipment, it probably uses ITU-BT709. If it comes from older equipment, it might use SMPTE-170M. Equipment using NTSC is long gone. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Sep 29 19:27:44 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA11563 for ; Tue, 29 Sep 1998 19:27:43 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA29275; Tue, 29 Sep 1998 19:26:44 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA29271; Tue, 29 Sep 1998 19:26:43 -0500 Received: (qmail 11565 invoked from network); 30 Sep 1998 00:26:40 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 30 Sep 1998 00:26:40 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id RAA12424 for ; Tue, 29 Sep 1998 17:26:40 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id RAA19151 for png-list@ccrc.wustl.edu; Tue, 29 Sep 1998 17:26:38 -0700 Date: Tue, 29 Sep 1998 17:26:38 -0700 Message-Id: <199809300026.RAA19151@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: RE: PNG 1.1 draft 1.2.5 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Michael Stokes wrote: > I've talked with the original implementors of Xcms (which predates ICC) and > while it is theoretically possible, it is impractical for Xcms to support > ICC. On the other hand, it could be made to support sRGB, gAMA and cHRM > chunks "relatively" easily. OK. Due to a combination of time and knowledge constraints, I won't be able to do this for the first release, but if there's a second edition, I'll try to figure it out. (Or maybe I can update the reference code on the web site in the interim.) Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 30 07:39:09 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id HAA16655 for ; Wed, 30 Sep 1998 07:39:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA12481; Wed, 30 Sep 1998 07:36:34 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA12477; Wed, 30 Sep 1998 07:36:33 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA04880; Wed, 30 Sep 1998 08:36:31 -0400 Message-Id: <1.5.4.32.19980930123207.01042f20@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, 30 Sep 1998 08:32:07 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG 1.1 draft 1.2.7 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List The style of the sRGB chunk description looks different from the other chunk descriptions. I recommend, for consistency, moving the list of intents into a PRE block, followed by descriptions of the intents in regular (proportional-font) paragraphs. Here's how I would like to write it: 4.2.11. sRGB Standard RGB color space If the sRGB chunk is present, the image samples conform to the sRGB color space [sRGB], and should be displayed using the specified rendering intent as defined by the International Color Consortium [ICC]. The sRGB chunk contains: Rendering intent: 1 byte The following values are legal for the rendering intent: 0: Perceptual 1: Relative colorimetric 2: Saturation 3: Absolute colorimetric Perceptual intent is for images preferring good adaptation to the output device gamut at the expense of colorimetric accuracy, like photographs. Relative colorimetric intent is for images requiring color appearance matching (relative to the output device white point), like logos. Saturation intent is for images preferring preservation of saturation at the expense of hue and lightness, like charts and graphs. Absolute colorimetric intent is for images requiring preservation of absolute colorimetry, like proofs (previews of images destined for a different output device). An application that writes an sRGB chunk should also write a ... -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 30 10:45:35 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA18818 for ; Wed, 30 Sep 1998 10:45:35 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA16168; Wed, 30 Sep 1998 10:42:33 -0500 Received: from atlrel2.hp.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id KAA16164; Wed, 30 Sep 1998 10:42:28 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id LAA20414 for ; Wed, 30 Sep 1998 11:42:24 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Wed, 30 Sep 1998 09:46:41 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B101462B81@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: PNG 1.1 draft 1.2.7 Date: Wed, 30 Sep 1998 09:46:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Looks good to me, I support convergence and consistency :) Michael > -----Original Message----- > From: Glenn Randers-Pehrson [mailto:glennrp@netgsi.com] > Sent: Wednesday, September 30, 1998 8:32 AM > To: PNG List > Subject: Re: PNG 1.1 draft 1.2.7 > > > > The style of the sRGB chunk description looks different from the > other chunk descriptions. I recommend, for consistency, moving the > list of intents into a PRE block, followed by descriptions of the > intents in regular (proportional-font) paragraphs. > > Here's how I would like to write it: > > 4.2.11. sRGB Standard RGB color space > > If the sRGB chunk is present, the image samples > conform to the > sRGB color space [sRGB], and should be displayed using the > specified rendering intent as defined by the International > Color Consortium [ICC]. > > The sRGB chunk contains: > > Rendering intent: 1 byte > > The following values are legal for the rendering intent: > > 0: Perceptual > 1: Relative colorimetric > 2: Saturation > 3: Absolute colorimetric > > Perceptual intent is for > images preferring good adaptation to the output > device gamut at the expense of colorimetric accuracy, > like photographs. > > Relative colorimetric intent is for > images requiring color appearance matching (relative > to the output device white point), like logos. > > Saturation intent is for > images preferring preservation of saturation at the > expense of hue and lightness, like charts and graphs. > > Absolute colorimetric intent is for > images requiring preservation of absolute > colorimetry, like proofs (previews of images destined for > a different output device). > > An application that writes an sRGB chunk should also write a > > ... > > > -- > Send the message body "help" to png-list-request@ccrc.wustl.edu > -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 30 13:47:03 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA20799 for ; Wed, 30 Sep 1998 13:47:02 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA20821; Wed, 30 Sep 1998 13:44:22 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA20797; Wed, 30 Sep 1998 13:44:04 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id KAA09709; Wed, 30 Sep 1998 10:59:47 -0700 (PDT) Date: Wed, 30 Sep 1998 10:59:47 -0700 (PDT) Message-Id: <199809301759.KAA09709@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: Re: PNG 1.1 draft 1.2.7 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > I recommend, for consistency, moving the list of intents into a > PRE block, followed by descriptions of the intents in regular > (proportional-font) paragraphs. Okay, the next gamma-fix draft will do it that way. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Sep 30 20:52:08 1998 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA24950 for ; Wed, 30 Sep 1998 20:52:07 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA02712; Wed, 30 Sep 1998 20:50:31 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA02708; Wed, 30 Sep 1998 20:50:30 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA02653; Wed, 30 Sep 1998 21:50:30 -0400 Message-Id: <1.5.4.32.19981001014606.009da0dc@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, 30 Sep 1998 21:46:06 -0400 To: png-list@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: Draft PNG-1.1 19980930 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Another PNG 1.1 draft, trying to keep in sync with Adam's proposal, fixing some minor typos, changing the HTML tags again: draft-png-1.1-19980930-rfc.txt.gz draft-png-1.1-19980930-w3c.html draft-png-1.1-19980930-w3c/png.html draft-png-1.1-19980930-w3c.ps.gz in ftp://swrinde.nde.swri.edu/pub/png-group/documents/ Nothing to upset the two-week discussion clock. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu