Date   

Review: First pass at TruelightTransform and TruelightOp

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

Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm


Re: Status of CSP prelut?

Jeremy Selan <jeremy...@...>
 

Thanks, looks great.  Committed.

I did a bit of superficial re-factoring; take a look if you're interested.  The big changes where to separate lut parsing from evaluation.  This lets us detect no-op cases earlier, and in the no-op case not even bother allocating the interpolators or 1d luts.

-- Jeremy

On Mon, Feb 14, 2011 at 7:41 PM, DBR - Ben <dbr....@...> wrote:
Oh, of course - test data might be.. useful...

http://dl.dropbox.com/u/796113/ocio_temp/csp_prelut_testfile.tar.gz

- Source image (JPLogLin'd marcie)
- a lin_to_rec709.csp test LUT
- source image with LUT burned-in, using both RSP's internal code, and the OCIOFileTransform node (..with one small tweak)

It matches very closely. The only change I made is to bump the number of samples from 2**12 to 2**16 (will commit this shortly) - any difference is likely due to tetrahedral interoplation vs OCIO's linear.


On 15 February 2011 09:40, Malcolm Humphreys <malcolmh...@...> wrote:
Sorry I'm working on some other stuff for the last few days in preparation for wrapping up next week. I'll be back on ocio tomorrow so I'll have a look at it then.

.malcolm

On 15/02/2011, at 9:33 AM, Jeremy Selan wrote:

Cool, looks good!

Would anyone have an example csp file with a prelut suitable for testing?
Malcolm?

Even though what you've done looks totally reasonable, I'd like to QC it against some known good results before we say it's working... ;)

-- Jeremy


On Sun, Feb 13, 2011 at 6:43 AM, dbr/Ben <b...@...> wrote:
Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised:


On 09/02/2011, at 7:10 AM, Jeremy Selan wrote:

Looks good.

So for the case you outline below, you'd create a Lut1D op, where
from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go
in the lut.

I'd go with a fixed number of samples for now, using linear
interpolation between.  Let's just pick a big number for the short
term, say 2**12 or 2**16, and hard code it.   In the medium or long
term, we'll probably swap it out for analytical spline evaluation to
make it a non-issue.

-- Jeremy


On Mon, Feb 7, 2011 at 5:53 AM, dbr/Ben <b...@...> wrote:
Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.

https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).

SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy

On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben








Re: Review: new Baker interface

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

Thats cool, I'm trying to get all the remaining pieces in place before friday. So
I will have a few more things over the next few days.

.malcolm


On 22/02/2011, at 5:17 AM, Jeremy Selan wrote:

On first glance, this looks great. Thanks! I wont have a chance to do a more thorough review until tomorrow...

-- Jeremy

On Sun, Feb 20, 2011 at 3:54 AM, Malcolm Humphreys <malcolmh...@...> wrote:
https://github.com/imageworks/OpenColorIO/pull/73

Replacing some pre ocio code for building luts at drd

- Added new OCIO::Baker interface and initial pass at houdini lut writing
- Added new app ociobakelut which is a light wrapper around OCIO::Baker
- Exposed the FormatRegistry to the rest of the core so that OCIO::Baker can access format->Write()
- Added GetFileFormat() which will return a format based on nickname
- Modify the truelight test data so that it looks more like what comes out of truelight

.malcolm




Re: Review: new Baker interface

Jeremy Selan <jeremy...@...>
 

On first glance, this looks great. Thanks! I wont have a chance to do a more thorough review until tomorrow...

-- Jeremy


On Sun, Feb 20, 2011 at 3:54 AM, Malcolm Humphreys <malcolmh...@...> wrote:
https://github.com/imageworks/OpenColorIO/pull/73

Replacing some pre ocio code for building luts at drd

- Added new OCIO::Baker interface and initial pass at houdini lut writing
- Added new app ociobakelut which is a light wrapper around OCIO::Baker
- Exposed the FormatRegistry to the rest of the core so that OCIO::Baker can access format->Write()
- Added GetFileFormat() which will return a format based on nickname
- Modify the truelight test data so that it looks more like what comes out of truelight

.malcolm



Review: new Baker interface

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

https://github.com/imageworks/OpenColorIO/pull/73

Replacing some pre ocio code for building luts at drd

- Added new OCIO::Baker interface and initial pass at houdini lut writing
- Added new app ociobakelut which is a light wrapper around OCIO::Baker
- Exposed the FormatRegistry to the rest of the core so that OCIO::Baker can access format->Write()
- Added GetFileFormat() which will return a format based on nickname
- Modify the truelight test data so that it looks more like what comes out of truelight

.malcolm


Re: Status of CSP prelut?

DBR - Ben <dbr....@...>
 

Oh, of course - test data might be.. useful...

http://dl.dropbox.com/u/796113/ocio_temp/csp_prelut_testfile.tar.gz

- Source image (JPLogLin'd marcie)
- a lin_to_rec709.csp test LUT
- source image with LUT burned-in, using both RSP's internal code, and the OCIOFileTransform node (..with one small tweak)

It matches very closely. The only change I made is to bump the number of samples from 2**12 to 2**16 (will commit this shortly) - any difference is likely due to tetrahedral interoplation vs OCIO's linear.

On 15 February 2011 09:40, Malcolm Humphreys <malcolmh...@...> wrote:
Sorry I'm working on some other stuff for the last few days in preparation for wrapping up next week. I'll be back on ocio tomorrow so I'll have a look at it then.

.malcolm

On 15/02/2011, at 9:33 AM, Jeremy Selan wrote:

Cool, looks good!

Would anyone have an example csp file with a prelut suitable for testing?
Malcolm?

Even though what you've done looks totally reasonable, I'd like to QC it against some known good results before we say it's working... ;)

-- Jeremy


On Sun, Feb 13, 2011 at 6:43 AM, dbr/Ben <b...@...> wrote:
Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised:


On 09/02/2011, at 7:10 AM, Jeremy Selan wrote:

Looks good.

So for the case you outline below, you'd create a Lut1D op, where
from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go
in the lut.

I'd go with a fixed number of samples for now, using linear
interpolation between.  Let's just pick a big number for the short
term, say 2**12 or 2**16, and hard code it.   In the medium or long
term, we'll probably swap it out for analytical spline evaluation to
make it a non-issue.

-- Jeremy


On Mon, Feb 7, 2011 at 5:53 AM, dbr/Ben <b...@...> wrote:
Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.

https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).

SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy

On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben







Re: Status of CSP prelut?

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

Sorry I'm working on some other stuff for the last few days in preparation for wrapping up next week. I'll be back on ocio tomorrow so I'll have a look at it then.

.malcolm


On 15/02/2011, at 9:33 AM, Jeremy Selan wrote:

Cool, looks good!

Would anyone have an example csp file with a prelut suitable for testing?
Malcolm?

Even though what you've done looks totally reasonable, I'd like to QC it against some known good results before we say it's working... ;)

-- Jeremy


On Sun, Feb 13, 2011 at 6:43 AM, dbr/Ben <b...@...> wrote:
Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised:


On 09/02/2011, at 7:10 AM, Jeremy Selan wrote:

Looks good.

So for the case you outline below, you'd create a Lut1D op, where
from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go
in the lut.

I'd go with a fixed number of samples for now, using linear
interpolation between.  Let's just pick a big number for the short
term, say 2**12 or 2**16, and hard code it.   In the medium or long
term, we'll probably swap it out for analytical spline evaluation to
make it a non-issue.

-- Jeremy


On Mon, Feb 7, 2011 at 5:53 AM, dbr/Ben <b...@...> wrote:
Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.

https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).

SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy

On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben






Re: Status of CSP prelut?

Jeremy Selan <jeremy...@...>
 

Cool, looks good!

Would anyone have an example csp file with a prelut suitable for testing?
Malcolm?

Even though what you've done looks totally reasonable, I'd like to QC it against some known good results before we say it's working... ;)

-- Jeremy


On Sun, Feb 13, 2011 at 6:43 AM, dbr/Ben <b...@...> wrote:
Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised:


On 09/02/2011, at 7:10 AM, Jeremy Selan wrote:

Looks good.

So for the case you outline below, you'd create a Lut1D op, where
from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go
in the lut.

I'd go with a fixed number of samples for now, using linear
interpolation between.  Let's just pick a big number for the short
term, say 2**12 or 2**16, and hard code it.   In the medium or long
term, we'll probably swap it out for analytical spline evaluation to
make it a non-issue.

-- Jeremy


On Mon, Feb 7, 2011 at 5:53 AM, dbr/Ben <b...@...> wrote:
Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.

https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).

SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy

On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben





Re: Status of CSP prelut?

"dbr/Ben" <b...@...>
 

Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised:


On 09/02/2011, at 7:10 AM, Jeremy Selan wrote:

Looks good.

So for the case you outline below, you'd create a Lut1D op, where
from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go
in the lut.

I'd go with a fixed number of samples for now, using linear
interpolation between.  Let's just pick a big number for the short
term, say 2**12 or 2**16, and hard code it.   In the medium or long
term, we'll probably swap it out for analytical spline evaluation to
make it a non-issue.

-- Jeremy


On Mon, Feb 7, 2011 at 5:53 AM, dbr/Ben <b...@...> wrote:
Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcol...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.

Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.

https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).

SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.

Do you have example CSP files that use the prelut? I'd love to look at them.

-- Jeremy

On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <db...@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..

From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?

- Ben




Re: Review: No more email reviews!

Jeremy Selan <jeremy...@...>
 

Actually, on further thought let's do both.  Very few people get notified of pull requests, and I'd like to keep everyone on this list in the development loop. (that is it's purpose, after all).

So going ahead, I'd like to encourage review emails, to this list, that have a link to a github pull request and a quick summary.

Thanks!

-- Jeremy


Re: Review: No more email reviews!

"dbr/Ben" <b...@...>
 

Sounds good.

My only concern is that discussion would end up being spread over both the mailing list, and pull request comments - it's kind of nice to have it all in one place

...but that's a pretty minor thing - I like the pull requests, they're much more accessible and visible
- Ben

On 09/02/2011, at 12:01 PM, Jeremy Selan wrote:

So github's pull request mechanism has gotten a lot better since we
started the project.

At this point I don't see a compelling reason to submit reviews to
this email alias, rather than to just use github's existing mechanism.
Does anyone disagree?

If we're in favor of testing the approach out, I'll be submitting a
pull request momentarily (with the apps updated to not use boost's
program options).

-- Jeremy


Review: No more email reviews!

Jeremy Selan <jeremy...@...>
 

So github's pull request mechanism has gotten a lot better since we
started the project.

At this point I don't see a compelling reason to submit reviews to
this email alias, rather than to just use github's existing mechanism.
Does anyone disagree?

If we're in favor of testing the approach out, I'll be submitting a
pull request momentarily (with the apps updated to not use boost's
program options).

-- Jeremy


Re: Stable Version, Ahoy!

Jeremy Selan <jeremy...@...>
 

Excellent. Thanks for the feedback.

Do we know that static linking isn't currently working? I've never
tried. Why wouldn't it work already? (just that we dont have cmake
create the .a library?)

The transform / op plugin API is outside the scope of what I'd like to
get into 1.0, but the rest are feasible. What use cases are you
thinking of with regards to a plugin API. Why wouldnt these just be
developed as part of the core library for wide distribution? The
longer we can avoid going down the plugin API route, the more portable
we'll keep OCIO profiles...

-- Jeremy


Re: Review: ociocheck

Jeremy Selan <jeremy...@...>
 

Sounds good. I'll try to give it a shot.

-- Jeremy

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...@...





Re: Status of CSP prelut?

Jeremy Selan <jeremy...@...>
 

Looks good.

So for the case you outline below, you'd create a Lut1D op, where
from_min = 0.0, from_max = 4.0, and the lut values 0 ... 2.0 would go
in the lut.

I'd go with a fixed number of samples for now, using linear
interpolation between. Let's just pick a big number for the short
term, say 2**12 or 2**16, and hard code it. In the medium or long
term, we'll probably swap it out for analytical spline evaluation to
make it a non-issue.

-- Jeremy

On Mon, Feb 7, 2011 at 5:53 AM, dbr/Ben <b...@...> wrote:
Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.
Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.
https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready?  I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).
SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.
Do you have example CSP files that use the prelut? I'd love to look at them.
-- Jeremy
On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..
From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?
- Ben


Re: Review: ociocheck

Larry Gritz <l...@...>
 

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...@...


Re: Status of CSP prelut?

"dbr/Ben" <b...@...>
 

Started attempting this, seems to be progressing well - thanks for the tips!

To be clear about the resampling. Given a prelut of:

0.0 2.0 4.0
0.0 1.0 2.0

..the code would linearly-interoplate between 0.0 and 4.0, sampling the spline and producing something like:

0.0 0.5 1.0 1.5 2.0

Assuming that is correct - how many samples should be made? A fixed amount? Configurable? Based on the number of spline points?

Could this be a problem if (for some perverse/contrived reason) you have a prelut of:

0.0 1.0 99999.0
0.0 1.0 2.0

On 04/02/2011, at 11:22 AM, Jeremy Selan wrote:

Ben,

So if you're still interested in implementing this feel free to take a
stab.

What you'll probably want to do is to copy the code from the specified
link,
add it to an anonymous namespace in the cspreader, and then use it at
load time to resample the and create a shaper lut1D. Just follow the
example on the normal 1d lut already being used for reference code.

(Also please add the appropriate copyright additions to our license
file).

If you're not up for this any longer, no worries.

-- Jeremy

On Feb 1, 11:07 pm, Malcolm Humphreys <malcolmh...@...>
wrote:
I was planning on doing this but have had a few other higher priority production things come up so it's been on the back burner.

Yes, we're waiting on spline interpolation code.
Malcolm will be the authority on which spline interpolation is
appropriate for the csp prelut, I'll let him comment on the details.
I'm not sure if a simple spline model is sufficient, or if more
advanced features (such as tangent controls) are necessary.
https://cinespacelutlib.svn.sourceforge.net/svnroot/cinespacelutlib/t...

Ben - Do you already have suitable spline code ready? I have some
strong ideas for how I'd like the code to be implemented internally.
(The issue is whether the spline would be upsampled on load to a
regularized 1D lut, or instead if we should create a new native
SplineOp (which would likely require both CPU + GPU implementations).
SplineOp should sampled into the 1D lut on load (+1)







If you're not up for tackling the Op code, I'd be happy to do that
legwork, and then you could update the csp reader.
Do you have example CSP files that use the prelut? I'd love to look at them.
-- Jeremy
On Tue, Feb 1, 2011 at 2:46 PM, dbr/Ben <dbr....@...> wrote:
I was going to attempt to finish it off, but wanted to check if there's anything I should know before starting to prod around..
From the comments/old mailing list messages, it seems like it is mainly just waiting on a SplineOp class?
- Ben


Re: Review: ociocheck

"dbr/Ben" <b...@...>
 

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


Re: Review: ociocheck

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

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


Re: Review: ociocheck

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

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

1781 - 1800 of 2242