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

Dan C. Tatut dtatut
Thu Mar 30 18:04:27 BST 2006

Thanks to oktobor for supporting the TIG
Why not.

PFM, Radiance Pic, or even Mental Ray are simple HDRI image formats. 

The problem (and this is one great advantage of DPX) is that all these formats would require a bit more specification in order to store them efficiently on disk (e.g. for real-time access) and of course a well defined set of meta datas....

DPX is popular in the (Digital) Film community because it carries film-related information (timecode, edge code) and colorimetric information. If we can have all this in a new format, why not.

Dan Tatut
CHROME Imaging
105 Rue de Lyon
CH-1203 Geneva

Phone: +41 22 807 23 60
Fax: +41 22 807 23 70
Mobile: +41 78 659 11 04
WWW: http://www.chrome-imaging.com

-----Original Message-----
From: Kai-Uwe Behrmann [mailto:ku.b at gmx.de]
Sent: jeudi, 30. mars 2006 19:18
To: Bob Friesenhahn
Cc: Dan C. Tatut; glenn chan; tig at tig.colorist.org
Subject: RE: [Tig] Why isn't HDR(-like) rendering more widespread?

What about PFM?
The very simplistic floating point precission format is used as an trivial 
interchange format. At least PFM could play the role of an fall back 
option if others dont work. Support is easy.

A well defined / used standard should of course get priority.

PFM's are available from here can:

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

Am 29.03.06, 17:58 -0600 schrieb Bob Friesenhahn:

> --
> Thanks to oktobor for supporting the TIG
> --
> On Thu, 30 Mar 2006, Dan C. Tatut wrote:
> > Obviously our system supports 32-bit float not only during processing but
> > also in storage. When people ask us why we do not use DPX to store
> > intermediates frames, well, the answer is simple: not 32-bit float
> > definition in DPX/Cineon (which by the way is a shame).
> There is clearly a 32-bit float definition in DPX, and has been since 1994.
> It is based on 32-bit float and 64-bit doubles.  There are some (including
> myself) who would like to add 16-bit 'half'.  What is needed in DPX (besides
> actually using the defined floating format) is a bit more definition of how
> floating point values are to be treated. It makes sense to use a similar
> definition as is used in OpenEXR.
> > Our frame management is open and gives DPX and Cineon access but also
> > does more. For the exact purpose discussed here. DPX in its current state
> > of definition is not the future. Either a 32-bit float extension is added
> > to it soon, or it will slowly bur surely be replaced by OpenEXR or
> > something equivalent.
> The floating point storage is there in DPX but it seems that there is fear of
> actually using it.
> While I think that OpenEXR is really neat, it is not designed to be an
> standard DI interchange format like DPX is.  DI interchange formats need to be
> straightforward, specifiable, and ready to use.  OpenEXR is too powerful of a
> tool for DI interchange.  Since DPX has such a bad rap, there are folks
> working on a new format rather than trying to fix DPX.
> Bob
> ======================================
> 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