[vtk-developers] zlib

David Gobbi dgobbi at irus.rri.on.ca
Wed Nov 1 13:06:27 EST 2000

On Wed, 1 Nov 2000, Sebastien BARRE wrote:

> At 01/11/00 12:15, Michael Halle wrote:
> >I know that there's been a long-standing philosophy that vtk is
> >easiest maintained when it is standalone, not dependent on outside
> >libraries except when essential.  I would like to discuss the
> >possibility of making an exception and adding zlib to a future vtk
> >release.
> I do agree with you, zlib is a good candidate, I've been using it myself as 
> part of a freeware I've written, and it is very easy to use. The static lib 
> is small.

I disagree... what someone should do is take this opportunity to
demonstrate how to add _extensions_ to VTK (either via a configure
option or preferably via the ObjectFactories).  This will be much
better in the long run.

> >* Many of the data and image files in visualization are enormous, yet
> >   sparse. A standard compression would be extremely helpful, and improve
> >   the speed of loading over network-mounted disks or the net.
> As the vtkdata and vtkbaseline are growing and growing, we could shrink 
> them easily.

Using compression would only shrink them to about 1/2 or 1/4 their
original size.   With disk space as cheap as it is these days, I never
compress my files unless I'm archiving them.  My CPU has better things
to do than compress and uncompress 40MB data files. 

> >* with zlib, it's possible to read and write PNG files, which support
> >   up-to-16 bit grayscale images, 48 bit truecolor images, color-palette
> >   images, and alpha transparency.  PNG is a very simple format (simpler
> >   than TIFF), so you don't really need libpng, but you need to have
> >   zip compression.
> Indeed libpng is *very* small and portable too, both projects have the same 
> philosophy.
> But as we already have a TIFF writer, we might be able to use the zlib 
> compression scheme in TIFF.

This would be an EXTREMELY bad idea.  The standard compression scheme in
LZW, which is incompatible with zlib.  Do we want VTK to write TIFF files
that can't be read by other software?

The main problem with the vtkTIFFWriter is not that it doesn't support
compression (which is a strictly optional portion of the TIFF standard)
but that it doesn't support multiple strips (which is manditory according
to the standard).  

This is why the vtkTIFFWriter can't read the TIFF files generated by
many other applications.  This is a major pain in the arse. 

So, here's how things should proceed (IMHO):

1) someone should write a vtkPNGReader, which can go in 'vtk/local'

2) at least someone else should test it

3) modify 'configure' or 'pcmaker' to check for either libpng or
   for the libpng source code, move vtkPNGReader to 'vtk/contrib',
   and then contribute the class to Ken, Will and Bill. 

I would be willing to do steps 2 & 3, if someone is willing to do
step 1.  (For anyone who wants to do this, I would suggest deriving
vtkPNGReader from vtkImageImport instead of vtkImageReader, it'll make
things a lot easier).

 - David

  David Gobbi, MSc                    dgobbi at irus.rri.on.ca
  Advanced Imaging Research Group
  Robarts Research Institute, University of Western Ontario

More information about the vtk-developers mailing list