|
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:
|
|
|
|
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 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.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. 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:
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 profilesI 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:
|
|
|
|
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,
|
|
|
|
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 ?! 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:
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.
toggle quoted messageShow quoted text
On January 17, 2017 5:56:34 AM PST, Ben De Luca <bd...@...> wrote:
--
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:
|
|
|
|
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.
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|