From owner-png-list@dworkin.wustl.edu Tue Aug 4 08:42:03 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA18506 for ; Tue, 4 Aug 1998 08:42:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA02052 for png-list-outgoing; Tue, 4 Aug 1998 08:40:28 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA02046 for ; Tue, 4 Aug 1998 08:40:24 -0500 Received: (qmail 7124 invoked from network); 4 Aug 1998 13:39:53 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 4 Aug 1998 13:39:53 -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 GAA16793 for ; Tue, 4 Aug 1998 06:39:40 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id GAA14988 for png-list@dworkin.wustl.edu; Tue, 4 Aug 1998 06:43:18 -0700 Date: Tue, 4 Aug 1998 06:43:18 -0700 Message-Id: <199808041343.GAA14988@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: PNG Advocacy Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Jon A. Cruz" wrote: > I was thinking that it might be time to get PNG Now! going for the > various homepage providers, but I don't want to be duplicating any > effort. Sounds like a great idea, and judging by the lack of response on the list, I'm guessing there isn't any duplication involved. Go for it! -- Greg Roelofs newt@pobox.com http://pobox.com/~newt/ Newtware, PNG Group, Info-ZIP, Philips Multimedia Center, ... -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 08:52:38 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA18616 for ; Tue, 4 Aug 1998 08:52:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA02115 for png-list-outgoing; Tue, 4 Aug 1998 08:46:59 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA02102; Tue, 4 Aug 1998 08:46:46 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA11291; Tue, 4 Aug 1998 09:45:57 -0400 Message-Id: <1.5.4.32.19980804134156.00f3c664@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, 04 Aug 1998 09:41:56 -0400 To: PNP List , png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: Re: PNJ Draft 45, 19980803 Cc: poynton@poynton.com Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List FYI: This recent posting to c.g.a etc. is relevant to our discussion about Portable Network JPEG (PNJ) and also to our current work on a PNG 1.1 version of the PNG spec. "[]" marks my editing of the posting. Glenn Subject: Re: RGB to LAB conversion From: poynton@poynton.com (Charles Poynton) Date: 1998/08/03 Message-ID: Newsgroups: comp.graphics.algorithms,sci.engr.color,comp.graphics.apps.photoshop [...] The [PNG spec] states that > The JFIF standard specifies that images in that format should use linear > samples, but many JFIF images found on the Internet actually have a gamma > somewhere near 0.4 or 0.5. The JFIF 1.02 standard does not specify that linear intensity should be used. The language is ambiguous. The specification says this: The color space to be used is YCbCr as defined by CCIR 601 (256 levels). The RGB components calculated by linear conversion from YCbCr shall not be gamma corrected (gamma = 1.0). This is an overloaded and ambiguous sentence, and it should be clarified in the next revision. "YCbCr as defined by CCIR 601" can only mean that the R'G'B' signals have been gamma corrected prior to Y'CbCr encoding. "(256 levels)" means, unfortunately, that 256 levels are used for luma, not 219 as specified in Rec. 601: JFIF uses "full-range" coding. (Chroma in JFIF has 254 levels, that is, 128+-127.) The "RGB components" are "calculated by linear conversion," that is, a linear 3x3 matrix is used. But the underlying "RGB" are already nonlinear. This is a poorly worded suggestion that additional gamma correction shall not be applied. JFIF does not work on 8-bit linear components, because JPEG depends upon perceptual coding! Virtually all JFIF images on the net are based upon nonlinearly-coded R'G'B' primaries. There are basically two classes of JFIF images: JFIF images coded on a PC or a workstation have a nonlinear transfer function like that of Rec. 709 or sRGB. Those coded on a Mac, for desktop prepress, have a power function with an exponent of 1/1.8. Perhaps "image gamma values around 1.0" are found primarily due to poor understanding of nonlinear image coding. This poor understanding is encouraged by Timo [Autiokari]'s postings on the topic, and his web pages. The PNG "Gamma Tutorial" is quite clear on what works well and what doesn't. -- Charles Poynton [Mac Eudora/MIME/BinHex/uu] -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 09:05:17 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id JAA18740 for ; Tue, 4 Aug 1998 09:05:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA02373 for png-list-outgoing; Tue, 4 Aug 1998 09:05:05 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA02368 for ; Tue, 4 Aug 1998 09:05:02 -0500 Received: (qmail 8137 invoked from network); 4 Aug 1998 14:04:30 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 4 Aug 1998 14:04:30 -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 HAA21950 for ; Tue, 4 Aug 1998 07:04:17 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA15463 for png-list@dworkin.wustl.edu; Tue, 4 Aug 1998 07:07:55 -0700 Date: Tue, 4 Aug 1998 07:07:55 -0700 Message-Id: <199808041407.HAA15463@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: VOTE on iCCP 19980729 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Greg Roelofs I propose that iCCP be incorporated into the PNG core specification, itself currently proposed to be labelled "version 1.1". This message counts as the official Call For Votes, according to the proposed voting rules (unless someone else beat me to it). The two- week voting period begins now... Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 09:07:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id JAA18750 for ; Tue, 4 Aug 1998 09:07:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA02322 for png-list-outgoing; Tue, 4 Aug 1998 09:00:22 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA02317 for ; Tue, 4 Aug 1998 09:00:19 -0500 Received: (qmail 7918 invoked from network); 4 Aug 1998 13:59:48 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 4 Aug 1998 13:59:48 -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 GAA20806 for ; Tue, 4 Aug 1998 06:59:35 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA15379 for png-list@dworkin.wustl.edu; Tue, 4 Aug 1998 07:03:13 -0700 Date: Tue, 4 Aug 1998 07:03:13 -0700 Message-Id: <199808041403.HAA15379@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: iCCP (was Re: com.sixlegs.image.png v0.7 available) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > > Just for the record, sRGB is a registered chunk and iCCP is a proposed > > > chunk. Apps should not be writing iCCP chunks just yet, except for > > > testing purposes in files that won't be posted to the Net. > > Speaking of which, the two-week discussion period expired 5 days ago. > > Shall we get on with the voting period (assuming that's the next step)? > > I must admit, I'm fairly rusty on such things... > I have just posted a new version of the proposal (simply copied from > Adam's latest PNG-1.1 proposal). The changes are only editorial, so > I don't think this resets the discussion clock. ...which sidesteps the issue of getting on with the voting. That is the next step, right? So I'll fire up the 2-week voting clock by submitting my vote in just a moment. But first, a couple of editorial questions: > The file is ftp://swrinde.nde.swri.edu/pub/png-group/documents > iccp-proposal-19980729.txt There should be commas after "nonconsecutive" and "noninitial." The ICC reference (color.org) was removed--is that because it already exists somewhere in the main spec (either 1.0 or 1.1-proposed)? Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 09:49:55 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id JAA19078 for ; Tue, 4 Aug 1998 09:49:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA02923 for png-list-outgoing; Tue, 4 Aug 1998 09:45:06 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA02918 for ; Tue, 4 Aug 1998 09:45:02 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id KAA13483; Tue, 4 Aug 1998 10:44:16 -0400 Message-Id: <1.5.4.32.19980804144014.00f4ea84@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, 04 Aug 1998 10:40:14 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: iCCP (was Re: com.sixlegs.image.png v0.7 available) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 07:03 AM 8/4/98 -0700, Greg wrote: > >[...] a couple of editorial questions: > >> The file is ftp://swrinde.nde.swri.edu/pub/png-group/documents >> iccp-proposal-19980729.txt > >There should be commas after "nonconsecutive" and "noninitial." I didn't actually care for that sentence much... It's clear what it means only if you read the section on tEXt keywords, but people from the ICC community are probably going to jump right to the iCCP section and might be puzzled or bemused by it. > The >ICC reference (color.org) was removed--is that because it already exists >somewhere in the main spec (either 1.0 or 1.1-proposed)? It will appear in the references section, and there will be a link to the reference in the iCCP section. glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 09:51:19 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id JAA19107 for ; Tue, 4 Aug 1998 09:51:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA02963 for png-list-outgoing; Tue, 4 Aug 1998 09:49:08 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA02958 for ; Tue, 4 Aug 1998 09:49:05 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id KAA13622; Tue, 4 Aug 1998 10:48:20 -0400 Message-Id: <1.5.4.32.19980804144417.00f3d4d0@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, 04 Aug 1998 10:44:17 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: VOTE on iCCP 19980729 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Glenn Randers-Pehrson -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 11:10:26 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id LAA19718 for ; Tue, 4 Aug 1998 11:10:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA04305 for png-list-outgoing; Tue, 4 Aug 1998 11:07:17 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA04295 for ; Tue, 4 Aug 1998 11:07:10 -0500 Received: (qmail 13033 invoked from network); 4 Aug 1998 16:06:38 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 4 Aug 1998 16:06:38 -0000 Received: from ultraann (solicited-mailing.href.com [208.201.252.123]) by sub.sonic.net (8.8.8/8.8.5) with SMTP id JAA24474; Tue, 4 Aug 1998 09:06:24 -0700 X-envelope-info: Message-Id: <3.0.3.32.19980804090734.03f92170@mail.sonic.net> X-Sender: ann@mail.sonic.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 04 Aug 1998 09:07:34 -0700 To: PNG List , png-list@dworkin.wustl.edu From: Ann Lynnworth Subject: Re: PNG Advocacy In-Reply-To: <199808041343.GAA14988@bolt.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I would be very glad to help advocate for PNG. The obstacles that I see from my Windows-centric perspective are * browser support is inconsistent between Netscape and IE - NS works off MIME types and the IE off file extensions - and * web server support from Microsoft IIS is non-compliant, i.e. there is no real MIME support for PNG. While I have gotten around this on my servers by running O'Reilly's WebSite on an additional port, that's not a great answer, most importantly because a fair number of surfers can't get to http ports other than 80. Optional, would really help : animated PNGs. Having that feature would let everyone ditch GIF forever. Ann ann@href.com http://www.href.com At 06:43 AM 8/4/98 -0700, Greg Roelofs wrote: >"Jon A. Cruz" wrote: > >> I was thinking that it might be time to get PNG Now! going for the >> various homepage providers, but I don't want to be duplicating any >> effort. > >Sounds like a great idea, and judging by the lack of response on the >list, I'm guessing there isn't any duplication involved. Go for it! > >-- >Greg Roelofs newt@pobox.com http://pobox.com/~newt/ >Newtware, PNG Group, Info-ZIP, Philips Multimedia Center, ... > >-- >Send the message body "help" to png-list-request@dworkin.wustl.edu > > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 11:53:24 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id LAA20007 for ; Tue, 4 Aug 1998 11:53:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA04790 for png-list-outgoing; Tue, 4 Aug 1998 11:49:48 -0500 Received: from kobra.efd.lth.se (kobra.efd.lth.se [130.235.34.36]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA04783 for ; Tue, 4 Aug 1998 11:49:43 -0500 Received: from efd.lth.se (d89cb@batch-1.efd.lth.se [130.235.34.53]) by kobra.efd.lth.se (8.8.8/8.8.8) with ESMTP id SAA02920; Tue, 4 Aug 1998 18:48:35 +0200 (MET DST) Message-Id: <199808041648.SAA02920@kobra.efd.lth.se> To: PNG List cc: d89cb@efd.lth.se Subject: VOTE on iCCP 19980729 In-reply-to: Your message of "Tue, 04 Aug 1998 07:07:55 PDT." <199808041407.HAA15463@bolt.sonic.net> Date: Tue, 04 Aug 1998 18:48:31 +0200 From: Christian Brunschen Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Christian Brunschen -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 13:05:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id NAA20518 for ; Tue, 4 Aug 1998 13:05:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA05537 for png-list-outgoing; Tue, 4 Aug 1998 12:58:25 -0500 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA05532 for ; Tue, 4 Aug 1998 12:58:22 -0500 Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id ; Tue, 4 Aug 1998 10:57:36 -0700 Message-ID: <71F299426E8CCF11B05600805F6809DF022AE316@CUP-01-MSG> From: John Bowler To: png-list@dworkin.wustl.edu Subject: VOTE on iCCP 19980729 Date: Tue, 4 Aug 1998 10:57:28 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 13:34:29 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id NAA20748 for ; Tue, 4 Aug 1998 13:34:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA05943 for png-list-outgoing; Tue, 4 Aug 1998 13:31:35 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA05938 for ; Tue, 4 Aug 1998 13:31:31 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id OAA22029; Tue, 4 Aug 1998 14:29:42 -0400 Message-Id: <1.5.4.32.19980804182540.00f2f45c@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, 04 Aug 1998 14:25:40 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG Advocacy Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 09:07 AM 8/4/98 -0700, you wrote: >Optional, would really help : animated PNGs. Having that feature would let >everyone ditch GIF forever. That and animated transparent JPEGS. MNG will do both. See ftp://swrinde.nde.swri.edu/pub/mng/documents/ That reminds me --- gotta update the MNG-status document --- done Look at MNG_status_19980804.html or .txt; then if you want some heavier reading, read the draft MNG spec. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 14:37:38 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id OAA21287 for ; Tue, 4 Aug 1998 14:37:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA07452 for png-list-outgoing; Tue, 4 Aug 1998 14:26:03 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA07447 for ; Tue, 4 Aug 1998 14:25:59 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id VAA08170; Tue, 4 Aug 1998 21:24:26 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-29.nice.iway.fr [194.98.49.93] claimed to be w3.org Message-ID: <35C7602B.B8D8A92F@w3.org> Date: Tue, 04 Aug 1998 21:25:31 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "png-list@dworkin.wustl.edu" Subject: VOTE on iCCP 19980729 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Chris Lilley -- Chris -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 18:26:07 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id SAA23080 for ; Tue, 4 Aug 1998 18:26:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA11242 for png-list-outgoing; Tue, 4 Aug 1998 18:24:14 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA11236 for ; Tue, 4 Aug 1998 18:24:06 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id QAA02002; Tue, 4 Aug 1998 16:23:18 -0700 (PDT) Date: Tue, 4 Aug 1998 16:23:18 -0700 (PDT) Message-Id: <199808042323.QAA02002@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: iCCP From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The iCCP proposal contains: The profile name can be any convenient name for referring to the profile, and is subject to the same restrictions as a tEXt keyword (printable Latin-1 characters and nonconsecutive noninitial nonfinal spaces). Glenn Randers-Pehrson says: > I didn't actually care for that sentence much... How about this: The profile name can be any convenient name for referring to the profile, and is subject to the same restrictions as a tEXt keyword: it must contain only printable Latin-1 [ISO-8859] characters (33-126 and 161-255) and spaces (32), but no leading, trailing, or consecutive spaces. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 18:26:07 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id SAA23081 for ; Tue, 4 Aug 1998 18:26:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA11252 for png-list-outgoing; Tue, 4 Aug 1998 18:24:36 -0500 Received: from cirrostratus.netaccess.co.nz (ron.mac.co.nz [202.37.101.18]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA11247 for ; Tue, 4 Aug 1998 18:24:33 -0500 Received: from turbopress.com (ppp186088.netaccess.co.nz [202.27.186.88]) by cirrostratus.netaccess.co.nz (8.8.7/8.8.7) with SMTP id LAA07322 for ; Wed, 5 Aug 1998 11:24:16 +1200 (NZST) Message-Id: <199808042324.LAA07322@cirrostratus.netaccess.co.nz> Received: from peter by turbopress.com Wed, 05 Aug 98 11:25:27 +1200 From: "Peter Hyde" Organization: South Pacific Information Services Ltd To: png-list@dworkin.wustl.edu Date: Wed, 5 Aug 1998 11:25:27 +13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <3.0.3.32.19980804090734.03f92170@mail.sonic.net> References: <199808041343.GAA14988@bolt.sonic.net> X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Ann Lynnworth wrote: > The obstacles that > I see from my Windows-centric perspective are > > * browser support is inconsistent between Netscape and IE - NS works off > MIME types and the IE off file extensions - and > > * web server support from Microsoft IIS is non-compliant, i.e. there is no > real > MIME support for PNG. I'd just like to agree with Ann and emphasise that it is the intolerably slow/poor support from the "majors" which has held PNG up for so long. We released a humble offline browser with PNG support TWO YEARS ago. So why should it take NS and Microsoft so long to get their act together in this area? More importantly, what can be done to tidy the still- unsatisfactory situation up at this point? As professional Web site builders, we'd love to abandon GIFs altogether -- so we have: in favour of JPGs on all new sites. Of *course* we'd rather use PNG in many cases, but we can't do that if the visitors and site owners both have cause to complain that the server and/or browser combination with PNG just doesn't work. Frankly, we'd need to be sure 95% of the site visitors would see the graphics before we could use them with confidence. A tough call I know, but that's the reality as we see it. > Optional, would really help : animated PNGs. Having that feature would let > everyone ditch GIF forever. It would be the final nail, yes. An-GIFs have definitely put another obstacle in the way of wider PNG use. How can we help? cheers, peter ================================================== SPIS Ltd, Christchurch, New Zealand * TurboPress Print-to-Web automation http://www.TurboPress.com * Web design, automation and international hosting specialists * Authorised Support Centre for HREF Tools WebHub Find all the above and MORE at http://www.spis.co.nz -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 18:28:00 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id SAA23098 for ; Tue, 4 Aug 1998 18:27:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA11278 for png-list-outgoing; Tue, 4 Aug 1998 18:27:57 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA11272 for ; Tue, 4 Aug 1998 18:27:54 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id QAA02054; Tue, 4 Aug 1998 16:27:07 -0700 (PDT) Date: Tue, 4 Aug 1998 16:27:07 -0700 (PDT) Message-Id: <199808042327.QAA02054@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: VOTE on iCCP 19980729 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp_proposal_19980729.txt Adam M. Costello -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 21:24:34 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id VAA23752 for ; Tue, 4 Aug 1998 21:24:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA13305 for png-list-outgoing; Tue, 4 Aug 1998 21:22:15 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA13300 for ; Tue, 4 Aug 1998 21:22:12 -0500 Received: (qmail 4987 invoked from network); 5 Aug 1998 02:21:23 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 5 Aug 1998 02:21:23 -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 TAA02610 for ; Tue, 4 Aug 1998 19:21:09 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id TAA17767 for png-list@dworkin.wustl.edu; Tue, 4 Aug 1998 19:24:50 -0700 Date: Tue, 4 Aug 1998 19:24:50 -0700 Message-Id: <199808050224.TAA17767@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: PNG Advocacy Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> * web server support from Microsoft IIS is non-compliant, i.e. there is no >> real MIME support for PNG. Lee Crocker indicated to me that he knew how to set that up (some registry hack); if you haven't done that, then maybe he can cough up the info for us. Of course, his MX stuff is screwed up right now, so he's not receiving list messages (as of this afternoon). > As professional Web site builders, we'd love to abandon GIFs > altogether -- so we have: in favour of JPGs on all new sites. Of > *course* we'd rather use PNG in many cases, but we can't do > that if the visitors and site owners both have cause to > complain that the server and/or browser combination with PNG > just doesn't work. Well, the server is up to the site owner, so they have a fairly obvious choice they can make: use a server that can be configured correctly, or don't. The client issue is something else, and that's where server logs can help (w.r.t. user agents/browsers and detecting the 95% threshold). And you can always do the OBJECT/IMG trick; it doesn't currently work in the intended way, but it's no worse than your current alternative. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 21:43:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id VAA23823 for ; Tue, 4 Aug 1998 21:43:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA13449 for png-list-outgoing; Tue, 4 Aug 1998 21:42:23 -0500 Received: from cirrostratus.netaccess.co.nz (ron.mac.co.nz [202.37.101.18]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA13443 for ; Tue, 4 Aug 1998 21:42:19 -0500 Received: from turbopress.com (ppp186088.netaccess.co.nz [202.27.186.88]) by cirrostratus.netaccess.co.nz (8.8.7/8.8.7) with SMTP id OAA14475 for ; Wed, 5 Aug 1998 14:42:01 +1200 (NZST) Message-Id: <199808050242.OAA14475@cirrostratus.netaccess.co.nz> Received: from peter by turbopress.com Wed, 05 Aug 98 14:43:13 +1200 From: "Peter Hyde" Organization: South Pacific Information Services Ltd To: png-list@dworkin.wustl.edu Date: Wed, 5 Aug 1998 14:43:13 +13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <199808050224.TAA17767@bolt.sonic.net> X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg wrote: > Well, the server is up to the site owner, so they have a fairly obvious > choice they can make: use a server that can be configured correctly, or > don't. True, but PNG support is just one of the issues which dictate the choice of a server to use. In reality, it is unlikely to be an overriding one. Therefore, obviously, it is desirable to at least "encourage" the more commonly available servers to provide good support. Or at least, in IIS's case, make the information about registry hack as readily available as possible. > can help (w.r.t. user agents/browsers and detecting the 95% threshold). Aye. We watch that carefully: we're a long way off yet, I feel. > And you can always do the OBJECT/IMG trick; it doesn't currently work in > the intended way, but it's no worse than your current alternative. I did read about that a while back (not on the list -- just joined), but have now forgotten the details. Is there a URL with a description please? cheers, peter ================================================== SPIS Ltd, Christchurch, New Zealand * TurboPress Print-to-Web automation http://www.TurboPress.com * Web design, automation and international hosting specialists * Authorised Support Centre for HREF Tools WebHub Find all the above and MORE at http://www.spis.co.nz -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 21:50:34 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id VAA23846 for ; Tue, 4 Aug 1998 21:50:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA13504 for png-list-outgoing; Tue, 4 Aug 1998 21:50:27 -0500 Received: from m6.sprynet.com (m6.sprynet.com [165.121.2.89]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA13499 for ; Tue, 4 Aug 1998 21:50:24 -0500 Received: from stormyweather (97.white-plains-01.ny.dial-access.att.net [12.68.96.97]) by m6.sprynet.com (8.8.5/8.8.5) with SMTP id TAA20592 for ; Tue, 4 Aug 1998 19:49:33 -0700 (PDT) Message-Id: <199808050249.TAA20592@m6.sprynet.com> From: "Soren Andersen" To: png-list@dworkin.wustl.edu Date: Tue, 4 Aug 1998 22:49:33 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <199808042324.LAA07322@cirrostratus.netaccess.co.nz> References: <3.0.3.32.19980804090734.03f92170@mail.sonic.net> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On 5 Aug 98 at 11:25, in the matter of Re: PNG Advocacy, Peter Hyde wrote: > More importantly, what can be done to tidy the still- > unsatisfactory situation up at this point? What can be done by developers, is being done, I think. Use Netscape not IE if possible, promote Netscape, and hope that N5 is a mega-hit. > As professional Web site builders, we'd love to abandon GIFs > altogether -- so we have: in favour of JPGs on all new sites. Of > *course* we'd rather use PNG in many cases, but we can't do > that if the visitors and site owners both have cause to > complain that the server and/or browser combination with PNG > just doesn't work. Ahh, the server. Can't do much about the browsers, except to use (support use of) plugins -- the PNGLive plugin for instance which wasn't a bad effort. Main problem I have seen with PNG and ANY other alternative graphic file type: server doesn't know about it, doesn't return the correct HTTP RESPONSE HEADER, and so plugin won't invoke correctly!!! (The stupid browser thinks it is a file type "text/html" by default). > Frankly, we'd need to be sure 95% of the site visitors would > see the graphics before we could use them with confidence. A > tough call I know, but that's the reality as we see it. > How can we help? Contact you Web Host admin and/or "Customer Support" personnel (I use this term VERY advisedly based on my bad experiences so far) and sternly request (yes, start by being very polite and of course remain that way for as long as possible ... ) that they add to mime.types the entry for PNG: type extentions ----- ------------- image/png exts=png image/x-png exts=png I just went shopping for a new Web Host and didn't contract with one until he had edited his mime.types and then emailed me a text copy of his mime.types file! I had another prospective Host do this too. Write to these guys and start making sound about how you won't become clients of Hosts that don't support PNG by taking care of this very simple thing. Is it a cure-all? No. Just something you can do. soren andersen PNG Advocate Strongly Opinionated Person jabPH [just another baby Perl Hacker] P.S. SpryNet div of CompuServe (prisoner of AOL) afaik does NOT send the correct http response for PNG on their Our World server! Scandalous! C-Serve promised to support PNG from the outset! -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 22:13:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id WAA24000 for ; Tue, 4 Aug 1998 22:13:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA13625 for png-list-outgoing; Tue, 4 Aug 1998 22:12:55 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA13620 for ; Tue, 4 Aug 1998 22:12:52 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id XAA10597; Tue, 4 Aug 1998 23:12:02 -0400 Message-Id: <1.5.4.32.19980805030759.00f2b4d8@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, 04 Aug 1998 23:07:59 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: iCCP Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 04:23 PM 8/4/98 -0700, you wrote: >The iCCP proposal contains: > > The profile name can be any convenient name for referring to the > profile, and is subject to the same restrictions as a tEXt keyword > (printable Latin-1 characters and nonconsecutive noninitial nonfinal > spaces). > >Glenn Randers-Pehrson says: > >> I didn't actually care for that sentence much... > >How about this: > > The profile name can be any convenient name for referring to the > profile, and is subject to the same restrictions as a tEXt keyword: > it must contain only printable Latin-1 [ISO-8859] characters > (33-126 and 161-255) and spaces (32), but no leading, trailing, or > consecutive spaces. > Ahhh. Very good. That is an editorial change that doesn't affect the voting clock. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 4 23:28:48 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id XAA24276 for ; Tue, 4 Aug 1998 23:28:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA14266 for png-list-outgoing; Tue, 4 Aug 1998 23:27:51 -0500 Received: from m6.sprynet.com (m6.sprynet.com [165.121.1.89]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA14261 for ; Tue, 4 Aug 1998 23:27:47 -0500 Received: from stormyweather (82.white-plains-01.ny.dial-access.att.net [12.68.96.82]) by m6.sprynet.com (8.8.5/8.8.5) with SMTP id VAA16454 for ; Tue, 4 Aug 1998 21:26:55 -0700 (PDT) Message-Id: <199808050426.VAA16454@m6.sprynet.com> From: "Soren Andersen" To: png-list@dworkin.wustl.edu Date: Wed, 5 Aug 1998 00:26:46 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <199808042324.LAA07322@cirrostratus.netaccess.co.nz> References: <3.0.3.32.19980804090734.03f92170@mail.sonic.net> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Peter & All, Per my previous reply -- just felt that I had laid an unsubstantiated charge on SpryNet -- so here's the proof: Connecting to home.sprynet.com port 80 Requesting http://home.sprynet.com/sprynet/sorentin/images/ToluFla00.256.png HTTP/1.0 200 OK Server: Spry-SafetyWEB-Server-NT/1.2a Date: Wed, 05 Aug 1998 04:20:09 GMT Content-Type: application/octet-stream Content-Length: 15555 "application/octet-stream". Humph. And it's not even IIS they are running. Sheer laziness or incompetence, I'd say. soren andersen -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 01:49:36 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id BAA24890 for ; Wed, 5 Aug 1998 01:49:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA15490 for png-list-outgoing; Wed, 5 Aug 1998 01:47:42 -0500 Received: from cirrostratus.netaccess.co.nz (ron.mac.co.nz [202.37.101.18]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA15485 for ; Wed, 5 Aug 1998 01:47:39 -0500 Received: from turbopress.com (ppp186088.netaccess.co.nz [202.27.186.88]) by cirrostratus.netaccess.co.nz (8.8.7/8.8.7) with SMTP id SAA22599 for ; Wed, 5 Aug 1998 18:47:16 +1200 (NZST) Message-Id: <199808050647.SAA22599@cirrostratus.netaccess.co.nz> Received: from peter by turbopress.com Wed, 05 Aug 98 18:48:27 +1200 From: "Peter Hyde" Organization: South Pacific Information Services Ltd To: png-list@dworkin.wustl.edu Date: Wed, 5 Aug 1998 18:48:26 +13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <199808050249.TAA20592@m6.sprynet.com> References: <199808042324.LAA07322@cirrostratus.netaccess.co.nz> X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Soren wrote: > What can be done by developers, is being done, I think. Use Netscape not > IE if possible, promote Netscape, and hope that N5 is a mega-hit. Aye, wait and push, in other words. Easy enough to use the right browser and plug-ins ourselves, it's the random users visiting our sites that I worry about. > request (yes, start by being very polite and of course remain that way for > as long as possible ... ) that they add to mime.types the entry for PNG: We run our own servers, but IIS is apparently not easy to tweak in this area (it's nuts, it should be). However, as soon as a way is discovered/published, It Shall Be Done . > that don't support PNG by taking care of this very simple thing. Is it a > cure-all? No. Just something you can do. As far as it goes, worth doing. cheers, peter ================================================== SPIS Ltd, Christchurch, New Zealand * TurboPress Print-to-Web automation http://www.TurboPress.com * Web design, automation and international hosting specialists * Authorised Support Centre for HREF Tools WebHub Find all the above and MORE at http://www.spis.co.nz -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 04:35:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id EAA25701 for ; Wed, 5 Aug 1998 04:35:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA16478 for png-list-outgoing; Wed, 5 Aug 1998 04:34:06 -0500 Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA16473 for ; Wed, 5 Aug 1998 04:34:03 -0500 Received: from elm.ukc.ac.uk ([129.12.3.225]) by mercury.ukc.ac.uk with smtp (Exim 1.92 #1) for png-list@dworkin.wustl.edu id 0z3zwX-0002fb-00; Wed, 5 Aug 1998 10:33:13 +0100 Received: from localhost by elm.ukc.ac.uk (SMI-8.6/UKC-2.14) id KAA27983; Wed, 5 Aug 1998 10:33:11 +0100 To: png-list@dworkin.wustl.edu X-URI: http://www.cs.ukc.ac.uk/people/staff/djb1/ Subject: VOTE on iCCP 19980729 Date: Wed, 05 Aug 1998 10:33:11 +0100 Message-ID: <27980.902309591@elm.ukc.ac.uk> From: Dave Beckett Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Dave Beckett Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 07:35:12 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id HAA26073 for ; Wed, 5 Aug 1998 07:35:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA17554 for png-list-outgoing; Wed, 5 Aug 1998 07:29:39 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA17549 for ; Wed, 5 Aug 1998 07:29:36 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA21804; Wed, 5 Aug 1998 08:28:45 -0400 Message-Id: <1.5.4.32.19980805122442.00f3e480@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, 05 Aug 1998 08:24:42 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Serving PNGs [was PNG Advocacy] Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 12:26 AM 8/5/98 +0000, Soren wrote: >Peter & All, > > Per my previous reply -- just felt that I had laid an unsubstantiated >charge on SpryNet -- so here's the proof: > >Connecting to home.sprynet.com port 80 >Requesting http://home.sprynet.com/sprynet/sorentin/images/ToluFla00.256.png I launched NC4.0.4 by clicking on the link and the result was a download of ToluFla00_256.exe (the file contains a valid PNG and nothing else). Interesting what two confused applications can come up with when they get their heads together. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 07:42:24 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id HAA26095 for ; Wed, 5 Aug 1998 07:42:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA17613 for png-list-outgoing; Wed, 5 Aug 1998 07:42:22 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA17608 for ; Wed, 5 Aug 1998 07:42:19 -0500 Received: (qmail 16267 invoked from network); 5 Aug 1998 12:41:44 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 5 Aug 1998 12:41:44 -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 FAA25419 for ; Wed, 5 Aug 1998 05:41:29 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id FAA01240 for png-list@dworkin.wustl.edu; Wed, 5 Aug 1998 05:45:07 -0700 Date: Wed, 5 Aug 1998 05:45:07 -0700 Message-Id: <199808051245.FAA01240@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: iCCP Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > it must contain only printable Latin-1 [ISO-8859] characters I believe that should be ISO-8859-1, right? Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 07:51:12 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id HAA26129 for ; Wed, 5 Aug 1998 07:51:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA17659 for png-list-outgoing; Wed, 5 Aug 1998 07:50:48 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA17654 for ; Wed, 5 Aug 1998 07:50:45 -0500 Received: (qmail 16333 invoked from network); 5 Aug 1998 12:50:10 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 5 Aug 1998 12:50:10 -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 FAA26900 for ; Wed, 5 Aug 1998 05:49:56 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id FAA01333 for png-list@dworkin.wustl.edu; Wed, 5 Aug 1998 05:53:39 -0700 Date: Wed, 5 Aug 1998 05:53:39 -0700 Message-Id: <199808051253.FAA01333@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: PNG Advocacy Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Peter, >> Well, the server is up to the site owner, so they have a fairly obvious >> choice they can make: use a server that can be configured correctly, or >> don't. > True, but PNG support is just one of the issues which dictate > the choice of a server to use. In reality, it is unlikely to be an > overriding one. Well, I didn't say it was necessarily a practical choice. :-) But I will note that Apache is the most popular server in the world for a reason, and it's not just the price. >> And you can always do the OBJECT/IMG trick; it doesn't currently work in >> the intended way, but it's no worse than your current alternative. > I did read about that a while back (not on the list -- just > joined), but have now forgotten the details. Is there a URL with > a description please? http://www.cdrom.com/pub/png/pngs.html Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 08:14:49 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA26269 for ; Wed, 5 Aug 1998 08:14:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA17861 for png-list-outgoing; Wed, 5 Aug 1998 08:14:31 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA17856 for ; Wed, 5 Aug 1998 08:14:24 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id PAA01909; Wed, 5 Aug 1998 15:13:31 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-03.nice.iway.fr [194.98.49.67] claimed to be w3.org Message-ID: <35C85ABD.B64F4EE6@w3.org> Date: Wed, 05 Aug 1998 15:14:37 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: Serving PNGs [was PNG Advocacy] References: <1.5.4.32.19980805122442.00f3e480@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson wrote: > I launched NC4.0.4 by clicking on the link and the result was a download > of ToluFla00_256.exe (the file contains a valid PNG and nothing else). > Interesting what two confused applications can come up with when they get > their heads together. The browser did exactly the correct thing when faced with data labelled application/octet-stream. That MIME type guarantees that the data consists of zeros and ones, but says nothing about the proportions of each ;-) -- Chris -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 08:17:57 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA26280 for ; Wed, 5 Aug 1998 08:17:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA17871 for png-list-outgoing; Wed, 5 Aug 1998 08:14:39 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA17866 for ; Wed, 5 Aug 1998 08:14:36 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id PAA01942; Wed, 5 Aug 1998 15:13:40 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-03.nice.iway.fr [194.98.49.67] claimed to be w3.org Message-ID: <35C844A2.1471AF0A@w3.org> Date: Wed, 05 Aug 1998 13:40:18 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: PNG Advocacy References: <199808042324.LAA07322@cirrostratus.netaccess.co.nz> <199808050647.SAA22599@cirrostratus.netaccess.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Peter Hyde wrote: > > Soren wrote: > > What can be done by developers, is being done, I think. Use Netscape not > > IE if possible, promote Netscape, and hope that N5 is a mega-hit. Both IE 4 .0 (and up) and NS 4.04 (and up) support PNG natively, without plug-ins. There were pretty much the last browsers to do so - all the smaller companies and smaller platforms seemed to have PNG-enabled browsers in 1995 or 1996. > Aye, wait and push, in other words. Easy enough to use the > right browser and plug-ins ourselves, If you are still using plugins, its probably time to consider upgrading to a later release. > it's the random users > visiting our sites that I worry about. Content negotiation. Give the PNG to the folks that can handle it, give GIF to the rest. Fairly simple to arrange, the W3C site has been doing it for years. The market-leading server, Apache, can do this (amongst others). -- Chris -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 08:23:30 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA26310 for ; Wed, 5 Aug 1998 08:23:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA17932 for png-list-outgoing; Wed, 5 Aug 1998 08:18:20 -0500 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA17927 for ; Wed, 5 Aug 1998 08:18:17 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id GAA22603 for ; Wed, 5 Aug 1998 06:17:26 -0700 (PDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Wed, 5 Aug 1998 07:21:07 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B1ADE956@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: VOTE on iCCP 19980729 Date: Wed, 5 Aug 1998 07:21:04 -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@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Michael Stokes Michael -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 08:43:09 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA26512 for ; Wed, 5 Aug 1998 08:43:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA18014 for png-list-outgoing; Wed, 5 Aug 1998 08:34:55 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA18008 for ; Wed, 5 Aug 1998 08:34:52 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id PAA02534; Wed, 5 Aug 1998 15:33:58 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-03.nice.iway.fr [194.98.49.67] claimed to be w3.org Message-ID: <35C85F87.3EBAF6C3@w3.org> Date: Wed, 05 Aug 1998 15:35:03 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: iCCP References: <199808051245.FAA01240@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs wrote: > > > it must contain only printable Latin-1 [ISO-8859] characters > > I believe that should be ISO-8859-1, right? Yes, good catch. 8859-[2..10] are different character sets for Eastern Europe, Greek, Cyrillic, Arabic etc. 8859-1 is what tEXT and zTXT use. -- Chris -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 08:52:00 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA26602 for ; Wed, 5 Aug 1998 08:52:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA18260 for png-list-outgoing; Wed, 5 Aug 1998 08:51:25 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA18255 for ; Wed, 5 Aug 1998 08:51:22 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa08808; 5 Aug 98 9:46 EDT Message-ID: <35C86252.C825E8AE@alumni.rpi.edu> Date: Wed, 05 Aug 1998 09:46:58 -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: Serving PNGs [was PNG Advocacy] References: <1.5.4.32.19980805122442.00f3e480@netgsi.com> <35C85ABD.B64F4EE6@w3.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris Lilley wrote: > > Glenn Randers-Pehrson wrote: > > > I launched NC4.0.4 by clicking on the link and the result was a download > > of ToluFla00_256.exe (the file contains a valid PNG and nothing else). > > Interesting what two confused applications can come up with when they get > > their heads together. > > The browser did exactly the correct thing when faced with data labelled > application/octet-stream. That MIME type guarantees that the data > consists of zeros and ones, but says nothing about the proportions of > each ;-) Why is renaming it from ".png" to ".exe" exactly the correct thing? Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 09:09:57 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id JAA26741 for ; Wed, 5 Aug 1998 09:09:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA18338 for png-list-outgoing; Wed, 5 Aug 1998 09:02:10 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA18333 for ; Wed, 5 Aug 1998 09:02:06 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id QAA03617; Wed, 5 Aug 1998 16:01:14 +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: <35C865EC.EEC9D72B@w3.org> Date: Wed, 05 Aug 1998 16:02:20 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: Serving PNGs [was PNG Advocacy] References: <1.5.4.32.19980805122442.00f3e480@netgsi.com> <35C85ABD.B64F4EE6@w3.org> <35C86252.C825E8AE@alumni.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson wrote: > Why is renaming it from ".png" to ".exe" exactly the correct thing? Oh, I didn't mean that part; I meant saving it to disk. On an OS which uses the filename extension to type the file, it is unclear what extension should be used. I agree that exe is a bad choice. Leaving it as .png would change the MIME type that the *OS* uses to image/png which is a bad thing to do for something labelled as application/octet-stream. I expect that this has happened because many servers send executable files labelled as application/octet-stream. I think there is an unofficial MIME type of application/x-windows-executable or something similar that should probably be used instead for this sort of thing. -- Chris -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 15:45:39 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id PAA00595 for ; Wed, 5 Aug 1998 15:45:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02144 for png-list-outgoing; Wed, 5 Aug 1998 15:41:25 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02139 for ; Wed, 5 Aug 1998 15:41:20 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA03773; Wed, 5 Aug 1998 13:40:19 -0700 (PDT) Date: Wed, 5 Aug 1998 13:40:19 -0700 (PDT) Message-Id: <199808052040.NAA03773@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: iCCP From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs says: > > it must contain only printable Latin-1 [ISO-8859] characters > > I believe that should be ISO-8859-1, right? Right. I was following the example of the tEXt spec, which makes the same mistake: Both keyword and text are interpreted according to the ISO 8859-1 (Latin-1) character set [ISO-8859]. "[ISO-8859]" is a citation key, pointing at a bibliography entry: [ISO-8859] International Organization for Standardization, "Information Processing --- 8-bit Single-Byte Coded Graphic Character Sets --- Part 1: Latin Alphabet No. 1", IS 8859-1, 1987. Also see sample files at ftp://ftp.uu.net/graphics/png/documents/iso_8859-1.* If the document being cited defined all the Latin character sets, then [ISO-8859] would be the appropriate key, but the document defines only Latin-1, so the key should be [ISO-8859-1]. The next revision of the PNG 1.1 proposal will fix this in all four places. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 15:52:16 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id PAA00683 for ; Wed, 5 Aug 1998 15:52:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02220 for png-list-outgoing; Wed, 5 Aug 1998 15:51:17 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02215 for ; Wed, 5 Aug 1998 15:51:13 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA03904; Wed, 5 Aug 1998 13:50:16 -0700 (PDT) Date: Wed, 5 Aug 1998 13:50:16 -0700 (PDT) Message-Id: <199808052050.NAA03904@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: mail server down time From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The host of the PNG mailing lists will be down from 22:00 GMT Fri 7 Aug 1998 until 13:00 GMT Mon 10 Aug 1998. Actually, it might only be down intermittently during that period. Coincidentally, I'll be going offline in a few hours, returning around 7:00 GMT Wed 12 Aug. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 16:29:55 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id QAA01128 for ; Wed, 5 Aug 1998 16:29:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA02802 for png-list-outgoing; Wed, 5 Aug 1998 16:28:58 -0500 Received: from cirrostratus.netaccess.co.nz (ron.mac.co.nz [202.37.101.18]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA02793 for ; Wed, 5 Aug 1998 16:28:53 -0500 Received: from turbopress.com (ppp186088.netaccess.co.nz [202.27.186.88]) by cirrostratus.netaccess.co.nz (8.8.7/8.8.7) with SMTP id JAA11879 for ; Thu, 6 Aug 1998 09:28:29 +1200 (NZST) Message-Id: <199808052128.JAA11879@cirrostratus.netaccess.co.nz> Received: from peter by turbopress.com Thu, 06 Aug 98 09:29:42 +1200 From: "Peter Hyde" Organization: South Pacific Information Services Ltd To: png-list@dworkin.wustl.edu Date: Thu, 6 Aug 1998 09:29:42 +13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <35C844A2.1471AF0A@w3.org> X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris wrote: > There were pretty much the last browsers to do so - all the > smaller companies and smaller platforms seemed to have PNG-enabled browsers in > 1995 or 1996. Yep, smaller platforms like ours ;-). > If you are still using plugins, its probably time to consider upgrading > to a later release. There are sometimes very good reasons not to hurry into new browser releases. Size, loading speed, installation footprint/hassle (esp. IE4), need to ensure sites we make are compatible with older common browsers etc. The time and hassle ones are what keep so many users on older versions of course. In truth, native PNG support is the first *good* reason I've seen in the past three years to hurry a browser upgrade... > Content negotiation. Give the PNG to the folks that can handle it, give > GIF to the rest. Fairly simple to arrange, the W3C site has been doing > it for years. The market-leading server, Apache, can do this (amongst > others). Sorry, not that attractive. From my perspective, PNG is supposed to REPLACE GIF, not simply parallel it. I can't say to my clients (the ones footing the bills) "look, let's do an extra 20% work in the graphic area to add PNG support to your site, so all the people who have PNG-ready browsers can see the same images they can already see even if we didn't do the 20% extra." I realise what you are saying is quite correct technically and in terms of desirability. But the reality is that the average Web developer (and client!) is going to say "until the vast majority of visitors can see PNG, we'll use another format. Then we'll switch over completely (probably). The LAST thing we want to do is to use two formats to render the same images at the same time." In other words, it comes back to browser support, and more dark mutterings about why NS and IE have dragged the chain for so long. I dare say I've said enough on this all-too-obvious point so I'll give it a rest now. cheers, peter ================================================== SPIS Ltd, Christchurch, New Zealand * TurboPress Print-to-Web automation http://www.TurboPress.com * Web design, automation and international hosting specialists * Authorised Support Centre for HREF Tools WebHub Find all the above and MORE at http://www.spis.co.nz -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 17:12:22 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id RAA01619 for ; Wed, 5 Aug 1998 17:12:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA03373 for png-list-outgoing; Wed, 5 Aug 1998 17:07:55 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA03365 for ; Wed, 5 Aug 1998 17:07:51 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id AAA15684; Thu, 6 Aug 1998 00:06:56 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-20.nice.iway.fr [194.98.49.84] claimed to be w3.org Message-ID: <35C8D7C1.C6BE4F2B@w3.org> Date: Thu, 06 Aug 1998 00:08:01 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: PNG Advocacy References: <199808052128.JAA11879@cirrostratus.netaccess.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Peter Hyde wrote: > > Chris wrote: > > If you are still using plugins, its probably time to consider upgrading > > to a later release. > > There are sometimes very good reasons not to hurry into new > browser releases. I accept that may users do not upgrade their browser ever. There are still hots being generated by MCOM Mozilla 0.97 for example. > In truth, native PNG support is the first *good* reason I've seen > in the past three years to hurry a browser upgrade... Yes. > > Content negotiation. Give the PNG to the folks that can handle it, give > > GIF to the rest. Fairly simple to arrange, the W3C site has been doing > > it for years. The market-leading server, Apache, can do this (amongst > > others). > > Sorry, not that attractive. From my perspective, PNG is > supposed to REPLACE GIF, not simply parallel it. Yes. But the replacement can be a smooth, user-freindly replacement or it can be a sudden, flag day, my-site-cjhanged-so-upgrade replacement. > I can't say > to my clients (the ones footing the bills) "look, let's do an > extra 20% work in the graphic area to add PNG support to > your site, so all the people who have PNG-ready browsers can > see the same images they can already see even if we didn't > do the 20% extra." Except that they see those graphics with better quality, more cross-platform color fidelity, and they load faster. All without causing problems for those folks with older browsers who continue to see a result, albeit of poorer quality and slower. I think you will find that extra 20% (seems a bit exagerated actually) easy to sell if presented as "we can improve the quality of the site and make it load faster, all without reducing the usability of the site for legacy browsers". > I realise what you are saying is quite correct technically and in > terms of desirability. But the reality is that the average Web > developer (and client!) is going to say "until the vast majority of > visitors can see PNG, we'll use another format. Then we'll > switch over completely (probably). The LAST thing we want to > do is to use two formats to render the same images at the > same time." Given the number of sites that author completely parallel text versions, Shockwave versions, versions for different browsers, etc then I didpute your claim. This is much easier. Generate all the PNGs then have a script run over your server creating a GIF version of all the PNGs. > In other words, it comes back to browser support, and more > dark mutterings about why NS and IE have dragged the chain > for so long. Well, as I said you can have your cake and eat it too, with coneg. -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 17:16:52 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id RAA01664 for ; Wed, 5 Aug 1998 17:16:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA03255 for png-list-outgoing; Wed, 5 Aug 1998 17:03:25 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA03249 for ; Wed, 5 Aug 1998 17:03:16 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id SAA11051; Wed, 5 Aug 1998 18:02:19 -0400 Message-Id: <1.5.4.32.19980805215815.00f35104@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, 05 Aug 1998 17:58:15 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: mail server down time Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 01:50 PM 8/5/98 -0700, you wrote: >The host of the PNG mailing lists will be down from 22:00 GMT Fri 7 Aug >1998 until 13:00 GMT Mon 10 Aug 1998. > >Actually, it might only be down intermittently during that period. > >Coincidentally, I'll be going offline in a few hours, returning around >7:00 GMT Wed 12 Aug. Sounds like an evil plot to foil the registration of iCCP. Can we assume that incoming mail during that period will be stored somewhere, or will it be rejected? Vote early and often, folks, then vote again next week, just to be sure. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 5 19:02:23 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id TAA02513 for ; Wed, 5 Aug 1998 19:02:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA04513 for png-list-outgoing; Wed, 5 Aug 1998 19:01:57 -0500 Received: from cirrostratus.netaccess.co.nz (ron.mac.co.nz [202.37.101.18]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA04506 for ; Wed, 5 Aug 1998 19:01:52 -0500 Received: from turbopress.com (ppp186088.netaccess.co.nz [202.27.186.88]) by cirrostratus.netaccess.co.nz (8.8.7/8.8.7) with SMTP id MAA17021 for ; Thu, 6 Aug 1998 12:01:27 +1200 (NZST) Message-Id: <199808060001.MAA17021@cirrostratus.netaccess.co.nz> Received: from peter by turbopress.com Thu, 06 Aug 98 12:02:40 +1200 From: "Peter Hyde" Organization: South Pacific Information Services Ltd To: png-list@dworkin.wustl.edu Date: Thu, 6 Aug 1998 12:02:40 +13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: PNG Advocacy Priority: normal In-reply-to: <35C8D7C1.C6BE4F2B@w3.org> X-mailer: Pegasus Mail for Win32 (v3.01b) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris wrote: > Except that they see those graphics with better quality, mre cross-platform color > fidelity, and they load faster. Good arguments. You will understand that, to me, the *major* appeal of PNGs are that they are NOT GIFS . But the technical/aesthetic arguments help. > I think you will find that extra 20% (seems a bit exagerated actually) Quite possibly. > Given the number of sites that author completely parallel text versions, > Shockwave versions, versions for different browsers, etc then I didpute > your claim. I guess it's a matter of perspective. I don't dispute that a number of sites go to some trouble to create browser-specific experiences. Personally (and as company policy), we *don't* do that unless in very exceptional cases. We are strongly opposed to the proliferation of browser-specific HTML and our reaction is to try and make all our sites with generic, validated HTML (roughly at the 3.2 level these days, but desirably supporting as far back as, say, Mozilla 1.2). As much as possible, all the smarts go in the site's back end, where browser dependencies are a non-issue. Therefore, for us anyway, the issue of "we duplicate stuff anyway, so the client won't mind paying for this little bit extra" doesn't arise. Anyway, no argument with the general thrust for PNG -- this is just our take on the real-world concerns which people like us face when considering PNG adoption. Anything that can be done do ease our poor benighted lot will have a strong positive effect on PNG uptake. 'best. cheers, peter ================================================== SPIS Ltd, Christchurch, New Zealand * TurboPress Print-to-Web automation http://www.TurboPress.com * Web design, automation and international hosting specialists * Authorised Support Centre for HREF Tools WebHub Find all the above and MORE at http://www.spis.co.nz -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 6 11:22:22 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id LAA09919 for ; Thu, 6 Aug 1998 11:22:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA11806 for png-list-outgoing; Thu, 6 Aug 1998 11:20:48 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA11801 for ; Thu, 6 Aug 1998 11:20:43 -0500 Received: from xcitemail.com ([209.203.85.1]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id MAA27094 for ; Thu, 6 Aug 1998 12:19:43 -0400 (EDT) X-Authentication-Warning: www10.w3.org: Host [209.203.85.1] claimed to be xcitemail.com Received: from localhost (camera@localhost) by xcitemail.com (8.8.7/8.8.7) with SMTP id MAA27178; Thu, 6 Aug 1998 12:40:19 -0400 Date: Thu, 6 Aug 1998 12:40:19 -0400 From: Camera Exchange Received: by stripper.xcitemail.com (bulk_mailer v1.5); Thu, 6 Aug 1998 16:40:19 +0000 To: camera@internetmedia.com Subject: Auction-Camera Equipment Only-For Buyers & Sellers Message-ID: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Now there is a NEW way to buy and sell your Used camera equipment on the Internet's first CAMERA ONLY online Auction at THE Camera Exchange matches Buyers andSellers of used cameras and equipment. Special features include: - Guaranteeing Buyers 5 days to inspect purchased camera equipment before payment is final. - Handling of all transaction details, including bidding, payment collection, complaints, etc. - Buyer's Search our database by manufacturer, Model, Price Range, Year, Focus Method, and Finish. - Exclusive automated personal camera finder service. - No costs to bid, buy or sell. Visit our online auction at www.THE cameraexchange.com now to WIN a FREE brand new CAMERA! No drawing! FIRST PLACE The first individual to list more than 50 cameras and/or equipment for sale into our database. PRIZE: A new Sony MVC-FD7 Digital Mavica camera worth over $700. SECOND PLACE The first individual to list over 25 cameras and/or equipment for sale into our database. PRIZE: A New Canon Elph Outfit worth $300 THIRD PLACE The first person to list over 10 cameras and/or equipment for sale into our database. PRIZE: A check for $100 to purchase camera accessories at your favorite store. We are building our inventory now before our web site promotions hit later in August. VISIT us now at ; Fri, 7 Aug 1998 08:10:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA24722 for png-list-outgoing; Fri, 7 Aug 1998 08:05:01 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA24715 for ; Fri, 7 Aug 1998 08:04:58 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA19236; Fri, 7 Aug 1998 09:03:54 -0400 Message-Id: <1.5.4.32.19980807125952.009716f8@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, 07 Aug 1998 08:59:52 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG 1.1 proposal draft 1.2.1 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I'm in the process of adding sPLT and pCAL to the PNG extensions document. I would like to suggest moving the "oFFs" chunk specification from the extensions document to the main PNG spec. It has been supported all along in libpng (sCAL and gIF* haven't, so they should remain in the extensions document) --- but, unfortunately, I just noticed that libpng returns unsigned 32-bit numbers for x_offset and y_offset, which is incorrect. I will fix that in the next libpng release. If no one has noticed that, maybe it's an argument not to move oFFs after all.... If we do move oFFs, there needs to be a statement in the PNG spec about the format and range of 4-byte signed numbers. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 7 09:31:03 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id JAA21340 for ; Fri, 7 Aug 1998 09:31:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA26025 for png-list-outgoing; Fri, 7 Aug 1998 09:30:18 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA26020 for ; Fri, 7 Aug 1998 09:30:13 -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 KAA09592 for ; Fri, 7 Aug 1998 10:29:09 -0400 (EDT) To: PNG List Subject: Re: PNG 1.1 proposal draft 1.2.1 In-reply-to: Your message of Fri, 07 Aug 1998 08:59:52 -0400 <1.5.4.32.19980807125952.009716f8@netgsi.com> Date: Fri, 07 Aug 1998 10:29:09 -0400 Message-ID: <9590.902500149@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson writes: > I would like to suggest moving the "oFFs" chunk specification > from the extensions document to the main PNG spec. Why? > I will fix that in the next libpng release. If no one has > noticed that, maybe it's an argument not to move oFFs after > all.... Lack of widespread usage is certainly a reason not to make it part of the core spec. regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 7 11:01:21 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id LAA22435 for ; Fri, 7 Aug 1998 11:01:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA27075 for png-list-outgoing; Fri, 7 Aug 1998 10:59:06 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA27070 for ; Fri, 7 Aug 1998 10:59:01 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id LAA26124; Fri, 7 Aug 1998 11:57:57 -0400 Message-Id: <1.5.4.32.19980807155355.00f39de8@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, 07 Aug 1998 11:53:55 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG 1.1 proposal draft 1.2.1 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:29 AM 8/7/98 -0400, you wrote: >Glenn Randers-Pehrson writes: >> I would like to suggest moving the "oFFs" chunk specification >> from the extensions document to the main PNG spec. > >Why? When I wrote that sentence, I thought oFFs had been supported for a couple of years, successfully. I perceived the extensions document as a place where chunks could cool off for a year or two and then be moved up if they turned out to be widely supported. Then I went to check the implementation in libpng and discovered that it hasn't really been supported properly after all, and wrote: > >> I will fix that in the next libpng release. If no one has >> noticed that, maybe it's an argument not to move oFFs after >> all.... > >Lack of widespread usage is certainly a reason not to make it >part of the core spec. I can't really tell whether it's being used or not, but the fact that the error was never reported suggests that it isn't being used much. However, people who are converting GIFs would not be likely to notice the error, because the offsets in GIF89a are unsigned 16-bit ints. But in view of the fact that the support in libpng has been erroneous, I withdraw the suggestion. ARL viewpng (which isn't widely used, to my knowledge) has supported oFFs for quite a while, interpreting the fields as 4-byte signed longs on the SGI, in which negative numbers are expressed in two's complement form (which is consistent with the PNG spec, section 2.1). Negative numbers are much more prevalent in MNG, so MNG decoders will have to pay attention to the range and format of negative numbers. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 7 14:43:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id OAA24940 for ; Fri, 7 Aug 1998 14:43:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA29935 for png-list-outgoing; Fri, 7 Aug 1998 14:40:53 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA29930 for ; Fri, 7 Aug 1998 14:40:49 -0500 From: isd269@aol.com Received: from ds1.gl.umbc.edu (ds1.gl.umbc.edu [130.85.60.6]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id PAA16438 for ; Fri, 7 Aug 1998 15:39:46 -0400 (EDT) Received: from student.umbc.edu ([130.85.157.77]) by ds1.gl.umbc.edu (8.8.8/8.8.7) with SMTP id PAA21315; Fri, 7 Aug 1998 15:39:06 -0400 (EDT) Date: Fri, 7 Aug 1998 15:39:06 -0400 (EDT) Subject: The Online Classroom Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII Apparently-To: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List REGISTER NOW! This fall the University of Maryland, Baltimore County is offering the course, "The Online Classroom (EDUC 641)" This course is part of UMBC's graduate program in Instructional Systems Development Training Systems. Take the course by itself, or use it as a springboard to complete a letter of certification in distance education in just three semesters. The Internet, the online classroom, and computer-based instruction are increasingly being used as teaching tools for workforce training and development. This three-credit course examines various aspects of computer-mediated communication and instruction. From the theoretical to the practical, you will explore a broad range of distance education issues and applications. Who Shoud Attend * Corporate, Business or Government Trainers * Human Resource Professionals * Classroom Teachers * Educators Upcoming Distance Education Courses * Corporate Distance Training (Spring 1999) * Principles of Distance Education (Summer 1999) * Interactive Video Systems and Conferencing (Fall 1999) Technical Requirements You must have convenient access to the internet via a web browser. The classroom will be hosted on the UMBC homepage and the entire class will be held on-line using the WebCT interface. Admissions You must have a BA or BS degree to be admitted to this course. Application: To request that an admissions application be mailed, faxed or emailed to you, please email connect@umbc.edu or call 410-455-2797. Information Contact UMBC Professional Programs at 410-455-2797 Email: connect@umbc.edu Website: http//www.umbc.edu/continuing-education -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 8 13:51:19 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id NAA08949 for ; Sat, 8 Aug 1998 13:51:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA11806 for png-list-outgoing; Sat, 8 Aug 1998 13:50:53 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA11801 for ; Sat, 8 Aug 1998 13:50:48 -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 OAA01696 for ; Sat, 8 Aug 1998 14:49:39 -0400 (EDT) To: PNG List Subject: extensions vs core spec (was Re: PNG 1.1 proposal draft 1.2.1) In-reply-to: Your message of Fri, 07 Aug 1998 11:53:55 -0400 <1.5.4.32.19980807155355.00f39de8@netgsi.com> Date: Sat, 08 Aug 1998 14:49:39 -0400 Message-ID: <1694.902602179@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson writes: > I perceived the extensions document as a place where chunks could cool > off for a year or two and then be moved up if they turned out to be > widely supported. I don't really think that the extensions document should be considered a farm team for chunks that might make the majors next year ;-). The point of it was to (a) make the core spec smaller, and (b) provide a place to define less-widely-used chunks in a document that could be revised more often and with less pain than the core spec. The fact that we haven't actually bothered to revise the extensions doc even once since the core came out is evidence of burnout ... but it's not a reason to abandon the distinction. Especially not when we are proceeding down the path to ISO standardization of the core spec. Once that happens we may as well assume the core is graven on stone tablets; we'll need an extensions doc that we can revise without touching the core or giving the impression that we might shortly want to revise the core. regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 8 15:08:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id PAA09648 for ; Sat, 8 Aug 1998 15:08:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA12142 for png-list-outgoing; Sat, 8 Aug 1998 15:07:19 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA12136 for ; Sat, 8 Aug 1998 15:07:15 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA16176; Sat, 8 Aug 1998 16:06:06 -0400 Message-Id: <1.5.4.32.19980808200203.0096ef38@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, 08 Aug 1998 16:02:03 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: ISO 8859-1 [was Re: iCCP] Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 03:35 PM 8/5/98 +0200, you wrote: >Greg Roelofs wrote: >> >> > it must contain only printable Latin-1 [ISO-8859] characters >> >> I believe that should be ISO-8859-1, right? > >Yes, good catch. 8859-[2..10] are different character sets for Eastern >Europe, Greek, Cyrillic, Arabic etc. 8859-1 is what tEXT and zTXT use. Also, the reference should be updated to reflect the fact that a new version of ISO 8859-1 was released in April 1998. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 8 15:09:59 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id PAA09673 for ; Sat, 8 Aug 1998 15:09:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA12164 for png-list-outgoing; Sat, 8 Aug 1998 15:10:19 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA12159 for ; Sat, 8 Aug 1998 15:10:16 -0500 Received: (qmail 15048 invoked from network); 8 Aug 1998 20:09:29 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 8 Aug 1998 20:09:29 -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 NAA24970; Sat, 8 Aug 1998 13:09:08 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id NAA20032; Sat, 8 Aug 1998 13:08:09 -0700 Date: Sat, 8 Aug 1998 13:08:09 -0700 Message-Id: <199808082008.NAA20032@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: sRGB rendering intent; ICC LCDs? Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I thought Adam's gamma-fix document asked about the default sRGB rendering intent, but his machine is down and I don't have a local copy of the 1.2.1 version (or whatever is most recent). In any case, someone, somewhere, asked about it and suggested that "perceptual" might be the most appropriate; Annex E of the ICC profile spec says that "relative colorimetric" is the ICC default. That makes sense to me (insofar as I now semi-understand the four possibilities), so I suggest we either make the same recommendation or else simply mention that of the ICC. (Note that sRGB refers to ICC for the definition of the four intents.) Also, Chris Lilley once said that LCDs' transfer functions are "sigmoid"; what does that mean? If it's S-shaped, is it flat in the middle (sort of like a scaled tangent curve) or steep in the middle (like an integral)? Do ICC profiles cover this case, either explicitly (couldn't find any mention) or implicitly? As far as sRGB support goes, will Microsoft's OS support include specific support for LCDs? Apple, Sun, NEC and Sony all make (or at least used to make) laptops; does their membership in ICC imply anything in this regard? Man, this has been some tough writing... Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 8 16:02:02 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id QAA10184 for ; Sat, 8 Aug 1998 16:02:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA12410 for png-list-outgoing; Sat, 8 Aug 1998 15:57:14 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA12404 for ; Sat, 8 Aug 1998 15:57:10 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA17773; Sat, 8 Aug 1998 16:56:00 -0400 Message-Id: <1.5.4.32.19980808205157.00f3f550@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, 08 Aug 1998 16:51:57 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: sRGB rendering intent; ICC LCDs? Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 01:08 PM 8/8/98 -0700, you wrote: >I thought Adam's gamma-fix document asked about the default sRGB >rendering intent, but his machine is down and I don't have a local >copy of the 1.2.1 version (or whatever is most recent). I think it's the latest. I haven't been able to get to his machine for a couple of days; he must have powered it down before he left. > In any case, >someone, somewhere, asked about it and suggested that "perceptual" >might be the most appropriate; Annex E of the ICC profile spec says >that "relative colorimetric" is the ICC default. That makes sense >to me (insofar as I now semi-understand the four possibilities), so I >suggest we either make the same recommendation or else simply mention >that of the ICC. (Note that sRGB refers to ICC for the definition >of the four intents.) I agree that we should quote the ICC recommendation rather than making a different one. > >Also, Chris Lilley once said that LCDs' transfer functions are "sigmoid"; >what does that mean? If it's S-shaped, is it flat in the middle (sort >of like a scaled tangent curve) or steep in the middle (like an integral)? >Do ICC profiles cover this case, either explicitly (couldn't find any >mention) or implicitly? The only "TRC" (Tone Reproduction Curve) types they accommodate are linear, simple gamma, and tabular, as of ICCP version 3.4. So if you want a sigmoidal TRC you have to write it in tabular form. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 12 14:16:07 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA06845 for ; Wed, 12 Aug 1998 14:16:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA05755 for png-list-outgoing; Wed, 12 Aug 1998 14:14:55 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA05750 for ; Wed, 12 Aug 1998 14:14:52 -0500 Received: (qmail 25880 invoked from network); 12 Aug 1998 19:13:50 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 12 Aug 1998 19:13:50 -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 MAA32657 for ; Wed, 12 Aug 1998 12:13:21 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id MAA06726 for png-list@dworkin.wustl.edu; Wed, 12 Aug 1998 12:12:44 -0700 Date: Wed, 12 Aug 1998 12:12:44 -0700 Message-Id: <199808121912.MAA06726@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: iCCP vote Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Just a reminder: the voting period for the proposed iCCP chunk ends next Tuesday at around 7am Pacific time. So far there are 8 votes in favor; two more are needed for passage, according to the proposed voting rules of way-back-when. Don't be shy, now. :-) Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 12:42:20 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA20932 for ; Thu, 13 Aug 1998 12:42:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA22422 for png-list-outgoing; Thu, 13 Aug 1998 12:41:15 -0500 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA22386 for ; Thu, 13 Aug 1998 12:41:09 -0500 Received: from gerard1 (dc2-modem1669.dial.xs4all.nl [194.109.134.133]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id TAA16655 for ; Thu, 13 Aug 1998 19:39:32 +0200 (CEST) Message-Id: <199808131739.TAA16655@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: png-list@dworkin.wustl.edu Date: Thu, 13 Aug 1998 19:38:11 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: iCCp votes X-Confirm-Reading-To: "Gerard Juyn" X-pmrqc: 1 Priority: normal In-reply-to: <199808131410.HAA10238@bolt.sonic.net> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7BIT YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp-proposal-19980729.txt Gerard Juyn -- Gerard (gjuyn@xs4all.nl) -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 13:19:13 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA21284 for ; Thu, 13 Aug 1998 13:19:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA22952 for png-list-outgoing; Thu, 13 Aug 1998 13:17:35 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA22947 for ; Thu, 13 Aug 1998 13:17:27 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id LAA20438; Thu, 13 Aug 1998 11:15:49 -0700 (PDT) Date: Thu, 13 Aug 1998 11:15:49 -0700 (PDT) Message-Id: <199808131815.LAA20438@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: iCCp votes From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Gerard, as much as we'd like to count your YES vote, I don't think you yet qualify as a voter. The qualification is having sent a message to png-list at least 180 days prior to the close of the voting period. I suggest that in the future every call for votes include at least a pointer to the voting procedures document: ftp://swrinde.nde.swri.edu/pub/png-group/documents/png-registration-19960926.html The document includes a sample call for votes in which all the rules are summarized, but I think a pointer would be sufficient. By the way, the document ends with the line: End of PNG Chunk Registration Process document. Expires 26 Mar 1997. I don't remember any discussion of an expiration date on the procedure. I would assume the procedure stays in effect until it is used to ammend itself. Maybe the expiration date was boilerplate added automatically by the document preparation scripts. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 14:11:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA21719 for ; Thu, 13 Aug 1998 14:11:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA23594 for png-list-outgoing; Thu, 13 Aug 1998 14:01:34 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA23588 for ; Thu, 13 Aug 1998 14:01:27 -0500 Received: (qmail 32427 invoked from network); 13 Aug 1998 19:00:20 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 13 Aug 1998 19:00:20 -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 LAA31117 for ; Thu, 13 Aug 1998 11:59:50 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA20085 for png-list@dworkin.wustl.edu; Thu, 13 Aug 1998 11:59:17 -0700 Date: Thu, 13 Aug 1998 11:59:17 -0700 Message-Id: <199808131859.LAA20085@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: iCCp votes Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam wrote: > End of PNG Chunk Registration Process document. Expires 26 Mar 1997. > I don't remember any discussion of an expiration date on the procedure. > I would assume the procedure stays in effect until it is used to ammend > itself. Maybe the expiration date was boilerplate added automatically > by the document preparation scripts. I don't recall ever having voted on the procedure. As far as I recall, it is a proposal (now expired) that was discussed but never put up for vote and therefore never approved. If I'm mistaken, please let me know the month it was approved so I can check the archives and see how (or whether) I voted on it. Having reread it just recently, I would vote against it today if only for its Subject-line restrictions (which, I believe, you violated in your own iCCP vote...). But whatever. The main thing is to verify its status. If indeed it is "official," it should be moved to the main /pub/png/documents area so that everyone can see what's required. And if it's not official, we need to decide how to proceed with the current vote and how to amend the registration procedure. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 14:15:43 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA21773 for ; Thu, 13 Aug 1998 14:15:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA24014 for png-list-outgoing; Thu, 13 Aug 1998 14:15:54 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA24009 for ; Thu, 13 Aug 1998 14:15:51 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa17234; 13 Aug 98 15:12 EDT Message-ID: <35D33AB7.98BB2884@alumni.rpi.edu> Date: Thu, 13 Aug 1998 15:12:55 -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: iCCp votes References: <199808131815.LAA20438@u33.CS.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > > By the way, the document ends with the line: > > End of PNG Chunk Registration Process document. Expires 26 Mar 1997. > > I don't remember any discussion of an expiration date on the procedure. > I would assume the procedure stays in effect until it is used to ammend > itself. Maybe the expiration date was boilerplate added automatically > by the document preparation scripts. We got worn out discussing the procedure and never voted on it. We used an informal procedure, using the document as a model, instead. The expiration date was 6 months from the date it was posted, applied manually. The sRGB, sPLT, and pCAL specs have also expired, but since they were approved, they still need to get installed in the PNG spec or PNG extensions document. Six months seemed an appropriate period for that to occur. To refresh people's memory about the informal voting rules that we used: At least 10 affirmative votes to pass At least twice as many affirmative votes as negative votes to pass ABSTAIN votes can be submitted but do not count Only votes from people who have posted to png-list at least 180 days prior to close of voting will be counted Only the final vote of any person will be counted A two-week discussion period and a two-week voting period are required. Votes must be cast in a particular format (but I think we relaxed that in the informal procedure -- two of the votes on iCCP have subject lines beginning with "Re:" which may be invalid, strictly speaking) Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 14:18:26 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA21803 for ; Thu, 13 Aug 1998 14:18:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA23939 for png-list-outgoing; Thu, 13 Aug 1998 14:14:57 -0500 Received: from psdbay.com (mail.psdbay.com [206.159.213.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA23934 for ; Thu, 13 Aug 1998 14:14:54 -0500 Received: from [157.57.6.177] (206.159.213.70) by psdbay.com with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 13 Aug 1998 11:12:51 -0800 X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) Date: Thu, 13 Aug 1998 12:19:01 -0700 Subject: Re: iCCP vote From: "Brad Pettit" To: PNG List Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Message-ID: <1309115725-441885491@psdbay.com> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit I vote Yes. ---------- >From: Greg Roelofs >To: png-list@dworkin.wustl.edu >Subject: iCCP vote >Date: Wed, Aug 12, 1998, 12:12 PM > >Just a reminder: the voting period for the proposed iCCP chunk ends next >Tuesday at around 7am Pacific time. So far there are 8 votes in favor; >two more are needed for passage, according to the proposed voting rules >of way-back-when. > >Don't be shy, now. :-) > >Greg > >-- >Send the message body "help" to png-list-request@dworkin.wustl.edu > > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 15:23:30 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id PAA22655 for ; Thu, 13 Aug 1998 15:23:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA25224 for png-list-outgoing; Thu, 13 Aug 1998 15:22:55 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA25219 for ; Thu, 13 Aug 1998 15:22:49 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA20585; Thu, 13 Aug 1998 13:21:08 -0700 (PDT) Date: Thu, 13 Aug 1998 13:21:08 -0700 (PDT) Message-Id: <199808132021.NAA20585@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: iCCp votes From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > Votes must be cast in a particular format (but I think we relaxed that > in the informal procedure -- two of the votes on iCCP have subject > lines beginning with "Re:" which may be invalid, strictly speaking) Indeed, I just looked through the archives, and we reached consensus on the informal procedure on Fri 27 Sep 1996. These are your exact words, to which several people responded affirmatively: - 180 days since first submission for voter eligibility [in mpng-list I will suggest a shorter time like 90 days because the list hasn't been around so long] - 2-week discussion period - 2-week voting period - votes submitted publicly to png-list - [at least] 10 votes to approve - 2:1 YES:NO required to approve - rejected chunks not to be re-voted unless external conditions change, the proposal changes, or sufficent time [180 days?] has elapsed. Therefore, there is no official format for a vote--we have to use our human judgement. But in the future, I'll try to remember to remove the "Re:" from the subject line. :) By the way, the iCCP votes cast before mine had the wrong file name (hyphens vs. underscores), but we know what was meant. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 16:27:47 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA23402 for ; Thu, 13 Aug 1998 16:27:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA25926 for png-list-outgoing; Thu, 13 Aug 1998 16:26:16 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA25921 for ; Thu, 13 Aug 1998 16:26:11 -0500 Received: (qmail 13519 invoked from network); 13 Aug 1998 21:25:04 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 13 Aug 1998 21:25:04 -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 OAA23013 for ; Thu, 13 Aug 1998 14:24:34 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id OAA10209 for png-list@dworkin.wustl.edu; Thu, 13 Aug 1998 14:24:03 -0700 Date: Thu, 13 Aug 1998 14:24:03 -0700 Message-Id: <199808132124.OAA10209@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: iCCp votes Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam wrote: > Indeed, I just looked through the archives, and we reached consensus on > the informal procedure on Fri 27 Sep 1996. Ah, thanks for the pointer. I just grabbed the September archive and looked through it a bit (mainly messages with "registration" in the subject line). I'm not sure I agree that consensus was reached; Glenn said that it was, but then there was some fuss about reaching a quorum, possibly extending the voting period if an insufficient number of votes were received, etc. I didn't yet look at the October archive to see how (or if) some of these things were resolved, but 27 September seems not to have been the final word on things. There are several reasons why I'm in favor (or at least leaning that way) of relaxing some of the rules a bit: - There is no provision for vacations; ordinarily this isn't a big deal, but in this case I have reason to believe that there are at least three people missing who would otherwise have taken the time to vote. Postponing the vote until September wasn't an option for reasons outside of the group's control (i.e., ISO/IEC JTC schedules). - The six-month rule was intended to ensure that voters were "sufficiently familiar with PNG to recognize potential problems" (in the absence of actual sample implementations to prove a chunk's worthiness). That's a direct quote from Tom Lane, who first proposed most of the essential points that Glenn summarized a few weeks later. I would argue that anyone who can implement most of MNG in three months is probably "sufficiently familiar with PNG" to be allowed to vote. (I refer to Gerard Juyn, of course. I don't know how long Brad Pettit has been posting, and he hasn't personally posted any software, but he clearly seems to be a PNG implementer of some sort.) - The required number of votes was based on the list traffic of the time; again, quoting Tom's original proposal: Picking some numbers out of the air, something like ten YES votes and no NO votes would seem like a reasonable threshold for deciding that a chunk has no problems and should pass the vote. (I'm guessing from recent list traffic that a dozen or two people might be sufficiently interested to put the effort into vetting any particular chunk. We might have to adjust the number after we get some experience.) If there are any NO votes at all, my instinct would be to raise the threshold of YES votes considerably --- maybe require fifteen YES votes? But we don't want to turn a single NO into a veto power. We've got some experience now, and I don't think anywhere near two dozen people have posted lately, much less posted regularly (though I haven't checked the recent archives to be sure). My sense is that more like 12 to 16 people are actually active, to greater or lesser extent, and only about 8 are very active. Anyway, I think iCCP will probably squeak by even with the old guide- lines in place, but I'm not certain of it. I definitely think it's going to pass according to the *spirit* of the guidelines (call it list-consensus or whatever). I'll forego any more predictions or comments about iCCP's vote until the nominal two-week period closes, but I would like to hear other opinions about the generic voting process itself. Greg P.S. ObDisclaimer: I do have a small vested interest in seeing iCCP succeed; I spent enough time studying it (and sRGB, cHRM and gAMA) to be able to write about it--and I *did* write about it--so it would irk me somewhat to have wasted all of that time and effort. I also just think it rounds out the foursome very nicely; for example, there is *no* other way for software to deal with LCD displays sensibly if it truly wants good cross-platform color reproduction of PNG images. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 17:18:32 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA23997 for ; Thu, 13 Aug 1998 17:18:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA26845 for png-list-outgoing; Thu, 13 Aug 1998 17:19:03 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA26839 for ; Thu, 13 Aug 1998 17:18:59 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id SAA05283; Thu, 13 Aug 1998 18:17:20 -0400 Message-Id: <1.5.4.32.19980813221315.00f543bc@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, 13 Aug 1998 18:13:15 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: iCCp Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 02:24 PM 8/13/98 -0700, you wrote: > for > example, there is *no* other way for software to deal with LCD > displays sensibly if it truly wants good cross-platform color > reproduction of PNG images. I don't agree. As long as a PNG image has defined its own colorspace via gAMA and cHRM or via sRGB, then software can make a good-looking image on an LCD panel, if it knows the ICC profile of the panel (which must come from the user or output hardware, not from the image file). An embedded profile would be needed if the author had designed the image to look good on the LCD panel, without any color correction; then an embedded ICC profile would be needed so software could make it look good on other displays, but that's a far cry from saying that there's *no* other way. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 17:25:27 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA24054 for ; Thu, 13 Aug 1998 17:25:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA26961 for png-list-outgoing; Thu, 13 Aug 1998 17:25:32 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA26955 for ; Thu, 13 Aug 1998 17:25:28 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id AAA27659; Fri, 14 Aug 1998 00:23:49 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-09.nice.iway.fr [194.98.49.73] claimed to be w3.org Message-ID: <35D367BA.C79B4031@w3.org> Date: Fri, 14 Aug 1998 00:24:58 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: iCCp votes References: <199808131815.LAA20438@u33.CS.Berkeley.EDU> <35D33AB7.98BB2884@alumni.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Glenn Randers-Pehrson wrote: > > Adam M. Costello wrote: > > > > By the way, the document ends with the line: > > > > End of PNG Chunk Registration Process document. Expires 26 Mar 1997. > > > > I don't remember any discussion of an expiration date on the procedure. > > I would assume the procedure stays in effect until it is used to ammend > > itself. Maybe the expiration date was boilerplate added automatically > > by the document preparation scripts. > > We got worn out discussing the procedure and never voted on it. We used > an informal procedure, using the document as a model, instead. The informal procedure seems to be working so far, but perhaps there is some need for a formal procedure. This is not usually needed until someone/ some company starts complaining that their proposal got rejected... until then , a procedure as lightweight as possible seems to be best. > To refresh people's memory about the informal voting rules that we used: > > At least 10 affirmative votes to pass > At least twice as many affirmative votes as negative votes to pass > ABSTAIN votes can be submitted but do not count > Only votes from people who have posted to png-list at least 180 days > prior to > close of voting will be counted > Only the final vote of any person will be counted > A two-week discussion period and a two-week voting period are > required. > Votes must be cast in a particular format (but I think we relaxed > that > in the informal procedure -- two of the votes on iCCP have subject > lines beginning with "Re:" which may be invalid, strictly > speaking) The Re: implies that folk remember that the format is complex so they wait for the first vote and then copy that one ;-) I feel that it is more important that we get a significant number of informed votes that that we adhere to some protocol of subject lines. Ten or twenty votes are easy to count manually; if it was ten or twenty thousand then a strict, automatable format might be justified (and would need a separate archived mailing list, etc)... -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 17:48:55 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA24226 for ; Thu, 13 Aug 1998 17:48:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA27438 for png-list-outgoing; Thu, 13 Aug 1998 17:48:34 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA27430 for ; Thu, 13 Aug 1998 17:48:24 -0500 Received: (qmail 16129 invoked from network); 13 Aug 1998 22:47:17 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 13 Aug 1998 22:47:17 -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 PAA13632 for ; Thu, 13 Aug 1998 15:46:47 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id PAA13763 for png-list@dworkin.wustl.edu; Thu, 13 Aug 1998 15:46:16 -0700 Date: Thu, 13 Aug 1998 15:46:16 -0700 Message-Id: <199808132246.PAA13763@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: LCD panels, iCCP Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> for >> example, there is *no* other way for software to deal with LCD >> displays sensibly if it truly wants good cross-platform color >> reproduction of PNG images. > I don't agree. As long as a PNG image has defined its own colorspace > via gAMA and cHRM or via sRGB, then software can make a good-looking > image on an LCD panel, if it knows the ICC profile of the panel (which > must come from the user or output hardware, not from the image file). > An embedded profile would be needed if the author had designed > the image to look good on the LCD panel, without any color correction; > then an embedded ICC profile would be needed so software could make > it look good on other displays, but that's a far cry from saying > that there's *no* other way. Sorry, that's the direction I was thinking of--LCD panels are becoming affordable and will undoubtedly be quite popular for home use and whatnot, since they're so lightweight and compact in the depth dimension. There- fore we will start to see images created on them (directly, or via scanner and follow-up tweaking, or whatever). Keep in mind that ICC profiles and color management modules are still somewhat "future" items themselves, at least in the consumer domain. I agree that the other direction is no real problem (aside from the lack of common info on how LCD panels behave). Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 17:49:53 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA24237 for ; Thu, 13 Aug 1998 17:49:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA27502 for png-list-outgoing; Thu, 13 Aug 1998 17:49:50 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA27489 for ; Thu, 13 Aug 1998 17:49:45 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id AAA28079; Fri, 14 Aug 1998 00:48:05 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-09.nice.iway.fr [194.98.49.73] claimed to be w3.org Message-ID: <35D36D6B.16F42B17@w3.org> Date: Fri, 14 Aug 1998 00:49:15 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: iCCp References: <1.5.4.32.19980813221315.00f543bc@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Glenn Randers-Pehrson wrote: > > At 02:24 PM 8/13/98 -0700, you wrote: > > for > > example, there is *no* other way for software to deal with LCD > > displays sensibly if it truly wants good cross-platform color > > reproduction of PNG images. > > I don't agree. As long as a PNG image has defined its own colorspace > via gAMA and cHRM or via sRGB, then software can make a good-looking > image on an LCD panel, if it knows the ICC profile of the panel (which > must come from the user or output hardware, not from the image file). > > An embedded profile would be needed if the author had designed > the image to look good on the LCD panel, without any color correction; > then an embedded ICC profile would be needed so software could make > it look good on other displays, but that's a far cry from saying > that there's *no* other way. Thank you Glenn I was composing a (longer) message on similar lines but you have covered exactly what I was going to say. Note however that the PNG spec encourages people to not do color correction, so if someone is doing stuff on a portable (or one of these overpriced desktop units that mysteriously substitute an LCD panel for a much higher quality monitor which would still be cheaper) the spec says to post the PNG image as is (and to describe it using gAMA which is not possible with any accuracy) We might want to revisit that advice. -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 13 18:10:37 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id SAA24416 for ; Thu, 13 Aug 1998 18:10:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA27841 for png-list-outgoing; Thu, 13 Aug 1998 18:05:13 -0500 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA27836 for ; Thu, 13 Aug 1998 18:05:07 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id QAA02822 for ; Thu, 13 Aug 1998 16:03:29 -0700 (PDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Thu, 13 Aug 1998 17:07:12 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B1ADE9F3@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: LCD panels, iCCP Date: Thu, 13 Aug 1998 17:07: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@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > >> for > >> example, there is *no* other way for software to deal with LCD > >> displays sensibly if it truly wants good cross-platform color > >> reproduction of PNG images. > > > I don't agree. As long as a PNG image has defined its own > colorspace > > via gAMA and cHRM or via sRGB, then software can make a good-looking > > image on an LCD panel, if it knows the ICC profile of the > panel (which > > must come from the user or output hardware, not from the > image file). > > > An embedded profile would be needed if the author had designed > > the image to look good on the LCD panel, without any color > correction; > > then an embedded ICC profile would be needed so software could make > > it look good on other displays, but that's a far cry from saying > > that there's *no* other way. > > Sorry, that's the direction I was thinking of--LCD panels are becoming > affordable and will undoubtedly be quite popular for home use > and whatnot, > since they're so lightweight and compact in the depth > dimension. There- > fore we will start to see images created on them (directly, > or via scanner > and follow-up tweaking, or whatever). Keep in mind that ICC > profiles and > color management modules are still somewhat "future" items themselves, > at least in the consumer domain. > > I agree that the other direction is no real problem (aside from the lack > of common info on how LCD panels behave). > Since LCDs are physically somewhat linear with respect to luminance while CRTs are somewhat linear with respect to lightness, you seem to be implying that LCD manufacturers will knowingly avoid adding some internal compensation that makes LCDs appears like CRTs. The other consequence of this behaviour would be to make LCDs incompatible with HDTV, DTV and more than a little bit of legacy images. This doesn't even get into the issue of storage and compressability, which is much better in the lightness domain than the luminance domain. >From a manufacturer's standpoint, I see no overwhelming reason NOT to (continue to) include some internal compensation in my LCDs. I would be most interested is hearing otherwise. Michael Stokes -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 14 11:27:25 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA00482 for ; Fri, 14 Aug 1998 11:27:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA10710 for png-list-outgoing; Fri, 14 Aug 1998 11:25:12 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA10701 for ; Fri, 14 Aug 1998 11:25:08 -0500 Received: (qmail 8387 invoked from network); 14 Aug 1998 16:23:58 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 14 Aug 1998 16:23:58 -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 JAA07578 for ; Fri, 14 Aug 1998 09:23:26 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id JAA08569 for png-list@dworkin.wustl.edu; Fri, 14 Aug 1998 09:22:55 -0700 Date: Fri, 14 Aug 1998 09:22:55 -0700 Message-Id: <199808141622.JAA08569@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: RE: LCD panels, iCCP Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Michael Stokes wrote: > Since LCDs are physically somewhat linear with respect to luminance while > CRTs are somewhat linear with respect to lightness, you seem to be implying > that LCD manufacturers will knowingly avoid adding some internal > compensation that makes LCDs appears like CRTs. The other consequence of > this behaviour would be to make LCDs incompatible with HDTV, DTV and more > than a little bit of legacy images. This doesn't even get into the issue of > storage and compressability, which is much better in the lightness domain > than the luminance domain. I am "implying" only what Chris Lilley and others have stated explicitly on this list (i.e., _in the context of PNG_): "LCDs are sigmoidal." I'm pretty sure I asked about two weeks ago what exactly that meant; I know I've sent at least one or two private e-mails on the subject. So far the only good information I've gotten back is something Glenn found, which indicated that at least one type of raw LCD is roughly exponential (gamma = 3) between 0 and 0.6, and that Apple's LCD panel has corrective circuitry that gives "gamma values around 1.7 for red and green and 1.45 for blue." I have no idea what "gamma" means in that context, given Apple's Macintosh LUTs, but I wasn't aware that CRTs had anywhere near that much variance in the transfer functions of their R, G and B channels. Maybe Apple's compensation is just bad. > From a manufacturer's standpoint, I see no overwhelming reason NOT to > (continue to) include some internal compensation in my LCDs. I would be most > interested is hearing otherwise. *I* would be most interested in seeing an actual, real-life transfer- function curve and xy chromaticity diagram for a complete LCD display system. Both Glenn and I have searched the net for one, without success. (Well, I did find a fairly bad LCD xy chromaticity diagram, but part of it is in Japanese, and the resolution is pretty bad.) Presumably you have access to such things; please post one! I don't care if you have to obscure the exact model number or whatever, if that's necessary for "proprietary reasons." Heck, feel free to use a competitor's if you want. If I knew whom to contact in my own company for such things, I would... Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 15 21:10:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA09267 for ; Sat, 15 Aug 1998 21:10:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA29052 for png-list-outgoing; Sat, 15 Aug 1998 21:08:11 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA29028 for ; Sat, 15 Aug 1998 21:08:01 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id TAA23472; Sat, 15 Aug 1998 19:05:50 -0700 (PDT) Date: Sat, 15 Aug 1998 19:05:50 -0700 (PDT) Message-Id: <199808160205.TAA23472@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: PNG 1.1 proposal draft 1.2.2 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have incorporated the recent comments into the PNG 1.1 proposal. Draft 1.2.2 is available from: http://www.cs.berkeley.edu/~amc/png/ The remaining unresolved 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? * Should we refer to CIE 122? * Should we say anything about constructing gamma correction tables using fixed-point math? * The proposed encoder gamma handling section says that images grabbed from a video digitizer are probably in the sRGB color space. So if I decide to write an sRGB chunk on that basis, what rendering intent should I use? Glenn Randers-Pehrson says: > I haven't been able to get to his machine for a couple of days; he > must have powered it down before he left. www.cs.berkeley.edu is not my machine--it's supposed to be more reliable than the one on my desk. I don't know why it was down. Chris Lilley says: > ...if someone is doing stuff on a portable... the spec says to post > the PNG image as is (and to describe it using gAMA which is not > possible with any accuracy) The Encoder Gamma Handling section of the 1.1 proposal says: If the renderer wants to write the displayed sample values to the PNG file, avoiding a separate gamma encoding step for file output, then the renderer should approximate the transfer function of the display system by a power function, and write the reciprocal of the exponent into the gAMA chunk. This will allow a PNG decoder to reproduce what the file's originator saw on screen during rendering. However, it is equally reasonable for a renderer to compute displayed pixels appropriate for the display device, and to perform separate gamma encoding for file storage, arranging to have a value in the gAMA chunk more appropriate to the future use of the image. So at least in this section we recognize both options. Is there another section that comes down too hard on the side of not doing any conversion? AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Aug 16 08:01:15 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA11682 for ; Sun, 16 Aug 1998 08:01:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA02274 for png-list-outgoing; Sun, 16 Aug 1998 07:58:15 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA02269 for ; Sun, 16 Aug 1998 07:58:11 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA18160; Sun, 16 Aug 1998 08:56:18 -0400 Message-Id: <1.5.4.32.19980816125213.00977d74@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, 16 Aug 1998 08:52:13 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: sRGB rendering intent, PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 07:05 PM 8/15/98 -0700, you wrote: >I have incorporated the recent comments into the PNG 1.1 proposal. >Draft 1.2.2 is available There was some discussion of adding a recommendation that encoders use sRGB rendering_intent = 1 as default, to be consistent with the ICC recommendation in the ICC Profile Format Specification, Appendix E, Paragraph 8. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Aug 16 11:34:32 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA12288 for ; Sun, 16 Aug 1998 11:34:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA03665 for png-list-outgoing; Sun, 16 Aug 1998 11:29:38 -0500 Received: from mail.mco.bellsouth.net (mail.mco.bellsouth.net [205.152.48.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA03659 for ; Sun, 16 Aug 1998 11:29:35 -0500 Received: from bellsouth.net (host-209-214-32-137.mco.bellsouth.net [209.214.32.137]) by mail.mco.bellsouth.net (8.8.8-spamdog/8.8.5) with ESMTP id MAA22475 for ; Sun, 16 Aug 1998 12:27:40 -0400 (EDT) Message-ID: <35D73214.B5C145CE@bellsouth.net> Date: Sun, 16 Aug 1998 12:25:09 -0700 From: John Riddle X-Mailer: Mozilla 4.04 [en]C-bls40 (Win95; U) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu Subject: A simple request. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit My name is David, and I am currently trying to develop some software. I would be greatly appreciative if you would allow me to join your "PNG mailing list". You can e-mail me at dbc-pa@usa.net . -Thanks -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Aug 16 16:41:38 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA13396 for ; Sun, 16 Aug 1998 16:41:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA05684 for png-list-outgoing; Sun, 16 Aug 1998 16:42:09 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA05678 for ; Sun, 16 Aug 1998 16:42:06 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id RAA00648; Sun, 16 Aug 1998 17:40:07 -0400 Message-Id: <1.5.4.32.19980816213601.00f69a10@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, 16 Aug 1998 17:36:01 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: A simple request. Cc: dbc-pa@usa.net Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 12:25 PM 8/16/98 -0700, you wrote: >My name is David, and I am currently trying to develop some software. I >would be greatly appreciative if you would allow me to join your "PNG >mailing list". Sure. Write to majordomo@dworkin.wustl.edu In the body of your message, put subscribe png-list subscribe png-implement subscribe png-announce Also, if you are interested in the Multiple-image spinoff and lossy-compression spinoff formats, put the following in the body of your message as well. subscribe mpng-list subscribe pnp-list You can find archives of all of the lists at ftp://swrinde.nde.swri.edu/pub/png-group/ The "png-implement" list is the one that deals mostly with software development, primarily about development of libpng. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Aug 16 19:04:43 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA13888 for ; Sun, 16 Aug 1998 19:04:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA06851 for png-list-outgoing; Sun, 16 Aug 1998 19:04:42 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA06845 for ; Sun, 16 Aug 1998 19:04:38 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id RAA24184; Sun, 16 Aug 1998 17:02:43 -0700 (PDT) Date: Sun, 16 Aug 1998 17:02:43 -0700 (PDT) Message-Id: <199808170002.RAA24184@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: sRGB rendering intent, PNG 1.1 proposal draft 1.2.2 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > There was some discussion of adding a recommendation that encoders > use sRGB rendering_intent = 1 as default, to > be consistent with the ICC recommendation in the ICC Profile Format > Specification, Appendix E, Paragraph 8. For a long time now, whenever I've seen the list of four rendering intents, I've wondered to myself, "What the heck do these mean?" I just read parts of chapters 4, A, and E of the ICC spec, and I think I have a rough understanding now. Perhaps it would be helpful to be more verbose when we list the four rendering intents in the sRGB chunk spec. How about something like this: 0: Perceptual The image gamut is to be compressed or expanded to fill the output device gamut, at the expense of colorimetric accuracy. 1: Relative colorimetric The image gamut is to be linearly scaled so that image white maps to output device white, and colors falling outside the device gamut are to be clipped. The ICC recommends this intent by default in most cases. 2: Saturation Saturation is to be preserved at the expense of hue and lightness. 3: Absolute colorimetric The image gamut is not to be scaled, and colors falling outside the output device gamut are to be clipped. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Aug 16 19:32:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA14000 for ; Sun, 16 Aug 1998 19:32:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA07038 for png-list-outgoing; Sun, 16 Aug 1998 19:32:28 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA07032 for ; Sun, 16 Aug 1998 19:32:25 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id UAA06353; Sun, 16 Aug 1998 20:30:29 -0400 Message-Id: <1.5.4.32.19980817002623.00d52e38@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, 16 Aug 1998 20:26:23 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: sRGB rendering intent, PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 05:02 PM 8/16/98 -0700, Adam wrote: >I just read parts of chapters 4, A, and E of the ICC spec, and I think I >have a rough understanding now. Perhaps it would be helpful to be more >verbose when we list the four rendering intents in the sRGB chunk spec. >How about something like this: Looks like a nice, succinct, accurate, helpful summary. Put it in, by all means! Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sun Aug 16 22:59:56 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA15282 for ; Sun, 16 Aug 1998 22:59:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA08273 for png-list-outgoing; Sun, 16 Aug 1998 22:59:57 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA08268 for ; Sun, 16 Aug 1998 22:59:54 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id XAA13581; Sun, 16 Aug 1998 23:57:56 -0400 Message-Id: <1.5.4.32.19980817035351.00983bd8@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, 16 Aug 1998 23:53:51 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: gAMA in PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Here's how the gAMA chunk specification reads, according to Adam's latest proposal (draft 1.2.2) after being run through the PNG documentation scripts: 4.2.3. gAMA Image gamma The gAMA chunk specifies the the relationship between the image samples and the desired display output intensity as a power function: sample = light_out ^ gamma Here sample and light_out are normalized to the range 0.0 (minimum intensity) to 1.0 (maximum intensity). Therefore: sample = integer_sample / (2^bitdepth - 1) The gAMA chunk contains: Gamma: 4 bytes The value is encoded as a 4-byte unsigned integer, representing gamma times 100000. For example, a gamma of 1/2.2 would be stored as 45455. Technically, "desired display output intensity" is not specific enough; one needs to specify the viewing conditions under which the output is desired. gAMA assumes the reference viewing conditions of the sRGB specification [sRGB], which are based on ISO standards [ISO-3664]. Adjusting for different viewing conditions is a complex process normally handled by a Color Management System (CMS). If this adjustment is not performed, the error is usually small. Applications desiring high color fidelity may wish to use an sRGB chunk (see the sRGB specification) or an embedded ICC profile [ICC]. If the encoder does not know the image's gamma value, it should not write a gAMA chunk; the absence of a gAMA chunk indicates that the gamma is unknown. If the gAMA chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. An sRGB chunk or iCCP chunk, when present and recognized, overrides the gAMA chunk. See the sRGB specification and the the iCCP specification, Gamma correction (Section 2.7), Recommendations for Encoders: Encoder gamma handling (Section 9.2), and Recommendations for Decoders: Decoder gamma handling (Section 10.5). I still think that novices will have trouble with this. I doubt that they will read any further than "Technically, ..." It might help somewhat to say "linear_light_out" instead of "light_out". (We don't use or define "light_out" anywhere else in the proposed spec.) I'd extend the example to say "For example, a gamma of 1/2.2 would be stored as 45455 (this is a reasonable value of gamma for images that look right when they are displayed without gamma processing on a typical PC monitor.) Also, just before "Technically" I'd put a paragraph that says "When gamma is 1.0, the samples are in a linear colorspace. This linear colorspace is not precisely defined, however, unless a cHRM chunk is also present and recognized, which will relate it to the CIE XYZ colorspace." Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 00:15:25 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id AAA15663 for ; Mon, 17 Aug 1998 00:15:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA09009 for png-list-outgoing; Mon, 17 Aug 1998 00:15:56 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA09004 for ; Mon, 17 Aug 1998 00:15:53 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id WAA25356; Sun, 16 Aug 1998 22:13:56 -0700 (PDT) Date: Sun, 16 Aug 1998 22:13:56 -0700 (PDT) Message-Id: <199808170513.WAA25356@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > I still think that novices will have trouble with this. I doubt that > they will read any further than "Technically, ..." There's not much of importance after that, except the next paragraph that says not to write a gAMA chunk if you don't know the gamma value. Maybe we should swap the order of those two paragraphs. > It might help somewhat to say "linear_light_out" instead of > "light_out". The phrase "linear light" means nothing to me. I think the text surrounding the equation makes it clear that light_out is proportional to the display output intensity. Would it be better to use the word "proportional" rather than "normalized"? > I'd extend the example to say "For example, a gamma of 1/2.2 would > be stored as 45455 (this is a reasonable value of gamma for images > that look right when they are displayed without gamma processing on a > typical PC monitor.) That information is already in the recommendations and gamma tutorial. We want poeple to read those sections, and we don't want them to use the value 45455 without understanding why. Does anyone else want this added to the gAMA section? > "When gamma is 1.0, the samples are in a linear colorspace. "Linear colorspace" is meaningless. When gamma is 1.0, the samples are proportional to the output light intensity, which is evident from the equation. Is this noteworthy enough to add a textual statement? > This linear colorspace is not precisely defined, however, unless a > cHRM chunk is also present and recognized, which will relate it to the > CIE XYZ colorspace." The colorspace of a color image is not precisely defined without cHRM regardless of the value of gamma. Is this worth mentioning in the gAMA section? It's possible to understand concept of gamma without understanding the more complex concept of colorspace, so it might be nice to leave the latter out of the gAMA section. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 08:09:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA17534 for ; Mon, 17 Aug 1998 08:09:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA11443 for png-list-outgoing; Mon, 17 Aug 1998 08:02:40 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA11437 for ; Mon, 17 Aug 1998 08:02:35 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA23977; Mon, 17 Aug 1998 09:00:32 -0400 Message-Id: <1.5.4.32.19980817125625.00f62f6c@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, 17 Aug 1998 08:56:25 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:13 PM 8/16/98 -0700, Adam wrote: >Glenn Randers-Pehrson says: > >> "When gamma is 1.0, the samples are in a linear colorspace. > >"Linear colorspace" is meaningless. When gamma is 1.0, the samples are >proportional to the output light intensity, which is evident from the >equation. Is this noteworthy enough to add a textual statement? > The trouble with that is that it's fine for people who already understand gamma. I think a fair percentage of novices will interpret both "proportional to output intensity" and the equation to mean "looks OK to me when I send them straight to the screen, therefore gamma = 1." What's sad is that with a lot of software, that will work fine because it ignores the gAMA chunk. We have been living and breathing gamma for 3-1/2 years, so no matter what we write, we'll probably understand it. And I think we do need to say what gamma = 1 really means. Technically and precisely, I agree that it means nothing. But it is a proportional-to-intensity space into which we need to transform our pixels if we want to do composition (I was wanting to add some statement about how important it is to transform into and out of this nebulous linear space when doing composition, and to be sure to use sufficient bit_depth in that linear working space, but it's difficult to figure out exactly how to say it when gamma=1 is such a loose end). Near the beginning of "Decoder gamma handling" we called it "a linear intensity value", which has been changed to "proportional to the desired display output intensity" which is correct but awkward and makes the motivation for doing that less clear (we want to be doing pixel operations in a linear colorspace -- or something equivalent to a "linear colorspace" -- "linear workspace"?). Also it is the connection space that cHRM uses ("*linear* RGB floating point data"), isn't it? "If gamma is not 1.0, make it so on the floating point data." Gamma=1.0 must mean something there. About explaining why the example is 1/2.2, that will be clear to people who read the chapter on "Encoder gamma handling" and see "choosing a value that causes the gamma value in the gAMA chunk to be 1/2.2 is often a reasonable choice..." Why not reinforce that in the gAMA chunk specification? I don't think it would confuse anyone who reads the appendices, but would be helpful to those who won't. [Dave, don't forget to vote on iCCP before you dive into this discussion] Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 08:49:35 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA17874 for ; Mon, 17 Aug 1998 08:49:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA11865 for png-list-outgoing; Mon, 17 Aug 1998 08:41:43 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA11860 for ; Mon, 17 Aug 1998 08:41:39 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA25332; Mon, 17 Aug 1998 09:39:40 -0400 Message-Id: <1.5.4.32.19980817133533.00f779bc@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, 17 Aug 1998 09:35:33 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: VOTE on iCCP 19980729 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp_proposal_19980729.txt Glenn Randers-Pehrson Re-voting with underscores in the filename. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 09:28:29 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id JAA18226 for ; Mon, 17 Aug 1998 09:28:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA12171 for png-list-outgoing; Mon, 17 Aug 1998 09:18:00 -0500 Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA12166 for ; Mon, 17 Aug 1998 09:17:57 -0500 Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id JAA10320 for ; Mon, 17 Aug 1998 09:15:59 -0500 (CDT) Received: from sji-ca3-181.ix.netcom.com(209.109.233.181) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma010309; Mon Aug 17 09:15:47 1998 Message-Id: <3.0.5.32.19980817071720.0094ecc0@popd.ix.netcom.com> X-Sender: jcbowler@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 17 Aug 1998 07:17:20 -0700 To: PNG List From: John Bowler Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 In-Reply-To: <1.5.4.32.19980817125625.00f62f6c@netgsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 08:56 17/08/98 -0400, Glenn Randers-Pehrson wrote: > I think a fair percentage of novices will >interpret both "proportional to output intensity" and the >equation to mean "looks OK to me when I send them straight to >the screen, therefore gamma = 1." I liked Adam's wording. It is concise and it is clear that the words after "Technically" can be skipped safely. As Glenn pointed out before this skips the important paragraph about not recording gamma if it is not known. If that paragraph occurs earlier this would seem to help answer the above question, perhaps something to the effect "different displays systems require different gamma values see Section 2.7, 'Recommendations for Encoders'" would help more. >And I think we do need to say what gamma = 1 really means. >Technically and precisely, I agree that it means nothing. I think it can have a very precise meaning. sRGB defines, precisely, the light emitted by a monitor and the viewing conditions. Thus a gAMA of 100000 (on an image with no cHRM or iCCP) allows a simple linear equation to be written to determine the absolute light output on an sRGB system for each pixel value. I'm not sure this needs to be explained in the main gAMA section. One thing which maybe should be said in that section is that the alpha values are *not* gamma encoded - I know this was a mistake I made. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 10:01:48 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA18736 for ; Mon, 17 Aug 1998 10:01:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA12443 for png-list-outgoing; Mon, 17 Aug 1998 09:57:29 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA12438 for ; Mon, 17 Aug 1998 09:57:26 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa21405; 17 Aug 98 10:50 EDT Message-ID: <35D8433C.8CD3911C@alumni.rpi.edu> Date: Mon, 17 Aug 1998 10:50:36 -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: gAMA in PNG 1.1 proposal draft 1.2.2 References: <3.0.5.32.19980817071720.0094ecc0@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit John Bowler wrote: > [Glenn wrote] > >And I think we do need to say what gamma = 1 really means. > >Technically and precisely, I agree that it means nothing. > > I think it can have a very precise meaning. sRGB defines, precisely, the > light emitted by a monitor and the viewing conditions. Thus a gAMA of > 100000 (on an image with no cHRM or iCCP) allows a simple linear equation > to be written to determine the absolute light output on an sRGB system for > each pixel value. That's saying that gamma=1.0 is the sRGB linear colorspace sRGB (as opposed to sRGB nonlinear colorspace sR'G'B' which is the one we call the "sRGB" standard colorspace). But in the absence of an sRGB or cHRM chunk, is that necessarily true? Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 11:37:20 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id LAA19808 for ; Mon, 17 Aug 1998 11:37:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA13631 for png-list-outgoing; Mon, 17 Aug 1998 11:37:25 -0500 Received: from pedigree.cs.ubc.ca (pop.cs.ubc.ca [142.103.6.51]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA13612 for ; Mon, 17 Aug 1998 11:37:20 -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 JAA16198 for ; Mon, 17 Aug 1998 09:35:16 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <3.0.5.32.19980817071720.0094ecc0@popd.ix.netcom.com> References: <1.5.4.32.19980817125625.00f62f6c@netgsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Aug 1998 09:35:24 -0700 To: PNG List From: Dave Martindale Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List We need to be quite careful about wording things to do with gAMA now that we's switched from discussing things in terms of the camera to discussing things in terms of the display. The reason is that people want the reproduced image to have a higher contrast than is physically accurate in order for it to "look right". Consider the "gAMA 100000" case with a real image. Light hits some sort of sensor, which measures light flux and produces a quantized number proportional to that flux. When this is displayed on a frame buffer, the frame buffer will have a LUT loaded whose gamma is probably about 0.45. The CRT, though, has a gAMA of around 2.5, and this results in an image *on screen* whose contrast relative to the original scene, and relative to the data in the file, is 2.5*0.45 = 1.125. And this is how everything is supposed to be working in this case - we want that extra contrast. Now, in this situation, it *is* true that values in the file are linearly proportional to light intensity in the original scene, while they are *not* proportional to light emanating from the screen because of the additional 1.125 contrast change. So our original choice of explaining gAMA as relative to the original scene certainly gave us something easier to explain. The problem with *it* was that the explanation only applied to "perceptually accurate" reproduction of a real scene. If there was no original scene, or someone had deliberately altered the image to give a different effect, then the sample values in the file were never (or were no longer) proportional to original scene light - and yet they should still have a gAMA of 100000 because the gAMA really tells how to *display* the image, not how it was created. Ok, so now we talk about display and we've fixed that problem. But what gAMA now *really* tells you is how the gamma of this particular file is related to the gamma of a linear-light image, *not* the light emitted from the screen, since the latter involves additional viewing contrast not accounted for by gAMA. (Alternately, you can use any other value of gAMA as your "calibrated" value, not just 1.0. The important thing is that changes in gAMA from the calibrated value require compensation somewhere. So, in concept, the viewing software needs to do the following: It needs to figure out what it needs to do to view an image of some reference gamma on a particular monitor, either by measurement or by fiat. You might imagine someone displaying a gAMA 1.0 image on the display and adjusting LUT characteristics until they get the most pleasing display. In that case, their reference gamma is 1.0 and the "display compensation" is that particular LUT. If they are following sRGB recommendations, then their reference gamma is 0.45 (by declaration of sRGB) and their "display compensation" is nothing (again by declaration of sRGB). Then, when the software receives an image with arbitrary gamma, it needs to compare the new image gamma to the reference gamma, and figure out what gamma change (if any) is needed. It then has to apply that gamma change *followed* by the display compensation when loading the pixels into the frame buffer. Of course, it could build a single LUT that applies both functions at once. This ensures that images that come in with various values of gAMA are all displayed *the same*, which is our aim. But it doesn't mean that any of them are displayed with light coming off the screen being proportional to sample values in the file - in general that will not be true (unless the file has a strange gAMA of about 1.125). Nor is it true that the DAC output voltages will be proportional to sample values, except in the special case of gAMA around 0.45. We don't really want to try explaining all of this in the body of the spec, I think. But at the same time we need to avoid saying things that are technically wrong, like "when gAMA is 1.0 the sample values in the file are proportional to the light emitted by the monitor". This makes it easier to understand for some people, but will make it worse for someone who thinks (correctly) that the statement is wrong but isn't sufficiently sure of that. As for how exactly to word the section to make that true: I don't know. I'll have to look at it again. Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 13:05:17 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA20641 for ; Mon, 17 Aug 1998 13:05:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA14724 for png-list-outgoing; Mon, 17 Aug 1998 13:00:16 -0500 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA14719 for ; Mon, 17 Aug 1998 13:00:11 -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 NAA08945 for ; Mon, 17 Aug 1998 13:57:17 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Mon, 17 Aug 1998 12:01:56 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B1ADEA15@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: gAMA in PNG 1.1 proposal draft 1.2.2 Date: Mon, 17 Aug 1998 12:01:53 -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@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Todd Newman and I have been using the terms "intensity space" to refer to color spaces that are linear with respect to luminance and "intuitive space" to refer to color spaces that are linear with respec to lightness. I'm not sure this helps, but I've found this description and distinction quite helpful personally. Mostly, I'd recommend always using the phrase "with respect to..." immediately after the word linear :) Michael > -----Original Message----- > From: Glenn Randers-Pehrson [mailto:randeg@alumni.rpi.edu] > Sent: Monday, August 17, 1998 8:51 AM > To: PNG List > Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 > > > John Bowler wrote: > > > [Glenn wrote] > > >And I think we do need to say what gamma = 1 really means. > > >Technically and precisely, I agree that it means nothing. > > > > I think it can have a very precise meaning. sRGB defines, > precisely, the > > light emitted by a monitor and the viewing conditions. > Thus a gAMA of > > 100000 (on an image with no cHRM or iCCP) allows a simple > linear equation > > to be written to determine the absolute light output on an > sRGB system for > > each pixel value. > > That's saying that gamma=1.0 is the sRGB linear colorspace sRGB (as > opposed to sRGB nonlinear colorspace sR'G'B' which is the one we call > the > "sRGB" standard colorspace). But in the absence of an sRGB or cHRM > chunk, > is that necessarily true? > > Glenn > > -- > Send the message body "help" to png-list-request@dworkin.wustl.edu > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 13:31:50 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA20875 for ; Mon, 17 Aug 1998 13:31:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA14378 for png-list-outgoing; Mon, 17 Aug 1998 12:49:48 -0500 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA14372 for ; Mon, 17 Aug 1998 12:49:43 -0500 Received: from boi-itex02.boi.hp.com (exchange.boi.hp.com [15.98.137.131]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id KAA20906 for ; Mon, 17 Aug 1998 10:47:45 -0700 (PDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Mon, 17 Aug 1998 11:51:28 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B1ADEA14@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: RE: sRGB rendering intent, PNG 1.1 proposal draft 1.2.2 Date: Mon, 17 Aug 1998 11:51:23 -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@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List OK, I have some sins of the past to make amends for. When I wrote the original ICC specification, we got into a big argument on what the rendering intents actually meant. The only way we could reach consensus was essentially leave the actually gamut mapping implementation issues completely undefined. The was in part due to some participants feeling they had superior, proprietary or patented approaches that they did not want to share or limit. My current informal understanding of the intents is more based on target object and not processing method. Unfortunately, this also leads to confusion, but it's the best we have. In summary, I believe if you print your understanding of the ICC rendering intents, it will actually be in conflict with the ICC, since they don't offer any help on processing issues in general. Here's my shot at an alternative... 0: Perceptual This intent targets for images, such as photographs or pictures where the colors blend together. One common method to achieve this is to compress or expand the image gamut to fill the output device gamut, at the expense of colorimetric accuracy. This is the most default intent in most cases. 1: Relative colorimetric This intent targets color matching, where you use a color that you need to match exactly, such as a corporate logo. One common method to achieve this is to gamut map the image gamut to be linearly scaled so that image white maps to output device white, and colors falling outside the device gamut are to be clipped. 2: Saturation This intent targets graphics, such as charts, graphcs, or fully saturated bright colors. One common method to achieve this is by gamut mapping that preserves saturation at the expense of hue and lightness. 3: Absolute colorimetric This intent targts proofing, where you want to preview the color settings from another device. One common method to achieve this is to not scale the image gamut, and clip colors falling outside the output device gamut. Michael Stokes > -----Original Message----- > From: amc@cs.berkeley.edu [mailto:amc@cs.berkeley.edu] > Sent: Sunday, August 16, 1998 6:03 PM > To: png-list@dworkin.wustl.edu > Subject: Re: sRGB rendering intent, PNG 1.1 proposal draft 1.2.2 > > > Glenn Randers-Pehrson says: > > > There was some discussion of adding a recommendation that encoders > > use sRGB rendering_intent = 1 as default, to > > be consistent with the ICC recommendation in the ICC Profile Format > > Specification, Appendix E, Paragraph 8. > > For a long time now, whenever I've seen the list of four rendering > intents, I've wondered to myself, "What the heck do these mean?" > > I just read parts of chapters 4, A, and E of the ICC spec, > and I think I > have a rough understanding now. Perhaps it would be helpful > to be more > verbose when we list the four rendering intents in the sRGB > chunk spec. > How about something like this: > > 0: Perceptual > The image gamut is to be compressed or expanded to fill > the output device gamut, at the expense of colorimetric > accuracy. > > 1: Relative colorimetric > The image gamut is to be linearly scaled so that image > white maps to output device white, and colors falling > outside the device gamut are to be clipped. The ICC > recommends this intent by default in most cases. > > 2: Saturation > Saturation is to be preserved at the expense of hue and > lightness. > > 3: Absolute colorimetric > The image gamut is not to be scaled, and colors falling > outside the output device gamut are to be clipped. > > AMC > > -- > Send the message body "help" to png-list-request@dworkin.wustl.edu > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 13:32:47 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA20885 for ; Mon, 17 Aug 1998 13:32:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA15096 for png-list-outgoing; Mon, 17 Aug 1998 13:23:59 -0500 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA15091 for ; Mon, 17 Aug 1998 13:23:55 -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 OAA27274 for ; Mon, 17 Aug 1998 14:21:00 -0400 (EDT) Received: by exchange.boi.hp.com with Internet Mail Service (5.5.1960.3) id ; Mon, 17 Aug 1998 12:25:40 -0600 Message-ID: <212BCC3857C6D111930A0800099B19B1ADEA17@exchange.boi.hp.com> From: "Stokes, Michael" To: "'PNG List'" Subject: VOTE on iCCP 19980729 Date: Mon, 17 Aug 1998 12:25:38 -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@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ iccp_proposal_19980729.txt Michael Stokes -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 17:14:56 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA22684 for ; Mon, 17 Aug 1998 17:14:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA18040 for png-list-outgoing; Mon, 17 Aug 1998 17:09:42 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA18035 for ; Mon, 17 Aug 1998 17:09:39 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id AAA13794; Tue, 18 Aug 1998 00:07:37 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-09.nice.iway.fr [194.98.49.73] claimed to be w3.org Message-ID: <35D8A9EA.43D7BDA3@w3.org> Date: Tue, 18 Aug 1998 00:08:42 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu Subject: Tiff to png Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit I recently was asked for help, someone wanted a converter for bilevel TIFF to PNG. Simple enouh. For NT, and either free or low cost shareware; still fairly simple, I thought. There is source code for a tifftopng converter at [1] but I don't have a compiler at home. I would tend to use the netpbm utilities on unix for this: tifftopnm file.tiff | pnmtopng > file.png but the request was for NT and again, I don't have an NT compiler handy. At home under NT I generally use Ulead smart saver as both a Photoshop 5 plug-in and as a stand-alone program. It turns out that Ulead smart saver can only go down to 2bits/pixel indexed images, not 1bit. Same for Photoshop 4 and 5 which, mysteriously, refuse you the option of saving as PNG when the image is bilevel. I rarely if ever use bilevel images so I never noticed the lack before. There are various compiled, free/share/pay image conversion programs at [2]. So I sifted through them. I tried one such converter, AlterImage32 ($35 shareware). It read a bilivel TIFF and output a PNG. The good news: it is smaller than the TIFF ( 107k instead of 389k). The bad news is that it is a 24bit PNG so it could actually be a bit smaller yet ;-) Ulead smart saver (which can only go down to 2bit samples for indexed and greyscale) took that down to 35k (34,980 bytes) as a 2bit indexed PNG - 2bit samples but with two palette entries. Still not great. Macromedia Fireworks (certainly not free) saved it out as an 8bit indexed image, complete with spurious sBIT chunk saying there were 8 bits of precision - which is entirely the wrong thing to do! It also saved out some unnecessary keywords, pHYs, etc and only used default compression. 49k, still smaller than the GIF at 89k that firemworks saved out but not optimal. Netpbm with the command given earlier gave a 35k (36,561 bytes) image at 1bit/pixel greyscale. Which is bigger than the 2bit indexed image. PNGcrush -brute on the image from netpbm got it down to 34,105 bytes. But I was still surprised how little different that was from the two bit indexed image. Should I be? Is the refusal of USS to go below 2bits (4 colors) a simple oversight or a canny realisation about the characteristics of PNG compression? Comments welcome, either of the form "my program will make smaller files than that" or "of course, the compression scheme can never get smaller than that because ..." If anyone wants to have a crack at it, the 1bit/pixel greyscale png is at [3] for the time being; nothing great artistically you understand, just some greyscale doodles and a couple of graduated fills converted to bilevel by screening; if you want to compare your results to mine you will need the same file, though. [1] http://www.cdrom.com/pub/png/pngcode.html [2] http://www.cdrom.com/pub/png/pngapcv.html [3] http://www.w3.org/people/chris/png/bitest-pbm.png -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 18:01:09 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id SAA23166 for ; Mon, 17 Aug 1998 18:01:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA18520 for png-list-outgoing; Mon, 17 Aug 1998 17:56:33 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA18515 for ; Mon, 17 Aug 1998 17:56:30 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id PAA26281; Mon, 17 Aug 1998 15:54:29 -0700 (PDT) Date: Mon, 17 Aug 1998 15:54:29 -0700 (PDT) Message-Id: <199808172254.PAA26281@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave Martindale says: > But at the same time we need to avoid saying things that are > technically wrong, like "when gAMA is 1.0 the sample values in the > file are proportional to the light emitted by the monitor". If the viewing conditions are the sRGB reference viewing conditions, and gamma is 1.0, then the sample values in the file are supposed to be proportional to the intensity of the light emitted by the monitor. The gAMA section of the 1.1 proposal makes no stronger claim than that. We have agreed that images designed for PCs have a gamma of 1/2.2. We have accepted that CRTs have an exponent of 2.2. Therefore, an image with a gamma of 1.0 must have samples proportional to the light output of the monitor. If we ever find out we were wrong about the CRT exponent, we'll have to retract that claim, but for now it stands. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 19:26:56 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA24245 for ; Mon, 17 Aug 1998 19:26:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA19103 for png-list-outgoing; Mon, 17 Aug 1998 19:27:18 -0500 Received: from pedigree.cs.ubc.ca (pedigree.cs.ubc.ca [142.103.6.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA19098 for ; Mon, 17 Aug 1998 19:27:14 -0500 Received: from chaplin.cs.ubc.ca (davem@chaplin.cs.ubc.ca [142.103.9.32]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with SMTP id RAA21503 for ; Mon, 17 Aug 1998 17:25:08 -0700 (PDT) Date: Mon, 17 Aug 1998 17:25:08 -0700 (PDT) From: Dave Martindale Message-Id: <199808180025.RAA21503@pedigree.cs.ubc.ca> To: png-list@dworkin.wustl.edu Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > If the viewing conditions are the sRGB reference viewing conditions, > and gamma is 1.0, then the sample values in the file are supposed to be > proportional to the intensity of the light emitted by the monitor. The > gAMA section of the 1.1 proposal makes no stronger claim than that. I don't think that is necessarily correct. > We have agreed that images designed for PCs have a gamma of 1/2.2. > We have accepted that CRTs have an exponent of 2.2. Therefore, an > image with a gamma of 1.0 must have samples proportional to the light > output of the monitor. If we ever find out we were wrong about the CRT > exponent, we'll have to retract that claim, but for now it stands. I haven't accepted that CRTs actually have an exponent of 2.2. I talked to Charles Poynton at SIGGRAPH, and he still believes it's about 2.5 based on some measurements that the BBC made. For myself, I don't believe it's exactly a power function at all, and a power function is only an approximation. Regardless of what it actually is, I believe that the PNG standard should stay out of the argument. All that should matter to us is that images tagged with sRGB should be dumped directly into the framebuffer on an sRGB-compliant machine, and you will get the correct appearance, regardless of whether the actual CRT gamma is 2.2 or 2.5 or something else. We don't need to decide what CRT gamma is in order to write the PNG spec. All we need to say is that as the gAMA value in the file changes, the decoder compensates for this change in a well-defined way that results in getting *the same* result on screen. Whether or not this result is exactly correct, and whether its contrast is the same as the original scene (if the CRT gamma is 2.2) or somewhat higher (if the CRT gamma is 2.5 instead) can and should remain outside the scope of the standard. But I'd hate to write the standard assuming that CRT gamma really is 2.2, always. Because if the sRGB people turn out to be wrong about that, then the PNG spec is wrong too. And it doesn't need to be, because we only really care about relative changes in gamma. Dave > > AMC > > -- > Send the message body "help" to png-list-request@dworkin.wustl.edu > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 19:33:35 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA24275 for ; Mon, 17 Aug 1998 19:33:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA19143 for png-list-outgoing; Mon, 17 Aug 1998 19:34:32 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA19137 for ; Mon, 17 Aug 1998 19:34:28 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id UAA22497; Mon, 17 Aug 1998 20:32:27 -0400 Message-Id: <1.5.4.32.19980818002820.00f758c8@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, 17 Aug 1998 20:28:20 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: Tiff to png Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 12:08 AM 8/18/98 +0200, you wrote: >PNGcrush -brute on the image from netpbm got it down to 34,105 bytes. >But I was still surprised how little different that was from the two bit >indexed image. Should I be? Is the refusal of USS to go below 2bits (4 >colors) a simple oversight or a canny realisation about the >characteristics of PNG compression? My old ppm-png (gzip-based) wrote a 33133-byte, 1-bit grayscale file. There's not much pngcrush can do with it because "none" filtering is best and your file is already "none" filtered. >Comments welcome, either of the form "my program will make smaller files >than that" or "of course, the compression scheme can never get smaller >than that because ..." My experimental bzip-based ppm-png makes a file that's 26452 bytes, which is of course unreadable by any PNG decoder. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 20:42:34 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA24472 for ; Mon, 17 Aug 1998 20:42:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA19595 for png-list-outgoing; Mon, 17 Aug 1998 20:32:55 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA19590 for ; Mon, 17 Aug 1998 20:32:51 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id SAA26940; Mon, 17 Aug 1998 18:30:46 -0700 (PDT) Date: Mon, 17 Aug 1998 18:30:46 -0700 (PDT) Message-Id: <199808180130.SAA26940@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave Martindale says: > All that should matter to us is that images tagged with sRGB should be > dumped directly into the framebuffer on an sRGB-compliant machine, and > you will get the correct appearance, regardless of whether the actual > CRT gamma is 2.2 or 2.5 or something else. We know the exact characteristics of at least one sRGB-compliant machine--the sRGB reference monitor sitting in the sRGB reference viewing conditions. Regardless of what real CRTs are like, the sRGB spec defines the reference monitor to have a transfer function that is closely approximated by a power function with exponent 2.2. Therefore, given an sRGB image and sRGB reference viewing conditions, the samples should be related to the monitor light output by an exponent of 2.2. The sRGB spec is unambiguous on this point. We have declared that the gamma value consistent with sRGB is 1/2.2. It follows that if gamma is 1.0 and we have sRGB reference viewing conditions, then the image samples are proportional to the monitor light output. We need one stake in the ground, and we can infer all gamma handling from that. In PNG 1.0, the stake was "a gamma of 1.0 means the samples are proportional to camera input". We discovered that that was a design flaw. In the 1.1 proposal, the stake is either "a gamma of 1.0 means the samples are proportional to monitor output, assuming sRGB viewing conditions", or it's "a gamma of 1/2.2 [and a cHRM of...] means the samples are in the sRGB color space". But those two stakes are equivalent--either can be inferred from the other. > We don't need to decide what CRT gamma is in order to write the PNG > spec. All we need to say is that as the gAMA value in the file > changes, the decoder compensates for this change in a well-defined way > that results in getting *the same* result on screen. That's not quite enough. We need to make sure that two applications written by two authors for the same platform will produce the same displayed image given the same PNG file. If we can't tell the authors the truth about their display system, we at least need to tell them both the same fantasy; we can't leave it up to them to make up their own separate fantasies. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 21:06:29 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA24562 for ; Mon, 17 Aug 1998 21:06:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA19704 for png-list-outgoing; Mon, 17 Aug 1998 20:57:19 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA19699 for ; Mon, 17 Aug 1998 20:57:15 -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 VAA03334 for ; Mon, 17 Aug 1998 21:55:14 -0400 (EDT) To: png-list@dworkin.wustl.edu Subject: VOTE on iCCP 19980729 Date: Mon, 17 Aug 1998 21:55:14 -0400 Message-ID: <3331.903405314@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/iccp_proposal_19980729.txt Tom Lane One minor editing recommendation. The second sentence "The color space must be an RGB color space for color images (color types 2, 3, and 6), or a monochrome greyscale color space for greyscale images (color types 0 and 4)" uses two different but confusingly similar terms, one referring to an ICC notion and one referring to a PNG notion. I suggest it would be clearer to label each, say The color space of the ICC profile must be an RGB color space for color ------------------ images (PNG color types 2, 3, and 6), or a monochrome greyscale color --- space for greyscale images (PNG color types 0 and 4). --- where I simply inserted the underlined words. Also the infelicitous description of the restrictions on profile names should be mended as previously discussed. I don't think either of these wording changes merits a vote restart. regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 21:12:24 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA24599 for ; Mon, 17 Aug 1998 21:12:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA19738 for png-list-outgoing; Mon, 17 Aug 1998 21:03:03 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA19733 for ; Mon, 17 Aug 1998 21:03:00 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id TAA27222; Mon, 17 Aug 1998 19:00:59 -0700 (PDT) Date: Mon, 17 Aug 1998 19:00:59 -0700 (PDT) Message-Id: <199808180200.TAA27222@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: VOTE on iCCP 19980729 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom Lane says: > The color space of the ICC profile must be an RGB color space for color > ------------------ > images (PNG color types 2, 3, and 6), or a monochrome greyscale color > --- > space for greyscale images (PNG color types 0 and 4). Sounds good to me. I'll put it in the next draft. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Mon Aug 17 22:07:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA24956 for ; Mon, 17 Aug 1998 22:07:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA20319 for png-list-outgoing; Mon, 17 Aug 1998 21:57:43 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA20314 for ; Mon, 17 Aug 1998 21:57:38 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA29032; Mon, 17 Aug 1998 22:55:36 -0400 Message-Id: <1.5.4.32.19980818025129.00f68f94@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, 17 Aug 1998 22:51:29 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: VOTE on iCCP 19980729 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 07:00 PM 8/17/98 -0700, Adam wrote: >Tom Lane says: > >Sounds good to me. I'll put it in the next draft. Agreed. And the runon set of adjectives has been replaced with something much better -- see Adam's PNG-1.1 (draft 1.2.2) proposal. And yes, it's just editorial; what we are really voting on is the chunk itself and not editorial details. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 01:24:52 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id BAA25823 for ; Tue, 18 Aug 1998 01:24:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA22332 for png-list-outgoing; Tue, 18 Aug 1998 01:24:52 -0500 Received: from ns-1.macromedia.com (ns-1.macromedia.com [207.88.220.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA22327 for ; Tue, 18 Aug 1998 01:24:49 -0500 Received: from ns-2.macromedia.com (ns-2.macromedia.com [207.88.156.10]) by ns-1.macromedia.com (8.8.8/8.8.8) with ESMTP id XAA25892 for ; Mon, 17 Aug 1998 23:22:43 -0700 (PDT) Received: from dmendels-pclap (sfas-p35.macromedia.com [192.168.210.135]) by ns-2.macromedia.com (8.8.5/8.8.8) with SMTP id XAA23188; Mon, 17 Aug 1998 23:22:40 -0700 (PDT) Message-Id: <3.0.5.32.19980818022201.009827e0@sfpo.macromedia.com> X-Sender: dmendels@sfpo.macromedia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Aug 1998 02:22:01 -0400 To: PNG List , png-list@dworkin.wustl.edu From: David Mendels Subject: Re: Tiff to png Cc: challenge@macromedia.com In-Reply-To: <35D8A9EA.43D7BDA3@w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris, Our team would love to take a look at this. Can you send the original and the Fireworks compressed png with these comments to mailto://challenge@macromedia.com? Appreciate the feedback, Regards, David Mendels Vice President and General Manager, Web Publishing Macromedia At 12:08 AM 8/18/98 +0200, Chris Lilley wrote: >I recently was asked for help, someone wanted a converter for bilevel >TIFF to PNG. Simple enouh. For NT, and either free or low cost >shareware; still fairly simple, I thought. > >There is source code for a tifftopng converter at [1] but I don't have a >compiler at home. I would tend to use the netpbm utilities on unix for >this: > >tifftopnm file.tiff | pnmtopng > file.png > >but the request was for NT and again, I don't have an NT compiler handy. > >At home under NT I generally use Ulead smart saver as both a Photoshop 5 >plug-in and as a stand-alone program. It turns out that Ulead smart >saver can only go down to 2bits/pixel indexed images, not 1bit. Same for >Photoshop 4 and 5 which, mysteriously, refuse you the option of saving >as PNG when the image is bilevel. > >I rarely if ever use bilevel images so I never noticed the lack before. >There are various compiled, free/share/pay image conversion programs at >[2]. So I sifted through them. > >I tried one such converter, AlterImage32 ($35 shareware). It read a >bilivel TIFF and output a PNG. The good news: it is smaller than the >TIFF ( 107k instead of 389k). The bad news is that it is a 24bit PNG so >it could actually be a bit smaller yet ;-) > >Ulead smart saver (which can only go down to 2bit samples for indexed >and greyscale) took that down to 35k (34,980 bytes) as a 2bit indexed >PNG - 2bit samples but with two palette entries. Still not great. > >Macromedia Fireworks (certainly not free) saved it out as an 8bit >indexed image, complete with spurious sBIT chunk saying there were 8 >bits of precision - which is entirely the wrong thing to do! It also >saved out some unnecessary keywords, pHYs, etc and only used default >compression. 49k, still smaller than the GIF at 89k that firemworks >saved out but not optimal. > >Netpbm with the command given earlier gave a 35k (36,561 bytes) image at >1bit/pixel greyscale. Which is bigger than the 2bit indexed image. > >PNGcrush -brute on the image from netpbm got it down to 34,105 bytes. >But I was still surprised how little different that was from the two bit >indexed image. Should I be? Is the refusal of USS to go below 2bits (4 >colors) a simple oversight or a canny realisation about the >characteristics of PNG compression? > >Comments welcome, either of the form "my program will make smaller files >than that" or "of course, the compression scheme can never get smaller >than that because ..." > >If anyone wants to have a crack at it, the 1bit/pixel greyscale png is >at [3] for the time being; nothing great artistically you understand, >just some greyscale doodles and a couple of graduated fills converted to >bilevel by screening; if you want to compare your results to mine you >will need the same file, though. > > >[1] http://www.cdrom.com/pub/png/pngcode.html >[2] http://www.cdrom.com/pub/png/pngapcv.html >[3] http://www.w3.org/people/chris/png/bitest-pbm.png > >-- >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@w3.org 2004 Rt des Lucioles / BP 93 >+33 (0)492 387 987 06902 Sophia Antipolis Cedex, France > >-- >Send the message body "help" to png-list-request@dworkin.wustl.edu > > -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 01:27:03 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id BAA25833 for ; Tue, 18 Aug 1998 01:27:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA22357 for png-list-outgoing; Tue, 18 Aug 1998 01:27:33 -0500 Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA22352 for ; Tue, 18 Aug 1998 01:27:30 -0500 Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id BAA22166; Tue, 18 Aug 1998 01:25:28 -0500 (CDT) Received: from sji-ca3-109.ix.netcom.com(209.109.233.109) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma022162; Tue Aug 18 01:25:01 1998 Message-Id: <3.0.5.32.19980817232211.00952e60@popd.ix.netcom.com> X-Sender: jcbowler@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 17 Aug 1998 23:22:11 -0700 To: PNG List , PNG List From: John Bowler Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 In-Reply-To: <35D8433C.8CD3911C@alumni.rpi.edu> References: <3.0.5.32.19980817071720.0094ecc0@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:50 17/08/98 -0400, Glenn Randers-Pehrson wrote: >John Bowler wrote: > >> [Glenn wrote] >> >And I think we do need to say what gamma = 1 really means. >> >Technically and precisely, I agree that it means nothing. >> >> I think it can have a very precise meaning. sRGB defines, precisely, the >> light emitted by a monitor and the viewing conditions. Thus a gAMA of >> 100000 (on an image with no cHRM or iCCP) allows a simple linear equation >> to be written to determine the absolute light output on an sRGB system for >> each pixel value. > >That's saying that gamma=1.0 is the sRGB linear colorspace sRGB (as >opposed to sRGB nonlinear colorspace sR'G'B' which is the one we call >the >"sRGB" standard colorspace). But in the absence of an sRGB or cHRM >chunk, >is that necessarily true? That wasn't exactly what I meant. I meant that should the program choose to display the image on an sRGB system (including viewing conditions) then the correct light to be output by the monitor (*excluding* flare - i.e. just the phosphor output) can be derived from the sRGB encoding equations and the assumption that these correspond to gAMA 0.45455. This is an approximately linear equation: VsRGB = ((V'sRGB + 0.055)/1.055)^(2.4/2.2) Where a value of VsRGB=1.0 corresponds to a display output of 80cd/m^2 The image contains no cHRM chunk so the application cannot make adaptations for the differences between sRGB and the intended monitor phosphors (it doesn't know the latter!) If the cHRM chunk is given then it additionally defines the CIE XYZ end points of the *intended* monitor phosphors - the light levels are still as defined above in the reference (sRGB/ISO) viewing environment *with the correct phosphors*. If those phosphors are not available then additional corrections will need to be made (but they will probably be small.) John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 01:31:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id BAA25864 for ; Tue, 18 Aug 1998 01:31:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA22390 for png-list-outgoing; Tue, 18 Aug 1998 01:32:17 -0500 Received: from pedigree.cs.ubc.ca (pedigree.cs.ubc.ca [142.103.6.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA22385 for ; Tue, 18 Aug 1998 01:32:09 -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 XAA10552 for ; Mon, 17 Aug 1998 23:30:06 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199808180130.SAA26940@u33.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Aug 1998 23:30:19 -0700 To: PNG List From: Dave Martindale Subject: Re: gAMA in PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >Therefore, given an sRGB image and sRGB reference viewing conditions, >the samples should be related to the monitor light output by an exponent >of 2.2. The sRGB spec is unambiguous on this point. > >We have declared that the gamma value consistent with sRGB is 1/2.2. >It follows that if gamma is 1.0 and we have sRGB reference viewing >conditions, then the image samples are proportional to the monitor light >output. > >We need one stake in the ground, and we can infer all gamma handling >from that. In PNG 1.0, the stake was "a gamma of 1.0 means the samples >are proportional to camera input". We discovered that that was a design >flaw. > >In the 1.1 proposal, the stake is either "a gamma of 1.0 means the >samples are proportional to monitor output, assuming sRGB viewing >conditions", or it's "a gamma of 1/2.2 [and a cHRM of...] means the >samples are in the sRGB color space". But those two stakes are >equivalent--either can be inferred from the other. I agree with all that. As long as we qualify our statements with something like "assuming sRGB viewing conditions" or "when displayed on the sRGB reference monitor", we can justifiably make the statements about gAMA==1 meaning that pixel values are linearly proportional to light. I just want us to be careful not to make that sort of statement about monitors in general, since it may not be true. >That's not quite enough. We need to make sure that two applications >written by two authors for the same platform will produce the same >displayed image given the same PNG file. If we can't tell the authors >the truth about their display system, we at least need to tell them both >the same fantasy; we can't leave it up to them to make up their own >separate fantasies. Right. Perhaps we should add, at the end of a section somewhere, something like this: "Not all display devices provide sRGB viewing conditions. If you have or can measure detailed information about the transfer characteristic of the display device and its viewing environment, you may wish to provide compensation specific to your device. Colour management systems may provide tools to do this. But if you lack precise information, it's generally best to assume that any CRT is an sRGB device. This assumption is unlikely to be badly wrong, and if everyone picks the same default then there will be better consistency of image appearance across different applications running on the same display". Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 03:04:40 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id DAA26359 for ; Tue, 18 Aug 1998 03:04:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA22811 for png-list-outgoing; Tue, 18 Aug 1998 02:54:33 -0500 Received: from pedigree.cs.ubc.ca (imap.cs.ubc.ca [142.103.6.53]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA22805 for ; Tue, 18 Aug 1998 02:54:30 -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 AAA12737 for ; Tue, 18 Aug 1998 00:52:27 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <3331.903405314@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Aug 1998 23:35:58 -0700 To: PNG List From: Dave Martindale Subject: VOTE on iCCP 19980729 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP 19980729 ftp://swrinde.nde.swri.edu/pub/png-group/documents/iccp_proposal_19980729.txt Dave Martindale with Tom's suggested text editing. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 08:49:32 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA27699 for ; Tue, 18 Aug 1998 08:49:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA25013 for png-list-outgoing; Tue, 18 Aug 1998 08:48:20 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA25008 for ; Tue, 18 Aug 1998 08:48:12 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA12487; Tue, 18 Aug 1998 09:46:07 -0400 Message-Id: <1.5.4.32.19980818134200.009792f8@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, 18 Aug 1998 09:42:00 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: Tiff to png Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >Macromedia Fireworks ... >saved out some unnecessary keywords, pHYs, etc Did the original TIFF contain XResolution and YResolution tags? If so, you can't blame Fireworks for converting them. Do the pHYs values represent aspect ratio = 1 and some common dpi value? Or do they represent the actual slightly non-square pixels that is typical of monitors? Didn't the ULead-converted file also have a pHYs chunk? My copy of PhotoImpact 3.02 always inserts one, with aspect ratio = 1 (there's no option for specifying X-resolution and Y-resolution separately). I don't know what more recent ULead software does. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 13:02:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id NAA29853 for ; Tue, 18 Aug 1998 13:02:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA27387 for png-list-outgoing; Tue, 18 Aug 1998 12:55:53 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA27382 for ; Tue, 18 Aug 1998 12:55:50 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id MAA25779 for ; Tue, 18 Aug 1998 12:41:39 -0500 (CDT) Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA22568; Tue, 18 Aug 1998 13:41:30 -0400 Message-Id: <1.5.4.32.19980818173723.00980180@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, 18 Aug 1998 13:37:23 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: integer range in PNG chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In PNG 1.0 we forgot to state the range of the integer values that can appear in pHYs and oFFs chunks. I think it's clear that our intent would have been to limit them to 0..2^31-1 in the case of signed integers and -2^31-1..2^31-1 in the case of signed integers. Should we go ahead and say that in PNG 1.1, even though technically it could be considered not to be backward compatible? I don't imagine that it would affect any existing files. It could be handled by stating it explicitly in each chunk specification, or generically in section 2.1 by adding a sentence, "Unless otherwise stated, four-byte unsigned integers are limited to the range 0 to 2^31-1 and four-byte signed integers are limited to the range -2^31-1 to +2^31-1." Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 14:02:19 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id OAA00344 for ; Tue, 18 Aug 1998 14:02:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA28712 for png-list-outgoing; Tue, 18 Aug 1998 14:00:38 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA28702 for ; Tue, 18 Aug 1998 14:00:31 -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 OAA05671 for ; Tue, 18 Aug 1998 14:58:24 -0400 (EDT) To: PNG List Subject: Re: integer range in PNG chunks In-reply-to: Your message of Tue, 18 Aug 1998 13:37:23 -0400 <1.5.4.32.19980818173723.00980180@netgsi.com> Date: Tue, 18 Aug 1998 14:58:23 -0400 Message-ID: <5669.903466703@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson writes: > It could be handled by stating it > explicitly in each chunk specification, or generically > in section 2.1 by adding a sentence, "Unless otherwise > stated, four-byte unsigned integers are limited to the > range 0 to 2^31-1 and four-byte signed integers are limited > to the range -2^31-1 to +2^31-1." I like the generic approach better. No reason to have to repeat it in every chunk. (On the other hand, I don't want to take it out of the description of IHDR...) regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 16:05:57 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA01302 for ; Tue, 18 Aug 1998 16:05:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA01828 for png-list-outgoing; Tue, 18 Aug 1998 16:04:45 -0500 Received: from buffy.graphicswiz.com (buffy.graphicswiz.com [207.239.128.194]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA01823 for ; Tue, 18 Aug 1998 16:04:40 -0500 Date: Tue, 18 Aug 1998 16:04:40 -0500 Message-Id: <199808182104.QAA01823@dworkin.wustl.edu> Received: (qmail 12996 invoked from network); 18 Aug 1998 21:01:22 -0000 Received: from sally.internal.graphicswiz.com (10.10.10.3) by buffy.graphicswiz.com with SMTP; 18 Aug 1998 21:01:22 -0000 Received: (qmail 2132 invoked from network); 18 Aug 1998 21:04:20 -0000 Received: from cpic.internal.graphicswiz.com (HELO cpic) (10.10.10.10) by sally.internal.graphicswiz.com with SMTP; 18 Aug 1998 21:04:20 -0000 X-Sender: pschmidt@mail X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: pschmidt@photodex.com (Paul Schmidt) Subject: Re: integer range in PNG chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >Glenn Randers-Pehrson writes: >> It could be handled by stating it >> explicitly in each chunk specification, or generically >> in section 2.1 by adding a sentence, "Unless otherwise >> stated, four-byte unsigned integers are limited to the >> range 0 to 2^31-1 and four-byte signed integers are limited >> to the range -2^31-1 to +2^31-1." Glenn, Are you sure you don't mean 2^32-1 for unsigned four byte integers? Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1106 Clayton Lane #200W AOL: Photodex Photodex Austin, TX 78723 CIS: Photodex 74774,3635 (512)406-3020 Voice (512)452-6825 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 16:48:39 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA01610 for ; Tue, 18 Aug 1998 16:48:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA02288 for png-list-outgoing; Tue, 18 Aug 1998 16:48:07 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA02280 for ; Tue, 18 Aug 1998 16:48:03 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id RAA01028; Tue, 18 Aug 1998 17:45:54 -0400 Message-Id: <1.5.4.32.19980818214145.0097c600@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, 18 Aug 1998 17:41:45 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: integer range in PNG chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 04:04 PM 8/18/98 -0500, you wrote: >>Glenn Randers-Pehrson writes: >>> It could be handled by stating it >>> explicitly in each chunk specification, or generically >>> in section 2.1 by adding a sentence, "Unless otherwise >>> stated, four-byte unsigned integers are limited to the >>> range 0 to 2^31-1 and four-byte signed integers are limited >>> to the range -2^31-1 to +2^31-1." > >Glenn, > >Are you sure you don't mean 2^32-1 for unsigned four byte integers? Yes. That's the whole point; as in the width and height values, we limit the range to one bit less than the full range, to avoid certain problems with some OS that might insist interpreting the top bit as a sign bit. What OS? I dunno.. CP/M, maybe? I meant what it says in the sentence I'm suggesting. (I did make a typo, leaving off an "un" in a part of the message that you and tom didn't quote...) Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 16:54:23 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA01649 for ; Tue, 18 Aug 1998 16:54:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA02339 for png-list-outgoing; Tue, 18 Aug 1998 16:50:32 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA02328 for ; Tue, 18 Aug 1998 16:50:27 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id OAA01083; Tue, 18 Aug 1998 14:48:17 -0700 (PDT) Date: Tue, 18 Aug 1998 14:48:17 -0700 (PDT) Message-Id: <199808182148.OAA01083@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: integer range in PNG chunks From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List pschmidt@photodex.com (Paul Schmidt) says: > Are you sure you don't mean 2^32-1 for unsigned four byte integers? If the limit were 2^32-1, it would go without saying, because you can't represent anything larger in four bytes. The limit is 2^31-1 "to accommodate languages that have difficulty with unsigned 4-byte values." (I'm quoting from the PNG spec.) One example would be Java, which does not support unsigned integers. I will add the proposed sentence to section 2.1 in the next draft of the proposal, with the numbers formatted consistently with the rest of the spec: Unless otherwise stated, four-byte unsigned integers are limited to the range 0 to (2^31)-1, and four-byte signed integers are limited to the range -(2^31)+1 to (2^31)-1. Note that the restriction on signed integers omits only one representable value, -(2^31), but it's a troublesome one--it's a negative number whose opposite is negative. And ANSI C does not guarantee that a long int can represent it. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 17:58:17 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA01960 for ; Tue, 18 Aug 1998 17:58:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA03539 for png-list-outgoing; Tue, 18 Aug 1998 17:59:10 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA03527 for ; Tue, 18 Aug 1998 17:59:05 -0500 Received: (qmail 32346 invoked from network); 18 Aug 1998 22:57:40 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 18 Aug 1998 22:57:40 -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 PAA11468 for ; Tue, 18 Aug 1998 15:57:00 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id PAA23772 for png-list@dworkin.wustl.edu; Tue, 18 Aug 1998 15:02:14 -0700 Date: Tue, 18 Aug 1998 15:02:14 -0700 Message-Id: <199808182202.PAA23772@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: iCCP vote: PASSES Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Gentlebeings, The nominal voting period on the iCCP chunk ended about 8 hours ago, with unanimous passage: 12 YES votes (10 of which certainly meet the 6-month criterion), zero NO votes, zero ABSTAIN votes. The votes are listed below: YES Greg Roelofs YES Christian Brunschen YES John Bowler YES Chris Lilley YES Adam M. Costello YES Dave Beckett YES Gerard Juyn YES Brad Pettit YES Glenn Randers-Pehrson YES Michael Stokes YES Tom Lane YES Dave Martindale Regardless of a few deviations from the procedural restrictions in the unofficial proposed-chunks document (slightly misspelled filename, one or two unformated votes), I think it's quite clear that we have a con- sensus of knowledgable PNG experts. Therefore we can go ahead and include iCCP in version 1.1 of the core PNG spec, subject to a few editorial changes suggested by Tom and one or two others, I think. Btw, I apologize for the delay; I got nailed by the most stupendous, death-dealing headache known to mankind and have been stuck in bed all day. Sigh. Thank goodness for drugs. :-) Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 19:16:37 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA02267 for ; Tue, 18 Aug 1998 19:16:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA04364 for png-list-outgoing; Tue, 18 Aug 1998 19:17:41 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA04359 for ; Tue, 18 Aug 1998 19:17:37 -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 UAA07411 for ; Tue, 18 Aug 1998 20:15:31 -0400 (EDT) To: PNG List Subject: Re: integer range in PNG chunks In-reply-to: Your message of Tue, 18 Aug 1998 14:48:17 -0700 (PDT) <199808182148.OAA01083@u33.CS.Berkeley.EDU> Date: Tue, 18 Aug 1998 20:15:30 -0400 Message-ID: <7409.903485730@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List amc@cs.berkeley.edu (Adam M. Costello) writes: > Unless otherwise stated, four-byte unsigned integers are limited > to the range 0 to (2^31)-1, and four-byte signed integers are > limited to the range -(2^31)+1 to (2^31)-1. The nitpick desk wishes to suggest that that last would be more easily read as limited to the range -((2^31)-1) to (2^31)-1. or some such. That way it's clearer what's going on. I had to read the other wording twice before I believed it... regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 21:39:44 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA04066 for ; Tue, 18 Aug 1998 21:39:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA06238 for png-list-outgoing; Tue, 18 Aug 1998 21:39:55 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA06233 for ; Tue, 18 Aug 1998 21:39:50 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA14640; Tue, 18 Aug 1998 22:37:38 -0400 Message-Id: <1.5.4.32.19980819023334.00f6f9d4@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, 18 Aug 1998 22:33:34 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: integer range in PNG chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 08:15 PM 8/18/98 -0400, you wrote: >The nitpick desk wishes to suggest that that last would be more easily >read as > limited to the range -((2^31)-1) to (2^31)-1. >or some such. That way it's clearer what's going on. Agreed. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 22:32:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA04314 for ; Tue, 18 Aug 1998 22:32:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA06462 for png-list-outgoing; Tue, 18 Aug 1998 22:32:27 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA06457 for ; Tue, 18 Aug 1998 22:32:22 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id XAA16721; Tue, 18 Aug 1998 23:30:14 -0400 Message-Id: <1.5.4.32.19980819032606.00f6b9b4@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, 18 Aug 1998 23:26:06 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: gIFT chunk and transparency Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List While working on updating the PNG extensions spec, and looking at other documents, I'm wondering about what happens when either the foreground or the background color in a gIFT happens to be the transparent color? Is it supposed to replace the cell background or the text, respectively, with the image's transparent color, letting the browser (or whatever) background showing through, or is it supposed to let the image show through? The latter makes a lot more sense to me, but our extensions document and the GIF89a spec are both mute about it. For example, if the gIFT background color is transparent: If you just replace the cell background with the transparent color, then you'd have a rectangular hole in the image with the text displayed against whatever is behind the image (browser background, image bKGD, MNG background image, or whatnot). If you replace the cell background with the pixels of the image, you'll have the text appearing to be written on the image. I suggest that the gIFT spec in the extensions document specify a behavior, even though the GIF89a spec doesn't. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 22:48:48 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA04371 for ; Tue, 18 Aug 1998 22:48:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA06565 for png-list-outgoing; Tue, 18 Aug 1998 22:50:07 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA06560 for ; Tue, 18 Aug 1998 22:50:04 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id UAA01946; Tue, 18 Aug 1998 20:47:52 -0700 (PDT) Date: Tue, 18 Aug 1998 20:47:52 -0700 (PDT) Message-Id: <199808190347.UAA01946@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: gIFT chunk and transparency From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > I suggest that the gIFT spec in the extensions document specify a > behavior, even though the GIF89a spec doesn't. I don't think this is our problem, and I don't think it's our place to specify the solution. If the GIF spec is ambiguous on this point, the GIF conversion chunks inherit the same exact same semantics, including the ambiguity. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Tue Aug 18 23:41:23 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA04836 for ; Tue, 18 Aug 1998 23:41:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA06959 for png-list-outgoing; Tue, 18 Aug 1998 23:41:19 -0500 Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA06954 for ; Tue, 18 Aug 1998 23:41:15 -0500 Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id XAA28835 for ; Tue, 18 Aug 1998 23:39:06 -0500 (CDT) Received: from sji-ca10-25.ix.netcom.com(205.186.214.25) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma028803; Tue Aug 18 23:38:50 1998 Message-Id: <3.0.5.32.19980818213944.009488c0@popd.ix.netcom.com> X-Sender: jcbowler@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 18 Aug 1998 21:39:44 -0700 To: PNG List From: John Bowler Subject: Re: gIFT chunk and transparency In-Reply-To: <199808190347.UAA01946@u33.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 20:47 18/08/98 -0700, Adam M. Costello wrote: >Glenn Randers-Pehrson says: > >> I suggest that the gIFT spec in the extensions document specify a >> behavior, even though the GIF89a spec doesn't. > >I don't think this is our problem, and I don't think it's our place to >specify the solution. If the GIF spec is ambiguous on this point, the >GIF conversion chunks inherit the same exact same semantics, including >the ambiguity. I agree. In any case there are too many existing implementations (not necessarily based on a reading of GIF89a) to attempt to define a single behavior. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 01:38:42 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id BAA05220 for ; Wed, 19 Aug 1998 01:38:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA08024 for png-list-outgoing; Wed, 19 Aug 1998 01:38:44 -0500 Received: from buffy.graphicswiz.com (buffy.graphicswiz.com [207.239.128.194]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id BAA08019 for ; Wed, 19 Aug 1998 01:38:40 -0500 Date: Wed, 19 Aug 1998 01:38:40 -0500 Message-Id: <199808190638.BAA08019@dworkin.wustl.edu> Received: (qmail 15926 invoked from network); 19 Aug 1998 06:35:19 -0000 Received: from sally.internal.graphicswiz.com (10.10.10.3) by buffy.graphicswiz.com with SMTP; 19 Aug 1998 06:35:19 -0000 Received: (qmail 5470 invoked from network); 19 Aug 1998 06:38:18 -0000 Received: from katie.internal.graphicswiz.com (HELO katie) (10.10.10.250) by sally.internal.graphicswiz.com with SMTP; 19 Aug 1998 06:38:18 -0000 X-Sender: pschmidt@mail X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: pschmidt@photodex.com (Paul Schmidt) Subject: Re: integer range in PNG chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List ... >>>> range 0 to 2^31-1 ... >>Are you sure you don't mean 2^32-1 for unsigned four byte integers? > >Yes. That's the whole point; as in the width and height values, we >limit the range to one bit less than the full range, to avoid certain >problems with some OS that might insist interpreting the top bit as a sign >bit. What OS? I dunno.. CP/M, maybe? I meant what it says in the >sentence I'm suggesting. (I did make a typo, leaving off an "un" in a >part of the message that you and tom didn't quote...) Glenn, Wow. At the expense of trolling up stuff that's been gone over a million times... First, I understand why the spec is this way. But... (a) I don't think anyone's going to honor that limitation in their code, and (b) I think just the fact that this looks like a typo is going to generate more work in the form of answering when someone points it out than it will save in confusion because the number range is limited. I shudder to think of the researcher sitting in front of his monitor late at night and finally realizing after all of his research on which file format to use...finally figuring out that PNG won't be suitable for his purposes because he can't store "Legal PNG" images larger than 2 billion pixels wide, when he really needs to store one 3.5 billion pixels wide. I would guess that anyone doing this level of imaging will be using 64-bit processors (at least) and probably NSA-squelched supercomputers and has no interest in compression, PNG or portability. It sounds to me like fixing things that don't need fixing at the expense of causing more confusion than is saved. But, it's almost definitely not worth the bandwidth I've already spent on it. So, I hereby drop the issue. :-) Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1106 Clayton Lane #200W AOL: Photodex Photodex Austin, TX 78723 CIS: Photodex 74774,3635 (512)406-3020 Voice (512)452-6825 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 02:19:39 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id CAA05507 for ; Wed, 19 Aug 1998 02:19:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA08242 for png-list-outgoing; Wed, 19 Aug 1998 02:15:10 -0500 Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA08237 for ; Wed, 19 Aug 1998 02:15:07 -0500 Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id CAA17423 for ; Wed, 19 Aug 1998 02:12:59 -0500 (CDT) Received: from sji-ca10-25.ix.netcom.com(205.186.214.25) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma017405; Wed Aug 19 02:12:25 1998 Message-Id: <3.0.5.32.19980819001410.00953100@popd.ix.netcom.com> X-Sender: jcbowler@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 19 Aug 1998 00:14:10 -0700 To: PNG List From: John Bowler Subject: Re: integer range in PNG chunks In-Reply-To: <199808190638.BAA08019@dworkin.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 01:38 19/08/98 -0500, Paul Schmidt wrote: >>>Are you sure you don't mean 2^32-1 for unsigned four byte integers? >> >>Yes. That's the whole point; as in the width and height values, we >>limit the range to one bit less than the full range, to avoid certain >>problems with some OS that might insist interpreting the top bit as a sign >>bit. > >Wow. At the expense of trolling up stuff that's been gone over a million >times... > >First, I understand why the spec is this way. But... (a) I don't think >anyone's going to honor that limitation in their code, and (b) I think just >the fact that this looks like a typo is going to generate more work in the >form of answering when someone points it out than it will save in confusion >because the number range is limited. > >I shudder to think of the researcher sitting in front of his monitor late at >night and finally realizing after all of his research on which file format >to use...finally figuring out that PNG won't be suitable for his purposes >because he can't store "Legal PNG" images larger than 2 billion pixels wide, >when he really needs to store one 3.5 billion pixels wide. I would guess >that anyone doing this level of imaging will be using 64-bit processors (at >least) and probably NSA-squelched supercomputers and has no interest in >compression, PNG or portability. That last sentence (with which I agree) seems to defeat your own argument. Speaking for myself I find it very difficult to write correct C (or C++) code which mixes signed and unsigned arithmetic. That is partly a deficiency in the language and partly a deficiency in me (I seem to have an unreasonable tendency to assume that all numbers fit in [32 bit] (int).) On the other hand I have seen it in other code and we have spent a lot of time over the last few months fixing "signed/unsigned" warnings which one or other compiler emits. There is nothing magic about 4294967295 in the real world, 2147483647 is, almost 50% of the time, just as good an arbitrary limit :-) In practice many implementations will impose lower limits - this is perfectly valid so long as they recognize and reject PNG files which exceed their limits. For example I do not believe any libpng implementation running on a typical business or home machine will accept a PNG image with a row width of 2^32-1 (libpng allocates or expects several row-width size buffers.) >It sounds to me like fixing things that don't need fixing at the expense of >causing more confusion than is saved. But, it's almost definitely not worth >the bandwidth I've already spent on it. So, I hereby drop the issue. :-) Well, I disagree again. It's worth arguing about because it *is* a good design decision, because it attends to a very real engineering problem - the difficulty of dealing correctly with values at the limit of the precision. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 08:29:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA07106 for ; Wed, 19 Aug 1998 08:29:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA11102 for png-list-outgoing; Wed, 19 Aug 1998 08:23:38 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA11096 for ; Wed, 19 Aug 1998 08:23:34 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA31062; Wed, 19 Aug 1998 09:21:24 -0400 Message-Id: <1.5.4.32.19980819131716.00f68c5c@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, 19 Aug 1998 09:17:16 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFT chunk and transparency Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 09:39 PM 8/18/98 -0700, you wrote: >At 20:47 18/08/98 -0700, Adam M. Costello wrote: >>Glenn Randers-Pehrson says: >> >>> I suggest that the gIFT spec in the extensions document specify a >>> behavior, even though the GIF89a spec doesn't. >> >>I don't think this is our problem, and I don't think it's our place to >>specify the solution. If the GIF spec is ambiguous on this point, the >>GIF conversion chunks inherit the same exact same semantics, including >>the ambiguity. > >I agree. In any case there are too many existing implementations (not >necessarily based on a reading of GIF89a) to attempt to define a single >behavior. There's a problem with my idea, anyway. The transparency information that existed in the GIF about the text colors can be lost unless each of the foreground and background RGB triples is either always transparent or always opaque in the image, which isn't necessarily true, even in converted GIFs. Troublesome. We could have designed a gIFt chunk that preserved the transparency information by using RGBA quads instead of RGB triples. Therefore the simplest, and sometimes the only possible implementation of gIFt is simply to regard the given RGB samples as opaque, regardless of their transparency status in the original GIF. If authors want anything more complicated they can generate the pixels themselves and write a regular PNG file, not messing with gIFt at all. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 09:00:09 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id JAA07424 for ; Wed, 19 Aug 1998 09:00:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA11383 for png-list-outgoing; Wed, 19 Aug 1998 09:00:20 -0500 Received: from kobra.efd.lth.se (kobra.efd.lth.se [130.235.34.36]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA11360; Wed, 19 Aug 1998 08:59:51 -0500 Received: from efd.lth.se (d89cb@batch-1.efd.lth.se [130.235.34.53]) by kobra.efd.lth.se (8.8.8/8.8.8) with ESMTP id PAA11785; Wed, 19 Aug 1998 15:57:42 +0200 (MET DST) Message-Id: <199808191357.PAA11785@kobra.efd.lth.se> X-Mailer: exmh version 1.6.7 5/3/96 To: PNG List , PNGAnnouncement List Subject: Re: "oh no, not again!" In-reply-to: Your message of "Tue, 18 Aug 1998 23:43:24 EDT." <35DA49DB.C3A1376@worldnet.att.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 19 Aug 1998 15:57:41 +0200 From: Christian Brunschen Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by swrinde.nde.swri.edu id JAA07424 Regarding the email message <35DA49DB.C3A1376@worldnet.att.net> that was sent to png-announce, I have drafted the following reply; could someone please take a look at it and phrase it more gently and correctly ? :-) In message <35DA49DB.C3A1376@worldnet.att.net>, "Richard W. Franzen" writes: > Humans, > > The pages referenced below refer to a new graphics format which I > think could be a useful addition to our set of imaging tools. At the > current time I am not proposing that it be made part of the png > specification, although I do admit to a bit of hubris in calling the > format "png-16". The extension for the images would be ".pn6"; png-16 > images would be a superset of png images. > > If the format turns out to be useful over time, then I would hope > that it could be merged into the png specification, however. > > http://home.att.net/~rocq/pngBase.html > http://home.att.net/~rocq/colSpace.html > http://home.att.net/~rocq/png16.html > http://home.att.net/~rocq/png16Tech.html (it exists, but it doesn't > think) > > > Feel free to criticize, critique, make suggestions, or send money. Having read the pages in question, I shall now do so. I see no merit in your proposal. Should it be found useful to include a Hue-Saturation-Lightness color space in PNG, I feel confident that it would be as a 24-bit-per-pixel format - 8 bits for each of hue, saturation, and lightness (intensity or whatever). You make repeated claims of a 1-third space advantage of 16-bit pixels over 24-bit pixels. This is a misrepresentation, of course; You can not accurately represent all possible 24-bit-per-pixel color values in your 16-bit-per-pixel-HSI proposal, so you are in fact losing image accuracy. Furthermore, the image data in PNG are losslessly compressed; thus, your claimed 33% advantage in size per pixel with raw data, may well disappear completely once the pixels are compressed. Also, saying that one unit of 16 bits is more natural to store one pixel than 3 units of 8 bits - well, with 24-bit-per-pixel pixels, you just grab each byte and get the red, green, and blue values; with your proposal, you will have to do shifts or rotations, plus AND (and possible OR) operations to extract the Hue, Saturation and Intensity values - which is even less effective, usually. Another thing: If someone is willing to sacrifice visual accuracy to store an (originally 24-bit-per-pixel) image, then I would suggest that JPG is a more reasonable choice. As for your proposal offering 12 bit-per-pixel greyscale in conjunction with color - that is true if and only if you treat 'Saturation = 0' as a special case, thus breaking the orthogonality of the format - ie, it won't be a simple 'Hue, Saturation, Intensity' format any more. As for your suggestion for transparency - you have misunderstood what Alpha is all about. It is not an 'overlay'; it is another channel (much like red, green, or blue) which tells how the current pixel and its background are to be blended. Your comments regarding 48-bit-per-pixel as being 'precision far in excess of accuracy', you are also wrong. This accuracy is in fact sometimes _necessary_. Medical applications, for instance, often need 16-bit greyscale for a _good_ representation of an X-ray image. Also, 'precision' and 'accuracy' are in fact two terms that describe different phenomena when you are measuring something. Likewise, 32-bit-per-pixel CMYK can _not_ be represented equally well as 16-bit-per-pixel CMYK. Ask someone in the printing industry, perhaps. Also, you write a long paragraph about gamma correction - concluding that while great in theory, it has practical problems. Well, those practical problems are indeed just that - practical problems which need to be overcome. And which _have_ been overcome on some platforms - Apple Macintosh, for instance, offer color synchronization in the whole system. Of course, you write about gamma correction in the section about how many bits one might use per pixel - which is in itself rather confusing, since one would not store gamma information with each pixel, but rather include 'gamma' information with the whole image - as it is done in PNG. Basically, it seems like you have either not read or not understood most parts of the PNG specification. > > > -- Rich > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rich Franzen richf@dba-sys.com (work) > Staff Scientist 407/727-0660 x2294 (voice) > DBA Systems, Inc. 407/727-7019 (fax) > 1200 S. Woody Burke Rd. http://www.dba-sys.com > Melbourne, FL 32901 rocq@worldnet.att.net (home) > http://home.att.net/~rocq > > -- > Send the message body "help" to png-announce-request@dworkin.wustl.edu -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 10:05:45 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA08144 for ; Wed, 19 Aug 1998 10:05:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA12010 for png-list-outgoing; Wed, 19 Aug 1998 09:55:45 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA12005 for ; Wed, 19 Aug 1998 09:55:42 -0500 Received: (qmail 19348 invoked from network); 19 Aug 1998 14:54:15 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 19 Aug 1998 14:54:15 -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 HAA26900 for ; Wed, 19 Aug 1998 07:53:33 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA23757 for png-list@dworkin.wustl.edu; Wed, 19 Aug 1998 07:53:32 -0700 Date: Wed, 19 Aug 1998 07:53:32 -0700 Message-Id: <199808191453.HAA23757@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: gIFT chunk and transparency Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >>>> I suggest that the gIFT spec in the extensions document specify a >>>> behavior, even though the GIF89a spec doesn't. >>> I don't think this is our problem, and I don't think it's our place to >>> specify the solution. If the GIF spec is ambiguous on this point, the >>> GIF conversion chunks inherit the same exact same semantics, including >>> the ambiguity. I don't know where the idea that the GIF spec is ambiguous comes from; it clearly states: This block is a graphic rendering block, therefore it may be modified by a Graphic Control Extension. The GCE, of course, is where GIF's transparency info lives. There is no indication that, if present, the GCE may be considered optional; the only optional part about it is its presence in the first place. I found the problem a couple of months ago while writing the chapter on miscellaneous chunks, and I never brought it up because it seems clear to me that there's no way around it except to define a new gIFt chunk (with a different name, obviously--GIFT or GTXT would make the most sense). Since no one has complained about the current one, it didn't seem worth bothering with. Nevertheless: >>I agree. In any case there are too many existing implementations (not >>necessarily based on a reading of GIF89a) to attempt to define a single >>behavior. This is largely irrelevant--PNG chunks are part of the *PNG* spec, so we could certainly define a single behavior (presumably according to the GIF 89a spec's intent) in our document. And it's arguably a useful chunk to have even for PNG--store text as a transparent overlay on a normal image, but with the compression hit of standard ASCII (or Latin-1) text, not of gobs of pixels. The problem, of course, is that the decoder has to have a raster representation of the text characters, and now you're talking about all sorts of non- portable options. So again, it didn't seem worth bringing up. > Troublesome. We could have designed a gIFt chunk that preserved > the transparency information by using RGBA quads instead of RGB triples. And should have, but Tim didn't catch it, and the rest of us didn't pore over the GIF spec sufficiently. Oh well. The font issue would still just about guarantee that no PNG decoder would ever honor gIFt, regardless of the presence or absence of transparency info. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 16:49:55 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA11227 for ; Wed, 19 Aug 1998 16:49:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA16929 for png-list-outgoing; Wed, 19 Aug 1998 16:42:40 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA16896; Wed, 19 Aug 1998 16:42:08 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id XAA24128; Wed, 19 Aug 1998 23:39:51 +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: <35DB4670.19C144FC@w3.org> Date: Wed, 19 Aug 1998 23:41:04 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List CC: PNGAnnouncement List Subject: Re: "oh no, not again!" References: <199808191357.PAA11785@kobra.efd.lth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Christian Brunschen wrote: > > Regarding the email message <35DA49DB.C3A1376@worldnet.att.net> that was sent > to png-announce, I have drafted the following reply; could someone please take > a look at it and phrase it more gently and correctly ? :-) Sorry I happen to be really tied up with something else right now, or I would certainly have a go. But let me jot down a few notes that occured to me reading throught the proposal, particularly the color space part of course, and maybe that will help someone else do a response. There are various different color spaces answering to the name HLS HSI, IHS,; they are all cylindrical spaces (x, y, radius) It seems that the one he is talking about is where black is at the bottom cap of the cylinder; greys run up the middle, white is at the center of the top cap, and the primary and secondary colors red, yellow, green, cyan, blue, mageta are spaced at equal 60 degree distances around the perimiter of the top cap. This means that the "lightness" component has nothing to do with percieved lightness - blue (RGB 0000FF) is given the same lightness value as yellow (RGB FFFF00) even though yellow is quite obviously much brighter. It means that the hue angle is not perceptually uniform - at some angles the hue is changing very fast, on others it changes more slowly for the same angular change - so bits are wasted because you need enough resolution in the areas where hue change is fast and those bits are wasted in areas where hue change is slower. Considering a 24bit RGB cube, balanced on its point such that black is at the bottom and white at the top, the hue angle runs around a zig-zag of six edges of the cube (between red to yellow, then to green, ands so on). There are 256 steps on each edge, giveng a maximum number of hue steps of 6*256= 1536. He proposes 60 unique hue angles, around 4% of what 24bit color supports. It means that many bits are wasted at the darker end of the color space, because the eye can increasingly resolve hue and saturation levels as brightness increases. So at the dark end, many colors with different bit patterns will be the same visual color, wasting bits (and there are precious few to begin with). This is taken care of in his proposal for pure black, which is the bottom end cap (1024 colors all the same, black) so he does some clever things with these when intensity is 0. But he allocates 6 bits for intensity (64 levels) so when intensity is 1, 2 etc all 1024 colors on that intensity slice are the same visually and so on (as you go up in intensity you can see more distinct colors, eventually at or near full intensity you can see all 1024 distinct colors in that slice). This is why the HSI color space is usually drawn as a cone with black at the point, to show there is only one visible black color and increasingly more as you get brighter. Geometrically as a coordinate system, and in terms of bit usage, it is a cone. Assuming the cone is a good representation of the visible colors, someone with better recollection of high school geometry can subtract the volume of a cone from the volume of the enclosing cylinder and work out what percentage of bit patterns are wasted. [1] There are lots of other clever tweaks for specific cases in his proposal, mainly getting only a single black color (instead of 1024) and more grey levels (instead of only 64). These fall down when the color is nearly but not quite black (wasted bits) and lack of colors when the saturation is nearly but not quite neutral (there are 4 bits of saturation radius ie 16 values from the center to the edge; in a slice passing through the center and parallel to the center line you get 4 bits to the left of center and 4 bits to the right of center (with the hue angle 180 degrees different on the right and on the left) so you effectively get twice as many colors, you would assume 5 bits, with ther colors for saturation=0 overlapping; but saturation=0 is treated specially so saturation actually goes 1 to 15 both sides. At low levels of saturation (near-neutral, pastel colors) where the eye is sensitive to shade variation, there are only 64 levels of lightness. Lastly, because of the various tweaks and tucks, this isn't really a truecolor space (you couldn't render to it by direct calculation; you have to render to 24 or actually 48 bits (to allow for the 12 bits of grey) and then quantize to the allowed colors. What this actually is is an *indexed* colorspace, but one in which the resulting indexed to truecolor conversion does not need to be stored in a separate palette because it can be described algorithmically. In other words, this is a single fixed palette. The perils of quantising to a fixed palette are already well known, as anyone who has quantised to 216 colors of the mythical "browser safe" palette and then 216 colors of an adaptive pallete can testify. There are 2^16 ie 65526 values, of which 256 are reserved for "vendor options' and 3,780 are reserved for a variable palette (this would be a large palette, and a sizeable proportion of the image unless the image was really large). That means it is a 61,500 entry fixed palette, with 16 bits used for each palette entry in the image data. In this fixed palette a large proportion (volume of cylinder divided by volume of cone) of the colors are wasted because they look the same. As we all know, indexed data rarely if ever benefits from PNG pre-filtering before compression. So we are actually comparing 16bit, non filtered, compressed indexed data with 24bit, filtered, compressed truecolor data. I'm sure many of you have observed a 24bit, filtered truecolor PNG oftentimes being only twice the size (or less) of an 8bit indexed PNG rather than three times the size. This leads me to believe that a 16bit, indexed image using thhis proposed colorspace would be about the same size as a 24bit, truecolor PNG image, using the same compression algorithms. [1] children, pay attention in high school now, and learn all that 'by heart' stuff, not like Uncle Chris. -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 16:54:22 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id QAA11261 for ; Wed, 19 Aug 1998 16:54:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA17102 for png-list-outgoing; Wed, 19 Aug 1998 16:49:21 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA17097 for ; Wed, 19 Aug 1998 16:49:18 -0500 Received: from mail.cyberverse.com (brionne.cyberverse.com [209.151.224.34]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id RAA09229 for ; Wed, 19 Aug 1998 17:47:07 -0400 (EDT) X-Authentication-Warning: www10.w3.org: Host brionne.cyberverse.com [209.151.224.34] claimed to be mail.cyberverse.com Received: from atorrez (atviA42.pool.activision.com [207.82.188.42]) by mail.cyberverse.com (8.8.7/mail) with SMTP id OAA23938 for ; Wed, 19 Aug 1998 14:47:06 -0700 Message-Id: <199808192147.OAA23938@mail.cyberverse.com> X-Sender: simple@mail.cyberverse.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 19 Aug 1998 14:41:16 -0700 To: png-group@w3.org From: Andre Torrez Subject: png spec? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I've been trying to find the latest articles on the png specification, but the homepage for png http://www.wco.com/~png/ does not appear to exist. is it acceptable to follow the specification found at http://www.w3.org/TR/PNG-Resources.html in order to implement PNG graphics in my application? -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 17:00:51 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA11339 for ; Wed, 19 Aug 1998 17:00:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA17185 for png-list-outgoing; Wed, 19 Aug 1998 17:00:56 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA17180 for ; Wed, 19 Aug 1998 17:00:47 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id OAA02773; Wed, 19 Aug 1998 14:58:31 -0700 (PDT) Date: Wed, 19 Aug 1998 14:58:31 -0700 (PDT) Message-Id: <199808192158.OAA02773@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: png spec? X-Advice: should read soon From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > http://www.wco.com/~png/ > > does not appear to exist. http://www.cdrom.com/pub/png/ > is it acceptable to follow the specification found at > http://www.w3.org/TR/PNG-Resources.html > > in order to implement PNG graphics in my application? Yes, version 1.0 is the latest version, and both sites have it. Sometime in the not-too-distant future, there will be a version 1.1, and it will probably appear at cdrom.com before it appears at w3.org. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 17:33:58 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id RAA11518 for ; Wed, 19 Aug 1998 17:33:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA17650 for png-list-outgoing; Wed, 19 Aug 1998 17:32:46 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA17644 for ; Wed, 19 Aug 1998 17:32:43 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id AAA25342; Thu, 20 Aug 1998 00:30:31 +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: <35DB5250.7A893873@w3.org> Date: Thu, 20 Aug 1998 00:31:44 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: png spec? References: <199808192147.OAA23938@mail.cyberverse.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Andre Torrez wrote: > > I've been trying to find the latest articles on the png specification, but > the homepage for png > http://www.wco.com/~png/ > > does not appear to exist It has moved to www.cdrom.com/pub/png > is it acceptable to follow the specification found at > http://www.w3.org/TR/PNG-Resources.html > > in order to implement PNG graphics in my application? Yes, that is a stable reference to the current version of the specification but you want to start at the beginning, not chapter 16. Start at http://www.w3.org/TR/REC-png-multi.html -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 19:46:00 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA11960 for ; Wed, 19 Aug 1998 19:46:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA18732 for png-list-outgoing; Wed, 19 Aug 1998 19:46:56 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA18727 for ; Wed, 19 Aug 1998 19:46:53 -0500 From: marketing@countyweb.co.uk Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id UAA10266; Wed, 19 Aug 1998 20:44:27 -0400 (EDT) Received: from mailserver1 by sophia.inria.fr (8.8.8/8.8.5) with SMTP id CAA28813; Thu, 20 Aug 1998 02:44:20 +0200 (MET DST) Message-Id: <199808200044.CAA28813@sophia.inria.fr> X-Authentication-Warning: sophia.inria.fr: Host [194.168.79.97] claimed to be mailserver1 To: Subject: COUNTYWeb UK Network Date: Thu, 20 Aug 1998 01:50:29 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Message from COUNTYWeb ...if you do not wish to continue to receive messages from us reply with 'REMOVE' in the subject line. Great Web Site !!! Visit the top UK business focussed web site Network........ **COUNTYWeb Homepage - http://www.countyweb.co.uk **Live Currencies - http://www.countyweb.co.uk/countyweb/business/currency/fscurrency.htm **National News,Business & Sport http://www.countyweb.co.uk/countyweb/newsfeed/index.htm **Property Locator http://www.countyweb.co.uk/countyweb/property/index.htm Thousands of contacts and information, Subscribe and be found yourself by taking a National, Regional or Local geographic presence. Thank you for reading this message Regards COUNTYWeb Marketing Team -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Wed Aug 19 19:58:56 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id TAA11994 for ; Wed, 19 Aug 1998 19:58:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA18770 for png-list-outgoing; Wed, 19 Aug 1998 19:59:08 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA18765 for ; Wed, 19 Aug 1998 19:59:05 -0500 Received: (qmail 10915 invoked from network); 20 Aug 1998 00:57:37 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 20 Aug 1998 00:57:37 -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 RAA23913 for ; Wed, 19 Aug 1998 17:56:54 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id RAA00440 for png-list@dworkin.wustl.edu; Wed, 19 Aug 1998 17:05:35 -0700 Date: Wed, 19 Aug 1998 17:05:35 -0700 Message-Id: <199808200005.RAA00440@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: "oh no, not again!" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List [Redirected to png-list...you guys are driving off interested folks who just want PNG announcements.] > This is why the HSI color space is usually drawn as a cone with black at > the point, to show there is only one visible black color and > increasingly more as you get brighter. Geometrically as a coordinate > system, and in terms of bit usage, it is a cone. Assuming the cone is a > good representation of the visible colors, someone with better > recollection of high school geometry can subtract the volume of a cone > from the volume of the enclosing cylinder and work out what percentage > of bit patterns are wasted. [1] 67% (vol = 1/3 pi r^2 h) > There are 2^16 ie 65526 values, of which 256 are reserved for "vendor 65536, since we're picking nits. :-) > As we all know, indexed data rarely if ever benefits from PNG > pre-filtering before compression. So we are actually comparing 16bit, > non filtered, compressed indexed data with 24bit, filtered, compressed > truecolor data. I'm not sure that follows, necessarily. This "fixed palette" should have more correlation in it than an arbitrary 8-bit palette, so I would expect that filtering might actually help. (For that matter, I'm still convinced that filtering can help in palette images for the right per- mutation of the palette; finding that permutation is the tricky part.) Of course, the lack of alignment between the 4/6/6-bit sample data and the 8-bit PNG filter algorithms might toss all that out the window. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 20 01:44:03 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id BAA13342 for ; Thu, 20 Aug 1998 01:44:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA20909 for png-list-outgoing; Thu, 20 Aug 1998 01:33:37 -0500 Received: from mtiwmhc02.worldnet.att.net (mtiwmhc02.worldnet.att.net [204.127.131.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA20904 for ; Thu, 20 Aug 1998 01:33:13 -0500 Received: from worldnet.att.net ([12.77.197.96]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980820063042.DEAR7243@worldnet.att.net>; Thu, 20 Aug 1998 06:30:42 +0000 Message-ID: <35DBC13F.7515A773@worldnet.att.net> Date: Thu, 20 Aug 1998 02:25:03 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: PNG List CC: Rich.Franzen@dba-sys.com Subject: Re: "oh no, not again!" References: <199808191357.PAA11785@kobra.efd.lth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Christian Brunschen wrote (Wed, 19 Aug 1998 15:57:41 +0200): > > Regarding the email message <35DA49DB.C3A1376@worldnet.att.net> that was sent > to png-announce, I have drafted the following reply; could someone please take > a look at it and phrase it more gently and correctly ? :-) Don't worry about being gentle, Christian. I knew when i posted this there would be skeptics... > > In message <35DA49DB.C3A1376@worldnet.att.net>, "Richard W. Franzen" writes: > > Humans, > > > > ... > > > > Feel free to criticize, critique, make suggestions, or send money. > > Having read the pages in question, I shall now do so. > > I see no merit in your proposal. It is not currently a proposal. It is simply an announcement of a png-related project I am working on; if you are interested and wish to provide suggestions, great. If you think that I am simply naive, ignorant, and/or noise, by all means feel free to ignore me. > > Should it be found useful to include a Hue-Saturation-Lightness color space in > PNG, I feel confident that it would be as a 24-bit-per-pixel format - 8 bits > for each of hue, saturation, and lightness (intensity or whatever). > > You make repeated claims of a 1-third space advantage of 16-bit pixels over > 24-bit pixels. This is a misrepresentation, of course; You can not accurately > represent all possible 24-bit-per-pixel color values in your > 16-bit-per-pixel-HSI proposal, so you are in fact losing image accuracy. > > Furthermore, the image data in PNG are losslessly compressed; thus, your > claimed 33% advantage in size per pixel with raw data, may well disappear > completely once the pixels are compressed. No lo contendre. Maybe I've been around marketing people too long. What I can say accurately is that 16-bit compressed files should be smaller than 24-bit compressed files. And yes, in some sense fc16 is a "lossy" format, assuming the original image format contained 24 accurate bits per pixel. But the loss is in the hue/saturation domain rather than the jpeg's geometric domain. > Also, saying that one unit of 16 bits is more natural to store one pixel than > 3 units of 8 bits - well, with 24-bit-per-pixel pixels, you just grab each > byte and get the red, green, and blue values; with your proposal, you will > have to do shifts or rotations, plus AND (and possible OR) operations to > extract the Hue, Saturation and Intensity values - which is even less > effective, usually. When I get my techical overview page written (hopefully this weekend), you will see that this is not true. Luts, think Luts, three 65536-entry luts... u_char lutRGB[3][65536]; > > Another thing: If someone is willing to sacrifice visual accuracy to store an > (originally 24-bit-per-pixel) image, then I would suggest that JPG is a more > reasonable choice. Do a 3x blow-up of a typical jpeg image. Then get back to me. (As monitor resolution grows, displaying a 500x400 image on, say, a 1600x1280 display becomes problematic. Blowing up jpeg images to fill up a reasonable portion of the monitor is not an aesthetically pleasing option.) > As for your proposal offering 12 bit-per-pixel greyscale in conjunction with > color - that is true if and only if you treat 'Saturation = 0' as a special > case, thus breaking the orthogonality of the format - ie, it won't be a simple > 'Hue, Saturation, Intensity' format any more. Hmmm, to me it is not a "special case". Pretending there was red with no saturation which was different than teal with no saturation would be a special case. "Unorthogonal", yes, "special", yes; "special case", no. > > As for your suggestion for transparency - you have misunderstood what Alpha is > all about. It is not an 'overlay'; it is another channel (much like red, > green, or blue) which tells how the current pixel and its background are to be > blended. Here I may have used a poor choice of words. My mend blends words in ways that even many of my fellow Americans don't understand. I need to be very precise in this international arena. To me, "overlay" is simply a special type of "channel". And I do have a basic understanding of the blending capability of PNG Alpha channels. But many times, blending is not necessary. If all you want to do is show the background image (with perhaps some intensity variation), then the png-16 transparancy feature is quite adequate, without requiring a separate channel. > Your comments regarding 48-bit-per-pixel as being 'precision far in excess of > accuracy', you are also wrong. This accuracy is in fact sometimes _necessary_. > Medical applications, for instance, often need 16-bit greyscale for a _good_ > representation of an X-ray image. Also, 'precision' and 'accuracy' are in fact > two terms that describe different phenomena when you are measuring something. This is really funny, Christian. Check out my PNG Gallery (http://home.att.net/~rocq/pngLibrary.html). The company I work for makes film scanners for the medical and NDT (non-destructive testing) industries. I have been working with "deep grey" (12 to 16 bits per pixel) for 8 years now, and I _know_ how important it is to these industries. My comment that you criticize dealt with 48-bit images (images with saturations greater than 0). I will stand by my statement that, for color images, 48 bits per pixel is overkill, and is in fact precision far in excess of accuracy. > Likewise, 32-bit-per-pixel CMYK can _not_ be represented equally well as > 16-bit-per-pixel CMYK. Ask someone in the printing industry, perhaps. Maybe I was wrong on this point. I suspect, though, it deals with the algorithm for representing the image. If they store every pixel of a 1200 dpi image, then 32 bits per pixel is extreme. If, however, there are good algorithms to do a color-to-geometric trade off, then having the 32-bits per pixel at maybe 150 dots per inch would be necessary. > Also, you write a long paragraph about gamma correction - concluding that > while great in theory, it has practical problems. Well, those practical > problems are indeed just that - practical problems which need to be overcome. > And which _have_ been overcome on some platforms - Apple Macintosh, for > instance, offer color synchronization in the whole system. > > Of course, you write about gamma correction in the section about how many bits > one might use per pixel - which is in itself rather confusing, since one would > not store gamma information with each pixel, but rather include 'gamma' > information with the whole image - as it is done in PNG. Actually, some graphic boards do provide gamma correction on each pixel. You think you are sending the graphic board 8 bits of red, but that 8 bits is sent to a 256-entry 10-bit gamma LUT, and there is a 10-bit d-to-a converter on the output end. Similarly, some scanners scan internally at 10 bits per pixel per color channel and then map the data down to 8 bits per channel for the actual output file. > Basically, it seems like you have either not read or not understood most parts > of the PNG specification. Hey, I downloaded it, and it's on my hard disk. Really! ;-) Seriously, I haven't got to the point of implementing a specification, and right now all the technical details have not been finalized or even thought-through thoroughly. I plan to use the PNG specification as a framework for building the png-16 spec. I see png-16 as being a superset of png. A "png-16" compliant package would handle both the ".png" and ".pn6" extensions, whereas png-compliant packages need only handle ".png". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dave Martindale wrote (Wed, 19 Aug 1998 10:35:48 -0700): > > >Regarding the email message <35DA49DB.C3A1376@worldnet.att.net> that was sent > >to png-announce, I have drafted the following reply; could someone please take > >a look at it and phrase it more gently and correctly ? :-) > > Well, it could be phrased more gently, but I'm not the right person to > do that. But I think you're correct about what you say. > > I glanced at the proposal, and I think its most fundamental problem is > too few bits. If you really want to store images in HSL format, I think > you need at least 8 bits for the L (intensity) data, not 6. 6 bits is > just about guaranteed to produce banding artifacts in some images. > > The author, I think, tries to anticipate this by offering 12-bit greyscale. > He has a special case in the coding where, if saturation is zero, this > indicates greyscale, and then the hue bits can be used as an extension > to the lightness bits. That's great for pure monochrome images, except > that PNG would have stored those images using only 8 bits per sample or, > in worst case, 16 bits with a lot less trouble encoding and decoding. > > And if you take this monochrome image and add just a hint of colour to > it, then the hue and saturation fields are now forced to be non-zero, > and you have only 6 bits for intensity. So there is a big discontinuity > in the intensity resolution between pure greyscale and ever-so-slightly- > tinted images. > > Basically, if you really have to store images in only 16 bits per pixel, > this encoding might work better than straightforward 5/5/5 bit RGB - for > some images. But 16-bit RGB is generally just a bad idea for photographic > quality images, and a slight improvement on a bad idea is still, I'm afraid, > a bad idea. > > Dave Dave, I don't expect to convince everyone until there is a png-16 library and a test-app or two. I find your points to be accurate and useful. I can't wait to do my "indistinguishability" test. Maybe I'm wrong, but I'm willing to give it a shot! As far as your "banding" argument goes, I agree that the human eye can discern more than 64 shades of grey on a high-contrast monitor. I've read, and my experience tends to confirm, that we can see about 80 shades of intensity on a high-quality monitor. In fact my original draft of the PNG-16 overview had 4 bits of saturation, 7 bits of intensity, and only 5 bits of hue. I finally decided, though, that I would rather have the discernable precision in hue rather than 40 shades of grey per hue/sat combination that were not even distinct. For problematic images, I intend that libpn6 will have an optimizing mode that will assign the indexed colors appropriately and automatically to eliminate/minimize any banding or other artifacting. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chris Lilley wrote (Wed, 19 Aug 1998 23:41:04 +0200): > > Sorry I happen to be really tied up with something else right now, or I > would certainly have a go. But let me jot down a few notes that occured > to me reading throught the proposal, particularly the color space part > of course, and maybe that will help someone else do a response. > > There are various different color spaces answering to the name HLS HSI, > IHS,; they are all cylindrical spaces (x, y, radius) > > It seems that the one he is talking about is where black is at the > bottom cap of the cylinder; greys run up the middle, white is at the > center of the top cap, and the primary and secondary colors red, yellow, > green, cyan, blue, mageta are spaced at equal 60 degree distances around > the perimiter of the top cap. > > This means that the "lightness" component has nothing to do with > percieved lightness - blue (RGB 0000FF) is given the same lightness > value as yellow (RGB FFFF00) even though yellow is quite obviously much > brighter. Chris, your interpretation of my intent is basically correct. I agree that the number of photons hitting my eye from a full-intensity magenta image are more than the number of photons hitting my eye from a full-intensity blue image. For magenta, both the blue and red guns are shooting their photons right at me! But I have to say that I just viewed the following html code:
and I can't say that magenta actually looked brighter than blue. Or that white looked brighter than magenta. My intent at this point is to define intensity as MAX(red, green, blue). This may well change if it is shown that some other SIH algorithm provides a more useful color space. > It means that the hue angle is not perceptually uniform - at some angles > the hue is changing very fast, on others it changes more slowly for the > same angular change - so bits are wasted because you need enough > resolution in the areas where hue change is fast and those bits are > wasted in areas where hue change is slower. > > Considering a 24bit RGB cube, balanced on its point such that black is > at the bottom and white at the top, the hue angle runs around a zig-zag > of six edges of the cube (between red to yellow, then to green, ands so > on). There are 256 steps on each edge, giveng a maximum number of hue > steps of 6*256= 1536. He proposes 60 unique hue angles, around 4% of > what 24bit color supports. Cool. But how many hues can a $300 monitor actually display? > It means that many bits are wasted at the darker end of the color space, > because the eye can increasingly resolve hue and saturation levels as > brightness increases. So at the dark end, many colors with different bit > patterns will be the same visual color, wasting bits (and there are > precious few to begin with). This is taken care of in his proposal for > pure black, which is the bottom end cap (1024 colors all the same, > black) so he does some clever things with these when intensity is 0. But > he allocates 6 bits for intensity (64 levels) so when intensity is 1, 2 > etc all 1024 colors on that intensity slice are the same visually and so > on (as you go up in intensity you can see more distinct colors, > eventually at or near full intensity you can see all 1024 distinct > colors in that slice). > > This is why the HSI color space is usually drawn as a cone with black at > the point, to show there is only one visible black color and > increasingly more as you get brighter. Geometrically as a coordinate > system, and in terms of bit usage, it is a cone. Assuming the cone is a > good representation of the visible colors, someone with better > recollection of high school geometry can subtract the volume of a cone > from the volume of the enclosing cylinder and work out what percentage > of bit patterns are wasted. [1] You make a good case for providing a special mapping in all cases where the intensity component is 7 or less. This would free up the "wasted" entries to serve the "holes" at brighter levels. > There are lots of other clever tweaks for specific cases in his > proposal, mainly getting only a single black color (instead of 1024) and > more grey levels (instead of only 64). These fall down when the color is > nearly but not quite black (wasted bits) and lack of colors when the > saturation is nearly but not quite neutral (there are 4 bits of > saturation radius ie 16 values from the center to the edge; in a slice > passing through the center and parallel to the center line you get 4 > bits to the left of center and 4 bits to the right of center (with the > hue angle 180 degrees different on the right and on the left) so you > effectively get twice as many colors, you would assume 5 bits, with ther > colors for saturation=0 overlapping; but saturation=0 is treated > specially so saturation actually goes 1 to 15 both sides. At low levels > of saturation (near-neutral, pastel colors) where the eye is sensitive > to shade variation, there are only 64 levels of lightness. > > Lastly, because of the various tweaks and tucks, this isn't really a > truecolor space (you couldn't render to it by direct calculation; you > have to render to 24 or actually 48 bits (to allow for the 12 bits of > grey) and then quantize to the allowed colors. If the display hardware were capable of more than 8 bits per gun, then yes, the lutRGB[3][65536] should be of type u_short instead of u_char. > What this actually is is an *indexed* colorspace, but one in which the > resulting indexed to truecolor conversion does not need to be stored in > a separate palette because it can be described algorithmically. In other > words, this is a single fixed palette. > > The perils of quantising to a fixed palette are already well known, as > anyone who has quantised to 216 colors of the mythical "browser safe" > palette and then 216 colors of an adaptive pallete can testify. Yep. But a very big "single fixed palette". Comparing the problems of a palette with just 216 colors to one with 60796 colors (counting only the static colors and greys) isn't really fair. > There are 2^16 ie 65526 values, of which 256 are reserved for "vendor > options' and 3,780 are reserved for a variable palette (this would be a > large palette, and a sizeable proportion of the image unless the image > was really large). That means it is a 61,500 entry fixed palette, with > 16 bits used for each palette entry in the image data. In this fixed > palette a large proportion (volume of cylinder divided by volume of > cone) of the colors are wasted because they look the same. Ok, I won't "waste" any colors. (Maybe we should map PNG-16 to a klein bottle rather than a cone. ;-) > As we all know, indexed data rarely if ever benefits from PNG > pre-filtering before compression. So we are actually comparing 16bit, > non filtered, compressed indexed data with 24bit, filtered, compressed > truecolor data. Greg Roelofs answers this point below. Since the "indices" have a representational similarity to the "true colors" they represent, compression would tend to be greater than you imply. > I'm sure many of you have observed a 24bit, filtered truecolor PNG > oftentimes being only twice the size (or less) of an 8bit indexed PNG > rather than three times the size. This leads me to believe that a 16bit, > indexed image using thhis proposed colorspace would be about the same > size as a 24bit, truecolor PNG image, using the same compression > algorithms. > > [1] children, pay attention in high school now, and learn all that 'by > heart' stuff, not like Uncle Chris. > > 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@w3.org 2004 Rt des Lucioles / BP 93 > +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Greg Roelofs wrote (Wed, 19 Aug 1998 17:05:35 -0700): > > [Redirected to png-list...you guys are driving off interested folks who > just want PNG announcements.] > > > This is why the HSI color space is usually drawn as a cone with black at > > the point, to show there is only one visible black color and > > increasingly more as you get brighter. Geometrically as a coordinate > > system, and in terms of bit usage, it is a cone. Assuming the cone is a > > good representation of the visible colors, someone with better > > recollection of high school geometry can subtract the volume of a cone > > from the volume of the enclosing cylinder and work out what percentage > > of bit patterns are wasted. [1] > > 67% (vol = 1/3 pi r^2 h) > > > There are 2^16 ie 65526 values, of which 256 are reserved for "vendor > > 65536, since we're picking nits. :-) > > > As we all know, indexed data rarely if ever benefits from PNG > > pre-filtering before compression. So we are actually comparing 16bit, > > non filtered, compressed indexed data with 24bit, filtered, compressed > > truecolor data. > > I'm not sure that follows, necessarily. This "fixed palette" should > have more correlation in it than an arbitrary 8-bit palette, so I would > expect that filtering might actually help. (For that matter, I'm still > convinced that filtering can help in palette images for the right per- > mutation of the palette; finding that permutation is the tricky part.) > > Of course, the lack of alignment between the 4/6/6-bit sample data and > the 8-bit PNG filter algorithms might toss all that out the window. > > Greg I intend to flesh-out my png-16 technical page this weekend. I am at an early stage of design, and the only things "fixed in stone" is that I want 16 bits per pixel, and I want to have a color space that includes both 12-bit grey and a large color palette. Well, I also really, really want to see color-cycled color-cycled colors put to effective use, but that will be awhile... Thanks for input from everyone. It's cool that you are free to tell me what you honestly think; I don't have particularly thin skin. And I'm not asking the pngMasters to consider any of this as a png proposal until they can see png-16 actually implemented. The first pass at implementation would include the 60796 fixed colors and 3780 indexed colors. Bells and whistles come some time after the invention of brass. It's late here in Florida and I'm too tired to further edit this letter. So if there are typos, grammatical errors, or silly logical errors please ignore them. -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 20 04:06:55 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id EAA14164 for ; Thu, 20 Aug 1998 04:06:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA21620 for png-list-outgoing; Thu, 20 Aug 1998 04:03:04 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA21615 for ; Thu, 20 Aug 1998 04:02:57 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id LAA08977; Thu, 20 Aug 1998 11:00:40 +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: <35DBE5FF.D5839D7C@w3.org> Date: Thu, 20 Aug 1998 11:01:51 +0200 From: Chris Lilley X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: PNG List Subject: Re: "oh no, not again!" References: <199808200005.RAA00440@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Greg Roelofs wrote: > > [Redirected to png-list...you guys are driving off interested folks who > just want PNG announcements.] Sorry, I hadn't noticed it went to the announce list. The text of the original message was asking for help from ng-list to create a message to send to png-announce ... > > someone with better > > recollection of high school geometry can subtract the volume of a cone > > from the volume of the enclosing cylinder and work out what percentage > > of bit patterns are wasted. [1] > > 67% (vol = 1/3 pi r^2 h) Thanks > > > There are 2^16 ie 65526 values, of which 256 are reserved for "vendor > > 65536, since we're picking nits. :-) I knew that. Typing too quickly. I did use 65536 in the calculations > Of course, the lack of alignment between the 4/6/6-bit sample data and > the 8-bit PNG filter algorithms might toss all that out the window. If this was a serious proposal to add to PNG, we could do some code and convert some images and try compressing them. I am assuming at this point that such a non backwards compatible change of dubious usefulness would not be a serious contender. But other folks might disagree. -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 20 08:52:21 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA15279 for ; Thu, 20 Aug 1998 08:52:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA23182 for png-list-outgoing; Thu, 20 Aug 1998 08:52:06 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA23177 for ; Thu, 20 Aug 1998 08:52:03 -0500 Received: (qmail 5638 invoked from network); 20 Aug 1998 13:50:28 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 20 Aug 1998 13:50: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 GAA10909 for ; Thu, 20 Aug 1998 06:49:44 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id GAA30741 for png-list@dworkin.wustl.edu; Thu, 20 Aug 1998 06:49:48 -0700 Date: Thu, 20 Aug 1998 06:49:48 -0700 Message-Id: <199808201349.GAA30741@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: "oh no, not again!" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Rich wrote: > When I get my techical overview page written (hopefully this weekend), > you will see that this is not true. Luts, think Luts, three 65536-entry > luts... > u_char lutRGB[3][65536]; Holy loss of cache coherency, Batman! :-) That's gotta hurt. Performance- wise, you might almost be better off calculating on the fly. > My comment that you criticize dealt with 48-bit images > (images with saturations greater than 0). I will stand by my statement > that, for color images, 48 bits per pixel is overkill, and is in fact > precision far in excess of accuracy. You should check out comp.graphics.apps.photoshop or any of the other three or four cross-posted groups for the lengthy threads on gamma, RGB/LAB, and linear representations. For those who want to do every- thing in a linear domain, 11 or 12 bits per sample is necessary to avoid visible artifacts at the low end. (Chris and Dave can word this better.) You must also be aware that astronomers obtain deep pixel data with some rather impressive CCD hardware. Although those scans are individually single-channel, multi-filter composites are quite common--giving, e.g., the Eagle Nebula image that Star Trek and B5 are so fond of. So one could imagine that they'd want to store such things in a 48-bit RGB format. (In practice I think they use floating-point because of the dynamic range, but what's an extra 48 bits between friends?) Chris wrote: > I am assuming at this point that such a non backwards compatible change > of dubious usefulness would not be a serious contender. But other folks > might disagree. I think that, unless there is a very strong desire for something like this from the graphics community, incorporating it into the core of PNG would be extremely harmful to the acceptance of both PNG and PN6. If and when we decide to make a non-backward-compatible upgrade to PNG on other grounds (say, to incorporate zlib 2 compression methods), then the barrier would obviously be smaller. But I suspect that point is at least two or three years off. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 20 10:26:07 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA15939 for ; Thu, 20 Aug 1998 10:26:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA24426 for png-list-outgoing; Thu, 20 Aug 1998 10:24:15 -0500 Received: from mtiwmhc02.worldnet.att.net (mtiwmhc02.worldnet.att.net [204.127.131.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA24420 for ; Thu, 20 Aug 1998 10:24:11 -0500 Received: from worldnet.att.net ([12.77.129.27]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980820152156.DOUM19638@worldnet.att.net>; Thu, 20 Aug 1998 15:21:56 +0000 Message-ID: <35DC3DBA.4D7FAFE@worldnet.att.net> Date: Thu, 20 Aug 1998 11:16:10 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: PNG List CC: Rich.Franzen@dba-sys.com, Nathan@geodetic.com Subject: Re: "oh no, not again!" References: <199808201349.GAA30741@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Greg Roelofs wrote (Thu, 20 Aug 1998 06:49:48 -0700): > > Rich wrote: > > > When I get my techical overview page written (hopefully this weekend), > > you will see that this is not true. Luts, think Luts, three 65536-entry > > luts... > > > u_char lutRGB[3][65536]; > > Holy loss of cache coherency, Batman! :-) That's gotta hurt. Performance- > wise, you might almost be better off calculating on the fly. I'll just pretend everyone who uses png-16 is using the genuine Intel Celeron processor, and they ain't got no frickin' cache! Seriously, I don't expect real-world cases to be that bad; geometrically close regions will tend to have close colors. And for many people, even an extreme loss of "cache-coherency" means that their image viewer will take 1.5 seconds to show the next image rather than 1.0 seconds. Besides, this lutRGB[][] is the only reasonable way I can see to support deep grey, static colors, and indexed colors all at once. > > My comment that you criticize dealt with 48-bit images > > (images with saturations greater than 0). I will stand by my statement > > that, for color images, 48 bits per pixel is overkill, and is in fact > > precision far in excess of accuracy. > > You should check out comp.graphics.apps.photoshop or any of the other > three or four cross-posted groups for the lengthy threads on gamma, > RGB/LAB, and linear representations. For those who want to do every- > thing in a linear domain, 11 or 12 bits per sample is necessary to > avoid visible artifacts at the low end. (Chris and Dave can word this > better.) > > You must also be aware that astronomers obtain deep pixel data with some > rather impressive CCD hardware. Although those scans are individually > single-channel, multi-filter composites are quite common--giving, e.g., > the Eagle Nebula image that Star Trek and B5 are so fond of. So one > could imagine that they'd want to store such things in a 48-bit RGB format. > (In practice I think they use floating-point because of the dynamic range, > but what's an extra 48 bits between friends?) I'm glad that png supports 48 bits per pixel. I suspect, however, that the number of people who will find it useful will be, um, limited. > Chris wrote: > > > I am assuming at this point that such a non backwards compatible change > > of dubious usefulness would not be a serious contender. But other folks > > might disagree. > > I think that, unless there is a very strong desire for something like > this from the graphics community, incorporating it into the core of PNG > would be extremely harmful to the acceptance of both PNG and PN6. If > and when we decide to make a non-backward-compatible upgrade to PNG on > other grounds (say, to incorporate zlib 2 compression methods), then > the barrier would obviously be smaller. But I suspect that point is at > least two or three years off. I knew and admitted from my first posting that getting this into PNG via the formal methods would be an ineffective approach. It's fine and actually good that you are skeptical until you can see it. Once it's implemented and found useful, then I'll make a formal proposal. Until then I'm perfectly happy to be some weird American standing at the outside of pngHouse, making occasional erratic motions which you can see thru the windows. > Greg > > -- > Send the message body "help" to png-list-request@dworkin.wustl.edu -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 20 10:58:01 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id KAA16139 for ; Thu, 20 Aug 1998 10:57:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA24635 for png-list-outgoing; Thu, 20 Aug 1998 10:52:36 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA24630 for ; Thu, 20 Aug 1998 10:52:33 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa26312; 20 Aug 98 11:48 EDT Message-ID: <35DC4561.5D8637A8@alumni.rpi.edu> Date: Thu, 20 Aug 1998 11:48:49 -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: "oh no, not again!" References: <199808201349.GAA30741@bolt.sonic.net> <35DC3DBA.4D7FAFE@worldnet.att.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Richard W. Franzen wrote: > > Greg Roelofs wrote (Thu, 20 Aug 1998 06:49:48 -0700): > > > > Rich wrote: > > > > > When I get my techical overview page written (hopefully this weekend), > > > you will see that this is not true. Luts, think Luts, three 65536-entry > > > luts... > > > > > u_char lutRGB[3][65536]; > > > > Holy loss of cache coherency, Batman! :-) That's gotta hurt. Performance- > > wise, you might almost be better off calculating on the fly. > > I'll just pretend everyone who uses png-16 is using the genuine Intel > Celeron processor, and they ain't got no frickin' cache! Seriously, I > don't expect real-world cases to be that bad; geometrically close > regions will tend to have close colors. And for many people, even an > extreme loss of "cache-coherency" means that their image viewer will > take 1.5 seconds to show the next image rather than 1.0 seconds. Greg wasn't talking about closeness of colors, merely about lut[3][n] versus lut[n][3]. I think. > > I knew and admitted from my first posting that getting this into PNG via > the formal methods would be an ineffective approach. It's fine and > actually good that you are skeptical until you can see it. Once it's > implemented and found useful, then I'll make a formal proposal. Until > then I'm perfectly happy to be some weird American standing at the > outside of pngHouse, making occasional erratic motions which you can see > thru the windows. The proof would be in the pudding. You'll have to demonstrate a significant improvement in compression versus existing PNG bit depths, zero-filled to match any equivalent loss in resolution. Since the amount of information present will be roughly equal, it's likely that the final compressed sizes will be roughly equal as well. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Thu Aug 20 12:34:41 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id MAA16808 for ; Thu, 20 Aug 1998 12:34:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA25871 for png-list-outgoing; Thu, 20 Aug 1998 12:34:09 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA25865 for ; Thu, 20 Aug 1998 12:34:04 -0500 Received: (qmail 13200 invoked from network); 20 Aug 1998 17:32:33 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 20 Aug 1998 17:32:33 -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 KAA10310 for ; Thu, 20 Aug 1998 10:31:49 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id KAA04416 for png-list@dworkin.wustl.edu; Thu, 20 Aug 1998 10:31:55 -0700 Date: Thu, 20 Aug 1998 10:31:55 -0700 Message-Id: <199808201731.KAA04416@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: "oh no, not again!" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >>>> u_char lutRGB[3][65536]; >>> Holy loss of cache coherency, Batman! :-) That's gotta hurt. Performance- >>> wise, you might almost be better off calculating on the fly. >> I'll just pretend everyone who uses png-16 is using the genuine Intel >> Celeron processor, and they ain't got no frickin' cache! Seriously, I >> don't expect real-world cases to be that bad; geometrically close >> regions will tend to have close colors. And for many people, even an >> extreme loss of "cache-coherency" means that their image viewer will >> take 1.5 seconds to show the next image rather than 1.0 seconds. > Greg wasn't talking about closeness of colors, merely about lut[3][n] > versus lut[n][3]. I think. Valid point, but actually I was talking about L1 cache, which is typically only 8K or 16K--certainly nowhere near 192K. (Celerons do have those, btw.) Since 16-bit pixels are most commonly used in games, I was under the im- pression that speed was a major concern. If not, never mind... Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 21 20:07:51 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id UAA28962 for ; Fri, 21 Aug 1998 20:07:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA17807 for png-list-outgoing; Fri, 21 Aug 1998 20:06:17 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA17802 for ; Fri, 21 Aug 1998 20:06:13 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id SAA06088; Fri, 21 Aug 1998 18:03:48 -0700 (PDT) Date: Fri, 21 Aug 1998 18:03:48 -0700 (PDT) Message-Id: <199808220103.SAA06088@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: PNG 1.1 proposal draft 1.2.3 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I've incorporated recent suggestions into the 1.1 proposal. Draft 1.2.3 is available from: http://www.cs.berkeley.edu/~amc/png/ There are still three unresolved issues: * 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? * Should we refer to CIE 122? * Should we say anything about constructing gamma correction tables using fixed-point math? In light of Michael's explanation of the deliberate ambiguity of ICC rendering intents, I decided to avoid describing any implementations, and use his examples. This is what I came up with: 0: Perceptual For images preferring good adaptation to the output device gamut at the expense of colorimetric accuracy, like photographs. 1: Relative colorimetric For images requiring color appearance matching (relative to the output device white point), like logos. 2: Saturation For images preferring preservation of saturation at the expense of hue and lightness, like charts and graphs. 3: Absolute colorimetric For images requiring preservation of absolute colorimetry, like proofs (previews of images destined for a different output device). AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 21 21:50:52 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id VAA29312 for ; Fri, 21 Aug 1998 21:50:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA18360 for png-list-outgoing; Fri, 21 Aug 1998 21:46:48 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA18355 for ; Fri, 21 Aug 1998 21:46:40 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA08017; Fri, 21 Aug 1998 22:44:17 -0400 Message-Id: <1.5.4.32.19980822024009.00f8a830@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, 21 Aug 1998 22:40:09 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG 1.1 proposal draft 1.2.3 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I like your use of "intensity sample" instead of "linear colorspace". We need a glossary entry for "intensity" or "intensity sample". Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 21 22:14:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id WAA29438 for ; Fri, 21 Aug 1998 22:14:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA18599 for png-list-outgoing; Fri, 21 Aug 1998 22:11:52 -0500 Received: from u33.CS.Berkeley.EDU (u33.CS.Berkeley.EDU [128.32.44.157]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA18594 for ; Fri, 21 Aug 1998 22:11:49 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id UAA06437; Fri, 21 Aug 1998 20:09:25 -0700 (PDT) Date: Fri, 21 Aug 1998 20:09:25 -0700 (PDT) Message-Id: <199808220309.UAA06437@u33.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: PNG 1.1 proposal draft 1.2.3 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson says: > We need a glossary entry for "intensity" or "intensity sample". How about this: Intensity Power per unit area of light entering or leaving a surface. It is often normalized to the range 0 to 1 by dividing by a maximum intensity. AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Fri Aug 21 23:51:50 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id XAA29905 for ; Fri, 21 Aug 1998 23:51:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA19045 for png-list-outgoing; Fri, 21 Aug 1998 23:52:47 -0500 Received: from mtiwmhc02.worldnet.att.net (mtiwmhc02.worldnet.att.net [204.127.131.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA19038 for ; Fri, 21 Aug 1998 23:52:44 -0500 Received: from worldnet.att.net ([12.77.129.99]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980822045020.HRXY15090@worldnet.att.net>; Sat, 22 Aug 1998 04:50:20 +0000 Message-ID: <35DE4CB8.97CFE0E5@worldnet.att.net> Date: Sat, 22 Aug 1998 00:44:40 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu CC: Rich.Franzen@dba-sys.com Subject: nerd discovers "shadow soup" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit A mysterious Florida programmer and rogainer announced today that he has discovered shadow soup. When asked for comment, he said, "It's not like I won the lottery or nothun', but it sure beats a punch in the nose. I think the shadow soup was there the whole time, but I wasn't usin' a flashlight at first." More details may be found at http://home.att.net/~rocq/png16.html#shadowSoup -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 22 05:37:46 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id FAA01296 for ; Sat, 22 Aug 1998 05:37:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA20656 for png-list-outgoing; Sat, 22 Aug 1998 05:35:33 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA20651 for ; Sat, 22 Aug 1998 05:35:30 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id GAA18380; Sat, 22 Aug 1998 06:33:04 -0400 Message-Id: <1.5.4.32.19980822102854.00f8e204@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, 22 Aug 1998 06:28:54 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: nerd discovers "shadow soup" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 12:44 AM 8/22/98 -0400, you wrote: >A mysterious Florida programmer and rogainer announced today that he has >discovered shadow soup. When asked for comment, he said, "It's not like >I won the lottery or nothun', but it sure beats a punch in the nose. I >think the shadow soup was there the whole time, but I wasn't usin' a >flashlight at first." > >More details may be found at >http://home.att.net/~rocq/png16.html#shadowSoup The human vision system is actually more sensitive at low levels than at high levels. Your observations must be based on looking at gamma-encoded images on a PC (or simply throwing data onto the screen without gamma-decoding). It's true that *those* might be trading off a little too much resolution in the bright areas for resolution in the dark areas. Cure for that is to use a gamma larger than 1/2.2, as is done on Macs and SGIs (but still less than 1.0). The Florida programmer is multiplying the (explicit or implicit) 1/2.2 gamma transform by another two-piece linear transform that has a discontinuity in the middle. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 22 08:05:17 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id IAA01661 for ; Sat, 22 Aug 1998 08:05:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA21346 for png-list-outgoing; Sat, 22 Aug 1998 08:06:46 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA21341 for ; Sat, 22 Aug 1998 08:06:42 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA21812; Sat, 22 Aug 1998 09:04:16 -0400 Message-Id: <1.5.4.32.19980822130006.00f76800@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, 22 Aug 1998 09:00:06 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG 1.1 proposal draft 1.2.3 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 06:03 PM 8/21/98 -0700, you wrote: >In light of Michael's explanation of the deliberate ambiguity of ICC >rendering intents, I decided to avoid describing any implementations, >and use his examples. This is what I came up with: > > 0: Perceptual > For images preferring good adaptation to the output > device gamut at the expense of colorimetric accuracy, > like photographs. > > 1: Relative colorimetric > For images requiring color appearance matching (relative > to the output device white point), like logos. > > 2: Saturation > For images preferring preservation of saturation at the > expense of hue and lightness, like charts and graphs. > > 3: Absolute colorimetric > For images requiring preservation of absolute > colorimetry, like proofs (previews of images destined for > a different output device). It strikes me that a decoder could use this information to decide whether to dither or not when displaying on a limited-color device. Clearly "perceptual" should be dithered and "saturation" should not. I don't know about the others. Anyhow, we could put a little statement about that in the Recommendation for Decoders:Truecolor image handling, such as > graininess that can be objectionable. + When the sRGB chunk is present with rendering_intent=2, the + image should be quantized by simply selecting the nearest + color rather than by dithering. -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@dworkin.wustl.edu Sat Aug 22 09:29:01 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1a/8.9.1) with SMTP id JAA01923 for ; Sat, 22 Aug 1998 09:29:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA21791 for png-list-outgoing; Sat, 22 Aug 1998 09:30:16 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA21786 for ; Sat, 22 Aug 1998 09:30:12 -0500 Received: (qmail 23770 invoked from network); 22 Aug 1998 14:28:34 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 22 Aug 1998 14:28:34 -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 HAA32346 for ; Sat, 22 Aug 1998 07:27:46 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA06638 for png-list@dworkin.wustl.edu; Sat, 22 Aug 1998 07:28:02 -0700 Date: Sat, 22 Aug 1998 07:28:02 -0700 Message-Id: <199808221428.HAA06638@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: PNG 1.1 proposal draft 1.2.3 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > There are still three unresolved issues: > * 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? What sections are you specifically referring to? > * Should we refer to CIE 122? Which is what? > * Should we say anything about constructing gamma correction tables > using fixed-point math? Yes. In addition, I strongly disagree with the idea that the new chunks must be tacked onto the end of section 4.2 for the sake of some nebulous third- party documents that happen to refer to section numbers. Section 4.2 is in alphabetic order and should remain that way. Section 4.3 is in physical order, and then alphabetized within that; same comment. You're sacrificing the readability of the spec and its usefulness as a reference for hypothet- ical reasons. (I thought I had brought up this point some time ago, but maybe I forgot.) > In light of Michael's explanation of the deliberate ambiguity of ICC > rendering intents, I decided to avoid describing any implementations, > and use his examples. This is what I came up with: The deliberateness of the ambiguity should be mentioned somewhere, too. I don't like it, but if the ICC can't make up its mind, at least let's note that it's their ambiguity, not ours. I'd be in favor of adding "for example" clauses to each intent--*something* to help decoder-writers figure out what the hell to do with this stuff. (Or do we just assume everyone is going to ship a CMS with their software?) Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 24 00:52:20 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 AAA05656 for ; Mon, 24 Aug 1998 00:52:19 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA17168; Mon, 24 Aug 1998 00:49:11 -0500 Received: from dworkin.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id AAA17162; Mon, 24 Aug 1998 00:49:05 -0500 Received: from by dworkin.ccrc.wustl.edu (4.1/ECL-A1.21) id AB01193; Mon, 24 Aug 98 00:51:39 CDT Received: from mtiwmhc03.worldnet.att.net (mtiwmhc03.worldnet.att.net [204.127.131.38]) by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id WAA05734 for ; Sun, 23 Aug 1998 22:55:46 -0500 (CDT) Received: from worldnet.att.net ([12.77.197.79]) by mtiwmhc03.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980824035514.IUSE123@worldnet.att.net>; Mon, 24 Aug 1998 03:55:14 +0000 Message-Id: <35E0E2BE.ADB8959A@worldnet.att.net> Date: Sun, 23 Aug 1998 23:49:18 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) Mime-Version: 1.0 To: png-list@dworkin.wustl.edu Cc: rocq@netscape.net Subject: Re: nerd discovers "shadow soup" (or, "almost a cone") Content-Type: multipart/mixed; boundary="------------50E9E17AD63EC12A8CB74AFF" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List This is a multi-part message in MIME format. --------------50E9E17AD63EC12A8CB74AFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit resent; first try on 22aug98.12:15 EST disappeared I apologize if you end up getting this message twice. -- Rich --------------50E9E17AD63EC12A8CB74AFF Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <35DEEEA1.A0BEC1B2@worldnet.att.net> Date: Sat, 22 Aug 1998 12:15:29 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List CC: Rich.Franzen@dba-sys.com, Nathan@geodetic.com Subject: Re: nerd discovers "shadow soup" (or, "almost a cone") References: <1.5.4.32.19980822102854.00f8e204@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Glenn Randers-Pehrson wrote (Sat, 22 Aug 1998 06:28:54 -0400): > > The human vision system is actually more sensitive at low levels > than at high levels. Your observations must be based on looking > at gamma-encoded images on a PC (or simply throwing data onto > the screen without gamma-decoding). It's true that *those* might > be trading off a little too much resolution in the bright areas > for resolution in the dark areas. Cure for that is to use a > gamma larger than 1/2.2, as is done on Macs and SGIs (but still > less than 1.0). The Florida programmer is multiplying the (explicit > or implicit) 1/2.2 gamma transform by another two-piece linear transform > that has a discontinuity in the middle. > > Glenn > Chris Lilley wrote (Wed, 19 Aug 1998 23:41:04 +0200): > > ... > > It means that many bits are wasted at the darker end of the color space, > because the eye can increasingly resolve hue and saturation levels as > brightness increases. So at the dark end, many colors with different bit > patterns will be the same visual color, wasting bits (and there are > precious few to begin with). This is taken care of in his proposal for > pure black, which is the bottom end cap (1024 colors all the same, > black) so he does some clever things with these when intensity is 0. But > he allocates 6 bits for intensity (64 levels) so when intensity is 1, 2 > etc all 1024 colors on that intensity slice are the same visually and so > on (as you go up in intensity you can see more distinct colors, > eventually at or near full intensity you can see all 1024 distinct > colors in that slice). > > ... > Ok, I'm confused. Maybe Glenn is just telling me that the 70 intensities should be spread evenly, without a "discontinuity in the middle". (My page currently states that the first 15 intensities occupy the low 25% of the brightness range, and the remaining 55 intensities (including the 7 new intensity levels) occupy the upper 75%.) But if this discontinuity is problematic, then, heck, spread all 70 intensities evenly across the brightness range. Since png-16 represents a display-space and not an analytical space, should the brightness of the static colors be pre-modified with gamma as Glenn seems to suggest? My initial thought was to keep them linear, but there is nothing that would require this. I thank you all for your ideas and comments. Nothing is fixed in stone yet, and I'm definately not averse to making sensible modifications. It was because of Chris' feedback that "shadow soup" was even discovered. Now it's not just with intensity 0 that I'm doing some "clever things"; intensities 1 thru 7 have now been cleverated ("cleverized?", "clevered?") as well. My choice was to expand the number of discrete intensities rather than the number of hue/sat variations. (Chris, except for the bottom eight intensities, this is 900 (60 * 15) not 1024.) The number of hues have already been doubled by allocating 6 bits to hue rather than 5 (as my original, unpublished, overview said). Intuition tells me that the eye will be more forgiving to "missing" colors than "missing" intensities. What do you think? -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq/png16.html#shadowSoup --------------50E9E17AD63EC12A8CB74AFF-- -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 01:18: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 BAA16348 for ; Tue, 25 Aug 1998 01:18:59 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id BAA28221; Tue, 25 Aug 1998 01:15:07 -0500 Received: from mail3.mailsorter.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id BAA28217; Tue, 25 Aug 1998 01:15:06 -0500 Received: from libretto.schaik.com ([195.232.45.3]) by mail3.mailsorter.net (Netscape Mail Server v2.02) with SMTP id AAB14176 for ; Mon, 24 Aug 1998 23:14:57 -0700 Message-Id: <3.0.3.32.19980817210321.00691458@mail.schaik.com> X-Sender: willemschaik@mail.schaik.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 17 Aug 1998 21:03:21 +0200 To: png-list@dworkin.wustl.edu From: Willem van Schaik Subject: VOTE on iCCP 19980729 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List YES iCCP ftp://swrinde.nde.swri.edu/pub/png-group/documents/iccp-proposal-19980729.txt willem@schaik.com v a n S c h a i k ------------------------------------------------------------------------ willem@schaik.com http://www.schaik.com/wwwillem.html -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 09:53: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 JAA20388 for ; Tue, 25 Aug 1998 09:53:49 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA06000; Tue, 25 Aug 1998 09:51:51 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA05996; Tue, 25 Aug 1998 09:51:50 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id KAA30951; Tue, 25 Aug 1998 10:51:47 -0400 Message-Id: <1.5.4.32.19980825144737.00f94334@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, 25 Aug 1998 10:47:37 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: sPLT [Re: PNG 1.1 proposal draft 1.2.3] Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List The PNG 1.1 proposal doesn't change anything in the PLTE/hIST writeup, although we have concluded that this system is slightly flawed, and we have created and registered the sPLT chunk to provide a better solution. Should we add a specific reference to the sPLT chunk (which will appear in the PNG extensions document)? Or should we just move sPLT into the core spec? Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 12:25: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 MAA22182 for ; Tue, 25 Aug 1998 12:25:05 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09150; Tue, 25 Aug 1998 12:22:09 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09146; Tue, 25 Aug 1998 12:22:08 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA04653; Tue, 25 Aug 1998 13:18:58 -0400 Message-Id: <1.5.4.32.19980825171449.00f93b58@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, 25 Aug 1998 13:14:49 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 07:53 AM 8/19/98 -0700, you wrote: >>>>> I suggest that the gIFT spec in the extensions document specify a >>>>> behavior, even though the GIF89a spec doesn't. > >>>> I don't think this is our problem, and I don't think it's our place to >>>> specify the solution. If the GIF spec is ambiguous on this point, the >>>> GIF conversion chunks inherit the same exact same semantics, including >>>> the ambiguity. > >I don't know where the idea that the GIF spec is ambiguous comes from; >it clearly states: > > This block is a graphic rendering block, > therefore it may be modified by a Graphic Control Extension. > >The GCE, of course, is where GIF's transparency info lives. There is >no indication that, if present, the GCE may be considered optional; the >only optional part about it is its presence in the first place. Right, it is not ambiguous. If the TextBackgroundColor is transparent, then it is transparent with respect to whatever is on the screen, which would be the main PNG image, if gIFt follows IDAT, and would be the application's background, if gIFt comes first or if it overlays a transparent part of the main PNG image. But there are circumstances where the transparency information about the RGB colors in gIFt can be lost or become ambiguous (when the original GIF contains a separate GCE for the PlainText rendering block, with a different transparent color than that of the main GIF image rendering block, for instance). >I found the problem a couple of months ago while writing the chapter on >miscellaneous chunks, and I never brought it up because it seems clear to >me that there's no way around it except to define a new gIFt chunk (with >a different name, obviously--GIFT or GTXT would make the most sense). >Since no one has complained about the current one, it didn't seem worth >bothering with. Not critical chunks. Maybe gTXt or gIFa (GIF text with alpha) or tXTo (text overlay). I think it's worth bothering with because some GIFs can't be converted absolutely losslessly to PNG (why leave that objection open, even if few if any such GIFs exist?) and because it's easy to fix by defining a new ancillary extension chunk that's exactly like gIFt except that TextForegroundColor and TextBackgroundColor are RGBA instead of RGB. That way, gif->png would create gIFa, and png->gif would create a GCE plus PlainText block. Right now, gif->png will create gIFt, but png->gif only creates the PlainText block, leaving it to rely on the main image's GCE, which might be wrong. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 12:36: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 MAA22276 for ; Tue, 25 Aug 1998 12:36:51 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09369; Tue, 25 Aug 1998 12:34:05 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09365; Tue, 25 Aug 1998 12:34:04 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA05335; Tue, 25 Aug 1998 13:33:40 -0400 Message-Id: <1.5.4.32.19980825172930.00f96e64@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, 25 Aug 1998 13:29:30 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List In recent discussion it's been pointed out that the gIFt chunk is slightly flawed in that transparency information can be lost under certain circumstances. I propose an additional "extensions" chunk: gIFa GIF Plain Text Extension with Alpha The gIFa chunk is identical to the gIFt chunk, except that the Text Foreground Color and Text Background Color fields are 4-byte RGBA quads instead of 3-byte RGB triples. The alpha value represents transparency with respect to what is on the display when the gIFt chunk is read (i.e. the application's background shows through when gIFa precedes IDAT, and the main PNG image shows through when gIFa follows IDAT). The use of gIFt is deprecated when either the foreground color or the background color is transparent. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 13:21:12 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 NAA22783 for ; Tue, 25 Aug 1998 13:21:12 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA10315; Tue, 25 Aug 1998 13:19:16 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA10311; Tue, 25 Aug 1998 13:19:14 -0500 Received: from marine.sonic.net by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA04293; Tue, 25 Aug 98 13:20:48 CDT Received: (qmail 30269 invoked from network); 25 Aug 1998 18:20:05 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 25 Aug 1998 18:20: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 LAA10690; Tue, 25 Aug 1998 11:19:12 -0700 X-Envelope-Info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA21805; Tue, 25 Aug 1998 11:19:13 -0700 Date: Tue, 25 Aug 1998 11:19:13 -0700 Message-Id: <199808251819.LAA21805@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn wrote: > I propose an additional "extensions" chunk: > gIFa GIF Plain Text Extension with Alpha My reaction to this is divided: on the one hand, it fixes a long-standing problem and should have been how the original gIFt chunk was designed. On the other hand, no one even noticed the problem in practice--it was only when I got around to writing the chapter on PNG extensions, with relatively detailed descriptions of each and every registered chunk, that *I* noticed it, and I convinced myself that it wasn't worth bothering about. To recap my reasoning: there is no obvious and reasonable standard--in terms of implementation size and universality--for font info. The two most likely general-purpose candidates are PostScript and TrueType/free- type, but both are arguably unreasonable requirements for a PNG decoder that just wants to deal with a single ancillary chunk. An alternative would be to define a specific font and include it and some basic display code in libpng. Reportedly the only widely supported font from the GIF days was the 8x8 IBM CGA font; one could incorporate or design a similar fixed-width, 8x8 font and standardize on that. (One might wish to add a 7x14 or 8x16 font, too; the former is a common xterm font, and the latter is the standard VGA font, I think. I don't know what the copyright issues are in either case.) But to do so would basically be an acknowledgment that the GIF text-chunk is fundamentally underspecified, and this current proposal doesn't address that. I do think that a well-supported method of overlaying text on an image without actually encoding the bitmapped characters is a good idea and would be very handy for anyone who wishes to include a copyright or a title or whatever. But such a chunk should probably be critical and should not include the name "gif" in its name; I would suggest TEXT or GTXT instead. 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 has no prayer of being accepted. > The use of gIFt is deprecated when either the foreground > color or the background color is transparent. You're speaking of the GIF foreground/background, I assume? Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 13:49: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 NAA23079 for ; Tue, 25 Aug 1998 13:49:45 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA11096; Tue, 25 Aug 1998 13:46:35 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA11092; Tue, 25 Aug 1998 13:46:34 -0500 Received: from marine.sonic.net by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA04356; Tue, 25 Aug 98 13:48:08 CDT Received: (qmail 31424 invoked from network); 25 Aug 1998 18:47:26 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 25 Aug 1998 18:47:26 -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 LAA20789 for ; Tue, 25 Aug 1998 11:46:33 -0700 X-Envelope-Info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA23044 for png-list@ccrc.wustl.edu; Tue, 25 Aug 1998 11:46:34 -0700 Date: Tue, 25 Aug 1998 11:46:34 -0700 Message-Id: <199808251846.LAA23044@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn wrote: > Right, it is not ambiguous. If the TextBackgroundColor is transparent, > then it is transparent with respect to whatever is on the screen, > which would be the main PNG image, if gIFt follows IDAT, and would > be the application's background, if gIFt comes first or if it overlays > a transparent part of the main PNG image. I'm not sure that's implied by the GIF spec; my impression was that the text stuff is always an overlay on top of the main image. > But there are circumstances > where the transparency information about the RGB colors in gIFt can > be lost or become ambiguous (when the original GIF contains a separate > GCE for the PlainText rendering block, with a different transparent color > than that of the main GIF image rendering block, for instance). I don't see how that's ambiguous; if the PlainText block has its own GCE, then that's what defines the RGBt values for its foreground and background colors. >>I found the problem a couple of months ago while writing the chapter on >>miscellaneous chunks, and I never brought it up because it seems clear to >>me that there's no way around it except to define a new gIFt chunk (with >>a different name, obviously--GIFT or GTXT would make the most sense). >>Since no one has complained about the current one, it didn't seem worth >>bothering with. > Not critical chunks. Maybe gTXt or gIFa (GIF text with alpha) or > tXTo (text overlay). A simple GIF conversion chunk is fine as an ancillary chunk, since the text overlay is ignored by 99% of all GIF decoders anyway. But if we're going to go back and define a real text overlay chunk, it had better be critical or it's a waste of everyone's time. If I'm going to use such a thing to store my displayable copyright or author info on the image, I want to be damn sure that the decoder isn't going to ignore it. (If I can't be sure of that--speaking as a content creator--the whole thing is pointless.) And if my entire image *is* the text, then either display it or give up, but don't throw up a blank background square and pretend like you've done the job. > I think it's worth bothering with because some GIFs can't be converted > absolutely losslessly to PNG (why leave that objection open, even if > few if any such GIFs exist?) and because it's easy to fix by defining > a new ancillary extension chunk that's exactly like gIFt except > that TextForegroundColor and TextBackgroundColor are RGBA instead of RGB. I don't see that there's a serious objection there: if someone wants an absolutely, unarguably lossless GIF conversion, they can define their own private, gIFt-like chunk to do it. That's lossless. Any argument about lack of application support of a private chunk went out the window three years ago; nobody supports gIFa, either (and, for that matter, I very much doubt that anyone supports gIFt, although I obviously don't know for sure). Also, *if* the chunk is to be a simple GIF conversion aid, there's no reason for the four four-byte text-grid values. Those are all two bytes in the GIF spec, and there are plenty of other PNG things that are only two bytes wide. > That way, gif->png would create gIFa, and png->gif would create a GCE plus > PlainText block. Right now, gif->png will create gIFt, but png->gif > only creates the PlainText block, leaving it to rely on the main image's > GCE, which might be wrong. Arguably we don't care that much about the other direction; if we did, there would never have been RGB or alpha or 16-bit grayscale support in PNG. OK, yes, in principle it would be nice to do GIF -> PNG -> GIF and get exactly the same thing back out. In principle it would be nice to do that with animated GIFs, too. Basically I see the gIFa quick-fix as a solution in search of a problem. A real method of storing text as text but having it show up as part of the image would probably be worth doing, IMHO, but gIFa is both too little and too much. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 15:04:47 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 PAA23877 for ; Tue, 25 Aug 1998 15:04:46 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12535; Tue, 25 Aug 1998 15:01:50 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12531; Tue, 25 Aug 1998 15:01:46 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA12125; Tue, 25 Aug 1998 16:01:38 -0400 Message-Id: <1.5.4.32.19980825195728.00f9be60@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, 25 Aug 1998 15:57:28 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 11:46 AM 8/25/98 -0700, you wrote: >Glenn wrote: > >> Right, it is not ambiguous. If the TextBackgroundColor is transparent, >> then it is transparent with respect to whatever is on the screen, >> which would be the main PNG image, if gIFt follows IDAT, and would >> be the application's background, if gIFt comes first or if it overlays >> a transparent part of the main PNG image. > >I'm not sure that's implied by the GIF spec; my impression was that the >text stuff is always an overlay on top of the main image. I interpret it this way: a PlainText extension is a rendering block. An image is a rendering block. Rendering blocks are rendered in the order they appear in the GIF stream. > >> But there are circumstances >> where the transparency information about the RGB colors in gIFt can >> be lost or become ambiguous (when the original GIF contains a separate >> GCE for the PlainText rendering block, with a different transparent color >> than that of the main GIF image rendering block, for instance). > >I don't see how that's ambiguous; if the PlainText block has its own >GCE, then that's what defines the RGBt values for its foreground and >background colors. It's not ambiguous in the GIF. But the information can be lost in the PNG because there is only one transparent color, namely the transparent color defined in the GCE associated with the main image. > >>>I found the problem a couple of months ago while writing the chapter on >>>miscellaneous chunks, and I never brought it up because it seems clear to >>>me that there's no way around it except to define a new gIFt chunk (with >>>a different name, obviously--GIFT or GTXT would make the most sense). >>>Since no one has complained about the current one, it didn't seem worth >>>bothering with. > >> Not critical chunks. Maybe gTXt or gIFa (GIF text with alpha) or >> tXTo (text overlay). > >A simple GIF conversion chunk is fine as an ancillary chunk, since the >text overlay is ignored by 99% of all GIF decoders anyway. But if we're >going to go back and define a real text overlay chunk, it had better be >critical or it's a waste of everyone's time. If I'm going to use such >a thing to store my displayable copyright or author info on the image, >I want to be damn sure that the decoder isn't going to ignore it. (If >I can't be sure of that--speaking as a content creator--the whole thing >is pointless.) >And if my entire image *is* the text, then either display >it or give up, but don't throw up a blank background square and pretend >like you've done the job. This is possible, too. A GIF containing only a PlainText extension and a palette (no image block) would be a legal GIF. A new public critical chunk will be a hard sell, though, even if it's in the extensions document and not in the core. What about putting such a chunk in MNG? Not that we want to be complicating MNG right now, either. But then you'd be able to overlay text on either an underlying PNG, JNG, or over a background area that doesn't have any image at all. Call it TXTO for "text overlay". > >> I think it's worth bothering with because some GIFs can't be converted >> absolutely losslessly to PNG (why leave that objection open, even if >> few if any such GIFs exist?) and because it's easy to fix by defining >> a new ancillary extension chunk that's exactly like gIFt except >> that TextForegroundColor and TextBackgroundColor are RGBA instead of RGB. > >I don't see that there's a serious objection there: if someone wants an >absolutely, unarguably lossless GIF conversion, they can define their own >private, gIFt-like chunk to do it. That's lossless. Any argument about >lack of application support of a private chunk went out the window three >years ago; nobody supports gIFa, either (and, for that matter, I very much >doubt that anyone supports gIFt, although I obviously don't know for sure). > >Also, *if* the chunk is to be a simple GIF conversion aid, there's no >reason for the four four-byte text-grid values. Those are all two bytes >in the GIF spec, and there are plenty of other PNG things that are only >two bytes wide. Obviously someone was thinking ahead. > >> That way, gif->png would create gIFa, and png->gif would create a GCE plus >> PlainText block. Right now, gif->png will create gIFt, but png->gif >> only creates the PlainText block, leaving it to rely on the main image's >> GCE, which might be wrong. > >Arguably we don't care that much about the other direction; if we did, >there would never have been RGB or alpha or 16-bit grayscale support in >PNG. Waitaminute. No one is advocating arbitraryPNG->GIF, only PNGthatWasGIF->GIF. >OK, yes, in principle it would be nice to do GIF -> PNG -> GIF and >get exactly the same thing back out. In principle it would be nice to >do that with animated GIFs, too. > >Basically I see the gIFa quick-fix as a solution in search of a problem. Not really. You noticed the problem and gIFa is the solution to that problem. The problem only becomes important if people start wholesale conversion of GIF to PNG and don't want to lose transparency information about their text overlays. >A real method of storing text as text but having it show up as part of the >image would probably be worth doing, IMHO, but gIFa is both too little and >too much. Wouldn't a general-purpose TXTO look a lot like gIFa? Or would you want to be able to define fonts and angles as well? I'm not sure I like the way this is heading. A TXTO renderer could take a fair amount of code, if it needs to accomodate scalable fonts and arbitrary angles (or even if it only can do horizontal layout of a single font) Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 15:24:29 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 PAA24094 for ; Tue, 25 Aug 1998 15:24:29 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12922; Tue, 25 Aug 1998 15:22:30 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12918; Tue, 25 Aug 1998 15:22:15 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA13121; Tue, 25 Aug 1998 16:22:11 -0400 Message-Id: <1.5.4.32.19980825201801.00f95934@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, 25 Aug 1998 16:18:01 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 11:19 AM 8/25/98 -0700, you wrote: >Glenn wrote: >> The use of gIFt is deprecated when either the foreground >> color or the background color is transparent. > >You're speaking of the GIF foreground/background, I assume? I was speaking of the GIF TextForeground/Background. Whether the main image has a transparent area or not is irrelevant if we're going to slap an opaque rectangle with text over it. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 15:26: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 PAA24125 for ; Tue, 25 Aug 1998 15:26:14 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12934; Tue, 25 Aug 1998 15:24:36 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12930; Tue, 25 Aug 1998 15:24:35 -0500 Received: from u33.CS.Berkeley.EDU by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA04528; Tue, 25 Aug 98 15:26:03 CDT Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA10103; Tue, 25 Aug 1998 13:24:23 -0700 (PDT) Date: Tue, 25 Aug 1998 13:24:23 -0700 (PDT) Message-Id: <199808252024.NAA10103@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: 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 > In recent discussion it's been pointed out that the gIFt chunk is > slightly flawed... Or maybe fundamentally flawed. Back in 1995 I paid no attention to the GIF conversion chunks. I just now skimmed the GIF 89a spec for the first time. (I found a copy at http://www.letters.com/~gray/docs/gifspecs/, someone tell me if there's a more official source) According to the GIF spec, the plain text extension is a graphic rendering block, just like an image. Therefore, a GIF file containing both an image and a plain text extension is a multi-image GIF. The GIF conversion chunks say that they're intended only for single-image GIFs. Whereas the PNG format is declarative ("this is how the image is"), GIF is procedural ("here is how to construct the image"). A GIF stream can contain multiple "graphic rendering blocks" (drawing instructions), each of which alters a rectangular region. These regions can overlap. If a GIF stream contains only a single instruction that draws a pixel array, we can convert it losslessly to PNG. The PNG extensions document punts on the question of how to convert a multi-image GIF to PNG, but I suppose the goal should be to create a PNG image that reflects the final state of the GIF decoding process. This is inherently a lossy process in the sense that it loses information about the procedure used to construct the final image. If the GIF stream contains only instructions that draw pixel arrays, the final state is a well-defined pixel array. But if it contains any plain text extensions (instructions that draw ASCII characters), the final state is not simply a pixel array, because the font is not specified. The final state is a superposition of the many pixels arrays that could result from the many possible fonts that could be used. In general, the final state is very complex and can be expressed only by the ordered procedure. For any two instructions that affect overlapping regions, we need to know which comes first. I think, if I were writing a multi-image-GIF to PNG converter, I'd choose fonts and draw the text into the image, and maybe also include the text in an ancillary chunk for indexing purposes. But if we want special handling for the case of a GIF stream containing one image and zero or more non-overlapping plain text extensions, then something like gIFt will work, but as people have pointed out, it should have used RGBA instead of RGB. I would not be opposed to a slight change to the extensions document. gIFt could become gIFa, or maybe gIFp, for Plain text extension. The foreground/background fields would grow to 4 bytes, and a note could be added saying "There is also a gIFt chunk, now deprecated, that is exactly like the gIFp chunk except that the foreground and background fields are only three bytes each (R, G, B samples)." Actually, a limited amount of overlapping between plain text extensions can be handled, because PNG preserves the order of ancillary chunks relative to IDAT and PLTE. The GIF stream can contain: plain text extensions, set A plain text extensions, set B image plain text extensions, set C where each set of plain text extensions is non-overlapping within itself, but possibly overlapping with members of the other sets. The PNG file would contain: gIFp set A PLTE gIFp set B IDAT gIFp set C AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 15:48: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 PAA24400 for ; Tue, 25 Aug 1998 15:48:22 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA13293; Tue, 25 Aug 1998 15:46:04 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA13289; Tue, 25 Aug 1998 15:46:03 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA14315; Tue, 25 Aug 1998 16:45:59 -0400 Message-Id: <1.5.4.32.19980825204150.00fa9e54@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, 25 Aug 1998 16:41:50 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 11:19 AM 8/25/98 -0700, you 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 has no prayer of being accepted. 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. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 16:15: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 QAA24696 for ; Tue, 25 Aug 1998 16:15:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14597; Tue, 25 Aug 1998 16:12:53 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14593; Tue, 25 Aug 1998 16:12:52 -0500 Received: from marine.sonic.net by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA04615; Tue, 25 Aug 98 16:14:27 CDT Received: (qmail 13810 invoked from network); 25 Aug 1998 21:13:44 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 25 Aug 1998 21:13:44 -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 OAA22201 for ; Tue, 25 Aug 1998 14:12:49 -0700 X-Envelope-Info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id OAA16188 for png-list@ccrc.wustl.edu; Tue, 25 Aug 1998 14:12:51 -0700 Date: Tue, 25 Aug 1998 14:12:51 -0700 Message-Id: <199808252112.OAA16188@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > I interpret it this way: a PlainText extension is a rendering block. > An image is a rendering block. Rendering blocks are rendered in > the order they appear in the GIF stream. OK, I didn't go reread the GIF89a spec, so I'll accept that there are probably two interpretations and that it is therefore ambiguous. > It's not ambiguous in the GIF. But the information can be lost in the > PNG because there is only one transparent color, namely the transparent > color defined in the GCE associated with the main image. Right. I'm not arguing that gIFt is correct; it isn't. It provides no reasonable way to do transparency at all, given that PNG palette colors aren't unique. My argument boils down to: no one who cares about GIF has complained, so there's no point in worrying about a quick fix right now. There may be many people who have yet to do wholesale conversion of their GIFs to PNGs, but I'd be willing to bet money that 99.99% of them have no GIFs with plain text and wouldn't know it if they did. If there were a web browser--ANY web browser--that supported the feature, then maybe it would be a potential issue that might come up in the next year or two, possibly almost maybe. > What about putting such a chunk in MNG? That's possibly a better way to handle it, yes, but as a PNG chunk it would still be available to MNG, and it would be handy in stand-alone PNG images, too. >>Also, *if* the chunk is to be a simple GIF conversion aid, there's no >>reason for the four four-byte text-grid values. Those are all two bytes >>in the GIF spec, and there are plenty of other PNG things that are only >>two bytes wide. > Obviously someone was thinking ahead. To what? There has never been any wording to indicate that a *PNG* decoder should bother with it; the gIFt chunk is even less descriptive than what's in the GIF89a spec. On the contrary, the mere fact that *the* most obvious, useful feature about text overlays--i.e., transparency--is missing indicates that someone wasn't thinking very hard about it. (I include myself in this criticism, since I apparently helped approve the chunk.) Don't get me wrong--for TEXT/GTXT/TXTO I would want 4-byte values, just like oFFs and IHDR and whatnot. But for a simple, throw-away GIF chunk-- which is basically what all four of them are, given the lack of decoder hints--a simple one-to-one mapping is more appropriate. > Wouldn't a general-purpose TXTO look a lot like gIFa? Yes, except that decoders would be required to honor it or bail, and authors could then depend on it. In other words, it would be well- specified. > Or would you > want to be able to define fonts and angles as well? I'm not sure I > like the way this is heading. A TXTO renderer could take a fair amount > of code, if it needs to accomodate scalable fonts and arbitrary angles > (or even if it only can do horizontal layout of a single font) No, that's precisely what I argued against--that implies PostScript or TrueType or the equivalent, and those are clearly overkill. But defining one or two fixed-width, bitmapped, Latin-1 fonts in the chunk spec--8x8 and 8x16, say--would be a reasonable and useful compromise, IMHO. They would have to be included in libpng as well, but I'd even volunteer to do that work if the chunk passed. Btw, I prefer "GTXT" for "graphical text." :-) (GLTN would also be OK, if we want to acknowledge the Western [Latin-1] bias.) Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 16:16: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 QAA24706 for ; Tue, 25 Aug 1998 16:16:23 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14613; Tue, 25 Aug 1998 16:15:07 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14609; Tue, 25 Aug 1998 16:15:04 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id RAA15838; Tue, 25 Aug 1998 17:14:19 -0400 Message-Id: <1.5.4.32.19980825211009.00faec28@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, 25 Aug 1998 17:10:09 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 01:24 PM 8/25/98 -0700, you wrote: >> In recent discussion it's been pointed out that the gIFt chunk is >> slightly flawed... > >Or maybe fundamentally flawed. >If the GIF stream contains only instructions that draw pixel arrays, the >final state is a well-defined pixel array. But if it contains any plain >text extensions (instructions that draw ASCII characters), the final >state is not simply a pixel array, because the font is not specified. >The final state is a superposition of the many pixels arrays that could >result from the many possible fonts that could be used. This is an important observation. There are consequences in, for example, use of such PNGs in MNG (I think MNG can deal with it, though, because only the IDAT data and not the final picture is used in delta operations). > >In general, the final state is very complex and can be expressed only by >the ordered procedure. For any two instructions that affect overlapping >regions, we need to know which comes first. > >I think, if I were writing a multi-image-GIF to PNG converter, I'd >choose fonts and draw the text into the image, and maybe also include >the text in an ancillary chunk for indexing purposes. It'd be a bigger file than the original GIF, though. But you'd be sure it would be rendered properly even with viewers that don't recognize or process gIFt. > >But if we want special handling for the case of a GIF stream containing >one image and zero or more non-overlapping plain text extensions, then >something like gIFt will work, but as people have pointed out, it should >have used RGBA instead of RGB. Actually zero or more images is legal, if I'm reading the GIF spec right; but such GIFs could not be converted to PNG, which must have at least one image. A zero-image GIF could, however, be converted to a legal MNG, if the gIFt (or its successor) chunk were available at the top MNG level. > >I would not be opposed to a slight change to the extensions document. >gIFt could become gIFa, or maybe gIFp, for Plain text extension. The >foreground/background fields would grow to 4 bytes, and a note could >be added saying "There is also a gIFt chunk, now deprecated, that is >exactly like the gIFp chunk except that the foreground and background >fields are only three bytes each (R, G, B samples)." > >Actually, a limited amount of overlapping between plain text extensions >can be handled, because PNG preserves the order of ancillary chunks >relative to IDAT and PLTE. The GIF stream can contain: > > plain text extensions, set A > plain text extensions, set B > image > plain text extensions, set C > >where each set of plain text extensions is non-overlapping within >itself, but possibly overlapping with members of the other sets. The >PNG file would contain: > > gIFp set A > PLTE > gIFp set B > IDAT > gIFp set C The only problem is that (I suppose) the gIFp sets are all going to occur after IDAT, because the author probably intends for people to be able to see them. A virtually unlimited amount of overlapping could be handled if the gIFp chunk included a 4-byte (or even 2-byte) sequence number. Or if it's made critical. Something not noted in the extensions document, but can be inferred from the GIF89a document, is that the oFFs chunk does not affect the position of gIFt; gIFt positions are relative to the Logical Screen. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 16:37: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 QAA24931 for ; Tue, 25 Aug 1998 16:37:02 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA15196; Tue, 25 Aug 1998 16:35:40 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA15192; Tue, 25 Aug 1998 16:35:39 -0500 Received: from marine.sonic.net by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA04677; Tue, 25 Aug 98 16:37:13 CDT Received: (qmail 14692 invoked from network); 25 Aug 1998 21:36:32 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 25 Aug 1998 21:36:32 -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 OAA31172 for ; Tue, 25 Aug 1998 14:35:37 -0700 X-Envelope-Info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id OAA17266 for png-list@ccrc.wustl.edu; Tue, 25 Aug 1998 14:35:37 -0700 Date: Tue, 25 Aug 1998 14:35:37 -0700 Message-Id: <199808252135.OAA17266@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >> In recent discussion it's been pointed out that the gIFt chunk is >> slightly flawed... Adam wrote: > Or maybe fundamentally flawed. [multi-image interpretation, which I completely missed--kinda makes gIFt/gIFa as an ancillary chunk moot] Then again, the entire GIF spec is equally flawed from the PNG per- spective: you can have colormapped images with no colormap, and you can have pure palettes with no image. Both are legal GIFs and illegal PNGs. So I'd vote to forget all about any further GIF compatibility issues unless and until (1) MNG is stable and implemented or (2) someone who honestly needs to convert some oddball GIFs complains. I'm guessing item (2) will never occur. > Back in 1995 I paid no attention to the GIF conversion chunks. I just > now skimmed the GIF 89a spec for the first time. (I found a copy at > http://www.letters.com/~gray/docs/gifspecs/, someone tell me if there's > a more official source) See also http://www.wotsit.org/ . > If a GIF stream contains only a single instruction that draws a pixel > array, we can convert it losslessly to PNG. The PNG extensions document > punts on the question of how to convert a multi-image GIF to PNG, but > I suppose the goal should be to create a PNG image that reflects the > final state of the GIF decoding process. The list consensus, as I recall it, was to convert multi-image GIFs into multiple PNGs. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 16:43:37 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 QAA25019 for ; Tue, 25 Aug 1998 16:43:31 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA15365; Tue, 25 Aug 1998 16:41:59 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA15361; Tue, 25 Aug 1998 16:41:58 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id RAA17278; Tue, 25 Aug 1998 17:41:57 -0400 Message-Id: <1.5.4.32.19980825213748.00fb6440@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, 25 Aug 1998 17:37:48 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 02:12 PM 8/25/98 -0700, Greg wrote: >Btw, I prefer "GTXT" for "graphical text." :-) (GLTN would also be OK, >if we want to acknowledge the Western [Latin-1] bias.) Do the reasons for our Latin-1 bias in tEXt/zTXt still exist? Should a GTXT chunk have a "charset" field? This gets more fun every minute. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 17:55: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 RAA25657 for ; Tue, 25 Aug 1998 17:55:58 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA17559; Tue, 25 Aug 1998 17:53:34 -0500 Received: from smtp1.xs4all.nl by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA17554; Tue, 25 Aug 1998 17:53:29 -0500 Received: from gerard1 (dc2-modem1128.dial.xs4all.nl [194.109.132.104]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id AAA02302 for ; Wed, 26 Aug 1998 00:53:27 +0200 (CEST) Message-Id: <199808252253.AAA02302@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: png-list@dworkin.wustl.edu Date: Wed, 26 Aug 1998 00:52:03 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: gIFt,gIFa,TXTO,GTXT,etc X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7BIT Just adding some late-nite comments. I think that the least amount of energy should be spent on this. Adding or changing special chunks for specific text-features is just going to complicate things beyond need. If it is only for GIF-conversion, keep it the way it is, as, like Greg says, there's no implementation of it where it really matters: eg. Web browsers. If someone would have a specific GIF-implementation and wants to convert to PNG they can come up with their own specific PNG-implementation of it. For the general use of PNG I see no merit in the gif-chunks. There could be use of a GTXT-chunk, but it depends on what the goal is. Is it simply to display a small copyright notice? Then it could even be rendered in the system's default font. Ok. it wouldn't look exactly the same on each and every computer. But does a copyright notice need to? If more is wanted, one could opt to implement it in a way that's consistent with CSS, but that would be like building a browser inside an image-format. Not the right way forward I would think. Just adding a limited amount of pre-defined fonts is like saying, "Ok, we want to offer text-overlays, but we can't offer too much..." And wouldn't all this be going the way of multiple-image format anyway? The only real gain of a separate text-chunk is that it creates smaller files. How much? A copyright-notice is usually for larger images, where the extra overhead of the text-chunk might actually be more than the savings in compression of the image data including the notice. And a text-chunk can be easier removed than embedded text! If used, such as in the well-known graphical buttons, it would probably save some space. But these are usually small anyway, and the authors will want to use specific fonts as well. So where's the gain? When CSS gets implemented correctly such buttons could be created with HTML: eg. a text-box with background-image. That way the image could be reused and a heap of time saved when loading the page, and also save server-storage for all the different buttons... Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 18:10: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 SAA25797 for ; Tue, 25 Aug 1998 18:10:55 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA17888; Tue, 25 Aug 1998 18:09:49 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA17884; Tue, 25 Aug 1998 18:09:48 -0500 Received: from worldnet.att.net ([12.77.197.99]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980825230946.NNGB27789@worldnet.att.net>; Tue, 25 Aug 1998 23:09:46 +0000 Message-ID: <35E342D3.EC9E010F@worldnet.att.net> Date: Tue, 25 Aug 1998 19:03:47 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu CC: Rich.Franzen@dba-sys.com Subject: [Fwd: nerd discovers "shadow soup" (or, "almost a cone")] Content-Type: multipart/mixed; boundary="------------AE54E89514857E6947541412" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List This is a multi-part message in MIME format. --------------AE54E89514857E6947541412 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit resent; first try on 22aug98.12:15 EST disappeared I apologize if you end up getting this message twice. PS: I downloaded and installed Netscape 4.06 this weekend. I also copied the HTML 4.0 spec to my computer. But either something is wrong with my Hitachi portable, or Netscape 4.06 cannot display certain pages of the spec. Has anyone else noticed this? -- Rich --------------AE54E89514857E6947541412 Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <35DEEEA1.A0BEC1B2@worldnet.att.net> Date: Sat, 22 Aug 1998 12:15:29 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List CC: Rich.Franzen@dba-sys.com, Nathan@geodetic.com Subject: Re: nerd discovers "shadow soup" (or, "almost a cone") References: <1.5.4.32.19980822102854.00f8e204@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Glenn Randers-Pehrson wrote (Sat, 22 Aug 1998 06:28:54 -0400): > > The human vision system is actually more sensitive at low levels > than at high levels. Your observations must be based on looking > at gamma-encoded images on a PC (or simply throwing data onto > the screen without gamma-decoding). It's true that *those* might > be trading off a little too much resolution in the bright areas > for resolution in the dark areas. Cure for that is to use a > gamma larger than 1/2.2, as is done on Macs and SGIs (but still > less than 1.0). The Florida programmer is multiplying the (explicit > or implicit) 1/2.2 gamma transform by another two-piece linear transform > that has a discontinuity in the middle. > > Glenn > Chris Lilley wrote (Wed, 19 Aug 1998 23:41:04 +0200): > > ... > > It means that many bits are wasted at the darker end of the color space, > because the eye can increasingly resolve hue and saturation levels as > brightness increases. So at the dark end, many colors with different bit > patterns will be the same visual color, wasting bits (and there are > precious few to begin with). This is taken care of in his proposal for > pure black, which is the bottom end cap (1024 colors all the same, > black) so he does some clever things with these when intensity is 0. But > he allocates 6 bits for intensity (64 levels) so when intensity is 1, 2 > etc all 1024 colors on that intensity slice are the same visually and so > on (as you go up in intensity you can see more distinct colors, > eventually at or near full intensity you can see all 1024 distinct > colors in that slice). > > ... > Ok, I'm confused. Maybe Glenn is just telling me that the 70 intensities should be spread evenly, without a "discontinuity in the middle". (My page currently states that the first 15 intensities occupy the low 25% of the brightness range, and the remaining 55 intensities (including the 7 new intensity levels) occupy the upper 75%.) But if this discontinuity is problematic, then, heck, spread all 70 intensities evenly across the brightness range. Since png-16 represents a display-space and not an analytical space, should the brightness of the static colors be pre-modified with gamma as Glenn seems to suggest? My initial thought was to keep them linear, but there is nothing that would require this. I thank you all for your ideas and comments. Nothing is fixed in stone yet, and I'm definately not averse to making sensible modifications. It was because of Chris' feedback that "shadow soup" was even discovered. Now it's not just with intensity 0 that I'm doing some "clever things"; intensities 1 thru 7 have now been cleverated ("cleverized?", "clevered?") as well. My choice was to expand the number of discrete intensities rather than the number of hue/sat variations. (Chris, except for the bottom eight intensities, this is 900 (60 * 15) not 1024.) The number of hues have already been doubled by allocating 6 bits to hue rather than 5 (as my original, unpublished, overview said). Intuition tells me that the eye will be more forgiving to "missing" colors than "missing" intensities. What do you think? -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq/png16.html#shadowSoup --------------AE54E89514857E6947541412-- -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 18:13: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 SAA25846 for ; Tue, 25 Aug 1998 18:13:39 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA18020; Tue, 25 Aug 1998 18:12:47 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA18016; Tue, 25 Aug 1998 18:12:46 -0500 Received: from worldnet.att.net ([12.77.197.99]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980825231246.NOPK27789@worldnet.att.net>; Tue, 25 Aug 1998 23:12:46 +0000 Message-ID: <35E34386.A9AB0B09@worldnet.att.net> Date: Tue, 25 Aug 1998 19:06:47 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu CC: Rich.Franzen@dba-sys.com Subject: [Fwd: png-16 Technical Page] Content-Type: multipart/mixed; boundary="------------486644256982F516401EA5B0" Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List This is a multi-part message in MIME format. --------------486644256982F516401EA5B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit resent; first try on 23aug98.16:22 EST disappeared I apologize if you end up getting this message twice. -- Rich --------------486644256982F516401EA5B0 Content-Type: message/rfc822 Content-Disposition: inline Message-ID: <35E07A1D.A1FAB476@worldnet.att.net> Date: Sun, 23 Aug 1998 16:22:53 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List CC: Rich.Franzen@dba-sys.com Subject: png-16 Technical Page References: <199808201731.KAA04416@bolt.sonic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://home.att.net/~rocq/png16Tech.html This page is far from complete, but it is fleshed-out enough that it is worth showing to people. Maybe you will better be able to understand the png-16 construction in my mind. Note that even when complete, the page is _not_ the specification. It is a description-in-progress of the technical elements which at some later date will go into the spec. Any ideas, comments, and suggestions are welcome. (Even rotten tomatoes are ok; there are some birds outside this tree-house that would love them!) Now is the time to get it right! -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq --------------486644256982F516401EA5B0-- -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 18:29: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 SAA25944 for ; Tue, 25 Aug 1998 18:29:08 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA18380; Tue, 25 Aug 1998 18:25:58 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA18376; Tue, 25 Aug 1998 18:25:57 -0500 Received: from pedigree.cs.ubc.ca (pop.cs.ubc.ca) by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA04879; Tue, 25 Aug 98 18:27:31 CDT Received: from chaplin.cs.ubc.ca (davem@chaplin.cs.ubc.ca [142.103.9.32]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with SMTP id QAA24923 for ; Tue, 25 Aug 1998 16:25:45 -0700 (PDT) Date: Tue, 25 Aug 1998 16:25:45 -0700 (PDT) From: Dave Martindale Message-Id: <199808252325.QAA24923@pedigree.cs.ubc.ca> To: png-list@ccrc.wustl.edu Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >From my (perhaps curmudgeonly) point of view, a text overlay doesn't belong in a single-image file at all. >From the description of what's in the GIf89 spec, it sounds like the text is treated as a separate graphical object even there. So, why should PNG support it at all? MNG, with its multi-image support, should. But PNG doesn't support the equivalent of GIF animation. Why must it support text overlays? It seems much cleaner to me to say "PNG files contain one image". Period. No overlays of any kind. Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 20:28: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 UAA27043 for ; Tue, 25 Aug 1998 20:28:12 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA21129; Tue, 25 Aug 1998 20:24:26 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA21125; Tue, 25 Aug 1998 20:24:23 -0500 Received: from marine.sonic.net by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA05038; Tue, 25 Aug 98 20:25:57 CDT Received: (qmail 23637 invoked from network); 26 Aug 1998 01:25:16 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 26 Aug 1998 01:25:16 -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 SAA13757 for ; Tue, 25 Aug 1998 18:24:21 -0700 X-Envelope-Info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id SAA27668 for png-list@dworkin.wustl.edu; Tue, 25 Aug 1998 18:24:23 -0700 Date: Tue, 25 Aug 1998 18:24:23 -0700 Message-Id: <199808260124.SAA27668@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: Re: gIFt,gIFa,TXTO,GTXT,etc Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List First comment: I would not want to deal with GTXT or whatever until after PNG 1.1 is approved and off to the ISO. Right now it's a dis- traction we don't need. Second: Gerard made some very good points; I'll have to think about whether GTXT would still be useful as I semi-defined it. For me I think it might be, but obviously that's not a sufficient reason to go ahead with a public proposal. If anyone else has an opinion in favor of it, at least let *me* know. I probably won't bring it up again for quite some time, if ever. (I will vote against any new gIF* chunks, though.) Btw, note that GTXT is as much part of the image as IDAT is, as far as I'm concerned; it's simply a second piece of the compression method, if you wish. There are no multi-image issues here. (That's not the case with gIFt/gIFa, though--at least, it's arguable.) And it doesn't bother me to bias it in favor of Latin-1, either--there isn't any portable al- ternative. Sure, you can include UTF-8 text in a chunk, but I doubt there are a dozen machines on the planet that can render all possible Unicode characters, if indeed all possible ones are defined in the first place. Anyway, I'm inclined to let sleeping dogs lie w.r.t. this whole topic. Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 20:54: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 UAA27226 for ; Tue, 25 Aug 1998 20:54:02 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA21689; Tue, 25 Aug 1998 20:53:19 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA21685; Tue, 25 Aug 1998 20:53:16 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA28611; Tue, 25 Aug 1998 21:52:57 -0400 Message-Id: <1.5.4.32.19980826014847.010b1880@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, 25 Aug 1998 21:48:47 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFt,gIFa,TXTO,GTXT,etc Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 12:52 AM 8/26/98 +0100, you wrote: >Just adding some late-nite comments. >When CSS gets implemented correctly such buttons could be created >with HTML: eg. a text-box with background-image. That way the image >could be reused and a heap of time saved when loading the page, >and also save server-storage for all the different buttons... Also in MNG, you could have a nice reusable background image followed by a lot of text-boxes: MHDR BACK DEFI 1 IHDR IEND FRAM "Retry" GTXT <"Retry (R)"> FRAM "Abort" MOVE 1 1 GTXT <"Abort (A)"> FRAM "Fail" MOVE 1 1 GTXT <"Fail (F)"> FRAM "Toss" MOVE 1 1 GTXT <"Toss computer"> GTXT <"out the window (T)"> MEND And you could address the buttons as separate URLs: Details are still to be worked out exactly how you request a single FRAM out of a MNG, versus requesting an animation that begins with a named FRAM or SEEK chunk. Consult the W3C SMIL spec for ideas. Glenn [I think the "toss computer" idea was from TTanner.] -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 21:09: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 VAA27325 for ; Tue, 25 Aug 1998 21:09:07 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA21864; Tue, 25 Aug 1998 21:08:01 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA21860; Tue, 25 Aug 1998 21:08:00 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA29269; Tue, 25 Aug 1998 22:07:58 -0400 Message-Id: <1.5.4.32.19980826020348.010b6a14@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, 25 Aug 1998 22:03:48 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFt,gIFa,TXTO,GTXT,etc Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 06:24 PM 8/25/98 -0700, you wrote: >First comment: I would not want to deal with GTXT or whatever until >after PNG 1.1 is approved and off to the ISO. Right now it's a dis- >traction we don't need. > >Second: Gerard made some very good points; I'll have to think about >whether GTXT would still be useful as I semi-defined it. For me I think >it might be, but obviously that's not a sufficient reason to go ahead >with a public proposal. If anyone else has an opinion in favor of it, >at least let *me* know. I probably won't bring it up again for quite >some time, if ever. (I will vote against any new gIF* chunks, though.) I would vote for an "upgraded" gIFt (gIFp or whatever) that is simply gIFt with RGBA colors, along with "deprecating" gIFt. I would vote against any critical GTXT or similar in PNG, and would think very hard before voting for *any* new critical chunk in PNG. It looks as though GTXT could find a place in MNG, though, and it's not too late to be adding or subtracting critical chunks from MNG, and it doesn't affect the ISO process. Keeps Gerard off the streets, but otherwise there isn't a whole lot of legacy code to worry about yet. The main thing I'm concerned about is the complexity of GTXT. We would need to find the right balance, somewhere between Truetype/PostScript with arbitrary angles and sizes and a single 8x8 or 8x16 fixed horizontal font. >Btw, note that GTXT is as much part of the image as IDAT is, as far as >I'm concerned; it's simply a second piece of the compression method, if >you wish. There are no multi-image issues here. I think that'd only be true if we specify and provide a single font (or choice of fonts where the image *author* makes the choice) -- which I think is what you have in mind. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Tue Aug 25 21:23:47 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 VAA27439 for ; Tue, 25 Aug 1998 21:23:46 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA22204; Tue, 25 Aug 1998 21:22:56 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id VAA22200; Tue, 25 Aug 1998 21:22:55 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id WAA30011; Tue, 25 Aug 1998 22:22:52 -0400 Message-Id: <1.5.4.32.19980826021842.010bd1a0@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, 25 Aug 1998 22:18:42 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 04:25 PM 8/25/98 -0700, you wrote: >>From my (perhaps curmudgeonly) point of view, a text overlay doesn't >belong in a single-image file at all. > >>From the description of what's in the GIf89 spec, it sounds like the >text is treated as a separate graphical object even there. So, why >should PNG support it at all? MNG, with its multi-image support, >should. But PNG doesn't support the equivalent of GIF animation. >Why must it support text overlays? I don't know of any decoder that does. The motivation was to be able to convert single-image GIFs, losslessly, to PNG and back again. It was only really apparent to me today that the text overlay is really a separate image (rendering block, in GIF spec's terminology). I don't know what the rest of us were thinking way back when, but for one thing there wasn't a MNG format where we *could* put such things. Now, I agree with you that MNG is a much better place for text overlays. The structure for managing the association of an overlay with a particular image, and managing overlays that happen to overlap, is already there. Plus, we don't have too much legacy code to worry about, yet, so there's not so much of a problem making the chunk critical. >It seems much cleaner to me to say "PNG files contain one image". >Period. No overlays of any kind. No argument there. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 03:38: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 DAA00361 for ; Wed, 26 Aug 1998 03:38:33 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA27120; Wed, 26 Aug 1998 02:31:32 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA27116; Wed, 26 Aug 1998 02:31:31 -0500 Received: from buffy.graphicswiz.com by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA05409; Wed, 26 Aug 98 02:31:30 CDT Date: Wed, 26 Aug 98 02:31:23 CDT Message-Id: <9808260731.AA05409@wuccrc.ccrc.wustl.edu> Received: (qmail 6525 invoked from network); 26 Aug 1998 07:29:36 -0000 Received: from sally.internal.graphicswiz.com (10.10.10.3) by buffy.graphicswiz.com with SMTP; 26 Aug 1998 07:29:36 -0000 Received: (qmail 27526 invoked from network); 26 Aug 1998 07:29:35 -0000 Received: from katie.internal.graphicswiz.com (HELO katie) (10.10.10.250) by sally.internal.graphicswiz.com with SMTP; 26 Aug 1998 07:29:35 -0000 X-Sender: pschmidt@mail X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: pschmidt@photodex.com (Paul Schmidt) Subject: Re: gIFT chunk and transparency Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >>>From the description of what's in the GIf89 spec, it sounds like the >>text is treated as a separate graphical object even there. So, why >>should PNG support it at all? MNG, with its multi-image support, >>should. But PNG doesn't support the equivalent of GIF animation. >>Why must it support text overlays? > >I don't know of any decoder that does. The motivation was to >be able to convert single-image GIFs, losslessly, to PNG and >back again. It was only really apparent to me today that >the text overlay is really a separate image (rendering block, >in GIF spec's terminology). I don't know what the rest >of us were thinking way back when, but for one thing there >wasn't a MNG format where we *could* put such things. I know of and have written graphics processors that handle GIF89a text overlays and do it "Properly", but they're so mind-bendingly rare as to be heartily ignored. I've only seen about 18 pictures in my life that use GIF's text overlays, and most of them were created just to see what they looked like by the hardcore CompuServe users (these were programmers, like Bob Barry, author of CSHOW for DOS). I am not aware of a single actual practical application requiring them. I would even go so far as to go ahead and say that a GIF-alternative format is 100% compatible even if it didn't support this feature. That's how obscure it is. I respectfully motion to drop the notion of any official GIF-esque text overlay support in PNG. Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1106 Clayton Lane #200W AOL: Photodex Photodex Austin, TX 78723 CIS: Photodex 74774,3635 (512)406-3020 Voice (512)452-6825 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 06:14: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 GAA01342 for ; Wed, 26 Aug 1998 06:14:16 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id EAA29617; Wed, 26 Aug 1998 04:32:02 -0500 Received: from smtp1.xs4all.nl by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id EAA29613; Wed, 26 Aug 1998 04:31:49 -0500 Received: from gerard1 (dc2-modem1130.dial.xs4all.nl [194.109.132.106]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id KAA28908 for ; Wed, 26 Aug 1998 10:53:11 +0200 (CEST) Message-Id: <199808260853.KAA28908@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: png-list@dworkin.wustl.edu Date: Wed, 26 Aug 1998 10:51:30 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: gIFt,gIFa,TXTO,GTXT,etc In-reply-to: <1.5.4.32.19980826014847.010b1880@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7BIT > Date: Tue, 25 Aug 1998 21:48:47 -0400 > From: Glenn Randers-Pehrson > Also in MNG, you could have a nice reusable background image followed > by a lot of text-boxes: > > MHDR > BACK > DEFI 1 > IHDR > > IEND > FRAM "Retry" > GTXT <"Retry (R)"> > FRAM "Abort" > MOVE 1 1 > GTXT <"Abort (A)"> > FRAM "Fail" > MOVE 1 1 > GTXT <"Fail (F)"> > FRAM "Toss" > MOVE 1 1 > GTXT <"Toss computer"> > GTXT <"out the window (T)"> > MEND > > And you could address the buttons as separate URLs: > > > > Details are still to be worked out exactly how you request > a single FRAM out of a MNG, versus requesting an animation > that begins with a named FRAM or SEEK chunk. Consult the > W3C SMIL spec for ideas. I would suggest SEEK chunks are more in order for requesting a specific FRAM (or sequence of FRAM's) from an external source. But we're still discussing a GTXT chunk with lots of text-processing overhead. The browser would be more appropriate to handle that stuff, as it's been designed to do so. Naturally it's a lot easier for people if they can simply create a single file (MNG) that contains it all, but is that worth the overhead? *MNGeye* hasn't got much of a problem with lots of text-features (fonts,sizes,angles) as Windows can do most of the work for it. But I suspect other platforms may require too much code, just to handle a bit of text. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 09:47: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 JAA03212 for ; Wed, 26 Aug 1998 09:47:24 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA05619; Wed, 26 Aug 1998 09:45:51 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA05615; Wed, 26 Aug 1998 09:45:51 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us) by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA00234; Wed, 26 Aug 98 09:47:23 CDT 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 KAA28755 for ; Wed, 26 Aug 1998 10:45:45 -0400 (EDT) To: PNG List Subject: Re: gIFa chunk proposal In-Reply-To: Your message of Tue, 25 Aug 1998 14:35:37 -0700 <199808252135.OAA17266@bolt.sonic.net> Date: Wed, 26 Aug 1998 10:45:45 -0400 Message-Id: <28753.904142745@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Greg Roelofs writes: > The list consensus, as I recall it, was to convert multi-image GIFs into > multiple PNGs. As I recall, the goal was to be able to convert single-image (meaning one-image, not zero-image ;-)) GIFs into PNG. We postponed the problem of multiple-image GIFs for MNG. I don't remember whether we recognized that GIFs containing one image plus plain text blocks would have to be treated as multi-image in some situations. But in short, the current discussion certainly deals with problems that are outside PNG's sphere. If Glenn wants to support this stuff in MNG, it's OK with me. (But I notice that we have yet to hear from anyone who's actually trying and failing to convert such files.) regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 11:13: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 LAA03928 for ; Wed, 26 Aug 1998 11:13:33 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA07726; Wed, 26 Aug 1998 11:11:42 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA07722; Wed, 26 Aug 1998 11:11:41 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa06921; 26 Aug 98 12:09 EDT Message-ID: <35E4333B.93FBE88@alumni.rpi.edu> Date: Wed, 26 Aug 1998 12:09:31 -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: gIFa chunk proposal References: <28753.904142745@sss.pgh.pa.us> 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 Tom Lane wrote: > > Greg Roelofs writes: > > The list consensus, as I recall it, was to convert multi-image GIFs into > > multiple PNGs. > > But in short, the current discussion certainly deals with problems > that are outside PNG's sphere. If Glenn wants to support this stuff > in MNG, it's OK with me. (But I notice that we have yet to hear > from anyone who's actually trying and failing to convert such files.) > > regards, tom lane I agree that the discussion of GTXT is outside the sphere of PNG, and is still speculation with regard to MNG. But the discussion of gIFa/gIFp is about fixing a broken PNG chunk. Anyone who *does* try to convert files with transparent text blocks is bound to fail, because text blocks can have their own GCE and we are combining information from all GCEs into identification of a single transparent palette index. We are also (as Adam pointed out) losing the ordering information about multiple text blocks. These can be fixed (I think) by defining gIFp that is like gIFt but with RGBA entries instead of RGB, and with a sequence number to guarantee that the rendering blocks are done in the right order (or placed in the right order when the file is converted back to GIF). Such a sequence numbering would have to assign a number to the IDAT as well (although it obviously wouldn't appear in the IDAT, but would leave a gap in the gIFp sequence numbers): When converting a GIF to PNG with GIF PNG Text Block A gIFp A Text Block B gIFp B Image PLTE, IDAT Text Block C gIFp C Text Block D gIFp D The sequence numbers would be A:0; B:1; C:3; D:4. The gIFg and gIFx chunks are likewise broken, in that the original order in the GIF can be lost. This is ugly, but, the sequence numbers that I've just proposed should probably be global sequence numbers within the three GIF chunk types: GCE A Text Block A GCE B Text Block B GCE for image Image GCE C Text Block C GCE D TExt Block D The sequence numbers would be GCE A: 0; TextBlock A: 1; GCE B: 2: TextBlock B: 3; GCE for image: 4; GCE C: 6; TextBlock C: 7; GCE D: 8; TextBlock D: 9. Without such sequencing, it's impossible to guarantee that the GIF will be reassembled in the right order. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 12:44:20 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 MAA04610 for ; Wed, 26 Aug 1998 12:44:19 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09526; Wed, 26 Aug 1998 12:42:33 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09522; Wed, 26 Aug 1998 12:42:29 -0500 Received: from u33.CS.Berkeley.EDU by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA00623; Wed, 26 Aug 98 12:42:19 CDT Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id KAA10828; Wed, 26 Aug 1998 10:41:59 -0700 (PDT) Date: Wed, 26 Aug 1998 10:41:59 -0700 (PDT) Message-Id: <199808261741.KAA10828@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: 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 Glenn Randers-Pehrson says: > The gIFg and gIFx chunks are likewise broken, in that the original > order in the GIF can be lost. Hey, you're right--I hadn't looked at the other GIF conversion chunks. So basically, all of the gIF* chunks are broken, and it's taken us three years to notice. I'm inclined to say, "Oops, this was a bad idea, forget we ever said anything about these gIF* chunks. PNG is backward compatible with GIF87a plus the transparency feature of GIF89a, but not the animation capability of GIF89a, nor any of the other features introduced in GIF89a which no one uses anyway." AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 12:48: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 MAA04660 for ; Wed, 26 Aug 1998 12:48:35 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09743; Wed, 26 Aug 1998 12:47:10 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09739; Wed, 26 Aug 1998 12:47:09 -0500 Received: from pedigree.cs.ubc.ca (pop.cs.ubc.ca) by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA00630; Wed, 26 Aug 98 12:47:06 CDT 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 KAA28418 for ; Wed, 26 Aug 1998 10:47:02 -0700 (PDT) X-Sender: davem@mail.cs.ubc.ca Message-Id: In-Reply-To: <199808261741.KAA10828@u33.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Aug 1998 10:47:29 -0700 To: PNG List From: Dave Martindale Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >So basically, all of the gIF* chunks are broken, and it's taken us three >years to notice. I'm inclined to say, "Oops, this was a bad idea, >forget we ever said anything about these gIF* chunks. PNG is backward >compatible with GIF87a plus the transparency feature of GIF89a, but >not the animation capability of GIF89a, nor any of the other features >introduced in GIF89a which no one uses anyway." That seems by far the cleanest way of handling this. Dave -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 12: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 MAA04711 for ; Wed, 26 Aug 1998 12:56:10 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09905; Wed, 26 Aug 1998 12:54:48 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA09901; Wed, 26 Aug 1998 12:54:47 -0500 Received: from sophia.inria.fr by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA00639; Wed, 26 Aug 98 12:54:35 CDT Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id TAA04579; Wed, 26 Aug 1998 19:54:29 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-02.nice.iway.fr [194.98.49.66] claimed to be w3.org Message-Id: <35E44C20.A197A4E@w3.org> Date: Wed, 26 Aug 1998 19:55:44 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr Mime-Version: 1.0 To: PNG List Subject: Re: gIFa chunk proposal References: <199808261741.KAA10828@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: > > Glenn Randers-Pehrson says: > > > The gIFg and gIFx chunks are likewise broken, in that the original > > order in the GIF can be lost. > > Hey, you're right--I hadn't looked at the other GIF conversion chunks. Nor had anyone else, it seems, oe=r noticed the lack > So basically, all of the gIF* chunks are broken, and it's taken us three > years to notice. I'm inclined to say, "Oops, this was a bad idea, > forget we ever said anything about these gIF* chunks. PNG is backward > compatible with GIF87a plus the transparency feature of GIF89a, but > not the animation capability of GIF89a, nor any of the other features > introduced in GIF89a which no one uses anyway." I regard that as an eminently sensible suggestion for PNG. -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 14:39:12 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 OAA05417 for ; Wed, 26 Aug 1998 14:39:12 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA12260; Wed, 26 Aug 1998 14:34:10 -0500 Received: from mail2.microsoft.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA12256; Wed, 26 Aug 1998 14:34:08 -0500 Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Wed, 26 Aug 1998 12:34:08 -0700 Message-ID: <71F299426E8CCF11B05600805F6809DF023B015F@CUP-01-MSG> From: John Bowler To: PNG List Subject: RE: gIFa chunk proposal Date: Wed, 26 Aug 1998 12:33:10 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List From: amc@cs.berkeley.edu [mailto:amc@cs.berkeley.edu] >Glenn Randers-Pehrson says: > >> The gIFg and gIFx chunks are likewise broken, in that the original >> order in the GIF can be lost. > >Hey, you're right--I hadn't looked at the other GIF conversion chunks. > >So basically, all of the gIF* chunks are broken, and it's taken us three >years to notice. I'm inclined to say, "Oops, this was a bad idea, >forget we ever said anything about these gIF* chunks. PNG is backward >compatible with GIF87a plus the transparency feature of GIF89a, but >not the animation capability of GIF89a, nor any of the other features >introduced in GIF89a which no one uses anyway." Here is what I do: 1) Can the GIF be converted losslessly? No if any of the following apply: a) More than one graphic rendering block b) No "table based image data" c) There is a NetScape loop extension These tests are such that the PNG will render exactly the same as the original GIF, except that a GIF with a global color table which does not match the (single image) local color table will probably change (some code does use the global palette to set up the color table, some does not, some GIFs contain global palettes which are totally broken.) 2) If the GIF cannot be converted losslessly produce a representative PNG (the code I have to do this cannot handle the plain text extension, it just outputs the first bitmap), embed the whole GIF - PNG is just being used as a container for the GIF for backward compatibility reasons. 3) If the GIF can be converted (by the above test) then write a PNG with an image which matches the logical screen size. If the image does not cover the logical screen the background is filled with the transparent pixel value if there is one otherwise the background pixel. [This is the issue which caused me to say earlier that the GIF spec is ambiguous in this area - it isn't clear what to do if there is a global color table, applications seem to have responded to this by writing 255 regardless of whether or not this is a legal value.] Unrecognized application extensions are written as gIFx chunks and the order with with respect to other unrecognized chunks, the image and the GCE chunk is preserved. The GCE information is written as a gIFg chunk. The result is a PNG which renders in the same way as the GIF would render (at least when I render it :-) and which can be used to reconstruct a GIF which has the same property. The second GIF will have an image descriptor which matches the logical screen and will have a local color table (no global table). So far as I am concerned gIFg and gIFx are essential for PNG, gIFt is not useful. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 15:12: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 PAA05685 for ; Wed, 26 Aug 1998 15:12:16 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12904; Wed, 26 Aug 1998 15:09:15 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA12900; Wed, 26 Aug 1998 15:09:14 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa10998; 26 Aug 98 16:08 EDT Message-ID: <35E46B2D.FF5F63AF@alumni.rpi.edu> Date: Wed, 26 Aug 1998 16:08: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: gIFa chunk proposal References: <199808261741.KAA10828@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: > > Glenn Randers-Pehrson says: > > > The gIFg and gIFx chunks are likewise broken, in that the original > > order in the GIF can be lost. > > Hey, you're right--I hadn't looked at the other GIF conversion chunks. > > So basically, all of the gIF* chunks are broken, and it's taken us three > years to notice. Well, *we* are probably not a good representative sample of people who are interested in GIF. At least I know that I'm not. But I think we owe it to our public to fix what we now know is broken. It does not look very hard to do. I would rather fix them than disown them. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 15:23: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 PAA05768 for ; Wed, 26 Aug 1998 15:23:36 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA13125; Wed, 26 Aug 1998 15:21:48 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA13121; Wed, 26 Aug 1998 15:21:47 -0500 Received: from u33.CS.Berkeley.EDU by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA00887; Wed, 26 Aug 98 15:21:41 CDT Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA11075; Wed, 26 Aug 1998 13:21:39 -0700 (PDT) Date: Wed, 26 Aug 1998 13:21:39 -0700 (PDT) Message-Id: <199808262021.NAA11075@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: 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 John Bowler says: > So far as I am concerned gIFg and gIFx are essential for PNG, gIFt is > not useful. The second half of your GIF -> PNG -> GIF conversion relies on the ordering of ancillary chunks. Would you like new chunks to be defined that are like gIFg and gIFx but with sequence numbers, or would you rather ignore the problem? AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 16:36: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 QAA06397 for ; Wed, 26 Aug 1998 16:36:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14406; Wed, 26 Aug 1998 16:23:10 -0500 Received: from mail2.microsoft.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14402; Wed, 26 Aug 1998 16:23:09 -0500 Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Wed, 26 Aug 1998 14:23:09 -0700 Message-ID: <71F299426E8CCF11B05600805F6809DF023B0198@CUP-01-MSG> From: John Bowler To: PNG List Subject: RE: gIFa chunk proposal Date: Wed, 26 Aug 1998 14:23:02 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List From: amc@cs.berkeley.edu [mailto:amc@cs.berkeley.edu] >John Bowler says: > >> So far as I am concerned gIFg and gIFx are essential for PNG, gIFt is >> not useful. > >The second half of your GIF -> PNG -> GIF conversion relies on the >ordering of ancillary chunks. Would you like new chunks to be defined >that are like gIFg and gIFx but with sequence numbers, or would you >rather ignore the problem? I'd much rather ignore it - the convertion is, effectively, a streaming operation, I wouldn't want to have to re-order chunks because it would hit performance (and the convertion is a performance critical operation in my case.) Apart from the ones I am producing I've never seen a single image GIF with multiple "unknown" application extensions - so I don't think it will be a problem. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 16:47: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 QAA06556 for ; Wed, 26 Aug 1998 16:47:07 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14743; Wed, 26 Aug 1998 16:34:12 -0500 Received: from pop03.globecomm.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id QAA14739; Wed, 26 Aug 1998 16:34:07 -0500 Received: from briline08.bri.net.au (briline08.bri.net.au [203.16.176.188]) by pop03.globecomm.net (8.9.0/8.8.0) with ESMTP id RAA08034 for ; Wed, 26 Aug 1998 17:34:01 -0400 (EDT) From: "Will Wilson" Organization: Private User Date: 26 Aug 98 18:38:51 +0900 Subject: MNG voxel implementation X-Face: 1c.=Yt_ To: png-list@dworkin.wustl.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: MicroDot-II/AmigaOS NC 1.0 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7bit Hi, Could anyone give me a quick run down on MNG's voxel support. By defining support for altitude mapping does MNG simply outline the way in which the data is to be encoded or does it go further? Cheers, Will. -- ///// Will P Wilson \ lantic@mindless.com \\\\\ //// AKA lantic / #worms #amiga #fubar ICQ# - 14645518 \\\\ /// AMIGA 1200 030 \ FPU/MMU 50Mhz 33.6k 16Mb fast 2Mb chip FUBAR \\\ // (lantic : site) / http://www.bri.net.au/~lantic Updated 24.8.98 \\ / PiNG! PNG support \ http://www.bri.net.au/~lantic/ping.html 26.8.98 \ -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 17:51: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 RAA06895 for ; Wed, 26 Aug 1998 17:51:10 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA16474; Wed, 26 Aug 1998 17:36:49 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA16470; Wed, 26 Aug 1998 17:36:48 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id SAA06926; Wed, 26 Aug 1998 18:36:38 -0400 Message-Id: <1.5.4.32.19980826223227.00f9aef8@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, 26 Aug 1998 18:32:27 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: RE: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 02:23 PM 8/26/98 -0700, you wrote: >From: amc@cs.berkeley.edu [mailto:amc@cs.berkeley.edu] >>John Bowler says: >> >>> So far as I am concerned gIFg and gIFx are essential for PNG, gIFt is >>> not useful. >> >>The second half of your GIF -> PNG -> GIF conversion relies on the >>ordering of ancillary chunks. Would you like new chunks to be defined >>that are like gIFg and gIFx but with sequence numbers, or would you >>rather ignore the problem? > >I'd much rather ignore it - the convertion is, effectively, a streaming >operation, I wouldn't want to have to re-order chunks because it would hit >performance (and the convertion is a performance critical operation in my >case.) If it's a streaming operation, the chunks will be remaining in the right order, so there shouldn't be much of a performance hit; you'll look at the sequence number and say "yup, that's the one I was expecting". The problem is when someone interrupts the flow and edits the PNG before proceeding. > >Apart from the ones I am producing I've never seen a single image GIF with >multiple "unknown" application extensions - so I don't think it will be a >problem. That could very well be. I haven't looked at very many GIFs from a lot of different sources, so I don't know. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 18:04: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 SAA06957 for ; Wed, 26 Aug 1998 18:04:01 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA16711; Wed, 26 Aug 1998 17:49:50 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA16707; Wed, 26 Aug 1998 17:49:49 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id SAA07515; Wed, 26 Aug 1998 18:49:49 -0400 Message-Id: <1.5.4.32.19980826224538.00fa6264@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, 26 Aug 1998 18:45:38 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: MNG voxel implementation Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 06:38 PM 8/26/98 +0900, Will wrote: >Hi, > Could anyone give me a quick run down on MNG's voxel support. By >defining support for altitude mapping does MNG simply outline the way >in which the data is to be encoded or does it go further? It doesn't much beyond storing them. You can use something like the Army High Performance Computing Center's freeware "bob" (Brick-o-bytes) program to view them. i.e., decode the file.mng into file.bob (which is a simple raw 3-d array of voxels) and then proceed. In addition, you can add text and scaling chunks that provide information about the data. e.g., if the voxels contained scaled physical measurements or predictions of density or temperature, you could use the "pCAL" chunk to recover those physical values. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 18:35: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 SAA07064 for ; Wed, 26 Aug 1998 18:35:07 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA17409; Wed, 26 Aug 1998 18:21:09 -0500 Received: from www10.w3.org by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA17403; Wed, 26 Aug 1998 18:21:08 -0500 Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by www10.w3.org (8.8.5/8.7.3) with ESMTP id TAA01159; Wed, 26 Aug 1998 19:20:59 -0400 (EDT) Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id BAA27182; Thu, 27 Aug 1998 01:20:55 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-22.nice.iway.fr [194.98.49.86] claimed to be w3.org Message-ID: <35E498AA.6C984BF1@w3.org> Date: Thu, 27 Aug 1998 01:22:18 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr MIME-Version: 1.0 To: png-group@w3.org Subject: Browser compositing of PNG 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 I added a new test page to check for compositing of alpha PNGs against the correct background. The test uses CSS to set the color of four table cells and the nn puts an alpha PNG in each. I have seen what the current crop of browsers for Win95/NT do with this, would be interested to hear of reports from other browsers. I know, its a torture test, the browser needs to implement CSS and implement PNG and do PNG alpha processing and pick up the correct color based on the CSS. It could be worse, I could animate the PNGs using CSS positioning and make them drift across the screen ... FWIW changing this to use HTML to set the background colors didn't improve things. http://www.w3.org/Graphics/PNG/inline-alpha-table.html -- 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 19:50: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 TAA07347 for ; Wed, 26 Aug 1998 19:50:40 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA18870; Wed, 26 Aug 1998 19:45:05 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA18858; Wed, 26 Aug 1998 19:45:04 -0500 Received: from worldnet.att.net ([12.77.197.145]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980827004504.OPUG14950@worldnet.att.net>; Thu, 27 Aug 1998 00:45:04 +0000 Message-ID: <35E4AAAD.B62F468B@worldnet.att.net> Date: Wed, 26 Aug 1998 20:39:09 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu CC: Rich.Franzen@dba-sys.com, hornak@medimage.com Subject: 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 I have a suggestion for png itself. It relates to the gc16 (grey with color) image type I will be including in png-16. ref: http://home.att.net/~rocq/png16Tech.html#gc16 It occurs to me that the same thing could be done in png. The only difference is that png would not bother with the possibility of embedded transparency levels. What gc16 offers is 15-bit greyscale plus 15 bit RGB. Because of the ordering of bits ( iiiiiiiiiiiiiii.1 (i15) rrrrr.ggggg.bbbbb.0 (rgb15) ) even 1.0 viewers could show the imagery effectively. I.e., they would only know about 16-bit greyscale. So when the pixel was grey, it would look right. However, if the pixel were color, the pixel would still be rendered coherently, but as if red were grey intensity. The current png solution of allowing simultaneous color and deep grey is to use 48-bit color. Scientists or doctors who may find it useful to have color in the same image with the contrast sensitivity offered by a 15-bit greyscale might find this much-smaller image format to be very useful. -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq/pngBase.html -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 22:06: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 WAA07860 for ; Wed, 26 Aug 1998 22:06:57 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id WAA22452; Wed, 26 Aug 1998 22:05:45 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id WAA22448; Wed, 26 Aug 1998 22:05:44 -0500 Received: from u33.CS.Berkeley.EDU by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA01766; Wed, 26 Aug 98 22:05:37 CDT Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id UAA12784; Wed, 26 Aug 1998 20:05:30 -0700 (PDT) Date: Wed, 26 Aug 1998 20:05:30 -0700 (PDT) Message-Id: <199808270305.UAA12784@u33.CS.Berkeley.EDU> To: png-list@dworkin.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 "Richard W. Franzen" says: > iiiiiiiiiiiiiii.1 (i15) > rrrrr.ggggg.bbbbb.0 (rgb15) > > The current png solution of allowing simultaneous color and deep grey > is to use 48-bit color. Scientists or doctors who may find it useful > to have color in the same image with the contrast sensitivity offered > by a 15-bit greyscale might find this much-smaller image format to be > very useful. I think the colored portion of the image is probably an overlay or annotation, and they probably want to preserve the high-precision grayscale information under it, so a multiple-image format would be more appropriate. I initially doubted the "much smaller" claim, thinking that compression would close the 3:1 ratio to near 1:1, but I tried it on one image and the final ratio was 2:1. I didn't have any 16-bit gray images lying around, so I generated one from a 24-bit color photo using: pnmdepth 65535 | ppmtopgm | pnmscale 0.707106781187 I generated the PNG files using: pnmtopng -compression 9 pgmtoppm rgb:ffff/ffff/ffff | pnmtopng -force -compression 9 AMC -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Wed Aug 26 23:13: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 XAA08244 for ; Wed, 26 Aug 1998 23:13:02 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA26314; Wed, 26 Aug 1998 23:11:52 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA26310; Wed, 26 Aug 1998 23:11:51 -0500 Received: from worldnet.att.net ([12.77.196.254]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980827041150.BAEA4228@worldnet.att.net>; Thu, 27 Aug 1998 04:11:50 +0000 Message-ID: <35E4DB23.1653F609@worldnet.att.net> Date: Thu, 27 Aug 1998 00:05:55 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List CC: hornak@medimage.com Subject: Re: suggestion for png 1.1: gc16 References: <199808270305.UAA12784@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: > "Richard W. Franzen" says: > > I think the colored portion of the image is probably an overlay or > annotation, and they probably want to preserve the high-precision > grayscale information under it, so a multiple-image format would be more > appropriate. > I probably am one of the "they". My company makes 12- and 16-bit greyscale film scanners. You want to know a secret? (shhh, don't tell anyone I told you this ;-) When you read the specs on the expensive 16-bit a-to-d chip we use, you find that it doesn't deliver 16 bits--it kind of delivers 15 1/2 bits. (I think it was designed by one of the Gallo brothers. You know, "we will deliver no bit before its time") Plus there are other unavoidable sources of digitization inaccuracy, such as calibration granularity, electronic noise, temperature of sensing element, etc. So using 15 bits of a 16-bit scanner (ours or anyone else's) isn't a loss of any real consequence. And if the data was from a 10-, 12-, or 14-bit source, then there is obviously no loss in going to 15 bits. Yes, right now, if there is color used with a deep-grey image, it probably is in an overlay plane. If you were writing an image-analysis plus enhancement program that used deep grey information, would you store the output in a 48-bit format or a 16-bit plus overlay format? Most x-rays that I have seen, both medical and NDT, have a lot of their area that is basically unused. There would be plenty of room to put additional graphics within the main image, without writing on top of useful scanned data. I'm saying let's offer the tools. Just because the natives of Papua New Guinea don't have the factories and tools to build Mazzariti's doesn't mean they wouldn't build and use them if the tools were available. > > I initially doubted the "much smaller" claim, thinking that compression > would close the 3:1 ratio to near 1:1, but I tried it on one image and > the final ratio was 2:1. > > I didn't have any 16-bit gray images lying around, so I generated one > from a 24-bit color photo using: > > pnmdepth 65535 | ppmtopgm | pnmscale 0.707106781187 > > I generated the PNG files using: > > pnmtopng -compression 9 > pgmtoppm rgb:ffff/ffff/ffff | pnmtopng -force -compression 9 > > AMC Maybe the dudes who wrote zlib knew what they were doing after all. ;-) There are some digitally generated 12- and 16-bit files at 'http://home.att.net/~rocq/pngLibrary.html'. My company will finally be getting a T-1 line in a few weeks, and when it is up, I plan to post some real-world scanned imagery at our ftp site 'ftp://ftp.dba-sys.com/pub'. -- Rich =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Franzen richf@dba-sys.com (work) Staff Scientist 407/727-0660 x2294 (voice) DBA Systems, Inc. 407/727-7019 (fax) 1200 S. Woody Burke Rd. http://www.dba-sys.com Melbourne, FL 32901 rocq@worldnet.att.net (home) http://home.att.net/~rocq -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 03:40: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 DAA09432 for ; Thu, 27 Aug 1998 03:40:58 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA00696; Thu, 27 Aug 1998 03:36:44 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA00692; Thu, 27 Aug 1998 03:36:44 -0500 Received: from mh.acorn.co.uk by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA01977; Thu, 27 Aug 98 03:36:37 CDT Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA06220 for ; Thu, 27 Aug 1998 09:36:34 +0100 (BST) Date: Thu, 27 Aug 1998 09:37:19 +0100 From: Kevin Bracey To: png-list@dworkin.wustl.edu Subject: Re: gIFa chunk proposal Message-Id: In-Reply-To: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40a for RISC OS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.60l Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List In message Dave Martindale wrote: > >So basically, all of the gIF* chunks are broken, and it's taken us three > >years to notice. I'm inclined to say, "Oops, this was a bad idea, > >forget we ever said anything about these gIF* chunks. PNG is backward > >compatible with GIF87a plus the transparency feature of GIF89a, but > >not the animation capability of GIF89a, nor any of the other features > >introduced in GIF89a which no one uses anyway." > > That seems by far the cleanest way of handling this. > Amen. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 08:40: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 IAA10402 for ; Thu, 27 Aug 1998 08:40:31 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA06309; Thu, 27 Aug 1998 08:38:06 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA06305; Thu, 27 Aug 1998 08:38:05 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA02446; Thu, 27 Aug 1998 09:38:04 -0400 Message-Id: <1.5.4.32.19980827133352.00997b38@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, 27 Aug 1998 09:33:52 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List >In message > Dave Martindale wrote: > >> >So basically, all of the gIF* chunks are broken, and it's taken us three >> >years to notice. I'm inclined to say, "Oops, this was a bad idea, >> >forget we ever said anything about these gIF* chunks. PNG is backward >> >compatible with GIF87a plus the transparency feature of GIF89a, but >> >not the animation capability of GIF89a, nor any of the other features >> >introduced in GIF89a which no one uses anyway." >> >> That seems by far the cleanest way of handling this. 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? It appears that there is a simple easy fix. 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. 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. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 08:54: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 IAA10536 for ; Thu, 27 Aug 1998 08:54:45 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA06523; Thu, 27 Aug 1998 08:53:18 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA06519; Thu, 27 Aug 1998 08:53:18 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us) by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA02168; Thu, 27 Aug 98 08:53:13 CDT 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 JAA02273 for ; Thu, 27 Aug 1998 09:53:12 -0400 (EDT) To: PNG List Subject: Re: gIFa chunk proposal In-Reply-To: Your message of Thu, 27 Aug 1998 09:33:52 -0400 <1.5.4.32.19980827133352.00997b38@netgsi.com> Date: Thu, 27 Aug 1998 09:53:12 -0400 Message-Id: <2271.904225992@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson writes: > 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? For political reasons, and no others. It was asserted (without much proof AFAIR) that we had to be able to claim that any GIF could be losslessly converted to PNG. Being able to make that claim for portions of the GIF spec that no one uses in practice is not a technical requirement, only a political/marketing one. >From the vantage point of three years later it's clear that our principal mistake w.r.t. GIF89 features was not to move more quickly on MNG so's we could replace animated GIFs. There was and is no demand whatever to support GIF plain text extension blocks. The reason no one has complained about the deficiencies of the gIF* chunks is that in three years *no one has used them*. And no one ever will, whether we "fix" them or not. (In fact, "fixing" them by making them more complex/harder to support only decreases the chances that they will ever be good for anything.) I think we are completely wasting our time even to be discussing these chunks, especially when there are much more pressing things to worry about. I'm for moving these chunks (as well as fRAc) into a "deprecated chunks" section of the extensions document. I suppose we can't deregister them entirely. regards, tom lane -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 09:15: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 JAA10740 for ; Thu, 27 Aug 1998 09:15:52 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA06961; Thu, 27 Aug 1998 09:14:38 -0500 Received: from wuccrc.ccrc.wustl.edu by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA06957; Thu, 27 Aug 1998 09:14:37 -0500 Received: from marine.sonic.net by wuccrc.ccrc.wustl.edu (4.1/ECL-A1.21) id AA02220; Thu, 27 Aug 98 09:14:32 CDT Received: (qmail 12145 invoked from network); 27 Aug 1998 14:15:30 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 27 Aug 1998 14:15:30 -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 HAA04202 for ; Thu, 27 Aug 1998 07:14:33 -0700 X-Envelope-Info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id HAA32737 for png-list@ccrc.wustl.edu; Thu, 27 Aug 1998 07:14:44 -0700 Date: Thu, 27 Aug 1998 07:14:44 -0700 Message-Id: <199808271414.HAA32737@bolt.sonic.net> From: Greg Roelofs To: png-list@ccrc.wustl.edu Subject: Re: gIFa chunk proposal Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List > 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? As Tom said, it was for political reasons; I'll add that "we" didn't design them, a subgroup of CompuServe-based programmers did (i.e., they had a strongly vested interest in doing so). If I'm not mistaken, Tim Wegner is the last vestige of that group who still has something to do with PNG, and he's been *very* quiet lately. And CompuServe has essentially abandoned GIF and disbanded their engineering depart- ment. John Bowler apparently does use the chunks, but the sequence issue doesn't seem to be a problem for him, and even he hasn't noticed the text-transparency problem. John, any thoughts? Fix or deprecate? > 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? My only technical comment is that chunks that are specifically and solely designed to convert GIF images/streams don't need PNG-like resolution--i.e., where GIF uses two-byte values, the PNG chunks should use two-byte values as well, not four-byte values. We're certainly not recommending that people design new PNG images around the GIF chunks, so the extra precision is just wasted space. But I don't consider that any more compelling than the sequencing or transparency problems. > 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. That's a valid point, but I would rather say that they're deprecated than have to talk about six of the damn things. :-) I do think that we cannot unregister an existing, specified chunk (note that I leave myself some weasel room for fRAc ;-) ) without setting a terrible precedent. And I'm willing to leave fRAc alone given your proposed wording (which most of the group haven't seen yet but soon will). Greg -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 09:29: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 JAA10844 for ; Thu, 27 Aug 1998 09:29:42 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA07337; Thu, 27 Aug 1998 09:28:34 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA07333; Thu, 27 Aug 1998 09:28:33 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa22138; 27 Aug 98 10:25 EDT Message-ID: <35E56C4B.B2B64A99@alumni.rpi.edu> Date: Thu, 27 Aug 1998 10:25:15 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu Subject: png-gifa-19980827 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 I've uploaded a proposal, png-gifa-19980827.html, png-gifa-19980827.txt, to ftp://swrinde.nde.swri.edu/pub/png-group/documents, for the purpose of discussion. It describes gIFa, gIFc, and gIFp, which are replacements for gIFx, gIFg, and gIFt, respectively, with sequence numbers, and RGBA colors in gIFp. Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 14: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 OAA15084 for ; Thu, 27 Aug 1998 14:30:04 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA14502; Thu, 27 Aug 1998 14:27:04 -0500 Received: from mail4.microsoft.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id OAA14498; Thu, 27 Aug 1998 14:27:03 -0500 Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 27 Aug 1998 12:27:03 -0700 Message-ID: <71F299426E8CCF11B05600805F6809DF023B029A@CUP-01-MSG> From: John Bowler To: PNG List Subject: RE: gIFa chunk proposal Date: Thu, 27 Aug 1998 12:27:00 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List From: Glenn Randers-Pehrson >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. Thinking about it I can't see a real need for the sequence numbers. GIF makes no statement about ordering/reordering on edit operations, so an application cannot rely on extension chunks coming in any particular order. It seems reasonable that an editor should not re-order extensions in such a way that they change relative position to graphic rendering blocks - but this is just the same as the ordering rule with respect to IDAT in PNG. gIFg must be ordered before the image, PNG guarantees this (ordering with respect to IDAT). My GIF reassembly code *always* places the GCE immediately before the image - so even if there was some way of preserving application extension/GCE ordering I would not be inclined to use it. Consequently I don't think new chunks should be defined (of course I have a significant commercial interest - I've got a lot of code written round the existing chunks :-) Use of gIFt in PNG should be discouraged - do any current PNG renderers handle it? John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 15:24: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 PAA15650 for ; Thu, 27 Aug 1998 15:24:13 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA15429; Thu, 27 Aug 1998 15:19:38 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id PAA15425; Thu, 27 Aug 1998 15:19:37 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa27520; 27 Aug 98 16:15 EDT Message-ID: <35E5BE71.48F69F63@alumni.rpi.edu> Date: Thu, 27 Aug 1998 16:15:45 -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: gIFa chunk proposal References: <71F299426E8CCF11B05600805F6809DF023B029A@CUP-01-MSG> 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 John Bowler wrote: > > gIFg must be ordered before the image, PNG guarantees this (ordering with > respect to IDAT). My GIF reassembly code *always* places the GCE > immediately before the image - so even if there was some way of preserving > application extension/GCE ordering I would not be inclined to use it. gIFg must be ordered before the rendering block to which it applies. That might be the image, or it might be a Plain Text rendering block. What would your code do with a GIF that contained GCE image block GCE Plain text extension block Would both gIFg chunks wind up ahead of IDAT? You can argue (and I would argue) that this is a multi-image GIF, even though it only has one image rendering block. But if this is a multi-image GIF, then *all* GIFs with Plain Text Blocks are multiple-image (except for those that don't contain an image rendering block, and those can't be converted to PNG) Glenn -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Thu Aug 27 17:22: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 RAA17044 for ; Thu, 27 Aug 1998 17:22:43 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA17947; Thu, 27 Aug 1998 17:20:50 -0500 Received: from mail4.microsoft.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id RAA17943; Thu, 27 Aug 1998 17:20:49 -0500 Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 27 Aug 1998 15:20:49 -0700 Message-ID: <71F299426E8CCF11B05600805F6809DF023B02F5@CUP-01-MSG> From: John Bowler To: PNG List Subject: RE: gIFa chunk proposal Date: Thu, 27 Aug 1998 15:20:46 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List From: Glenn Randers-Pehrson >John Bowler wrote: >> gIFg must be ordered before the image, PNG guarantees this (ordering with >> respect to IDAT). My GIF reassembly code *always* places the GCE >> immediately before the image - so even if there was some way of preserving >> application extension/GCE ordering I would not be inclined to use it. > >gIFg must be ordered before the rendering block to which it applies. >That might be the image, or it might be a Plain Text rendering block. > >What would your code do with a GIF that contained > > GCE > image block > GCE > Plain text extension block That fails my test for something I can losslessly round trip - there must be one rendering block and it must be "table based image data". By preference I won't convert such an image to PNG (even though the user has specified that PNG should be used), however if it is necessary (for compatibility with existing file formats) I produce a PNG which contains no gIF? chunks and contains the whole GIF wrapped up in an "msOG" chunk. >You can argue (and I would argue) that this is a multi-image GIF, >even though it only has one image rendering block. But if this >is a multi-image GIF, then *all* GIFs with Plain Text Blocks are >multiple-image (except for those that don't contain an image rendering >block, and those can't be converted to PNG) Right, this is what I believe. I think the GIF89a spec is totally unambiguous on this. John Bowler -- Send the message body "help" to png-list-request@dworkin.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Aug 28 06:38:51 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 GAA23046 for ; Fri, 28 Aug 1998 06:38:50 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id GAA03071; Fri, 28 Aug 1998 06:37:21 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id GAA03067; Fri, 28 Aug 1998 06:37:20 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id HAA15985; Fri, 28 Aug 1998 07:37:20 -0400 Message-Id: <1.5.4.32.19980828113308.00fa33ec@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, 28 Aug 1998 07:33:08 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: pngextensions-19980828 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List 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. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Fri Aug 28 08:29:12 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 IAA23970 for ; Fri, 28 Aug 1998 08:29:11 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA04971; Fri, 28 Aug 1998 08:27:38 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id IAA04967; Fri, 28 Aug 1998 08:27:37 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA19858; Fri, 28 Aug 1998 09:27:37 -0400 Message-Id: <1.5.4.32.19980828132325.00f9f240@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, 28 Aug 1998 09:23:25 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: pngextensions-19980828 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 07:33 AM 8/28/98 -0400, I 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. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 03:17:29 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 DAA04615 for ; Sat, 29 Aug 1998 03:17:29 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA26530; Sat, 29 Aug 1998 03:15:47 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id DAA26526; Sat, 29 Aug 1998 03:15:46 -0500 Received: from worldnet.att.net ([12.77.129.11]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980829081545.TWLF24506@worldnet.att.net>; Sat, 29 Aug 1998 08:15:45 +0000 Message-ID: <35E7B74B.844CF58F@worldnet.att.net> Date: Sat, 29 Aug 1998 04:09:47 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: png-list@dworkin.wustl.edu CC: Rich.Franzen@dba-sys.com Subject: color cycling 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 for a great headache, click below: http://home.att.net/~rocq/png16Tech.html#colorCycling -- Rich -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 09:59: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 JAA06999 for ; Sat, 29 Aug 1998 09:59:54 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA03440; Sat, 29 Aug 1998 09:58:49 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA03436; Sat, 29 Aug 1998 09:58:48 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id KAA03541; Sat, 29 Aug 1998 10:58:39 -0400 Message-Id: <1.5.4.32.19980829145427.0099e324@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, 29 Aug 1998 10:54:27 -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 08:05 PM 8/26/98 -0700, Adam wrote: >I initially doubted the "much smaller" claim, thinking that compression >would close the 3:1 ratio to near 1:1, but I tried it on one image and >the final ratio was 2:1. > >I didn't have any 16-bit gray images lying around, so I generated one >from a 24-bit color photo using: > > pnmdepth 65535 | ppmtopgm | pnmscale 0.707106781187 > >I generated the PNG files using: > > pnmtopng -compression 9 > pgmtoppm rgb:ffff/ffff/ffff | pnmtopng -force -compression 9 > >AMC I ran the same procedure on a collection of 23 color photos from ftp://ipl.rpi.edu/pub/images/still/KodakImages/color I also observed about 2:1 RGB16:GRAY16 (actually 2.15:1) However, when I ran both sets of results through pngcrush (default), the ratio was reduced to 1.38:1 RGB16:GRAY16 Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 11: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 LAA07532 for ; Sat, 29 Aug 1998 11:34:16 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA05343; Sat, 29 Aug 1998 11:33:21 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id LAA05339; Sat, 29 Aug 1998 11:33:20 -0500 Received: from worldnet.att.net ([12.77.197.122]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980829163319.XFUT24506@worldnet.att.net> for ; Sat, 29 Aug 1998 16:33:19 +0000 Message-ID: <35E82BE4.59DBAB73@worldnet.att.net> Date: Sat, 29 Aug 1998 12:27:16 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <1.5.4.32.19980829145427.0099e324@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 (at Sat, 29 Aug 1998 10:54:27 -0400): > At 08:05 PM 8/26/98 -0700, Adam wrote: > > >I initially doubted the "much smaller" claim, thinking that compression > >would close the 3:1 ratio to near 1:1, but I tried it on one image and > >the final ratio was 2:1. > > > >I didn't have any 16-bit gray images lying around, so I generated one > >from a 24-bit color photo using: > > > > pnmdepth 65535 | ppmtopgm | pnmscale 0.707106781187 > > > >I generated the PNG files using: > > > > pnmtopng -compression 9 > > pgmtoppm rgb:ffff/ffff/ffff | pnmtopng -force -compression 9 > > > >AMC > > I ran the same procedure on a collection of 23 color photos from > ftp://ipl.rpi.edu/pub/images/still/KodakImages/color > > I also observed about 2:1 RGB16:GRAY16 (actually 2.15:1) > > However, when I ran both sets of results through pngcrush (default), > the ratio was reduced to 1.38:1 RGB16:GRAY16 > > Glenn > 38% ? Still not bad for a 24-bit to 16-bit comparison -- better than the general size reduction of png over gif. I checked out the images (you had typo in ftp line, it should be: ftp://ipl.rpi.edu/pub/image/still/KodakImages/color ('image' not 'images')). They are .ras format (Sun Raster?), so I don't think they are 48 bits per pixel. The only existing, commonly supported format I know that offers deep-grey and true color is 48-bit png. Does anyone care to guess what the reduction ratio from this would be? (I don't have any 48-bit images floating around...) I'm not trying to be a smart-ass. 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. -- 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 Sat Aug 29 12:12: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 MAA07846 for ; Sat, 29 Aug 1998 12:12:09 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA05885; Sat, 29 Aug 1998 12:11:19 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA05881; Sat, 29 Aug 1998 12:11:18 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA07661; Sat, 29 Aug 1998 13:11:17 -0400 Message-Id: <1.5.4.32.19980829170704.00fa6580@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, 29 Aug 1998 13:07: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 12:27 PM 8/29/98 -0400, you wrote: >Glenn Randers-Pehrson wrote (at Sat, 29 Aug 1998 10:54:27 -0400): > 38% ? Still not bad for a 24-bit to 16-bit comparison -- better than >the general size reduction of png over gif. It's a 48-bit to 16-bit comparison. > ftp://ipl.rpi.edu/pub/image/still/KodakImages/color > >('image' not 'images')). They are .ras format (Sun Raster?), so I don't >think they are 48 bits per pixel. The only existing, commonly supported >format I know that offers deep-grey and true color is 48-bit png. Does >anyone care to guess what the reduction ratio from this would be? (I don't >have any 48-bit images floating around...) The .ras files are indeed 24-bit images. After converting them to PPM, I used Adam's procedure to make 16-bit grayscale images out of them. The ratios that I quoted were for 48-bit color (that actually contains three identical channels, R=G=B) and 16-bit gray. There is of course some risk in making conclusions about compression based on synthetic images. It would be better to take some existing real 16-bit gray images, make 48-bit PNGs out of them, and then compare the 16-bit PNGs with the 48-bit PNGs. I think that will also turn out to be on the order of 38 percent. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 12:41: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 MAA08010 for ; Sat, 29 Aug 1998 12:41:39 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA00641; Sat, 29 Aug 1998 12:40:26 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA00637; Sat, 29 Aug 1998 12:40:23 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA07898; Sat, 29 Aug 1998 13:19:01 -0400 Message-Id: <1.5.4.32.19980829171448.00fa9690@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, 29 Aug 1998 13:14:48 -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 12:27 PM 8/29/98 -0400, you 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"). 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. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 13:50: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 NAA08468 for ; Sat, 29 Aug 1998 13:50:42 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA01902; Sat, 29 Aug 1998 13:49:45 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA01898; Sat, 29 Aug 1998 13:49:44 -0500 Received: from worldnet.att.net ([12.77.197.122]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980829184943.MXN11152@worldnet.att.net> for ; Sat, 29 Aug 1998 18:49:43 +0000 Message-ID: <35E84BDD.FB136FE2@worldnet.att.net> Date: Sat, 29 Aug 1998 14:43:41 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <1.5.4.32.19980829171448.00fa9690@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: > At 12:27 PM 8/29/98 -0400, you wrote: > > > > 38% ? Still not bad for a 24-bit to 16-bit comparison -- better than > > the general size reduction of png over gif. > > It's a 48-bit to 16-bit comparison. > > > ftp://ipl.rpi.edu/pub/image/still/KodakImages/color > > > >('image' not 'images')). They are .ras format (Sun Raster?), so I don't > >think they are 48 bits per pixel. The only existing, commonly supported > >format I know that offers deep-grey and true color is 48-bit png. Does > >anyone care to guess what the reduction ratio from this would be? (I don't > > have any 48-bit images floating around...) > > The .ras files are indeed 24-bit images. After converting them to > PPM, I used Adam's procedure to make 16-bit grayscale images out of them. > The ratios that I quoted were for 48-bit color (that actually contains > three identical channels, R=G=B) and 16-bit gray. There is of course some > risk in making conclusions about compression based on synthetic images. > It would be better to take some existing real 16-bit gray images, > make 48-bit PNGs out of them, and then compare the 16-bit PNGs with > the 48-bit PNGs. I think that will also turn out to be on the order > of 38 percent. Glenn, I think I understand now. You began with 24-bit color images and, in a series of steps converted them to 16-bit grey, then 48-bit grey (r-g-b echoed 3 times). With no color in them, I'm surprised that the size differential is as big as 38%. > At 12:27 PM 8/29/98 -0400, you 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"). > > 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. > > Glenn > 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. I _know_ that it is verbotten to annotate on top of actual tissue-space!!! A mng overlay, as you suggest, would be a great way to allow the doctor to "grease-pencil" in all his little circles and arrows. Or imagine a large 70-micron image of a turbine blade with a suspected weld defect. The engineers have processed the image into pseudo-color, and reduced the effective resolution to 140 microns per pixel. They want to archive their study, and so they inset the color, processed image into the raw scanned image. Again, there was plenty of black area on the film in which to do the inset without writing over the blade itself. 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've been locked in a grey world for 10 years, and I want to see some yellow SUN!) -- Rich -- mailto:rfranzen@my-dejanews.com -- http://www.dejanews.com/group/dejanews.members.tech.rfranzen.png-16 -- http://home.att.net/~rocq/png16.html#gc16 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 20:49:49 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 UAA10873 for ; Sat, 29 Aug 1998 20:49:49 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA08891; Sat, 29 Aug 1998 20:48:52 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id UAA08887; Sat, 29 Aug 1998 20:48:51 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA24160; Sat, 29 Aug 1998 21:48:51 -0400 Message-Id: <1.5.4.32.19980830014440.0099ae44@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, 29 Aug 1998 21:44:40 -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 Without commenting on the merits of your gc16 proposal, I'd like to discuss *how* it could be implemented in PNG. I think defining a new color type, or enclosing the data in a new *HDR/IEND sequence would be counterproductive. This could be implemented more like the previously-proposed fALS and lOGE chunks, which amount to an ancillary chunk that defines an alternate way of interpreting a grayscale or gray-alpha image, while allowing decoders that don't recognize the chunk to display it as a regular grayscale image. e.g., grYc Gray with color 1 byte: method 0: interpret grayscale image according to the "gc16" proposal If the chunk is ignored, the deep-gray pixels will look ok, and the colored ones will also be gray, using the red channel as the most significant bits of gray and the remaining channels as noise (perhaps it would be better to store them as ggggg.rrrrr.bbbbb.f instead of rrrrr.ggggg.bbbbb.f, so that the most luminous channel, green, appears in the high bits). If the chunk is recognized and processed, the image will look exactly as the author intended. Gamma, sRGB, etc., processing must be done *after* the color samples have been separated. Alpha samples in a gray-alpha image must be interpreted in the usual manner, and are applied to all three color channels after they have been separated. BTW, messages on this topic are being mirrored in a Dejanews tech forum, fortunately with poster's addresses being given an anti-spam treatment. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sat Aug 29 23:21: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 XAA01201 for ; Sat, 29 Aug 1998 23:21:17 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA11220; Sat, 29 Aug 1998 23:20:10 -0500 Received: from mtiwmhc01.worldnet.att.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA11216; Sat, 29 Aug 1998 23:20:09 -0500 Received: from worldnet.att.net ([12.77.243.75]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with ESMTP id <19980830042008.GRXW11152@worldnet.att.net> for ; Sun, 30 Aug 1998 04:20:08 +0000 Message-ID: <35E8D14A.10CE4FA7@worldnet.att.net> Date: Sun, 30 Aug 1998 00:12:59 -0400 From: "Richard W. Franzen" X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <1.5.4.32.19980830014440.0099ae44@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: > Without commenting on the merits of your gc16 proposal, > I'd like to discuss *how* it could be implemented in PNG. > > I think defining a new color type, or enclosing the data > in a new *HDR/IEND sequence would be counterproductive. > > This could be implemented more like the previously-proposed > fALS and lOGE chunks, which amount to an ancillary chunk that defines > an alternate way of interpreting a grayscale or gray-alpha image, > while allowing decoders that don't recognize the chunk to display > it as a regular grayscale image. > > e.g., > > grYc Gray with color > 1 byte: method > 0: interpret grayscale image according to the > "gc16" proposal > > If the chunk is ignored, the deep-gray pixels will look ok, and > the colored ones will also be gray, using the red channel as > the most significant bits of gray and the remaining channels as noise > (perhaps it would be better to store them as ggggg.rrrrr.bbbbb.f instead > of rrrrr.ggggg.bbbbb.f, so that the most luminous channel, green, > appears in the high bits). > This approach is _exactly_ what was in my head also. I tried to say it in my first posting, but I don't know enough specsmanship yet to word it as well as you did. Thanks! As far as green coming first, it sounds like a good idea, and I certainly have no objection to it. Momentum with common speech and 24-bit RGB ordering was the only reason I suggested red first. Technically there is no decoding advantage to one ordering or another. (I may have to re-think the ordering of the mc16 image type in png-16 as well. I would want it to be consistent with gc16.) > > If the chunk is recognized and processed, the image will look exactly > as the author intended. > > Gamma, sRGB, etc., processing must be done *after* the color samples > have been separated. Alpha samples in a gray-alpha image must be > interpreted in the usual manner, and are applied to all three color > channels after they have been separated. > > BTW, messages on this topic are being mirrored in a Dejanews tech forum, > fortunately with poster's addresses being given an anti-spam treatment. > > Glenn > I guess I'm the one who should have stated this explicitly about the DejaNews reposting. As you can see/click below, there is a newsgroup (accessible only via DejaNews) that I have established for png-16. Unless there is any objection, I plan to repost to there any items on this mail-list that has to do with png-16. (Since gc16 is proposed for png-16 as well, it is "on topic" for the group.) Since all traffic to this mail-list is already being archived at a publicly accessible site, I didn't think there would be any legal problems. As Glenn says, when an e-mail address is part of what I mirror, I de-spamulate it ("fred:AT:flintstone.bc", for example). If you examine the stuff I have mirrored, you will see that I don't edit the mail to make me look better. BTW, membership at DejaNews is free. To read the "Forums" (their term for News groups) or do searches, you do not have to be a member, but to post new messages or replies, you do. From my perspective it's much better than, say, an "alt.graphics.png16" group because all messages will be accessible to everyone, instead of randomly appearing and disappearing at News hosts through-out the world. I don't know quite how long they archive for, but I've done searches and gotten News postings from back to 1996. -- 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 Sun Aug 30 04:04:29 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 EAA02348 for ; Sun, 30 Aug 1998 04:04:28 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id EAA16073; Sun, 30 Aug 1998 04:00:42 -0500 Received: from smtp3.xs4all.nl by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id EAA16069; Sun, 30 Aug 1998 04:00:40 -0500 Received: from gerard1 (dc2-isdn975.dial.xs4all.nl [194.109.151.207]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id LAA25948 for ; Sun, 30 Aug 1998 11:00:39 +0200 (CEST) Message-Id: <199808300900.LAA25948@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: png-list@ccrc.wustl.edu Date: Sun, 30 Aug 1998 10:59:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: suggestion for png 1.1: gc16 In-reply-to: <35E84BDD.FB136FE2@worldnet.att.net> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7BIT Hi Richard, Sorry I haven't been able to reply to some of your stuff lately, but I've been kind-a busy. There's a few things I'd like to comment on. Some of the features of your PNG-16 are actually already part of MNG. If such a thing were possible I would suggest to have a quick look through it's spec, but that would be like asking someone to read War and Peace in a day or so. 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. About the color-cycling (which actually almost gave me a headache...) I think we have it in MNG too. Perhaps a bit more complex than your proposal but it's in there. PPLT (partial palette) with delta-values. "Hello.mng" demonstrates it (rather poorly but I'm no graphics-designer...). This doesn't cover the entire design you propose, but it can do the flame-flickering and wave-movement. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Aug 30 18:30: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 SAA04681 for ; Sun, 30 Aug 1998 18:30:02 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA03187; Sun, 30 Aug 1998 18:28:58 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id SAA03183; Sun, 30 Aug 1998 18:28:56 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id TAA26586; Sun, 30 Aug 1998 19:28:56 -0400 Message-Id: <1.5.4.32.19980830232443.00fc7ef4@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, 30 Aug 1998 19:24:43 -0400 To: png-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: Re: pngextensions-19980828 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Greg wrote: >Two items, based on the PostScript version this time: > > - Under "Redundant equation types," the hyphen after sufficiently is > unnecessary. OK. Also in that paragraph, I'm setting "e", "exp()", and "pow()" in TT font. > > - The first bullet under {X0,X1} (~ next paragraph) is almost > incomprehensible-- > 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." Not quite. It's a botched cut-and-paste operation from Todd French's message of 26 Jan 1997. I'm removing "and second, as a way to label a limited range image" which restores the original sense of Todd's message. > >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. :-) ) I've got my master copy in sync with Adam's 1.2.3 proposal. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Sun Aug 30 23:26: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 XAA05696 for ; Sun, 30 Aug 1998 23:26:19 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA07867; Sun, 30 Aug 1998 23:25:17 -0500 Received: from m1.dejanews.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id XAA07863; Sun, 30 Aug 1998 23:25:16 -0500 Received: from x2.dejanews.com (ix2.dejanews.com [10.2.1.193]) by m1.dejanews.com (8.8.5/8.8.5) with ESMTP id XAA13470 for ; Sun, 30 Aug 1998 23:25:17 -0500 Received: (from www@dejanews.com) by x2.dejanews.com (8.7.6/8.6.12) id XAA23835; Sun, 30 Aug 1998 23:25:15 -0500 Message-Id: <199808310425.XAA23835@x2.dejanews.com> From: rfranzen@my-dejanews.com To: png-list@ccrc.wustl.edu Subject: Re: suggestion for png 1.1: gc16 Date: Mon, 31 Aug 1998 04:25:15 GMT Newsgroups: dejanews.members.tech.rfranzen.png-16 NNTP-Posting-Host: 12.77.129.110 Organization: Deja News - The Leader in Internet Discussion References: <6s9av3$p95$1@nnrp1.dejanews.com> <6sbru3$i7l$1@nnrp1.dejanews.com> X-Article-Creation-Date: Mon Aug 31 04:25:15 1998 GMT X-Http-Proxy: 1.0 x2.dejanews.com:80 (Squid/1.1.22) for client 12.77.129.110 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 <6sbru3$i7l$1@nnrp1.dejanews.com>, rfranzen@my-dejanews.com wrote: > Subject: Re: suggestion for png 1.1: gc16 > Date: Sun, 30 Aug 1998 10:59:46 +0100 > From: "Gerard Juyn" > To: png-list@ccrc.wustl.edu > > Hi Richard, > > Sorry I haven't been able to reply to some of your stuff lately, but > I've been kind-a busy. There's a few things I'd like to comment on. Hi, Gerard. No problem. Things are changing constantly on my pages, so the longer you wait, the more mature the png-16 concept will be. (Still, I like the ongoing feedback!) > Some of the features of your PNG-16 are actually already part of MNG. > If such a thing were possible I would suggest to have a quick look > through it's spec, but that would be like asking someone to read War > and Peace in a day or so. 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". > 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. > About the color-cycling (which actually almost gave me a headache...) > I think we have it in MNG too. Perhaps a bit more complex than your > proposal but it's in there. PPLT (partial palette) with delta-values. > "Hello.mng" demonstrates it (rather poorly but I'm no > graphics-designer...). This doesn't cover the entire design you > propose, but it can do the flame-flickering and wave-movement. > > Gerard (gjuyn:At:xs4all.nl) > http://www.3-t.com 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". I had looked at 'Hello.mng', but didn't notice the color cycling until now. It's breathing! ;-) In the intel-pc world, there have not been a lot of graphic tools that support color cycling. (Deluxe Paint was an exception, but it was ported from the Amiga.) So don't feel bad about not being an artist; even if you were, until programs come out that really support mng and pn6, then drawing with color-cycled colors will be high-tech and user unfriendly. (That's one of the reasons I chose to allow 8-bit images to be inset into a png-16 image--the easiest way to show off color-cycling is to convert a bunch of images from the Amiga and build mosaic's around them. Now I just need a good, complete iff library for Unix, pc's and mac's...) Let me back up to 'gc16' again. I'm hoping that it can become a part of the 1.1 spec because then it will be available for general use in a short time span. Who knows when msOffice, PhotoShop, et.al. will fully support mng and pn6? Of course some of us will hack the Netscape source to make sure the capability exists in that realm, but the problem will be getting into the hands of most users the "enhanced" Netscape. -- 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 PS: http://home.att.net/~rocq/images/pn6Logo.png <-- what do you think? -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 02:24:37 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 CAA06405 for ; Mon, 31 Aug 1998 02:24:37 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA10625; Mon, 31 Aug 1998 02:23:20 -0500 Received: from marine.sonic.net by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id CAA10621; Mon, 31 Aug 1998 02:23:19 -0500 Received: (qmail 21983 invoked from network); 30 Aug 1998 22:24:13 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 30 Aug 1998 22:24:13 -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 PAA10400 for ; Sun, 30 Aug 1998 15:23:09 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id PAA19736 for png-list@dworkin.wustl.edu; Sun, 30 Aug 1998 15:23:38 -0700 Date: Sun, 30 Aug 1998 15:23:38 -0700 Message-Id: <199808302223.PAA19736@bolt.sonic.net> From: Greg Roelofs To: png-list@dworkin.wustl.edu Subject: PNG spec and 32K sliding window Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List In the PNG 1.0 spec, the description of the IHDR chunk and the first line of the chapter on Deflate/Inflate Compression both talk about a 32K sliding window (i.e., exactly 32K). Elsewhere in the Deflate/Inflate chapter it says that "an LZ77 sliding window size of not more than 32K" is allowed. (libpng also allows the user to set the window to a smaller value when encoding, via the png_set_compression_window_bits() function.) I think both places should be clarified to say a "32K (or smaller) sliding window." The Deflate/Inflate chapter should also state explicitly that encoders may use a window smaller than 32K but no larger (and always a power of two), and that decoders must accept any power-of-two window size up to and including 32K. Greg -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 04:04: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 EAA06890 for ; Mon, 31 Aug 1998 04:04:10 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id EAA12795; Mon, 31 Aug 1998 04:01:42 -0500 Received: from smtp3.xs4all.nl by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id EAA12791; Mon, 31 Aug 1998 04:01:41 -0500 Received: from gerard1 (dc2-isdn998.dial.xs4all.nl [194.109.151.230]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id LAA25131 for ; Mon, 31 Aug 1998 11:01:40 +0200 (CEST) Message-Id: <199808310901.LAA25131@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: png-list@ccrc.wustl.edu Date: Mon, 31 Aug 1998 11:00:48 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: suggestion for png 1.1: gc16 In-reply-to: <199808310425.XAA23835@x2.dejanews.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List Content-Transfer-Encoding: 7BIT > 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 sigle 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@xs4all.nl) http://www.3-t.com -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 07:18:20 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 HAA07415 for ; Mon, 31 Aug 1998 07:18:19 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA15958; Mon, 31 Aug 1998 07:16:37 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id HAA15954; Mon, 31 Aug 1998 07:16:37 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA14051; Mon, 31 Aug 1998 08:16:37 -0400 Message-Id: <1.5.4.32.19980831121223.00fb1e84@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, 31 Aug 1998 08:12:23 -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 >> 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 -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 09:04:29 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 JAA08055 for ; Mon, 31 Aug 1998 09:04:28 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA17579; Mon, 31 Aug 1998 09:02:19 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id JAA17575; Mon, 31 Aug 1998 09:02:18 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id KAA17794; Mon, 31 Aug 1998 10:02:16 -0400 Message-Id: <1.5.4.32.19980831135802.00fa6a78@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, 31 Aug 1998 09:58:02 -0400 To: PNG List From: Glenn Randers-Pehrson Subject: Re: PNG 1.1 proposal draft 1.2.2 Sender: owner-png-list@ccrc.wustl.edu Precedence: bulk Reply-To: PNG List At 07:05 PM 8/15/98 -0700, Adam wrote: >I have incorporated the recent comments into the PNG 1.1 proposal. >Draft 1.2.2 is available from: > >http://www.cs.berkeley.edu/~amc/png/ > >The remaining unresolved issues are: > * 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. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 12:06: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 MAA09496 for ; Mon, 31 Aug 1998 12:06:06 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA21055; Mon, 31 Aug 1998 12:03:48 -0500 Received: from sophia.inria.fr by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA21051; Mon, 31 Aug 1998 12:03:47 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id OAA25329; Sun, 30 Aug 1998 14:57:23 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-18.nice.iway.fr [194.98.49.82] claimed to be w3.org Message-ID: <35E94C88.D0CF273B@w3.org> Date: Sun, 30 Aug 1998 14:58:48 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <1.5.4.32.19980829171448.00fa9690@netgsi.com> <35E84BDD.FB136FE2@worldnet.att.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 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 12:06: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 MAA09502 for ; Mon, 31 Aug 1998 12:06:08 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA21060; Mon, 31 Aug 1998 12:03:49 -0500 Received: from sophia.inria.fr by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id MAA21056; Mon, 31 Aug 1998 12:03:48 -0500 Received: from w3.org by sophia.inria.fr (8.8.8/8.8.5) with ESMTP id OAA25043; Sun, 30 Aug 1998 14:46:26 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host max1-18.nice.iway.fr [194.98.49.82] claimed to be w3.org Message-ID: <35E949F8.8EDE3A0A@w3.org> Date: Sun, 30 Aug 1998 14:47:52 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr MIME-Version: 1.0 To: PNG List Subject: Re: suggestion for png 1.1: gc16 References: <1.5.4.32.19980829171448.00fa9690@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: > > 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@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)492 387 987 06902 Sophia Antipolis Cedex, France -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 13:40: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 NAA10183 for ; Mon, 31 Aug 1998 13:40:25 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA23007; Mon, 31 Aug 1998 13:38:41 -0500 Received: from tiu.arl.mil by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA23002; Mon, 31 Aug 1998 13:38:39 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa12376; 31 Aug 98 14:33 EDT Message-ID: <35EAEC5D.2DD153DB@alumni.rpi.edu> Date: Mon, 31 Aug 1998 14:33:01 -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: <1.5.4.32.19980829171448.00fa9690@netgsi.com> <35E84BDD.FB136FE2@worldnet.att.net> <35E94C88.D0CF273B@w3.org> 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 Chris Lilley wrote: > > 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. Have you seen the grYc chunk proposal that I posted yesterday? It's backwards compatible. I'll post it as a formal proposal when I get time (but I presently plan to vote against it because I think the MNG solution is far superior.) > > > (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)? > Well, faLT only got two votes when I attempted to get it registered last year. And faLT is a better chunk than grYc. Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 13: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 NAA10279 for ; Mon, 31 Aug 1998 13:52:42 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA23236; Mon, 31 Aug 1998 13:51:07 -0500 Received: from u33.CS.Berkeley.EDU by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id NAA23232; Mon, 31 Aug 1998 13:51:02 -0500 Received: (from amc@localhost) by u33.CS.Berkeley.EDU (8.8.3/8.8.2) id OAA14487; Thu, 27 Aug 1998 14:54:14 -0700 (PDT) Date: Thu, 27 Aug 1998 14:54:14 -0700 (PDT) Message-Id: <199808272154.OAA14487@u33.CS.Berkeley.EDU> To: png-list@ccrc.wustl.edu Subject: 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 John Bowler says: > GIF makes no statement about ordering/reordering on edit operations, > so an application cannot rely on extension chunks coming in any > particular order. I think you mean non-graphic-rendering blocks (i.e. control and special purpose blocks) rather than extension blocks, which can be any of the three types. It looks to me like GIF is inherently procedural, and therefore it would be legitimate for applications to pay attention to the order of all the blocks. On the other hand, the GIF89a spec says in section 12: Special Purpose blocks such as the Comment Extension and the Application Extension are neither used to control the process of the Data Stream nor do they contain information or data used to render a graphic on the display device. Special Purpose blocks are transparent to the decoding process. So it could be argued that the location of special purpose blocks is not significant (implying that gIFx does not need a sequence number). As for control blocks, the spec leaves room for many to be defined, but besides the fixed-location stuff at the beginning and end there is currently only one control block defined, the graphic control extension, and it appears unlikely that the GIF spec will ever be updated again. There can be at most one graphic control extension preceeding each graphic-rendering block. Therefore, if you restrict your attention to GIF streams containing one image and no text extensions (i.e. true single-image GIFs), there will be no gIFt chunks and at most one gIFg chunk. The gIFg must appear before IDAT, and there's nothing left for it to be ordered with respect to, so it doesn't need a sequence number either. Therefore, we could probably get away with deprecating gIFt and leaving gIFg and gIFx as-is. I think I've probably just re-stated John's message, but it's helped me better understand things. AMC -- Send the message body "help" to png-list-request@ccrc.wustl.edu From owner-png-list@ccrc.wustl.edu Mon Aug 31 19:29: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 TAA12460 for ; Mon, 31 Aug 1998 19:29:50 -0500 (CDT) Received: by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA29804; Mon, 31 Aug 1998 19:23:14 -0500 Received: from grok.netgsi.com by ccrc.wustl.edu (SMI-8.6/ECL-A1.27) id TAA29800; Mon, 31 Aug 1998 19:23:12 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id UAA11798; Mon, 31 Aug 1998 20:23:13 -0400 Message-Id: <1.5.4.32.19980901001859.00fb4f78@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, 31 Aug 1998 20:18:59 -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 03:23 PM 8/30/98 -0700, you wrote: >In the PNG 1.0 spec, the description of the IHDR chunk and the first >line of the chapter on Deflate/Inflate Compression both talk about a >32K sliding window (i.e., exactly 32K). Elsewhere in the Deflate/Inflate >chapter it says that "an LZ77 sliding window size of not more than 32K" >is allowed. (libpng also allows the user to set the window to a smaller >value when encoding, via the png_set_compression_window_bits() function.) > >I think both places should be clarified to say a "32K (or smaller) sliding >window." The Deflate/Inflate chapter should also state explicitly that >encoders may use a window smaller than 32K but no larger (and always a >power of two), and that decoders must accept any power-of-two window size >up to and including 32K. Not "any power of two". The window size is encoded in the CINFO bits of the zlib datastream, and CINFO can only take on values 1..7, which represent window sizes 512 through 32K: CINFO Window size 1 512 bytes 2 1024 3 2048 4 4096 5 8192 6 16384 7 32768 If you want to play around with this, you can use pngcrush -w [n] where [n] is 32, 16, 8, or 4, representing windowsize in kilobytes (I didn't bother with the smallest window sizes) and observe the tradeoff between amount of compression and the memory footprint of pngcrush. 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".) Glenn -- Send the message body "help" to png-list-request@ccrc.wustl.edu