XCF2 metadata
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
XCF spec | David Neary | 31 Aug 20:56 |
XCF spec | Sven Neumann | 31 Aug 21:20 |
XCF spec | David Neary | 31 Aug 21:49 |
XCF spec | Sven Neumann | 01 Sep 08:00 |
XCF spec | Florent Monnier | 02 Sep 00:25 |
XCF spec | Simon Budig | 02 Sep 00:24 |
XCF spec | Florent Monnier | 02 Sep 19:44 |
XCF spec | Simon Budig | 02 Sep 23:17 |
XCF spec | Michael Schumacher | 02 Sep 23:30 |
XCF2 metadata | Florent Monnier | 02 Sep 19:59 |
XCF2 metadata | Sven Neumann | 03 Sep 13:53 |
XCF2 metadata | Øyvind Kolås | 04 Sep 11:40 |
20060902190005.75370A67FF2@... | 07 Oct 20:24 | |
XCF spec | David Neary | 02 Sep 21:31 |
XCF spec | Sven Neumann | 03 Sep 13:55 |
XCF spec
Hi,
Could we get Henning's XCF spec committed to CVS before any of the freezes for 2.4 come into effect, please? It's a vast improvement over the existing version, and has been improved since his first draft to include a detailed definition of layer modes.
Cheers, Dave.
XCF spec
Hi,
On Thu, 2006-08-31 at 20:56 +0200, David Neary wrote:
Could we get Henning's XCF spec committed to CVS before any of the freezes for 2.4 come into effect, please? It's a vast improvement over the existing version, and has been improved since his first draft to include a detailed definition of layer modes.
Didn't you already commit it? I somehow remember that you did. If not, please do so.
Sven
XCF spec
Hi,
Sven Neumann wrote:
On Thu, 2006-08-31 at 20:56 +0200, David Neary wrote:
Could we get Henning's XCF spec committed to CVS before any of the freezes for 2.4 come into effect, please? It's a vast improvement over the existing version, and has been improved since his first draft to include a detailed definition of layer modes.
Didn't you already commit it? I somehow remember that you did. If not, please do so.
Nope - I did ask, but you asked that we wait until it was complete.
Cheers, Dave.
XCF spec
Hi,
now that the spec is in CVS, someone should review it and fix the places where it is wrong with regard to the CVS version of GIMP. Like when it states that only the bottom layer may be without an alpha channel.
Sven
XCF spec
Florent Monnier (fmonnier@linux-nantes.fr.eu.org) wrote:
Hi, I'm searching through the CVS web viewer for the XCF specs without success http://cvs.gnome.org/viewcvs/gimp/
could someone tell me in which directory does it resides ?
http://cvs.gnome.org/viewcvs/gimp/devel-docs/xcf.txt?rev=1.2&view=markup
Bye, Simon
XCF spec
Hi,
now that the spec is in CVS, someone should review it and fix the places where it is wrong with regard to the CVS version of GIMP. Like when it states that only the bottom layer may be without an alpha channel.
Hi, I'm searching through the CVS web viewer for the XCF specs without success
http://cvs.gnome.org/viewcvs/gimp/
could someone tell me in which directory does it resides ?
thanks in advance
XCF spec
Hi, I'm searching through the CVS web viewer for the XCF specs without success http://cvs.gnome.org/viewcvs/gimp/ could someone tell me in which directory does it resides ?
http://cvs.gnome.org/viewcvs/gimp/devel-docs/xcf.txt?rev=1.2&view=markup
Thanks, I was willing to read the last version before to ask a clueless question. Some months ago someone on a mailing-list asked how he could change the comment of xcf files in order to add licencing informations (such as GPL or creative-commons), so as it seems it's not possible from the GUI (maybe we all failed on this mailing-list to find it) I tryed to write a script to change the comment. I noticed that the byte just before the comment (which resides at the begining of the xcf) was the length of this comment, so I tryed to make a script for that guy which changed the comment, and changed the length byte of it too. But It didn't work. http://www.linux-nantes.org/~fmonnier/tmp/comlen.ml.html
From the specs draft I guess that's because there are offsets before the
comment, is it right ?
(I haven't found for the xcf comment in this draft, perhaps I have missed it?)
thanks in advence
XCF2 metadata
Hi, I'm searching through the CVS web viewer for the XCF specs without success http://cvs.gnome.org/viewcvs/gimp/ could someone tell me in which directory does it resides ?
http://cvs.gnome.org/viewcvs/gimp/devel-docs/xcf.txt?rev=1.2&view=markup
Thanks,
In SVG files there are fields in for licencing informations and so
on (you can have an overview of it wathing the xml source of, for exemple,
this file http://openclipart.org/clipart/people/people_juliane_krug_09c.svg)
so I was wondering if it is planed to provide such features in the futur xcf2?
cheers
XCF spec
Florent Monnier wrote:
(I haven't found for the xcf comment in this draft, perhaps I have missed it?)
It's tricky - the comment is stored in a parasite, and in the spec you have the following:
Parasites
---------A second level of extensibility is provided by the "parasite" concept. A parasite is analogous to a property (and is usually stored in a special property in the XCF file) but is identified by a string rather than a number. This makes a larger namespace available for parasites. Gimp plug-ins can access the parasites of an image component through a generic API and can define their own parasite names which will be ignored by other plug-ins. In contrast, only the Gimp itself should define new property types.
A list of known parasites and their data formats can be found in the file devel-doc/parasites.txt of the Gimp source tree.
And in parasites.txt, there is:
gimp-comment" (IMAGE, PERSISTENT) Standard GIF-style image comments. This parasite should be human-readable text in UTF-8 encoding. A trailing \0 might be included and is not part of the comment.
A parasite is the ideal place to store copyright and licence information - you could store it in an exif block stored in the "exif-data" parasite, for example, or perhaps propose some new parasites for gimp-licence, gimp-copyright, etc.
Cheers, Dave.
XCF spec
Florent Monnier (fmonnier@linux-nantes.fr.eu.org) wrote:
Some months ago someone on a mailing-list asked how he could change the comment of xcf files in order to add licencing informations (such as GPL or creative-commons), so as it seems it's not possible from the GUI (maybe we all failed on this mailing-list to find it) I tryed to write a script to change the comment. I noticed that the byte just before the comment (which resides at the begining of the xcf) was the length of this comment, so I tryed to make a script for that guy which changed the comment, and changed the length byte of it too. But It didn't work. http://www.linux-nantes.org/~fmonnier/tmp/comlen.ml.html
From the specs draft I guess that's because there are offsets before the comment, is it right ?
(I haven't found for the xcf comment in this draft, perhaps I have missed it?)
The comment is stored as a so-called "parasite", in this case a parasite of the image (you can also attach parasites to the individual layers/drawables). The comments parasite name is "gimp-comment".
You can use script-fu to access the content of said parasites, the problem is, that the format of the data is not very convenient to process with script fu.
Try this:
- start the gimp
- create a new image, optionally changing the comment
- open the script-fu-console and enter the following command:
=> (gimp-image-parasite-list 1) (1 ("gimp-comment"))
This tells us that there is one parasite for image no. 1, and it is called "gimp-comment".
=> (gimp-image-parasite-find 1 "gimp-comment") (("gimp-comment" 1 #22"437265617465642077697468205468652047494d5000"))
Executing PDB commands via script-fu always returns a list, in this case the first element of the returned list (the first return value) is the parasite that is attached, in script-fu it is represented as a list itself: (name, flags, value). The value is a byte array with in this case 22 bytes, and you'll notice that the following hex values are the bytes of the string "Created with the GIMP", which is the comment.
Writing a plugin to change the comment probably is easier than doing this with script fu or even binary-patching the XCF, the functions in the PDB allow to do this and this is the route I'd suggest.
I hope this helps, Simon
XCF spec
Simon Budig wrote:
Writing a plugin to change the comment probably is easier than doing this with script fu or even binary-patching the XCF, the functions in the PDB allow to do this and this is the route I'd suggest.
Using an existing plug-in is probably even better: http://registry.gimp.org/plugin?id=3064
Can be found by searching for "comment" on http://registry.gimp.org
HTH, Michael
XCF2 metadata
Hi,
On Sat, 2006-09-02 at 19:59 +0200, Florent Monnier wrote:
In SVG files there are fields in for licencing informations and so on (you can have an overview of it wathing the xml source of, for exemple, this file http://openclipart.org/clipart/people/people_juliane_krug_09c.svg) so I was wondering if it is planed to provide such features in the futur xcf2
It's even planned to provide this with XCF:
http://bugzilla.gnome.org/show_bug.cgi?id=61499 http://bugzilla.gnome.org/show_bug.cgi?id=349224
Sven
XCF spec
Hi,
On Sat, 2006-09-02 at 21:31 +0200, David Neary wrote:
A parasite is the ideal place to store copyright and licence information - you could store it in an exif block stored in the "exif-data" parasite, for example, or perhaps propose some new parasites for gimp-licence, gimp-copyright, etc.
Or better yet, read what had been discussed here earlier, have a look at Bugzilla and current CVS. There is really no point in reinventing this wheel once more.
Sven
XCF2 metadata
On 9/2/06, Florent Monnier wrote:
In SVG files there are fields in for licencing informations and so on (you can have an overview of it wathing the xml source of, for exemple, this file http://openclipart.org/clipart/people/people_juliane_krug_09c.svg) so I was wondering if it is planed to provide such features in the futur xcf2?
My current work on XCF2 has been moved over to a collaboration with krita developers on an OpenRaster specification that aims to use/become OpendDocument. I presume OpenDocument has ways of dealing with this, but it is far beyond the things I currently care to experiment with[1]. I am currently only concerned with a compositing tree of layers (with compositing modes and filters, potentially the definition of filters through a syntax similar to SVG-filters with custom graph based pipelines.)
/Øyvind K.