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

[D.J. Capelis]

A difficult decision indeed, but from what I remember qt isn't a
terrible joy to use across platform either while libtiff and ffmpeg are
a bit more portable.  Someone correct me if I'm wrong on this.

If we do take out qt then the missing features such as PSD support can
be redone properly at another point in time as such features usually
aren't working on all platforms or aren't really implemented very well
anyways.

Theoretically it would be nice to figure out a way we could accomplish
some of this through python scripts.  Does this seem feasible to other
people or does it seem like a pipedream?  Seems like a more portable way
of doing things.

Eventually it would also be nice to see something like this:
http://www.gegl.org/  

Whatever we'll do we're going to be in this situation again later I
think... probably the best thing is to try and making them all work
together for now until there's a longer term solution but if it comes
down to it I think keeping ffmpeg/libtiff may be more important.  Then
again qt works better on other platforms...

Just my $.02

On Tue, 2005-09-06 at 11:55 -0700, Nick Winters wrote:
> On 9/6/05, Ton Roosendaal <ton at blender.org> wrote:
> > Hi,
> > 
> > >
> > > Unfortunately, it will grow the distributed binary by about 400KB.
> > > I'll start work on dynamic linking at runtime... :-)
> > 
> > Hrms... difficult topic. It resembles a little bit the ffmpg
> > integration we want to do now. This also conflicts a bit with the QT
> > support on windows/osx.
> > Choices could be;
> > 
> > - just add ffmpg + libtiff for all platforms (find a way how this can
> > work with QT)
> > - add ffmpg + libtiff for all platforms, remove QT? This because our
> > aim really should be to have a singular functional release for all
> > platforms
> > - only add ffmpg + libtiff for the linux/freebsd/sun/sgi releases
> > 
> > > 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.
> > 
> > Coolness, certainly something we can use for Orange as well! :)
> > 
> > -Ton-
> > 
> Quicktime added also [not perfect, but functional] .psd support, as a
> user I don't think getting rid of it is a good idea
> 
> -nick
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
> 
-- 
~D.J. Capelis~