Hi All,

I'm currently writing a LUT to go from S-Log to Rec709. I've got the
transfer functions for both and generally the curves I've plotted look
like what I expect, but one part of the formula is bothering me. The
t in the S-Log whitepaper from Sony (camera Sony - not
imageworks) says t ranges from 0 to 109%.

So I've been trying to ascertain whether this means in 10bit (for
example) that 1023 should be 1.09 or whether it should be 1.

A section of the whitepaper shows examples of converting between
10bit S-Log and 14bit linear. It just has some magic numbers in
there and I've been trying to nail down exactly how they're calculated
in order to answer the 1 vs 1.09 question. Though while I can step
kinda close to it I've not just hit exact. So I'm hoping someone here
can shed some light on this.

Cheers,

Alan.

Hi all,

The example config doesn't appear to have the required luma
attributes. Could someone let me know what and where they should be?

Also is there any documentation around or should I just run doxygen
over the source?

Cheers,

Alan

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...@...> 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

Hi,

I would like to write tests for the work that I do.

What unit test framework are you planning on using, as I guess it adds another
dependancy. I have gotten used to using the boost framework but I'm sure you
have something else planned.

.malcolm

Agreed.  The issue isn't how to do the conversion, it is how to
determine the input arguments.

But OCIO has this problem anyway.  There is no definition for how a
given image can help influence what conversion is used.  In a
commercial tool, the conversion is chosen by the user, where the list
of options is everything in the config.

OCIO has routines to do a conversion if the "conversion name" is
provided.  OCIO could easily have routines to do conversions if the
gamma-matrix-gamma is provided.  Either way, commercial tools have to
decide if the conversion hints come from the user, the filename, the
header, the environment, or whatever.

RGB



On Sat, Jun 26, 2010 at 5:19 PM, Jeremy Selan <jeremy...@...> wrote:

I thought of a simpler way to summarize the topic:

In dynamic colorspaces, the color transforms are dependent upon a set
of potentially changing input arguments.

Our ideal solution is one where the input argument handing is
standardized so that OCIO can be supported out of the box in
commercial tools. But, the logic that interprets input arguments would
be structured to allow the use of facility-specific code and
conventions.

-- Jeremy