[Tig] Why isn't HDR(-like) rendering more widespread?
Thu Mar 30 01:44:10 BST 2006
Thanks to oktobor for supporting the TIG
"What is more important for now is that people in the industry focus on
updating their infrastructure in terms of storage. The future is hungry for
storage and too few can go above a couple of terabytes."
Nobody increases their storage so they can ask "now what?'. They increase
their storage because it will allow them to provide a higher quality
product, ie: hdr
In my opinion, linear floating point, or hdr, is an increase in quality that
warrants the storage upgrade, whereas 4k doesn't (necessarily).
On 3/29/06, Dan C. Tatut <dtatut at chrome-imaging.com> wrote:
> Thanks to oktobor for supporting the TIG
> True about DPX (sad but true) and true about OpenEXR..
> Things will change as soon as there will be devices to capture and record
> HDR images... but this will come for sure.
> What is more important for now is that people in the industry focus on
> updating their infrastructure in terms of storage. The future is hungry for
> storage and too few can go above a couple of terabytes.
> 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: Bob Friesenhahn [mailto:bfriesen at simple.dallas.tx.us]
> Sent: jeudi, 30. mars 2006 01:58
> To: Dan C. Tatut
> Cc: glenn chan; tig at tig.colorist.org
> Subject: RE: [Tig] Why isn't HDR(-like) rendering more widespread?
> 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 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
Tig list - http://tig.oktobor.com/mailman/listinfo/tig
TIG wiki: http://tig.colorist.org/wiki
More information about the Tig