[Bf-committers] TIFF support - submitted patch #2995

[Jonathan Merritt]

Ton Roosendaal wrote:

> Can you provide information how much the tiff library would add to 
> our  distribution binary size? Or, would it be possible to dynamically 
> link  with it, like for yafray or quicktime now, based on dlopen 
> linking (so  no dependency)...?


Unfortunately, it will grow the distributed binary by about 400KB.  I'll 
start work on dynamic linking at runtime... :-)

I can see a problem with availability though.  libtiff is mature and 
quite likely to be available to Linux users as an *.so, but users on 
other platforms (Windoze!) will probably be stuck.  In the short term, 
this is not a real problem, since the patch only implements 
functionality that is already available via QuickTime.  In the future 
though (see below), depending upon demand, static linkage may be better.

> Oh, and last note; can we then also read/write 16 bits per channel  
> tiff? It's used a lot for defining high definition displacement maps  
> (like ZBrush).


Abso-smurfly! :-)  The patch doesn't support this yet, but libtiff 
itself does.  TIFF has many possibilities beyond a plain image file.  
Some (maybe all?) cross over into the kinds of things that OpenEXR was 
designed to handle.  An example is the use of TIFF to store "arbitrary" 
variables.  These could include:
    - depth (z-buffer)
    - surface normals
    - uv coordinates
    - etc...
These can be stored as floating point quantities in TIFF files.  They 
can be stored as separate files, or as additional images alongside the 
RGBA output within a single TIFF file.  Aqsis already supports this kind 
of thing, so I have plenty of example code to look at.

Jonathan Merritt.