Looking at my values closer, looks like you are probably right. My input image is 0 to 1 linear, so I wasn't using a shaper. However, when I get to LAB space, there are negative values, which would

That screams bad shaper to me. What are you using for a shaper here? With respect, TJS

Ha. Yeah, that pull request is exactly what I'd want. I'll add my +1 to the PR :) And thanks for the response Sean and Troy --that's pretty much what I'd tried already, CMSTestPattern -> ColorSpace

FWIW there is an old pull request for a simple expression transform which would have been perfect for this, https://github.com/imageworks/OpenColorIO/pull/366 Sent from my phone

Tacking onto Sean's comments, roughly: Use ociolutimage --generate --maxwidth 4225 --cubesize 65 --output all-in-one.exr to generate an all-in-one RGB EXR. Roll that through your L*a*b* CTL functions

OCIO is just a LUT and simple math processor(+,-,*,**,log, etc.), so its not really intended to implement algorithms like L*a*b*. Some equations are more LUT friendly than others something RGB-like to

Can you expand on that? Looking into CTL now, does look like I could define L*a*b* there, but how would that tie in to a config.ocio? I haven't used it before, got some reading to do

Would be more optimal to define L*a*b* according to the proper formulas in a CTL and generate the to and froms from there on an EXR, using a suitable shaper to the 3D LUT. With respect, TJS

hmm, I tried that but it didn't line up. I'll poke around with other lut formats maybe. I used nuke to generate two .cube files

You can use a 3D LUT but still have a reversible colorspace transform by defining both the to-reference and from-reference transforms (I.e to reference would use lab_to_xyz.lut and from-ref would use

Hey all! So I'm trying to get my team off of doing so much in photoshop, and have written some tools using oiio to replace a lot of the workflow. Right now, they like to do an unsharpen mask in

Jack Holm had identified a number of issues with the ICC profiles and was willing to help correct them. Alex

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

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

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

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

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

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

<kevin.j....@...> wrote: I really should avoid typing on small devices... "Our" in this context refers to my day job and not OCIO . Kevin

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