Date   

Re: icc profile for photoshop

Haarm-Pieter Duiker <li...@...>
 

Lars is certainly the right person to receive that suggestion...

HP




On Fri, Jan 27, 2017 at 9:55 AM Brendan Bolles <bre...@...> wrote:
On Jan 27, 2017, at 8:45 AM, Kevin Wheatley wrote:

> sounds similar to us then, do you explicitly assign a profile to the
> displays in the OS or at least use the same profile from the display
> when baking the ICC profile? This is the (ab)use I mentioned in our
> usage - we use a perfect display profile for all our machines so we
> only bake a single ICC for a given look using the same profile -  it
> essentially defeats the colour management engine somewhat but means it
> "matches Nuke" (OCIO Display node).
>
> Our monitors calibration is handled within the monitors.


We always bake to sRGB and have the computers use that as their display profile.  Nuke doesn't respect the actual display properties, so we don't want Photoshop to either.

In the past few years Photoshop has added the Color Lookup adjustment layer and artists are starting to turn off color management in Photoshop and use that instead, which matches Nuke exactly.

Would this be a good time to mention how nice it would be if Adobe would add OCIO as an option or let us set an explicit LUT for display?  I guess their response would be to tell those smaller companies like Autodesk and the Foundry to adopt their ICC workflow.


Brendan

--
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: icc profile for photoshop

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

On Jan 27, 2017, at 8:45 AM, Kevin Wheatley wrote:

sounds similar to us then, do you explicitly assign a profile to the
displays in the OS or at least use the same profile from the display
when baking the ICC profile? This is the (ab)use I mentioned in our
usage - we use a perfect display profile for all our machines so we
only bake a single ICC for a given look using the same profile - it
essentially defeats the colour management engine somewhat but means it
"matches Nuke" (OCIO Display node).

Our monitors calibration is handled within the monitors.

We always bake to sRGB and have the computers use that as their display profile. Nuke doesn't respect the actual display properties, so we don't want Photoshop to either.

In the past few years Photoshop has added the Color Lookup adjustment layer and artists are starting to turn off color management in Photoshop and use that instead, which matches Nuke exactly.

Would this be a good time to mention how nice it would be if Adobe would add OCIO as an option or let us set an explicit LUT for display? I guess their response would be to tell those smaller companies like Autodesk and the Foundry to adopt their ICC workflow.


Brendan


Re: icc profile for photoshop

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

On Fri, Jan 27, 2017 at 4:31 PM, Brendan Bolles <bre...@...> wrote:
I'd say lift in the blacks is the most common, usually shifting their colors some direction in the process. This is exacerbated by us making profiles intended to be applied to a log image, so you lose some bandwidth there.

The differences often don't seem too major, but I'm usually making them for Matte Painters who have a VERY good eye for even small shifts.

It's hard to tell how much of it is non-optimal profiles from OCIO vs. limitations in the CMS software vs. limitations in the ICC approach overall. Maybe Lars can help us get to the bottom of it.
sounds similar to us then, do you explicitly assign a profile to the
displays in the OS or at least use the same profile from the display
when baking the ICC profile? This is the (ab)use I mentioned in our
usage - we use a perfect display profile for all our machines so we
only bake a single ICC for a given look using the same profile - it
essentially defeats the colour management engine somewhat but means it
"matches Nuke" (OCIO Display node).

Our monitors calibration is handled within the monitors.

Kevin


Re: icc profile for photoshop

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

On Jan 27, 2017, at 12:47 AM, Kevin Wheatley wrote:

I'm intrigued by your comment of not good enough, when I compare, the differences are usually most visible as a slight lift in the blacks vs Nuke.

We set up with P3 monitors and generate profiles using the displays' profile typically with a log input colour space with some wide primary set, e. g. ACEScc(t).

What sort of differences do you see?

I'd say lift in the blacks is the most common, usually shifting their colors some direction in the process. This is exacerbated by us making profiles intended to be applied to a log image, so you lose some bandwidth there.

The differences often don't seem too major, but I'm usually making them for Matte Painters who have a VERY good eye for even small shifts.

It's hard to tell how much of it is non-optimal profiles from OCIO vs. limitations in the CMS software vs. limitations in the ICC approach overall. Maybe Lars can help us get to the bottom of it.


Brendan


Re: icc profile for photoshop

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



On 26 Jan 2017 11:13 p.m., "Brendan Bolles" <bre...@...> wrote:
On Jan 24, 2017, at 8:14 PM, 'Lars Borg' via OpenColorIO Developers wrote:

> Is there any interest in creating WCG/HDR-ready ICC profiles within OCIO?


Yes!!!

And aside from lacking the improvements you mention, I find the ICCs we're currently making to be pretty inadequate.  If set up an ICC transformation and compare it to the original LUT, there are usually noticeable differences.  It's in the ballpark, but often not good enough for production work.

I'm intrigued by your comment of not good enough,  when I compare,  the differences are usually most visible as a slight lift in the blacks vs Nuke. 

We set up with P3 monitors and generate profiles using the displays' profile typically with a log input colour space with some wide primary set,  e. g.  ACEScc(t). 

What sort of differences do you see? 

Kevin 


Re: icc profile for photoshop

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

On Jan 24, 2017, at 8:14 PM, 'Lars Borg' via OpenColorIO Developers wrote:

Is there any interest in creating WCG/HDR-ready ICC profiles within OCIO?

Yes!!!

And aside from lacking the improvements you mention, I find the ICCs we're currently making to be pretty inadequate. If set up an ICC transformation and compare it to the original LUT, there are usually noticeable differences. It's in the ballpark, but often not good enough for production work.


Brendan


Re: icc profile for photoshop

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

On Wed, Jan 25, 2017 at 9:30 AM, Kevin Wheatley
<kevin.j....@...> wrote:
Or current (ab)use of the profiles
I really should avoid typing on small devices... "Our" in this context
refers to my day job and not OCIO .

Kevin


Re: icc profile for photoshop

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

Lars, 

Ah,  now I feel a little silly for not recognising your email address!

I'm interested in improving the use of hdr/wcg/ACES* images in Adobe's products,  so I'll bite too. 

Or current (ab)use of the profiles really does not acknowledge colour management and it is  more a way of applying a lut,  without the need for an adjustment layer. 

Though not strictly OCIO related,  I'm  particularly interested in an integer representation for use with Photoshop,  having better profiles would help with that.

Kevin 


Re: icc profile for photoshop

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

Haha I don't think you could dangle such a tantalizing carrot in front of us and not expect us to bite ;)

On Tue, Jan 24, 2017 at 10:19 PM, Haarm-Pieter Duiker <li...@...> wrote:
Count me as interested. It would be very helpful if the ICC generation capabilities of OCIO could handle HDR input ranges and wide color gamuts. 

HP




On Tue, Jan 24, 2017 at 9:19 PM 'Lars Borg' via OpenColorIO Developers <ocio...@...> wrote:
Hi Kevin,



Well, I had planned to write a longer mail, but it got sent prematurely.



Here is a longer version:



Is there any interest in creating WCG/HDR-ready ICC profiles within OCIO?



The current set of ICC profiles from OCIO (I looked at the ones created

for ACES

1.0.3) has some short-comings in current workflows and that we should

consider addressing. Here's my list:



1. The profile’s PCS space is too small, just Lab.

   The ICC specification states that compliant implementations (CMMs)

shall constrain (clip) conversions to the ICC Lab range. The ICC Lab range

is 0..100 for L, and -128..+128 for a and b. This space was sufficient for

printing.

  It is not sufficient for say Rec. 2020. For Rec. 2020 the green corner

is outside ICC’s Lab range. This is easily shown in a ColorSync plot.

Other spaces that support colors (already in SDR mode) wider than ICC Lab

includes ACES, ACEScc,ACEScg, ARRI LogC, Sony S-Gamut,

   Now it might not matter to you as today all your colors are inside the

P3 space and (SDR) P3 fits completely within ICC Lab range.

   Another aspect that saves the day is that not all CMMs are ICC

compliant. Some CMMs support intermediate values outside the Lab range.

But now you’re relying heavily on deviations from the spec.





2. The profile is an SDR profile, not supporting any HDR content or HDR

displays.

   Lab maxes out at ACES diffuse white (100). When applying RRT ODT to

ACES HDR shots, this (in a compliant CMM) clips the specular highlights.

   Constrained XYZ gives us 2x headroom. Not much but should give us less

clipping.

   However, we can use ICC profiles in non-constrained mode, extrapolating

into HDR space. Marti Maria (lcms) suggested this years ago, and we’ve

been doing this since 2006. All but 3D LUTs can be extrapolated. We’re now

routinely creating HDR profiles for HDR TV, log cinema spaces, etc.



Interested?



Lars Borg

Adobe



--

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: icc profile for photoshop

Haarm-Pieter Duiker <li...@...>
 

Count me as interested. It would be very helpful if the ICC generation capabilities of OCIO could handle HDR input ranges and wide color gamuts. 

HP




On Tue, Jan 24, 2017 at 9:19 PM 'Lars Borg' via OpenColorIO Developers <ocio...@...> wrote:
Hi Kevin,



Well, I had planned to write a longer mail, but it got sent prematurely.



Here is a longer version:



Is there any interest in creating WCG/HDR-ready ICC profiles within OCIO?



The current set of ICC profiles from OCIO (I looked at the ones created

for ACES

1.0.3) has some short-comings in current workflows and that we should

consider addressing. Here's my list:



1. The profile’s PCS space is too small, just Lab.

   The ICC specification states that compliant implementations (CMMs)

shall constrain (clip) conversions to the ICC Lab range. The ICC Lab range

is 0..100 for L, and -128..+128 for a and b. This space was sufficient for

printing.

  It is not sufficient for say Rec. 2020. For Rec. 2020 the green corner

is outside ICC’s Lab range. This is easily shown in a ColorSync plot.

Other spaces that support colors (already in SDR mode) wider than ICC Lab

includes ACES, ACEScc,ACEScg, ARRI LogC, Sony S-Gamut,

   Now it might not matter to you as today all your colors are inside the

P3 space and (SDR) P3 fits completely within ICC Lab range.

   Another aspect that saves the day is that not all CMMs are ICC

compliant. Some CMMs support intermediate values outside the Lab range.

But now you’re relying heavily on deviations from the spec.





2. The profile is an SDR profile, not supporting any HDR content or HDR

displays.

   Lab maxes out at ACES diffuse white (100). When applying RRT ODT to

ACES HDR shots, this (in a compliant CMM) clips the specular highlights.

   Constrained XYZ gives us 2x headroom. Not much but should give us less

clipping.

   However, we can use ICC profiles in non-constrained mode, extrapolating

into HDR space. Marti Maria (lcms) suggested this years ago, and we’ve

been doing this since 2006. All but 3D LUTs can be extrapolated. We’re now

routinely creating HDR profiles for HDR TV, log cinema spaces, etc.



Interested?



Lars Borg

Adobe



--

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: icc profile for photoshop

Lars Borg <bo...@...>
 

Hi Kevin,

Well, I had planned to write a longer mail, but it got sent prematurely.

Here is a longer version:

Is there any interest in creating WCG/HDR-ready ICC profiles within OCIO?

The current set of ICC profiles from OCIO (I looked at the ones created
for ACES
1.0.3) has some short-comings in current workflows and that we should
consider addressing. Here's my list:

1. The profile’s PCS space is too small, just Lab.
The ICC specification states that compliant implementations (CMMs)
shall constrain (clip) conversions to the ICC Lab range. The ICC Lab range
is 0..100 for L, and -128..+128 for a and b. This space was sufficient for
printing.
It is not sufficient for say Rec. 2020. For Rec. 2020 the green corner
is outside ICC’s Lab range. This is easily shown in a ColorSync plot.
Other spaces that support colors (already in SDR mode) wider than ICC Lab
includes ACES, ACEScc,ACEScg, ARRI LogC, Sony S-Gamut,
Now it might not matter to you as today all your colors are inside the
P3 space and (SDR) P3 fits completely within ICC Lab range.
Another aspect that saves the day is that not all CMMs are ICC
compliant. Some CMMs support intermediate values outside the Lab range.
But now you’re relying heavily on deviations from the spec.


2. The profile is an SDR profile, not supporting any HDR content or HDR
displays.
Lab maxes out at ACES diffuse white (100). When applying RRT ODT to
ACES HDR shots, this (in a compliant CMM) clips the specular highlights.
Constrained XYZ gives us 2x headroom. Not much but should give us less
clipping.
However, we can use ICC profiles in non-constrained mode, extrapolating
into HDR space. Marti Maria (lcms) suggested this years ago, and we’ve
been doing this since 2006. All but 3D LUTs can be extrapolated. We’re now
routinely creating HDR profiles for HDR TV, log cinema spaces, etc.

Interested?

Lars Borg
Adobe


Re: icc profile for photoshop

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

On Fri, Jan 20, 2017 at 3:59 AM, <lrs...@...> wrote:
Now's the time to make better ICC profiles ?!

The current set of ICC profiles (I looked at the ones created for ACES
1.0.3) has some short-comings in current workflows and that we should
consider addressing. Here's my list:

- The PCS space is Lab. This is too small for current projects. Lab is
smaller than Rec. 2020. Several corners of the 202 cube get clipped by Lab.

Whilst I'm don't think OCIO has perfect ICC support, I'm not sure
what you propose is even possible. Last time I read the ICC
specifications the only options for profile connection space are
L*a*b* and XYZ, neither of which have any limits which prevent you
using 2020 gamut - I certainly have profiles using ACES AP1 which is
wider than 2020. Could you describe what you are trying to do?

As a random guess are you perhaps relying on the inbuilt sRGB display
profile, when really you need a wider one?

Kevin


ACES 1.0.2 and 1.0.3 configs in the Sony repo

Haarm-Pieter Duiker <li...@...>
 

Hello OCIO-ers,

The ACES 1.0.2 and 1.0.3 configs were accepted into the main OCIO repo this weekend.

The 1.0.3 config includes the latest 1.0.3 transforms, including the sRGB Output Transform, some updates to organization that should be helpful to newcomers and updates to the Input Transforms for ARRI, Canon and Red.

One thing to note, the names of a few colorspaces changed as follow:
  • 'ADX - ADX10' became 'Input - ADX - ADX10'
  • 'ADX - ADX16' became 'Input - ADX - ADX16'
  • 'Input - ARRI - Linear - ARRI Wide Gamut' became 'Input - ARRI - Linear - ALEXA Wide Gamut'
  • The 'logc3eiXXX_arriwide' spaces became 'logc3eiXXX_alexawide'
Please post OCIO-specific issues here and ACES-specific issues on acescentral.com

Thanks!
HP





Re: OCIO - Path Forward

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

TravisCI supports OSX and Linux.



On January 17, 2017 5:56:34 AM PST, Ben De Luca <bd...@...> wrote:
Absolutely pick the best thing, the only real benefit to what I am providing is I can give you exactly the environment that you want if its not provided by one of the cloudy tools. I don't believe any of them supported OSX. 

Its would be running on my virtual CI infrastructure.   

On 16 January 2017 at 23:52, Larry Gritz <l...@...> wrote:
I don't have any Jenkins experience, but Travis is pretty straightforward and I've really come to rely on it for my open source projects. It's a big boost to know before you merge something that it's been built and passes tests on a matrix of several platforms, compilers, and build options. Well worth the time investment to get it set up. Appveyor is also helpful as the rough equivalent on Windows.


On Jan 16, 2017, at 1:31 PM, Sean Cooper <se...@...> wrote:

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


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


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


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


Re: OCIO - Path Forward

Ben De Luca <bde...@...>
 

Absolutely pick the best thing, the only real benefit to what I am providing is I can give you exactly the environment that you want if its not provided by one of the cloudy tools. I don't believe any of them supported OSX. 

Its would be running on my virtual CI infrastructure.   

On 16 January 2017 at 23:52, Larry Gritz <l...@...> wrote:
I don't have any Jenkins experience, but Travis is pretty straightforward and I've really come to rely on it for my open source projects. It's a big boost to know before you merge something that it's been built and passes tests on a matrix of several platforms, compilers, and build options. Well worth the time investment to get it set up. Appveyor is also helpful as the rough equivalent on Windows.


On Jan 16, 2017, at 1:31 PM, Sean Cooper <se...@...> wrote:

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


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


--
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 - Path Forward

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

I don't have any Jenkins experience, but Travis is pretty straightforward and I've really come to rely on it for my open source projects. It's a big boost to know before you merge something that it's been built and passes tests on a matrix of several platforms, compilers, and build options. Well worth the time investment to get it set up. Appveyor is also helpful as the rough equivalent on Windows.


On Jan 16, 2017, at 1:31 PM, Sean Cooper <se...@...> wrote:

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


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



Re: OCIO - Path Forward

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

@ben, though iId look into the other contributors opinion on TravisCI vs. Jenkins

On Mon, Jan 16, 2017 at 12:37 PM, Sean Cooper <se...@...> wrote:
That would be great if you have the cycles!


Re: OCIO - Path Forward

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

That would be great if you have the cycles!


Re: OCIO - Path Forward

Ben De Luca <bde...@...>
 

On the CI front I can provide windows Linux and mac systems plus Jenkins if you want. 



On Fri., 13 Jan. 2017 at 1:40 am, Sean Cooper <se...@...> wrote:
Whoops, try giving it another go

On Thu, Jan 12, 2017 at 3:39 PM, Deke Kincaid <dekek...@...> wrote:
You probably have to move the file to your personal gmail.  Google docs are not view-able outside of our domain either.

On Thu, Jan 12, 2017 at 3:38 PM, Deke Kincaid <dekek...@...> wrote:
You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.


On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03








--


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.














--


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.











--


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 - Path Forward

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

Whoops, try giving it another go

On Thu, Jan 12, 2017 at 3:39 PM, Deke Kincaid <dekek...@...> wrote:
You probably have to move the file to your personal gmail.  Google docs are not view-able outside of our domain either.

On Thu, Jan 12, 2017 at 3:38 PM, Deke Kincaid <dekek...@...> wrote:
You need permission

This form can only be viewed by users in the owner's organization.

Try contacting the owner of the form if you think this is a mistake. Learn More.


On Thu, Jan 12, 2017 at 3:33 PM, Sean Cooper <se...@...> wrote:
Here is a form to get an invite for the OpenColorIO Slack channel, I'll add them manually from there. We're looking to keep it to the smaller group of core owners/contributors, though feel free to invite whomever you think would help the cause!

https://goo.gl/forms/Lq9buvEJg2qzJzq03

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

661 - 680 of 2201