From owner-png-implement@dworkin.wustl.edu Sat Jun 1 05:35:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA09757 for ; Sat, 1 Jun 1996 05:35:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA12067 for png-implement-outgoing; Sat, 1 Jun 1996 05:36:13 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA12062 for ; Sat, 1 Jun 1996 05:36:10 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id EAA17430; Sat, 1 Jun 1996 04:34:31 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606011034.EAA17430@enel.ucalgary.ca> Subject: Status of next libpng release To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Sat, 1 Jun 1996 04:34:30 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Just so people don't start to worry, work is continuing on a new release of libpng. I've got the palette gamma correction and background working, of course, but I've also improved the filtering code, which should speed things up somewhat (it no longer re-calculates the filtered scanline that it thinks is best after it has compared them). As the previous call to set the row filter type didn't actually work properly, while fixing it, I took the liberty to add the ability to not only select a single filter type, but also to allow the selection of some, but not all, of the filter types, which the library then chooses amongst. There is also much more error checking added to the writing portion of the library so it is more difficult to write an invalid PNG file (such as a 5 bit image, or a paletted image without a palette, or an sBIT chunk with zero significant bits). I've been using Willem's PNGSuite for testing (nice work), but I noticed that the images with the cHRM chunks actually have invalid values in the chunks. As I don't know much about chromaticity myself, I am using Chris Lilley's postings to png-list on the subject that I used for pngcheck as a guide. pngcheck says for both of the files: File: ccwn2c08.png File: ccwn3p08.png chunk IHDR at offset 0x0000c, length 13 32 x 32 image, 24-bit RGB, non-interlaced chunk gAMA at offset 0x00025, length 4: 1.0000 chunk cHRM at offset 0x00035, length 32: Invalid white point 0.06 42948.7 White x = 0.06 y = 42948.7, Red x = 42948.7 y = 42948.7 Green x = 42948.7 y = 42948.7, Blue x = 42948.7 y = 42948.7 chunk IDAT at offset 0x00061, length 1397 chunk IEND at offset 0x005e2, length 0 Along the way, I've re-written the XV patch so that it has a dialog which allows you to select the compression level, file gamma, interlacing, and filter types. I've also got a new version of pngcheck which adds testing for sBIT values out of range. I will try to get all of this up as soon as possible, but I don't want to release it before I'm sure it all works, and because I've just taken up this support work, I've had to do a lot of side work to do all of the testing. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sat Jun 1 23:19:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id XAA13727 for ; Sat, 1 Jun 1996 23:19:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA20329 for png-implement-outgoing; Sat, 1 Jun 1996 23:20:42 -0500 Received: from v9001.ntu.ac.sg (v9001.ntu.ac.sg [155.69.1.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA20324 for ; Sat, 1 Jun 1996 23:20:37 -0500 Received: from ntuvax.ntu.ac.sg by ntuvax.ntu.ac.sg (PMDF V5.0-6 #7636) id <01I5FKVMO3R4A2AL7U@ntuvax.ntu.ac.sg> for png-implement@dworkin.wustl.edu; Sun, 02 Jun 1996 12:19:44 +0800 Date: Sun, 02 Jun 1996 12:19:44 +0800 From: "WILLEM VAN SCHAIK (INTERNET: GWILLEM@NTUVAX.NTU.AC.SG)" Subject: Re: Status of next libpng release To: png-implement@dworkin.wustl.edu Message-id: <01I5FKVMPXOIA2AL7U@ntuvax.ntu.ac.sg> Organization: Nanyang Technological University - Singapore X-VMS-To: IN%"png-implement@dworkin.wustl.edu" X-VMS-Cc: GWILLEM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas reported: >I've been using Willem's PNGSuite for testing (nice work), but I >noticed that the images with the cHRM chunks actually have invalid >values in the chunks. As I don't know much about chromaticity myself, >I am using Chris Lilley's postings to png-list on the subject that I >used for pngcheck as a guide. pngcheck says for both of the files: > >File: ccwn2c08.png >File: ccwn3p08.png > chunk IHDR at offset 0x0000c, length 13 > 32 x 32 image, 24-bit RGB, non-interlaced > chunk gAMA at offset 0x00025, length 4: 1.0000 > chunk cHRM at offset 0x00035, length 32: Invalid white point 0.06 42948.7 > White x = 0.06 y = 42948.7, Red x = 42948.7 y = 42948.7 > Green x = 42948.7 y = 42948.7, Blue x = 42948.7 y = 42948.7 > chunk IDAT at offset 0x00061, length 1397 > chunk IEND at offset 0x005e2, length 0 Well Andreas, join the club of ignorants ;-) Or to be more precise, I am also not that sure if I did the right thing with the chroma chunk. But let's first get a few things straigt. You are using the latest PngSuite? So either the most recent from swrinde or from my Singapore web-site (http>//mht3.gintic.ntu.ac.sg:8000/pngsuite.html), because I did correct the chroma tests with the latest release. Those before that were definitely wrong. But the values you are reporting are anyway not what I have put in, no matter the version of PngSuite you have. I used pnmtopng (which uses pnglib-0.88) to create the chroma chunk. So my question is, could anyone who really understands this chroma business have a look at my test-image and verify (on byte/bit level) if it is correct or not? It should be: ccwn2c08 - chroma chunk w:0.3127,0.3290 r:0.64,0.33 g:0.30,0.60 b:0.15,0.06 You can find it at: http://mht3.gintic.ntu.ac.sg:8000/pngsuite/ccwn2c08.png Who can confirm? Willem W i l l e m v a n S c h a i k ------------------------------------------------------------------------------- Gintic - Singapore gwillem@ntuvax.ntu.ac.sg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 2 02:50:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id CAA14690 for ; Sun, 2 Jun 1996 02:50:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA22131 for png-implement-outgoing; Sun, 2 Jun 1996 02:51:18 -0500 Received: from fm3.facility.pipex.com (fm3.facility.pipex.com [194.131.104.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id CAA22126 for ; Sun, 2 Jun 1996 02:51:07 -0500 Received: from ak121.du.pipex.com by fm3.facility.pipex.com (5.x/PIPEX simple 1.26) id AB27865; Sun, 2 Jun 1996 07:49:52 +0100 Message-Id: <9606020649.AB27865@fm3.facility.pipex.com> Mime-Version: 1.0 From: ttehtann@argonet.co.uk (T. R. Tanner) To: png-implement@dworkin.wustl.edu Date: Fri, 31 May 96 17:23:33 X-Mailer: VTi Internet Email reader 3.50 Subject: LibPNG next version Content-Type: text/plain Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Could I make a minor suggestion that will probably be unpopular (with Andreas anyway). In the interests of "internationalisation", and adding your own messages, would it be possible for png_error and png_warning to be passed a number rather than a string - The default routines could then use a defaul look-up table to get the appropriate messages, but user routines could provide different messages as required. -- Thos -- T. R. Tanner email: ttehtann@argonet.co.uk ------------Sig deleted due to lack of support------------- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 2 15:24:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA18372 for ; Sun, 2 Jun 1996 15:24:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA27398 for png-implement-outgoing; Sun, 2 Jun 1996 15:25:45 -0500 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA27393 for ; Sun, 2 Jun 1996 15:25:41 -0500 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA26159 ; Sun, 2 Jun 1996 22:23:50 +0200 From: pottier@clipper.ens.fr (Francois Pottier) Received: from felouque.ens.fr (felouque [129.199.129.8]) by clipper.ens.fr (8.7.5/jb-1.1) id WAA12045 for ; Sun, 2 Jun 1996 22:23:50 +0200 (MET DST) Message-Id: <199606022023.WAA12045@clipper.ens.fr> Subject: Re: LibPNG next version To: png-implement@dworkin.wustl.edu Date: Sun, 2 Jun 1996 22:23:49 +0200 (MET DST) In-Reply-To: <9606020649.AB27865@fm3.facility.pipex.com> from "T. R. Tanner" at May 31, 96 05:23:33 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > Could I make a minor suggestion that will probably be unpopular (with Andreas > anyway). In the interests of "internationalisation", and adding your own > messages, would it be possible for png_error and png_warning to be passed a > number rather than a string I heartily second this request - I build four localized versions of my stuff and hard-coded strings are a pain... They're actually one of the main reasons I don't support PNG yet. -- Francois Pottier Francois.Pottier@ens.fr Francois.Pottier@inria.fr http://www.eleves.ens.fr:8080/home/pottier/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 2 18:09:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA18914 for ; Sun, 2 Jun 1996 18:09:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA28892 for png-implement-outgoing; Sun, 2 Jun 1996 18:10:56 -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 SAA28887 for ; Sun, 2 Jun 1996 18:10:52 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id TAA01671 for ; Sun, 2 Jun 1996 19:09:04 -0400 (EDT) To: PNG Implementation List Subject: cHRM in PngSuite (was Re: Status of next libpng release) In-reply-to: Your message of Sun, 02 Jun 1996 12:19:44 +0800 <01I5FKVMPXOIA2AL7U@ntuvax.ntu.ac.sg> Date: Sun, 02 Jun 1996 19:09:04 -0400 Message-ID: <1669.833756944@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem writes: > It should be: > ccwn2c08 - chroma chunk > w:0.3127,0.3290 r:0.64,0.33 g:0.30,0.60 b:0.15,0.06 > You can find it at: > http://mht3.gintic.ntu.ac.sg:8000/pngsuite/ccwn2c08.png > Who can confirm? It looks wrong to me. From a hex dump with 'od', the chunk contents are 00 00 00 20 length 32 (OK) 63 48 52 4d cHRM 00 00 17 70 White x = 6000 = 0.06000 ff fe 79 61 White y = -99999 = -0.99999 ff fe 79 61 remaining values also -0.99999 ff fe 79 61 ff fe 79 61 ff fe 79 61 ff fe 79 61 ff fe 79 61 1a a4 7f a2 CRC pngcheck 1.92 says chunk cHRM at offset 0x00035, length 32: Invalid white point 0.06 42948.7 which is correct: the fields are supposed to be unsigned. But I'll bet they were filled with the signed value -99999, not with 4294867297. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 2 21:51:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA19498 for ; Sun, 2 Jun 1996 21:51:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA00584 for png-implement-outgoing; Sun, 2 Jun 1996 21:52:27 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA00577 for ; Sun, 2 Jun 1996 21:52:19 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id KAA28288 for ; Mon, 3 Jun 1996 10:50:26 +0800 (SST) Date: Mon, 3 Jun 1996 10:50:26 +0800 (SST) Message-Id: <199606030250.KAA28288@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: cHRM in PngSuite (was Re: Status of next libpng release) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 19:09 02-06-1996 -0400, you wrote: >Willem writes: >> It should be: >> ccwn2c08 - chroma chunk >> w:0.3127,0.3290 r:0.64,0.33 g:0.30,0.60 b:0.15,0.06 >> You can find it at: >> http://mht3.gintic.ntu.ac.sg:8000/pngsuite/ccwn2c08.png >> Who can confirm? > >It looks wrong to me. From a hex dump with 'od', >the chunk contents are OK, there is appearently no blessing on this test. I had already somany problems with the chroma chunk, but I'll keep on trying. Only problem is that it can take a bit more then I would like, because the monitor of my NeXT broke down . I'll have first to fix that before I can test and rebuild PngSuite. But maybe I can make a hack, that doesn't involve my NeXT. I'll see and keep you informed. Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 3 05:01:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA21726 for ; Mon, 3 Jun 1996 05:01:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA05167 for png-implement-outgoing; Mon, 3 Jun 1996 05:02:30 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA05162 for ; Mon, 3 Jun 1996 05:02:25 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id SAA30261 for ; Mon, 3 Jun 1996 18:00:34 +0800 (SST) Date: Mon, 3 Jun 1996 18:00:34 +0800 (SST) Message-Id: <199606031000.SAA30261@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: cHRM in PngSuite (was Re: Status of next libpng release) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 19:09 02-06-1996 -0400, you wrote: >Willem (yes, that's me) wrote: >> It should be: >> ccwn2c08 - chroma chunk >> w:0.3127,0.3290 r:0.64,0.33 g:0.30,0.60 b:0.15,0.06 >> You can find it at: >> http://mht3.gintic.ntu.ac.sg:8000/pngsuite/ccwn2c08.png Ahum, I traced the error back to the command-line handling of pnmtopng. So, I corrected that and I have created two new chroma-images (ccwn2c08.png and ccwn3p08.png) which you can find on my web-server. See url above. So if anybody could be so kind an tell me of those are OK? My own pngcheck is namely not in good shape .... well more accurate, my NeXT is ill ..... Updated libraries of pnmtopng and PngSuite will follow later. Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 3 06:58:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA22376 for ; Mon, 3 Jun 1996 06:58:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA07051 for png-implement-outgoing; Mon, 3 Jun 1996 07:00:26 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA07046 for ; Mon, 3 Jun 1996 07:00:22 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id NAA22787; Mon, 3 Jun 1996 13:58:31 +0200 Date: Mon, 3 Jun 1996 13:58:31 +0200 From: Chris Lilley Message-Id: <199606031158.NAA22787@www47.inria.fr> To: PNG Implementation List Subject: Re: Status of next libpng release In-Reply-To: <01I5FKVMPXOIA2AL7U@ntuvax.ntu.ac.sg> References: <01I5FKVMPXOIA2AL7U@ntuvax.ntu.ac.sg> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List WILLEM VAN SCHAIK writes: > Andreas reported: > >I've been using Willem's PNGSuite for testing (nice work), but I > >noticed that the images with the cHRM chunks actually have invalid > >values in the chunks. > But the values you are reporting are anyway not what I have put in, no > matter the version of PngSuite you have. I used pnmtopng (which uses > pnglib-0.88) to create the chroma chunk. So my question is, could anyone > who really understands this chroma business have a look at my test-image > and verify (on byte/bit level) if it is correct or not? OK > It should be: > ccwn2c08 - chroma chunk > w:0.3127,0.3290 r:0.64,0.33 g:0.30,0.60 b:0.15,0.06 > > You can find it at: > http://mht3.gintic.ntu.ac.sg:8000/pngsuite/ccwn2c08.png The file at this URL looks fine to me. pngcheck version 1.95 of 21 May 1996 reports: chunk gAMA at offset 0x00025, length 4: 1.0000 chunk cHRM at offset 0x00035, length 32 White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33 Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06 The white is a suitable value for white, and the red green and blue values are in the right corners of the chromaticity diagram. This looks fine to me. Perhaps Andreas has an older version. Incidentally, files with a cHRM chunk but no gAMA chunk would be valid bu technicaly useless. Perhaps pngcheck could issue a warning on detecting such a comnbination? This would just need two flags, initially false, each toggled on encountering gAMA or cHRM. At the end of the program, print the warning if the chrm flag is true and the gamma flag is false. -- Chris ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 3 07:28:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA23005 for ; Mon, 3 Jun 1996 07:28:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA07284 for png-implement-outgoing; Mon, 3 Jun 1996 07:30:01 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA07275 for ; Mon, 3 Jun 1996 07:29:56 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id OAA22853; Mon, 3 Jun 1996 14:28:05 +0200 Date: Mon, 3 Jun 1996 14:28:05 +0200 From: Chris Lilley Message-Id: <199606031228.OAA22853@www47.inria.fr> To: PNG Implementation List Subject: cHRM in PngSuite (was Re: Status of next libpng release) In-Reply-To: <1669.833756944@sss.pgh.pa.us> References: <01I5FKVMPXOIA2AL7U@ntuvax.ntu.ac.sg> <1669.833756944@sss.pgh.pa.us> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tom Lane writes: > Willem writes: > > http://mht3.gintic.ntu.ac.sg:8000/pngsuite/ccwn2c08.png > 00 00 00 20 length 32 (OK) > 63 48 52 4d cHRM > 00 00 17 70 White x = 6000 = 0.06000 > ff fe 79 61 White y = -99999 = -0.99999 > ff fe 79 61 remaining values also -0.99999 > ff fe 79 61 > ff fe 79 61 > ff fe 79 61 > ff fe 79 61 > ff fe 79 61 > 1a a4 7f a2 CRC > > pngcheck 1.92 says > chunk cHRM at offset 0x00035, length 32: > Invalid white point 0.06 42948.7 Well I retrieved the same URL and got correct results (but with a different version of pngcheck). OK so let's go to the hex: 0000000 8950 4e47 0d0a 1a0a 0000 000d 4948 4452 0000020 0000 0020 0000 0020 0802 0000 00fc 18ed 0000040 a300 0000 0467 414d 4100 0186 a031 e896 v--- starts here 0000060 5f00 0000 2063 4852 4d00 007a 2600 0080 ^--- different numbers from what Tom sees 0000100 8400 00fa 0000 0080 e800 0075 3000 00ea 0000120 6000 003a 9800 0017 709c ba51 3c00 0005 Hmm we got different data let's see: www47$ telnet mht3.gintic.ntu.ac.sg 8000 Trying 155.69.28.109 ... Connected to mht3.gintic.ntu.ac.sg. Escape character is '^]'. HEAD /pngsuite/ccwn2c08.png HTTP/1.0 HTTP/1.0 200 OK Date: Mon, 03 Jun 1996 12:21:35 GMT Server: Apache/1.0.3 Content-type: image/x-png Content-length: 1514 Last-modified: Mon, 03 Jun 1996 09:43:49 GMT Connection closed by foreign host. Ah so it was modified today, this morning. Tom must have got a previous version. -- Chris ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 3 12:40:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA28707 for ; Mon, 3 Jun 1996 12:40:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA11155 for png-implement-outgoing; Mon, 3 Jun 1996 12:42:14 -0500 Received: from v9000.ntu.ac.sg (v9000.ntu.ac.sg [155.69.1.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA11150 for ; Mon, 3 Jun 1996 12:42:10 -0500 Received: from ntuvax.ntu.ac.sg by ntuvax.ntu.ac.sg (PMDF V5.0-6 #7636) id <01I5HRMHZO74A2AOBP@ntuvax.ntu.ac.sg> for png-implement@dworkin.wustl.edu; Tue, 04 Jun 1996 01:41:06 +0800 Date: Tue, 04 Jun 1996 01:41:06 +0800 From: "WILLEM VAN SCHAIK (INTERNET: GWILLEM@NTUVAX.NTU.AC.SG)" Subject: Re: Status of next libpng release To: png-implement@dworkin.wustl.edu Message-id: <01I5HRMI2NKIA2AOBP@ntuvax.ntu.ac.sg> Organization: Nanyang Technological University - Singapore X-VMS-To: IN%"png-implement@dworkin.wustl.edu" X-VMS-Cc: GWILLEM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Chris told us: > WILLEM VAN SCHAIK writes: > > Andreas reported: > > >I've been using Willem's PNGSuite for testing (nice work), but I > > >noticed that the images with the cHRM chunks actually have invalid > > >values in the chunks. > > The file at this URL looks fine to me. pngcheck version 1.95 of 21 May > 1996 reports: > > chunk gAMA at offset 0x00025, length 4: 1.0000 > chunk cHRM at offset 0x00035, length 32 > White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33 > Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06 > > The white is a suitable value for white, and the red green and blue > values are in the right corners of the chromaticity diagram. This > looks fine to me. Perhaps Andreas has an older version. > May I thank you all for helping me testing this one. As many of you mentioned the Singaporese web-server is now OK. Asap (told you about that one :-) I will update the .tar.gz files on swri and the incorrect pnmtopng source. Willem ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 4 11:59:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA13073 for ; Tue, 4 Jun 1996 11:59:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA28703 for png-implement-outgoing; Tue, 4 Jun 1996 11:59:33 -0500 Received: from quests.com (quests.com [192.77.210.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA28697 for ; Tue, 4 Jun 1996 11:59:29 -0500 Received: from smtp.quests.com by silver.quests.com with SMTP (1.38.193.5/16.2) id AA06656; Tue, 4 Jun 1996 09:55:33 -0700 Received: from ccMail by smtp.quests.com (SMTPLINK V2.10.08) id AA833907055; Tue, 04 Jun 96 09:49:46 PDT Date: Tue, 04 Jun 96 09:49:46 PDT From: "Eduardo Suastegui" Message-Id: <9605048339.AA833907055@smtp.quests.com> To: png-implement@dworkin.wustl.edu Subject: PNG-to-Windows DIB conversion Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I am trying to write code to read PNG files into an MS Windows application for display, but I have not had much luck. Would you have any sample code on how to implement this functionality? Thanks, Ed Suastegui ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 4 13:58:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA15447 for ; Tue, 4 Jun 1996 13:58:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA00380 for png-implement-outgoing; Tue, 4 Jun 1996 13:59:43 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA00375 for ; Tue, 4 Jun 1996 13:59:39 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id UAA39903; Tue, 4 Jun 1996 20:57:29 +0200 Received: from fb0403.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA161634650; Tue, 4 Jun 1996 20:57:31 +0200 Received: from localhost by fb0403.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA247674645; Tue, 4 Jun 1996 20:57:25 +0200 Date: Tue, 4 Jun 1996 20:57:25 +0200 (MESZ) From: Alexander Lehmann To: Eduardo Suastegui Cc: png-implement@dworkin.wustl.edu Subject: Re: PNG-to-Windows DIB conversion In-Reply-To: <9605048339.AA833907055@smtp.quests.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello Eduardo, On Tue, 4 Jun 1996, Eduardo Suastegui wrote: > I am trying to write code to read PNG files into an MS Windows > application for display, but I have not had much luck. Would > you have any sample code on how to implement this > functionality? I would guess as a sample for the basic usage of libpng, the pngtopnm would be pretty good, how this is handled in Windows internals, I have no idea, but this should be invariant of the image format (take e.g. a GIF or PCX viewer if there is one in source code and substitute the PNG code). bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Wed Jun 5 18:49:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA03002 for ; Wed, 5 Jun 1996 18:49:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA24888 for png-implement-outgoing; Wed, 5 Jun 1996 18:49:56 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA24882 for ; Wed, 5 Jun 1996 18:49:50 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA03055; Wed, 5 Jun 1996 17:47:46 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606052347.RAA03055@enel.ucalgary.ca> Subject: new libpng, pngcheck, xv patch To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Wed, 5 Jun 1996 17:47:44 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I have uploaded a new version of libpng (0.89), pngcheck 1.96, and xv patch 1.2 to swrinde in the incoming directory. pngcheck can be moved to the png/incoming directory, but I would like libpng 0.89 and the xv patch (which is written for libpng 0.89) to remain in png-group until a few people have tested it out. I have successfully tested it with reading and writing all of the pngsuite images, and all of the PNG images I have (using the xv 1.2 patch), so I'm reasonably confident it all works, but I don't have a DOS compiler, nor do I use progressive reading. Once several people have reported success, we can move it over to png/source, and put an announcement to png-announce. If people could give it a try, and report any bugs here, I would be most greatful. The major changes are: new functions to create and destroy png_structs and info_structs, so there will be less problems with shared libraries. The old _init() functions still exist. new error function API png_set_error_fn() instead of png_set_message_fn() so old programs that use the old call fail to compile, and users will be aware that the old method of setting handlers before the png__init() call is invalid. new filter selection API that works, and allows the selection of multiple filters (the old API didn't work, so I presume nobody used it anyways). fixed bug in Borland 64K memory allocation (Alexander Lehmann) fixed bug in reading 4 bit interlaced files fixed background and gamma handling for paletted images more error checking when writing images. allow using arbitrary RGB value for background in a paletted image. Those people who want to add internationalization of the error and warning messages are free to do so and send me a patch. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 04:43:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id EAA07035 for ; Thu, 6 Jun 1996 04:43:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA00905 for png-implement-outgoing; Thu, 6 Jun 1996 04:44:14 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA00900 for ; Thu, 6 Jun 1996 04:44:09 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id LAA00756; Thu, 6 Jun 1996 11:42:02 +0200 Date: Thu, 6 Jun 1996 11:42:02 +0200 From: Chris Lilley Message-Id: <199606060942.LAA00756@www47.inria.fr> To: PNG Implementation List Subject: new libpng, pngcheck, xv patch In-Reply-To: <199606052347.RAA03055@enel.ucalgary.ca> References: <199606052347.RAA03055@enel.ucalgary.ca> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas Dilger writes: > Those people who want to add internationalization of the error and warning > messages are free to do so and send me a patch. A patch? You mean it has to be recompiled for each locale? Better than nothing, but a more plug and play approach would be better... If this part could be firmed up, so that there was a text single file which could be sent to translators, that would be a better solution. People who do translation are not necessarily C programmers ;-) I am willing to persuade people I know to donate translations, if there is a text file I can give them to translate. I presume all translations need to be 8 bit Latin-1 characters at this stage. -- Chris Lilley, W3C [ http://www.w3.org/ ] http://www.w3.org/people/chris/ INRIA/W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 05:40:55 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA07526 for ; Thu, 6 Jun 1996 05:40:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA01274 for png-implement-outgoing; Thu, 6 Jun 1996 05:41:27 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA01269 for ; Thu, 6 Jun 1996 05:41:24 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id EAA04001; Thu, 6 Jun 1996 04:39:17 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606061039.EAA04001@enel.ucalgary.ca> Subject: filters, compression, and GIF To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Thu, 6 Jun 1996 04:39:16 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, I was just playing around with XV and the hell.png image, and I got a few results (at least for this image) that I thought I would share. I was comparing speed and file size vs filters in various combinations, as well as speed in encoding and decoding vs GIF. The new libpng + XV 1.2 patch allow you to select a single filter, or any combination of filters, as well as the zlib compression level. All times quoted here are for the 512x512 hell.png image on my, ahem, 386/25 running Linux, and are approximate (hand timed over two iterations). Using no compression and no filtering, it takes 11s to save the 24 bit image on my system. As can be expected, testing fewer filters takes less time to encode the image. This is in contrast to the previous version of libpng, which tested all of the filter types for each row, then RE-ENCODED the row using the selected filter type. The new code buffers the various filtered rows when comparing them, and then writes out the row buffer of the chosen row, so even when all filters are compared, it should be faster than the old code. Using no filtering by itself is obviously fastest, as it doesn't need to do any calculation for the rows. There is a 1 second overhead for the none filter when used in combination with other filters to add up the "absolute sum of differences" for the filter so it can be compared to the others. The up and sub filters come next, and each take 2 seconds longer than no filter. The avg filter takes 3 seconds longer, while the Paeth filter takes 8 seconds more. However, the filtering time is a relatively small part of the compression time: compression level time file size ----------------- ---- --------- 0 11 787K (no filters used - no effect on compression) 0 28 787K (filters used) 1 45 438K 4 60 397K 6 70 396K 9 90 396K Adding compression into the mix makes things more interesting, as it seems that the smaller the resulting file is, the longer it takes to copmress, so although using a given combination of filters may compress faster, it is usally a larger file than another combination of filters that take longer to compress. In general, the minimum-sum-of-absolute-differences is a pretty good heuristic, although on occasion it is possible to get better compression using only a subset of the filters (such as sub and up on the 8-bit grayscale version), although not by very much. There may still be some improvement in the heuristic if it were possible to select subsets of the filters for regions of the image, using a filter type inertia of something. On the hell.png image, it was the case (as had been shown before for 8-bit paletted images), that using no filter was best when it was saved as an 8-bit PNG. What was really interesting for the 8-bit paletted version of this image, was that changing the zlib compression level between 1 and 9 harly affected the file size at all (about 150K - it actually went down by 3K going from compression level 4 to 3!), but noticably reduced the time it took to save the image. compression level time file size ----------------- ---- --------- 0 3 263K 1 8 151K 2 9 150K 3 10 149K 4 11 152K 5 12 152K 6 15 152K 7 15 152K 8 16 152K 9 18 152K GIF 5 172K All images take about 8 seconds to load. This has caused me to rethink my compression settings in POV-Ray as well, as I figured that I could live with the time penalty of using level 9 compression, for whatever reduction it gives for the filesize, but it seems to be a negligible gain (if any) at a noticable penalty in time. I hope someone finds this interesting and/or useful. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 05:48:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA07556 for ; Thu, 6 Jun 1996 05:48:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA01318 for png-implement-outgoing; Thu, 6 Jun 1996 05:48:52 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA01310 for ; Thu, 6 Jun 1996 05:48:48 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id EAA04055; Thu, 6 Jun 1996 04:46:41 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606061046.EAA04055@enel.ucalgary.ca> Subject: Re: new libpng, pngcheck, xv patch To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 04:46:40 -0600 (MDT) In-Reply-To: <199606060942.LAA00756@www47.inria.fr> from "Chris Lilley" at Jun 6, 96 11:42:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Chris writes: > A patch? You mean it has to be recompiled for each locale? Better than > nothing, but a more plug and play approach would be better... What I meant was - they can send me a patch to the libpng code which allows the messages to be stored separately, as I have no experience with how this is done, and no sense reinventing the wheel, if others have seen it before, and if there is a standard way of doing it. > I presume all translations need to be 8 bit Latin-1 characters at > this stage. I suppose it really depends on the character set that people are using at the time to display the messages in. I don't see any problems with using Latin-8 or whatever if the messages will be displayed on a Latin-8 terminal. However, Unicode is probably more work. If we start getting into different character sets, we probably also need a facility to translate between the local character set and Latin-1 to store them in the tEXt chunks, or define a Unicode chunk or something. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 06:49:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA08315 for ; Thu, 6 Jun 1996 06:49:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA01713 for png-implement-outgoing; Thu, 6 Jun 1996 06:49:42 -0500 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA01707 for ; Thu, 6 Jun 1996 06:49:35 -0500 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA09779 ; Thu, 6 Jun 1996 13:47:21 +0200 From: pottier@clipper.ens.fr (Francois Pottier) Received: from drakkar.ens.fr (drakkar [129.199.129.5]) by clipper.ens.fr (8.7.5/jb-1.1) id NAA26928 for ; Thu, 6 Jun 1996 13:47:21 +0200 (MET DST) Message-Id: <199606061147.NAA26928@clipper.ens.fr> Subject: Re: new libpng, pngcheck, xv patch To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 13:47:21 +0200 (MET DST) In-Reply-To: <199606061046.EAA04055@enel.ucalgary.ca> from "Andreas Dilger" at Jun 6, 96 04:46:40 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > What I meant was - they can send me a patch to the libpng code which > allows the messages to be stored separately, as I have no experience > with how this is done, The best way, IMHO, would be to define a symbolic constant for each error message and have the library deal only with these constants internally. Then, one would provide a way to map these constants to human error messages. I guess under most systems a set of header files, where each file defines an array of C strings, is enough. Under Macintosh, though, this is usually done by using resources: each symbolic constant is in fact the ID of the resource which contains the string. This has the advantage that the strings can then be modified/translated without recompiling; also the strings can be encoded using different character sets (e.g. Mac, Kanji) without recompiling the program. This is why I'm insisting on having the library use symbolic constants rather than just hard-coded strings. -- Francois Pottier Francois.Pottier@ens.fr Francois.Pottier@inria.fr http://www.eleves.ens.fr:8080/home/pottier/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 08:00:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA08731 for ; Thu, 6 Jun 1996 08:00:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA02241 for png-implement-outgoing; Thu, 6 Jun 1996 08:02:24 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA02236 for ; Thu, 6 Jun 1996 08:02:20 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id PAA02946; Thu, 6 Jun 1996 15:00:11 +0200 Date: Thu, 6 Jun 1996 15:00:11 +0200 From: Chris Lilley Message-Id: <199606061300.PAA02946@www47.inria.fr> To: PNG Implementation List Subject: new libpng, pngcheck, xv patch In-Reply-To: <199606052347.RAA03055@enel.ucalgary.ca> References: <199606052347.RAA03055@enel.ucalgary.ca> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas Dilger writes: > I have uploaded a new version of libpng (0.89), pngcheck 1.96, and xv > patch 1.2 to swrinde in the incoming directory. > If people could give it a try, and report any bugs here, I would be > most greatful. I compiled it with gcc on Sun Sol2.4. zlib was version 1.0.2 which passes make test. Libpng does not: ./pngtest Testing libpng version 0.89 Files pngtest.png and pngout.png are different *** Error code 1 make: Fatal error: Command failed for target `test' probably because: make pngtest gcc -I../zlib-1.0.2 -O -c pngtest.c gcc -o pngtest pngtest.o -L. -L../zlib-1.0.2/ -lpng -lz -lm coff2exe pngtest sh: coff2exe: not found *** Error code 1 make: Fatal error: Command failed for target `pngtest' What is coff2exe? -- Chris Lilley, W3C [ http://www.w3.org/ ] http://www.w3.org/people/chris/ INRIA/W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 08:28:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA09036 for ; Thu, 6 Jun 1996 08:28:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA02509 for png-implement-outgoing; Thu, 6 Jun 1996 08:30:59 -0500 Received: from jeeves.va.pubnix.com (jeeves.va.pubnix.com [199.170.214.66]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA02504 for ; Thu, 6 Jun 1996 08:30:56 -0500 Received: from garotte.va.pubnix.com by jeeves.va.pubnix.com with ESMTP id JAA25628; Thu, 6 Jun 1996 09:13:33 -0400 Received: from garotte.va.pubnix.com by garotte.va.pubnix.com with ESMTP id JAA22575; Thu, 6 Jun 1996 09:13:33 -0400 (EDT) Message-Id: To: PNG Implementation List Subject: Re: filters, compression, and GIF In-reply-to: Your message of "Thu, 06 Jun 1996 04:39:16 MDT." <199606061039.EAA04001@enel.ucalgary.ca> Date: Thu, 06 Jun 1996 09:13:33 -0400 From: "Josh M. Osborne" Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In message <199606061039.EAA04001@enel.ucalgary.ca>, Andreas Dilger writes: [...] >The new libpng + XV 1.2 patch allow you to select a single filter, or any >combination of filters, as well as the zlib compression level. All times >quoted here are for the 512x512 hell.png image on my, ahem, 386/25 running >Linux, and are approximate (hand timed over two iterations). Using no >compression and no filtering, it takes 11s to save the 24 bit image on my >system. [...very good message about timings, thanks for all the work...] If that 386 has no external cache it may not reflect the timings of most systems (i.e. it may not be merely a linear function of the speed of a 486, esp a 486 with a 256K or larget L2 cache... or likewise it may not be a linear function of the speed of a PentimumPro (which has it's own L2 cache)). (386's have no internal cache, only a small instruction queue) On a machine with a sizeable cache the diffrence between N and M filter sets may be unoticable. With a smallish cache the diffrence between N and N+1 could be dramitic for some values of N, but not for others. Likewise for compresion levels (however I think the compresion is a bit more CPU intensave then filtering, so it may be more notciable even with caches). All that is just the long way of saying that your results may well only be valid for machines with the same amount of cache & charistics (dirrect mapped, assoc, timings) as your 386. Sorry. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 09:13:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA09736 for ; Thu, 6 Jun 1996 09:13:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA02867 for png-implement-outgoing; Thu, 6 Jun 1996 09:14:59 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA02862 for ; Thu, 6 Jun 1996 09:14:53 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id QAA26923 for ; Thu, 6 Jun 1996 16:12:41 +0200 Received: from fb0408.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA001680362; Thu, 6 Jun 1996 16:12:42 +0200 Received: from localhost by fb0408.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA287000357; Thu, 6 Jun 1996 16:12:37 +0200 Date: Thu, 6 Jun 1996 16:12:37 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: new libpng, pngcheck, xv patch In-Reply-To: <199606061300.PAA02946@www47.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, On Thu, 6 Jun 1996, Chris Lilley wrote: > Andreas Dilger writes: > > I have uploaded a new version of libpng (0.89), pngcheck 1.96, and xv > > patch 1.2 to swrinde in the incoming directory. > > > If people could give it a try, and report any bugs here, I would be > > most greatful. > > I compiled it with gcc on Sun Sol2.4. zlib was version 1.0.2 which > passes make test. Libpng does not: > > ./pngtest > Testing libpng version 0.89 > Files pngtest.png and pngout.png are different > *** Error code 1 > make: Fatal error: Command failed for target `test' > > probably because: > > make pngtest > gcc -I../zlib-1.0.2 -O -c pngtest.c > gcc -o pngtest pngtest.o -L. -L../zlib-1.0.2/ -lpng -lz -lm > coff2exe pngtest > sh: coff2exe: not found > *** Error code 1 > make: Fatal error: Command failed for target `pngtest' > > What is coff2exe? makefile.gcc is for a DOS port of gcc called djgpp, to use gcc on a unix system, you can just change from CC=cc to CC=gcc in makefile. coff2exe is a program in djgpp that takes the coff executable produced by gcc and prepends a small DOS real mode program to it which takes care of loading the DOS extender and running the program in protected mode. This procedure is no longer needed in the current version of djgpp (2.0), because the program is called after the linker stage by the gcc compiler driver. Maybe makefile.gcc should be renamed makefile.dj. (zlib has makefile.dj2) bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 09:47:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA10447 for ; Thu, 6 Jun 1996 09:47:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA03320 for png-implement-outgoing; Thu, 6 Jun 1996 09:49: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 JAA03314 for ; Thu, 6 Jun 1996 09:49:13 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id KAA29191 for ; Thu, 6 Jun 1996 10:47:05 -0400 (EDT) To: PNG Implementation List Subject: Localization (Re: new libpng, pngcheck, xv patch) In-reply-to: Your message of Thu, 6 Jun 1996 13:47:21 +0200 (MET DST) <199606061147.NAA26928@clipper.ens.fr> Date: Thu, 06 Jun 1996 10:47:04 -0400 Message-ID: <29189.834072424@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Francois wrote: > The best way, IMHO, would be to define a symbolic constant for each > error message and have the library deal only with these constants > internally. > Then, one would provide a way to map these constants to human error > messages. I guess under most systems a set of header files, where each > file defines an array of C strings, is enough. Right. Instead of png_error(pngptr, "Blah blah blah"); you write png_error(pngptr, PNGERROR_BLAH_BLAH_BLAH); where the constant is defined in pngerror.h, and is used as an index into an error message table by png_error. Localization of the library then only requires substituting a different message table in png_error, and can even be done at runtime. This is a pain in the neck during initial development of a library, because every time you think of a new error condition, you have to add a value to pngerror.h (thus forcing recompilation of everything...) But hopefully libpng is now stable enough to make it feasible. > Under Macintosh, though, this is usually done by using resources: each > symbolic constant is in fact the ID of the resource which contains the > string. A Mac-specific version of png_error could choose to store the message table as a stringlist resource rather than directly in a C array. Again, the rest of the library is oblivious to what happens inside png_error. For C code specifics, you might find some useful ideas in jerror.h and jerror.c in the IJG JPEG library v6 or later. The IJG code is not localized as distributed, but could easily be localized if anyone bothered to put together an alternate message table. (In particular, the use and redefinition of JMESSAGE() macro is real handy, because any given message code need only be specified in one place. There exist versions of jerror.c that store the messages differently than the default version does, by defining JMESSAGE() differently when it comes time to build the table.) regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 10:23:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA10778 for ; Thu, 6 Jun 1996 10:23:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA03789 for png-implement-outgoing; Thu, 6 Jun 1996 10:25:38 -0500 Received: from v9000.ntu.ac.sg (v9000.ntu.ac.sg [155.69.1.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA03784 for ; Thu, 6 Jun 1996 10:25:33 -0500 Received: from ntuvax.ntu.ac.sg by ntuvax.ntu.ac.sg (PMDF V5.0-6 #7636) id <01I5LTUU33YOA2BF70@ntuvax.ntu.ac.sg> for png-implement@dworkin.wustl.edu; Thu, 06 Jun 1996 23:24:20 +0800 Date: Thu, 06 Jun 1996 23:24:20 +0800 From: "WILLEM VAN SCHAIK (INTERNET: GWILLEM@NTUVAX.NTU.AC.SG)" Subject: Re: new libpng, pngcheck, xv patch To: png-implement@dworkin.wustl.edu Message-id: <01I5LTUU810YA2BF70@ntuvax.ntu.ac.sg> Organization: Nanyang Technological University - Singapore X-VMS-To: IN%"png-implement@dworkin.wustl.edu" X-VMS-Cc: GWILLEM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I found a small hitch in the new libpng-0.89. When I tried the default makefile it aborted because at the end of line 16 in the makefile a backslash is missing. Didn't check with other makefiles. Willem ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 12:52:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA12348 for ; Thu, 6 Jun 1996 12:52:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA05591 for png-implement-outgoing; Thu, 6 Jun 1996 12:54:34 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA05586 for ; Thu, 6 Jun 1996 12:54:30 -0500 Received: from munet-f.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id LAA05268; Thu, 6 Jun 1996 11:52:20 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606061752.LAA05268@enel.ucalgary.ca> Received: by munet-f.enel.ucalgary.ca (NX5.67d/NX3.0X) id AA07028; Thu, 6 Jun 96 11:52:18 -0600 Subject: Re: libpng localization To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 11:52:17 -0600 (MDT) In-Reply-To: <199606061147.NAA26928@clipper.ens.fr> from "Francois Pottier" at Jun 6, 96 01:47:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Francios writes: > The best way, IMHO, would be to define a symbolic constant for each > error message and have the library deal only with these constants > internally. > > This has the advantage that the strings can then be > modified/translated without recompiling; also the strings can be > encoded using different character sets (e.g. Mac, Kanji) without > recompiling the program. > > This is why I'm insisting on having the library use symbolic constants > rather than just hard-coded strings. Not to sound negative, but if you feel this is important, please feel free to contribute some code and translated error messages. While I bit the bullet and updated libpng with most of the outstanding bugs, I don't want to take on the whole development, and then fail to release new versions as time passes because I'm too busy. Maybe it can be handled like pngcheck, or Linux, where everybody contributes to the areas that they feel are important, and a new version is released as required. This also has the added benefit that I don't spend time working on code that people don't really use (like dithering - anyone use the dithering code?). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 13:12:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA12622 for ; Thu, 6 Jun 1996 13:12:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA05748 for png-implement-outgoing; Thu, 6 Jun 1996 13:14:16 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA05743 for ; Thu, 6 Jun 1996 13:14:10 -0500 Received: from munet-f.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id MAA05386; Thu, 6 Jun 1996 12:12:01 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606061812.MAA05386@enel.ucalgary.ca> Received: by munet-f.enel.ucalgary.ca (NX5.67d/NX3.0X) id AA07043; Thu, 6 Jun 96 12:11:59 -0600 Subject: Re: filters, compression, and GIF To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 12:11:58 -0600 (MDT) In-Reply-To: from "Josh M. Osborne" at Jun 6, 96 09:13:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Josh writes: > If that 386 has no external cache it may not reflect the timings > of most systems (i.e. it may not be merely a linear function of > the speed of a 486, esp a 486 with a 256K or larget L2 cache... > or likewise it may not be a linear function of the speed of a > PentimumPro (which has it's own L2 cache)). (386's have no > internal cache, only a small instruction queue) Well, despite being a very old machine, it has 32K external cache, which is plenty for holding two rows of pixels. As well, Linux has a delayed write cache, and I also tested with writing to /dev/null (but can't do this when finding the file size). However, the speed differrences are a fact of life not directly related to the external cache, as there are arithmetic operations that need to be done for all filters (except when no filtering is done). This is clearly shown by the fact that no filtering is fastest, followed by sub and up (which both do the same number of ops), and Paeth is by far the slowest, since it does as many ops as all the other filters put together. While the absolute time taken may be smaller, I think the relative time will remain the same. It's just that it's a lot easier to time things by hand on my computer than on a faster one :-). As of right now, I don't have a command-line only PNG program, except the new pngtest program, which optionally can be given an input and output filename to read and write a file other than pngtest.png. However, it doesn't allow changing the compression and filters like the XV dialog does. (This reminds me - ppmtopng and pngtoppm require a file "pnmpalette.h" or similar, that I haven't been able to find in the latest version of netpbm. Where is this file?) The whole point of the data wasn't to show off my speedy computer, but to hopefully contribute to people's understanding of how PNG compression works and can be optimized - as can be seen with the 8-bit PNG compression. With the changes to the filtering code, I made it easier to add in functionality like an compression testing filter selector that isn't forced to write lines immediately after they are recieved. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 16:31:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA17867 for ; Thu, 6 Jun 1996 16:31:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA08073 for png-implement-outgoing; Thu, 6 Jun 1996 16:32:22 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA08068 for ; Thu, 6 Jun 1996 16:32:17 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id QAA05606 for ; Thu, 6 Jun 1996 16:29:41 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id QAA18711 for png-implement@dworkin.wustl.edu; Thu, 6 Jun 1996 16:30:35 -0500 (CDT) Date: Thu, 6 Jun 1996 16:30:35 -0500 (CDT) From: Cave Newt Message-Id: <199606062130.QAA18711@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: libpng localization Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas writes: > This also has the added benefit that I don't spend time > working on code that people don't really use (like dithering - anyone use > the dithering code?). Yes, X Mosaic did as of the last time I checked. It uses both libjpeg's and libpng's built-in dithering, and the latter looks (or looked) horrible. > (This reminds me - ppmtopng and pngtoppm require > a file "pnmpalette.h" or similar, that I haven't been able to find > in the latest version of netpbm. Where is this file?) Never heard of it, and I don't recall having a problem compiling pnmtopng, either. Did this change recently? Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 17:00:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA18298 for ; Thu, 6 Jun 1996 17:00:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA08458 for png-implement-outgoing; Thu, 6 Jun 1996 17:02:25 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA08450 for ; Thu, 6 Jun 1996 17:02:17 -0500 Received: from munet-f.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA06076; Thu, 6 Jun 1996 16:00:07 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606062200.QAA06076@enel.ucalgary.ca> Received: by munet-f.enel.ucalgary.ca (NX5.67d/NX3.0X) id AA07212; Thu, 6 Jun 96 16:00:05 -0600 Subject: Re: libpng localization To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 16:00:04 -0600 (MDT) In-Reply-To: <199606062130.QAA18711@ellis.uchicago.edu> from "Cave Newt" at Jun 6, 96 04:30:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Greg writes: > Yes, X Mosaic did as of the last time I checked. It uses both libjpeg's > and libpng's built-in dithering, and the latter looks (or looked) horrible. I don't think it would be all that hard to convert libpng's dithering code to use a Floyd-Steinberg error diffusion dither, but IMHO, a program like X Mosaic would be much better off getting all of the images, regardless of format, in 24 bit RGBA, and then using its own code to dither the whole display to the available color cube (or even do color cube optimization for the screen, if there are cycles to spare). Note that I'm not talking about removing the dithering code, but I was just of the opinion that this shouldn't really be a part of the image decoding library. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 17:42:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA18802 for ; Thu, 6 Jun 1996 17:42:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA08910 for png-implement-outgoing; Thu, 6 Jun 1996 17:43:28 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA08905 for ; Thu, 6 Jun 1996 17:43:24 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id RAA09363 for ; Thu, 6 Jun 1996 17:40:48 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id RAA27473 for png-implement@dworkin.wustl.edu; Thu, 6 Jun 1996 17:41:43 -0500 (CDT) Date: Thu, 6 Jun 1996 17:41:43 -0500 (CDT) From: Cave Newt Message-Id: <199606062241.RAA27473@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: libpng localization Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas writes: > I don't think it would be all that hard to convert libpng's dithering > code to use a Floyd-Steinberg error diffusion dither, but IMHO, a program > like X Mosaic would be much better off getting all of the images, regardless > of format, in 24 bit RGBA, and then using its own code to dither the whole > display to the available color cube (or even do color cube optimization for > the screen, if there are cycles to spare). That's probably true, and it may even be a feature in 2.8, but for now everything is 8-bit at the source. > Note that I'm not talking about removing the dithering code, but I was > just of the opinion that this shouldn't really be a part of the image > decoding library. There I disagree. libpng already does a zillion other transformations on the data, either boosting the size to 8 bits or shrinking it down from something larger or resolving transparency or whatever, and I see no reason why just the shrinking-to-8-bits part should be thrown out. I don't know the details of FS dithering, but I have seen numerous cases where dithering an already-quantized image looks far worse than quantizing and dithering a 24-bit image in one step. In other words, the dithering is not separate from the shrinking-to-8-bits part. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 18:57:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA19085 for ; Thu, 6 Jun 1996 18:57:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA09655 for png-implement-outgoing; Thu, 6 Jun 1996 18:59:00 -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 SAA09650 for ; Thu, 6 Jun 1996 18:58:55 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id TAA07194 for ; Thu, 6 Jun 1996 19:56:44 -0400 (EDT) To: PNG Implementation List Subject: dithering & etc (was Re: libpng localization) In-reply-to: Your message of Thu, 6 Jun 1996 17:41:43 -0500 (CDT) <199606062241.RAA27473@ellis.uchicago.edu> Date: Thu, 06 Jun 1996 19:56:44 -0400 Message-ID: <7192.834105404@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Greg writes: > Andreas writes: >> IMHO, a program >> like X Mosaic would be much better off getting all of the images, regardless >> of format, in 24 bit RGBA, and then using its own code to dither the whole >> display to the available color cube (or even do color cube optimization for >> the screen, if there are cycles to spare). > That's probably true, and it may even be a feature in 2.8, but for now > everything is 8-bit at the source. X Mosaic 2.8 very probably will behave that way (btw, I should know, I'm going to be doing it ;-)). The real issue is just that when you're dealing with N image formats, it makes the most sense to have only one set of color reduction/ dithering/gamma adjustment/rescaling/compositing/etc code, not one for each format. It's not a bad idea to supply such code with libpng, but it should be a separable library, not something wired into PNG decoding. libjpeg does have color reduction/dithering code built into it, but I don't think that libpng should follow that precedent. libjpeg's ability to do this is partly a historical matter: at the time it was designed, lots of graphics programs had an eight-bit worldview, and it was just a lot easier to sell JPEG to programmers if they could get a palette image on demand with no extra thought. That's less true now than it was then. If I were redesigning libjpeg's feature set from scratch, I might still leave in color quantization, and certainly would leave in rescaling, but that's because it's possible to get some performance boosts by doing those things inside the JPEG decoder. I don't see any corresponding advantage to embedding such functions in a PNG decoder. Doing it at arm's length in a separate library will be just about as fast and much more flexible. I do think we can do the world a service by providing such functions so's people don't have to reinvent that particular wheel. But don't tie them to PNG decoding; make it possible to apply the functions to images coming from other sources. regards, tom lane organizer, Independent JPEG Group ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 19:59:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA19380 for ; Thu, 6 Jun 1996 19:59:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10326 for png-implement-outgoing; Thu, 6 Jun 1996 20:01:28 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA10321 for ; Thu, 6 Jun 1996 20:01:24 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id IAA15882 for ; Fri, 7 Jun 1996 08:59:13 +0800 (SST) Date: Fri, 7 Jun 1996 08:59:13 +0800 (SST) Message-Id: <199606070059.IAA15882@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: libpng localization Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 16:30 06-06-1996 -0500, Greg wrote: >Andreas writes: > >> (This reminds me - ppmtopng and pngtoppm require >> a file "pnmpalette.h" or similar, that I haven't been able to find >> in the latest version of netpbm. Where is this file?) > >Never heard of it, and I don't recall having a problem compiling pnmtopng, >either. Did this change recently? > Never heard of it either :-). And I think I should know 8-). But which version of netpbm are you using? Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 20:04:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA19405 for ; Thu, 6 Jun 1996 20:04:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10366 for png-implement-outgoing; Thu, 6 Jun 1996 20:06:31 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA10361 for ; Thu, 6 Jun 1996 20:06:21 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA01224 for ; Fri, 7 Jun 1996 09:04:08 +0800 (SST) Date: Fri, 7 Jun 1996 09:04:08 +0800 (SST) Message-Id: <199606070104.JAA01224@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: dithering & etc (was Re: libpng localization) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 19:56 06-06-1996 -0400, Tom wrote: >Greg writes: >> Andreas writes: >>> IMHO, a program >>> like X Mosaic would be much better off getting all of the images, regardless >>> of format, in 24 bit RGBA, and then using its own code to dither the whole >>> display to the available color cube (or even do color cube optimization for >>> the screen, if there are cycles to spare). > >> That's probably true, and it may even be a feature in 2.8, but for now >> everything is 8-bit at the source. > >It's not a bad idea to supply such code with libpng, but it should be >a separable library, not something wired into PNG decoding. > Just an idea, can't we use the netpbm code for doing the "arms-length dithering"? I agree fully with not reinventing the wheel again. Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 20:08:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA19448 for ; Thu, 6 Jun 1996 20:08:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10404 for png-implement-outgoing; Thu, 6 Jun 1996 20:10:39 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA10398 for ; Thu, 6 Jun 1996 20:10:34 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA14446 for ; Fri, 7 Jun 1996 09:08:23 +0800 (SST) Date: Fri, 7 Jun 1996 09:08:23 +0800 (SST) Message-Id: <199606070108.JAA14446@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: libpng localization Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 11:52 06-06-1996 -0600, Andreas wrote: >Francios writes: >> The best way, IMHO, would be to define a symbolic constant for each >> error message and have the library deal only with these constants >> internally. >> >Not to sound negative, but if you feel this is important, please feel >free to contribute some code and translated error messages. While I >bit the bullet and updated libpng with most of the outstanding bugs, >I don't want to take on the whole development, and then fail to release >new versions as time passes because I'm too busy. > Two comments. I like to support Andreas vision on how to improve the library. It should not be a one man's effort. Secondly, I have my doubts about the necessity for internationalization for this type of library. It is only used by programmers and the error messages will hardly reach application end-users. And programmers understand English like "while, repeat, if, do, etc" don't they :-). Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 20:17:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA19518 for ; Thu, 6 Jun 1996 20:17:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10492 for png-implement-outgoing; Thu, 6 Jun 1996 20:19:08 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA10486 for ; Thu, 6 Jun 1996 20:19:05 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id UAA14773 for ; Thu, 6 Jun 1996 20:16:29 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id UAA10749 for png-implement@dworkin.wustl.edu; Thu, 6 Jun 1996 20:17:23 -0500 (CDT) Date: Thu, 6 Jun 1996 20:17:23 -0500 (CDT) From: Cave Newt Message-Id: <199606070117.UAA10749@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: dithering & etc (was Re: libpng localization) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tom writes: > X Mosaic 2.8 very probably will behave that way (btw, I should know, > I'm going to be doing it ;-)). Ooo, most excellent. > at the time it was designed, lots of graphics programs had an > eight-bit worldview, and it was just a lot easier to sell JPEG > to programmers if they could get a palette image on demand with > no extra thought. That's less true now than it was then. True, but on the other hand, there are a whole lot of graphics duffers (myself included) who have been hacking PNG support into various things without much trouble, thanks largely to the rich set of functions Guy built into libpng. I think a lot of those ports would not have happened if everyone had had to deal with the raw N-bit image data on their own. > If I were redesigning libjpeg's feature set from scratch, I might > still leave in color quantization, and certainly would leave in > rescaling, but that's because it's possible to get some performance > boosts by doing those things inside the JPEG decoder. I don't see > any corresponding advantage to embedding such functions in a PNG decoder. Correct me if I'm wrong, but doesn't FS operate locally? I.e., given a 24-bit image with a suggested palette, is it not true that libpng can dither to 8 bits with only epsilon more storage than the final 8-bit image requires? That's a BIG advantage, believe me. (I just watched my memory usage shoot up to 132MB--of which only 32MB was DRAM--with XPaint on a 3000x900 image. That wasn't because of anything in the PNG code, but it illustrates the importance of memory optimization as image sizes get larger.) > Doing it at arm's length in a separate library will be just about > as fast and much more flexible. But unless libpng is aware of the library and able to link it in dynamically, you're going to end up with a 24-bit temporary image in addition to an 8-bit final one. Depending on your machine, there goes your speed. (The image above required over 5 minutes just to write to disk since it was mostly swapped out at any given time.) Maybe more to the point, there's already 24-to-8-bit dithering code in libpng; it's just not very good. Given that you can't remove what's already in there, I'd vote for making it better. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 20:26:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA19538 for ; Thu, 6 Jun 1996 20:26:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10579 for png-implement-outgoing; Thu, 6 Jun 1996 20:28:49 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA10574 for ; Thu, 6 Jun 1996 20:28:45 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id TAA06483; Thu, 6 Jun 1996 19:26:34 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606070126.TAA06483@enel.ucalgary.ca> Subject: Re: libpng localization To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 19:26:33 -0600 (MDT) In-Reply-To: <199606070059.IAA15882@ntuix.ntu.ac.sg> from "Willem van Schaik" at Jun 7, 96 08:59:13 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem writes: > >> (This reminds me - ppmtopng and pngtoppm require > >> a file "pnmpalette.h" or similar, that I haven't been able to find > >> in the latest version of netpbm. Where is this file?) > Never heard of it either :-). And I think I should know 8-). But which > version of netpbm are you using? Actually, the file is ppmcmap.h that I'm missing for pnmtopng.c. I have p[bgnp]m.h and pbmplus.h, but not ppmcmap.h. Also, Willem, you should give the new libpng a try with pnmtopng, as it now should handle the palette correction properly, and you can remove the HOMEMADE_GAMMA code. Actually, while I was playing with XV, I was thinking if, rather than PNG being a nice lossless format, we haven't made the most lossy format available. The reason is that, as recommended by the PNG group, many applications now handle the gamma correction of images. However, since libpng does the correction while the image is being loaded, data is lost unless the current display gamma matches that of the file. Then, when the file is saved, it has a new gAMA chunk written out, and if it is loaded again on another computer, it will again undergo a lossy transformation. This is really far worse than using a GIF, where the pixel values stay constant if you load and save the image any number of times on several different computers. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 20:51:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA19590 for ; Thu, 6 Jun 1996 20:50:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10771 for png-implement-outgoing; Thu, 6 Jun 1996 20:53:03 -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 UAA10766 for ; Thu, 6 Jun 1996 20:52:59 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id VAA07371 for ; Thu, 6 Jun 1996 21:50:48 -0400 (EDT) To: PNG Implementation List Subject: Re: dithering & etc (was Re: libpng localization) In-reply-to: Your message of Thu, 6 Jun 1996 20:17:23 -0500 (CDT) <199606070117.UAA10749@ellis.uchicago.edu> Date: Thu, 06 Jun 1996 21:50:48 -0400 Message-ID: <7369.834112248@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Greg wonders: > Tom writes: >> ... because it's possible to get some performance >> boosts by doing those things inside the JPEG decoder. I don't see >> any corresponding advantage to embedding such functions in a PNG decoder. > Correct me if I'm wrong, but doesn't FS operate locally? I.e., given a > 24-bit image with a suggested palette, is it not true that libpng can > dither to 8 bits with only epsilon more storage than the final 8-bit > image requires? That's a BIG advantage, believe me. Well, if you insist on grabbing and storing the whole image before starting to feed it to the quantizer/ditherer, then yes, you need a 24-bit work buffer. My own preference in such things is to work a scanline at a time; that seems to work pretty well as a simple compromise between too much workspace and too many transfers of control. So the way I'd do it is to read a 24-bit scanline from libpng, hand it off to QuantizeDither in my hypothetical libraster-image-munger, and get back an 8-bit scanline that goes into my final image. This needs only one scanline worth of "extra" storage. BTW, it looks to me like libpng's internal implementation is structured exactly this way: it uses a one-row workspace and applies the various transforms in sequence on one row at a time. So "epsilon" is a scanline. Trying to apply all the transforms with only a pixel's worth of workspace would be too slow or too complex. (Basically, you don't want to incur the overhead of deciding what to do on every pixel, but incurring it once per scanline is livable.) > Maybe more to the point, there's already 24-to-8-bit dithering code > in libpng; it's just not very good. Given that you can't remove what's > already in there, I'd vote for making it better. Well, if we've decided that libpng's API is frozen solid, then that's true. But I think it'd be smarter to pull that functionality out and expect people to invoke it with a separate call. Or how about this: separate out the pngrtran functionality as a library-within-a-library, that could be called directly if someone wants to use it for non-PNG-source images. That approach could preserve the current libpng API. (Hmm, maybe I should do that with the libjpeg quantizers...) regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 20:55:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA19611 for ; Thu, 6 Jun 1996 20:55:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10811 for png-implement-outgoing; Thu, 6 Jun 1996 20:57:45 -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 UAA10806 for ; Thu, 6 Jun 1996 20:57:41 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id VAA07407 for ; Thu, 6 Jun 1996 21:55:30 -0400 (EDT) To: PNG Implementation List Subject: Re: libpng localization In-reply-to: Your message of Fri, 7 Jun 1996 09:08:23 +0800 (SST) <199606070108.JAA14446@ntuix.ntu.ac.sg> Date: Thu, 06 Jun 1996 21:55:30 -0400 Message-ID: <7405.834112530@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem writes: > I have my doubts > about the necessity for internationalization for this type of library. > It is only used by programmers and the error messages will hardly > reach application end-users. And programmers understand English like > "while, repeat, if, do, etc" don't they :-). You might be right about the error messages that respond to application programmer mistakes. But any error message that can arise as a result of reading an incorrect/corrupted PNG file is likely to be seen by end users, and needs to be localizable. So you might as well just localize 'em all... regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 21:18:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA19737 for ; Thu, 6 Jun 1996 21:18:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA11043 for png-implement-outgoing; Thu, 6 Jun 1996 21:20:34 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA11038 for ; Thu, 6 Jun 1996 21:20:29 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id UAA06589; Thu, 6 Jun 1996 20:18:19 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606070218.UAA06589@enel.ucalgary.ca> Subject: Re: dithering & etc (was Re: libpng localization) To: png-implement@dworkin.wustl.edu Date: Thu, 6 Jun 1996 20:18:18 -0600 (MDT) In-Reply-To: <7369.834112248@sss.pgh.pa.us> from "Tom Lane" at Jun 6, 96 09:50:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Re FS dithering: Actually, I have a FS dither working with only one scanline + one pixel extra storage for POV-Ray, rather than the two error row buffers that FS dithering normally uses. It wasn't an issue of the extra memory, but POV has a "mosaic preview" which is a lot like the Adam-7 interlacing, and there is no guarantee that the pixels are accessed all in order, although it is a general top-down, left-to-right fashion. It basically keeps only one error row, and an extra pixel to store the future error for the current pixel (actually it's kind of hard to explain). Has anyone heard of doing it this way before, or have I just re-invented the wheel? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 22:23:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id WAA20068 for ; Thu, 6 Jun 1996 22:23:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA11628 for png-implement-outgoing; Thu, 6 Jun 1996 22:25:42 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA11614 for ; Thu, 6 Jun 1996 22:24:51 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id LAA09465 for ; Fri, 7 Jun 1996 11:22:33 +0800 (SST) Date: Fri, 7 Jun 1996 11:22:33 +0800 (SST) Message-Id: <199606070322.LAA09465@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: libpng localization Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 19:26 06-06-1996 -0600, Andreas wrote: >Actually, the file is ppmcmap.h that I'm missing for pnmtopng.c. I have >p[bgnp]m.h and pbmplus.h, but not ppmcmap.h. Also, Willem, you should Did you download netpbm as mentioned in the readme file of pnmtopng: ftp://ftp.x.org/R5contrib/netpbm-1mar1994.tar.gz >give the new libpng a try with pnmtopng, as it now should handle the >palette correction properly, and you can remove the HOMEMADE_GAMMA code. As you could notice from my other message about the error in the libpng makefile, that is exactly what I'm doing now. The moment libpng0.89 is out officially, I will release a new pnmtopng version without HOME.... WIllem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 6 22:27:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id WAA20121 for ; Thu, 6 Jun 1996 22:27:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA11751 for png-implement-outgoing; Thu, 6 Jun 1996 22:30:02 -0500 Received: from dub-img-4.compuserve.com (dub-img-4.compuserve.com [198.4.9.4]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA11742 for ; Thu, 6 Jun 1996 22:29:59 -0500 Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id XAA06856; Thu, 6 Jun 1996 23:27:39 -0400 Date: 06 Jun 96 23:26:39 EDT From: "Owen J. Mortensen" To: png-implement , Tom Lane Subject: Re: dithering & etc (was Re: libpng localization) Message-ID: Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tom Lane wrote: >Or how about this: separate out the pngrtran functionality as a >library-within-a-library, that could be called directly if someone >wants to use it for non-PNG-source images. That approach could preserve >the current libpng API. (Hmm, maybe I should do that with the libjpeg >quantizers...) PLEASE DO! This would make it MUCH easier to pull out the libjpeg ditherer and substitute my own without having to know the intimate details of the data structures (poor man's OO) that libjpeg uses. Of course, I suppose this discussion belongs over on the JPEG list.... Regards, Owen ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 05:48:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA22949 for ; Fri, 7 Jun 1996 05:48:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA16092 for png-implement-outgoing; Fri, 7 Jun 1996 05:48:57 -0500 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA16087 for ; Fri, 7 Jun 1996 05:48:52 -0500 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA03071 ; Fri, 7 Jun 1996 12:46:39 +0200 From: pottier@clipper.ens.fr (Francois Pottier) Received: from chaland.ens.fr (chaland [129.199.129.3]) by clipper.ens.fr (8.7.5/jb-1.1) id MAA13925 for ; Fri, 7 Jun 1996 12:46:38 +0200 (MET DST) Message-Id: <199606071046.MAA13925@clipper.ens.fr> Subject: Re: libpng localization To: png-implement@dworkin.wustl.edu Date: Fri, 7 Jun 1996 12:46:38 +0200 (MET DST) In-Reply-To: <199606061752.LAA05268@enel.ucalgary.ca> from "Andreas Dilger" at Jun 6, 96 11:52:17 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > Not to sound negative, but if you feel this is important, please feel > free to contribute some code and translated error messages. Well, I'd like to give it a try, but I don't know where to download 0.89. I only see 0.88 on swrinde.nde.swri.edu. Can you give me a URL? -- Francois Pottier Francois.Pottier@ens.fr Francois.Pottier@inria.fr http://www.eleves.ens.fr:8080/home/pottier/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 05:57:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA22996 for ; Fri, 7 Jun 1996 05:57:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA16162 for png-implement-outgoing; Fri, 7 Jun 1996 05:59:59 -0500 Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA16157 for ; Fri, 7 Jun 1996 05:59:55 -0500 Received: from clipper.ens.fr (clipper-gw.ens.fr) by nef.ens.fr (5.65c8/ULM-1.0) Id AA03455 ; Fri, 7 Jun 1996 12:57:42 +0200 From: pottier@clipper.ens.fr (Francois Pottier) Received: from chaland.ens.fr (chaland [129.199.129.3]) by clipper.ens.fr (8.7.5/jb-1.1) id MAA14443 for ; Fri, 7 Jun 1996 12:57:41 +0200 (MET DST) Message-Id: <199606071057.MAA14443@clipper.ens.fr> Subject: Re: libpng localization To: png-implement@dworkin.wustl.edu Date: Fri, 7 Jun 1996 12:57:41 +0200 (MET DST) In-Reply-To: <199606070108.JAA14446@ntuix.ntu.ac.sg> from "Willem van Schaik" at Jun 7, 96 09:08:23 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > It is only used by programmers and the error messages will hardly > reach application end-users. And programmers understand English like > "while, repeat, if, do, etc" don't they :-). Well, at least some messages will reach end users. Of course we could choose to make them more abstract so that only a few messages are needed (out-of-memory, bad file format, etc.) -- Francois Pottier Francois.Pottier@ens.fr Francois.Pottier@inria.fr http://www.eleves.ens.fr:8080/home/pottier/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 08:24:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA24322 for ; Fri, 7 Jun 1996 08:24:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA17145 for png-implement-outgoing; Fri, 7 Jun 1996 08:25:36 -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 IAA17140 for ; Fri, 7 Jun 1996 08:25:32 -0500 Received: from rs2.hrz.th-darmstadt.de by wugate.wustl.edu (8.6.12/8.6.11) with ESMTP id IAA27844 for ; Fri, 7 Jun 1996 08:23:43 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id PAA68549 for ; Fri, 7 Jun 1996 15:21:43 +0200 Received: from fb0410.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA074743704; Fri, 7 Jun 1996 15:21:44 +0200 Received: from localhost by fb0410.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA088633699; Fri, 7 Jun 1996 15:21:39 +0200 Date: Fri, 7 Jun 1996 15:21:39 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: libpng maintenace (was: Re: libpng localization) In-Reply-To: <199606061752.LAA05268@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List On Thu, 6 Jun 1996, Andreas Dilger wrote: > Not to sound negative, but if you feel this is important, please feel > free to contribute some code and translated error messages. While I > bit the bullet and updated libpng with most of the outstanding bugs, > I don't want to take on the whole development, and then fail to release > new versions as time passes because I'm too busy. > > Maybe it can be handled like pngcheck, or Linux, where everybody contributes > to the areas that they feel are important, and a new version is released > as required. This also has the added benefit that I don't spend time > working on code that people don't really use (like dithering - anyone use > the dithering code?). While distributing tasks between people is certain useful, I don't think it would be a good idea to have different people actually release versions, with a relatively simple program like pngcheck this would more or less, but when it becomes more complex, the risk of introducing incompatible changes and more importantly parallel fixes is much too great. (Even with pngcheck, I had some trouble to merge the changes from Greg and mine that were done independently around v1.6-v1.8). Taking Linux as an example, there are very many parts of it that are maintained by different people, but each package seems to have a more or less a responsible person and independent changes are usually released as patches. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 09:00:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA24655 for ; Fri, 7 Jun 1996 09:00:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA17685 for png-implement-outgoing; Fri, 7 Jun 1996 09:02:42 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA17680 for ; Fri, 7 Jun 1996 09:02:35 -0500 Date: Fri, 7 Jun 96 10:00:03 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: libpng localization Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606071000.aa22947@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > > Actually, while I was playing with XV, I was thinking if, rather than > PNG being a nice lossless format, we haven't made the most lossy format > available. The reason is that, as recommended by the PNG group, many > applications now handle the gamma correction of images. However, since > libpng does the correction while the image is being loaded, data is > lost unless the current display gamma matches that of the file. Then, > when the file is saved, it has a new gAMA chunk written out, and if it > is loaded again on another computer, it will again undergo a lossy > transformation. This is really far worse than using a GIF, where the > pixel values stay constant if you load and save the image any number of > times on several different computers. > > Cheers, Andreas. PNG is certainly not a lossy format. But if apps are applying gamma during the image reading step instead of during the display step, and the app writes gamma corrected files, then the app is doing the wrong thing. If libpng is doing that, it must be fixed, even if it requires a major rewrite of libpng. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 09:25:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA25094 for ; Fri, 7 Jun 1996 09:25:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA18018 for png-implement-outgoing; Fri, 7 Jun 1996 09:27:56 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA18013 for ; Fri, 7 Jun 1996 09:27:53 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id JAA01195 for ; Fri, 7 Jun 1996 09:25:12 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id JAA27035 for png-implement@dworkin.wustl.edu; Fri, 7 Jun 1996 09:26:08 -0500 (CDT) Date: Fri, 7 Jun 1996 09:26:08 -0500 (CDT) From: Cave Newt Message-Id: <199606071426.JAA27035@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: dithering & etc Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tom writes: > So the way I'd do it > is to read a 24-bit scanline from libpng, hand it off to QuantizeDither > in my hypothetical libraster-image-munger, and get back an 8-bit scanline > that goes into my final image. This needs only one scanline worth of > "extra" storage. That's entirely OK. I was thinking that the PNG side is always fully allocated since that's how it's usually implemented, but at least for non-interlaced images it doesn't have to be that way. (I never con- sidered epsilon == 1 pixel, btw.) > Or how about this: separate out the pngrtran functionality as a > library-within-a-library, that could be called directly if someone > wants to use it for non-PNG-source images. That approach could preserve > the current libpng API. (Hmm, maybe I should do that with the libjpeg > quantizers...) That would be an excellent solution, as far as I'm concerned. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 10:07:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA25613 for ; Fri, 7 Jun 1996 10:07:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA18694 for png-implement-outgoing; Fri, 7 Jun 1996 10:09:36 -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 KAA18687 for ; Fri, 7 Jun 1996 10:09:31 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id LAA07972 for ; Fri, 7 Jun 1996 11:07:13 -0400 (EDT) To: PNG Implementation List Subject: Re: dithering & etc (was Re: libpng localization) In-reply-to: Your message of Thu, 6 Jun 1996 20:18:18 -0600 (MDT) <199606070218.UAA06589@enel.ucalgary.ca> Date: Fri, 07 Jun 1996 11:07:13 -0400 Message-ID: <7970.834160033@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas wonders: > It basically > keeps only one error row, and an extra pixel to store the future error > for the current pixel (actually it's kind of hard to explain). Has anyone > heard of doing it this way before, or have I just re-invented the wheel? I'm afraid it's old hat. The IJG code has done it that way since early 1993, and I doubt I invented it... regards, tom lane Extract from IJG v4a jquant2.c, dated 17 Feb 1993: /* Declarations for Floyd-Steinberg dithering. * * Errors are accumulated into the array fserrors[], at a resolution of * 1/16th of a pixel count. The error at a given pixel is propagated * to its not-yet-processed neighbors using the standard F-S fractions, * ... (here) 7/16 * 3/16 5/16 1/16 * We work left-to-right on even rows, right-to-left on odd rows. * * We can get away with a single array (holding one row's worth of errors) * by using it to store the current row's errors at pixel columns not yet * processed, but the next row's errors at columns already processed. We * need only a few extra variables to hold the errors immediately around the * current column. (If we are lucky, those variables are in registers, but * even if not, they're probably cheaper to access than array elements are.) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 10:29:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA25791 for ; Fri, 7 Jun 1996 10:29:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA19064 for png-implement-outgoing; Fri, 7 Jun 1996 10:31:57 -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 KAA19059 for ; Fri, 7 Jun 1996 10:31:52 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.3/8.7.3) with ESMTP id LAA08061 for ; Fri, 7 Jun 1996 11:29:37 -0400 (EDT) To: PNG Implementation List Subject: gamma and lossiness (was Re: libpng localization) In-reply-to: Your message of Fri, 7 Jun 96 10:00:03 EDT <9606071000.aa22947@THOR.ARL.MIL> Date: Fri, 07 Jun 1996 11:29:37 -0400 Message-ID: <8059.834161377@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Glenn writes: > PNG is certainly not a lossy format. But if apps are applying gamma > during the image reading step instead of during the display step, and > the app writes gamma corrected files, then the app is doing the wrong > thing. If libpng is doing that, it must be fixed, even if it requires > a major rewrite of libpng. libpng offers an *optional* service of correcting to an application-selected gamma during image reading. If you don't call png_set_gamma, it doesn't apply this transformation. As Andreas points out, it's a lousy idea for image editors to make use of this service. What they have to do is read the unmodified image into their workspace, then apply gamma correction on-the-fly during display. Changing the gamma of the working image must be done only on user command. (Photoshop works this way, for example.) I think this is another argument for the notion of pulling quantization, gamma correction, and other post-decoding services out to a separate library. That might make it a little more obvious that these are lossy transformations, not an alternative form of the same data. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 10:52:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA00266 for ; Fri, 7 Jun 1996 10:52:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA19351 for png-implement-outgoing; Fri, 7 Jun 1996 10:54:17 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA19343 for ; Fri, 7 Jun 1996 10:54:12 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id JAA07836; Fri, 7 Jun 1996 09:51:58 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606071551.JAA07836@enel.ucalgary.ca> Subject: Re: libpng localization To: png-implement@dworkin.wustl.edu Date: Fri, 7 Jun 1996 09:51:57 -0600 (MDT) In-Reply-To: <199606071046.MAA13925@clipper.ens.fr> from "Francois Pottier" at Jun 7, 96 12:46:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Francios, you write: > Well, I'd like to give it a try, but I don't know where to download > 0.89. I only see 0.88 on swrinde.nde.swri.edu. Can you give me a URL? We currently are using libpng 0.89 at ftp://swrinde.nde.swri.edu/pub/png-group/src/ The reason it is not in the public area is to have a short test period before making a public distribution to catch any small bugs before it is released (like the makefile and pngtest.png problems that were found immediately after release). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 10:54:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA00432 for ; Fri, 7 Jun 1996 10:54:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA19382 for png-implement-outgoing; Fri, 7 Jun 1996 10:57:04 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA19371 for ; Fri, 7 Jun 1996 10:56:58 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id JAA07845; Fri, 7 Jun 1996 09:54:44 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606071554.JAA07845@enel.ucalgary.ca> Subject: interlace bug in 0.89 To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Fri, 7 Jun 1996 09:54:44 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, I just thought I'd let you know that there is a bug with interlaced images and the UP, AVG, and PAETH filter types. I am just working on this now, and I will upload a new version of libpng with the fix as soon as I have it (along with the other minor problems reported here). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 11:27:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA00861 for ; Fri, 7 Jun 1996 11:27:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA20020 for png-implement-outgoing; Fri, 7 Jun 1996 11:29:24 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA20010 for ; Fri, 7 Jun 1996 11:29:18 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id SAA07984; Fri, 7 Jun 1996 18:27:03 +0200 Date: Fri, 7 Jun 1996 18:27:03 +0200 From: Chris Lilley Message-Id: <199606071627.SAA07984@www47.inria.fr> To: PNG Implementation List Subject: Localization (Re: new libpng, pngcheck, xv patch) In-Reply-To: <29189.834072424@sss.pgh.pa.us> References: <199606061147.NAA26928@clipper.ens.fr> <29189.834072424@sss.pgh.pa.us> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tom Lane writes: > Right. Instead of > png_error(pngptr, "Blah blah blah"); > you write > png_error(pngptr, PNGERROR_BLAH_BLAH_BLAH); > where the constant is defined in pngerror.h, and is used as an index > into an error message table by png_error. Localization of the library > then only requires substituting a different message table in png_error, > and can even be done at runtime. > For C code specifics, you might find some useful ideas in jerror.h and > jerror.c in the IJG JPEG library v6 or later. The IJG code is not > localized as distributed, but could easily be localized if anyone bothered > to put together an alternate message table. Speaking of which, please find encloded a sample of such a thing: jerror-nl.h which I enclose here just to show it can be done. If I get others, I will put them up on a Web site. /* * jerror.h * * Copyright (C) 1994-1995, Thomas G. Lane. * Translation to Dutch: 1996, Bert Bos (W3C) * This file is part of the Independent JPEG Group's software. * For conditions of distribution and use, see the accompanying README file. * * This file defines the error and message codes for the JPEG library. * Edit this file to add new codes, or to translate the message strings to * some other language. * A set of error-reporting macros are defined too. Some applications using * the JPEG library may wish to include this file to get the error codes * and/or the macros. */ /* * To define the enum list of message codes, include this file without * defining macro JMESSAGE. To create a message string table, include it * again with a suitable JMESSAGE definition (see jerror.c for an example). */ #ifndef JMESSAGE #ifndef JERROR_H /* First time through, define the enum list */ #define JMAKE_ENUM_LIST #else /* Repeated inclusions of this file are no-ops unless JMESSAGE is defined */ #define JMESSAGE(code,string) #endif /* JERROR_H */ #endif /* JMESSAGE */ #ifdef JMAKE_ENUM_LIST typedef enum { #define JMESSAGE(code,string) code , #endif /* JMAKE_ENUM_LIST */ JMESSAGE(JMSG_NOMESSAGE, "Onbekende berichtcode") /* Bogus message code %d */ /* Must be first entry! */ /* For maintenance convenience, list is alphabetical by message code name */ JMESSAGE(JERR_ARITH_NOTIMPL, "Sorry, er zijn juridische beperkingen voor Arithmetic Coding") /* Sorry, there are legal restrictions on arithmetic coding */ JMESSAGE(JERR_BAD_ALIGN_TYPE, "ALIGN_TYPE is verkeerd, kies een andere waarde") /* ALIGN_TYPE is wrong, please fix */ JMESSAGE(JERR_BAD_ALLOC_CHUNK, "MAX_ALLOC_CHUNK is verkeerd, kies een andere waarde") /* MAX_ALLOC_CHUNK is wrong, please fix */ JMESSAGE(JERR_BAD_BUFFER_MODE, "Onbekende modus voor buffer-controle") /* Bogus buffer control mode */ JMESSAGE(JERR_BAD_COMPONENT_ID, "Verkeerd identificatienummer voor een component in SOS") /* Invalid component ID %d in SOS */ JMESSAGE(JERR_BAD_DCTSIZE, "Grootte %d voor IDCT output-blok wordt niet ondersteund") /* IDCT output block size %d not supported */ JMESSAGE(JERR_BAD_IN_COLORSPACE, "Onbekend kleurensysteeem voor input") /* Bogus input colorspace */ JMESSAGE(JERR_BAD_J_COLORSPACE, "Onbekend kleurensysteem voor JPEG") /* Bogus JPEG colorspace */ JMESSAGE(JERR_BAD_LENGTH, "Verkeerde lengte voor een markeerpunt (marker)") /* Bogus marker length */ JMESSAGE(JERR_BAD_LIB_VERSION, "Verkeerde versie van de JPEG-bibliotheek: %d, moet zijn: %d") /* Wrong JPEG library version: library is %d, caller expects %d */ JMESSAGE(JERR_BAD_MCU_SIZE, "Meetfactoren te groot voor een `interleaved scan'") /* Sampling factors too large for interleaved scan */ JMESSAGE(JERR_BAD_POOL_ID, "Verkeerde code (%d) voor geheugenpool") /* Invalid memory pool code %d */ JMESSAGE(JERR_BAD_PRECISION, "Precisie %d voor JPEG data wordt niet ondersteund.") /* Unsupported JPEG data precision %d */ JMESSAGE(JERR_BAD_PROGRESSION, "Verkeerde parameters voor pogressieve JPEG: Ss=%d Se=%d Ah=%d Al=%d") /* Invalid progressive parameters Ss=%d Se=%d Ah=%d Al=%d */ JMESSAGE(JERR_BAD_PROG_SCRIPT, "Verkeerde parameters voor progressieve JPEG in `scan script' item %d") /* Invalid progressive parameters at scan script entry %d */ JMESSAGE(JERR_BAD_SAMPLING, "Verkeerde meetfactoren") /* Bogus sampling factors */ JMESSAGE(JERR_BAD_SCAN_SCRIPT, "Verkeerd `scan script' item %d") /* Invalid scan script at entry %d */ JMESSAGE(JERR_BAD_STATE, "Onjuiste aanroep van JPEG-bibliotheek in toestandscode %d") /* Improper call to JPEG library in state %d */ JMESSAGE(JERR_BAD_STRUCT_SIZE, "JPEG-parameter blokken komen niet overeen: bibliotheek heeft grootte %u, applicatie verwacht grootte %u") /* JPEG parameter struct mismatch: library thinks size is %u, caller expects %u */ JMESSAGE(JERR_BAD_VIRTUAL_ACCESS, "Onjuiste uitlezing van virtueel `array'") /* Bogus virtual array access */ JMESSAGE(JERR_BUFFER_SIZE, "De door de applicatie aangeboden buffer is te klein voor de JPEG-bibliotheek") /* Buffer passed to JPEG library is too small */ JMESSAGE(JERR_CANT_SUSPEND, "Onderbreking is niet mogelijk op dit punt") /* Suspension not allowed here */ JMESSAGE(JERR_CCIR601_NOTIMPL, "CCIR601-meting is nog niet geïmplementeerd") /* CCIR601 sampling not implemented yet */ JMESSAGE(JERR_COMPONENT_COUNT, "Te veel kleur-componenten: %d, maximum %d") /* Too many color components: %d, max %d */ JMESSAGE(JERR_CONVERSION_NOTIMPL, "Gevraagde kleurconversie wordt niet ondersteund") /* Unsupported color conversion request */ JMESSAGE(JERR_DAC_INDEX, "Onjuiste DAC-index: %d") /* Bogus DAC index %d */ JMESSAGE(JERR_DAC_VALUE, "Onjuiste DAC-waarde: 0x%x") /* Bogus DAC value 0x%x */ JMESSAGE(JERR_DHT_COUNTS, "Onjuist aantal voor DHT") /* Bogus DHT counts */ JMESSAGE(JERR_DHT_INDEX, "Onjuiste DHT-index: %d") /* Bogus DHT index %d */ JMESSAGE(JERR_DQT_INDEX, "Onjuiste DQT-index: %d") /* Bogus DQT index %d */ JMESSAGE(JERR_EMPTY_IMAGE, "Lege JPEG-afbeelding (DNL wordt niet ondersteund)") /* Empty JPEG image (DNL not supported) */ JMESSAGE(JERR_EMS_READ, "Lezen van EMS niet gelukt") /* Read from EMS failed */ JMESSAGE(JERR_EMS_WRITE, "Schrijven naar EMS niet gelukt") /* Write to EMS failed */ JMESSAGE(JERR_EOI_EXPECTED, "Onverwachte tweede `scan'") /* Didn't expect more than one scan */ JMESSAGE(JERR_FILE_READ, "Fout bij lezen van input-file") /* Input file read error */ JMESSAGE(JERR_FILE_WRITE, "Fout bij schrijven van output-file -- onvoldoende schijfruimte?") /* Output file write error --- out of disk space? */ JMESSAGE(JERR_FRACT_SAMPLE_NOTIMPL, "Alleen meting met gehele getallen is geïmplementeerd") /* Fractional sampling not implemented yet */ JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman-codetabel is vol") /* Huffman code size table overflow */ JMESSAGE(JERR_HUFF_MISSING_CODE, "Ontbrekend item in Huffman-codetabel") /* Missing Huffman code table entry */ JMESSAGE(JERR_IMAGE_TOO_BIG, "Maximaal ondersteunde grootte voor een afbeelding is %u pixels") /* Maximum supported image dimension is %u pixels */ JMESSAGE(JERR_INPUT_EMPTY, "Lege input-file") /* Empty input file */ JMESSAGE(JERR_INPUT_EOF, "Onverwacht einde van de input-file") /* Premature end of input file */ JMESSAGE(JERR_MISMATCHED_QUANT_TABLE, "Transcodering onmogelijk als gevolg van dubbel gebruik van kwantificatie-tabel %d") /* Cannot transcode due to multiple use of quantization table %d */ JMESSAGE(JERR_MISSING_DATA, "`Scan script' geeft niet alle data door") /* Scan script does not transmit all data */ JMESSAGE(JERR_MODE_CHANGE, "Onjuiste verandering van modus voor kleurkwantificatie") /* Invalid color quantization mode change */ JMESSAGE(JERR_NOTIMPL, "Nog niet geïmplementeerd") /* Not implemented yet */ JMESSAGE(JERR_NOT_COMPILED, "Gevraagde eigenschap is weggelaten bij het compileren") /* Requested feature was omitted at compile time */ JMESSAGE(JERR_NO_BACKING_STORE, "Achtergrond-geheugen (backing store) wordt niet ondersteund") /* Backing store not supported */ JMESSAGE(JERR_NO_HUFF_TABLE, "Huffman-tabel 0x%02x is niet gedefiniëerd") /* Huffman table 0x%02x was not defined */ JMESSAGE(JERR_NO_IMAGE, "JPEG-data bevat geen afbeelding") /* JPEG datastream contains no image */ JMESSAGE(JERR_NO_QUANT_TABLE, "Kwantificatietabel 0x%02x is niet gedefiniëerd") /* Quantization table 0x%02x was not defined */ JMESSAGE(JERR_NO_SOI, "Geen JPEG-file: begint met 0x%02x 0x%02x") /* Not a JPEG file: starts with 0x%02x 0x%02x */ JMESSAGE(JERR_OUT_OF_MEMORY, "Onvoldoende geheugen (geval %d)") /* Insufficient memory (case %d) */ JMESSAGE(JERR_QUANT_COMPONENTS, "Het is niet mogelijk meer dan %d kleurcomponenten te kwantificeren") /* Cannot quantize more than %d color components */ JMESSAGE(JERR_QUANT_FEW_COLORS, "Het is niet mogelijk naar minder dan %d kleuren te kwantificeren") /* Cannot quantize to fewer than %d colors */ JMESSAGE(JERR_QUANT_MANY_COLORS, "Het is niet mogelijk naar meer dan %d kleuren te kwantificeren") /* Cannot quantize to more than %d colors */ JMESSAGE(JERR_SOF_DUPLICATE, "Onjuiste JPEG-file: twee SOF-markeerpunten") /* Invalid JPEG file structure: two SOF markers */ JMESSAGE(JERR_SOF_NO_SOS, "Onjuiste JPEG-file: SOF-markeerpunt ontbreekt") /* Invalid JPEG file structure: missing SOS marker */ JMESSAGE(JERR_SOF_UNSUPPORTED, "Dit JPEG proces wordt niet ondersteund: SOF-type 0x%02x") /* Unsupported JPEG process: SOF type 0x%02x */ JMESSAGE(JERR_SOI_DUPLICATE, "Onjuiste structuur voor JPEG-file: twee SOI-markeerpunten") /* Invalid JPEG file structure: two SOI markers */ JMESSAGE(JERR_SOS_NO_SOF, "Onjuiste structuur voor JPEG-file: SOS vóór SOF") /* Invalid JPEG file structure: SOS before SOF */ JMESSAGE(JERR_TFILE_CREATE, "Kan geen tijdelijke file %s maken") /* Failed to create temporary file %s */ JMESSAGE(JERR_TFILE_READ, "Lezen van tijdelijke file niet gelukt") /* Read failed on temporary file */ JMESSAGE(JERR_TFILE_SEEK, "Positionering in tijdelijke file niet gelukt") /* Seek failed on temporary file */ JMESSAGE(JERR_TFILE_WRITE, "Schrijven van tijdelijk file niet gelukt -- onvoldoende schijfruimte?") /* Write failed on temporary file --- out of disk space? */ JMESSAGE(JERR_TOO_LITTLE_DATA, "De applicatie leverde te weinig beeldlijnen") /* Application transferred too few scanlines */ JMESSAGE(JERR_UNKNOWN_MARKER, "Merkeerpunt van type 0x%02x wordt niet ondersteund") /* Unsupported marker type 0x%02x */ JMESSAGE(JERR_VIRTUAL_BUG, "Regelaar voor virtueel `array' werkt niet goed") /* Virtual array controller messed up */ JMESSAGE(JERR_WIDTH_OVERFLOW, "Afbeelding is te breed voor deze implementatie") /* Image too wide for this implementation */ JMESSAGE(JERR_XMS_READ, "Lezen van XMS mislukt") /* Read from XMS failed */ JMESSAGE(JERR_XMS_WRITE, "Schrijven naar XMS mislukt") /* Write to XMS failed */ JMESSAGE(JMSG_COPYRIGHT, JCOPYRIGHT) JMESSAGE(JMSG_VERSION, JVERSION) JMESSAGE(JTRC_16BIT_TABLES, "kwantificatietabellen zijn te onnnauwkeuring voor basis-JPEG") /* Caution: quantization tables are too coarse for baseline JPEG */ JMESSAGE(JTRC_ADOBE, "Adobe APP14 markeerpunt: versie %d, vlaggen 0x%04x 0x%04x, transformatie %d") /* Adobe APP14 marker: version %d, flags 0x%04x 0x%04x, transform %d */ JMESSAGE(JTRC_APP0, "Onbekend APP0 markeerpunt (geen JFIF), lengte %u") /* Unknown APP0 marker (not JFIF), length %u */ JMESSAGE(JTRC_APP14, "Onbekend APP14 markeerpunt (geen Adobe), lengte %u") /* Unknown APP14 marker (not Adobe), length %u */ JMESSAGE(JTRC_DAC, "Definiëren van Arithmetic Table 0x%02x: 0x%02x") /* Define Arithmetic Table 0x%02x: 0x%02x */ JMESSAGE(JTRC_DHT, "Definiëren van Huffmantabel 0x%02x") /* Define Huffman Table 0x%02x */ JMESSAGE(JTRC_DQT, "Definiëren van kwantificatietabel %d precisie %d") /* Define Quantization Table %d precision %d */ JMESSAGE(JTRC_DRI, "Definiëren van herstart-interval %u") /* Define Restart Interval %u */ JMESSAGE(JTRC_EMS_CLOSE, "EMS-hendel %u vrijgegeven") /* Freed EMS handle %u */ JMESSAGE(JTRC_EMS_OPEN, "EMS-hendel %u gekregen") /* Obtained EMS handle %u */ JMESSAGE(JTRC_EOI, "Einde van afbeelding (EOI)") /* End Of Image */ JMESSAGE(JTRC_HUFFBITS, " %3d %3d %3d %3d %3d %3d %3d %3d") JMESSAGE(JTRC_JFIF, "JFIF APP0-markeerpunt, dichtheid %dx%d %d") /* JFIF APP0 marker, density %dx%d %d */ JMESSAGE(JTRC_JFIF_BADTHUMBNAILSIZE, "Waarschuwing: grootte van mini-afbeelding komt niet overeen met data-lengte %u") /* Warning: thumbnail image size does not match data length %u */ JMESSAGE(JTRC_JFIF_MINOR, "Onbekende JFIF-revisie nummer %d.%02d") /* Unknown JFIF minor revision number %d.%02d */ JMESSAGE(JTRC_JFIF_THUMBNAIL, " met %d x %d mini-afbeelding") /* with %d x %d thumbnail image */ JMESSAGE(JTRC_MISC_MARKER, "Markeerpunt 0x%02x, lengte %u, wordt overgeslagen") /* Skipping marker 0x%02x, length %u */ JMESSAGE(JTRC_PARMLESS_MARKER, "Onverwacht markeerpunt 0x%02x") /* Unexpected marker 0x%02x */ JMESSAGE(JTRC_QUANTVALS, " %4u %4u %4u %4u %4u %4u %4u %4u") JMESSAGE(JTRC_QUANT_3_NCOLORS, "Bezig met kwantificatie naar %d = %d*%d*%d kleuren") /* Quantizing to %d = %d*%d*%d colors */ JMESSAGE(JTRC_QUANT_NCOLORS, "Bezig met kwantificatie naar %d kleuren") /* Quantizing to %d colors */ JMESSAGE(JTRC_QUANT_SELECTED, "%d kleuren voor kwantificatie gekozen") /* Selected %d colors for quantization */ JMESSAGE(JTRC_RECOVERY_ACTION, "Bij markeerpunt 0x%02x, herstelactie %d") /* At marker 0x%02x, recovery action %d */ JMESSAGE(JTRC_RST, "RST%d") JMESSAGE(JTRC_SMOOTH_NOTIMPL, "Egalisatie wordt alleen ondersteund voor standaard meetverhoudingen") /* Smoothing not supported with nonstandard sampling ratios */ JMESSAGE(JTRC_SOF, "Begin van blok 0x%02x: breedte=%u, hooghte=%u, component=%d") /* Start Of Frame 0x%02x: width=%u, height=%u, components=%d */ JMESSAGE(JTRC_SOF_COMPONENT, " Component %d: %dhx%dv q=%d") /* Component %d: %dhx%dv q=%d */ JMESSAGE(JTRC_SOI, "Begin van afbeelding (SOI)") /* Start of Image */ JMESSAGE(JTRC_SOS, "Begin van `scan (SOS): %d componenten") /* Start Of Scan: %d components */ JMESSAGE(JTRC_SOS_COMPONENT, " Component %d: dc=%d ac=%d")") /* JMESSAGE(JTRC_SOS_PARAMS, " Ss=%d, Se=%d, Ah=%d, Al=%d */ JMESSAGE(JTRC_TFILE_CLOSE, "Tijdelijke file %s gesloten") /* Closed temporary file %s */ JMESSAGE(JTRC_TFILE_OPEN, "Tijdelijke file %s geopend") /* Opened temporary file %s */ JMESSAGE(JTRC_UNKNOWN_IDS, "Onbekende identificatie-nummers %d %d %d voor een component, vervangen door YCbCr") /* Unrecognized component IDs %d %d %d, assuming YCbCr */ JMESSAGE(JTRC_XMS_CLOSE, "XMS-hendel %u vrijgegeven") /* Freed XMS handle %u */ JMESSAGE(JTRC_XMS_OPEN, "XMS-hendel %u gekregen") /* Obtained XMS handle %u */ JMESSAGE(JWRN_ADOBE_XFORM, "Onbekende Adobe kleurtransformatie %d") /* Unknown Adobe color transform code %d */ JMESSAGE(JWRN_BOGUS_PROGRESSION, "Inconsequentie in progressie-volgorder voor component %d coëfficient %d") /* Inconsistent progression sequence for component %d coefficient %d */ JMESSAGE(JWRN_EXTRANEOUS_DATA, "Onjuiste JPEG-data: %u overbodige bytes voor markeerpunt 0x%02x") /* Corrupt JPEG data: %u extraneous bytes before marker 0x%02x */ JMESSAGE(JWRN_HIT_MARKER, "Onjuiste JPEG-data: onverwacht einde van data-segment") /* Corrupt JPEG data: premature end of data segment */ JMESSAGE(JWRN_HUFF_BAD_CODE, "Onjuiste JPEG-data: verkeerde Huffmancode") /* Corrupt JPEG data: bad Huffman code */ JMESSAGE(JWRN_JFIF_MAJOR, "Waarschuwing: onbekende revisie %d.%02d van JFIF") /* Warning: unknown JFIF revision number %d.%02d */ JMESSAGE(JWRN_JPEG_EOF, "Onverwacht einde van JPEG-file") /* Premature end of JPEG file */ JMESSAGE(JWRN_MUST_RESYNC, "Onjuiste JPEG-data: markeerpunt 0x%02x in plaats van RST%d") /* Corrupt JPEG data: found marker 0x%02x instead of RST%d */ JMESSAGE(JWRN_NOT_SEQUENTIAL, "Onjuiste SOS-parameters voor sequentiële JPEG") /* Invalid SOS parameters for sequential JPEG */ JMESSAGE(JWRN_TOO_MUCH_DATA, "Applicatie leverde te veel beeldlijnen") /* Application transferred too many scanlines */ #ifdef JMAKE_ENUM_LIST JMSG_LASTMSGCODE } J_MESSAGE_CODE; #undef JMAKE_ENUM_LIST #endif /* JMAKE_ENUM_LIST */ /* Zap JMESSAGE macro so that future re-inclusions do nothing by default */ #undef JMESSAGE #ifndef JERROR_H #define JERROR_H /* Macros to simplify using the error and trace message stuff */ /* The first parameter is either type of cinfo pointer */ /* Fatal errors (print message and exit) */ #define ERREXIT(cinfo,code) \ ((cinfo)->err->msg_code = (code), \ (*(cinfo)->err->error_exit) ((j_common_ptr) (cinfo))) #define ERREXIT1(cinfo,code,p1) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (*(cinfo)->err->error_exit) ((j_common_ptr) (cinfo))) #define ERREXIT2(cinfo,code,p1,p2) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (cinfo)->err->msg_parm.i[1] = (p2), \ (*(cinfo)->err->error_exit) ((j_common_ptr) (cinfo))) #define ERREXIT3(cinfo,code,p1,p2,p3) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (cinfo)->err->msg_parm.i[1] = (p2), \ (cinfo)->err->msg_parm.i[2] = (p3), \ (*(cinfo)->err->error_exit) ((j_common_ptr) (cinfo))) #define ERREXIT4(cinfo,code,p1,p2,p3,p4) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (cinfo)->err->msg_parm.i[1] = (p2), \ (cinfo)->err->msg_parm.i[2] = (p3), \ (cinfo)->err->msg_parm.i[3] = (p4), \ (*(cinfo)->err->error_exit) ((j_common_ptr) (cinfo))) #define ERREXITS(cinfo,code,str) \ ((cinfo)->err->msg_code = (code), \ strncpy((cinfo)->err->msg_parm.s, (str), JMSG_STR_PARM_MAX), \ (*(cinfo)->err->error_exit) ((j_common_ptr) (cinfo))) #define MAKESTMT(stuff) do { stuff } while (0) /* Nonfatal errors (we can keep going, but the data is probably corrupt) */ #define WARNMS(cinfo,code) \ ((cinfo)->err->msg_code = (code), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), -1)) #define WARNMS1(cinfo,code,p1) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), -1)) #define WARNMS2(cinfo,code,p1,p2) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (cinfo)->err->msg_parm.i[1] = (p2), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), -1)) /* Informational/debugging messages */ #define TRACEMS(cinfo,lvl,code) \ ((cinfo)->err->msg_code = (code), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl))) #define TRACEMS1(cinfo,lvl,code,p1) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl))) #define TRACEMS2(cinfo,lvl,code,p1,p2) \ ((cinfo)->err->msg_code = (code), \ (cinfo)->err->msg_parm.i[0] = (p1), \ (cinfo)->err->msg_parm.i[1] = (p2), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl))) #define TRACEMS3(cinfo,lvl,code,p1,p2,p3) \ MAKESTMT(int * _mp = (cinfo)->err->msg_parm.i; \ _mp[0] = (p1); _mp[1] = (p2); _mp[2] = (p3); \ (cinfo)->err->msg_code = (code); \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl)); ) #define TRACEMS4(cinfo,lvl,code,p1,p2,p3,p4) \ MAKESTMT(int * _mp = (cinfo)->err->msg_parm.i; \ _mp[0] = (p1); _mp[1] = (p2); _mp[2] = (p3); _mp[3] = (p4); \ (cinfo)->err->msg_code = (code); \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl)); ) #define TRACEMS8(cinfo,lvl,code,p1,p2,p3,p4,p5,p6,p7,p8) \ MAKESTMT(int * _mp = (cinfo)->err->msg_parm.i; \ _mp[0] = (p1); _mp[1] = (p2); _mp[2] = (p3); _mp[3] = (p4); \ _mp[4] = (p5); _mp[5] = (p6); _mp[6] = (p7); _mp[7] = (p8); \ (cinfo)->err->msg_code = (code); \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl)); ) #define TRACEMSS(cinfo,lvl,code,str) \ ((cinfo)->err->msg_code = (code), \ strncpy((cinfo)->err->msg_parm.s, (str), JMSG_STR_PARM_MAX), \ (*(cinfo)->err->emit_message) ((j_common_ptr) (cinfo), (lvl))) #endif /* JERROR_H */ -- Chris Lilley, W3C [ http://www.w3.org/ ] http://www.w3.org/people/chris/ INRIA/W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 11:41:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA01002 for ; Fri, 7 Jun 1996 11:41:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA20284 for png-implement-outgoing; Fri, 7 Jun 1996 11:42:36 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA20278 for ; Fri, 7 Jun 1996 11:42:31 -0500 Date: Fri, 7 Jun 96 12:37:20 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: new libpng, pngcheck, xv patch Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606071237.aa27063@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List libpng 0.89 fails "make test" on my SGI IRIX 5.3 I fixed the missing backslash that willem pointed out. The reason for the failure is that pngtest.png has a single IDAT, length 8547, while pngout.png has two (8192 + 355 = 8547) (Both files would yield the same "fING" fingerprint) ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 12:05:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA01184 for ; Fri, 7 Jun 1996 12:05:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA20580 for png-implement-outgoing; Fri, 7 Jun 1996 12:06:26 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA20569 for ; Fri, 7 Jun 1996 12:06:08 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id TAA55816 for ; Fri, 7 Jun 1996 19:03:50 +0200 Received: from fb0409.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA094487031; Fri, 7 Jun 1996 19:03:51 +0200 Received: from localhost by fb0409.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA057247027; Fri, 7 Jun 1996 19:03:47 +0200 Date: Fri, 7 Jun 1996 19:03:46 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: gamma and lossiness (was Re: libpng localization) In-Reply-To: <8059.834161377@sss.pgh.pa.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List On Fri, 7 Jun 1996, Tom Lane wrote: > Glenn writes: > > PNG is certainly not a lossy format. But if apps are applying gamma > > during the image reading step instead of during the display step, and > > the app writes gamma corrected files, then the app is doing the wrong > > thing. If libpng is doing that, it must be fixed, even if it requires > > a major rewrite of libpng. > > libpng offers an *optional* service of correcting to an > application-selected gamma during image reading. If you don't call > png_set_gamma, it doesn't apply this transformation. > > As Andreas points out, it's a lousy idea for image editors to make use of > this service. What they have to do is read the unmodified image into > their workspace, then apply gamma correction on-the-fly during display. > Changing the gamma of the working image must be done only on user > command. (Photoshop works this way, for example.) But to add this feature to basically any editor will require a major rewrite of the display code. E.g. xv supports gamma correction by setting a gamma value in the color editor and the probably will save the file with the corrected value (which is correct for anything except PNG and TIFF, I guess). Maybe it would be possible to have an option to load the image without gamma correction and set the default gamma value that is used when storing the image. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 12:11:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA01222 for ; Fri, 7 Jun 1996 12:11:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA20643 for png-implement-outgoing; Fri, 7 Jun 1996 12:12:29 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA20636 for ; Fri, 7 Jun 1996 12:12:17 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id TAA68268 for ; Fri, 7 Jun 1996 19:10:03 +0200 Received: from fb0409.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA096447404; Fri, 7 Jun 1996 19:10:04 +0200 Received: from localhost by fb0409.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA057467401; Fri, 7 Jun 1996 19:10:01 +0200 Date: Fri, 7 Jun 1996 19:10:01 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: pbm libraries (was: Re: libpng localization) In-Reply-To: <199606070126.TAA06483@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List On Thu, 6 Jun 1996, Andreas Dilger wrote: > Willem writes: > > >> (This reminds me - ppmtopng and pngtoppm require > > >> a file "pnmpalette.h" or similar, that I haven't been able to find > > >> in the latest version of netpbm. Where is this file?) > > Never heard of it either :-). And I think I should know 8-). But which > > version of netpbm are you using? > > Actually, the file is ppmcmap.h that I'm missing for pnmtopng.c. I have > p[bgnp]m.h and pbmplus.h, but not ppmcmap.h. I would guess that whoever put together the precompiled version of the pbm libs has forgotten to include the file, you can simply get it from the current netpbm distribution, I would guess (ftp://ftp.x.org/contrib/utilities/netpbm-1mar1994.p1.tar.gz). bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 15:30:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03921 for ; Fri, 7 Jun 1996 15:30:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA23596 for png-implement-outgoing; Fri, 7 Jun 1996 15:32:15 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA23591 for ; Fri, 7 Jun 1996 15:32:08 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id OAA08784; Fri, 7 Jun 1996 14:29:53 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606072029.OAA08784@enel.ucalgary.ca> Subject: Yet newer libpng, xv To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Fri, 7 Jun 1996 14:29:52 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I have uploaded libpng-0.89a and xv-3.10a-png-1.2a to swrinde in the incoming directory. We can leave them in the png-group/src and png-group/applications respectively for a couple more days, and if no further problems are found, they can be moved to the public dirs. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 18:30:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA06188 for ; Fri, 7 Jun 1996 18:30:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA26972 for png-implement-outgoing; Fri, 7 Jun 1996 18:32:46 -0500 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA26966 for ; Fri, 7 Jun 1996 18:32:43 -0500 Received: by iguana.reptiles.org (/\##/\ Smail3.1.30.13 #30.5) id ; Fri, 7 Jun 96 19:30:26 -0400 (EDT) Message-Id: Date: Fri, 7 Jun 96 19:30:22 -0400 (EDT) From: smar@reptiles.org (Smarasderagd) To: png-implement@dworkin.wustl.edu Subject: Re: gamma and lossiness (was Re: libpng localization) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I agree that quantization, gamma correction, and other post-processing aren't necessary, but I would miss background colour processing. libpng doesn't as far as I know have any way of simply discarding a provided or generated alpha channel. To make the output fit with whatever program I'm using, I've supplied a background colour (usually black, unless the image supplies one) and gone through some rather intricate contortions to ensure that an alpha channel doesn't get generated if it isn't useful. If the library could discard alpha, I wouldn't mind if background colour processing went away. In that case, though, it should offer some way of transforming any bKGD chunk supplied (expand, gray-to-rgb, etc.) along with the image. libpng-0.89a may solve some of these problems (I haven't tried it yet) but I thought I should bring it up if we're talking about removing post-processing stuff. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 18:39:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA06211 for ; Fri, 7 Jun 1996 18:39:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA27024 for png-implement-outgoing; Fri, 7 Jun 1996 18:41:16 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA27019 for ; Fri, 7 Jun 1996 18:41:12 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA09231; Fri, 7 Jun 1996 17:38:56 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606072338.RAA09231@enel.ucalgary.ca> Subject: Re: Yet newer libpng, xv To: png-implement@dworkin.wustl.edu Date: Fri, 7 Jun 1996 17:38:56 -0600 (MDT) In-Reply-To: <199606072029.OAA08784@enel.ucalgary.ca> from "Andreas Dilger" at Jun 7, 96 02:29:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I write (a bit too soon, it seems): > I have uploaded libpng-0.89a and xv-3.10a-png-1.2a to swrinde in the > incoming directory. We can leave them in the png-group/src and > png-group/applications respectively for a couple more days, and if no > further problems are found, they can be moved to the public dirs. I've fixed another minor problem in libpng-0.89a that was a result of fixing the previous problem. I've also made cosmetic changes to the XV patch (recommend compression values in the range 2-7 instead of 4-9), and add a note that 0 = uncompressed (for those people who don't know whether 0 or 9 is the maximum compression value). Hopefully this is it. New files are in incoming/png at swrinde (hopefully nobody has even downloaded the 'a' revisions). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 7 20:41:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA06721 for ; Fri, 7 Jun 1996 20:41:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA28298 for png-implement-outgoing; Fri, 7 Jun 1996 20:43:12 -0500 Received: from mht3.gintic.ntu.ac.sg ([155.69.28.109]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA28292 for ; Fri, 7 Jun 1996 20:42:45 -0500 Received: (from willem@localhost) by mht3.gintic.ntu.ac.sg (8.7.4/8.7.3) id JAA00647 for png-implement@dworkin.wustl.edu; Sat, 8 Jun 1996 09:35:04 +0800 Date: Sat, 8 Jun 1996 09:35:04 +0800 From: Willem van Schaik Message-Id: <199606080135.JAA00647@mht3.gintic.ntu.ac.sg> To: png-implement@dworkin.wustl.edu Subject: pbm libraries, here is ppmcmap.h Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Because I got difficulties to get into ftp.x.org, where I wanted to check the path-name to the netpbm library, I have attached here the ppmcmap.h file that some people don't have. It's quite short. Willem ------------------------------------------ /* ppmcmap.h - header file for colormap routines in libppm */ /* Color histogram stuff. */ typedef struct colorhist_item* colorhist_vector; struct colorhist_item { pixel color; int value; }; typedef struct colorhist_list_item* colorhist_list; struct colorhist_list_item { struct colorhist_item ch; colorhist_list next; }; colorhist_vector ppm_computecolorhist ARGS(( pixel** pixels, int cols, int rows, int maxcolors, int* colorsP )); /* Returns a colorhist *colorsP long (with space allocated for maxcolors. */ void ppm_addtocolorhist ARGS(( colorhist_vector chv, int* colorsP, int maxcolors, pixel* colorP, int value, int position )); void ppm_freecolorhist ARGS(( colorhist_vector chv )); /* Color hash table stuff. */ typedef colorhist_list* colorhash_table; colorhash_table ppm_computecolorhash ARGS(( pixel** pixels, int cols, int rows, int maxcolors, int* colorsP )); int ppm_lookupcolor ARGS(( colorhash_table cht, pixel* colorP )); colorhist_vector ppm_colorhashtocolorhist ARGS(( colorhash_table cht, int maxcolors )); colorhash_table ppm_colorhisttocolorhash ARGS(( colorhist_vector chv, int colors )); int ppm_addtocolorhash ARGS(( colorhash_table cht, pixel* colorP, int value )); /* Returns -1 on failure. */ colorhash_table ppm_alloccolorhash ARGS(( void )); void ppm_freecolorhash ARGS(( colorhash_table cht )); ------------------------------------------ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 9 20:41:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA23622 for ; Sun, 9 Jun 1996 20:41:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA21507 for png-implement-outgoing; Sun, 9 Jun 1996 20:42:38 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA21502 for ; Sun, 9 Jun 1996 20:42:32 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA05608 for ; Mon, 10 Jun 1996 09:39:54 +0800 (SST) Date: Mon, 10 Jun 1996 09:39:54 +0800 (SST) Message-Id: <199606100139.JAA05608@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: anybody tried tiff2png Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hi there, Some weeks ago I uploaded to swri the tiff2png utility (which in the next release intend to rename to TiPi like an indian /\ :-). Anybody so far who tried it out? I would like to know which tiff-formats are not yet working. So are there for example some SGI owners, who could give it a test-run. Or does it all work perfectly, can't imagine ... Thanks, Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 11 16:25:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA25246 for ; Tue, 11 Jun 1996 16:25:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA28667 for png-implement-outgoing; Tue, 11 Jun 1996 16:26:36 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA28662 for ; Tue, 11 Jun 1996 16:26:33 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id QAA24798 for ; Tue, 11 Jun 1996 16:23:26 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id QAA01214 for png-implement@dworkin.wustl.edu; Tue, 11 Jun 1996 16:24:26 -0500 (CDT) Date: Tue, 11 Jun 1996 16:24:26 -0500 (CDT) From: Cave Newt Message-Id: <199606112124.QAA01214@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: libpng 0.89 buglet Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I found one very minor problem in libpng 0.89 yesterday, but it did prevent compilation with Sun's default cc (SunOS) compiler: "pngmem.c", line 208: redeclaration of png_create_struct It's voidp in one place and png_voidp in another. Is there any reason even to have two of these typedefs, aside from (possibly) zlib? I haven't looked, but maybe all of them could be made the same? At the very least, either the prototype or the definition for png_create_struct() needs to be changed. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 11 17:25:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA26481 for ; Tue, 11 Jun 1996 17:25:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA29603 for png-implement-outgoing; Tue, 11 Jun 1996 17:28:06 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA29598 for ; Tue, 11 Jun 1996 17:28:01 -0500 Received: from munet-f.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA18195; Tue, 11 Jun 1996 16:25:14 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606112225.QAA18195@enel.ucalgary.ca> Received: by munet-f.enel.ucalgary.ca (NX5.67d/NX3.0X) id AA01775; Tue, 11 Jun 96 16:25:13 -0600 Subject: Re: libpng 0.89 buglet To: png-implement@dworkin.wustl.edu Date: Tue, 11 Jun 1996 16:25:12 -0600 (MDT) In-Reply-To: <199606112124.QAA01214@ellis.uchicago.edu> from "Cave Newt" at Jun 11, 96 04:24:26 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Greg writes: > It's voidp in one place and png_voidp in another. Is there any reason > even to have two of these typedefs, aside from (possibly) zlib? I haven't > looked, but maybe all of them could be made the same? At the very least, > either the prototype or the definition for png_create_struct() needs to > be changed. I'm not positive on the destinction myself. On my Linux system, they both map to void * of course, but maybe on other 16-bit DOS compilers, they have some fun combination of far * that require them to be different? I will change the png_create_struct() call to be both png_voidp, but maybe someone who is more versed in the intricacies of DOS compilers can take a look at the need for both defines? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 11 23:43:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id XAA02195 for ; Tue, 11 Jun 1996 23:43:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA03245 for png-implement-outgoing; Tue, 11 Jun 1996 23:46:21 -0500 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA03240 for ; Tue, 11 Jun 1996 23:46:17 -0500 Received: from 199.3.232.2.phoenix.net (dial112.phoenix.net [205.241.121.126]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id XAA07924 for ; Tue, 11 Jun 1996 23:43:37 -0500 Message-Id: <199606120443.XAA07924@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-implement@dworkin.wustl.edu Date: Tue, 11 Jun 1996 23:43:35 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: libpng 0.89 buglet Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas wrote: > I'm not positive on the destinction myself. On my Linux system, they both > map to void * of course, but maybe on other 16-bit DOS compilers, they > have some fun combination of far * that require them to be different? I > will change the png_create_struct() call to be both png_voidp, but maybe > someone who is more versed in the intricacies of DOS compilers can take > a look at the need for both defines? There is no big distinction. All the Libpng voidp's have been changed to png_voidp's except a few that were either overlooked or come from Zlib so need to be voidp for consistency. I haven't had time to look at the specific instance, but I will. Perhaps a judicious cast will fix the problem. We DO need the png_voidp and voidp typedefs in order to avoid filling the code with the FAR key word. Both of these types expand to void far * in the small or medium models. BTW I checked Guy's Compuserve ID and it doesn't appear to be active. I hope he is all right. Perhaps all his email accounts are through his company and he is no longer there. Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Wed Jun 12 17:10:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA18961 for ; Wed, 12 Jun 1996 17:10:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA16970 for png-implement-outgoing; Wed, 12 Jun 1996 17:11:31 -0500 Received: from fm3.facility.pipex.com (fm3.facility.pipex.com [194.131.104.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA16964 for ; Wed, 12 Jun 1996 17:11:24 -0500 Received: from ao070.du.pipex.com by fm3.facility.pipex.com (5.x/PIPEX simple 1.26) id AB08397; Wed, 12 Jun 1996 22:08:54 +0100 Message-Id: <9606122108.AB08397@fm3.facility.pipex.com> Mime-Version: 1.0 From: ttehtann@argonet.co.uk (T. R. Tanner) To: png-implement@dworkin.wustl.edu Date: Wed, 12 Jun 96 22:58:56 X-Mailer: VTi Internet Email reader 3.50 Subject: LibPNG 0.89 & png_set_filler Content-Type: text/plain Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List This appears to be broken - PNG_FILLER_AFTER & PNG_FILLER_BEFORE now both seem to be behaving the same (always before). And it causes very strange effects! Or have I missed something subtle (again!) -- Thos -- T. R. Tanner email: ttehtann@argonet.co.uk ------------Sig deleted due to lack of support------------- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Wed Jun 12 17:51:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA19373 for ; Wed, 12 Jun 1996 17:51:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA17431 for png-implement-outgoing; Wed, 12 Jun 1996 17:54:05 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA17424 for ; Wed, 12 Jun 1996 17:54:00 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA21940; Wed, 12 Jun 1996 16:51:14 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id QAA02921 for png-implement@dworkin.wustl.edu; Wed, 12 Jun 1996 16:49:58 -0600 Message-Id: <199606122249.QAA02921@munet-h.enel.ucalgary.ca> Subject: Re: LibPNG 0.89 & png_set_filler To: png-implement@dworkin.wustl.edu Date: Wed, 12 Jun 1996 16:49:57 -0600 (MDT) In-Reply-To: <9606122108.AB08397@fm3.facility.pipex.com> from "T. R. Tanner" at Jun 12, 96 10:58:56 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List It was written: > This appears to be broken - PNG_FILLER_AFTER & PNG_FILLER_BEFORE now both seem > to be behaving the same (always before). And it causes very strange effects! > Or have I missed something subtle (again!) I don't use it myself, so I can't really comment on it. The code looks OK to me (it did change slightly from 0.88). In pngtrans.c:png_set_filter() the png_ptr->flag is set for PNG_FILLER_AFTER, and unset for anything else. Maybe if you were not passing a valid value for filter_loc, it is always putting it before? Can you trace through your code and the library a bit to see that png_ptr->flag is set correctly, and if it is doing the right thing in png_do_read_filler()? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 08:53:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA24923 for ; Thu, 13 Jun 1996 08:53:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA25018 for png-implement-outgoing; Thu, 13 Jun 1996 08:53:47 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA25012 for ; Thu, 13 Jun 1996 08:53:44 -0500 Date: Thu, 13 Jun 96 9:45:03 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: anybody tried tiff2png Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606130945.aa20811@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message > Date: Mon, 10 Jun 1996 09:39:54 +0800 (SST) > From: Willem van Schaik > Subject: anybody tried tiff2png > Hi there, > > Some weeks ago I uploaded to swri the tiff2png utility (which in the > next release intend to rename to TiPi like an indian /\ :-). Anybody > so far who tried it out? I would like to know which tiff-formats are > not yet working. So are there for example some SGI owners, who could > give it a test-run. Or does it all work perfectly, can't imagine ... > > Thanks, Willem It seems to run ok on SGI, IRIX 5.2-- I only tried one file so far (the authors collage, which is a color_type 2 file without transparency); if I run my "png-sgi", "totiff" from ftp.sgi.com, your "tiff2png", and my "png-ppm", I got the same result as running my "png-ppm" on the original file. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 11:57:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA29330 for ; Thu, 13 Jun 1996 11:57:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA28209 for png-implement-outgoing; Thu, 13 Jun 1996 11:59:40 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA28204 for ; Thu, 13 Jun 1996 11:59:34 -0500 Received: from munet-i.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id KAA24027; Thu, 13 Jun 1996 10:56:46 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-i.enel.ucalgary.ca (8.6.12/8.6.12) id LAA01430 for png-implement@dworkin.wustl.edu; Thu, 13 Jun 1996 11:01:55 -0600 Message-Id: <199606131701.LAA01430@munet-i.enel.ucalgary.ca> Subject: Re: anybody tried tiff2png To: png-implement@dworkin.wustl.edu Date: Thu, 13 Jun 1996 11:01:55 -0600 (MDT) In-Reply-To: <9606130945.aa20811@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Jun 13, 96 09:45:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Glenn writes: > It seems to run ok on SGI, IRIX 5.2-- I only tried one file so far > (the authors collage, which is a color_type 2 file without transparency); Speaking of which, I don't think I've ever seen the collage. Where is it available? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 12:12:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA29513 for ; Thu, 13 Jun 1996 12:12:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA28356 for png-implement-outgoing; Thu, 13 Jun 1996 12:13:35 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA28351 for ; Thu, 13 Jun 1996 12:13:31 -0500 Date: Thu, 13 Jun 96 13:07:45 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: anybody tried tiff2png Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606131307.aa27181@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message > From: Andreas Dilger > Subject: Re: anybody tried tiff2png > Date: Thu, 13 Jun 1996 11:01:55 -0600 (MDT) > Glenn writes: > > It seems to run ok on SGI, IRIX 5.2-- I only tried one file so far > > (the authors collage, which is a color_type 2 file without transparenc > y); > > Speaking of which, I don't think I've ever seen the collage. Where is it > available? It was on tcg.arl.mil, until tcg got commandeered for another purpose... I'll put a copy on swrinde, which Keith can put somewhere in png-group. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 15:53:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA02781 for ; Thu, 13 Jun 1996 15:53:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02632 for png-implement-outgoing; Thu, 13 Jun 1996 15:55:17 -0500 Received: from maxwell.nde.swri.edu (maxwell.nde.swri.edu [129.162.171.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02627 for ; Thu, 13 Jun 1996 15:55:11 -0500 Received: (from ksp@localhost) by maxwell.nde.swri.edu (8.7.4/8.7.1) id PAA28084 for png-implement@dworkin.wustl.edu; Thu, 13 Jun 1996 15:52:16 -0500 (CDT) Message-Id: <199606132052.PAA28084@maxwell.nde.swri.edu> From: ksp@maxwell.nde.swri.edu (Keith S. Pickens) Date: Thu, 13 Jun 1996 15:52:16 -0500 In-Reply-To: Glenn Randers-Pehrson ARL-WTD-TED-TIB "Re: anybody tried tiff2png" (Jun 13, 1:07pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: PNG Implementation List Subject: Re: anybody tried tiff2png Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List } It was on tcg.arl.mil, until tcg got commandeered for another purpose... } I'll put a copy on swrinde, which Keith can put somewhere in png-group. In /pub/png-group/images/ -keith ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 18:52:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA01900 for ; Thu, 13 Jun 1996 18:52:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA04630 for png-implement-outgoing; Thu, 13 Jun 1996 18:54:35 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA04625 for ; Thu, 13 Jun 1996 18:54:30 -0500 Received: from munet-i.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA25661; Thu, 13 Jun 1996 17:50:08 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-i.enel.ucalgary.ca (8.6.12/8.6.12) id RAA03758 for png-implement@dworkin.wustl.edu; Thu, 13 Jun 1996 17:55:22 -0600 Message-Id: <199606132355.RAA03758@munet-i.enel.ucalgary.ca> Subject: Re: author's collage (was anybody tried tiff2png) To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Thu, 13 Jun 1996 17:55:22 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I downloaded the PNG Author's collage image. Eeek, what a motley bunch! In any case, I noticed that the "Description" tEXt chunk is invalid: it has no keyword, and then "Description" followed by a linefeed. I went in and edited the image manually to be correct (leaving the CRC as the old CRC), and libpng refused to load the image because of the CRC error. IMHO, this makes libpng very good at detecting errors, but less than useful when displaying a file with an error in it. If there is a genuine problem in the file (ie missing or incorrect data), this will show up soon enough, because libpng now checks data in the chunks it decodes, as well as the line filter types. What do people think about having a real error only if there is a CRC problem in critical chunks and a warning if there is a CRC error in non-critical chunks? This would match my opinion of critical and ancillary better... Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 19:21:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA02086 for ; Thu, 13 Jun 1996 19:21:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA04877 for png-implement-outgoing; Thu, 13 Jun 1996 19:23:46 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA04872 for ; Thu, 13 Jun 1996 19:23:42 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA13312; Fri, 14 Jun 1996 00:20:53 GMT Date: Fri, 14 Jun 1996 00:20:53 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606140020.AA13312@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: author's collage (was anybody tried tiff2png) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas asks: > What do people think about having a real error only if there is a CRC > problem in critical chunks and a warning if there is a CRC error in > non-critical chunks? Sounds reasonable to me. Of course, the chunk with the error should not be used at all. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 20:03:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA02423 for ; Thu, 13 Jun 1996 20:03:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA05381 for png-implement-outgoing; Thu, 13 Jun 1996 20:06:29 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA05376 for ; Thu, 13 Jun 1996 20:06:23 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA02825 for ; Fri, 14 Jun 1996 09:03:19 +0800 (SST) Date: Fri, 14 Jun 1996 09:03:19 +0800 (SST) Message-Id: <199606140103.JAA02825@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: author's collage (was anybody tried tiff2png) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 17:55 13-06-1996 -0600, Andreas wrote: >IMHO, this makes libpng very good at detecting errors, but less than >useful when displaying a file with an error in it. If there is a >genuine problem in the file (ie missing or incorrect data), this will >show up soon enough, because libpng now checks data in the chunks it >decodes, as well as the line filter types. What do people think about >having a real error only if there is a CRC problem in critical chunks >and a warning if there is a CRC error in non-critical chunks? This >would match my opinion of critical and ancillary better... I hadn't thought of that one before, but now you raise it I think you have a very valid point. But I think we should go one step further. Even when a critical chunk has a problem, I still would like to be able to have a "best-effort" decoding. It would be rediculous to be forced to write your own libpng, just because the CRC of the IDAT chunk is wrong. How to implement it is another question. The best way would be to have a call that would "switch a mode" from normal to best-effort. In this best-effort mode all checks would only generate messages, but not halt to program. Applications like pngtopnm could then implement a -force command-line option. Default behaviour would ofcourse remain unchanged. Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/WWWillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 20:23:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA02533 for ; Thu, 13 Jun 1996 20:23:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA05545 for png-implement-outgoing; Thu, 13 Jun 1996 20:25:59 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA05540 for ; Thu, 13 Jun 1996 20:25:56 -0500 Date: Thu, 13 Jun 96 21:21:23 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: author's collage (was anybody tried tiff2png) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606132121.aa06326@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas wrote: > > I downloaded the PNG Author's collage image. Eeek, what a motley bunch! > In any case, I noticed that the "Description" tEXt chunk is invalid: > it has no keyword, and then "Description" followed by a linefeed. Hmmm, there was an extra linefeed in the text file that I read in to the text chunks. My Ppm-png didn't detect the situation and happily wrote an illegal, zero-length keyword. I have just uploaded to swrinde a fixed copy. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 20:48:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA02601 for ; Thu, 13 Jun 1996 20:48:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA05900 for png-implement-outgoing; Thu, 13 Jun 1996 20:51:18 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA05895 for ; Thu, 13 Jun 1996 20:51:13 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id TAA25884; Thu, 13 Jun 1996 19:48:23 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id TAA04646 for png-implement@dworkin.wustl.edu; Thu, 13 Jun 1996 19:46:58 -0600 Message-Id: <199606140146.TAA04646@munet-h.enel.ucalgary.ca> Subject: Re: author's collage (was anybody tried tiff2png) To: png-implement@dworkin.wustl.edu Date: Thu, 13 Jun 1996 19:46:58 -0600 (MDT) In-Reply-To: <9606132121.aa06326@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Jun 13, 96 09:21:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Glenn writes: > Hmmm, there was an extra linefeed in the text file that I read in to > the text chunks. My Ppm-png didn't detect the situation and happily > wrote an illegal, zero-length keyword. In libpng-0.89, I have added checks (basically most of the tests from pngcheck-1.96) for many of these problems so that it is much more difficult to write an invalid PNG file, which was very easy with prior versions of libpng. It would no longer be possible to write the invalid tEXt chunk. >From inference, it looks like your ppm-png converter can handle comments, although I thought Willem was just saying that ppmtopng doesn't save the comments. Is this a local patch, or a totally different program entirely? I would be interested in such a thing. Currently in XV-PNG 1.2b, it stores the comments in the form keyword::comment, so that it is possible to have linefeeds and colons in the comments, keywords up to 80 characters, and still parse them chunks back to tEXT chunks. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 21:05:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA02653 for ; Thu, 13 Jun 1996 21:05:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA06168 for png-implement-outgoing; Thu, 13 Jun 1996 21:08:29 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA06163 for ; Thu, 13 Jun 1996 21:08:21 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id KAA02078 for ; Fri, 14 Jun 1996 10:05:28 +0800 (SST) Date: Fri, 14 Jun 1996 10:05:28 +0800 (SST) Message-Id: <199606140205.KAA02078@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: author's collage (was anybody tried tiff2png) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 19:46 13-06-1996 -0600, Andreas wrote: >From inference, it looks like your ppm-png converter can handle comments, >although I thought Willem was just saying that ppmtopng doesn't save the >comments. Is this a local patch, or a totally different program entirely? With pnmtopng you can create tEXT chunks consisting of keyword-comment fields using an additional txt-file. See the man-page pnmtopng.1 for the exact format of the txt-file. Hope this answers your question. Allthough not 100% sure what you were driving at. Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/WWWillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 21:22:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA02792 for ; Thu, 13 Jun 1996 21:22:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA06461 for png-implement-outgoing; Thu, 13 Jun 1996 21:25:32 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA06456 for ; Thu, 13 Jun 1996 21:25:28 -0500 Date: Thu, 13 Jun 96 22:21:18 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: author's collage (was anybody tried tiff2png) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606132221.aa06926@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > > From inference, it looks like your ppm-png converter can handle comments, > although I thought Willem was just saying that ppmtopng doesn't save the > comments. Is this a local patch, or a totally different program entirely? It's a different program that predates libpng. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 13 22:30:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id WAA03075 for ; Thu, 13 Jun 1996 22:30:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA07156 for png-implement-outgoing; Thu, 13 Jun 1996 22:33:14 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA07151 for ; Thu, 13 Jun 1996 22:33:10 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id VAA26026; Thu, 13 Jun 1996 21:30:19 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606140330.VAA26026@enel.ucalgary.ca> Subject: Re: pnmtopng (was author's collage) To: png-implement@dworkin.wustl.edu Date: Thu, 13 Jun 1996 21:30:18 -0600 (MDT) In-Reply-To: <199606140205.KAA02078@ntuix.ntu.ac.sg> from "Willem van Schaik" at Jun 14, 96 10:05:28 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem writes: > With pnmtopng you can create tEXT chunks consisting of keyword-comment > fields using an additional txt-file. See the man-page pnmtopng.1 for > the exact format of the txt-file. Actually, what I was getting at was the ability to save PNG tEXt/zTXt data into a ppm file (from pngtoppm) and then re-create them when doing the ppmtopng conversion (without the use of an external file). Unfortunately, we can't do the same with any of the unsafe-to-copy data like gAMA or sBIT, since we don't know what has happened to the pixels since they were dumped into the ppm file. I would suggest something like the following when converting to ppm: P6 # keyword1::comment1 # continuation of previous comment # keyword2::comment2 # continuation of comment2 # more continuation of comment2 640 480 255 RGB data This is how XV inputs PNG comments, and then parses them back into keyword/comment pairs for tEXT or zTXT chunks, or stores them into another file. If there isn't a recognizable keyword, then it becomes a generic "Comment" tEXt chunk. A recognizable keyword is defined as a newline followed by 1-80 characters, followed by by two colons. However, this may have to be a bit more precise for ppm, since comments are also used for other things. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 07:30:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA06575 for ; Fri, 14 Jun 1996 07:30:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA11869 for png-implement-outgoing; Fri, 14 Jun 1996 07:32:17 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA11864 for ; Fri, 14 Jun 1996 07:32:12 -0500 Date: Fri, 14 Jun 96 8:26:17 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606140826.aa11333@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message > From: Andreas Dilger > Subject: Re: pnmtopng (was author's collage) > Date: Thu, 13 Jun 1996 21:30:18 -0600 (MDT) > Willem writes: > > With pnmtopng you can create tEXT chunks consisting of keyword-comment > > fields using an additional txt-file. See the man-page pnmtopng.1 for > > the exact format of the txt-file. > > Actually, what I was getting at was the ability to save PNG tEXt/zTXt > data into a ppm file (from pngtoppm) and then re-create them when doing > the ppmtopng conversion (without the use of an external file). > Unfortunately, we can't do the same with any of the unsafe-to-copy > data like gAMA or sBIT, since we don't know what has happened to the > pixels since they were dumped into the ppm file. > > I would suggest something like the following when converting to ppm: > > P6 > # keyword1::comment1 > # continuation of previous comment > # keyword2::comment2 > # continuation of comment2 > # more continuation of comment2 The way I have been thinking of doing it: P6 #PNG_tEXt #keyword #commment1 #comment1 continued #. #PNG_tEXt #keyword2 #commment2 #contiuation of commment2 #more comment2 #. #PNG_gAMA #0.5 #PNG_bKGD #50 50 150 #PNG_tRNS # 0 0 0 #PNG_unRg # hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh # hhhhhhhh hhhhhhhh hhhhhhhh hhhh (ASCII hex values) #. Also I'm also using P7 for RGBA, not limited to 8 bits per component and P8 for raw RGBA, not limited to 8 bits per component. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 08:16:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA06843 for ; Fri, 14 Jun 1996 08:16:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA12249 for png-implement-outgoing; Fri, 14 Jun 1996 08:19:36 -0500 Received: from rs1.hrz.th-darmstadt.de (rs1.hrz.th-darmstadt.de [130.83.22.60]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA12242 for ; Fri, 14 Jun 1996 08:19:09 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs1.hrz.th-darmstadt.de (8.6.12/8.6.12.0ms) with ESMTP id PAA07532 for ; Fri, 14 Jun 1996 15:16:07 +0200 Received: from fb0410.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA134888154; Fri, 14 Jun 1996 15:15:54 +0200 Received: from localhost by fb0410.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA145688149; Fri, 14 Jun 1996 15:15:49 +0200 Date: Fri, 14 Jun 1996 15:15:49 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-Reply-To: <199606140330.VAA26026@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, On Thu, 13 Jun 1996, Andreas Dilger wrote: > Willem writes: > > With pnmtopng you can create tEXT chunks consisting of keyword-comment > > fields using an additional txt-file. See the man-page pnmtopng.1 for > > the exact format of the txt-file. > > Actually, what I was getting at was the ability to save PNG tEXt/zTXt > data into a ppm file (from pngtoppm) and then re-create them when doing > the ppmtopng conversion (without the use of an external file). > Unfortunately, we can't do the same with any of the unsafe-to-copy > data like gAMA or sBIT, since we don't know what has happened to the > pixels since they were dumped into the ppm file. I have considered implementing this in pngtopnm/pnmtopng but I haven't gotten around to actually doing anything (I think it is mentioned in the BUGS section in the manpage). The main problem is that I would prefer to have a format that preserves the structure of the original comments if they come from a PNG file or create Comment entries if they don't. Handling text chunks containing lines that look like new text chunks but are continuation lines is a bit difficult I guess, but should be possible. Also, I think it should support C-string like escapes, this way, Latin1 chars can be handled even on systems that cannot handle them. (Probably similar to the output of pngcheck -t or -7). Maybe it would also be nice to have a way to store unknown ancillary chunks in the comment section of the PNM file (maybe as hex dump) so that they can be preserved also. I'm open to suggestions on the ppm comment format, I would think that using \ as escape and the usual C style should covert most things, the only thing that is needed is a way to indicate that a keywords isn`t really one. Maybe it would be possible to just escape colons in keywords and following something that looks like a keyword and then considering only unescaped colons as keyword delimiters. Or we could use blank lines (without the # sign as delimiting new text chunks). BTW. storing sBIT is usually not necessary when converting to PNM, since pngtopnm tries to adjust the maximum pixel value to match the sbit value, this only gets lost if the sbit values do not agree in RGB mode (since there is only one maxvalue for all channels in ppm) For e.g. 4 bit HAM images, this works quite well. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 12:27:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA12190 for ; Fri, 14 Jun 1996 12:27:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA15832 for png-implement-outgoing; Fri, 14 Jun 1996 12:30:01 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA15824 for ; Fri, 14 Jun 1996 12:29:55 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA27141; Fri, 14 Jun 1996 17:27:02 GMT Date: Fri, 14 Jun 1996 17:27:02 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606141727.AA27141@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: pnmtopng (was author's collage) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > P6 > # keyword1::comment1 > # continuation of previous comment > # keyword2::comment2 > # continuation of comment2 > # more continuation of comment2 > 640 480 > 255 > RGB data This doesn't work if a comment contains a double colon. > P6 > #PNG_tEXt > #keyword > #commment1 > #comment1 continued > #. > #PNG_tEXt > #keyword2 > #commment2 > #contiuation of commment2 > #more comment2 > #. > #PNG_gAMA > #0.5 > #PNG_bKGD > #50 50 150 > #PNG_tRNS > # 0 0 0 > #PNG_unRg > # hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh > # hhhhhhhh hhhhhhhh hhhhhhhh hhhh (ASCII hex values) > #. This is more general, which is nice, but fails if one line of a comment is a lone dot. > Maybe it would be possible to just escape colons in keywords and > following something that looks like a keyword and then considering > only unescaped colons as keyword delimiters. Escape sequences are a pain in the butt, in general. To allow Latin-1 text, they would be essential. Using escapes to avoid putting nonportable characters in a text file is not so bad. Using escapes to disambiguate things or to protect quote characters is a nightmare. For example, using \177 for a y with umlaut is okay. Using \: to mean something different from : is nasty. > Or we could use blank lines (without the # sign as delimiting new text > chunks). This is better, but I'm not sure what the ppm format can tolerate before the maxval line. Does it need those # symbols? If so, the idea can easily be salvaged: P6 #PNG_tEXt #=keyword #=commment1 #=comment1 continued #PNG_tEXt #=keyword2 #=commment2 #=continuation of commment2 #=more comment2 #PNG_gAMA #=0.5 #PNG_bKGD #=50 50 150 #PNG_tRNS #=0 0 0 640 480 255 RGB data How's that? AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 12:57:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA12550 for ; Fri, 14 Jun 1996 12:57:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA16268 for png-implement-outgoing; Fri, 14 Jun 1996 13:00:06 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA16261 for ; Fri, 14 Jun 1996 13:00:02 -0500 Date: Fri, 14 Jun 96 13:55:07 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: PNG data in PNM (was pnmtopng (was authors's collage)) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606141355.aa19542@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List [encoding PNG data in a ppm file] Adam suggested > > P6 > #PNG_tEXt > #=keyword > #=commment1 > #=comment1 continued > #PNG_tEXt > #=keyword2 > #=commment2 > #=continuation of commment2 > #=more comment2 > #PNG_gAMA > #=0.5 > #PNG_bKGD > #=50 50 150 > #PNG_tRNS > #=0 0 0 > 640 480 > 255 > RGB data > > How's that? > I like it better than mine. I knew that the lone dot would fail; this avoids that problem neatly. And the logic for reading this version is likely to be more straightforward. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 13:02:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA12674 for ; Fri, 14 Jun 1996 13:02:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA16361 for png-implement-outgoing; Fri, 14 Jun 1996 13:04:50 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA16356 for ; Fri, 14 Jun 1996 13:04:44 -0500 Received: from munet-i.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id MAA27734; Fri, 14 Jun 1996 12:01:50 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-i.enel.ucalgary.ca (8.6.12/8.6.12) id MAA04604 for png-implement@dworkin.wustl.edu; Fri, 14 Jun 1996 12:06:58 -0600 Message-Id: <199606141806.MAA04604@munet-i.enel.ucalgary.ca> Subject: Re: pnmtopng (was author's collage) To: png-implement@dworkin.wustl.edu Date: Fri, 14 Jun 1996 12:06:58 -0600 (MDT) In-Reply-To: <9606141727.AA27141@siesta.cs.wustl.edu> from "Adam M. Costello" at Jun 14, 96 05:27:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Adam writes: > This doesn't work if a comment contains a double colon. > > This is more general, which is nice, but fails if one line of a comment > is a lone dot. Granted, they will both fail, but the point is that we're not trying to make this 100% robust for PPM in all cases, since no matter how you do it, there is always the chance of a comment containing the wrong combination of characters. I prefer something that looks like a reasonable comment, and yet is not more than 5% likely to produce a false match. A single colon can happen in a comment. Two colons are much less likely, and still look reasonable. This is good enough for me. > > Maybe it would be possible to just escape colons in keywords and > > following something that looks like a keyword and then considering > > only unescaped colons as keyword delimiters. Why not just use the Latin-1 directly? Since raw PPM files can contain 8-bit data anyways, this isn't a major incompatibility. Even with ASCII PPM files, this data will only be munged if it passes through a 7-bit channel and it contains 8-bit Latin-1 text - a rare enough occurrence that I don't think we need to worry about it. No reason to make life overly complicated. If someone wants to edit the comments manually in the PPM file, what would they rather do: type normally, or find out the octal byte codes for every character? Regarding the preservation of unsafe-to-copy chunks in the text section, why would we do this? Since PPM has no concept of unsafe-to-copy, there is no guarantee that the data will be valid when it is converted back to a PNG. Also, it may be that another program will just put all of this text back into a comment, which may end up being placed into a tEXt chunk at a later time because the formatting has changed slightly. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 13:18:03 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA12896 for ; Fri, 14 Jun 1996 13:18:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA16689 for png-implement-outgoing; Fri, 14 Jun 1996 13:20:46 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA16684 for ; Fri, 14 Jun 1996 13:20:38 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id LAA24363 for ; Fri, 14 Jun 1996 11:13:46 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id LAA00396 for png-implement@dworkin.wustl.edu; Fri, 14 Jun 1996 11:13:46 -0700 (PDT) Message-Id: <199606141813.LAA00396@web1.calweb.com> Subject: Re: pnmtopng (was author's collage) To: png-implement@dworkin.wustl.edu Date: Fri, 14 Jun 1996 11:13:45 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9606141727.AA27141@siesta.cs.wustl.edu> from "Adam M. Costello" at Jun 14, 96 05:27:02 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > P6 > #PNG_tEXt > #=keyword > #=commment1 > #=comment1 continued > #PNG_tEXt > #=keyword2 > #=commment2 > #=continuation of commment2 > #=more comment2 > #PNG_gAMA > #=0.5 > #PNG_bKGD > #=50 50 150 > #PNG_tRNS > #=0 0 0 > 640 480 > 255 > RGB data This one looks the cleanest to me. You will have to have some means of encoding non-ASCII bytes from PNG text; I'd recommend using URL-escapes (i.e., %a9 for ©, %25 for %) because they're simpler than \-escapes for things like Perl scripts. You might also want to run the idea by Jef just to make sure he doesn't have conflicting ideas. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 13:39:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA13419 for ; Fri, 14 Jun 1996 13:39:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA16958 for png-implement-outgoing; Fri, 14 Jun 1996 13:41:20 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA16951 for ; Fri, 14 Jun 1996 13:41:15 -0500 Date: Fri, 14 Jun 96 14:35:48 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606141435.aa20643@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas asks: > > Regarding the preservation of unsafe-to-copy chunks in the text section, > why would we do this? It might provide a convenient way of editing them. Convert the file from PNG to P3, use a text editor to modify the cHRM chunk data, and convert it back to PNG. Is this the best way to do that? Probably not, but it's an easy and completely general way of doing it. In Adam's and my examples there weren't any unknown, unsafe-to-copy chunks. > Since PPM has no concept of unsafe-to-copy, there > is no guarantee that the data will be valid when it is converted back to > a PNG. This might be a nice use for the proposed fING chunk. pnmtopng could calculate a new fingerprint based on the RGB data and compare it with the fING chunk that was written by pngtopnm. This wouldn't work if the new PNG file were filtered or compressed differently, though, but that's only because of our slightly faulty safe-to-copy mechanism. > Also, it may be that another program will just put all of this > text back into a comment, which may end up being placed into a tEXt chunk > at a later time because the formatting has changed slightly. I guess anything could happen if the PNM file got out of the control of the person working on it. I see this pngtopnm, pnmtopng conversion just as a fleeting thing where one converts the file, does some work on it, and puts it back in PNG format, where it belongs. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 14:05:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA13637 for ; Fri, 14 Jun 1996 14:05:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA17452 for png-implement-outgoing; Fri, 14 Jun 1996 14:08:03 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA17447 for ; Fri, 14 Jun 1996 14:07:59 -0500 Received: from munet-i.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id NAA27933; Fri, 14 Jun 1996 13:05:03 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-i.enel.ucalgary.ca (8.6.12/8.6.12) id NAA04719 for png-implement@dworkin.wustl.edu; Fri, 14 Jun 1996 13:10:11 -0600 Message-Id: <199606141910.NAA04719@munet-i.enel.ucalgary.ca> Subject: Re: pnmtopng (was author's collage) To: png-implement@dworkin.wustl.edu Date: Fri, 14 Jun 1996 13:10:11 -0600 (MDT) In-Reply-To: <9606141435.aa20643@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Jun 14, 96 02:35:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Glenn writes: > This might be a nice use for the proposed fING chunk. pnmtopng could > calculate a new fingerprint based on the RGB data and compare it with the > fING chunk that was written by pngtopnm. This wouldn't work if the new > PNG file were filtered or compressed differently, though, but that's only > because of our slightly faulty safe-to-copy mechanism. I thought the whole point of the fING chunk was to determine if the CONTENT was different, not the actual storage format. Wasn't the proposal that the MD5 (or whatever method we use) be calculated on the image after it had been converted to raw RGBA data, so that even if an image is converted from paletted to RGB (maybe because it compresses better), or if the filtering or compression level changes, we know we have the same image. There was also a proposal for the entire file, but I don't see this having wide usefulness as it requires external key servers, etc, and would be useless in this case anyways, as it prevents us from editing the ancillary data, which is what we want to do in the first place. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 14:26:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA13995 for ; Fri, 14 Jun 1996 14:26:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA17730 for png-implement-outgoing; Fri, 14 Jun 1996 14:29:26 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA17722 for ; Fri, 14 Jun 1996 14:29:21 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA24361; Fri, 14 Jun 1996 19:26:27 GMT Date: Fri, 14 Jun 1996 19:26:27 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606141926.AA24361@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: pnmtopng (was author's collage) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas says: > Granted, they will both fail, but the point is that we're not trying > to make this 100% robust for PPM in all cases, since no matter how you > do it, there is always the chance of a comment containing the wrong > combination of characters. Not so. Did you look at my proposal? No comment can possibly screw it up. > I prefer something that looks like a reasonable comment, and yet is > not more than 5% likely to produce a false match. A single colon can > happen in a comment. Two colons are much less likely, and still look > reasonable. This is good enough for me. I think my proposal is at least as simple to code, and has 0% probability of producing a false match. Of course, whoever writes the program has the last word, and that's not me. :) AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 14:32:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA14178 for ; Fri, 14 Jun 1996 14:32:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA17786 for png-implement-outgoing; Fri, 14 Jun 1996 14:34:58 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA17781 for ; Fri, 14 Jun 1996 14:34:55 -0500 Date: Fri, 14 Jun 96 15:28:55 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606141528.aa22138@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > I thought the whole point of the fING chunk was to determine if the CONTENT > was different, not the actual storage format. Wasn't the proposal that > the MD5 (or whatever method we use) be calculated on the image after it had > been converted to raw RGBA data, so that even if an image is converted from > paletted to RGB (maybe because it compresses better), or if the filtering > or compression level changes, we know we have the same image. Yes, that's exactly the point. But the copy-safe mechanism depends not on content (like it should) but on format. So one can't legitimately use fING for determining whether a copy-unsafe chunk can be copied. > There was > also a proposal for the entire file, but I don't see this having wide > usefulness as it requires external key servers, etc, and would be useless > in this case anyways, as it prevents us from editing the ancillary data, > which is what we want to do in the first place. I agree that the other MD5 proposal (dSIG) seems to depend too much on external information to be very useful. There seemed to me to be no particular advantage to having the MD5 inside the PNG stream over having it in a message (or series of messages) that enclose the PNG file. This proposal hasn't been written up in detail, yet. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 14 19:38:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA17456 for ; Fri, 14 Jun 1996 19:38:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA21215 for png-implement-outgoing; Fri, 14 Jun 1996 19:41:11 -0500 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA21210 for ; Fri, 14 Jun 1996 19:41:08 -0500 Received: from 199.3.232.2.phoenix.net (dial77.phoenix.net [205.241.121.91]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id TAA15002 for ; Fri, 14 Jun 1996 19:38:11 -0500 Message-Id: <199606150038.TAA15002@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-implement@dworkin.wustl.edu Date: Fri, 14 Jun 1996 19:38:08 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: libpng 0.89 buglet Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List There's an MSC bug in pngmem.c that prevents conmpiling. The halloc() function has two parameters. The second parameter is the constant 1. This is right in one place and wrong in another. After fixing that bug, I can't get the test to work right under either MSC or dgjpp 1.12. The results are identical. I checked PNGOUT.PNG, and there is a noticeble horizontal line near the lower left corner. Has anyone else had this problem? Since I got the same effect with two totally different platforms, it must be real. Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sat Jun 15 15:22:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA26390 for ; Sat, 15 Jun 1996 15:22:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA29657 for png-implement-outgoing; Sat, 15 Jun 1996 15:25:26 -0500 Received: from dns1.noc.best.net (dns1.noc.best.net [206.86.8.69]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA29650 for ; Sat, 15 Jun 1996 15:25:22 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA07672 for ; Sat, 15 Jun 1996 13:22:22 -0700 Received: from cpic (photodex.vip.best.com [205.149.166.237]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA13767 for ; Sat, 15 Jun 1996 13:22:14 -0700 Date: Sat, 15 Jun 1996 13:22:14 -0700 Message-Id: <199606152022.NAA13767@shellx.best.com> X-Sender: photodex@best.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: pschmidt@photodex.com (Paul Schmidt) Subject: Re: dithering & etc (was Re: libpng localization) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas wonders: > It basically > keeps only one error row, and an extra pixel to store the future error > for the current pixel (actually it's kind of hard to explain). Has anyone > heard of doing it this way before, or have I just re-invented the wheel? If you port this code into assembly language on most processors and get cute with the registers, you can avoid using that "future error" storage and leave the value(s) in registeres until they can be stored over the current value. Saves *lots* of time in the process. Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1781 Barcelona Street AOL: Photodex Photodex Livermore, CA 94550 CIS: Photodex 74774,3635 (510)449-9079 Voice (510)449-3519 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 16 20:11:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA06556 for ; Sun, 16 Jun 1996 20:11:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA13952 for png-implement-outgoing; Sun, 16 Jun 1996 20:12:10 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA13942 for ; Sun, 16 Jun 1996 20:12:02 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA13883 for ; Mon, 17 Jun 1996 09:08:49 +0800 (SST) Date: Mon, 17 Jun 1996 09:08:49 +0800 (SST) Message-Id: <199606170108.JAA13883@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List The only thing I don't like is two lines with #PNG_tEXT for only one chunk. So we could do it a bit more like DXF and others: P6 # chunk # PNG_tEXt # key # # string # # string # # key # # string # # string # # chunk # PNG_gAMA # one_float # 0.5 # chunk # PNG_bKGD # three_int # 50 50 150 # chunk # PNG_tRNS # three_int # 0 0 0 640 480 255 RGB data Variants are ofcourse to put each int/float on separate lines, or to make no destinction in float/int and just use value, etc. etc. This way of coding is a bit more cumbersome, but more extensible into the future. The idea of a space (of course to follow pbm habits more whitespace is allowed), is just done for human readibility. I like it, but it is of course not necessary. OK, I realize that I put a number of independent ideas in one pro- posal, so it could be that only part is useful. Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/WWWillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 16 20:14:03 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA06578 for ; Sun, 16 Jun 1996 20:14:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA14011 for png-implement-outgoing; Sun, 16 Jun 1996 20:17:05 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA14006 for ; Sun, 16 Jun 1996 20:17:01 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA13546 for ; Mon, 17 Jun 1996 09:13:54 +0800 (SST) Date: Mon, 17 Jun 1996 09:13:54 +0800 (SST) Message-Id: <199606170113.JAA13546@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: pnmtopng (was author's collage) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 12:06 14-06-1996 -0600, Andreas wrote: >Adam writes: >> This doesn't work if a comment contains a double colon. >> >> This is more general, which is nice, but fails if one line of a comment >> is a lone dot. > >Why not just use the Latin-1 directly? Since raw PPM files can contain >8-bit data anyways, this isn't a major incompatibility. Even with >ASCII PPM files, this data will only be munged if it passes through a >7-bit channel and it contains 8-bit Latin-1 text - a rare enough occurrence >that I don't think we need to worry about it. No reason to make life >overly complicated. If someone wants to edit the comments manually in >the PPM file, what would they rather do: type normally, or find out the >octal byte codes for every character? I support this. Let's keep it simple (if possible :-). Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/WWWillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 16 20:30:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA06644 for ; Sun, 16 Jun 1996 20:30:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA14126 for png-implement-outgoing; Sun, 16 Jun 1996 20:33:29 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA14120 for ; Sun, 16 Jun 1996 20:33:21 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA32502 for ; Mon, 17 Jun 1996 09:30:10 +0800 (SST) Date: Mon, 17 Jun 1996 09:30:10 +0800 (SST) Message-Id: <199606170130.JAA32502@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 09:08 17-06-1996 +0800, "Me, Myself and I" wrote: After my previous message I saw a mayor flaw, not only in my proposal but also in all the others. When we are putting in comments, couldn't it be possible that others are doing the same ???? :-) At the same time, when you consistently use key/value pairs, there is no need for "PNG_" in front of the chunk-name. So, something like the following is needed: P6 #PNG chunk #PNG tEXt #PNG key #PNG #PNG string #PNG #PNG string #PNG #PNG key #PNG #PNG string #PNG #PNG string #PNG #PNG chunk #PNG gAMA #PNG one_float #PNG 0.5 #PNG chunk #PNG bKGD #PNG three_int #PNG 50 50 150 #PNG chunk #PNG tRNS #PNG three_int #PNG 0 0 0 640 480 255 RGB data ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/WWWillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 16 23:49:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id XAA07228 for ; Sun, 16 Jun 1996 23:49:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA16082 for png-implement-outgoing; Sun, 16 Jun 1996 23:52:00 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id XAA16077 for ; Sun, 16 Jun 1996 23:51:56 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA17377; Mon, 17 Jun 1996 04:48:48 GMT Date: Mon, 17 Jun 1996 04:48:48 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606170448.AA17377@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem suggests: > P6 > #PNG chunk > #PNG tEXt > #PNG key > #PNG > #PNG string > #PNG > #PNG string > #PNG > #PNG key > #PNG > #PNG string > #PNG > #PNG string > #PNG > #PNG chunk > #PNG gAMA > #PNG one_float > #PNG 0.5 > #PNG chunk > #PNG bKGD > #PNG three_int > #PNG 50 50 150 > #PNG chunk > #PNG tRNS > #PNG three_int > #PNG 0 0 0 > 640 480 > 255 > RGB data But there is only one key/value pair per tEXt chunk. I see what you're trying to do--simplify pnmtopng's job. In the extreme, pnmtopng wouldn't even have to know the syntax of the chunks: P6 #PNG chunk=tEXt #PNG string= #PNG byte=0 #PNG string= #PNG = #PNG chunk=tEXt #PNG string= #PNG byte=0 #PNG string= #PNG = #PNG chunk=gAMA #PNG fixedpoint=0.5 #PNG chunk=bKGD #PNG short=50 #PNG short=50 #PNG short=50 #PNG chunk=tRNS #PNG short=0 #PNG short=0 #PNG short=0 640 480 255 RGB data ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 07:42:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA09953 for ; Mon, 17 Jun 1996 07:42:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA19297 for png-implement-outgoing; Mon, 17 Jun 1996 07:45:13 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA19292 for ; Mon, 17 Jun 1996 07:45:10 -0500 Date: Mon, 17 Jun 96 8:39:18 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606170839.aa10353@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message > Date: Mon, 17 Jun 1996 04:48:48 GMT > From: "Adam M. Costello" > Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) > Willem suggests: > > > P6 > > #PNG chunk > > #PNG tEXt > > #PNG key > > #PNG > > #PNG string > > #PNG > > #PNG string > > #PNG > > #PNG key > > #PNG > > #PNG string > > #PNG > > #PNG string > > #PNG > > #PNG chunk > > #PNG gAMA > > #PNG one_float > > #PNG 0.5 > > #PNG chunk > > #PNG bKGD > > #PNG three_int > > #PNG 50 50 150 > > #PNG chunk > > #PNG tRNS > > #PNG three_int > > #PNG 0 0 0 > > 640 480 > > 255 > > RGB data > > But there is only one key/value pair per tEXt chunk. > > I see what you're trying to do--simplify pnmtopng's job. In the > extreme, pnmtopng wouldn't even have to know the syntax of the chunks: > > P6 > #PNG chunk=tEXt > #PNG string= > #PNG byte=0 > #PNG string= > #PNG = > #PNG chunk=tEXt > #PNG string= > #PNG byte=0 > #PNG string= > #PNG = > #PNG chunk=gAMA > #PNG fixedpoint=0.5 > #PNG chunk=bKGD > #PNG short=50 > #PNG short=50 > #PNG short=50 > #PNG chunk=tRNS > #PNG short=0 > #PNG short=0 > #PNG short=0 > 640 480 > 255 > RGB data > > ------------------------------------------------------------ > To find out more about the mailing list server, send mail to > png-implement-request@dworkin.wustl.edu > with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 08:01:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA10016 for ; Mon, 17 Jun 1996 08:01:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA19435 for png-implement-outgoing; Mon, 17 Jun 1996 08:04:08 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA19430 for ; Mon, 17 Jun 1996 08:04:05 -0500 Date: Mon, 17 Jun 96 8:57:47 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606170857.aa11618@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message > Date: Mon, 17 Jun 96 8:39:18 EDT > From: Glenn Randers-Pehrson ARL-WTD-TED-TIB > Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) What I was trying to transmit: Adam says: > > I see what you're trying to do--simplify pnmtopng's job. In the > extreme, pnmtopng wouldn't even have to know the syntax of the chunks: > > P6 > #PNG chunk=tEXt > #PNG string= > #PNG byte=0 > #PNG string= > #PNG = > #PNG chunk=tEXt > #PNG string= > #PNG byte=0 > #PNG string= > #PNG = > #PNG chunk=gAMA > #PNG fixedpoint=0.5 #PNG long=50000 [unless you define "fixedpoint" to always mean "multiply by 100000 and write as a network-byte-order-long"] > #PNG chunk=bKGD > #PNG short=50 > #PNG short=50 > #PNG short=150 #PNG short=50 50 150 > #PNG chunk=tRNS > #PNG short=0 > #PNG short=0 > #PNG short=0 #PNG short=0 0 0 > 640 480 > 255 > RGB data This is pretty good. You could make the "PNG type" syntax mean "all remaining entries on this line are this type", as shown. pnmtopng is going to have to know the syntax of those chunks whose syntax depends on color_type, like tRNS, though. If pnmtopng were to convert this to a color_type 3 file, the tRNS chunk would then make the first six colors transparent instead of just making black transparent. The zTXt chunk format would be tricky, because you'd want to write it in the pnm file in clear text, not compressed.. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 09:50:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA12823 for ; Mon, 17 Jun 1996 09:50:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA20481 for png-implement-outgoing; Mon, 17 Jun 1996 09:51:05 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA20476 for ; Mon, 17 Jun 1996 09:51:02 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA09728; Mon, 17 Jun 1996 14:47:53 GMT Date: Mon, 17 Jun 1996 14:47:53 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606171447.AA09728@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Glenn responds: > > #PNG fixedpoint=0.5 > > #PNG long=50000 [unless you define "fixedpoint" to always mean "multiply > by 100000 and write as a network-byte-order-long"] I think I remember discussions on png-list in which people said that they wanted to keep the number of representations of numerical data to a minimum, and this precise format is one of those representations. "fixedpoint" is too long. How about "fixed" (somewhat analogous to "float")? > You could make the "PNG type" syntax mean "all remaining entries on > this line are this type", as shown. Sure, for types "byte", "short", "long", and "fixedpoint". Not for "chunk" or "string". > pnmtopng is going to have to know the syntax of those chunks whose > syntax depends on color_type, like tRNS, though. Good point. Maybe pngtopnm should include the HEAD chunk, to give pnmtopng some defaults that the user could override. I suppose pngtopnm and pnmtopng should both consider themselves to be making critical changes for the purposes of copying chunks. At the very least pngtopng should--remember that recompression of the IDATs is a critical change. > The zTXt chunk format would be tricky, because you'd want to write it > in the pnm file in clear text, not compressed.. #PNG chunk=zTXt # Look, we can put real comments in the ppm file! #PNG string= #PNG byte=0 #PNG zstring= # The compression type byte is implicit in zstring. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 10:13:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA13417 for ; Mon, 17 Jun 1996 10:13:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA20771 for png-implement-outgoing; Mon, 17 Jun 1996 10:14:52 -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 KAA20765 for ; Mon, 17 Jun 1996 10:14:47 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id LAA29777 for ; Mon, 17 Jun 1996 11:11:33 -0400 (EDT) To: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) In-reply-to: Your message of Mon, 17 Jun 1996 14:47:53 GMT <9606171447.AA09728@siesta.cs.wustl.edu> Date: Mon, 17 Jun 1996 11:11:33 -0400 Message-ID: <29774.835024293@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Before anyone gets too carried away with inventing a PNM-comment representation of everything in PNG, let me point out one small problem: PNM comments will be discarded by every image-manipulation program that exists in the PBMPLUS package. Thus, the real-world value of this exercise is pretty limited. I can't think of any reason for converting PNG to PNM unless it's to run some member(s) of the PBMPLUS suite on the image. A more practical approach might be to extend pngtopnm to drop safe-to-copy chunks into a separate file, whence they could be merged back into the end product file by pnmtopng. Or just provide the original PNG file as an optional input to pnmtopng, and it could extract the safe-to-copy chunks itself. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 10:52:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA14398 for ; Mon, 17 Jun 1996 10:52:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA21379 for png-implement-outgoing; Mon, 17 Jun 1996 10:55:29 -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 KAA21368 for ; Mon, 17 Jun 1996 10:55:21 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id LAA29881 for ; Mon, 17 Jun 1996 11:52:12 -0400 (EDT) cc: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) In-reply-to: Your message of Mon, 17 Jun 1996 11:11:33 -0400 <29774.835024293@sss.pgh.pa.us> Date: Mon, 17 Jun 1996 11:52:11 -0400 Message-ID: <29879.835026731@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I said: > A more practical approach might be to extend pngtopnm to drop > safe-to-copy chunks into a separate file, whence they could > be merged back into the end product file by pnmtopng. I was thinking of this "separate file" as containing raw PNG chunks that could simply be copied. But on second thought, the right answer is to convert the chunks to a readable/editable textual format. This would provide a handy facility for examining and correcting the auxiliary chunks in a PNG file. (For example, fixing an incorrect gamma value.) Once you start thinking along these lines, the correct solution is a pair of tools that have nothing directly to do with PPM, and need not be part of pngtopnm/pnmtopng. I envision: * pngextract: extract contents of non-image chunks from a PNG file and produce a textual, editable representation in an output text file. * pnginsert: accept a PNG file and a text file containing chunk representations; produce a PNG file with the text file's chunks inserted. Some thought needs to go into switches for these utilities that would offer the most useful behaviors. For example, I can see wanting pngextract to extract all non-image chunks, just safe-to-copy chunks, or just chunks of a specified type (eg tEXt). pnginsert would need options controlling what to do with chunks found in the input PNG file. The syntax of the textual representation could use the ideas that have been kicked around in this thread, but there's no need to force it to look like a PPM comment. Pick something that's as easy to read and edit as possible. Such a facility would solve the PPM-comment problem, at the cost of an extra step or two in the pipeline, and would have lots of other applications. regards, tom lane PS: no, I'm not volunteering to write it ;-) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 11:13:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA15084 for ; Mon, 17 Jun 1996 11:13:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA23022 for png-implement-outgoing; Mon, 17 Jun 1996 11:16:55 -0500 Received: from v9000.ntu.ac.sg (v9000.ntu.ac.sg [155.69.1.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA23004 for ; Mon, 17 Jun 1996 11:16:49 -0500 Received: from ntuvax.ntu.ac.sg by ntuvax.ntu.ac.sg (PMDF V5.0-6 #7636) id <01I618IRQUHYA2DNM8@ntuvax.ntu.ac.sg> for png-implement@dworkin.wustl.edu; Tue, 18 Jun 1996 00:14:44 +0800 Date: Tue, 18 Jun 1996 00:14:44 +0800 From: "WILLEM VAN SCHAIK (INTERNET: GWILLEM@NTUVAX.NTU.AC.SG)" Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) To: png-implement@dworkin.wustl.edu Message-id: <01I618IRRIZCA2DNM8@ntuvax.ntu.ac.sg> Organization: Nanyang Technological University - Singapore X-VMS-To: IN%"png-implement@dworkin.wustl.edu" X-VMS-Cc: GWILLEM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tom wrote: > PNM comments will be discarded by every image-manipulation > program that exists in the PBMPLUS package. > Thus, the real-world value of this exercise is pretty limited. > I can't think of any reason for converting PNG to PNM unless > it's to run some member(s) of the PBMPLUS suite on the image. I knew already :-) that something was missing. Well, I was already wondering, why I had never seen pnm-comments before. So this is the answer. Which also brings me to another issue: if you have the source of let's say abctopnm and you take the source of pnmtopngm, then it is not that much work to make a dedicated abctopng. I did that for tifftopng. It was not that much work, and it opens suddenly all possibilities for really finetuning the converter. And let's be honest. PNG was meant to be universal, simple, clear, functional, extensible, compact, whatever, ... so what is a better way than just replace pbm/pgm/ppm with png. Thus, we just make for each format we know an abctopng and a pngtoabc and we just use png as the universal intermediate format . Life can be so simple! Willem ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 12:51:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA01524 for ; Mon, 17 Jun 1996 12:51:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA26056 for png-implement-outgoing; Mon, 17 Jun 1996 12:54:33 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA26031 for ; Mon, 17 Jun 1996 12:54:26 -0500 Date: Mon, 17 Jun 96 13:49:05 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606171349.aa19248@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message > > I said: > > A more practical approach might be to extend pngtopnm to drop > > safe-to-copy chunks into a separate file, whence they could > > be merged back into the end product file by pnmtopng. > > I was thinking of this "separate file" as containing raw PNG chunks > that could simply be copied. But on second thought, the right answer > is to convert the chunks to a readable/editable textual format. > This would provide a handy facility for examining and correcting > the auxiliary chunks in a PNG file. (For example, fixing an incorrect > gamma value.) > > Once you start thinking along these lines, the correct solution is > a pair of tools that have nothing directly to do with PPM, and need > not be part of pngtopnm/pnmtopng. I envision: > > * pngextract: extract contents of non-image chunks from a PNG file > and produce a textual, editable representation in an output text file. > > * pnginsert: accept a PNG file and a text file containing chunk > representations; produce a PNG file with the text file's chunks > inserted. > This is pretty much what I'm doing now, except that I found it convenient to use exactly PPM format for the image data, extended to 16-bits. I presently write the other chunks into a separate file (or two files, one for the before-idat chunks and another for the after-idat chunks), in a readable/editable format (this thread started because I had an extra newline in the file that caused a null keyword in collage.png. But I think the idea of using netpbm comments is a good one because this way all of the information can reside in a single file.) You're right, though, that the comments are pretty likely to disappear if you do any netpbm processing on the file. Adam says: PNG zstring= Very good. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 13:04:55 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA01623 for ; Mon, 17 Jun 1996 13:04:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA26842 for png-implement-outgoing; Mon, 17 Jun 1996 13:07:47 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA26830 for ; Mon, 17 Jun 1996 13:07:36 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id LAA05939 for ; Mon, 17 Jun 1996 11:00:46 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id LAA16173 for png-implement@dworkin.wustl.edu; Mon, 17 Jun 1996 11:00:45 -0700 (PDT) Message-Id: <199606171800.LAA16173@web1.calweb.com> Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) To: png-implement@dworkin.wustl.edu Date: Mon, 17 Jun 1996 11:00:45 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <29774.835024293@sss.pgh.pa.us> from "Tom Lane" at Jun 17, 96 11:11:33 am Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > Before anyone gets too carried away with inventing a PNM-comment > representation of everything in PNG, let me point out one small > problem: PNM comments will be discarded by every image-manipulation > program that exists in the PBMPLUS package. With all due respect, Tom, so what? PBMPLUS is just one package (albeit an important one). But a simple, complete textual format for PNG information would be a useful thing, and we should not let the limitations of existing tools cripple our efforts to do worthwhile things. Keeping auxilliary information when converting files is a useful thing--that's why I registered a TIFF tag for PNG info. A standard way to put them into PNM comments as well is clean, natural, and useful. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 13:47:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA02186 for ; Mon, 17 Jun 1996 13:47:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA28185 for png-implement-outgoing; Mon, 17 Jun 1996 13:50:59 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA28179 for ; Mon, 17 Jun 1996 13:50:54 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id UAA56245 for ; Mon, 17 Jun 1996 20:47:37 +0200 Received: from fb0404.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA158777258; Mon, 17 Jun 1996 20:47:39 +0200 Received: from localhost by fb0404.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA283307252; Mon, 17 Jun 1996 20:47:32 +0200 Date: Mon, 17 Jun 1996 20:47:32 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) In-Reply-To: <01I618IRRIZCA2DNM8@ntuvax.ntu.ac.sg> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, On Tue, 18 Jun 1996, WILLEM VAN SCHAIK (GWILLEM@NTUVAX.NTU.AC.SG) wrote: > Tom wrote: > > > PNM comments will be discarded by every image-manipulation > > program that exists in the PBMPLUS package. > > Thus, the real-world value of this exercise is pretty limited. > > I can't think of any reason for converting PNG to PNM unless > > it's to run some member(s) of the PBMPLUS suite on the image. And even worse, a considerable part of pbm+ reading programs will simply break on files containing comments (I even found at least one that relies on the single whitespace character after maxval to be newline). > I knew already :-) that something was missing. Well, I was already > wondering, why I had never seen pnm-comments before. So this is > the answer. Which also brings me to another issue: if you have the > source of let's say abctopnm and you take the source of pnmtopngm, > then it is not that much work to make a dedicated abctopng. I did > that for tifftopng. It was not that much work, and it opens suddenly > all possibilities for really finetuning the converter. > > And let's be honest. PNG was meant to be universal, simple, clear, > functional, extensible, compact, whatever, ... so what is a better > way than just replace pbm/pgm/ppm with png. Thus, we just make for > each format we know an abctopng and a pngtoabc and we just use png > as the universal intermediate format . Life can be so simple! But implementing a xxxtopng or pngtoxxx filter is more complicated that with pbm+. The original reason why I got into the PNG discussion at all was that I thought the proposed filtering (in rev. 6 or something) was not good, so I wrote a few filtering programs that read ppm or pgm file and applied whatever filter to it and wrote the file again. Then I could test the filter efficiency with gzip. The reason why pbm is great as an intermediate format is that it can be read by a few lines of C code (though not completely conforming to the spec, of course) and you don't need the pbm libraries. I occasionally even create small pnm files with an editor, I wouldn't want to write a program to interface with libpng just for that (though pnmtopng can do this job, of course). OK, now for my take on the data thing, I would prefer a reasonably simple way to preserve text comments when the file is converted to pnm and back, given the current lack of other tools, this would provide a means to edit the text chunks in a png file, among other things. Being able to preserve other data may be useful too (e.g. phys), but I think the main application will be text data. For this reason I would prefer the format to keep the structure of the text chunks closely so that they can be read OK in the pnm file (e.g. with less) while still reversible. Since we have to have some kind of escape char (for EOL etc), we can either choose %, = or \, % is used in HTML (and printf, sortof), = in quoted-printable (MIME) and \ is used in C. I always despised the octal numbers in C, so I would go for =, unless there is reason to believe that a considerable number of ='s will appear in PNG text (I always hate to see three lines of =3d just because someone delimited the signature with = instead of -). IMHO the format should look like this: Pn # Keyword: text # 2nd line # Keyword: text 640 480 255 ... Since we can use empty lines (I think) we don't need a delimiter for the end of multiline text. A = can be used (but doesn't have to be) for escaping Latin1 chars as well as whitespace if necessary. Also, if the last char on a line is =, no newline is generated. (This would make it possible to keep the lines reasonably short.) If a : appears in a keyword, it has to be escaped also, as well as = anywhere in the text. Maybe there could be an option in pngtopnm to write the text data into a separate file (or just instead of the decoded image) which then can be read pnmtopng again to recover the text. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 14:51:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA03257 for ; Mon, 17 Jun 1996 14:51:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA00998 for png-implement-outgoing; Mon, 17 Jun 1996 14:53:45 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA00989 for ; Mon, 17 Jun 1996 14:53:38 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id VAA35068 for ; Mon, 17 Jun 1996 21:50:26 +0200 Received: from fb0404.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA160291027; Mon, 17 Jun 1996 21:50:28 +0200 Received: from localhost by fb0404.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA285141022; Mon, 17 Jun 1996 21:50:22 +0200 Date: Mon, 17 Jun 1996 21:50:21 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Forgot a minor point: On Mon, 17 Jun 1996, Alexander Lehmann wrote: > IMHO the format should look like this: > > Pn > # Keyword: text > # 2nd line > > # Keyword: text > 640 480 > 255 > ... > > Since we can use empty lines (I think) we don't need a delimiter for > the end of multiline text. If we want to support other PNG data as well, we could use lines starting with :, since empty keywords are not allowed. Something like # :pYHs # something Probably it would make sense to decode known chunks to a human readable form (though I'm not sure if it is worth it). Unkown chunks can be represented as hex dump, I guess. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 15:00:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03328 for ; Mon, 17 Jun 1996 15:00:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA01284 for png-implement-outgoing; Mon, 17 Jun 1996 15:03:32 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA01271 for ; Mon, 17 Jun 1996 15:03:28 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA25330; Mon, 17 Jun 1996 19:59:55 GMT Date: Mon, 17 Jun 1996 19:59:55 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606171959.AA25330@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Alexander says: > Also, if the last char on a line is =, no newline is generated. (This > would make it possible to keep the lines reasonably short.) Continuation of lines is a complication that I'm not sure we need. Here's another way it could be done: #PNG chunk=tEXt #PNG string=Example #PNG string=Here is line one. #PNG =Here is #PNG + line two. #PNG + It is split among four li # Look, I can put ppm-level comments anywhere! #PNG +nes in the ppm file. #PNG =Here is line three. The advantage here is that we avoid escape characters (always a bonus in my book). The disadvantage is that we need slightly more lookahead in the parser. Do we really need any sort of escape character? Aren't most editors and pagers 8-bit clean by now? > I would prefer the format to keep the structure of the text chunks > closely so that they can be read OK in the pnm file (e.g. with less) > while still reversible. There is a trade-off between pnmtopng complication and human-readability. If we don't mind increasing the former in order to increase the latter, we could include shortcuts in the format for well-known, "privileged" chunks, like this: #PNG tEXt Key1: Value1 #PNG tEXt Key2: Value2 # Multi-line tEXt chunks would have to use the full format, # as would tEXt chunks whose keyword contains a colon. # But we get nice readability in the common case. #PNG gAMA 0.5 #PNG bKGD 50 50 50 #PNG chunk=bLAh #PNG short=67 #PNG short=91 # Chunks not on the privileged list, like bLAh, need to use the full # format. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 17 18:37:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA06463 for ; Mon, 17 Jun 1996 18:37:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA04159 for png-implement-outgoing; Mon, 17 Jun 1996 18:40:30 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA04154 for ; Mon, 17 Jun 1996 18:40:27 -0500 Received: from munet-i.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA03722; Mon, 17 Jun 1996 17:37:14 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-i.enel.ucalgary.ca (8.6.12/8.6.12) id RAA09742 for png-implement@dworkin.wustl.edu; Mon, 17 Jun 1996 17:41:57 -0600 Message-Id: <199606172341.RAA09742@munet-i.enel.ucalgary.ca> Subject: new libpng-0.89 To: png-implement@dworkin.wustl.edu (PNG Implementation) Date: Mon, 17 Jun 1996 17:41:56 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello All, I've uploaded a new version of libpng-0.89 to swrinde in the incoming directory. I think these can go into png/src to be mirrored, and announced on the PNG WWW page, and uploaded to CompuServe. Fixed in this version: halloc(), png_voidp for png_create_struct(), filter and filler problems. What hasn't been added in this version is: png_set_strip_alpha() (or something similar) internationalization of error and warning messages png_warning() instead of png_error() for CRC errors on ancillary chunks Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 18 00:38:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id AAA08611 for ; Tue, 18 Jun 1996 00:38:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA07450 for png-implement-outgoing; Tue, 18 Jun 1996 00:39:38 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA07445 for ; Tue, 18 Jun 1996 00:39:35 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id AAA10505 for ; Tue, 18 Jun 1996 00:35:50 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id AAA27834; Tue, 18 Jun 1996 00:36:57 -0500 (CDT) Date: Tue, 18 Jun 1996 00:36:57 -0500 (CDT) From: Cave Newt Message-Id: <199606180536.AAA27834@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: new libpng-0.89 Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > I've uploaded a new version of libpng-0.89 to swrinde in the incoming > directory. I think these can go into png/src to be mirrored, and > announced on the PNG WWW page, and uploaded to CompuServe. Um...how exactly did it get uploaded *last* June?? %-} libpng-0.89c.tar.gz 115 Kb Sun Jun 18 03:51:00 1995 lpng089c.zip 128 Kb Sun Jun 18 03:51:00 1995 Also, is there a reason why the most current copies of the PNG extensions (0.96) are all in png-group? I just updated the docs, and I know there's a fair amount of discussion going on currently, but aren't these basically public docs? Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 18 10:26:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA14704 for ; Tue, 18 Jun 1996 10:26:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA12285 for png-implement-outgoing; Tue, 18 Jun 1996 10:28:24 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA12280 for ; Tue, 18 Jun 1996 10:28:18 -0500 Received: from ntuix.ntu.ac.sg (yuan.ntu.ac.sg [155.69.4.55]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id XAA27200 for ; Tue, 18 Jun 1996 23:24:49 +0800 (SST) Date: Tue, 18 Jun 1996 23:24:49 +0800 (SST) Message-Id: <199606181524.XAA27200@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 08:47 PM 6/17/96 +0200, you wrote: >Hello all, > >On Tue, 18 Jun 1996, WILLEM VAN SCHAIK (GWILLEM@NTUVAX.NTU.AC.SG) wrote: >> And let's be honest. PNG was meant to be universal, simple, clear, >> functional, extensible, compact, whatever, ... so what is a better >> way than just replace pbm/pgm/ppm with png. Thus, we just make for >> each format we know an abctopng and a pngtoabc and we just use png >> as the universal intermediate format . Life can be so simple! > >But implementing a xxxtopng or pngtoxxx filter is more complicated >that with pbm+. [...] The reason >why pbm is great as an intermediate format is that it can be read by a >few lines of C code (though not completely conforming to the spec, of >course) and you don't need the pbm libraries. I occasionally even >create small pnm files with an editor, I wouldn't want to write a >program to interface with libpng just for that (though pnmtopng can do >this job, of course). He Alex, I must presume that we two are the biggest pnm-hackers in this PNG group. So, don't think that I was very serious about dropping pnm in favour of png. Just some silly thoughts and should I have put in more smiley's ???? >Maybe there could be an option in pngtopnm to write the text data into >a separate file (or just instead of the decoded image) which then can >be read pnmtopng again to recover the text. And now I will be serious. Yes really. What I could easily implement is that pngtopnm when using the -text option is not (only) displaying the text on screen (as it does it now (and also not very nicely)), but that it will write it to a file compatible with the format now used by pnmtopng. This solution has the advantage of being simple and I think the syntax I chose for pnmtopng is rather suitable for manual editing. See you, Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 18 10:29:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA14801 for ; Tue, 18 Jun 1996 10:29:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA12334 for png-implement-outgoing; Tue, 18 Jun 1996 10:31:18 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA12321 for ; Tue, 18 Jun 1996 10:31:12 -0500 Received: from ntuix.ntu.ac.sg (yuan.ntu.ac.sg [155.69.4.55]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id XAA27035 for ; Tue, 18 Jun 1996 23:27:51 +0800 (SST) Date: Tue, 18 Jun 1996 23:27:51 +0800 (SST) Message-Id: <199606181527.XAA27035@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: PNG data in PNM (was pnmtopng (was authors's collage)) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 09:50 PM 6/17/96 +0200, Alex wrote: >Forgot a minor point: >If we want to support other PNG data as well, we could use lines starting >with :, since empty keywords are not allowed. >Something like ># :pYHs ># something > It is my opinion that having the pnmtopng/pngtopnm extended for reading and writing a text-chunk, but when you want to go further for other types of chunks, I'm more in favour of Tom's proposal (pngextract and pnginsert). Willem ------------------------------------------------------------------------------ Gintic - Singapore gwillem@ntuvax.ntu.ac.sg http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 18 12:22:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA19749 for ; Tue, 18 Jun 1996 12:22:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA14417 for png-implement-outgoing; Tue, 18 Jun 1996 12:23:58 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA14411 for ; Tue, 18 Jun 1996 12:23:52 -0500 Received: from munet-i.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id LAA05805; Tue, 18 Jun 1996 11:20:30 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-i.enel.ucalgary.ca (8.6.12/8.6.12) id LAA10405 for png-implement@dworkin.wustl.edu; Tue, 18 Jun 1996 11:25:06 -0600 Message-Id: <199606181725.LAA10405@munet-i.enel.ucalgary.ca> Subject: Re: new libpng-0.89 To: png-implement@dworkin.wustl.edu Date: Tue, 18 Jun 1996 11:25:06 -0600 (MDT) In-Reply-To: <199606180536.AAA27834@ellis.uchicago.edu> from "Cave Newt" at Jun 18, 96 00:36:57 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Greg writes: > Um...how exactly did it get uploaded *last* June?? %-} > > libpng-0.89c.tar.gz 115 Kb Sun Jun 18 03:51:00 1995 > lpng089c.zip 128 Kb Sun Jun 18 03:51:00 1995 I've been sitting on this new version for a year now, waiting for the libpng version numbers to catch up before I used it?? :-) The date on the file is set by the ftp host, and not the uploader, so maybe the date at swrinde is wrong? Since the 0.89 version of libpng is public, we can also move the new XV patch from png-group into the public png/applications directory, and update the PNG home page (image viewers and image converters) with the new URL (it is ot currently included in the "Code from the PNG Group" section). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 18 13:21:42 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA22334 for ; Tue, 18 Jun 1996 13:21:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA15108 for png-implement-outgoing; Tue, 18 Jun 1996 13:22:46 -0500 Received: from maxwell.nde.swri.edu (maxwell.nde.swri.edu [129.162.171.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA15102 for ; Tue, 18 Jun 1996 13:22:41 -0500 Received: (from ksp@localhost) by maxwell.nde.swri.edu (8.7.4/8.7.1) id NAA07544 for png-implement@dworkin.wustl.edu; Tue, 18 Jun 1996 13:19:25 -0500 (CDT) Message-Id: <199606181819.NAA07544@maxwell.nde.swri.edu> From: ksp@maxwell.nde.swri.edu (Keith S. Pickens) Date: Tue, 18 Jun 1996 13:19:25 -0500 In-Reply-To: adilger@enel.ucalgary.ca (Andreas Dilger) "Re: new libpng-0.89" (Jun 18, 11:25am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: PNG Implementation List Subject: Re: new libpng-0.89 Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List On Jun 18, 11:25am, Andreas Dilger wrote: } Subject: Re: new libpng-0.89 } Greg writes: } > Um...how exactly did it get uploaded *last* June?? %-} } > } > libpng-0.89c.tar.gz 115 Kb Sun Jun 18 03:51:00 1995 } > lpng089c.zip 128 Kb Sun Jun 18 03:51:00 1995 } } I've been sitting on this new version for a year now, waiting for } the libpng version numbers to catch up before I used it?? :-) } } The date on the file is set by the ftp host, and not the uploader, } so maybe the date at swrinde is wrong? I get: 117760 Jun 17 22:51 libpng-0.89c.tar.gz 131236 Jun 17 22:51 lpng089c.zip The date/time on swrinde is correct +-20 milliseconds (NTP based). Strange. } Since the 0.89 version of } libpng is public, we can also move the new XV patch from png-group } into the public png/applications directory, and update the PNG home } page (image viewers and image converters) with the new URL (it is } ot currently included in the "Code from the PNG Group" section). Moved xv-3.10a-png-1.2b.tar.gz into png/applications. -keith ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Tue Jun 18 19:17:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA26469 for ; Tue, 18 Jun 1996 19:17:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA20003 for png-implement-outgoing; Tue, 18 Jun 1996 19:18:47 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA19998 for ; Tue, 18 Jun 1996 19:18:43 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id TAA20766 for ; Tue, 18 Jun 1996 19:14:54 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id TAA00315 for png-implement@dworkin.wustl.edu; Tue, 18 Jun 1996 19:16:02 -0500 (CDT) Date: Tue, 18 Jun 1996 19:16:02 -0500 (CDT) From: Cave Newt Message-Id: <199606190016.TAA00315@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: new libpng-0.89 Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > 117760 Jun 17 22:51 libpng-0.89c.tar.gz > 131236 Jun 17 22:51 lpng089c.zip > The date/time on swrinde is correct +-20 milliseconds (NTP based). Aside from the timezone (anonftp is GMT), that looks the same as what I see today. Then again, I'm using an older version of Netscape; maybe it was a bug in 3.0b4 for Linux. In other news: Keith, you can go ahead and remove all of the xpaint 2.3.1-png stuff; as of 2.4.x, PNG support is fully integrated, and I've already removed the links to swrinde's copy from the PNG pages. Thanks, Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 07:19:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA05267 for ; Fri, 21 Jun 1996 07:19:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA23860 for png-implement-outgoing; Fri, 21 Jun 1996 07:20:00 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA23855 for ; Fri, 21 Jun 1996 07:19:56 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id OAA11126; Fri, 21 Jun 1996 14:16:24 +0200 Date: Fri, 21 Jun 1996 14:16:24 +0200 From: Chris Lilley Message-Id: <199606211216.OAA11126@www47.inria.fr> To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-Reply-To: <199606141813.LAA00396@web1.calweb.com> References: <9606141727.AA27141@siesta.cs.wustl.edu> <199606141813.LAA00396@web1.calweb.com> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Lee Daniel Crocker writes: > You might also want to run the idea by Jef just to make sure he > doesn't have conflicting ideas. It is my understanding that Jef Poskanzer is no longer actively involved in the PBM development; the last release was I think in 1991, hence the NetPBM toolkit which came after that. -- Chris ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 08:15:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA06058 for ; Fri, 21 Jun 1996 08:15:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA24311 for png-implement-outgoing; Fri, 21 Jun 1996 08:18:54 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA24306 for ; Fri, 21 Jun 1996 08:18:50 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id PAA43249 for ; Fri, 21 Jun 1996 15:15:11 +0200 Received: from fb0410.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA018272912; Fri, 21 Jun 1996 15:15:12 +0200 Received: from localhost by fb0410.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA276222908; Fri, 21 Jun 1996 15:15:08 +0200 Date: Fri, 21 Jun 1996 15:15:08 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-Reply-To: <199606211216.OAA11126@www47.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, On Fri, 21 Jun 1996, Chris Lilley wrote: > Lee Daniel Crocker writes: > > > You might also want to run the idea by Jef just to make sure he > > doesn't have conflicting ideas. > > It is my understanding that Jef Poskanzer is no longer actively > involved in the PBM development; the last release was I think in 1991, > hence the NetPBM toolkit which came after that. Actually, there is a pbmplus mail list with Jef and lots of other people on it, the problems seems to be that a new release of the suite is planned, but due to lack of time or whatever, nothing has happened yet. Someone on the list released a revised netpbm version some time back collecting the patches available, but a official release should happen at some time. The address is pbmplus@lists1.best.com, the address of Jef is jef@acme.com, I think. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 10:23:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA08491 for ; Fri, 21 Jun 1996 10:23:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA26011 for png-implement-outgoing; Fri, 21 Jun 1996 10:26:42 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA26005 for ; Fri, 21 Jun 1996 10:26:36 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id RAA11494; Fri, 21 Jun 1996 17:23:03 +0200 Date: Fri, 21 Jun 1996 17:23:03 +0200 From: Chris Lilley Message-Id: <199606211523.RAA11494@www47.inria.fr> To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-Reply-To: References: <199606211216.OAA11126@www47.inria.fr> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Alexander Lehmann writes: > Hello all, > > On Fri, 21 Jun 1996, Chris Lilley wrote: > > > Lee Daniel Crocker writes: > > > > > You might also want to run the idea by Jef just to make sure he > > > doesn't have conflicting ideas. > > > > It is my understanding that Jef Poskanzer is no longer actively > > involved in the PBM development; the last release was I think in 1991, > > hence the NetPBM toolkit which came after that. > > Actually, there is a pbmplus mail list with Jef and lots of other > people on it, the problems seems to be that a new release of the suite > is planned, but due to lack of time or whatever, nothing has happened > yet. For half a decade. Right. > Someone on the list released a revised netpbm version some time > back collecting the patches available, yes, that is what everyone uses nowadays > but a official release should happen at some time. Real Soon Now, as Pournelle would say. ;-) -- Chris ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 12:53:42 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA11425 for ; Fri, 21 Jun 1996 12:53:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA28542 for png-implement-outgoing; Fri, 21 Jun 1996 12:56:49 -0500 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA28537 for ; Fri, 21 Jun 1996 12:56:45 -0500 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) id NAA02457 for png-implement@dworkin.wustl.edu; Fri, 21 Jun 1996 13:53:12 -0400 Message-Id: <199606211753.NAA02457@qnx.com> Subject: Re: pnmtopng (was author's collage) To: png-implement@dworkin.wustl.edu Date: Fri, 21 Jun 1996 13:53:06 -0400 (EDT) From: "Chris Herborth" In-Reply-To: <199606211216.OAA11126@www47.inria.fr> from "Chris Lilley" at Jun 21, 96 02:16:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List What Chris wrote: > Lee Daniel Crocker writes: > > > You might also want to run the idea by Jef just to make sure he > > doesn't have conflicting ideas. > > It is my understanding that Jef Poskanzer is no longer actively > involved in the PBM development; the last release was I think in 1991, > hence the NetPBM toolkit which came after that. I'm on the PBM-Plus mailing list and can back Chris up here. Jef sticks his head in once every century or so, but it pretty much just shambles along without intervention. Every now and then someone gets up the gumption to collect all the patches that have been sent to the list and do something about it... thus the slightly more up-to-date sources for NetPBM (netpbm-1-mar-94.p1.tar.gz or something similar on ftp.x.org) that are floating about. -- ----------================================================---------- _ Chris Herborth, R&D Technical Writer (chrish@qnx.com) | \ _ QNX Software Systems, Ltd. Arcane Dragon -==(UDIC)==- | < /_\ http://www.qnx.com/~chrish/ DNRC Holder of Past Knowledge |_/ \_ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 19:27:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA15497 for ; Fri, 21 Jun 1996 19:27:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA04490 for png-implement-outgoing; Fri, 21 Jun 1996 19:31:01 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA04485 for ; Fri, 21 Jun 1996 19:30:56 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id CAA85013 for ; Sat, 22 Jun 1996 02:27:21 +0200 Received: from fb0401.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA052093238; Sat, 22 Jun 1996 02:27:19 +0200 Received: from localhost by fb0401.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA069143238; Sat, 22 Jun 1996 02:27:18 +0200 Date: Sat, 22 Jun 1996 02:27:18 +0200 (MESZ) From: Alexander Lehmann To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-Reply-To: <199606211753.NAA02457@qnx.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Hello all, On Fri, 21 Jun 1996, Chris Herborth wrote: > What Chris wrote: > > Lee Daniel Crocker writes: > > > > > You might also want to run the idea by Jef just to make sure he > > > doesn't have conflicting ideas. > > > > It is my understanding that Jef Poskanzer is no longer actively > > involved in the PBM development; the last release was I think in 1991, > > hence the NetPBM toolkit which came after that. > > I'm on the PBM-Plus mailing list and can back Chris up here. Jef sticks > his head in once every century or so, but it pretty much just shambles > along without intervention. Well, the list is not one of the most active once. Since I moved my subsciption to another address beginning of May there were 16 mails 5 of which about spam. But I think Lee's point about asking Jef before inventing possibly conflicting features in pbm is still valid. BTW, maybe we should suggest enhancing the pbm spec to include 4 channel (rbg+alpha) data or is this of not enough use. The advantage would problaby be that programs reading ppm or pgm files could just ignore the alpha channel, if the libraries are revised. Given that some other programs support alpha channels (e.g. ImageMagick I think), maybe this would be useful. BTW. if pbmplus has a problem with being too seldomly updated, Image Magick is the exact opposite, it seems like the author is uploading a new version every two days to ftp.x.org. (At some point I reported a PNG releated bug fix and the fixed version was on our local mirror the next day). bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." !!CHANGED!! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 19:38:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA15522 for ; Fri, 21 Jun 1996 19:38:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA04562 for png-implement-outgoing; Fri, 21 Jun 1996 19:41:55 -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 TAA04557 for ; Fri, 21 Jun 1996 19:41:51 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id UAA18060 for ; Fri, 21 Jun 1996 20:38:16 -0400 (EDT) To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-reply-to: Your message of Sat, 22 Jun 1996 02:27:18 +0200 (MESZ) Date: Fri, 21 Jun 1996 20:38:16 -0400 Message-ID: <18058.835403896@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > But I think Lee's point about asking Jef before > inventing possibly conflicting features in pbm is still valid. Yes, I agree. Jef did promise me at one point that he was going to define types P7 and P8 as two-byte-per-sample raw PGM and PPM formats. (In fact, I implemented support for same in the IJG code on his say-so.) regards, tom lane organizer, Independent JPEG Group ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 19:58:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA15625 for ; Fri, 21 Jun 1996 19:58:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA04699 for png-implement-outgoing; Fri, 21 Jun 1996 20:01:19 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA04694 for ; Fri, 21 Jun 1996 20:01:16 -0500 Received: from ellis.uchicago.edu (roe2@ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id TAA20828 for ; Fri, 21 Jun 1996 19:57:07 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id TAA29512 for png-implement@dworkin.wustl.edu; Fri, 21 Jun 1996 19:58:19 -0500 (CDT) Date: Fri, 21 Jun 1996 19:58:19 -0500 (CDT) From: Cave Newt Message-Id: <199606220058.TAA29512@ellis.uchicago.edu> To: png-implement@dworkin.wustl.edu Subject: Re: pnmtopng (was author's collage) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > Yes, I agree. Jef did promise me at one point that he was going to > define types P7 and P8 as two-byte-per-sample raw PGM and PPM formats. This is getting waaayyy off-topic, but...is there a point? XV already accepts 16-bit data via P5 and P6 with the appropriate MAXVAL (i.e., > 255). I understand that apps that don't check for this will have to be modified or recompiled, but that's true of P7/P8 files, too. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 21 20:21:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA15707 for ; Fri, 21 Jun 1996 20:21:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA04941 for png-implement-outgoing; Fri, 21 Jun 1996 20:24:48 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA04936 for ; Fri, 21 Jun 1996 20:24:42 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA25591 for ; Sat, 22 Jun 1996 09:21:06 +0800 (SST) Date: Sat, 22 Jun 1996 09:21:06 +0800 (SST) Message-Id: <199606220121.JAA25591@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: pnmtopng (was author's collage) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 02:27 22-06-1996 +0200, Alex wrote: >Well, the list is not one of the most active once. Since I moved my >subsciption to another address beginning of May there were 16 mails 5 >of which about spam. But I think Lee's point about asking Jef before >inventing possibly conflicting features in pbm is still valid. >bye, Alexander Anybody who can tell me how to subscribe to that list. I think I'm in need for something like "Listservers for dummies" but OK, I tried to send a message with "help", which only resulted in that that was not a valid request, but no remark what was then the valid one. I will not elaborate on my other 10 attempts, but they were all unsuccessful. So, who of you on that list can still remember how he did that. Must be something overly simple. Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sat Jun 22 12:10:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA20038 for ; Sat, 22 Jun 1996 12:10:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA13048 for png-implement-outgoing; Sat, 22 Jun 1996 12:13:14 -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 MAA13041 for ; Sat, 22 Jun 1996 12:13:10 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id NAA18703 for ; Sat, 22 Jun 1996 13:07:59 -0400 (EDT) To: PNG Implementation List Subject: Re: pnmtopng (was author's collage) In-reply-to: Your message of Fri, 21 Jun 1996 19:58:19 -0500 (CDT) <199606220058.TAA29512@ellis.uchicago.edu> Date: Sat, 22 Jun 1996 13:07:58 -0400 Message-ID: <18701.835463278@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I said: >> Yes, I agree. Jef did promise me at one point that he was going to >> define types P7 and P8 as two-byte-per-sample raw PGM and PPM formats. Greg said: > This is getting waaayyy off-topic, but...is there a point? XV already > accepts 16-bit data via P5 and P6 with the appropriate MAXVAL (i.e., > 255). > I understand that apps that don't check for this will have to be modified > or recompiled, but that's true of P7/P8 files, too. Sigh, should've checked the code before writing. What's in both XV and the IJG code is that existing types P5 and P6 are taken to be 2 bytes/sample if the specified maxval is between 256 and 65535. Jef has blessed this, although his original opinion was that defining new P-numbers would be safer. I guess he decided that it'd be smarter to save the remaining P-numbers for some other type of expansion that would really need 'em. Support for this is supposed to be in the fabled next release of pbmplus. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 23 10:17:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA25461 for ; Sun, 23 Jun 1996 10:17:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA24355 for png-implement-outgoing; Sun, 23 Jun 1996 10:16:33 -0500 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA24350 for ; Sun, 23 Jun 1996 10:16:25 -0500 Received: from 199.3.232.2.phoenix.net (dial56.phoenix.net [205.241.121.70]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id KAA08057 for ; Sun, 23 Jun 1996 10:16:20 -0500 Message-Id: <199606231516.KAA08057@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-implement@dworkin.wustl.edu Date: Sun, 23 Jun 1996 10:16:10 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Medium model fixes Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Lip89c needs some changes to work with the medium memory model. I have made these, but I have also made some more radical changes that I want to discuss here before I send them to Andreas. I hope some UNIX folks will read this message since it does affect you somewhat. The current situation is that Zlib needs both near and far pointers. Libpng has gotten rid of most (but not all) near pointers. However the nomenclature is confusing. Some folks were asking about this earlier. Here is the scoop: Zlib: voidp is near (is the same as void *) voidpf is far (is the same as void far *) Libpng: png_voidp is far (is the same as void far *) This is unfortunately confusing. voidp should be used in Libpng only with variables that are related to Zlib. Otherwise, png_voidp or just plain void * should be used. If I do a minimal repair of the medium model problems in Libpng, there are still a few variables that have to be near, namely any variables that have to do with standard I/O. The trouble with this is it is of course very difficult for UNIX folks to keep the memory model considerations straight, so nearly every update will be broken for the medium model until I fix it. (BTW there ARE folks out there who need the medium model besides me; it IS worthwhile.) I propose to eliminate all near variables from Libpng. Then you would NEVER use void *, but ALWAYS use png_voidp. All the medium model complications would be confined to a few routines that use the standard I/O) functions. In some cases (eg io_ptr) near values would be carried in far variables. I believe this would make code maintenance much easier, since UNIX and other flat memory model programmers would be much less likely to break medium model support. All you'd have to remember is to always use Libpng typedefs such as png_voidp and not use void * or any Zlib typedefs (except when dealing with Zlib variables.) I have already made these changes in my version, and I can compile with no warnings or errors under the medium model, large model, or djgpp (flat model). There are only a very few void * declarations left in spots local to I/O functions. If there are any comments, let me know. I can look into a similar change for Zlib if Jean-loup will let me but I haven't done it yet in my version. Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 23 11:50:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA25727 for ; Sun, 23 Jun 1996 11:50:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA25043 for png-implement-outgoing; Sun, 23 Jun 1996 11:49:07 -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 LAA25038 for ; Sun, 23 Jun 1996 11:49:03 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id MAA19378 for ; Sun, 23 Jun 1996 12:48:58 -0400 (EDT) To: PNG Implementation List Subject: Re: Medium model fixes In-reply-to: Your message of Sun, 23 Jun 1996 10:16:10 -0500 <199606231516.KAA08057@mail.phoenix.net> Date: Sun, 23 Jun 1996 12:48:57 -0400 Message-ID: <19376.835548537@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tim writes: > I propose to eliminate all near variables from Libpng. Then you would > NEVER use void *, but ALWAYS use png_voidp. All the medium model > complications would be confined to a few routines that use the > standard I/O) functions. In some cases (eg io_ptr) near values > would be carried in far variables. Seems reasonable to me. IIRC I had to do much the same thing in libjpeg to make it portable to small/medium model. The only thing I would worry about is that any heavily referenced data that is actually near shouldn't be referenced through a far pointer for performance reasons. In particular, you probably want png_struct to be cheap to access, so pointer-to-png_struct shouldn't have a "far" in it. "void *" is unlikely to be the only pointer type that has to be consistently replaced by a typedef. I haven't examined the libpng source to see what else might be worrisome, but I'd be suspicious of *any* unadorned use of "*" in a variable declaration. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 23 22:22:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id WAA27959 for ; Sun, 23 Jun 1996 22:22:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA00923 for png-implement-outgoing; Sun, 23 Jun 1996 22:21:23 -0500 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA00913 for ; Sun, 23 Jun 1996 22:21:16 -0500 Received: from 199.3.232.2.phoenix.net (dial99.phoenix.net [205.241.121.113]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id WAA29757 for ; Sun, 23 Jun 1996 22:21:09 -0500 Message-Id: <199606240321.WAA29757@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-implement@dworkin.wustl.edu Date: Sun, 23 Jun 1996 22:21:06 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Medium model fixes Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I have emailed Andreas the diff file with medium model changes. If anyone else is interested, it's at: ftp://ftp.phoenix.net/pub/USERS/twegner/LIBP89D.ZIP Of course these aren't official until Andreas decides to incorporate them. In the notes I forgot to mention that one of the problems is that the signature is declared differently in png.h and in the .c where it is defined (far in one case, not far in the other). This bug has been rediscovered by me and reported four or five times, but keeps coming back to life like the Zombies in Night of the Living Dead. I hope Andreas can kill it for good ... Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 24 02:33:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id CAA28958 for ; Mon, 24 Jun 1996 02:33:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA03126 for png-implement-outgoing; Mon, 24 Jun 1996 02:32:14 -0500 Received: from enel.ucalgary.ca ([136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA03118 for ; Mon, 24 Jun 1996 02:32:10 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id BAA18191; Mon, 24 Jun 1996 01:32:01 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606240732.BAA18191@enel.ucalgary.ca> Subject: Re: Medium model fixes To: png-implement@dworkin.wustl.edu Date: Mon, 24 Jun 1996 01:32:01 -0600 (MDT) In-Reply-To: <199606240321.WAA29757@mail.phoenix.net> from "Tim Wegner" at Jun 23, 96 10:21:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Tim writes: > I have emailed Andreas the diff file with medium model changes. Thanks, I will incorporate it. I will take your word that everything works OK, as DOS memory management is all voodoo to me, and I don't have a DOS compiler (well, maybe an old copy of Turbo C 2.x that I haven't used in 5 years). > In the notes I forgot to mention that one of the problems is that > the signature is declared differently in png.h and in the .c where > it is defined (far in one case, not far in the other). Which way do you want it? Far or near? I have just completed changes that make most CRC errors into warnings, rather than fatal errors (this is only for ancillary chunks and IEND, and the data is then ignored). I haven't yet made it possible to override the errors for CRC errors in critical chunks. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Mon Jun 24 21:04:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA15517 for ; Mon, 24 Jun 1996 21:04:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA14802 for png-implement-outgoing; Mon, 24 Jun 1996 21:03:29 -0500 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA14796 for ; Mon, 24 Jun 1996 21:03:20 -0500 Received: from 199.3.232.2.phoenix.net (dial100.phoenix.net [205.241.121.114]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id VAA27205 for ; Mon, 24 Jun 1996 21:03:00 -0500 Message-Id: <199606250203.VAA27205@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: png-implement@dworkin.wustl.edu Date: Mon, 24 Jun 1996 21:02:58 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Medium model fixes Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas wrote: > > In the notes I forgot to mention that one of the problems is that > > the signature is declared differently in png.h and in the .c where > > it is defined (far in one case, not far in the other). > > Which way do you want it? Far or near? In the diff file I sent you I made it use FARDATA: png_byte FARDATA png_sig[8] I really don't care if it is far or near as long as it is the same in png.h and png.c If it's wrong (declared inconsistently in both places), then under the medium model the signature check fails and the user gets the message "not a PNG file". So it's not a mistake I'll ever miss! The idea of FARDATA is to give the programmer a choice between near and far for data. If the program is short of free near space, then they can choose far. This change is in the diff I sent, I only mentioned it befcause I forgot to make a note about this in readme.tw. And it is amusing how this keeps coming back again and again! I would appreciate hearing from anyone about medium model issues. Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Thu Jun 27 18:19:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA27703 for ; Thu, 27 Jun 1996 18:19:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA06313 for png-implement-outgoing; Thu, 27 Jun 1996 18:19:38 -0500 Received: from tide19.microsoft.com (tide19.microsoft.com [131.107.3.29]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA06306 for ; Thu, 27 Jun 1996 18:19:32 -0500 Received: by tide19.microsoft.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB6444.5C007C30@tide19.microsoft.com>; Thu, 27 Jun 1996 16:19:04 -0700 Message-ID: From: John Bowler To: "png-implement@dworkin.wustl.edu" Subject: RE: PNG support in Netscape and Internet Explorer Date: Thu, 27 Jun 1996 16:19:50 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 47 TEXT Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I took the liberty of redirecting this to the implementation list, since it seems very low level for the global list. >From: adilger@enel.ucalgary.ca[SMTP:adilger@enel.ucalgary.ca] >Sent: Thursday, June 27, 1996 2:58 PM >To: png-list@dworkin.wustl.edu >Subject: Re: PNG support in Netscape and Internet Explorer > > >... Looking at my compiled object files, some of the >larger ones such as pngrtran.c, pngrutil.c, pngpread.c, pngread.c, and >pngwutil.c could stand to be spilt up in some fashion. As I understand >it, the linkers are only allowed to select complete object files >because >of issues like static global variables and function pointers. Of >course >libpng doesn't have any global variables, so splitting up the files >should >be a relatively easy job, and this would shift the PNG_XXX_SUPPORTED >issue >to the linker (with the exception of the variables in the png_struct). In 0.88 I had to alter some of the _SUPPORTED cases in the png_struct (png.h) to be able to remove the selection of facilities I wanted to remove, in particular PNG_READ_BACKGROUND_SUPPORTED was used in a number of places where tRNS or GAMMA were required. One possibility is to generate a makefile which is capable of compiling the whole library with every possible _SUPPORTED macro on/off combination - it must be just a simple awk script :-) libpng does have global data - in particular the chunk id strings and the crc32 table (which is duplicated, in 0.88, over that in zlib/crc32.c - sorry if this is all hopelessly out of data, but I stopped merging in new versions in April). I don't think this causes problems with function level linking in practice and of course any good development system now supports function level linking and has done so for at least, let me see, 3 months :-) (This is the /Gy option in Microsoft Visual C, if anyone is interested... also I believe MacOS has worked this way for many years, possibly for ever.) On the other hand I have never had any problem developing code on the one-function-per-file basis as was used in the BSD (4.3-) libc implementation because of the ancient (but very fast) BSD ld implementation. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 07:01:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA02097 for ; Fri, 28 Jun 1996 07:01:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA13246 for png-implement-outgoing; Fri, 28 Jun 1996 07:01:13 -0500 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA13238 for ; Fri, 28 Jun 1996 07:01:09 -0500 Received: by iguana.reptiles.org via send-mail with stdio id for png-implement@dworkin.wustl.edu; Fri, 28 Jun 96 08:00:35 -0400 (EDT) (Smail-3.1.93 1996-May-30 #2 built 1996-Jun-15) Message-Id: Date: Fri, 28 Jun 96 08:00:35 -0400 (EDT) From: smar@reptiles.org (Smarasderagd) To: png-implement@dworkin.wustl.edu Subject: tEXt, zTXt and other ancillary chunks, plaintext format Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List After looking at some current programs and playing around on my own, I have a suggestion for how to output text chunks in plaintext format for use by programs like pnmtopng, pngtopnm and so on. Basically, the format would be like this: NAME [keyword ...] blah blah blah blah blah blah blah ..this line has a leading period, so we escape it. the next line is a period on a line by itself, which indicates the end ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 08:04:55 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA04733 for ; Fri, 28 Jun 1996 08:04:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA13745 for png-implement-outgoing; Fri, 28 Jun 1996 08:05:14 -0500 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA13740 for ; Fri, 28 Jun 1996 08:05:10 -0500 Received: by iguana.reptiles.org via send-mail with stdio id for png-implement@dworkin.wustl.edu; Fri, 28 Jun 96 09:04:36 -0400 (EDT) (Smail-3.1.93 1996-May-30 #2 built 1996-Jun-15) Message-Id: Date: Fri, 28 Jun 96 09:04:36 -0400 (EDT) From: smar@reptiles.org (Smarasderagd) To: png-implement@dworkin.wustl.edu Subject: tEXt, zTXt etc. Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Siiigh. I forgot that mailx ALSO considers '.' on a line by itself to be an end of message marker. It's just as well, as I had a whole lot of second thoughts. Once more from the top: text/tEXt/zTXt [flag ...] keyword Blah blah blah blah blah ..escape lines beginning with . next line is . by itself which ends the chunk From owner-png-implement@dworkin.wustl.edu Fri Jun 28 09:37:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA06176 for ; Fri, 28 Jun 1996 09:37:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA14883 for png-implement-outgoing; Fri, 28 Jun 1996 09:37:31 -0500 Received: from eye.eye.com (eye.eye.com [149.54.1.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA14869 for ; Fri, 28 Jun 1996 09:37:21 -0500 Received: from hemlock (hemlock.eye.com) by eye.eye.com with SMTP ($Revision: 1.36.108.11 $/16.2) id AA280842605; Fri, 28 Jun 1996 10:36:45 -0400 Received: by hemlock (1.37.109.8/15.6) id AA01115; Fri, 28 Jun 1996 10:36:44 -0400 Date: Fri, 28 Jun 1996 10:36:44 -0400 From: Eric Haines Message-Id: <9606281436.AA01115@hemlock> To: erich@hemlock.eye.com, png-implement@dworkin.wustl.edu, png-list@dworking.wustl.edu Subject: PNG alpha multiplication is a must Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I have put an interesting PNG image into: ftp://swrinde.nde.swri.edu/pub/incoming/png/alphtext.png By reading it in you can determine if a reader properly uses alpha or not. Here's my interest: In the latest spec (28 May 1996) it states in section 9.4: The alpha channel can be regarded either as a mask that temporarily hides transparent parts of the image, or as a means for constructing a non-rectangular image. In the first case, the color values of fully transparent pixels should be preserved for future use. In the second case, the transparent pixels carry no useful data and are simply there to fill out the rectangular image area required by PNG... Encoders should keep in mind the possibility that a decoder will ignore transparency control. This wording is a bit unnerving to me, as a programmer for a commercial product which will read and write PNG files. It implies that PNG readers have the choice of multiplying the color channels by alpha, or not, depending on what they want to do. This is different than all other image file formats, in which the image, when read in, always yields (essentially) the same image. This would be fine if there was a hint in the image file itself saying either: * I'm using alpha for blending and so color channels should be should be multiplied by the alphas. * I've stored image data in the background pixels and want it displayed. Unfortunately, there is no such hint currently as to which to do with any given data. The default is to multiply by alpha, but the "Encoders..." line in the spec is bad news, since the alphas are not premultiplied (that's one advantage of premultiplied alphas; you can ignore the alphas completely when reading in the image). PNG, it seems to me, wants to have it both ways: sometimes you want to see the data "hidden" in the background (transparent) pixels, sometimes you don't. Some readers default to ignoring alphas, which IMHO is something not to be encouraged. So what's the test image alphtext.png about? If you do multiply by the alphas you get an image that says "Reader does use alpha", if you ignore the alphas you get "Reader does not use alpha". However, more importantly, note the image quality when read using each method. When you use the alphas, the text has better antialiased borders, and my email address at the bottom is readable. If you ignore the alphas you get a hard to read email address, and you also get white dots around the borders of the text. These are from pixels where the values were something like "(2,2,2)" after alpha multiplication, but by not multiplying the color (say 255,255,255) by the alpha of "2" the pixel comes out bright and noticeable - not multiplying by alpha gives an ugly result. Just something to be aware of, and I hope we all will strongly support alpha multiplication to be the default way to view files (alternately, if this "feature" of hiding information where the alphas are 0 is important, adding a bit flag to PNG to say what the default method is for reading a particular file could be done - the spec's frozen, though, so I'm not sure how likely this is). What do people think? Is hiding information in the background where alphas are 0 all that important? This is a useful mode only when the alphas are either 0 or 255 (i.e. when there's just a transparency bit) - when you have alphas that are fractional this "hiding" feature becomes essentially useless: you can have the image look good with multiplied alphas, or you can have it look good without alphas getting blended in, but you cannot have both when there are fractional alphas. Eric Haines erich@eye.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 10:13:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA06475 for ; Fri, 28 Jun 1996 10:13:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA15600 for png-implement-outgoing; Fri, 28 Jun 1996 10:14:15 -0500 Received: from maxwell.nde.swri.edu (maxwell.nde.swri.edu [129.162.171.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA15595 for ; Fri, 28 Jun 1996 10:14:12 -0500 Received: (from ksp@localhost) by maxwell.nde.swri.edu (8.7.4/8.7.1) id KAA12964 for png-implement@dworkin.wustl.edu; Fri, 28 Jun 1996 10:13:40 -0500 (CDT) Message-Id: <199606281513.KAA12964@maxwell.nde.swri.edu> From: ksp@maxwell.nde.swri.edu (Keith S. Pickens) Date: Fri, 28 Jun 1996 10:13:40 -0500 In-Reply-To: Eric Haines "PNG alpha multiplication is a must" (Jun 28, 10:36am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: PNG Implementation List Subject: Re: PNG alpha multiplication is a must Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List On Jun 28, 10:36am, Eric Haines wrote: } Subject: PNG alpha multiplication is a must } I have put an interesting PNG image into: } } ftp://swrinde.nde.swri.edu/pub/incoming/png/alphtext.png } Moved to ftp://swrinde.nde.swri.edu/pub/png-group/images/alphtext.png -keith ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 13:55:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA10531 for ; Fri, 28 Jun 1996 13:55:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA18577 for png-implement-outgoing; Fri, 28 Jun 1996 13:55:55 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA18572 for ; Fri, 28 Jun 1996 13:55:52 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA05454; Fri, 28 Jun 1996 18:55:18 GMT Date: Fri, 28 Jun 1996 18:55:18 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606281855.AA05454@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: representing tEXt chunks in text files X-Advice: perhaps read whenever Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List I just remembered another problem. (I was dealing with a similar issue months ago.) In all the representations discussed so far, there has been no way to indicate whether the value ends with a newline or not. "foo" and "foo\n" both appear the same in the text file. Also, "foo\nbar" and "foo\nbar\n" appear the same. How lossless does it have to be? :) AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 14:23:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA10765 for ; Fri, 28 Jun 1996 14:23:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA18990 for png-implement-outgoing; Fri, 28 Jun 1996 14:23:59 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA18980 for ; Fri, 28 Jun 1996 14:23:45 -0500 Date: Fri, 28 Jun 96 15:21:47 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: representing tEXt chunks in text files Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606281521.aa02665@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message }Date: Fri, 28 Jun 1996 18:55:18 GMT }From: "Adam M. Costello" }Subject: representing tEXt chunks in text files }I just remembered another problem. (I was dealing with a similar }issue months ago.) In all the representations discussed so far, there }has been no way to indicate whether the value ends with a newline or }not. "foo" and "foo\n" both appear the same in the text file. Also, }"foo\nbar" and "foo\nbar\n" appear the same. How lossless does it have }to be? :) I think my implementation would give foo foo\n foo\nbar foo\n\bar\n #=foo #=foo #=foo #=foo #= #=bar #=bar #= } }AMC } ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 15:16:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA11241 for ; Fri, 28 Jun 1996 15:16:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA19814 for png-implement-outgoing; Fri, 28 Jun 1996 15:16:31 -0500 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA19809 for ; Fri, 28 Jun 1996 15:16:26 -0500 Received: by iguana.reptiles.org via send-mail with stdio id for png-implement@dworkin.wustl.edu; Fri, 28 Jun 96 16:15:48 -0400 (EDT) (Smail-3.1.93 1996-May-30 #2 built 1996-Jun-15) Message-Id: Date: Fri, 28 Jun 96 16:15:48 -0400 (EDT) From: smar@reptiles.org (Smarasderagd) To: png-implement@dworkin.wustl.edu Subject: Re: representing tEXt chunks in text files Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Have I mentioned that I hate my mailer? I'm going to try this ONE more time: text/tEXt/zTXt [flag ...] keyword Blah Blah Blah blah blah ..escape lines starting with a period next line is a single . which indicates the end . 'tEXt' or 'zTXt' forces creation of the corresponding chunk type, and 'text' (which is an illegal chunk name) indicates that an encoder should make up its own mind. 'flag' can be: notrail - ignore last newline pre - goes before image data post - goes after image data This would allow faithful representation of zero-length strings, strings with no terminating newline, keywords with spaces in them, and the compression and position of the resulting chunk. For cases where we want to preserve chunks which violate the spec in some nasty way, we could have a 'base64' flag to indicate that text is encoded. You could also use this to represent other, possibly unknown ancillary chunks. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 15:57:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA12211 for ; Fri, 28 Jun 1996 15:57:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA20431 for png-implement-outgoing; Fri, 28 Jun 1996 15:57:57 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA20426 for ; Fri, 28 Jun 1996 15:57:53 -0500 Date: Fri, 28 Jun 96 16:57:04 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: representing tEXt chunks in text files Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606281657.aa04100@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List }}From: "Adam M. Costello" }}Subject: representing tEXt chunks in text files }}I just remembered another problem. (I was dealing with a similar }}issue months ago.) In all the representations discussed so far, there }}has been no way to indicate whether the value ends with a newline or }}not. "foo" and "foo\n" both appear the same in the text file. Also, }}"foo\nbar" and "foo\nbar\n" appear the same. How lossless does it have }}to be? :) I think we also have to consider foo\fbar\n and foo\rbar\n as well as long lines. They could be =foo =foo =foobarfoobarfoobar...... /bar -bar +fooobarfoooobar = = = My Fortran background wanted me to escape the FF with a "1" but never mind that. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 19:44:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA14674 for ; Fri, 28 Jun 1996 19:44:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA23827 for png-implement-outgoing; Fri, 28 Jun 1996 19:44:33 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA23822 for ; Fri, 28 Jun 1996 19:44:28 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id IAA21995 for ; Sat, 29 Jun 1996 08:43:52 +0800 (SST) Date: Sat, 29 Jun 1996 08:43:52 +0800 (SST) Message-Id: <199606290043.IAA21995@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 08:00 28-06-1996 -0400, you wrote: >After looking at some current programs and playing around on my own, >I have a suggestion for how to output text chunks in plaintext format >for use by programs like pnmtopng, pngtopnm and so on. In the pnmtopng/pngtopnm version 2.3 I recently uploaded, both read and write to a separate text-file is now supported with the following format. If you like it or if you don't, I think you have to stick with it for a while ..... it's a pity :-) ---8x===----------------------------------------------------------- Author Mr Nobody Title Funky picture Description This picture is created as a PNG image and is used for not other reason than to whatever.... Copyright (c) Amsterdam, 1957 ---8x===----------------------------------------------------------- If it's an optimal format, I doubt it. But at least it works. Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 20:32:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA14813 for ; Fri, 28 Jun 1996 20:32:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA24420 for png-implement-outgoing; Fri, 28 Jun 1996 20:32:33 -0500 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA24415 for ; Fri, 28 Jun 1996 20:32:29 -0500 Received: by iguana.reptiles.org via send-mail with stdio id for png-implement@dworkin.wustl.edu; Fri, 28 Jun 96 21:31:51 -0400 (EDT) (Smail-3.1.93 1996-May-30 #2 built 1996-Jun-15) Message-Id: Date: Fri, 28 Jun 96 21:31:51 -0400 (EDT) From: smar@reptiles.org (Smarasderagd) To: png-implement@dworkin.wustl.edu Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem van Schaik writes: >If it's an optimal format, I doubt it. But at least it works. I think its main deficiency is that it doesn't allow for keywords with spaces in them. This would be a minor issue except that one of the standard keywords is "Creation Time", at least according to the spec at http://www.w3.org/pub/WWW/TR/WD-png. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Fri Jun 28 21:15:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA15111 for ; Fri, 28 Jun 1996 21:15:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA24733 for png-implement-outgoing; Fri, 28 Jun 1996 21:15:31 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA24725 for ; Fri, 28 Jun 1996 21:15:25 -0500 Received: from GIN324 ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id KAA27323 for ; Sat, 29 Jun 1996 10:13:19 +0800 (SST) Date: Sat, 29 Jun 1996 10:13:19 +0800 (SST) Message-Id: <199606290213.KAA27323@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG Implementation List From: Willem van Schaik Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List At 21:31 28-06-1996 -0400, you wrote: >Willem van Schaik writes: >>If it's an optimal format, I doubt it. But at least it works. > >I think its main deficiency is that it doesn't allow for keywords >with spaces in them. This would be a minor issue except that >one of the standard keywords is "Creation Time", at least according >to the spec at http://www.w3.org/pub/WWW/TR/WD-png. Good point. Hadn't thought of that one. Next release I will support quoting: Author Willem "Creation Time" 1 jan 1900 Title time-test or 'Creation Time' 1 jan 1900 Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 01:06:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id BAA24215 for ; Sun, 30 Jun 1996 01:06:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA10364 for png-implement-outgoing; Sun, 30 Jun 1996 01:06:17 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA10359 for ; Sun, 30 Jun 1996 01:06:13 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id AAA04944; Sun, 30 Jun 1996 00:05:32 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199606300605.AAA04944@enel.ucalgary.ca> Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format To: png-implement@dworkin.wustl.edu Date: Sun, 30 Jun 1996 00:05:31 -0600 (MDT) In-Reply-To: <199606290043.IAA21995@ntuix.ntu.ac.sg> from "Willem van Schaik" at Jun 29, 96 08:43:52 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem writes: > In the pnmtopng/pngtopnm version 2.3 I recently uploaded, both read > and write to a separate text-file is now supported with the following > format. > > ---8x===----------------------------------------------------------- > Copyright (c) Amsterdam, 1957 > ---8x===----------------------------------------------------------- I have to say I'm not overly fond of the format, as other people mentioned, it doesn't support spaces in keywords. Also, is there a limit on the length of keywords to 16 chars? Finally, when will people start using Latin-1 in their keywords (ie for the (c) symbol, rather the ASCII equivalent)? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 13:32:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA28246 for ; Sun, 30 Jun 1996 13:32:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA15849 for png-implement-outgoing; Sun, 30 Jun 1996 13:32:45 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA15842 for ; Sun, 30 Jun 1996 13:32:40 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id UAA15892; Sun, 30 Jun 1996 20:31:55 +0200 Date: Sun, 30 Jun 1996 20:31:55 +0200 From: Chris Lilley Message-Id: <199606301831.UAA15892@www47.inria.fr> To: PNG Implementation List Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format In-Reply-To: <199606290213.KAA27323@ntuix.ntu.ac.sg> References: <199606290213.KAA27323@ntuix.ntu.ac.sg> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Willem van Schaik writes: > At 21:31 28-06-1996 -0400, you wrote: > >Willem van Schaik writes: > >>If it's an optimal format, I doubt it. But at least it works. > > > >I think its main deficiency is that it doesn't allow for keywords > >with spaces in them. This would be a minor issue except that > >one of the standard keywords is "Creation Time", at least according > >to the spec at http://www.w3.org/pub/WWW/TR/WD-png. I had hit that problem already, and I use a local modification of the code so that it only uses a tab, rather than any whitespace, to delimiyt the keyword/phrase from the rest of the text. I figured that keywords with tabs in them were dumb enough that they wouldn't occur. > Good point. Hadn't thought of that one. Next release I will support > quoting: > > Author Willem > "Creation Time" 1 jan 1900 That's another way to do it. Since the spec disallows multiple or trailing spaces in keywords, perhaps two spaces would also be a suitable delimiter. -- Chris ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 13:34:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA28253 for ; Sun, 30 Jun 1996 13:34:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA15877 for png-implement-outgoing; Sun, 30 Jun 1996 13:34:46 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA15869 for ; Sun, 30 Jun 1996 13:34:42 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id UAA15900; Sun, 30 Jun 1996 20:33:57 +0200 Date: Sun, 30 Jun 1996 20:33:57 +0200 From: Chris Lilley Message-Id: <199606301833.UAA15900@www47.inria.fr> To: PNG Implementation List Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format In-Reply-To: <199606300605.AAA04944@enel.ucalgary.ca> References: <199606290043.IAA21995@ntuix.ntu.ac.sg> <199606300605.AAA04944@enel.ucalgary.ca> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Andreas Dilger writes: > I have to say I'm not overly fond of the format, as other people mentioned, > it doesn't support spaces in keywords. Also, is there a limit on the > length of keywords to 16 chars? Finally, when will people start using > Latin-1 in their keywords (ie for the (c) symbol, rather the ASCII > equivalent)? They already do. See the 8859.png file distributed with pngmeta for an example. -- Chris ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 14:14:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA28455 for ; Sun, 30 Jun 1996 14:14:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA16260 for png-implement-outgoing; Sun, 30 Jun 1996 14:15:31 -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 OAA16255 for ; Sun, 30 Jun 1996 14:15:27 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id PAA09567 for ; Sun, 30 Jun 1996 15:14:42 -0400 (EDT) To: PNG Implementation List Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format In-reply-to: Your message of Sun, 30 Jun 1996 20:31:55 +0200 <199606301831.UAA15892@www47.inria.fr> Date: Sun, 30 Jun 1996 15:14:41 -0400 Message-ID: <9565.836162081@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > I had hit that problem already, and I use a local modification of the > code so that it only uses a tab, rather than any whitespace, to > delimiyt the keyword/phrase from the rest of the text. I figured that > keywords with tabs in them were dumb enough that they wouldn't occur. Not only dumb, but explicitly forbidden by the spec: : Keywords must contain only printable Latin-1 characters and spaces; : that is, only character codes 32-126 and 161-255 decimal are allowed. > That's another way to do it. Since the spec disallows multiple or > trailing spaces in keywords, perhaps two spaces would also be a > suitable delimiter. I like tab better; it seems safer. Tabs in keywords were prohibited in draft 10 (well, it says "printable characters" which arguably disallows tabs) whereas the no-multiple-space rule is relatively recent. However tab might be harder to distinguish visually than two spaces, since with the right keyword length it could look just like a single space. Anyone for two consecutive tabs? Or is that just overkill? Quoting doesn't seem like a good answer since a keyword can legally contain a quote. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 15:54:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA28842 for ; Sun, 30 Jun 1996 15:54:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA17162 for png-implement-outgoing; Sun, 30 Jun 1996 15:55:23 -0500 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA17157 for ; Sun, 30 Jun 1996 15:55:20 -0500 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA27916; Sun, 30 Jun 1996 20:54:36 GMT Date: Sun, 30 Jun 1996 20:54:36 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9606302054.AA27916@siesta.cs.wustl.edu> To: png-implement@dworkin.wustl.edu Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format X-Advice: perhaps read whenever Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List Someone said: > That's another way to do it. Since the spec disallows multiple or > trailing spaces in keywords, perhaps two spaces would also be a > suitable delimiter. Tom Lane replied: > I like tab better; it seems safer. Tabs in keywords were prohibited > in draft 10 (well, it says "printable characters" which arguably > disallows tabs) whereas the no-multiple-space rule is relatively > recent. Tabs are evil. I would argue against their use whenever possible. The no-multiple-space rule may be recent, but honestly, how many keywords do you suspect have actually been created with multiple spaces? My guess: exactly zero. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 16:25:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA29033 for ; Sun, 30 Jun 1996 16:25:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA17581 for png-implement-outgoing; Sun, 30 Jun 1996 16:26:16 -0500 Received: from iguana.reptiles.org (iguana.reptiles.org [198.96.117.130]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA17576 for ; Sun, 30 Jun 1996 16:26:12 -0500 Received: by iguana.reptiles.org via send-mail with stdio id for png-implement@dworkin.wustl.edu; Sun, 30 Jun 96 17:25:23 -0400 (EDT) (Smail-3.1.93 1996-May-30 #2 built 1996-Jun-15) Message-Id: Date: Sun, 30 Jun 96 17:25:23 -0400 (EDT) From: smar@reptiles.org (Smarasderagd) To: png-implement@dworkin.wustl.edu Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List As a sort of compromise, how about putting the keyword on a line by itself, and terminate the text string with a blank line? ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 16:32:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA29088 for ; Sun, 30 Jun 1996 16:32:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA17646 for png-implement-outgoing; Sun, 30 Jun 1996 16:32:52 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA17640 for ; Sun, 30 Jun 1996 16:32:48 -0500 Date: Sun, 30 Jun 96 17:31:42 EDT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: PNG Implementation List Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9606301731.aa14321@THOR.ARL.MIL> Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List In reply to the message }Date: Sun, 30 Jun 96 17:25:23 -0400 (EDT) }From: Smarasderagd }Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format }As a sort of compromise, how about putting the keyword on a line }by itself, and terminate the text string with a blank line? That's how this thread started. The author's collage had a blank keyword because I was using that scheme, and had an extra blank line in my chunk-data file. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-implement@dworkin.wustl.edu Sun Jun 30 16:35:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA29105 for ; Sun, 30 Jun 1996 16:35:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA17678 for png-implement-outgoing; Sun, 30 Jun 1996 16:36:30 -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 QAA17673 for ; Sun, 30 Jun 1996 16:36:25 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id RAA09855 for ; Sun, 30 Jun 1996 17:35:35 -0400 (EDT) To: PNG Implementation List Subject: Re: tEXt, zTXt and other ancillary chunks, plaintext format In-reply-to: Your message of Sun, 30 Jun 96 17:31:42 EDT <9606301731.aa14321@THOR.ARL.MIL> Date: Sun, 30 Jun 1996 17:35:34 -0400 Message-ID: <9853.836170534@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-implement@dworkin.wustl.edu Precedence: bulk Reply-To: PNG Implementation List > }As a sort of compromise, how about putting the keyword on a line > }by itself, and terminate the text string with a blank line? > That's how this thread started. The author's collage had a blank > keyword because I was using that scheme, and had an extra blank line > in my chunk-data file. Allowing multiple blank lines between keyword+data groups would seem a simple improvement in the robustness of that format... of course you should also be checking that an alleged keyword meets the png spec's other restrictions... regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-implement-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body.