From owner-png-implement@ccrc.wustl.edu Sun Jan 2 15:21:20 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j02LLKC0008168 for ; Sun, 2 Jan 2005 15:21:20 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j02LLJ6i005849 for ; Sun, 2 Jan 2005 15:21:20 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4202305; Sun, 02 Jan 2005 15:20:45 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j02LKiUd017808 for ; Sun, 2 Jan 2005 15:20:44 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j02LJYs28999; Sun, 2 Jan 2005 15:19:34 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j02LJXQ28995 for ; Sun, 2 Jan 2005 15:19:33 -0600 (CST) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1ClD8P-0004nb-00 for png-implement@ccrc.wustl.edu; Sun, 02 Jan 2005 22:19:33 +0100 Received: from [84.135.57.66] (helo=buddha.localdomain.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ClD8P-0007LZ-00 for png-implement@ccrc.wustl.edu; Sun, 02 Jan 2005 22:19:33 +0100 Date: Sun, 2 Jan 2005 22:19:35 +0100 From: Chris confidential To: png-implement@ccrc.wustl.edu Subject: [png-implement] libpng12 error (propably unrelated to library content) Message-ID: <20050102221935.256f347e@buddha.localdomain.de> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3b2c3f724793a92e62915a6cfe16adb5 Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu [ non-member submission, don't forget to CC - Moderator ] Athens, January 2 2004 i_chris_pa@yahoo.com Hi, you dont't know me, but I still need your help. My name is Chris, I'm 18, I live in Greece (don't worry, I'll get to the problem) and I recently installed Linux Mandrake 8.2 on my old (and only) computer, a couple of days ago I updated it to 9.2 and everything was nice. Well, almost, the printer didn't work. So I read up on CUPS and LPD and yesterday I took action. Not really much, I called up a console (rxvt), stopped CUPS, removed all printers, added a new one (parallel port), restarted cups and that was about it. Right after that I wanted to see what changes were made in the /etc/printcap file when my GUI crashed. "Not a problem" I said to myself, "things like that happen sometimes". So I restarted the computer using shutdown -r now from the comand line on runlevel 3. And here's where you come in. The second KDE was about to start I got the error message "Error initializing inter-process communication could not read network connection list ~/.DCOPserver_localhost@localdomain__0 check if DCOP is running" I had no idea what DCOP was, so I read up on that server as well. Then I playd around with my network device a little bit, in case the server was ok but the loopback was down, which was not the case. Then I tried to start DCOP from the commandline to get the next error: "bla bla bla... /usr/lib/libpng12.so.0: no version information available (requested by libqt-mt.so.3) could not attach DCOP server" Now I know that it is not the libraries fault, propably some registerin a far away corner of my filessystem got altered or deleted. So I traced down the installation package this thing your libaray was part of, removed it (rpm --nodeps) and reinstalled it, hoping that Mandrake would reregister the library as installed - without success. In fact, things got even more confusing because rereinstalling it triggered "package already installed", querying for information on the package however caused "packet not installed". As a last resort I read through the readme files of the two libraries, that's were I got this Mail address from in the first place.Except from giving me somebody to address and disturb his privacy with my questions it didn't do me a lot of good though... So as I said, I know it is not the fault of your library, but this error is the last clue I was led to. I checked the manpages for the keywords, as well as my books - nothing. To make it short, I hope that you can help me out here or bounce this mail to somebody who can. By the way, the error occures only when starting kde or gnome, icewm starts just fine but does not have eny links to any applications available, so the only thing I can do there is log out again. The Window Manager works just fine, as I said, just KDE and Gnome... A preliminary thanks a lot, hope you can help me out. __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Mon Jan 3 18:39:09 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j040d8C0000036 for ; Mon, 3 Jan 2005 18:39:08 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j040d7aA002264 for ; Mon, 3 Jan 2005 18:39:07 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4250949; Mon, 03 Jan 2005 18:38:28 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j040cSUd015991 for ; Mon, 3 Jan 2005 18:38:28 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j040aew03251; Mon, 3 Jan 2005 18:36:40 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from mailgate.uni-paderborn.de (mailgate.uni-paderborn.de [131.234.22.32]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j040adQ03247 for ; Mon, 3 Jan 2005 18:36:39 -0600 (CST) Received: from vpn-cs15.uni-paderborn.de ([131.234.44.115] helo=pacomp) by mailgate.uni-paderborn.de with smtp (Exim 4.43) id 1Clcfs-000729-7W for png-implement@ccrc.wustl.edu; Tue, 04 Jan 2005 01:35:48 +0100 Message-ID: <008b01c4f1f5$cec428a0$0100a8c0@pacomp> From: "Jakob Wisor" To: Subject: [png-implement] What is wrong here? Date: Tue, 4 Jan 2005 01:38:57 +0100 Organization: University of Paderborn, Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-UNI-PB_FAK-EIM-MailScanner-Information: Please see http://imap.uni-paderborn.de for details X-UNI-PB_FAK-EIM-MailScanner: Found to be clean X-UNI-PB_FAK-EIM-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.82, required 4, ALL_TRUSTED -2.82) X-MailScanner-From: jwisor@upb.de Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu Hello, sorry to bother you, but I am out of ideas. None of the examples and test apps have revealed a hint to me. I am trying to load a PNG file into memory. I am using the DLL version 1.2.8 provided by the Gnuwin32 project. My compiler is MSVC 7. Error handling has been removed for readability reasons. What is wrong here: FILE *pngFile = NULL; png_info *pngInfo; png_struct *pngStruct; char pngHeader[8] = {0}; png_byte **pngRowPointers; pngFile = fopen("PNGTEST.PNG", "r"); /* if consider the next line, I am running on Win32 */ _setmode(_fileno(pngFile), _O_BINARY); fread(pngHeader, 1, 8, pngFile); png_sig_cmp(pngHeader, 0, 8) pngStruct = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL); pngInfo = png_create_info_struct(pngStruct); if (setjmp((*pngStruct).jmpbuf)) return; png_init_io(pngStruct, pngFile); png_set_sig_bytes(pngStruct, 8); /* everything goes right until here */ png_read_png(pngStruct, pngInfo, PNG_TRANSFORM_IDENTITY, NULL); /* the png_read_png() call crashes and terminates the app silently */ pngRowPointers = png_get_rows(pngStruct, pngInfo); png_destroy_read_struct(&pngStruct, &pngInfo, NULL); fclose(pngFile); Thank you for any help. -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Mon Jan 3 23:06:41 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0456fC0002272 for ; Mon, 3 Jan 2005 23:06:41 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0456eaA020170 for ; Mon, 3 Jan 2005 23:06:40 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4258752; Mon, 03 Jan 2005 23:06:24 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0456NUd014593 for ; Mon, 3 Jan 2005 23:06:24 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0456GK04065; Mon, 3 Jan 2005 23:06:16 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from wip-ectls-mx1.wipro.com (wip-ectls-mx1.wipro.com [203.101.113.37]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0456DQ04061 for ; Mon, 3 Jan 2005 23:06:13 -0600 (CST) Received: from wip-ectls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7AC4822026A for ; Tue, 4 Jan 2005 10:36:13 +0530 (IST) Received: from blr-ec-bh1.wipro.com (blr-ec-bh1.wipro.com [10.200.50.91]) by wip-ectls-mx1.wipro.com (Postfix) with ESMTP id 70C172204FC for ; Tue, 4 Jan 2005 10:36:13 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 10:36:12 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [png-implement] URGENT:INFO Date: Tue, 4 Jan 2005 10:35:59 +0530 Message-ID: <7EE204A11783534DB33779904613159B02342980@blr-ec-msg02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URGENT:INFO Thread-Index: AcTyGpGsBbUcV2D1QOCt00f3nXhfvAAAFUgA X-Priority: 1 Importance: high From: To: X-OriginalArrivalTime: 04 Jan 2005 05:06:12.0889 (UTC) FILETIME=[1C782090:01C4F21B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ccrc.wustl.edu id j0456FQ04062 Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu Hi, I have come across an error in my application while using the png_strip_alpha function. The condition for this function does not get satisfied and the displayed alpha image is incorrect. While opening an RGBA 8 bit image In this function:   png_do_strip_filler(png_row_infop row_info, png_bytep row, png_uint_32 flags) the following condition does not get satisfied if (row_info->color_type == PNG_COLOR_TYPE_RGB && row_info->channels == 4) Since the row_info->color_type is 6 (RGBA) and the value for PNG_COLOR_TYPE_RGB is 2. Same is the case for a GA image wrt the condition .. if (row_info->color_type == PNG_COLOR_TYPE_GRAY && row_info->channels == 2) I need to know why exactly is this condition set like this in the libpng? Does this mean that I have to modify the value of my color type to 2 manually before I read the image. Or is there some setting I am overlooking in my application? Or is this a flaw in the alpha strip function of the libpng? Please reply ASAP. Thanks, Cibby. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Tue Jan 4 01:41:51 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j047foC0005073 for ; Tue, 4 Jan 2005 01:41:50 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j047foaA000567 for ; Tue, 4 Jan 2005 01:41:50 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4263337; Tue, 04 Jan 2005 01:41:12 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j047fCUd001635 for ; Tue, 4 Jan 2005 01:41:12 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j047eUl04738; Tue, 4 Jan 2005 01:40:30 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from janet.rwhmax.com (janet.rwhmax.com [66.227.8.180]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j047eUQ04734 for ; Tue, 4 Jan 2005 01:40:30 -0600 (CST) Received: from s01060020af881903.cg.shawcable.net ([68.146.236.159] helo=volans) by janet.rwhmax.com with smtp (Exim 4.43) id 1CljIq-0000NQ-Hv; Tue, 04 Jan 2005 01:40:28 -0600 Message-ID: <000d01c4f230$a9718e40$5620a8c0@volans> From: "Willem van Schaik" To: Cc: References: <7EE204A11783534DB33779904613159B02342A41@blr-ec-msg02.wipro.com> Subject: [png-implement] png_strip_alpha Date: Tue, 4 Jan 2005 00:40:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - janet.rwhmax.com X-AntiAbuse: Original Domain - ccrc.wustl.edu X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - schaik.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu > > I am so sorry if my mail irritated you. > OK, all forgiven!!!. :-) IIRC, there was recently a lot of discussion going on about some changes in the png_strip_alpha function. If you are new on this list, check out the archives of png-implement (the last 3 months would do). I didn't follow the discussion too well, but if you need a quick fix, it is probably worthwile to try (at least temporarily) if your software works correctly with some older version of libpng. Good luck, Willem I am in a fix now and really needed to get some answers hence the mail. Hope you don't take it in the wrong sense. Thank you for understanding. Regards, Cibby. -----Original Message----- From: Willem van Schaik [mailto:willem@schaik.com] Sent: Tuesday, January 04, 2005 12:25 PM To: png-list@ccrc.wustl.edu Cc: Cibby Cherian (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS) Subject: Re: [png-list] URGENT:INFO Hi Cibby, > > Please reply ASAP. > So you're in a hurry, I can understand that. You sent your question to two png mailing lists (so I received two copies) and you put the status of your message to "High Priority". Well, let me tell you, for me that's the best recipe for getting irritated and not even reading your question. Good luck, Willem ----- Original Message ----- From: To: Cc: Sent: Monday, January 03, 2005 22:02 Subject: [png-list] URGENT:INFO Hi, I have come across an error in my application while using the png_strip_alpha function. The condition for this function does not get satisfied and the displayed alpha image is incorrect. While opening an RGBA 8 bit image In this function: png_do_strip_filler(png_row_infop row_info, png_bytep row, png_uint_32 flags) the following condition does not get satisfied if (row_info->color_type == PNG_COLOR_TYPE_RGB && row_info->channels == 4) Since the row_info->color_type is 6 (RGBA) and the value for PNG_COLOR_TYPE_RGB is 2. Same is the case for a GA image wrt the condition .. if (row_info->color_type == PNG_COLOR_TYPE_GRAY && row_info->channels == 2) I need to know why exactly is this condition set like this in the libpng? Does this mean that I have to modify the value of my color type to 2 manually before I read the image. Or is there some setting I am overlooking in my application? Or is this a flaw in the alpha strip function of the libpng? Please reply ASAP. Thanks, Cibby. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. -- Send the message body "help" to png-list-request@ccrc.wustl.edu Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Tue Jan 4 03:08:42 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0498fC0006895 for ; Tue, 4 Jan 2005 03:08:42 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0498faA007711 for ; Tue, 4 Jan 2005 03:08:41 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4266246; Tue, 04 Jan 2005 03:08:02 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j04981Ud012255 for ; Tue, 4 Jan 2005 03:08:02 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0497Xu05005; Tue, 4 Jan 2005 03:07:33 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from janet.rwhmax.com (janet.rwhmax.com [66.227.8.180]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0497WQ05001 for ; Tue, 4 Jan 2005 03:07:32 -0600 (CST) Received: from s01060020af881903.cg.shawcable.net ([68.146.236.159] helo=volans) by janet.rwhmax.com with smtp (Exim 4.43) id 1Clkf6-00046U-5U for png-implement@ccrc.wustl.edu; Tue, 04 Jan 2005 03:07:32 -0600 Message-ID: <001701c4f23c$cf5dff60$5620a8c0@volans> From: "Willem van Schaik" To: Subject: [png-implement] Fw: png_strip_alpha Date: Tue, 4 Jan 2005 02:07:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - janet.rwhmax.com X-AntiAbuse: Original Domain - ccrc.wustl.edu X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - schaik.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu ----- Original Message ----- From: To: Sent: Tuesday, January 04, 2005 00:55 Subject: RE: png_strip_alpha Hi Willem, Thank you for the fast response. The basic problem is I cant open any of the archives from my system that's why I have been up mailing you. After running through the libpng function I see the strip alpha function is not entered at all due to the condition set. Also I came across this comment /* STRIP_ALPHA and FILLER allowed: MASK_ALPHA bit stripped above */ Right before the strip filler function. I was hoping you would be able to give me an insight into this matter. What is the difference between strip alpha\filler and mask alpha? My application is able to display some incorrect image for alpha images....so I was wondering if there is any way I could resolve this issue.. Also please let me know how I could possibly get into the archives...is there some link online where I cud find these messages posted...because my system cant open any ftp link. Also one basic doubt I have is what's the relationship between :- png_ptr, info_ptr and row_info-> >From which of these structures is the image information taken for display in the end? Thank you once again. Cibby -----Original Message----- From: Willem van Schaik [mailto:willem@schaik.com] Sent: Tuesday, January 04, 2005 1:10 PM To: png-implement@ccrc.wustl.edu Cc: Cibby Cherian (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS) Subject: png_strip_alpha > > I am so sorry if my mail irritated you. > OK, all forgiven!!!. :-) IIRC, there was recently a lot of discussion going on about some changes in the png_strip_alpha function. If you are new on this list, check out the archives of png-implement (the last 3 months would do). I didn't follow the discussion too well, but if you need a quick fix, it is probably worthwile to try (at least temporarily) if your software works correctly with some older version of libpng. Good luck, Willem I am in a fix now and really needed to get some answers hence the mail. Hope you don't take it in the wrong sense. Thank you for understanding. Regards, Cibby. -----Original Message----- From: Willem van Schaik [mailto:willem@schaik.com] Sent: Tuesday, January 04, 2005 12:25 PM To: png-list@ccrc.wustl.edu Cc: Cibby Cherian (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS) Subject: Re: [png-list] URGENT:INFO Hi Cibby, > > Please reply ASAP. > So you're in a hurry, I can understand that. You sent your question to two png mailing lists (so I received two copies) and you put the status of your message to "High Priority". Well, let me tell you, for me that's the best recipe for getting irritated and not even reading your question. Good luck, Willem ----- Original Message ----- From: To: Cc: Sent: Monday, January 03, 2005 22:02 Subject: [png-list] URGENT:INFO Hi, I have come across an error in my application while using the png_strip_alpha function. The condition for this function does not get satisfied and the displayed alpha image is incorrect. While opening an RGBA 8 bit image In this function: png_do_strip_filler(png_row_infop row_info, png_bytep row, png_uint_32 flags) the following condition does not get satisfied if (row_info->color_type == PNG_COLOR_TYPE_RGB && row_info->channels == 4) Since the row_info->color_type is 6 (RGBA) and the value for PNG_COLOR_TYPE_RGB is 2. Same is the case for a GA image wrt the condition .. if (row_info->color_type == PNG_COLOR_TYPE_GRAY && row_info->channels == 2) I need to know why exactly is this condition set like this in the libpng? Does this mean that I have to modify the value of my color type to 2 manually before I read the image. Or is there some setting I am overlooking in my application? Or is this a flaw in the alpha strip function of the libpng? Please reply ASAP. Thanks, Cibby. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. -- Send the message body "help" to png-list-request@ccrc.wustl.edu Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Tue Jan 4 15:28:50 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j04LSof0017648 for ; Tue, 4 Jan 2005 15:28:50 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j04LSoaA016903 for ; Tue, 4 Jan 2005 15:28:50 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4299595; Tue, 04 Jan 2005 15:28:32 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j04LSVUd008124 for ; Tue, 4 Jan 2005 15:28:31 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j04LR5M07776; Tue, 4 Jan 2005 15:27:05 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j04LR5Q07772 for ; Tue, 4 Jan 2005 15:27:05 -0600 (CST) Received: from filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 87F2E103E4; Tue, 4 Jan 2005 21:27:05 +0000 (UTC) Received: from relay02.roc.ny.frontiernet.net ([66.133.131.35]) by filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) (amavisd-new, port 10024) with LMTP id 24672-52-74; Tue, 4 Jan 2005 21:27:05 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 2002610403; Tue, 4 Jan 2005 21:27:02 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1ClwCj-2hD-00; Tue, 04 Jan 2005 13:27:01 -0800 From: John Bowler To: , "'Chris confidential'" Subject: RE: [png-implement] libpng12 error (propably unrelated to library content) Date: Tue, 4 Jan 2005 13:26:59 -0800 Message-ID: <001301c4f2a4$21188570$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <20050102221935.256f347e@buddha.localdomain.de> X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter02.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu From: Chris confidential [i_chris_pa@yahoo.com] >>[ non-member submission, don't forget to CC >> - Moderator ] >Then I tried to start DCOP from the commandline to get the >next error: "bla bla bla... /usr/lib/libpng12.so.0: no version >information available (requested by libqt-mt.so.3) >could not attach DCOP server" My best guess (and it is only a guess) is that there are two copies of /usr/lib/libpng12.so.0 on your system and that something in the changes you made caused dcopserver(libqt-mt.so.3) to start to see the one in /usr/lib, not a special one built for libqt-mt. Still, I don't understand those messages - they seem to come from KDE (startkde?), which just calls dcopserver, but I'm not sure; if I remove my libpng and call dcopserver I just get: coruisk:/usr/lib# mv libpng.so.3 XXX coruisk:/usr/lib# /usr/kde/bin/dcopserver /usr/kde/bin/dcopserver: error while loading shared libraries: libpng.so.3: cannot open shared object file: No such file or directory So maybe the line "could not attach DCOP server" came from something else? Anyway, if this can be explained and I am right then libqt-mt.so.3 is looking for a copy of libpng12.so.0 which has been built with symbol versioning. This is non-standard - the distributed makefile does not put any version information in. Search for all copies of "libpng12.so*" on your system, if there is one in a Qt specific directory try using that instead (set LD_LIBRARY_PATH in .xsession for example). If that works then something has probably changed your LD_LIBRARY_PATH, or possibly installed libpng in /usr/lib when it wasn't there before. Note that shutdown -r can reveal pending DLL changes because the normal system boot runs "ldconfig" which rebuilds the DLL cache from /etc/ld.so.conf - so if you install /usr/lib/foo.so it may well not be noticed until the next reboot! To debug DLL problems use "ldd" on the executable then on the DLLs which is uses. ldd will tell you the actual path of the DLL being loaded, taking into account LD_LIBRARY_PATH. Take great care to ensure you use the right LD_LIBRARY_PATH. In this case the .xsession to start KDE routinely changes the value from that which you get from a regular tty login. This can be very confusing, even without the effects of /etc/ld.so.cache! John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Tue Jan 4 19:20:15 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j051KFf0021335 for ; Tue, 4 Jan 2005 19:20:15 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j051KEqh008533 for ; Tue, 4 Jan 2005 19:20:14 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4308552; Tue, 04 Jan 2005 19:19:48 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j051JlUd010351 for ; Tue, 4 Jan 2005 19:19:48 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j051JCv08513; Tue, 4 Jan 2005 19:19:12 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j051IrQ08509 for ; Tue, 4 Jan 2005 19:19:11 -0600 (CST) Received: from S0027509848 (pcp037323pcs.aberdn01.md.comcast.net[68.33.89.145]) by comcast.net (rwcrmhc12) with SMTP id <2005010501183801400r9t74e>; Wed, 5 Jan 2005 01:18:38 +0000 Message-Id: <3.0.6.32.20050104201827.01263dd8@mail.comcast.net> X-Sender: glennrp@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 04 Jan 2005 20:18:27 -0500 To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: [png-implement] libpng running out of memory while writing zTXt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu >From an ImageMagick forum: A) Line 541 of zlib/deflate.c is returning the error when the buffer runs out instead of allocating a bigger buffer. Instead of reading if (strm->avail_out == 0) it should read if (strm->avail_out == 0 && s->last_flush != -1) B) Change line 222 of png/pngwutil.c from if (!png_prt->zstream.avail_out && png_ptr->zstream.avail_in) to if (!png_prt->zstream.avail_out) For the discussion leading up to this see http://studio.imagemagick.org/magick/viewtopic.php?t=3403 Note that ImageMagick is writing Exif data into a large zTXt chunk when the failure occurs. We could probably gin up a simple test case that just writes a huge zTXt (over 32k compressed). Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Tue Jan 4 19:27:22 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j051RHf0021386 for ; Tue, 4 Jan 2005 19:27:17 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j051RGqh009027 for ; Tue, 4 Jan 2005 19:27:16 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4308760; Tue, 04 Jan 2005 19:26:34 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j051QYUd011116 for ; Tue, 4 Jan 2005 19:26:34 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j051QV508537; Tue, 4 Jan 2005 19:26:31 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j051QUQ08533 for ; Tue, 4 Jan 2005 19:26:30 -0600 (CST) Received: from S0027509848 (pcp037323pcs.aberdn01.md.comcast.net[68.33.89.145]) by comcast.net (rwcrmhc11) with SMTP id <2005010501261001300cprqle>; Wed, 5 Jan 2005 01:26:10 +0000 Message-Id: <3.0.6.32.20050104202601.01263dd8@mail.comcast.net> X-Sender: glennrp@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 04 Jan 2005 20:26:01 -0500 To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: RE: [png-implement] libpng running out of memory while writing zTXt In-Reply-To: <001301c4f2a4$21188570$1001a8c0@kalmiopsis> References: <20050102221935.256f347e@buddha.localdomain.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu Another report of the same problem, on the libpng bug tracker at SourceForge: [ 1021332 ] writing color profile fails (?) Submitted By: Keith Trummel - ktrummel Date Submitted: 2004-09-02 13:26 Last Updated By: glennrp - Settings changed Date Last Updated: 2004-09-12 09:25 Number of Comments: 0 Number of Attachments: 0 Data Type: (?) Category: (?) (admin) Group: (?) (admin) Assigned To: (?) (admin) Priority: (?) Status: (?) Resolution: (?) Summary: (?) There appears to be a bug in the function png_text_compress in the file pngwutil.cpp. I found this in version 1.2.5, but it appears to still be there in version 1.2.6. The problem occurs when the compression needs to loop. The problem occurs when the statement: /* check to see if we need more room */ if (!png_ptr->zstream.avail_out && png_ptr- >zstream.avail_in) is false with both avail_out and avail_in equal to 0. This then results with the following /* tell zlib we are finished */ ret = deflate(&png_ptr->zstream, Z_FINISH); failing due to avail_out set to 0. (ret ends up returning Z_BUF_ERROR). The way I trigged this problem is by trying to write a large (over 80K) color profile to a PNG file. Changing the if statement above to: /* check to see if we need more room */ if (!png_ptr->zstream.avail_out) seemed to fix the problem. Keith Trummel Sr. Software Engineer Scene7 Inc. ktrummel@scene7.com -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Wed Jan 5 11:12:42 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j05HCgf0004879 for ; Wed, 5 Jan 2005 11:12:42 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j05HCfqh025586 for ; Wed, 5 Jan 2005 11:12:41 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4343376; Wed, 05 Jan 2005 11:12:13 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j05HCCUd014897 for ; Wed, 5 Jan 2005 11:12:12 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j05HBmU11810; Wed, 5 Jan 2005 11:11:48 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j05HBmQ11806 for ; Wed, 5 Jan 2005 11:11:48 -0600 (CST) Received: from filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id D750E100B2 for ; Wed, 5 Jan 2005 17:11:47 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.131.34]) by filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) (amavisd-new, port 10024) with LMTP id 20476-07-70 for ; Wed, 5 Jan 2005 17:11:47 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id A00F8FFDA for ; Wed, 5 Jan 2005 17:11:46 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1CmEhF-3rS-00 for ; Wed, 05 Jan 2005 09:11:45 -0800 From: John Bowler To: Subject: RE: [png-implement] libpng running out of memory while writing zTXt Date: Wed, 5 Jan 2005 09:11:44 -0800 Message-ID: <000401c4f349$a2276730$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.6.32.20050104202601.01263dd8@mail.comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter01.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson >/* check to see if we need more room */ >if (!png_ptr->zstream.avail_out && png_ptr->zstream.avail_in) > >is false with both avail_out and avail_in equal to 0. This seems to have been fixed in 1.2.8 (i.e. in 1.2.7 at about line 222 the problem exists and it doesn't in 1.2.8.) John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Wed Jan 5 11:29:35 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j05HTZf0005150 for ; Wed, 5 Jan 2005 11:29:35 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j05HTYqj027499 for ; Wed, 5 Jan 2005 11:29:35 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4344180; Wed, 05 Jan 2005 11:29:18 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j05HTIUd017674 for ; Wed, 5 Jan 2005 11:29:18 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j05HSx511902; Wed, 5 Jan 2005 11:28:59 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j05HSwQ11898 for ; Wed, 5 Jan 2005 11:28:58 -0600 (CST) Received: from comcast.net (taos.arl.army.mil[128.63.26.62]) by comcast.net (sccrmhc13) with SMTP id <2005010517285801600p3c69e>; Wed, 5 Jan 2005 17:28:58 +0000 Message-ID: <41DC23D8.FE190029@comcast.net> Date: Wed, 05 Jan 2005 12:28:56 -0500 From: "Glenn Randers-Pehrson " X-Mailer: Mozilla 4.8C-SGI [en] (X11; U; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: png-implement@ccrc.wustl.edu Subject: Re: [png-implement] libpng running out of memory while writing zTXt References: <000401c4f349$a2276730$1001a8c0@kalmiopsis> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu John Bowler wrote: > > From: Glenn Randers-Pehrson > >/* check to see if we need more room */ > >if (!png_ptr->zstream.avail_out && png_ptr->zstream.avail_in) > > > >is false with both avail_out and avail_in equal to 0. > > This seems to have been fixed in 1.2.8 (i.e. in 1.2.7 at about line 222 the > problem exists and it doesn't in 1.2.8.) > > John Bowler > > -- > Send the message body "help" to png-implement-request@ccrc.wustl.edu Right, on November 1 according to CHANGES. But has the companion fix to zlib been made, or should it? Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Wed Jan 5 12:06:16 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j05I6Gf0005798 for ; Wed, 5 Jan 2005 12:06:16 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j05I6Fqh001784 for ; Wed, 5 Jan 2005 12:06:15 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4345918; Wed, 05 Jan 2005 12:05:58 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j05I5wUd023618 for ; Wed, 5 Jan 2005 12:05:58 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j05I5qw12046; Wed, 5 Jan 2005 12:05:52 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j05I5qQ12042 for ; Wed, 5 Jan 2005 12:05:52 -0600 (CST) Received: from filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 36EB3FEAC for ; Wed, 5 Jan 2005 18:05:52 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.131.34]) by filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) (amavisd-new, port 10024) with LMTP id 20533-12-52 for ; Wed, 5 Jan 2005 18:05:52 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id D5BF1FF9B for ; Wed, 5 Jan 2005 18:05:50 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1CmFXZ-3v4-00 for ; Wed, 05 Jan 2005 10:05:49 -0800 From: John Bowler To: Subject: RE: [png-implement] libpng running out of memory while writing zTXt Date: Wed, 5 Jan 2005 10:05:48 -0800 Message-ID: <000601c4f351$2ff23700$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <41DC23D8.FE190029@comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter01.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson >Right, on November 1 according to CHANGES. But has the companion fix to >zlib been made, or should it? libpng can't rely on it being made - it would take a long time to propogate a zlib change. I believe the libpng fix is sufficient alone. I looked at line 541 of deflate.c in both 1.1.4 and 1.2.1 - neither seems to correspond to the line quoted in the change. However line 541 of 1.2.1 does an ERR_RETURN if avail_out is 0. That seems to be correct - the calling requirements of deflate are that it must be possible to do something and that requires avail_out to be >0. Anyway, it seems to me that the suggested patch was to something around 1.1.4, not 1.2.1 and the line should be 547 (same in 1.1.3). I can't see why such a change would make things *safer*. At that point in deflate I believe the engine has not received Z_FINISH so some output is still required. It must be safe to return Z_OK, forcing the caller to allocate more buffer space. (I.e. it is safe because more buffer space is required.) Still, I am most certainly *not* a zlib expert... John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Fri Jan 7 12:13:24 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j07IDNf0016091 for ; Fri, 7 Jan 2005 12:13:24 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j07IDNvi011067 for ; Fri, 7 Jan 2005 12:13:23 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4453530; Fri, 07 Jan 2005 12:13:03 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j07ID2Ud013451 for ; Fri, 7 Jan 2005 12:13:02 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j07ICpW21750; Fri, 7 Jan 2005 12:12:51 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j07ICoQ21746 for ; Fri, 7 Jan 2005 12:12:50 -0600 (CST) Received: from filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 625E21028E for ; Fri, 7 Jan 2005 18:12:50 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.131.34]) by filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) (amavisd-new, port 10024) with LMTP id 02824-06-38 for ; Fri, 7 Jan 2005 18:12:50 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 1FD8F10266 for ; Fri, 7 Jan 2005 18:12:47 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1CmybO-6dM-00 for ; Fri, 07 Jan 2005 10:12:46 -0800 From: John Bowler To: Subject: [png-implement] RE: [png-list] tRNS function Date: Fri, 7 Jan 2005 10:12:44 -0800 Message-ID: <000201c4f4e4$7d4f5b10$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <7EE204A11783534DB33779904613159B023433F4@blr-ec-msg02.wipro.com> X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter01.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu Moved to png-implement from png-list. From: cibby.cherian@wipro.com >What is the exact purpose of the function >" png_set_tRNS_to_alpha(png_ptr) " . I know it creates >an alpha channel if the tRNS value is present which only >gets stripped later on in the " png_do_background " >function. Doesn't that defeat the whole purpose of creating >an alpha channel in the first place using the mentioned >function? Yes, but it makes the code a lot simpler. png_do_background does not have to handle palette images. Since, in general, palette+tRNS+background->palette is impossible this is highly desireable. So far as I can see the fact that PNG_EXPAND is used to indicate this means that png_do_background will typically not be called with a non-alpha colour type (not RGBA or GA) if tRNS is present in the image. That means that the case of a G or RGB image with a tRNS colour is not going to be handled optimally for typical application usage if the app calls any of the 'expand' functions. It would be possible to have an optimisation of the form: if (PNG_EXPAND && !(color_type & PNG_COLOR_MASK_ALPHA) && color_type != PNG_COLOR_TYPE_PALETTE && num_trans > 0 && PNG_BACKGROUND) cancel PNG_EXPAND but I don't think that happens anywhere. Still I don't think this is a big deal - RGB or G with tRNS is, I suspect, rare and I believe the application has to request *both* the expand *and* the background processing to get the non-optimal code. I would actually be tempted to remove the png_do_background cases for RGB and G and just force PNG_EXPAND in these cases! (Code size reduction.) John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Fri Jan 7 21:33:59 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j083Xsf0028486 for ; Fri, 7 Jan 2005 21:33:54 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j083XrdM028726 for ; Fri, 7 Jan 2005 21:33:53 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4474078; Fri, 07 Jan 2005 21:33:18 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j083XFUd025505 for ; Fri, 7 Jan 2005 21:33:17 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j083WnY23224; Fri, 7 Jan 2005 21:32:49 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j083WmQ23220 for ; Fri, 7 Jan 2005 21:32:48 -0600 (CST) Received: from S0027509848 (pcp037323pcs.aberdn01.md.comcast.net[68.33.89.145]) by comcast.net (sccrmhc12) with SMTP id <2005010803323301200p6n1de>; Sat, 8 Jan 2005 03:32:33 +0000 Message-Id: <3.0.6.32.20050107223243.0139eca8@mail.comcast.net> X-Sender: glennrp@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 07 Jan 2005 22:32:43 -0500 To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: [png-implement] high-level gamma transforms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu On the feature-request tracker at SourceForge it has been proposed to add high-level gamma transformations (for use with the png_read_png and png_write_png functions): PNG_TRANSFORM_SRGB Convert to sRGB colorspace PNG_TRANSFORM_LINEAR Convert to gamma==1.0 We'd need to specify the treatment of unlabelled input images; it is suggested that such input be assumed to be in sRGB. Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Fri Jan 7 22:02:18 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0842Hf0000455 for ; Fri, 7 Jan 2005 22:02:17 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0842HdM000462 for ; Fri, 7 Jan 2005 22:02:17 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4474799; Fri, 07 Jan 2005 22:01:56 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0841uUd028282 for ; Fri, 7 Jan 2005 22:01:56 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0841ow23368; Fri, 7 Jan 2005 22:01:50 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0841dQ23363 for ; Fri, 7 Jan 2005 22:01:49 -0600 (CST) Received: from S0027509848 (pcp037323pcs.aberdn01.md.comcast.net[68.33.89.145]) by comcast.net (sccrmhc12) with SMTP id <2005010804013901200ooqape>; Sat, 8 Jan 2005 04:01:39 +0000 Message-Id: <3.0.6.32.20050107230149.0139eca8@mail.comcast.net> X-Sender: glennrp@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 07 Jan 2005 23:01:49 -0500 To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: Re: [png-implement] high-level gamma transforms In-Reply-To: <3.0.6.32.20050107223243.0139eca8@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu At 10:32 PM 1/7/2005 -0500, you wrote: >On the feature-request tracker at SourceForge it has been proposed >to add high-level gamma transformations (for use with the png_read_png >and png_write_png functions): > >PNG_TRANSFORM_SRGB Convert to sRGB colorspace >PNG_TRANSFORM_LINEAR Convert to gamma==1.0 > >We'd need to specify the treatment of unlabelled input images; it is >suggested that such input be assumed to be in sRGB. Also, what to do with PNGs that contain the iCCP chunk? libpng isn't capable of transforming an ICC colorspace to another without help from LCMS or something. Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Sat Jan 8 02:23:09 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j088N9f0018264 for ; Sat, 8 Jan 2005 02:23:09 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j088N8dM015477 for ; Sat, 8 Jan 2005 02:23:08 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4481455; Sat, 08 Jan 2005 02:22:42 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j088MgUd023479 for ; Sat, 8 Jan 2005 02:22:42 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j088MSl24170; Sat, 8 Jan 2005 02:22:28 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j088MRQ24166 for ; Sat, 8 Jan 2005 02:22:27 -0600 (CST) Received: from filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id 1CAB4FEA2 for ; Sat, 8 Jan 2005 08:22:28 +0000 (UTC) Received: from relay01.roc.ny.frontiernet.net ([66.133.131.34]) by filter01.roc.ny.frontiernet.net (filter01.roc.ny.frontiernet.net [66.133.131.176]) (amavisd-new, port 10024) with LMTP id 04299-30-76 for ; Sat, 8 Jan 2005 08:22:28 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay01.roc.ny.frontiernet.net (Postfix) with ESMTP id BDF5DFEC9 for ; Sat, 8 Jan 2005 08:22:25 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1CnBrd-7To-00 for ; Sat, 08 Jan 2005 00:22:25 -0800 From: John Bowler To: Subject: RE: [png-implement] high-level gamma transforms Date: Sat, 8 Jan 2005 00:22:23 -0800 Message-ID: <000b01c4f55b$2eca5ea0$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <3.0.6.32.20050107223243.0139eca8@mail.comcast.net> X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter01.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson >On the feature-request tracker at SourceForge it has been proposed >to add high-level gamma transformations (for use with the png_read_png >and png_write_png functions): > >PNG_TRANSFORM_SRGB Convert to sRGB colorspace >PNG_TRANSFORM_LINEAR Convert to gamma==1.0 Why would these be added in this way? The function 'png_set_gamma' already exists and the transform flag PNG_GAMMA is there too, so why is it useful to add two new flags? The thing that really *is* missing here is a way to expand the image to 16 bits per sample - without this a transform of a typical gamma encoded image to linear is going to cause significant problems for low intensity parts of the image. It seems to me that 'png_set_expand16' would be a useful thing, and maybe two *APIs* to call png_set_gamma to do sRGB and linear convertion (preferably without the need to quote the actual PNG file gamma.) >We'd need to specify the treatment of unlabelled input images; it is >suggested that such input be assumed to be in sRGB. That seems fine for sRGB, since if the image is used in an sRGB environment one good guess in the absence of information to the contrary is that it is an sRGB image... For linear it's not so clear - it might be better to have the caller of a new API suggest the default as in png_set_gamma (this, of course, is ducking the question, but then it always has been ducked in the past!) >Also, what to do with PNGs that contain the iCCP chunk? libpng isn't >capable of transforming an ICC colorspace to another without help >from LCMS or something. App writers who need to do proper colour management don't call libpng convenience APIs. The thing I have done in the past is to extract an approximation to a gamma value from those ICCP profiles for which I can determine the basic encoding. log(out)/log(in) for each point on the transform is an estimate of the gamma value, an average (possibly weighted toward the high light levels)) gives a appropriate decoding gamma (1/png-gamma). Still that means writing a dumb parser for a profile, and decompressing it - probably not worth the effort in a decoder since ideally the *encoder* will supply a gAMA chunk. John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Sat Jan 8 06:28:19 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j08CSJf0003959 for ; Sat, 8 Jan 2005 06:28:19 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j08CSIdM001066 for ; Sat, 8 Jan 2005 06:28:18 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4488495; Sat, 08 Jan 2005 06:27:49 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j08CRnUd019722 for ; Sat, 8 Jan 2005 06:27:49 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j08CRY824862; Sat, 8 Jan 2005 06:27:34 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j08CRXQ24858 for ; Sat, 8 Jan 2005 06:27:33 -0600 (CST) Received: from S0027509848 (pcp037323pcs.aberdn01.md.comcast.net[68.33.89.145]) by comcast.net (rwcrmhc12) with SMTP id <2005010812273301400ghp47e>; Sat, 8 Jan 2005 12:27:33 +0000 Message-Id: <3.0.6.32.20050108072742.0125cc90@mail.comcast.net> X-Sender: glennrp@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 08 Jan 2005 07:27:42 -0500 To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: RE: [png-implement] high-level gamma transforms In-Reply-To: <000b01c4f55b$2eca5ea0$1001a8c0@kalmiopsis> References: <3.0.6.32.20050107223243.0139eca8@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu At 12:22 AM 1/8/2005 -0800, John Bowler wrote: >From: Glenn Randers-Pehrson >>On the feature-request tracker at SourceForge it has been proposed >>to add high-level gamma transformations (for use with the png_read_png >>and png_write_png functions): >> >>PNG_TRANSFORM_SRGB Convert to sRGB colorspace >>PNG_TRANSFORM_LINEAR Convert to gamma==1.0 > >Why would these be added in this way? The function 'png_set_gamma' already >exists and the transform flag PNG_GAMMA is there too, so why is it useful to >add two new flags? It's not my proposal, but just guessing--for completeness of the high- level functions. The libpng.txt seems to say that png_set_gamma appears after the PNG header has been read, i.e. partly through png_read_png(). >The thing that really *is* missing here is a way to expand the image to 16 >bits per sample - without this a transform of a typical gamma encoded image >to linear is going to cause significant problems for low intensity parts of >the image. It seems to me that 'png_set_expand16' would be a useful thing, Yes. And a PNG_TRANSFORM_16 (and _8) transform for png_read_png() and png_write_png(). >and maybe two *APIs* to call png_set_gamma to do sRGB and linear convertion >(preferably without the need to quote the actual PNG file gamma.) > >>We'd need to specify the treatment of unlabelled input images; it is >>suggested that such input be assumed to be in sRGB. > >That seems fine for sRGB, since if the image is used in an sRGB environment >one good guess in the absence of information to the contrary is that it is >an sRGB image... For linear it's not so clear - it might be better to have >the caller of a new API suggest the default as in png_set_gamma (this, of >course, is ducking the question, but then it always has been ducked in the >past!) > >>Also, what to do with PNGs that contain the iCCP chunk? libpng isn't >>capable of transforming an ICC colorspace to another without help >>from LCMS or something. > >App writers who need to do proper colour management don't call libpng >convenience APIs. but a second party might stumble over a PNG with iCCP and without a backup gAMA chunk. The API should do something reasonable even if it is to issue a warning like "sorry, application cannot process the iCCP chunk." >The thing I have done in the past is to extract an approximation to a gamma >value from those ICCP profiles for which I can determine the basic encoding. >log(out)/log(in) for each point on the transform is an estimate of the gamma >value, an average (possibly weighted toward the high light levels)) gives a >appropriate decoding gamma (1/png-gamma). Still that means writing a dumb >parser for a profile, and decompressing it - probably not worth the effort >in a decoder since ideally the *encoder* will supply a gAMA chunk. The proposal is for encoders and decoders, for example png_read_png(png_ptr,LINEAR|16_BIT,NULL); process_image(...); png_write_png(png_ptr,SRGB|8_BIT,NULL); But apps could do the equivalent with the existing library: png_read_png(png_ptr,NULL,NULL); convert to 16-bit Linear; process_image(...); convert to 8-bit sRGB; png_write_png(png_ptr,NULL,NULL); Glenn -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Sun Jan 9 12:20:47 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j09IKkHM020356 for ; Sun, 9 Jan 2005 12:20:46 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j09IKjHk016508 for ; Sun, 9 Jan 2005 12:20:46 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4531156; Sun, 09 Jan 2005 12:20:08 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j09IK7Ud003635 for ; Sun, 9 Jan 2005 12:20:08 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j09IJ5T28950; Sun, 9 Jan 2005 12:19:05 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j09IJ4Q28946 for ; Sun, 9 Jan 2005 12:19:04 -0600 (CST) Received: from filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id 38C6A104E1 for ; Sun, 9 Jan 2005 18:19:04 +0000 (UTC) Received: from relay02.roc.ny.frontiernet.net ([66.133.131.35]) by filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) (amavisd-new, port 10024) with LMTP id 10166-59-77 for ; Sun, 9 Jan 2005 18:19:04 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay02.roc.ny.frontiernet.net (Postfix) with ESMTP id C715C104E4 for ; Sun, 9 Jan 2005 18:18:59 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1CnheU-0pi-00 for ; Sun, 09 Jan 2005 10:18:58 -0800 From: John Bowler To: Subject: RE: [png-implement] high-level gamma transforms Date: Sun, 9 Jan 2005 10:18:57 -0800 Message-ID: <000001c4f677$afe2e440$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3.0.6.32.20050108072742.0125cc90@mail.comcast.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter02.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu Ok, I misunderstood - this is about the transforms parameter on png_read_png and png_write_png (APIs which, to tell the truth, I have never used...) So the documentation (libpng.txt) says that the transformations are limited, and that is, I believe, for two reasons: 1) None of the permitted transformations have parameters (png_set_gamma has two). 2) The transformations must be known before anything is known about the PNG. png_set_gamma requires the caller to have called png_read_info to find out if a gAMA or sRGB (and maybe even iCCP) chunk is present, png_read_info is called from png_read_png. The first observation is that the proposed extensions are very different from each other: >>PNG_TRANSFORM_SRGB Convert to sRGB colorspace This is a *colour space* - not just a gamma. That means the implementation would have to handle the cHRM and (ideally) the iCCP chunks as well as gAMA. There's no support for that at present and I believe that even cHRM handling requires a full CMS. I don't think this will happen... >>PNG_TRANSFORM_LINEAR Convert to gamma==1.0 This would be just gamma convertion but, to my mind, it needs a convertion to 16bits per sample at the same time - a typical PNG image cannot be represented as 8bit linear rgb. Notice that even non-extreme gamma convertion may result in a requirement for bit depth expansion - e.g. a 4bit-per-sample greyscale image typically needs to be converted to 8bits-per-sample if the gamma encoding power is moved toward linear. I suspect it's a simple mathematical formula to work out the extra precision required. Ok, these are packaged sets of transforms to make things easy for the programmer, but the aspect of them which can be implemented (gamma convertion) can simply be handled by adding: png_set_target_gamma(png_ptr, gamma) Then png_read_png and, for that matter, the lower level interfaces, can automatically do the gamma convertion *iff* a gAMA chunk is present. If the desire is to do the convertion for PNGs with no gamma information then: png_set_default_gamma(png_ptr, gamma) satisfies that requirement too. Since these new APIs would just be setting some state values there is no need to have read anything about the image before they are called - they just result in an automagic call to png_set_gamma at the end of png_read_info. Then there is the application to png_write_png. This I don't understand at all. All the relevant information (for producing gAMA, cHRM and even iCCP) should have already been filled in the png_info. The one problem here is that: png_set_cHRM(png_ptr, info_ptr, colour-space-info) seems to be missing from the documentation, however it's there in the code and png_set_sRGB_gAMA_and_cHRM *is* documented. Adding these transformations to png_write_png would, therefore, be slightly weird - it would require png_write_png to actually transform input data into the colour space set into the png_info when it could simply write the original data with the correct gAMA/cHRM/sRGB! This would cause enormous problems, because it's a *transform* but it seems to be setting the output format, I'm sure some app programmers would simply set the tranform flag and none of the png_info data. This would apparently result in a valid image with no gAMA/cHRM/sRGB (because none was set into the info structure.) On the other hand the same solution exists for png_write_png - recognise: png_set_target_gamma (i.e. 'png_set_source_data_gamma') png_set_default_gamma (== png_set_gAMA in this context) and do the obvious defaulting. If png_set_default_gamma was not called use the gamma from png_set_target_gamma. Call png_set_gAMA with the result if it has not been called already. Do a transformation only if both were called and the gammas are different - this makes the expensive-to-implement case the one which requires most work by the app programmer! It should be clear to all programmers who make both calls that they are asking for a significant transformation to happen. So I'm proposing, instead, that both the default PNG file gamma and the gamma of the RGB (or gray) data the app programmer uses be stored, if the app writer desires, in the png_ptr. If these values are stored then do the correct thing on read and write. As an additional proposal add transform flags to allow expansion to 16 bits and integrate this with the gamma transformation (this, unfortunately, seems like a significant amount of work.) John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Mon Jan 10 22:26:11 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0B4Q9HM025890 for ; Mon, 10 Jan 2005 22:26:09 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0B4Q8wd019791 for ; Mon, 10 Jan 2005 22:26:08 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4598158; Mon, 10 Jan 2005 22:25:50 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0B4PnUd006293 for ; Mon, 10 Jan 2005 22:25:50 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0B4O6R04117; Mon, 10 Jan 2005 22:24:06 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from wip-ectls-mx1.wipro.com (wip-ectls-mx1.wipro.com [203.101.113.37]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0B4O5Q04113 for ; Mon, 10 Jan 2005 22:24:05 -0600 (CST) Received: from wip-ectls-mx1.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 70259220038 for ; Tue, 11 Jan 2005 09:54:18 +0530 (IST) Received: from blr-ec-bh1.wipro.com (blr-ec-bh1.wipro.com [10.200.50.91]) by wip-ectls-mx1.wipro.com (Postfix) with ESMTP id 638C4220007 for ; Tue, 11 Jan 2005 09:54:18 +0530 (IST) Received: from blr-ec-msg02.wipro.com ([10.200.51.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jan 2005 09:54:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [png-implement] RE: [png-list] tRNS function Date: Tue, 11 Jan 2005 09:53:53 +0530 Message-ID: <7EE204A11783534DB33779904613159B023B8945@blr-ec-msg02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [png-implement] RE: [png-list] tRNS function Thread-Index: AcT05uwcaO6NALVdQe2TEdYLaaMPhQCrazhQ From: To: X-OriginalArrivalTime: 11 Jan 2005 04:24:28.0361 (UTC) FILETIME=[708BBB90:01C4F795] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ccrc.wustl.edu id j0B4O6Q04114 Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu Hi, The Issue has become even more complicated now. The png_set_tRNS_to_alpha(png_ptr) creates an alpha channel if the trns walue is provided. This function is also a part of ( one of the three functions) the the PNG_EXPAND function. The question I am asking is why have this feature of creating an alpha channel in the first place becoz it gets stripped in the png_do_background function anyways. Also if the alpha channel is not created then the png_do_background function will check each pixel values and replace them with background color if required. So why have a png_set_tRNS_to_alpha(png_ptr)? Cibby. -----Original Message----- From: owner-png-implement@ccrc.wustl.edu [mailto:owner-png-implement@ccrc.wustl.edu] On Behalf Of John Bowler Sent: Friday, January 07, 2005 11:43 PM To: png-implement@ccrc.wustl.edu Subject: [png-implement] RE: [png-list] tRNS function Moved to png-implement from png-list. From: cibby.cherian@wipro.com >What is the exact purpose of the function >" png_set_tRNS_to_alpha(png_ptr) " . I know it creates >an alpha channel if the tRNS value is present which only >gets stripped later on in the " png_do_background " >function. Doesn't that defeat the whole purpose of creating >an alpha channel in the first place using the mentioned >function? Yes, but it makes the code a lot simpler. png_do_background does not have to handle palette images. Since, in general, palette+tRNS+background->palette is impossible this is highly desireable. So far as I can see the fact that PNG_EXPAND is used to indicate this means that png_do_background will typically not be called with a non-alpha colour type (not RGBA or GA) if tRNS is present in the image. That means that the case of a G or RGB image with a tRNS colour is not going to be handled optimally for typical application usage if the app calls any of the 'expand' functions. It would be possible to have an optimisation of the form: if (PNG_EXPAND && !(color_type & PNG_COLOR_MASK_ALPHA) && color_type != PNG_COLOR_TYPE_PALETTE && num_trans > 0 && PNG_BACKGROUND) cancel PNG_EXPAND but I don't think that happens anywhere. Still I don't think this is a big deal - RGB or G with tRNS is, I suspect, rare and I believe the application has to request *both* the expand *and* the background processing to get the non-optimal code. I would actually be tempted to remove the png_do_background cases for RGB and G and just force PNG_EXPAND in these cases! (Code size reduction.) John Bowler -- Send the message body "help" to png-implement-request@ccrc.wustl.edu Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Tue Jan 11 14:04:59 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0BK4wHM013820 for ; Tue, 11 Jan 2005 14:04:58 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0BK4vwd010164 for ; Tue, 11 Jan 2005 14:04:58 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4635322; Tue, 11 Jan 2005 14:04:16 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0BK4GUd026344 for ; Tue, 11 Jan 2005 14:04:16 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0BK3S007327; Tue, 11 Jan 2005 14:03:28 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.131.37]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0BK3RQ07323 for ; Tue, 11 Jan 2005 14:03:28 -0600 (CST) Received: from filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) by relay04.roc.ny.frontiernet.net (Postfix) with ESMTP id 163B610585 for ; Tue, 11 Jan 2005 19:58:36 +0000 (UTC) Received: from relay04.roc.ny.frontiernet.net ([66.133.131.37]) by filter02.roc.ny.frontiernet.net (filter02.roc.ny.frontiernet.net [66.133.131.177]) (amavisd-new, port 10024) with LMTP id 21242-30-12 for ; Tue, 11 Jan 2005 19:58:35 +0000 (UTC) Received: from cioch.kalmiopsis (67-136-241-233.bras01.myc.or.frontiernet.net [67.136.241.233]) by relay04.roc.ny.frontiernet.net (Postfix) with ESMTP id 90FF210580 for ; Tue, 11 Jan 2005 19:58:33 +0000 (UTC) Received: from 192.168.1.16 (ident=unknown) by cioch.kalmiopsis with smtp (masqmail 0.2.18) id 1CoS9x-3YQ-00 for ; Tue, 11 Jan 2005 11:58:33 -0800 From: John Bowler To: Subject: RE: [png-implement] RE: [png-list] tRNS function Date: Tue, 11 Jan 2005 11:58:31 -0800 Message-ID: <000301c4f817$edcd2f80$1001a8c0@kalmiopsis> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C4F7D4.DFA9EF80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-MS-TNEF-Correlator: 0000000040FF0AD60B5A0B4FA38FD22056AD4647A4F5F301 In-Reply-To: <7EE204A11783534DB33779904613159B023B8945@blr-ec-msg02.wipro.com> Importance: Normal X-Virus-Scanned: by amavisd-new-20040701 (2.0) at filter02.roc.ny.frontiernet.net Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C4F7D4.DFA9EF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: cibby.cherian@wipro.com >So why have a png_set_tRNS_to_alpha(png_ptr)? ? Because some of the callers of the library *do* handle alpha and it makes that code (the calling code) simpler in many cases to reduce the palette case to RGBA (even with an completely opaque A channel if there is no tRNS!) If you call both png_set_tRNS_to_alpha *and* png_set_background it will do unnecessary work, but so far as I can see png_set_background alone special cases all the palette image cases correctly. I may be wrong, there may be a bug or this may be impossible for some reason. John Bowler ------=_NextPart_000_0004_01C4F7D4.DFA9EF80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IiETAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANUHAQALAAsAOgAAAAIALwEB A5AGAPwGAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAtAAAAW3BuZy1pbXBsZW1lbnRdIFJFOiBbcG5nLWxpc3RdIHRSTlMgZnVuY3Rp b24AAAAAAgFxAAEAAAAWAAAAAcT4F+zq6UINbclNSdCzDbJvgFxr0wAAAgEdDAEAAAAVAAAAU01U UDpKQk9XTEVSQEFDTS5PUkcAAAAACwABDgAAAABAAAYOAJQV2hf4xAECAQoOAQAAABgAAAAAAAAA QP8K1gtaC0+jj9IgVq1GR8KAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAAB8AgAAeAIAAIwDAABM WkZ1gx3buwMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5R AwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQ C6YgRgEDYTogY2liYnmuLhPQBnEAcEAD8HADYA8doANwCqIKgD5TbyAQd2h5IBPgdmUgQGEgcG5n XxQRX5B0Uk5TIIBvXwdAGnAT4CggEgUwcik/Qx7EHsQ/ICBCBZBhMnUUECBzA3Af0G9m3CB0HcAd QAdAbASQBCA1I8VsHWByCsAfgCpk5G8qH5FuZCRgH+AhIrMf4CYQIGkFQADAaweRnSPwYQVABaAB ACAoI/b1C4BnJ9MpI2AHcAtQEoH7C4AnIW4fgCMQFBAncR9A/xghGtAf0CPyCrAkYAJAJBJDI0Eq wVJHQkEoIGX/H8ADoAPwI/AmsSfRKYIOsOpsH4BvCrBxClAQwB1A/SXxbi5AJvAj0xggJvAEIKZu H0AgkiEpIgpJI9D2eQhgJCMgBuAtcSAfJnOuKiYBJdAytmIA0GsJwN8IYCbUA/AyMSWwIDVgL1CX KzAEECVidwWwaywyUGZ1BUAjcCBmCsEqcCD+SSQhA6AUECuBNI8mUQIg/SNRcAWQBzEqVTIiK2oH cDxhZywEBCAFoRggY3S9LlAuItA4UADAH4BiH9D+dwNgMsA3UC/EPgUf8DdwvyjgBbEj8DAhPgUp cW8EEP8dYCYxAhAFwCNzGCAqcAIgIi4iCkpvaAOgQm+ydymiPGoG4EPiQADQpG0uBbBnPh7EfUWw HgBCEAEAAABCAAAAPDdFRTIwNEExMTc4MzUzNERCMzM3Nzk5MDQ2MTMxNTlCMDIzQjg5NDVAYmxy LWVjLW1zZzAyLndpcHJvLmNvbT4AAAADAAlZAQAAAAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOF AAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAA RgAAAABShQAAJ2oBAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAAeAAqA CCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgALgAggBgAAAAAAwAAAAAAAAEYA AAAAN4UAAAEAAAABAAAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAA AAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABGAAAA ABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADAAAAA AAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQ AAAAQP8K1gtaC0+jj9IgVq1GRwIB+g8BAAAAEAAAAED/CtYLWgtPo4/SIFatRkcCAfsPAQAAAFIA AAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6 XE1vbmV5XE91dGxvb2tcb3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAA MDAwMDAwMDA0MEZGMEFENjBCNUEwQjRGQTM4RkQyMjA1NkFENDY0N0E0RjVGMzAxAAAAAAMABhDy PYEbAwAHEOYBAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAARlJPTTpDSUJCWUNIRVJJQU5A V0lQUk9DT01TT1dIWUhBVkVBUE5HU0VUVFJOU1RPQUxQSEEoUE5HUFRSKT8/QkVDQVVTRVNPTUVP RlRIRUNBTExFUlNPRlRIRUxJQlJBUlkqRAAAAAARgg== ------=_NextPart_000_0004_01C4F7D4.DFA9EF80-- -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Wed Jan 12 04:43:16 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0CAhGHM027447 for ; Wed, 12 Jan 2005 04:43:16 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0CAhF0m018503 for ; Wed, 12 Jan 2005 04:43:15 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4665620; Wed, 12 Jan 2005 04:42:45 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0CAgjUd014141 for ; Wed, 12 Jan 2005 04:42:45 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0CAgM610073; Wed, 12 Jan 2005 04:42:22 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0CAgLQ10069 for ; Wed, 12 Jan 2005 04:42:21 -0600 (CST) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CofxE-0004xp-00 for png-implement@ccrc.wustl.edu; Wed, 12 Jan 2005 11:42:20 +0100 Received: from [217.233.119.215] (helo=buddha.localdomain.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CofxD-0002pw-00 for png-implement@ccrc.wustl.edu; Wed, 12 Jan 2005 11:42:19 +0100 Date: Wed, 12 Jan 2005 11:42:23 +0100 From: Ed Vazquez To: png-implement@ccrc.wustl.edu Subject: [png-implement] Change to libpng since 1.2.5? png_create_read_struct no longer available? Message-ID: <20050112114223.2d8e0ece@buddha.localdomain.de> X-Mailer: Sylpheed-Claws 0.9.13 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:3b2c3f724793a92e62915a6cfe16adb5 Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu [ non-member submission, don't forget to CC To: changed from png-list to png-implement - Moderator ] I'm probably barking up the wrong tree, but here goes. On OpenBSD, 3.4-3.6 the latest/greatest version of LIBPNG available is 1.2.5p5. I was wanting to update to patch some of the vulnerabilities, but all versions I can download up to 1.2.8 (config and non-config versions) throw errors on configuring any libpng linked software (e.g.: PHP4, PHP5, GD, JPGraph, etc.). The error is regarding: png_create_read_struct. Which it seems no matter how libpng is compiled (with the platform specific makefile, the generic makefile, using the linux makefile and OpenBSD's RedHat compatibility platform) the library function cannot be called. And yet, all of the applications I listed above rely on that function. Any ideas? Is this just a platform/OS specific error? Has the function been deprecated and I just need to wait for all the depending software to catch up? Help? -- Ed Vazquez Our programs never have bugs, they just develop random features. -- Send the message body "help" to png-implement-request@ccrc.wustl.edu From owner-png-implement@ccrc.wustl.edu Wed Jan 12 06:35:40 2005 Received: from viruswall2.ccf.swri.edu (viruswall2.ccf.swri.edu [129.162.252.35]) by swrinde.nde.swri.edu (8.12.10/8.12.10) with ESMTP id j0CCZdHM002574 for ; Wed, 12 Jan 2005 06:35:39 -0600 (CST) Received: from ccf.swri.edu (localhost [127.0.0.1]) by viruswall2.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0CCZd0m026369 for ; Wed, 12 Jan 2005 06:35:39 -0600 (CST) Received: from ([129.162.1.33]) by ironmail.ccf.swri.edu with ESMTP id KP-GLL73.4669031; Wed, 12 Jan 2005 06:34:54 -0600 Received: from ccrc.wustl.edu (dns.ccrc.wustl.edu [128.252.169.100]) by mailhub.ccf.swri.edu (8.12.10/8.12.6) with ESMTP id j0CCYrUd021733 for ; Wed, 12 Jan 2005 06:34:53 -0600 (CST) Received: (from majordom@localhost) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) id j0CCYhn10340; Wed, 12 Jan 2005 06:34:43 -0600 (CST) X-Authentication-Warning: ccrc.wustl.edu: majordom set sender to owner-png-implement@ccrc.wustl.edu using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by ccrc.wustl.edu (8.11.6+Sun/8.11.6) with ESMTP id j0CCYbQ10336 for ; Wed, 12 Jan 2005 06:34:37 -0600 (CST) Received: from S0027509848 (pcp037323pcs.aberdn01.md.comcast.net[68.33.89.145]) by comcast.net (rwcrmhc11) with SMTP id <2005011212343701300su4bme>; Wed, 12 Jan 2005 12:34:37 +0000 Message-Id: <3.0.6.32.20050112073438.01274908@mail.comcast.net> X-Sender: glennrp@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 12 Jan 2005 07:34:38 -0500 To: png-implement@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: Re: [png-implement] Change to libpng since 1.2.5? png_create_read_struct no longer available? Cc: ed.vazquez@dhha.org In-Reply-To: <20050112114223.2d8e0ece@buddha.localdomain.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-png-implement@ccrc.wustl.edu Precedence: bulk Reply-To: png-implement@ccrc.wustl.edu At 11:42 AM 1/12/2005 +0100, Ed Vazquez wrote: >[ non-member submission, don't forget to CC > To: changed from png-list to png-implement > - Moderator ] > > > >I'm probably barking up the wrong tree, but here goes. > >On OpenBSD, 3.4-3.6 the latest/greatest version of LIBPNG >available is 1.2.5p5. > >I was wanting to update to patch some of the vulnerabilities, >but all versions I can download up to 1.2.8 (config and >non-config versions) throw errors on configuring any libpng >linked software (e.g.: PHP4, PHP5, GD, JPGraph, etc.). > >The error is regarding: png_create_read_struct. > >Which it seems no matter how libpng is compiled (with the >platform specific makefile, the generic makefile, using the >linux makefile and OpenBSD's RedHat compatibility platform) the >library function cannot be called. You may have an old png.h file on your system that is interfering. Glenn > >And yet, all of the applications I listed above rely on that >function. > >Any ideas? Is this just a platform/OS specific error? Has the >function been deprecated and I just need to wait for all the >depending software to catch up? > >Help? > >-- >Ed Vazquez > >Our programs never have bugs, they just develop random features. > > >-- >Send the message body "help" to png-implement-request@ccrc.wustl.edu > -- Send the message body "help" to png-implement-request@ccrc.wustl.edu