On Thu, Aug 21, 2003 at 01:38:01AM -0400, Leonard Rosenthol wrote: > At 8:12 PM -0700 8/13/03, Manish Singh wrote: > >On Wed, Aug 20, 2003 at 10:53:14PM -0400, Leonard Rosenthol wrote: > > > At 6:51 PM -0700 8/13/03, Manish Singh wrote: > >> >Does TIFF support, for example, float16 data, or a CIE XYZ colorspace? > >> > >> Yes to both... > > > >Hmm, got a reference to that? It wasn't immediately apparent in my reading > >of the spec. > > See Section 19 for Floating point support in data. Supports IEEE floats, but not float16 (a 32-bit float cut in half). R&H added this to filmgimp since they had established this format in their workflow with other tools already. One of the goals of GEGL is to allow GIMP to be adapted to wacky formats like these easily. TIFF only specs unsigned integer, signed integer, and IEEE floats. > I forget the section, but a simple search of the TIFF6 spec > led to a number of references on CIE XYZ support. Only CIE LAB is given an official type. It's a derivative of CIE XYZ, hence the references to it, but they aren't completely the same thing. GEGL uses XYZ as a native format. > > >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). And a lag time means either waiting for an updated spec, which is a holdup, or going ahead and running the risk it not being granted because someone else tried to get their conflicting values in first. Also nonstandard implementations that may use previously unallocated values or tags which we are trying to use. > >Another thing I'm worried about is simply adding to the confusion of > >"what is a tiff file". There are few tiff readers/writers that support > >the entire feature set of tiff, and many broken implementations out there. > > True - but that's the case with EVERY SINGLE file format > (graphic, wp, etc.). Only the original application for which the > format was created will usually support all features. Not every > feature of PNG is supported by all tools. GIMP doesn't support all > features of PSD files. > > The fact is, WHATEVER format we end up, it needs to be > understood that there will be other consumers of that format that > will not (or can not) implement a full 100% of it. Yes, but TIFF has got this situation much much worse than other formats. It'd be adding more confusion to an already bad situation. > >There's an advantage of starting from a clean slate, and not having to > >worry about existing baggage. > > > > There is indeed...and there are disadvantages as well > (including a LOT more time to design and then code). Not really. Nailing down a featureset has to be done regardless of the format. With the XML+AR idea, there's a little work needed to make a DTD, and then just putting some building blocks together, like an xml library and some ar processing code (multiple implementations exist) and some convenience wrappers. Also, suppose customizing libtiff is needed (and it sounds like it would be), that'd mean forking libtiff and the maintainence problem of tracking the original for bugfixes and enhancements. 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. -Yosh
