PNG and XMP already a way to consider storing metadata?
|
View:
New views
16 Messages
—
Rating Filter:
Alert me
|
 |
PNG and XMP already a way to consider storing metadata?
by Stefan Weisse
::
Rate this Message:
Hello,
I cite out of my older mail (April 28, 2009) that I sent to this list. > Currently I am creating API for physicists and engineers on top of > libpng to read/write more than just a plain PNG file. To put a long > story short: It would be helpful for the physicist to easily be able to > find out more on extra contents of the PNG file. Some already defined > text chunks like "Description" I favour to use. Built-in operating > system support to show such extra description (like list text chunks) is > necessary in order for it to work. Thanks to all who've answered. In principle I would have loved to write back and discuss more, but usually I have much more things on my list to do than I can do so I did not do it. In principle I am ready with my on-top-API specification and reference implementation for C++ (using libpng) and Java. Metadata is saved as proprietary, but documented optional text chunks. This is not how I would like to do it, but this was the only way that I could think of at that time. As weeks go by I slipped across XMP (Extensible Metadata Platform) [1], in short words a method of storing metadata in image files, used in imaging business, photography, ... more and more. Also when working with semi- or professional digital cameras, XMP is a way that might in future will be used more and more for storing metadata. The question I cannot answer myself whether it is already time to jump on that train. Do you have any insight whether there is already some specification on how to 'wed' (like wedding) XMP and PNG? Can XMP considered now as a method to store metadata or should one wait few years? I'd be really interested in your opinion and also in experiences you might have regarding XMP and image formats. My vision would be to use XMP in a way that metadata (text, numbers, binary) can be properly seen in image editing applications while also being possible to nicely read and write the sets by my on-top-API, keeping valuable metadata glued together with image bits. regards, Stefan [1] http://en.wikipedia.org/wiki/Extensible_Metadata_Platform ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Cosmin Truta
::
Rate this Message:
On Thu, Oct 8, 2009 at 8:00 AM, Stefan Weisse wrote:
> Do you have any insight whether there is already some specification on > how to 'wed' (like wedding) XMP and PNG? Can XMP considered now as a > method to store metadata or should one wait few years? Stefan, I'm happy to tell you that there is a standard way to embed XMP inside PNG, mentioned in the XMP specification, and used by big vendors (Adobe) as well as open-source developers (exiftool and others). That is done via the iTXT chunk, with the text keyword "XML:com.adobe.xmp". www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf I personally have no hands-on experience with it, but I was planning to enhance OptiPNG with XMP import (e.g. during TIFF-to-PNG conversion). In my opinion, XMP is one of the most viable method to store metadata, because it is gaining more and more popularity, and is interchangeable across different image formats. The regular PNG text chunks, on the other hand, are restricted to PNG/JNG/MNG only, and I haven't seen any big-shot software programs taking full advantage of their design, or using them in any sophisticated way. Heck, I didn't even see much support for PNG text keywords as elementary as "Title", "Author" or "Copyright". > My vision would be to use XMP in a way that metadata (text, numbers, > binary) can be properly seen in image editing applications while also > being possible to nicely read and write the sets by my on-top-API, > keeping valuable metadata glued together with image bits. I warmly encourage you to pursue your vision :-) If you need to see examples, it's easy: just take any image that you know it has metadata, and export it to PNG from either Adobe Photoshop or Adobe Lightroom. Other Adobe products, as well as other XMP-supporting tools like ACDSee, should probably do this as well, although I haven't tried them. Or if you want to stick with free command line tools, I can recommend you my favorite: exiftool. Best regards, Cosmin ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 8, 2009 at 8:00 AM, Stefan Weisse <stefan.weisse@...> wrote:
> As weeks go by I slipped across XMP (Extensible Metadata Platform) [1], > in short words a method of storing metadata in image files, used in > imaging business, photography, ... more and more. Also when working with > semi- or professional digital cameras, XMP is a way that might in future > will be used more and more for storing metadata. The question I cannot > answer myself whether it is already time to jump on that train. > > Do you have any insight whether there is already some specification on > how to 'wed' (like wedding) XMP and PNG? Can XMP considered now as a > method to store metadata or should one wait few years? I have not looked at the XMP spec so I cannot answer in detail. However, if an XMP datastream consists only of printable text, then it could be contained in a PNG text chunk with an "XMP" keyword or similar. e.g., zTXt XMP 0 data If it contains binary data then a new chunk could be designed such as xmPd keyword null_terminator compression_flag data Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
|
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Cosmin Truta
::
Rate this Message:
On Thu, Oct 8, 2009 at 10:57 AM, glennrp wrote:
> > ----- Original Message ----- > From: "Cosmin Truta" <cosmin@...> > > > I'm happy to tell you that there is a standard way to embed XMP inside > PNG, mentioned in the XMP specification, and used by big vendors > (Adobe) as well as open-source developers (exiftool and others). That > is done via the iTXT chunk, with the text keyword "XML:com.adobe.xmp". > > www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf > > It appears to me that it would be appropriate for us > to register that keyword. It was put into practice > five years ago according to the XMP spec, and as > Cosmin says, it's in use by multiple vendors and apps. I fully agree. This could be the death blow to our simple but unpopular text keyword system, and yet I still see it as a sound way of moving forward. Big players have identified areas of common interests concerning metadata, and the difference between them and us is that they have real experience, and they put that metadata to real use. http://www.metadataworkinggroup.com/ http://www.metadataworkinggroup.com/pdf/mwg_guidance.pdf Just to be clear on how XMP is embedded in PNG: The chunk must be iTXt, and the keyword must be "XML:com.adobe.xmp". iTXt (uncompressed) is required because XMP must be UTF8-encoded XML. (XMP can also be UTF-16 and UTF-32, but PNG only allows UTF-8, which is sufficient.) A typical PNG-only application should not normally care if it's tEXt, zTXt or iTXt, compressed or uncompressed. However, XMP is meant to be format-agnostic, so that you can easily transfer it across image formats without doing any heavy lifting. Best regards, Cosmin ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 8, 2009 at 12:43 PM, Cosmin Truta <cosmin@...> wrote:
> The chunk must be iTXt, and the keyword must be "XML:com.adobe.xmp". > iTXt (uncompressed) is required because XMP must be UTF8-encoded XML. > (XMP can also be UTF-16 and UTF-32, but PNG only allows UTF-8, which > is sufficient.) A typical PNG-only application should not normally > care if it's tEXt, zTXt or iTXt, compressed or uncompressed. However, > XMP is meant to be format-agnostic, so that you can easily transfer it > across image formats without doing any heavy lifting. I understand why it has to be iTXt and not tEXt or zTXt, but why must it be uncompressed? That seems to be an unreasonable and inconsistent requirement. Even if an application with knowledge of the particular keyword's non-compression rule writes the chunk properly, nothing prevents an editor that is unaware of the rule from rewriting it compressed, and we can't impose such a rule now. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>I understand why it has to be iTXt and not tEXt or zTXt, but why must it be >uncompressed? Doesn't 1.4.0 automagically decompress the chunk if it is compressed? Png_text_struct seems to always have uncompressed data - png_handle_iTXt always decompresses it if it is compressed. So far as I can see an app would have to do extra work to *disallow* compression, so it probably won't do it. Similarly the XMP spec doesn't say what to do with multiple chunks, so the behavior will be application defined - almost certainly the apps will read just one (probably the first). >That seems to be an unreasonable and inconsistent >requirement. Right, and it will get ignored. I bet it's there because it was easy for Adobe to add iTXt handling outside libpng (it can be done just by scanning the file) but they couldn't be bothered with adding the decompression support. Well, so what; as Glenn says: > We can't impose such a rule now. But we can register the keyword, without commenting on the unimplementable rules. John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
|
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Kopp, Thomas
::
Rate this Message:
For me it seems natural and consistent that any structure being embedded in a dedicated document type needs to respect the syntax and rules of the format it is embedded in. Otherwise the embedding document type would have to be adapted for each individual client it is embedding.
As a consequence, when embedding something into a document type, a kind of filter accompanying that something would have to be supplied for packing and unpacking it with respect to its container format. In particular, I fully agree with Glenn that a hosted client like XMP cannot impose its own rules to the container, i.e. PNG. The other way around would be the only reasonable approach. Regards, Thomas. -----Ursprüngliche Nachricht----- Von: glennrp@... [mailto:glennrp@...] Gesendet: Donnerstag, 8. Oktober 2009 21:35 An: PNG/MNG discussion list Betreff: Re: [png-mng-misc] PNG and XMP already a way to consider storing metadata? ----- Original Message ----- From: "Glenn Randers-Pehrson" <glennrp@...> To: "PNG/MNG discussion list" <png-mng-misc@...> I understand why it has to be iTXt and not tEXt or zTXt, but why must it be uncompressed? That seems to be an unreasonable and inconsistent requirement. Even if an application with knowledge of the particular keyword's non-compression rule writes the chunk properly, nothing prevents an editor that is unaware of the rule from rewriting it compressed, and we can't impose such a rule now. OK, reading the Adobe spec I see why. They want to be able to scan the file with a simple editor and extract or edit the XMP stuff and write it back in place. There is even a recommendation for a page or two of blank lines so an editor has a place to put new stuff without changing the length. I suppose they don't worry much about ruining the CRC. Who checks those anyhow? Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 8, 2009 at 3:32 PM, John Bowler <jbowler@...> wrote:
> From: Glenn Randers-Pehrson [mailto:glennrp@...] >>I understand why it has to be iTXt and not tEXt or zTXt, but why must it be >>uncompressed? > > Doesn't 1.4.0 automagically decompress the chunk if it is compressed? > Png_text_struct seems to always have uncompressed data - png_handle_iTXt > always decompresses it if it is compressed. So far as I can see an app > would have to do extra work to *disallow* compression, so it probably won't > do it. 1.4.0 handles them fine. But what Adobe desires is to be able to dump the file into a stupid text editor and read or manipulate the XMS data. Glenn > Similarly the XMP spec doesn't say what to do with multiple chunks, so the > behavior will be application defined - almost certainly the apps will read > just one (probably the first). Right. But we could define the behaviour (note that the first XMP chunk might not be the first one after editing with a PNG-compliant editor, though). > >>That seems to be an unreasonable and inconsistent >>requirement. > > Right, and it will get ignored. I bet it's there because it was easy for > Adobe to add iTXt handling outside libpng (it can be done just by scanning > the file) but they couldn't be bothered with adding the decompression > support. > > Well, so what; as Glenn says: > >> We can't impose such a rule now. > > But we can register the keyword, without commenting on the unimplementable > rules. I was thinking more of commenting on the fact that the chunk might be compressed, so a third-party application might be required to expand it before it becomes readable with a text editor, and that a third-party application would also be required, obviously, to repair the CRC. I am willing to write a png_xms application that expands, extracts, pads, or inserts an xms:adobe iTXt chunk and allows the user to deal with multiple such chunks. I'm sure that others here could do it too in a day's work. I might need a little help GUI'ing it though, but I know that there exists one for pngcrush that could be trivially modified to work with png_xms. Bear in mind that a file with an uncompressed iTXt is still a PNG. A file with a botched CRC is not. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>I am willing to write a png_xms application that expands, extracts, >pads, or inserts an xms:adobe iTXt chunk and allows the user to deal >with multiple such chunks. I'm sure that others here could do it too in >a day's work. I might need a little help GUI'ing it though, but I know >that there exists one for pngcrush that could be trivially modified to >work with png_xms. TweakPNG can already do this on Windows - it can read/write arbitrary iTXt chunks. I've attached a PNG with what I believe to be otherwise valid, but compressed, XMP data (copied from the spec.) Of course hand editing any XML, including XMP, without validating the result against all the schemas is likely to result in errors, and the attached file may well contain such errors! John Bowler <jbowler@...> ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 8, 2009 at 6:41 PM, John Bowler <jbowler@...> wrote:
> TweakPNG can already do this on Windows - it can read/write arbitrary iTXt > chunks. I've attached a PNG with what I believe to be otherwise valid, but > compressed, XMP data (copied from the spec.) Well, yeah. So can pngcrush, if it's built with libpng-1.4.0betaNN: Begin interlace pass 0 Reading and writing end_info data Handling 1 tEXt/zTXt chunks 0 XML:com.adobe.xmp (: ): <x:xmpmeta xmlns:x='adobe:ns:meta/'> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:format>application/pdf</dc:format> </rdf:Description> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/"> <xmp:CreateDate>2002-08-15T17:10:04Z</xmp:CreateDate> </rdf:Description> </rdf:RDF> </x:xmpmeta> Destroying data structs But that's way too much to ask (getting the commandline prompt and typing (pngcrush -v Comp*.png comp_pc.png") from a user who wants to hit "open with <something>" and see that listing, without having to figure out any pngcrush or tweakpng options. Also it seems I've got to fix the "pngcrush -n -v" because it doesn't display the iTXt contents. You only see them if you actually write a crushed output (which is what pngcrush is actually for)! Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Glenn Randers-Pehrson
::
Rate this Message:
On Thu, Oct 8, 2009 at 10:30 PM, Glenn Randers-Pehrson
<glennrp@...> wrote: > Also it seems I've got to fix the "pngcrush -n -v" because it doesn't > display the iTXt contents. You only see them if you actually write > a crushed output (which is what pngcrush is actually for)! This is fixed in pngcrush-1.7.3. I'm not sure what would happen if the XMP data contained non-Latin1 characters. Glenn ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Cosmin Truta
::
Rate this Message:
On Thu, Oct 8, 2009 at 2:44 PM, Glenn Randers-Pehrson <glennrp@...> wrote:
> On Thu, Oct 8, 2009 at 12:43 PM, Cosmin Truta <cosmin@...> wrote: > >> The chunk must be iTXt, and the keyword must be "XML:com.adobe.xmp". >> iTXt (uncompressed) is required because XMP must be UTF8-encoded XML. >> (XMP can also be UTF-16 and UTF-32, but PNG only allows UTF-8, which >> is sufficient.) A typical PNG-only application should not normally >> care if it's tEXt, zTXt or iTXt, compressed or uncompressed. However, >> XMP is meant to be format-agnostic, so that you can easily transfer it >> across image formats without doing any heavy lifting. > > I understand why it has to be iTXt and not tEXt or zTXt, but why must it be > uncompressed? That seems to be an unreasonable and inconsistent > requirement. Even if an application with knowledge of the particular > keyword's non-compression rule writes the chunk properly, nothing prevents > an editor that is unaware of the rule from rewriting it compressed, and > we can't impose such a rule now. I agree we cannot impose it, but we can still encourage applications to use it uncompressed, for maximum interoperability. If it makes sense to require iTXt instead of tEXt, to impose UTF-8 encoding over ISO8859-1 encoding (even when ISO8859 *can* do the job), well, it also makes sense to impose uncompressed iTXt over compressed iTXt, don't you think? On one hand you have the task of converting plain ISO8859-1 to plain UTF-8, on the other hand you have the task of converting a deflate-compressed UTF-8 to plain UTF-8. Either job require intimate knowledge of the container format (PNG, in this case), although this was not the intention of XMP. In my opinion, ISO8859 to plain UTF-8 is much easier than deflated UTF-8 to plain UTF-8. Ergo, if you insist on allowing compressed iTXt, why not insist on allowing tEXt, given that conversion to the desired plain UTF-8 is even easier? In contraposition: if it makes sense to stick to iTXt and not use tEXt, it also makes sense to stick to uncompressed iTXt and not compress it. Say I write a simple XMP processor that handles as many formats as possible: TIFF, JPEG, JPEG-2000, GIF, PNG, PDF, SVG, DNG, etc. The XMP specification has given clear and detailed information on how to *easily* embed XMP in each of these formats. They could have of course recommended the implementors to use libtiff, jpeglib, jasper, libgif, libpng, pdflib, etc. etc. etc. But that should not be the *required* way to go for a simple XMP processor! Perhaps the way to go is the freely-available XMP Toolkit; and does anybody know, is that toolkit able to handle deflate-compressed UTF-8 text? ** So it is entirely valid to embed "XML:com.adobe.xmp" in any text chunk: tEXt, zTXt, uncompressed iTXt, or compressed iTXt. Our registration process won't really change anything but acknowledge its use. Now, the PNG specification allows them all, the XMP specification allows only one of these. That one (the 3rd one) is PNG- and XMP-compliant, the other three (1st, 2nd and 4th) are PNG-compliant only. What we can do is recommend (not require) using uncompressed iTXt for compliance with the XMP specification. It is proposed to register the following new text keyword for use in PNG files: XML:com.adobe.xmp Extensible Metadata Platform (XMP) information, formatted as required by the XMP specification [XMP]. The use of iTXt, with Compression Flag set to 0, and both Language Tag and Translated Keyword set to the null string, are recommended for XMP compliance. References [XMP] Adobe Systems Inc., "XMP Specification", September 2005. http://www.adobe.com/devnet/xmp/ Best regards, Cosmin ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Andreas Kleinert-2
::
Rate this Message:
Kopp, Thomas schrieb:
> In particular, I fully agree with Glenn that a hosted client like XMP cannot impose its own rules to the container, i.e. PNG. The other way around would be the only reasonable approach. Agreed. EXIF, anyone? ;-) ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG and XMP already a way to consider storing metadata?
by Andreas Kleinert-2
::
Rate this Message:
glennrp@... schrieb:
> I understand why it has to be iTXt and not tEXt or zTXt, but why must it be > uncompressed? I'd say, the reason is just to avoid duplication of code and kind of hidden backwards compatibility to tXMP. The specification said back in 2001: >An XML packet can be embedded in a PNG graphic file by adding a chunk >of type “tXMP”. >The data of the chunk should be a UTF-8 serialized XML packet. >There should be no more than one ‘tXMP’ chunk present in each PNG file. [http://xml.coverpages.org/XMP-Embedding.pdf (Sep 14 2001)] So if you replace tXMP by iTXt and add XML:com.adobe.xmp (plus a few bytes) in front, it does not really change anything major in your parsing code. That's more or less what's done in a later version of the spec: [talking about UTF-8 and uncompressed iTXTt] http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf (Sep 2005) In SView5 I'm still supporting both ways for reading and the latter for writing. Prepared it for compressed chunks, but decided against that for now, due to the requirements of the spec. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
CompressesXMP.png (600 bytes) | Free embeddable forum powered by Nabble | Forum Help |
