Re: [ocs-dev] Re: Supporting 1D luts which are different per channel


Malcolm Humphreys <malcolmh...@...>
 

Hi,

Just looking at this again, one thing we didn't cover was a prelut which has non-uniform spaced points (scattered). Would you see this as support we would need to add to the Lut1DOp or would this end up being a different op type.

This is a simple example from the csp spec.
--snip--
Map extended input (max. 4.0) into top 10% of LUT

11
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4.0
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
11
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4.0
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
11
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 4.0
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
--snip--

A more complex example could be
--snip--
11
0.0 0.1 0.2 0.3 0.4 0.45 0.5 0.8 0.85 1.0 4.0
0.0 0.1 0.2 0.3 0.4 0.5 0.55 0.6 0.7 0.9 1.0
--snip--

.malcolm

On 22/07/2010, at 12:39 PM, Malcolm Humphreys wrote:

Hi Jeremy,

oops never mind looks like it will support it.

Yep it all looks ok to me, just really feel like spliting out the
non-core stuff into a plugin or similar dir.

For now I think nearest iterp is fine as we normally have enough
points for 10bits in all channels, we have used Catmull-Rom in
the past. As we will be only using this for viewing scene linear it
should be ok in the short term.

I don't need 4 channel luts, but other people might.

.malcolm

On Jul 22, 1:53 am, Jeremy Selan <jeremy...@gmail.com> wrote:
Malcolm,

I believe the 1D lut op does allow for a different number of entries
per channel.
If we look at src/core/Lut1DOp.h,

you'll see the entry for each color channel lut is stored in an
individual vector: fv_t luts[3].
So in your loading code (if we hardcoded the sizes used in your example),

lut1d->luts[0].resize(11);
lut1d->luts[1].resize(6);
lut1d->luts[2].resize(6);

Does the rest of the Format loading code make sense to you? All your
work should be in a single file, a la FileFormat3DL.

A few additional questions for you:

* Currently, OCIO only support linear and nearest interpolation for 1D
luts. If the examples you've given are typical (where the 1d lut is
size 6) I couldnt imagine linear interpolation would suffice, and I'd
also imagine that the interpolation type chosen would highly influence
the resulting image. Does CSP dictate the interpolation type? What
type would you prefer? I have no problem adding higher types (cubic,
etc) I just hadnt had the need to yet. (Note that the .3dl shaper 1D
lut also has this issue (it's often size 17), I just hadnt tackled it
yet.)

* Do you care about 4 channel luts? (I.e., changing alpha) We've
never needed this at SPI, which is why the OCIO currently assumes 3
channels, but if other people think its important for completeness
sake Im open to it.

-- Jeremy

On Wed, Jul 21, 2010 at 6:11 AM, Malcolm Humphreys

<malcolmh...@mac.com> wrote:
Hi,
I started looking at adding csp lut format to ocio.
A csp lut allows a 1D prelut with a different number of points per channel. The
current Lut1DOp only supports applying the same 1D lut to all channels.
I'm wondering if this is something you were thinking of supporting in ocio?
--snip--
Access LUT data via a gamma lookup
Red channel has gamma 2.0
Green channel has gamma 3.0 but also has fewer points
Blue channel has gamma 2.0 but also has fewer points
11
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
0.0 0.01 0.04 0.09 0.16 0.25 0.36 0.49 0.64 0.81 1.0
6
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.008 0.064 0.216 0.512 1.0
6
0.0 0.2 0.4 0.6 0.8 1.0
0.0 0.04 0.16 0.36 0.64 1.0
--snip--
.malcolm

Join ocio-dev@lists.aswf.io to automatically receive all group messages.