On Wed, 13 Aug 2003 23:42:36 -0700, Manish Singh <yosh@xxxxxxxx> 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 not. > 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 and recovery. 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. -Raphaël
