2003.11.26 17:54 "[Tiff] Re: Bug in LogLuv", by Greg Ward
> From: Antonio Scuri <firstname.lastname@example.org>
> Date: Wed Nov 26, 2003 9:41:40 AM US/Pacific
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.
Actually, L is still log(Y), so 16 bits is enough. You have to use the formula in the tif_luv.c header comments. I agree, though, linear XYZ and letting the library do the conversion is much easier! The Radiance source tree includes some handy routines in the ray/src/common directory for fast tone-mapping from LogLuv to 24-bit RGB, and this is what I use in Photosphere.
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?
I was there in Spring when Chris Tchou added this to their in-house version. I was hoping it would be in the official release by now. Perhaps if you nudged him and Paul a bit < email@example.com; firstname.lastname@example.org>...