|
Jeremy Selan <jeremy...@...>
|
|
|
Looks good!
Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:
$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...
Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)
Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?
toggle quoted message
Show quoted text
|
|
|
Jeremy Selan <jeremy...@...>
Agreed about the --inputconfig / $OCIO option. I've added that.
I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.
-- Jeremy
toggle quoted message
Show quoted text
On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote: Looks good!
Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:
$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...
Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)
Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?
On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555
ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.
-- Jeremy
|
|
|
Malcolm Humphreys <malcolmh...@...>
I was looking at oiio argparse but that too seems dependant on boost for something I remember.
.malcolm
toggle quoted message
Show quoted text
On 05/02/2011, at 7:00 AM, Jeremy Selan wrote: Agreed about the --inputconfig / $OCIO option. I've added that.
I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.
-- Jeremy
On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!
Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:
$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...
Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)
Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?
On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555
ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.
-- Jeremy
|
|
|
Only seems to use BOOST_FOREACH - should be easy enough to replace with an old-fashioned for()
toggle quoted message
Show quoted text
On 05/02/2011, at 9:46 AM, Malcolm Humphreys wrote: I was looking at oiio argparse but that too seems dependant on boost for something I remember.
.malcolm
On 05/02/2011, at 7:00 AM, Jeremy Selan wrote:
Agreed about the --inputconfig / $OCIO option. I've added that.
I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.
-- Jeremy
On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!
Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:
$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...
Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)
Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?
On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555
ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.
-- Jeremy
|
|
|
I don't mind at all if somebody wants to replace the BOOST_FOREACH in OIIO argparse with regular 'for' statements. -- lg On Feb 7, 2011, at 2:18 AM, dbr/Ben wrote: Only seems to use BOOST_FOREACH - should be easy enough to replace with an old-fashioned for()
On 05/02/2011, at 9:46 AM, Malcolm Humphreys wrote:
I was looking at oiio argparse but that too seems dependant on boost for something I remember.
.malcolm
On 05/02/2011, at 7:00 AM, Jeremy Selan wrote:
Agreed about the --inputconfig / $OCIO option. I've added that.
I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.
-- Jeremy
On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!
Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:
$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...
Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)
Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?
On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555
ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.
-- Jeremy -- Larry Gritz l...@...
|
|
|
Jeremy Selan <jeremy...@...>
Sounds good. I'll try to give it a shot.
-- Jeremy
toggle quoted message
Show quoted text
On Mon, Feb 7, 2011 at 9:15 AM, Larry Gritz <l...@...> wrote: I don't mind at all if somebody wants to replace the BOOST_FOREACH in OIIO argparse with regular 'for' statements.
-- lg
On Feb 7, 2011, at 2:18 AM, dbr/Ben wrote:
Only seems to use BOOST_FOREACH - should be easy enough to replace with an old-fashioned for()
On 05/02/2011, at 9:46 AM, Malcolm Humphreys wrote:
I was looking at oiio argparse but that too seems dependant on boost for something I remember.
.malcolm
On 05/02/2011, at 7:00 AM, Jeremy Selan wrote:
Agreed about the --inputconfig / $OCIO option. I've added that.
I'll see what I can do about remove the boost dependency. I agree
that if we can avoid it, we should.
-- Jeremy
On Fri, Feb 4, 2011 at 2:57 AM, dbr/Ben <b...@...> wrote:
Looks good!
Perhaps if --inputconfig flag is not set, it could check $OCIO? Might be a convenient way to verify the env is setup correctly, and may answer many "why doesn't OCIO work!" questions. Something like:
$ ociocheck
Checking $OCIO environment variable
Loading /wrong/path/to/config.ocio
Error: File does not exist
$ ociocheck -i /correct/path/to/config.ocio
Loading /correct/path/to/config.ocio ...
Could be useful when there env is less simple, such as inside applications that might be launched from wrapper scripts (e.g run subprocess.Popen("ociocheck") in Nuke's script editor)
Also, I wonder if requiring boost for the config-validation utility is reasonable? While I'm not fussed about the dependency, it seems like ociocheck is something that should always be available, even if built without the optional Boost. I guess the alternatives is to use something standalone like optparse.h, or copy that bit of boost?
On 04/02/2011, at 10:49 AM, Jeremy Selan wrote:
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/8be4a3ba174c69438cf151802f829696cb7b6555
ociocheck now does much better error checking.
It will test each colorspace and see which conversions conversions
to/from scene-linear work, and which do not. This will catch
potential errors related to missing luts, etc.
-- Jeremy --
Larry Gritz
l...@...
|
|
|
