|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
relative ordering of iCCP, gAMA and cHRM chunks-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Hi. The PNG specification does not mandate any relative ordering for the iCCP gAMA and cHRM chunks. It only says: """A PNG encoder that writes the iCCP chunk is encouraged to also write gAMA and cHRM chunks that approximate the ICC profile, to provide compatibility with applications that do not use the iCCP chunk""" I think that the spec should require that iCCP shall follow the gAMA and cHRM, if these chunks are present. Rationale: I'm the author of a Python package that converts PNG and JPEG images to PDF: http://hg.mperillo.ath.cx/pdfimg In previous versions I read the entire iCCP chunk in memory, but now I'm going to change this by reading the iCCP profile lazily, since it can be big. When creating the PDF color space object for ICC profile, PDF spec requires an "alternate color" space to use, in case the PDF viewer does not support ICC. The problem, now, is that I need to know if there is a cHRM chunk to properly set the alternate color space. This is not a problem in current version, since all chunks data up to the first IDAT are in memory. NOTE: with current PNG spec I can still implement the code as I want, since I can use a PDF object reference. Thanks Manlio Perillo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqwy+8ACgkQscQJ24LbaURzAACcDBOfEE/+VBpzlcGuR0Y06sPt SmcAn0am/sjcmw6AoueOpdjTp/koPJXg =XfYD -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: relative ordering of iCCP, gAMA and cHRM chunksOn Wed, Sep 16, 2009 at 7:28 AM, Manlio Perillo
<manlio.perillo@...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi. > > The PNG specification does not mandate any relative ordering for the > iCCP gAMA and cHRM chunks. > > It only says: > """A PNG encoder that writes the iCCP chunk is encouraged to also write > gAMA and cHRM chunks that approximate the ICC profile, to provide > compatibility with applications that do not use the iCCP chunk""" > > > I think that the spec should require that iCCP shall follow the gAMA and > cHRM, if these chunks are present. The PNG specification does not allow such a rule to be applied. The chunk copying mechanism depends on the existing rules. Couldn't your application scan the file for chunks before processing them? See pngcrush.c for an example of that. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: relative ordering of iCCP, gAMA and cHRM chunks-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Glenn Randers-Pehrson ha scritto: > On Wed, Sep 16, 2009 at 7:28 AM, Manlio Perillo > <manlio.perillo@...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi. >> >> The PNG specification does not mandate any relative ordering for the >> iCCP gAMA and cHRM chunks. >> >> It only says: >> """A PNG encoder that writes the iCCP chunk is encouraged to also write >> gAMA and cHRM chunks that approximate the ICC profile, to provide >> compatibility with applications that do not use the iCCP chunk""" >> >> >> I think that the spec should require that iCCP shall follow the gAMA and >> cHRM, if these chunks are present. > > The PNG specification does not allow such a rule to be applied. > The chunk copying mechanism depends on the existing rules. > Ok, thanks. > Couldn't your application scan the file for chunks before processing > them? See pngcrush.c for an example of that. > No, I can not scan ahead the chunks, since it may result in big memory usage. However, as I have written, an efficient solution is still possible with PDF so its not really a problem, just a matter of curiosity. Regards Manlio Perillo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqyXyEACgkQscQJ24LbaUTCgwCcCYLGUDTdjgIDhYW9JgXZVmb2 znkAnjapZUAFEKoRMaQy93e/TBuh7f5Y =4rqM -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: relative ordering of iCCP, gAMA and cHRM chunksOn Thu, Sep 17, 2009 at 12:09 PM, Manlio Perillo
<manlio.perillo@...> wrote: > >> Couldn't your application scan the file for chunks before processing >> them? See pngcrush.c for an example of that. >> > > No, I can not scan ahead the chunks, since it may result in big memory > usage. I meant simply scanning the file without storing anything, then "rewind" and read it again, storing the iCCP data only if necessary. Another possiblity is to store the iCCP chunk as an "unknown" chunk and only decode it later if you decide you need it. That would of course require memory to store the raw chunk though. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
| Free embeddable forum powered by Nabble | Forum Help |