|
Re: reversable, but not 1D color transforms in config.ocio
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
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
Re: reversable, but not 1D color transforms in config.ocio
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.
|
|
|
reversable, but not 1D color transforms in config.ocio
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
|
|
|
Re: icc profile for photoshop
Alexander Forsythe <alexfo...@...>
Jack Holm had identified a number of issues with the ICC profiles and was willing to help correct them.
Alex
On Sat, Jan 28, 2017 at 7:42 AM, Haarm-Pieter Duiker <li...@...> wrote: 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+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...@...>
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....@...>
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
|
|
|
