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.
Why would you only use half of a 32bit float?? That reduces your accuracy/precision and makes you incompatible with the rest of the world doing floating point imaging.
And admittedly, it's not a big deal to convert...
One of the goals of GEGL is to allow GIMP to be adapted to wacky formats like these easily.
I would argue that using "wacky formats" is a bad thing. The more wacky you make things, the less change you have for interoperability with other tools.
GEGL uses XYZ as a native format.
Why? Lab is a richer model esp. for handling chromanicity and is also a standard in the print world natively. Why limit to XYZ??
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.
The spec is only updated every 18-24 months when Adobe releases a new version of Photoshop - so you definitely don't wait for that! As for the other, yes, that is true you could wait, but nobody does...
Nailing down a featureset has to be done regardless of the format.
That part is most certainly true.
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.
Never implemented a file format, have you ;).
Reading/Writing the 'ar' archive, and reading/writing the XML is the easy part - because you can leverage existing libraries to some extent. The toughest part is putting it all together in a library of its own that allows for full random access. Most archiving libraries are "all at once" solutions, they aren't designed for single file extraction. We, of course, need that. We also, as part of the DTD/Schema work need to define how you go from a GIMP image in memory to a disk representation and then back and work out the details.
Worth the work, sure! Trivial - no way!
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.
There is no need to touch libtiff - and if there is, you don't work, you modify and then submit your changes back. libtiff is an active library, and the maintainers would happily accept changes...
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.
"Better off" for what reasons??
Does it have advantages, yes. Does it have disadvantages, yes. Where do we draw the line???
Leonard -- --------------------------------------------------------------------------- Leonard Rosenthol <mailto:leonardr@xxxxxxxxxxxxx> <http://www.lazerware.com>
