2005.04.11 00:03 "[Tiff] TIFF Technote 3, draft 1", by Chris Cox

2005.04.26 16:33 "Re: [Tiff] TIFF Technote 3, draft 2", by Kai-Uwe Behrmann

The new data formats and new predictor now (partially) supported by libtiff (you should grab development version from CVS). "Partially" means that you should not try the new predictor on big-endian hosts, I must solve one technical issue before it will be possible. But on little-endian boxes you can start playing. I should note that the new predictor works very well, in some cases I have ~25% reduction of image sizes over the plain LZW/ZIP methods.

The improvement depends on the source data (of course). I've got a few cases where it's up to 50% improvement over ZIP alone, but it averages closer to 20% improvement.

And with floating point data, ZIP always outperforms LZW.

All this is good news. It would be useful if the specification would specify a normalized range for the "viewable" data. For example, it would helpful if there was a standard way to convert back and forth between normal integer type RGB and float RGB. It can be expected that dynamic range will be lost when converting to unsigned RGB but the resulting image should look normal.

Is it possible to provide recommendations for this without stepping on someone's toes?

I can provide a recommendation about range for viewing - but that's about all it is.

1.0 should be diffuse white in the scene, specular highlights can go over -- this matches typical camera behavior and provides a useful image to preview using a trivial (1.0 -> 255, 0.0 -> 0) mapping.

Converting is another story, and optimal conversions are VERY image dependent when dealing with HDR data.

To make floating point a more meaningful format within the tiff spec, it would be nice to shift away from the simple 0.0 -> 1.0 mapping approach to a real world scene reference.

Most floating point data have some kind of reference to what 1.0 means, or simply expect the data representing some physical unit (cd/sqr meter or the like). The stonits tag make sense with unconverted XYZ data, while XYZ data are not covered directly by the current tiff spec. Alternatively the range description, suggestion by Bob, can be extended to add a physical value to the lower and upper 'normal' bounds.

The libtiff double and LogLUV sample images gives some examples.

regards
Kai-Uwe Behrmann
                                + development for color management
                                + imaging / panoramas
                                + email: ku.b@gmx.de
                                + http://www.behrmann.name