2003.11.26 14:17 "[Tiff] Bug in LogLuv", by Antonio Scuri

2003.11.26 16:31 "[Tiff] Re: Bug in LogLuv", by Greg Ward

Hi Scuri,

Thanks very much for spotting this bug! I must have never tested or used this particular routine, because as far as I know, it's never manifested a problem. Surely, it would have had it been applied by someone. The 48-bit LogLuv format is not used by any of my applications for communication with the library. I always use floating point XYZ or one of the raw LogLuv encodings.

LogLuv TIFF format is used a number of places, notably by Renderpark <http://www.linux.org/apps/AppId_4060.html> and Radiance <http://www.radiance-online.org> (via the ra_tiff converter). It is also supported by the newest version of HDRshop <http://www.debevec.org/HDRShop/>, a program for building and manipulating high dynamic-range images, and on the Mac by Photosphere <http://www.anyhere.com>, a program for building and cataloging regular and HDR images.

LogLuv still has the upper hand as the most efficient (i.e., most compact and fastest i/o) of any HDR format, which is why I use it for all my own images. The fact that it covers the entire visible gamut also makes it ideal for holding image data on its way to color printers, etc., whose gamut does not usually match the typical RGB range. This is what we used it for (and still use it for) at Shutterfly <http://www.shutterfly.com>.

I continue to be hopeful that Adobe will start supporting the LogLuv and IEEE floating-point TIFF formats, though having had a number of interactions with the appropriate technical group over the past few months, my hopes are starting to wane.