[vtk-developers] zlib

[David Gobbi]

On Wed, 1 Nov 2000, Michael Halle wrote:

> To clarify:
> 
> * To include the option to transparently compress/read data does not mean
>   *require* the use of compressed data.
> 
> * The issue of including widely useful mechanisms for data
>   compression as part of the core capabilities of vtk is separate
>   from making it easier to add extensions to vtk.  Both should be done,
>   I think.  Reading compressed streams is a core capability, not restricted
>   to a single vtk module.

It could be limited to a --configure option, or be automatically
configured like threads. 

> * vtk data files of sparse data can easily zip down by a factor of ten or one
>   hundredfold.  Knowing that compression is available for those kinds
>   of files as a core property of vtk changes how you think about dealing
>   with those files completely, and for the better.
.
> * the use of a standard compression method means that external tools can
>   still be used to manipulate the vtk data.  You're not locking anyone in
>   to anything.
> 
> 
> Michael Halle
> mhalle at media.mit.edu

Thanks for putting all the items into a succinct list.  I agree with 
everything, except that I'm uncertain about whether the zlib source
should be included with the VTK source.

> Ps.  The TIFF distribution doesn't ship with LZW anymore because of patent
> problems.  zip doesn't have those problems.

Yes, but this means that VTK should support PNG, not that VTK should
support zlib compression in TIFF files.  If you look at the current
vtkTIFFReader and vtkImageReader code, you'll see that the way they
are written it would be pretty difficult to add compressed file support
to them, writing an entirely new file reader might be easier.
 
 - David
 
--
  David Gobbi, MSc                    dgobbi at irus.rri.on.ca
  Advanced Imaging Research Group
  Robarts Research Institute, University of Western Ontario