Re: Review: Inital pass at searchpath impl

Malcolm Humphreys <malcolmh...@...>

On 09 Nov, 2010,at 06:53 AM, Jeremy Selan <jere...@...> wrote:

* I like supporting only strings for now. In the future, I can also
see numbers being supported (such as allowing for CDL blocks that rely
on envvars), but this can be added as needed.

* The FileTransform will probably have to get a bit smarter. Say
you're using a pershot lut, and for some shots you dont want any such
table. This could be solved by either not installing a lut in the
expected location, or by installing an identity lut. Which is
preferable? In the current implementation, if a lut is not found
this is always an error condition. Maybe we should introduce on the
FilmTransform a 'silent error mode', where this would just skip the
application of that specific LUT?
I was tempted to always have a lut that would match in the searchpath, say a global identity lut.
As this is possible to circumvent this way I would fix this later. The identity lut option should be
optimized out so it seems like a good option. But some explicit flag saying apply this lut when
the file is missing seems like a good way to try first.

* The "globals" pre-declaration could also define an optional default
(used if the envvar is not set). If the envvar is not set, and no
default is specified, any references to the global variable would
probably be an error.

* I have some apprehensions about the config->getGlobal,
config->setGlobal implementation. My primary concern is that the
GlobalConfig() is const (by design), so clients couldnt actually call
setGlobals on the config in use. Instead, they would have to do
something like:

c = GetGlobalConfig().createEditableCopy()
SetGlobalConfig( c )

This is a lot of copying, particularly as the globals often are tied
to the clip. If you're A/B-ing two clips in an image viewer,
conceptually there really is only one config, and two sets of globals.
Why force the client to copy and have duplicate configs?
What are your thoughts on having a config per clip and for each config to maintain each state.
I know this breaks the current concept of the config. Would be nice to re-confirm this is the way
we should go.


Join to automatically receive all group messages.