Jeremy Selan <jeremy...@...>
Looks good to me!
I have a few comments, but these dont need to be addressed yet.
* In terms of coding style, you put the return value on a new line,
where as I tend to not. I'm actually fine either way, but I'd really
like to keep the codebase uniform in this regard. I'm going to be
putting together coding guidelines together in the next few days, and
once we pick what's preferred I'll do a single cleanup pass to bring
the whole codebase up to spec. (I'll also attack line lengths, and
#include order at the same time).
* Your commit, c7a1bfadeb..., (where you change the walk order to
match GLs ordering) was not strictly necessary. Lut3DOp.h defines two
3dlut index helpers:
You could have used the second function, rather than the first, to
save yourself this trouble. (It is poorly named though, any better
idea on names?)
* We will be able to resolve ambiguously named formats (such as the
super ambiguous .lut) with a minor addition to FileTransform.cpp.
(This code is already in FileTransform:GetFile in code comment form).
The idea is inspired by image reading in Nuke. OCIO will use the
file extension to guess the format, and attempt to load it. (in the
case of multiple formats with the same extension, just pick one). If
this fails, then try to load all other formats with the same extension
until one succeeds. If this fails too, then go ahead and try all
known formats in case it's a misnamed file. The cool part of this
is that users don't have to worry about file format naming (assuming
the lut readers all are good about throwing exceptions early on
malformed luts), and performance doesnt suffer either as the format
results are cached so the rollover detection only happens once per
I'll implement this behavior before the next .lut format is added.