Date   

Re: OCIO 1.0.10

Sean Cooper <se...@...>
 

Hi Jep,

I've recently added you, let me know if you don't get the email.

On Fri, Jun 23, 2017 at 1:49 PM, <jep...@...> wrote:
Hi Sean, I'd love an invite to the Slack conversation, please.

Cheers,
Jep

On Wednesday, April 26, 2017 at 10:31:50 AM UTC-7, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO 1.0.10

jep...@...
 

Hi Sean, I'd love an invite to the Slack conversation, please.

Cheers,
Jep


On Wednesday, April 26, 2017 at 10:31:50 AM UTC-7, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean


Re: OCIO Windows build

Patrick Hodoul <patric...@...>
 

Pull request #392 could help you a lot.

On Wednesday, May 3, 2017 at 4:05:50 PM UTC-4, scott jones wrote:
Sorry I don't have an answer, but I am trying to do the same thing and having no luck. Were you ever able to get it working? If I can figure it out I will post my findings. Thanks

On Friday, September 30, 2016 at 1:29:33 AM UTC-7, tde wrote:
Hi,

I know it is an old question but I could not find a working solution.

Is there a walkthrough to build OCIO including PyOpenColorIO on Windows?

Or something precompiled that might work?

My current setup is Visual Studio Community 2015.

Thanks


Re: OCIO Windows build

villa...@...
 

Sorry I don't have an answer, but I am trying to do the same thing and having no luck. Were you ever able to get it working? If I can figure it out I will post my findings. Thanks


On Friday, September 30, 2016 at 1:29:33 AM UTC-7, tde wrote:
Hi,

I know it is an old question but I could not find a working solution.

Is there a walkthrough to build OCIO including PyOpenColorIO on Windows?

Or something precompiled that might work?

My current setup is Visual Studio Community 2015.

Thanks


Re: OCIO 1.0.10

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

I'm not really a part of the OCIO dev community, so take my opinion with a grain of salt, but,

I agree that any discussion about design or big issues of implementation really should happen on the archived, fully public mail list. The asynchronous, think and compose before you write, nature of email actually is an important feature.

Slack or other chat seems good for ephemeral, realtime collaboration, "how do I fix this, I need it in an hour", or a quick question/answer that need not be archived. Slack history may be searchable, but it seems to me that it's mainly geared toward conversations that are ok to be missed by people who happen not to be logged in at the time that they happen. It strikes me as the equivalent of an office hallway conversation -- very important to the daily life of a project, but not where any big decisions should be made.



On Apr 28, 2017, at 3:36 AM, DBR - Ben <dbr....@...> wrote:

I would be interested in joining the Slack channel (although I'd rather discussions happened "in the open" - only so discussion/decisions can be easily referenced in future. However as long as people are diligent in transcribing relevant discussions into this mailing list, or ticket comments etc, that would also be perfectly fine)

In terms of bugs I'd like fixed for a future patch version, these are the major problems we've encountered with 1.0.9, or have patched around in our internal builds:

Problems mainly in Nuke:
1. https://github.com/imageworks/OpenColorIO/issues/397 EnvExpand infinite recursion (querying an unset env-var in a OCIO Nuke node "context" value causes Nuke to freeze forever)
2. https://github.com/imageworks/OpenColorIO/issues/383 HDL baking broken when a look is specified
3. https://github.com/imageworks/OpenColorIO/issues/385 OCIODisplay channel selection dropdown order changed in Nuke 9+

Build problems:
(we also apply pull request #321 as it as it not part of any released version, but it is already merged in master)

Additionally, this seems pretty bad, although is not something I have personally encountered (but only because the en_AU locale we use happens to be compatible enough):
5. https://github.com/imageworks/OpenColorIO/issues/297 parsers should explicitly set LOCALE

On 28 April 2017 at 01:56, Michael Root <mi...@...> wrote:

I'd really like to see https://github.com/imageworks/OpenColorIO/pull/381 or some equivalent in the next official release.

I personally don't like closed-door development of open-source projects, and I don't find Slack at all appealing.  That said, I'm not really a major contributor, so whatever helps keep the OCIO project moving is great.

-miker




On 04/26/2017 10:31 AM, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@...



Re: OCIO 1.0.10

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

I would be interested in joining the Slack channel (although I'd rather discussions happened "in the open" - only so discussion/decisions can be easily referenced in future. However as long as people are diligent in transcribing relevant discussions into this mailing list, or ticket comments etc, that would also be perfectly fine)

In terms of bugs I'd like fixed for a future patch version, these are the major problems we've encountered with 1.0.9, or have patched around in our internal builds:

Problems mainly in Nuke:
1. https://github.com/imageworks/OpenColorIO/issues/397 EnvExpand infinite recursion (querying an unset env-var in a OCIO Nuke node "context" value causes Nuke to freeze forever)
2. https://github.com/imageworks/OpenColorIO/issues/383 HDL baking broken when a look is specified
3. https://github.com/imageworks/OpenColorIO/issues/385 OCIODisplay channel selection dropdown order changed in Nuke 9+

Build problems:
(we also apply pull request #321 as it as it not part of any released version, but it is already merged in master)

Additionally, this seems pretty bad, although is not something I have personally encountered (but only because the en_AU locale we use happens to be compatible enough):
5. https://github.com/imageworks/OpenColorIO/issues/297 parsers should explicitly set LOCALE

On 28 April 2017 at 01:56, Michael Root <mi...@...> wrote:

I'd really like to see https://github.com/imageworks/OpenColorIO/pull/381 or some equivalent in the next official release.

I personally don't like closed-door development of open-source projects, and I don't find Slack at all appealing.  That said, I'm not really a major contributor, so whatever helps keep the OCIO project moving is great.

-miker




On 04/26/2017 10:31 AM, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: OCIO 1.0.10

Michael Root <mi...@...>
 


I'd really like to see https://github.com/imageworks/OpenColorIO/pull/381 or some equivalent in the next official release.

I personally don't like closed-door development of open-source projects, and I don't find Slack at all appealing.  That said, I'm not really a major contributor, so whatever helps keep the OCIO project moving is great.

-miker



On 04/26/2017 10:31 AM, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean
--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: OCIO 1.0.10

zach....@...
 

Hey guys,
I'd love to join the Slack channel (provided our corporate proxy will let me use slack :/ )

I'm really pleased to see forward momentum, both in terms of discussions and development.


Thanks!

Zach


On Wednesday, April 26, 2017 at 1:31:50 PM UTC-4, Sean Cooper wrote:
Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean


OCIO 1.0.10

Sean Cooper <se...@...>
 

Hello all,

With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and product partners.

If you haven't been watching, I invite you to take a look at the OCIO repo, and point out other image quality *bugs* that you deem a requirement for the next minor version. Prior to my involvement there have been a number of commits to master since 1.0.9, and I think it's beneficial to put a stake in the ground as a firm mark of rejuvenation. We can proceed from there.

If you haven't joined in the side Slack conversation where more day-to-day conversation has been centered, please reply below or message me personally I am more than happy to invite you. Or if you have a strong opinion against the "closed-door" conversation, I am open ears.

Thoughts, and opinions welcomed, thanks!
Sean


Re: Error loading lut using environment variables

Simon Björk <bjork...@...>
 

Thanks Sean! I'll have a look at this and do some tests. Seems like it could do the trick :).



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503

2017-03-16 18:38 GMT+01:00 Sean Cooper <se...@...>:


On Tue, Mar 14, 2017 at 8:33 AM, Sean Cooper <se...@...> wrote:
Per-shot colorspaces are generally handeled by the OCIOLooks not OCIOColorspace. Additionally, with Looks you are able to use conditionals (atleast on unix, Id have to try it on other systems) 

So if you had a Look called "perShot" with a file transform pointing to /path/to/$SHOW/$SHOT.lut  you can then apply the Look using a conditional like "perShot|" where if perShot fails it will do the pipe/OR and instead do nothing. You can even do more complicated combinations like "+look1|+look1+look2|". 

This is pretty specific to Looks that modify the view, but that's usually how shot-specific transforms are used. You might be able to use this for other purposes if that isnt your use case. 



On Mar 14, 2017 12:33 AM, "Simon Björk" <bjork...@...> wrote:
Thanks Kevin, seems like it would work.

However (if I'm not misunderstanding) this would require all shot luts to be named the same and also be in separate directories? In my case I would prefer to have the luts named shot01.cube, shot02.cube etc and store them in the same directory (i.e /show/luts/shot_luts/).

I guess I can just create a dummy lut if it doesn't exist as a pre launch process.

/Simon



-------------------------------
Simon Björk
Compositor/TD


2017-03-13 10:35 GMT+01:00 Kevin Wheatley <kevin.j....@...>:
Create a null lut is about the best you can do, combined with the search path you could do

search_path: path/to/${SHOT}:path/to/null

then use a name like "mylut.cube" if you squint hard you can make this do sequence level as well as show wide level, by suitable nesting of directories in search paths.

Kevin


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Error loading lut using environment variables

Sean Cooper <se...@...>
 

On Tue, Mar 14, 2017 at 8:33 AM, Sean Cooper <se...@...> wrote:
Per-shot colorspaces are generally handeled by the OCIOLooks not OCIOColorspace. Additionally, with Looks you are able to use conditionals (atleast on unix, Id have to try it on other systems) 

So if you had a Look called "perShot" with a file transform pointing to /path/to/$SHOW/$SHOT.lut  you can then apply the Look using a conditional like "perShot|" where if perShot fails it will do the pipe/OR and instead do nothing. You can even do more complicated combinations like "+look1|+look1+look2|". 

This is pretty specific to Looks that modify the view, but that's usually how shot-specific transforms are used. You might be able to use this for other purposes if that isnt your use case. 



On Mar 14, 2017 12:33 AM, "Simon Björk" <bjork...@...> wrote:
Thanks Kevin, seems like it would work.

However (if I'm not misunderstanding) this would require all shot luts to be named the same and also be in separate directories? In my case I would prefer to have the luts named shot01.cube, shot02.cube etc and store them in the same directory (i.e /show/luts/shot_luts/).

I guess I can just create a dummy lut if it doesn't exist as a pre launch process.

/Simon



-------------------------------
Simon Björk
Compositor/TD


2017-03-13 10:35 GMT+01:00 Kevin Wheatley <kevin.j....@...>:
Create a null lut is about the best you can do, combined with the search path you could do

search_path: path/to/${SHOT}:path/to/null

then use a name like "mylut.cube" if you squint hard you can make this do sequence level as well as show wide level, by suitable nesting of directories in search paths.

Kevin


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



Re: Error loading lut using environment variables

Sean Cooper <se...@...>
 

Per-shot colorspaces are generally handeled by the OCIOLooks not OCIOColorspace. Additionally, with Looks you are able to use conditionals (atleast on unix, Id have to try it on other systems) 

So if you had a Look called "perShot" with a file transform pointing to /path/to/$SHOW/$SHOT.lut  you can then apply the Look using a conditional like "perShot|" where if perShot fails it will do the pipe/OR and instead do nothing. You can even do more complicated combinations like "+look1|+look1+look2|". 

This is pretty specific to Looks that modify the view, but that's usually how shot-specific transforms are used. You might be able to use this for other purposes if that isnt your use case. 



On Mar 14, 2017 12:33 AM, "Simon Björk" <bjork...@...> wrote:
Thanks Kevin, seems like it would work.

However (if I'm not misunderstanding) this would require all shot luts to be named the same and also be in separate directories? In my case I would prefer to have the luts named shot01.cube, shot02.cube etc and store them in the same directory (i.e /show/luts/shot_luts/).

I guess I can just create a dummy lut if it doesn't exist as a pre launch process.

/Simon



-------------------------------
Simon Björk
Compositor/TD


2017-03-13 10:35 GMT+01:00 Kevin Wheatley <kevin.j....@...>:
Create a null lut is about the best you can do, combined with the search path you could do

search_path: path/to/${SHOT}:path/to/null

then use a name like "mylut.cube" if you squint hard you can make this do sequence level as well as show wide level, by suitable nesting of directories in search paths.

Kevin


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Error loading lut using environment variables

Simon Björk <bjork...@...>
 

Thanks Kevin, seems like it would work.

However (if I'm not misunderstanding) this would require all shot luts to be named the same and also be in separate directories? In my case I would prefer to have the luts named shot01.cube, shot02.cube etc and store them in the same directory (i.e /show/luts/shot_luts/).

I guess I can just create a dummy lut if it doesn't exist as a pre launch process.

/Simon



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503

2017-03-13 10:35 GMT+01:00 Kevin Wheatley <kevin.j....@...>:

Create a null lut is about the best you can do, combined with the search path you could do

search_path: path/to/${SHOT}:path/to/null

then use a name like "mylut.cube" if you squint hard you can make this do sequence level as well as show wide level, by suitable nesting of directories in search paths.

Kevin


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Error loading lut using environment variables

Kevin Wheatley <kevin.j....@...>
 

Create a null lut is about the best you can do, combined with the search path you could do

search_path: path/to/${SHOT}:path/to/null

then use a name like "mylut.cube" if you squint hard you can make this do sequence level as well as show wide level, by suitable nesting of directories in search paths.

Kevin



Error loading lut using environment variables

Simon Björk <bjork...@...>
 

I'm trying to add a colorspace that is using a $SHOT env. It all works as expected if the shot lut exist. If the shot lut does not exist an error is thrown:

The specified file reference  '${SHOT}.cube' could not be located. The following attempts were made: D:\ocio_test\luts\sh001.cube

If I start Nuke i get an error saying it can't load the config file.

Is there anyway to get around this (without creating "dummy" luts)? Can if/else statements be used in the config somehow? It would be great if there was a way to skip the colorspace if the evaluated file doesn't exist.

/Simon



-------------------------------
Simon Björk
Compositor/TD

+46 (0)70-2859503


Re: Force a refresh of context variables?

Tobias Pfeiffer <pixeld...@...>
 

Hi guys,
we were forcing Nuke restarts for a long time now just to make OCIO's context work for fresh opened scripts. This is really unconvenient and artist-unfriendly. Thats why I wanted to give fixing that problem a second try.
Im not a fan of using the Viewer Process, because than you are incorporating software specific color transforms that do not properly work in other software packages (Maya, Max, Houdini). Isn't being software agnostic one of the main reasons to use OCIO in the first place?
I fiddled around with the getCurrentContext method Mark outlined aboved and this seems to work quite easily. But how do I get Nuke to recognize that fresh and updated config?
Any tips?
Best,
Tobias

Am Donnerstag, 16. Januar 2014 20:00:50 UTC+1 schrieb Mark Visser:

On Monday, January 13, 2014 6:35:29 PM UTC-5, dbr/Ben wrote:
If you only need a limited set of the env variables, you can set the Nuke node context tab up like so:

Brilliant, I hadn't thought of that. Just stuck that into our viewer process gizmos and it works like charm.

I wasn't aware of the metadata trick, neat.

cheers,
-Mark


Re: ICC Profile color space with XYZ PCS

joshua.a...@...
 

So...the "input" color space would be XYZ and the "output" would be device color space RGB when using ociobakelut? Is that what you're saying?


Re: ICC Profile color space with XYZ PCS

Brendan Bolles <bre...@...>
 

On Friday, March 3, 2017 at 4:20:36 PM UTC-8, Joshua Jackson wrote:
Is it possible to use ocio to crest an icc profile that can fully define a color space with XYZ PCS like a classic srgb or adobe rgb profile?  What  getting at is that I've defined a device color space with XYZ conversion matrix, shaper LUT for nonlinear response, all RGB and white chromaticities, flare, etc. for a device and would like to use this as an ICC profile in After Effects to define input footage for color management in AE.

For input footage, I'd recommend using the OCIO plug-in for After Effects. Depending on your parameters, there are many transformations that the current code can not bake into an ICC profile.

Where you will really need profiles in After Effects is for setting up a project working space and display transform. The included PDF shows how you can do it all with the plug-in, but it's pretty cumbersome.


Brendan


Re: ICC Profile color space with XYZ PCS

Joseph Slomka <joseph...@...>
 

Joshua,
It's not a problem to make a profile work as you envision it. All you need to is make the XYZ PCS space as the linear color space that each colorpspaces transfers to and from. 
-Joseph


On Fri, Mar 3, 2017 at 4:20 PM, <joshua.a...@...> wrote:
Is it possible to use ocio to crest an icc profile that can fully define a color space with XYZ PCS like a classic srgb or adobe rgb profile?  What  getting at is that I've defined a device color space with XYZ conversion matrix, shaper LUT for nonlinear response, all RGB and white chromaticities, flare, etc. for a device and would like to use this as an ICC profile in After Effects to define input footage for color management in AE.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


ICC Profile color space with XYZ PCS

joshua.a...@...
 

Sorry for the bad grammar, I'm attempting to type all of this on a phone...

641 - 660 of 2233