On Thu, Aug 21, 2003 at 10:16:13AM -0400, Leonard Rosenthol wrote: > At 11:42 PM -0700 8/13/03, Manish Singh wrote: > >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.
But if your other tools already use it (for whatever reason, technical or historical) easier have GIMP support it rather than change the rest. This is precisely the reason R&H decided to go with an open source solution like GIMP (they could hack float16 support in) instead of Photoshop or some other closed paint program. > And admittedly, it's not a big deal to convert... And makes the file size twice as big... > >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. If you make it easier to accept wacky things, you interoperate better. Suppose someone wants to use GIMP to manipulate what their neurological imaging scanner spits out at full precision; GEGL is supposed to make that possible. Yes, there should be efforts to make the common case easily interoperable, but uncommon things should be possible with the minimum amount of hoops. > >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... And Foo organization adds a tag with the the same value as Bar organization, for different purposes, since neither cares to wait. Part of the reason why there is a lot of bad tiff processors out there I think. > >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 ;). What widely used formats have you implemented? :) > 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 ar supports random access and single file extraction just fine. Take a look at the manpage for it sometime. :) > 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. And for TIFF we need to define how you go from a GIMP image in memory to TIFF tags and values. Remember GIMP has to carry around a fair amount of metadata, like layer settings, paths, parasites, etc. > Worth the work, sure! Trivial - no way! It doesn't seem to me that using libtiff saves us a significant amount of work. > > >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... Yeah, but there are people out there still running outdated installed, it's harder to get them to upgrade a system library. If we add and extend tags, their definitions should go in the library, no? So what to do in the time before those changes are accepted... Also, one has to wonder why Adobe is keeping PSD around if TIFF does everything. -Yosh _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
