Adding JPEG output image file support to VTK

[Lisa Sobierajski Avila]

Hello John,

JPEG image writing could be implemented as a writer class - like 
vtkTIFFWriter. This can still be used to write the image from a render 
window through the use of a vtkWindowToImageFilter. This way you wouldn't 
need to modify vtkRenderWindow, and the JPEG writer class could be added to 
the makefile of contrib or local by hand (like vtkVolumeProVG500Mapper in 
contrib which need the vli library).

Lisa


At 02:18 PM 5/9/00 -0600, John M. Linebarger wrote:
>Your proposal and solution pattern makes sense, as long as a fundamental 
>distinction is made between standalone *extensions* of VTK that use other 
>software packages, and fundemental *alterations* of the core class 
>functionality of VTK that involve other software packages.  A repository 
>of contributed code addresses the former situation, but the latter 
>situation is more tricky,
>and is (I think) the issue that Will et al. are grappling with below.
>
>My JPEG image contribution falls into the latter category, because it 
>could not easily be made as a standalone extension to VTK; it was much 
>cleaner to alter the core vtkRenderWindow class to add JPEG image 
>support.  Unfortunately, this begs the configuration issue because not all 
>platforms will have both the JPEG library and the required header files 
>installed.  My only
>suggestion here is to have a richer configuration script, such as a GNU 
>autoconfig script, that tests for the presence of required libraries and 
>header files and only enables certain methods if the supporting libraries 
>are present.  A call to the function on a system that did *not* have the 
>required libraries would return a message like "method not supported on 
>this system."
>Not pretty, perhaps, but how else are ya gonna handle it?
>
>Other ideas?
>
>Sean Spicer wrote:
>
> > Will, Others,
> >
> > The development of effective interfaces between vtk and external software
> > packages is of critical importance to many of us in the general vtk
> > community -- What we all have to realize though, is that these interfaces
> > in most cases are not part of the "core" of vtk, they are simply there to
> > augment the current functionality provided.  I've developed several
> > interfaces between vtk and external packages either written by me, other
> > individuals, and other organizations, and while I don't pretend that all
> > of these interfaces should be provided as part of the standard vtk
> > distribution, certainly some of them may benefit other programmers.  I'm
> > guessing that there are a number of people out there with similar
> > contributions to make.
> >
> > My suggestion would be to set aside a section of the kitware website as a
> > repository for contributed code and examples, provided with documentation
> > from the author as to system requirements, dependencies/conflicts, and an
> > appropriate usage/license agreement (GNU public license for
> > example).  All such code would then be available to the user by
> > (hopefully) downloading the source into local/ or contrib/, editing
> > user.make, and building the appropriate directory.  (see
> > http://solvedeath.stanford.edu/~spicer/vtk-volumizer for an example)
> >
> > This solution would enable members of our little community to share code,
> > without kitware necessarily becoming directly involved in maintaining
> > Makefiles and test suites for contributed code.
> >
> > What do people think?
> >
> > sean
> >
> > On Tue, 9 May 2000, Will Schroeder wrote:
> >
> > > Hi John-
> > >
> > > I've been away for a couple of days, sorry for the late response.
> > >
> > > Why don't you send me the diffs. I'll look into getting them into the 
> system. And thanks for the contribution.
> > >
> > > The work you've done raises some issues that we've been wrestling with.
> > > Namely, how do we include software that has dependencies on external 
> packages? Certainly your addition is extremely valuable and many people 
> would like to use it. On the other hand, since the contribution requires 
> additional external software, it ends up making VTK harder to compile and 
> test.  Do you (or anyone on this list) have any ideas on how to manage 
> this situation?
> > >
> > > Will
> >
> > ___________________________________________________________________________
> > Sean Spicer                       Stanford University Medical Center
> > Biomechanical Engineering         Division of Vascular Surgery, Suite H3642
> > Cardiovascular Biomechanics Lab   Stanford CA, 94305
> >                                   Telephone...650.723.1695
> >                                   Fax.........650.723.8762
> >
> >              http://solvedeath.stanford.edu/~spicer
> >
>
>
>--------------------------------------------------------------------
>This is the private VTK discussion list. Please keep messages on-topic.
>Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
><majordomo at public.kitware.com>. For help, send message body containing
>"info vtkusers" to the same address.
>--------------------------------------------------------------------

--------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at public.kitware.com>. For help, send message body containing
"info vtkusers" to the same address.
--------------------------------------------------------------------