Here is a brain dump about XCF and state persistence.  It is just food
for thought and does not require immediate action for 2.6, except
maybe for the handling of the flag GIMP_PARASITE_PERSISTENT:

Some time ago, Peter mentioned that he would like the XCF file format
to save all state associated with the image, so that you can reload
the file later and continue exactly where you left off.  This implies
that each XCF file would have to save the state of the image as well
as a bit of the GIMP state but we still have to discuss how far we
want to go with that.  For example: do we save the state of all tools
in each XCF file?  Do we save the current settings for all plug-ins?
Do we allow the user to remove that information before sharing the XCF
file with other users?

But besides the state of the environment (GIMP tools and plug-ins), we
should also ensure that the state of the image is correctly saved.
With the current GIMP, this is not perfect because some information
about the image exists only in internal (temporary) data structures
and some other data is stored in image or layer parasites that are not
persistent so these things are not saved in the XCF file.

For example, if you save a work-in-progress as XCF and come back to it
later, then you may have lost the original file name, you may not be
able to recompose layers that were decomposed from another layer and
you may get different settings if you save the image as TIFF or JPEG
(because the parasites "decompose-data" or "tiff-save-options" are not

If we want to solve some of these problems in 2.6 or later releases,
then a first step would be to make all parasites persistent (as if
GIMP_PARASITE_PERSISTENT was always included in the flags).  We will
also have to ensure that all binary parasites handle byte ordering
correctly because any XCF file could be loaded later on a different
platform.  Would there be any objection to making all parasites
persistent by default?

Gimp-developer mailing list

Reply via email to