|
Re: Review: DisplayTransform interface update
Oh, and have we agreed to use 'View' rather than 'Alias'? I'm cool with that...
-- Jeremy
Oh, and have we agreed to use 'View' rather than 'Alias'? I'm cool with that...
-- Jeremy
|
By
Jeremy Selan <jeremy...@...>
·
#400
·
|
|
Re: Review: DisplayTransform interface update
Would this syntax preserve Display order? I think that's important.
-- Jeremy
Would this syntax preserve Display order? I think that's important.
-- Jeremy
|
By
Jeremy Selan <jeremy...@...>
·
#399
·
|
|
Re: Review: DisplayTransform interface update
Malcom,
I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to
Malcom,
I'm thinking of an edge case where you want to query the defalt displays of a color configuration independently of the active displays. The example I could think of is writing a script to
|
By
Joseph Slomka <jsl...@...>
·
#398
·
|
|
Re: Review: DisplayTransform interface update
Hi Joesph,
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called
Hi Joesph,
Oh I was thinking in the profile the list of active_displays would be the defaults. Which then you could dynamically override with $OCIO_ACTIVE_DISPLAYS (which was called
|
By
Malcolm Humphreys <malcolmh...@...>
·
#403
·
|
|
Re: Review: DisplayTransform interface update
Malcom,
I like your layout. I think that calling the
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think
Malcom,
I like your layout. I think that calling the
The name change will allow the opportunity to have a list of default display that can be different from what the active displays are.
I think
|
By
Joseph Slomka <jsl...@...>
·
#397
·
|
|
Re: Review: DisplayTransform interface update
Hi,
Ok thats a bit clearer. But I think having this as a flat list is not so nice.
After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of
Hi,
Ok thats a bit clearer. But I think having this as a flat list is not so nice.
After playing around with this a bit I came up with this layout. This makes it clearer that you have a set of
|
By
Malcolm Humphreys <malcolmh...@...>
·
#402
·
|
|
Re: Review: DisplayTransform interface update
Here's a chunk from spi-vfx with the new options:
displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display>
Here's a chunk from spi-vfx with the new options:
displays:
- !<Display> {device: sRGB, alias: Raw, colorspace: nc10}
- !<Display> {device: sRGB, alias: Log, colorspace: lg10}
- !<Display>
|
By
Jeremy Selan <jeremy...@...>
·
#396
·
|
|
Re: Review: FileTransform supports .cc and .ccc files
This sounds like a good solution, much less error prone than storing the dropdown in the node itself.
The J_3Way node (http://major-kong.blogspot.com/2010/01/jops-10v1a5-released.html ) has a nice UI
This sounds like a good solution, much less error prone than storing the dropdown in the node itself.
The J_3Way node (http://major-kong.blogspot.com/2010/01/jops-10v1a5-released.html ) has a nice UI
|
By
"dbr/Ben" <b...@...>
·
#395
·
|
|
Re: Review: FileTransform supports .cc and .ccc files
Good point. I've renamed the first section "A contrived example", which just explains using env-vars to find a LUT. The second example is more practical, and applies the grade, then a lin-to-log/3D
Good point. I've renamed the first section "A contrived example", which just explains using env-vars to find a LUT. The second example is more practical, and applies the grade, then a lin-to-log/3D
|
By
"dbr/Ben" <b...@...>
·
#394
·
|
|
Re: Review: FileTransform supports .cc and .ccc files
Hi Ben,
I love docs :) (because of my horrible memory)
My main comments would be I would tend to aim 'contexts' being used as part of the complete viewing transform. Right now it reads as though we
Hi Ben,
I love docs :) (because of my horrible memory)
My main comments would be I would tend to aim 'contexts' being used as part of the complete viewing transform. Right now it reads as though we
|
By
Malcolm Humphreys <malcolmh...@...>
·
#393
·
|
|
Re: Review: FileTransform supports .cc and .ccc files
LGTM
.malcolm
By
Malcolm Humphreys <malcolmh...@...>
·
#392
·
|
|
Review: Processor.getGpuShaderTextCacheID()
LGTM
Begin forwarded message:
LGTM
Begin forwarded message:
|
By
Malcolm Humphreys <malcolmh...@...>
·
#391
·
|
|
Re: Review: DisplayTransform interface update
Hi,
Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as
Hi,
Can you post an example profile with a few more display lines. The code for this looks fine, I'm just not too sure of the structure in the yaml and how clear the names device and alias are as
|
By
Malcolm Humphreys <malcolmh...@...>
·
#390
·
|
|
Re: Review: FileTransform supports .cc and .ccc files
Nice job on the docs. By all means, check them in! (Even partial
docs are better than nothing). :)
I like this, but I'm not sure that there's a nuke UI widget rich
enough for this behavior. What
Nice job on the docs. By all means, check them in! (Even partial
docs are better than nothing). :)
I like this, but I'm not sure that there's a nuke UI widget rich
enough for this behavior. What
|
By
Jeremy Selan <jeremy...@...>
·
#388
·
|
|
Re: Review: FileTransform supports .cc and .ccc files
This is great. Nice and intuitive \o/
!<FileTransform> {src: grades/grades.ccc, cccid: "beauty/${SEQ}/${SHOT}"}
..or, could split the grades into one file per seq and do ({src:
This is great. Nice and intuitive \o/
!<FileTransform> {src: grades/grades.ccc, cccid: "beauty/${SEQ}/${SHOT}"}
..or, could split the grades into one file per seq and do ({src:
|
By
"dbr/Ben" <b...@...>
·
#389
·
|
|
Review: FileTransform supports .cc and .ccc files
Commits:
http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613
http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a
Issue:
htt
Commits:
http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613
http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a
Issue:
htt
|
By
Jeremy Selan <jeremy...@...>
·
#387
·
|
|
Review: Processor.getGpuShaderTextCacheID()
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/7ffb711edea3b4b3c4aa0ad046c15de8f70b936e
I added a call to get the cacheID for the shadertext on the processor
object. Note that querying the
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/7ffb711edea3b4b3c4aa0ad046c15de8f70b936e
I added a call to get the cacheID for the shadertext on the processor
object. Note that querying the
|
By
Jeremy Selan <jeremy...@...>
·
#386
·
|
|
Review: DisplayTransform interface update
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297ed0d14baa585f04ff4d452
Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenC
Commit:
http://github.com/jeremyselan/OpenColorIO/commit/2ac16ae5e55949e297ed0d14baa585f04ff4d452
Issues:
https://github.com/imageworks/OpenColorIO/issues#issue/25
https://github.com/imageworks/OpenC
|
By
Jeremy Selan <jeremy...@...>
·
#385
·
|
|
Re: Review: Replaced config->getRoleNameByIndex
Sure that sounds great, i'll fix that.
I don't remind removing them altogether.
I was really just adding them to match the old functionality of getRoleNameByIndex() which returned the colorspace
Sure that sounds great, i'll fix that.
I don't remind removing them altogether.
I was really just adding them to match the old functionality of getRoleNameByIndex() which returned the colorspace
|
By
Malcolm Humphreys <malcolmh...@...>
·
#384
·
|
|
Re: Review: Replaced config->getRoleNameByIndex
Thanks!
I like the intent, but have two minor issues:
First, the trivial: I'd prefer to never allow NULL values as return
types from const char * functions. Please use an empty string
Thanks!
I like the intent, but have two minor issues:
First, the trivial: I'd prefer to never allow NULL values as return
types from const char * functions. Please use an empty string
|
By
Jeremy Selan <jeremy...@...>
·
#382
·
|