|
Andrew Wood <andre...@...>
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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
|
|
|
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 xyz_to_lab.lut)
Sent from my phone
On 3 Feb 2017, at 09:03, Andrew Wood < andre...@...> wrote: 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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
--
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.
|
|
|
Andrew Wood <andre...@...>
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
On Thursday, February 2, 2017 at 2:54:20 PM UTC-8, dbr/Ben wrote: 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 xyz_to_lab.lut)
Sent from my phone On 3 Feb 2017, at 09:03, Andrew Wood < andr...@...> wrote: 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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Troy Sobotka <troy.s...@...>
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
On Thu, Feb 2, 2017 at 6:05 PM Andrew Wood < andre...@...> wrote: 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
On Thursday, February 2, 2017 at 2:54:20 PM UTC-8, dbr/Ben wrote:
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 xyz_to_lab.lut)
Sent from my phone On 3 Feb 2017, at 09:03, Andrew Wood < andr...@...> wrote:
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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
--
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-d...@....
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.
|
|
|
Andrew Wood <andre...@...>
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
On Thursday, February 2, 2017 at 5:16:37 PM UTC-8, Troy James Sobotka wrote: 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
On Thu, Feb 2, 2017 at 6:05 PM Andrew Wood < andr...@...> wrote: 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
On Thursday, February 2, 2017 at 2:54:20 PM UTC-8, dbr/Ben wrote:
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 xyz_to_lab.lut)
Sent from my phone On 3 Feb 2017, at 09:03, Andrew Wood < andr...@...> wrote:
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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
--
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-d...@....
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
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 RGB-like are generally ok, so I'm not sure how well fit CIELab transforms are for LUT quantization (though at first glance it feels like fitting a square peg into a round hole).
As per Troy's suggestion, you can't directly implement CTL in OCIO. So he was saying essentially you could do the mathematically faithful forward and inverse transform on a sample image (like Nuke's CMSTestPattern) and from them you could use Nuke's make LUT functionality, to LUT-ize the Lab calculation and THEN put than in OCIO. But I'd test the resulting LUT pretty well as I'd imagine it fails in a number of spots.
On Thu, Feb 2, 2017 at 5:55 PM, Andrew Wood <andre...@...> wrote: 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
On Thursday, February 2, 2017 at 5:16:37 PM UTC-8, Troy James Sobotka wrote: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
On Thu, Feb 2, 2017 at 6:05 PM Andrew Wood < andr...@...> wrote: 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
On Thursday, February 2, 2017 at 2:54:20 PM UTC-8, dbr/Ben wrote:
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 xyz_to_lab.lut)
Sent from my phone On 3 Feb 2017, at 09:03, Andrew Wood < andr...@...> wrote:
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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
--
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-d...@....
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-d...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Troy Sobotka <troy.s...@...>
On Thu, Feb 2, 2017 at 6:55 PM Andrew Wood < andre...@...> wrote: 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
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 via ctlrender. Generate two variants, one for to_reference and one for the from_reference, which would be the to L*a*b* and from L*a*b* respectively, assuming you want to do some work on the image in L*a*b* briefly
- Use ociolutimage --extract --input ctl-rendered.exr --cubesize 65 --maxwidth 4225 --output foobar.spi3d for each of the to and froms.
- Use the transform sparingly when you need to blur the first channel or whatever in your node chain, and get back out. Make sure you use proper shapers on the head and tail to shape and unshape accordingly to optimise your 3D LUTs.
With respect, TJS
|
|
|
FWIW there is an old pull request for a simple expression transform which would have been perfect for this,
On 3 Feb 2017, at 12:36, Sean Cooper < se...@...> wrote: 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 RGB-like are generally ok, so I'm not sure how well fit CIELab transforms are for LUT quantization (though at first glance it feels like fitting a square peg into a round hole).
As per Troy's suggestion, you can't directly implement CTL in OCIO. So he was saying essentially you could do the mathematically faithful forward and inverse transform on a sample image (like Nuke's CMSTestPattern) and from them you could use Nuke's make LUT functionality, to LUT-ize the Lab calculation and THEN put than in OCIO. But I'd test the resulting LUT pretty well as I'd imagine it fails in a number of spots.
--
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.
|
|
|
Andrew Wood <andre...@...>
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 (linear to lab) -> GenerateLUT I hadn't played with ociolutimage before, that's nifty. Unfortunately it just seems too lossy (esp in dark areas) for an unsharpening pass.
On Thursday, February 2, 2017 at 6:19:54 PM UTC-8, dbr/Ben wrote: FWIW there is an old pull request for a simple expression transform which would have been perfect for this, On 3 Feb 2017, at 12:36, Sean Cooper < se...@...> wrote: 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 RGB-like are generally ok, so I'm not sure how well fit CIELab transforms are for LUT quantization (though at first glance it feels like fitting a square peg into a round hole).
As per Troy's suggestion, you can't directly implement CTL in OCIO. So he was saying essentially you could do the mathematically faithful forward and inverse transform on a sample image (like Nuke's CMSTestPattern) and from them you could use Nuke's make LUT functionality, to LUT-ize the Lab calculation and THEN put than in OCIO. But I'd test the resulting LUT pretty well as I'd imagine it fails in a number of spots. On Thu, Feb 2, 2017 at 5:55 PM, Andrew Wood <andr...@...> wrote: 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
On Thursday, February 2, 2017 at 5:16:37 PM UTC-8, Troy James Sobotka wrote: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
On Thu, Feb 2, 2017 at 6:05 PM Andrew Wood < andr...@...> wrote: 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
On Thursday, February 2, 2017 at 2:54:20 PM UTC-8, dbr/Ben wrote:
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 xyz_to_lab.lut)
Sent from my phone On 3 Feb 2017, at 09:03, Andrew Wood < andr...@...> wrote:
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 photoshop in LAB space on just the Lightness channel for some images.
I was hoping to represent this transform using ocio, but so far am at a loss. I can use a MatrixTransform to get to XYZ, but I don't want to use a 3d LUT to get to LAB because it needs to be fully reversible.
Is there some magic that I'm missing, or will I just have to do this in code?
thanks!
Andrew
--
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-d...@....
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-d...@....
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Troy Sobotka <troy.s...@...>
On Thu, Feb 2, 2017, 7:32 PM Andrew Wood < andre...@...> wrote: Unfortunately it just seems too lossy (esp in dark areas) for an unsharpening pass.
That screams bad shaper to me. What are you using for a shaper here?
With respect, TJS
|
|
|
Andrew Wood <andre...@...>
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 explain why its all messed up going back to rgb right afterwards.
But what shaper would even make sense here? My head hurts trying to think about the a*b* components going through a log curve or something. That doesn't really make sense, does it?
On Thursday, February 2, 2017 at 6:41:59 PM UTC-8, Troy James Sobotka wrote:
On Thu, Feb 2, 2017, 7:32 PM Andrew Wood < andr...@...> wrote: Unfortunately it just seems too lossy (esp in dark areas) for an unsharpening pass.
That screams bad shaper to me. What are you using for a shaper here?
With respect, TJS
|
|
|
L* is inherently logarithmic, so perhaps you could use L* it's self as the shaper here. But I think the inherently negative a*b* values will make this effort futile, unless there is an alternative all positive formulation of L*a*b*, but that would be a bit odd.
On Fri, Feb 3, 2017 at 10:52 AM, Andrew Wood <andre...@...> wrote: 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 explain why its all messed up going back to rgb right afterwards. But what shaper would even make sense here? My head hurts trying to think about the a*b* components going through a log curve or something. That doesn't really make sense, does it? On Thursday, February 2, 2017 at 6:41:59 PM UTC-8, Troy James Sobotka wrote:
On Thu, Feb 2, 2017, 7:32 PM Andrew Wood < andr...@...> wrote: Unfortunately it just seems too lossy (esp in dark areas) for an unsharpening pass.
That screams bad shaper to me. What are you using for a shaper here?
With respect, TJS
|
|
|
Troy Sobotka <troy.s...@...>
On Fri, Feb 3, 2017 at 11:52 AM Andrew Wood < andre...@...> wrote: 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 explain why its all messed up going back to rgb right afterwards.
But what shaper would even make sense here? My head hurts trying to think about the a*b* components going through a log curve or something. That doesn't really make sense, does it?
The shaper here would be a purely technological solution, simply helping out interpolation given that your input happens to be imagery. In your CTL, you would assume that you are being fed Log2 values and undo it, then run the L*a*b* according to the proper canonical formula. Even a simple Log2 shaper would probably be more than acceptable I'd speculate, although Mr. Cooper's suggestion might be more on point perhaps given that L* is already nonlinear and uniform, albeit more complex to implement in the CTL.
To fix the negative nature of the a*b* formation, I'd encode them with a uniform offset of 0.5 in much the same way 8 bit cheats encode L*a*b*.
This would spit out a Log2 encoded L*a*b* series of values. Undo the Log2 on the tail end and you end up with pure L*a*b* with a*b* offset. If you really wanted to get fancy, you could run it through a MatrixTransform with an identity, and leverage the offset to reset the a*b* to proper negatives. Perhaps even an ExponentTransform or LogTransform etc. could be used to cheat that as well. Sean?
With respect, TJS
|
|
|
The conversion from XYZ to CIELab can be done with matrices and 1d-LUTs, so you should be able to do the forward and reverse quite exactly with the existing machinery and without resorting to 3d-LUTs.
(Of course CIELab is only appropriate for display-referred colors, but that is a separate issue.)
Doug Walker
|
|
|
Troy Sobotka <troy.s...@...>
Whilst stranded in an airport...
No assurances expressed or implied. Seems the values are darn close to Lindbloom's, which may account for a different value for Illuminant C adaptation via Bradford.
With respect, TJS
On Sat, Feb 4, 2017 at 11:58 AM doug < colo...@...> wrote: The conversion from XYZ to CIELab can be done with matrices and 1d-LUTs, so you should be able to do the forward and reverse quite exactly with the existing machinery and without resorting to 3d-LUTs.
(Of course CIELab is only appropriate for display-referred colors, but that is a separate issue.)
Doug Walker
--
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.
|
|
|
Doesn't really answer your question (sorry) but.... On Transformers the director wanted sharper cg robots! so we had a sharpen shootout. The joint winners were either LAB or Log, unshapen masks.i.e. the difference between artifacts when filtering it in L*AB or log was very minimal. It might be easier for your PS artists to use a lut rather than a RGB>LAB transform? On Sunday, 5 February 2017 06:13:36 UTC, Troy James Sobotka wrote: Whilst stranded in an airport...
No assurances expressed or implied. Seems the values are darn close to Lindbloom's, which may account for a different value for Illuminant C adaptation via Bradford.
With respect, TJS
On Sat, Feb 4, 2017 at 11:58 AM doug < col...@...> wrote: The conversion from XYZ to CIELab can be done with matrices and 1d-LUTs, so you should be able to do the forward and reverse quite exactly with the existing machinery and without resorting to 3d-LUTs.
(Of course CIELab is only appropriate for display-referred colors, but that is a separate issue.)
Doug Walker
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ahead of our New York launch, Finish and Realise Studios are now Freefolk. Please update the email address you have for me.
 +44 (0)20 7734 9110
140 Wardour Street, London W1F 8ZT
|
|
|
Andrew Wood <andre...@...>
You all are my heros. I had gotten so caught up in the XYZ to LAB calculation that I didn't notice it could be reduced to a 1d LUT and simple matrix.
Troy, I was looking through your (amazing) example, and the only part that I didn't recognize was the matrix you used to go from RGB to XYZ based on srgb d65 primaries. I usually steal my matrices from Bruce Almighty:
http://www.brucelindbloom.com/Eqn_RGB_XYZ_Matrix.html
but yours looks a little different from this one. What is it based on?
On Saturday, February 4, 2017 at 10:13:36 PM UTC-8, Troy James Sobotka wrote: Whilst stranded in an airport...
No assurances expressed or implied. Seems the values are darn close to Lindbloom's, which may account for a different value for Illuminant C adaptation via Bradford.
With respect, TJS
On Sat, Feb 4, 2017 at 11:58 AM doug < col...@...> wrote: The conversion from XYZ to CIELab can be done with matrices and 1d-LUTs, so you should be able to do the forward and reverse quite exactly with the existing machinery and without resorting to 3d-LUTs.
(Of course CIELab is only appropriate for display-referred colors, but that is a separate issue.)
Doug Walker
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Troy Sobotka <troy.s...@...>
> Troy, I was looking through your (amazing) example, and the only part that I didn't recognize was the matrix you used to go from RGB to XYZ based on srgb d65 primaries.
I didn't do much other than read Doug's post and force myself to re-read the CIE L*a*b* formula.
The matrices to XYZ are Illuminant C adapted from D65. Feel free to replace that component as required.
With respect, TJS
|
|
|
Andrew Wood <andre...@...>
Cool, that's what I thought. Just making sure you hadn't snuck anything else in there I hadn't noticed!
And yeah re: LAB space vs Log space for doing the actual sharpen --that's an interesting idea I'll have to look into that more for sure. I know that wide gamut devices will be here soon and we really can't be going off into l*a*b* and back to do this stuff. I'm starting with pipeline parity with what we do today, but I know there will be a whole bunch work to go back and move all of this to an aces workflow someday, and there's no room for this nonsense there.
On Monday, February 6, 2017 at 1:42:27 PM UTC-8, Troy James Sobotka wrote: > Troy, I was looking through your (amazing) example, and the only part that I didn't recognize was the matrix you used to go from RGB to XYZ based on srgb d65 primaries.
I didn't do much other than read Doug's post and force myself to re-read the CIE L*a*b* formula.
The matrices to XYZ are Illuminant C adapted from D65. Feel free to replace that component as required.
With respect, TJS
|
|
|
