[Tig] Why isn't HDR(-like) rendering more widespread?

Bob Friesenhahn bfriesen
Thu Mar 30 00:30:30 BST 2006

Thanks to oktobor for supporting the TIG
On Thu, 30 Mar 2006, Dan C. Tatut wrote:

> 32-bit color grading is not just to correct mistakes. Try this simple example:
> step 1: lift the luminance of all your colors until the image on screen looks white.

step 1 was a mistake. :-)

> step2: Add a secondary color correction and decrease the luminance of the selected region.
> If you get a grey shade, then too bad, your system is not HDR capable.
> Now imagine that step 1 and step 2 are animated and go from one 
> extreme to the other... if your system is not HDR capable, you will 
> get white or black most of the time... ugly and not correct.

I think that it should be clarified that there are systems which use 
extended range internally but which do I/O only to traditional 
integer-based formats, and there are true "HDR" capable systems which 
primarily do their I/O using HDR file formats.  With the first type of 
system, the colorist can do almost whatever they like and the image is 
not destroyed unless they accidentally saved the out-of-range version. 
With the second type of system (full HDR), the loaded image could look 
white or black but be restored by adjusting the values back into 
visual range.  This second type of system requires use of true HDR 
file formats like OpenEXR, LogLuv TIFF, floating point TIFF, Radiance, 
and others.

The third sort of system is one in which image values are always saved 
internally in limited (non-HDR) integer range so care must be taken to 
keep the values in range at all times.  Unfortunately, GraphicsMagick 
falls into this third category. :-(

Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Tig list - http://tig.oktobor.com/mailman/listinfo/tig
TIG wiki: http://tig.colorist.org/wiki

More information about the Tig mailing list