On Wed, 13 Aug 2003 23:42:36 -0700, Manish Singh <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote:
> > At 8:12 PM -0700 8/13/03, Manish Singh wrote:
> > >What's the turnaround time for that? Taking weeks or months isn't really
> > >acceptable...
> > It's there to make sure that people don't duplicate tags - so
> > as long as we pick pretty unique tags related to the GIMP, it's not a
> > problem.
> It's not just the tags, but extending value ranges for tags (needed for
> the two cases above).
If I am not mistaken, one cannot extend the value range of tags that
are already registered. So the only solution is to define a new tag
based on the old one and extending its capabilities. This also means
that most TIFF readers will just discard the new tags because they are
not able to deal with them. One solution (kludge) would be to encode
as much of the data as possible in the "standard" tags (i.e., for CIE
LAB) and then encoding the differences in a new tag (whatever parts of
XYZ do not fit in LAB). That would allow more software to read at
least a part of the data, but do we really want to do that? Probably
> For GIMP, we're better off to have a native file format we have the last word
> on rather than trying to co-opt something else and twisting things to work.
> Certainly, there should be a libxcf for other programs to use, and include
> thumbnails and other convenience ancillary data for simpler programs to
> work with.
>From my point of view, this is the best solution. However, there is
one thing that has not been mentioned in this discussion until now: we
have to state very clearly that the new XCF is meant to be an open
format (or not!). There has always been some confusion about whether
the current XCF could be used by other applications (e.g. file
managers, indexing programs or other image editing software). I think
that we have to choose one of the following two solution and not
something in between:
- XCF is an open format that can be used by other applications and can
be used as an interchange format. In this case, every single
feature of the file format has to be documented very clearly. The
documentation should not lag behind the implementation (even during
development). Also, the file format should use version numbers or
tag names for each part of the file and there should be a way for
other applications to know if understanding a given part of the file
is mandatory or if it is optional (like PNG does with the naming of
its tags). Ideally, the code for loading and/or saving XCF files
should be available as one or two libaries distributed under the
LGPL or maybe a BSD license. If XCF files can be produced by other
applications than the GIMP (and other libraries than the XCF library
included in the GIMP), then we should be prepared to handle files
that are broken in various ways and fail gracefully.
- XCF is mostly a GIMP internal file format and XCF files are not
intended to be distributed widely and read or written by other
applications. In this case, we can have some documentation but we
make no promises to other applications. The file format can change
at any time (as the GIMP developers add new features or fix some
bugs in the file format) and the others have to deal with it. This
also means that the file format is not a standard so nothing would
prevents another application from extending XCF in some incompatible
way: if XCF files are not intended for distribution, any application
can do whatever it wants to do with its private version of XCF.
Although I think it could have been done in a better way (more
communication and more care about XCF version numbers), there is
nothing really wrong in creating an incompatible version of XCF for
FilmGimp/CinePaint as long as XCF files are intended to be private
files for the application that created them.
We are leaning towards the first solution for the new XCF file format.
Previously, XCF was usually defined as belonging to the second
category. If we want XCF to be an open standard that can also be used
for distribution of images and exchange of files between several
applications, we have to do it in the right way. We also have to be
prepared to deal with the consequences: one of them will be that we
cannot make any assumptions about the correctness of the files that we
try to read. From now on, the GIMP will have to be (more) careful
when reading the XCF files and implement some (more) error detection
Also, if we define a new version of the XCF file format to be used in
GIMP 2.2 or 3.0, this means that the old versions used in GIMP 1.x and
2.0 and the versions used in FilmGimp/CinePaint will become frozen.
This may not be true for the CinePaint version if the CinePaint
developers do not want to adopt the new XCF file format, but I hope
that we can define a new format that will suit everybody. If the old
versions are frozen, this would be a good opportunity to document them
so that the applications that are interested in backwards
compatibility can read these files.
Gimp-developer mailing list