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

2003.11.26 17:41 "[Tiff] Re: Bug in LogLuv", by Antonio 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.

I started using the 48-bit format, but I missunderstood the name LogLuv and didn't noticed that L is infact Y. Since 16 bits were not enough to hold the linear Y, I end up using the conversion to XYZ. It was easier to handle the data this way.

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.

Thanks for the pointers.

The version 1.03 of HDRShop that I downloaded reports compression not implemented. Is there a newer version somewhere else?