Re: [ocs-dev] Re: The S-Log formula

Alan Jones <sky...@...>

Hi Jeremy,

On Thu, Aug 12, 2010 at 12:01 PM, Jeremy Selan <jeremy...@...> wrote:
Ah, when you read Sony Camera documents you often have to put on your
"video engineer" goggles. :)
Indeed - I'm still pretty fresh to dealing with this stuff so directly. Time to

Which camera are you using?  We've done a few Sony camera
characterizations, and may have real data for the camera you're
interested in.  F35, perhaps?
Yes - the F35 :)

In my experience, if you have the
luxury of actually running exposure sweeps on a camera you tend to get
much more plausible linearizations than by obeying manufacturer
claims.
Anywhere you could point me to for reading up on doing this and using it
to generate LUTs?

Sometimes it's a communication issue, but more often the
documentation fails to discriminate between the transform to get to a
scene referred linear (input space) vs an output referred linear
(display space).
Yeah - I've taken the formula as being input space and then applying
linear to rec709 to the result in order to generate the slog to rec709
LUT.

Are you referring to this document for the formulas?  (SRW_ITG_S-
Yes.

Assuming we trust the document for the moment, I think the rule of
thumb is understanding that whenever these guys talk about numbers
that include percentages (such as 0%, or 109%), these are video folks
talking in IRE land. (Ugh!)
Ahhhh - thanks :)

So when the document says "t has a range of 0 to 1.09", I take this to
mean that you're expected to have input 10-bit codevalues from 64 -
1023.
code 64 = t 0.0
code 1023 = t 1.09
Perfect :)

In the later example "S-Log Formula" this is already taken into
account for you.
Y = 379.044 * log10(((x-128)/1752 + 0.037584) + 630
(This assumes 10-bit input, which in practice will only contain values
from 3-1019 due to HD link peculiarities, which you can safely ignore
in this case).
I'm still trying to figure out where some of these values come from. The
1752 is Reference white minus Black level and the 128 is black level.
Though the 379.044 and 630 are still mysteries to me. I've tried dividing
them by the equivalent part of the formula (though I've been using anti
s-log to work on this rather than s-log, but same numbers anyway) and
the resulting numbers don't have any easily identifiable correlation with
either the input or output spaces.

I'd love to know how those are calculated as at the moment I can get my
results close when trying to find a generic way to deal with the formula
(so I can make it for an arbitrary bit depth), but not exact.

Cheers,

Alan.

Re: The S-Log formula

Jeremy Selan <jeremy...@...>

Ah, when you read Sony Camera documents you often have to put on your
"video engineer" goggles. :)

Which camera are you using? We've done a few Sony camera
characterizations, and may have real data for the camera you're
interested in. F35, perhaps? In my experience, if you have the
luxury of actually running exposure sweeps on a camera you tend to get
much more plausible linearizations than by obeying manufacturer
claims. Sometimes it's a communication issue, but more often the
documentation fails to discriminate between the transform to get to a
scene referred linear (input space) vs an output referred linear
(display space).

Are you referring to this document for the formulas? (SRW_ITG_S-

Assuming we trust the document for the moment, I think the rule of
thumb is understanding that whenever these guys talk about numbers
that include percentages (such as 0%, or 109%), these are video folks
talking in IRE land. (Ugh!) In the world of broadcast HD television
and safe white is 940/1023. Thus for folks in a broadcast-land
mindset, if you use the full 10-bit code range you're 'over white' by
(1023 / 940) = 1.09.

So when the document says "t has a range of 0 to 1.09", I take this to
mean that you're expected to have input 10-bit codevalues from 64 -
1023.
code 64 = t 0.0
code 1023 = t 1.09

In the later example "S-Log Formula" this is already taken into
account for you.
Y = 379.044 * log10(((x-128)/1752 + 0.037584) + 630
(This assumes 10-bit input, which in practice will only contain values
from 3-1019 due to HD link peculiarities, which you can safely ignore
in this case).

-- Jeremy

On Aug 12, 9:07 am, Alan Jones <sky...@...> wrote:
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.

LUT Plugin API

Alan Jones <sky...@...>

Hi All,

I was thinking it'd be neat if OCIO provided an API for plugin LUTs
(i.e. libraries that perform a LUT - they could use formula or whatever
internally without any restrictions on syntax, outside of C++ of
course). Making the API SIMD compatible could also be worth
considering.

I thought this may have some benefits over a straight formula syntax
support. Particularly not requiring a syntax, the ability to use any
library out there, also would make it simple for someone to offload
to GPU and use built-in LUT support on those.

I'm thinking it'd still be referenced by an xml config the same as all
the others - just the source instead of myspace.lut would be
myspace.so

Cheers,

Alan.

The S-Log formula

Alan Jones <sky...@...>

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.

OCIO 0.5.11 posted

Jeremy Selan <jeremy...@...>

This is a relatively minor update.

Version 0.5.11 (Aug 11 2010):
* DisplayTransform API
* ASC CDL Support

Available on github, and as a .tgz on google code.

Most important is that I've recently been stuck with writer's block
(coder's block?) on how to generalize the DisplayTransform code, and
this gets us over the hump. Full GPU support should now be just around
the corner. (Feel free to place bets on the check-in date.)

... and I haven't forgotten about the FAQ and documentation either!

-- Jeremy

Re: Luma attr error checking

Jeremy Selan <jeremy...@...>

I'm currently working on writing a quicktime generator using OpenImageIO,
OpenColorIO, libquicktime and Qt.
Cool! That sounds like a really good use case.

On our medium term list is to build a bridge between OIIO and OCIO, so
you can use OIIO's command-line utilities to do color conversions.
But I wouldnt want to promise a date for that, and hooking em up
yourself shouldnt be too hard.

I'd like to check that I'm correctly understanding OpenColorIO's intention.

Is it intended that it will handle the color transforms and that those
transforms
will be stored in it's own XML based format?
Yes, exactly.

The XML configuration file (.ocio) is super light-weight. All the
heavy data (1D LUTs, 3D LUTs) are references to other existing files
(which remain in their native formats). Also, you don't have to hand-
craft the XML. You can use the OCIO API to build configurations, see
src/testbed/main.py for an example.

There's also talk of making an ocio "bundle" for easy distribution
(which would be the .ocio xml file + the luts directory), but I havent
tackled this yet.

If so, would it be within the scope of the project to build importers
and exporters that for various formats? I'm thinking of cases where
I want to bring in a LUT to apply to footage or when I want to supply
a LUT from OpenImageIO to another application.
Very much so! What LUT formats do you need support for? Let's get em
in there.

At some point soon I'll add an ocio command-line utility that will do
LUT transcoding - which along with support for more luit formats -
should be a really popular option.

-- Jeremy

Re: [ocs-dev] Re: Luma attr error checking

Alan Jones <sky...@...>

Hi Jeremy,

On Thu, Aug 5, 2010 at 4:16 PM, Jeremy Selan <jeremy...@...> wrote:
Good catch.  I've updated the git repo and the downloads site (
configs will work with the latest trunk release.
Thanks - it's running happily now.

Unfortunately, I'm also a bit behind in the publishing the docs. (I
have a version internally, but they're a but out of date).  I'll do my
best to repost them all within a day or two.
I'm currently working on writing a quicktime generator using OpenImageIO,
OpenColorIO, libquicktime and Qt.

I'd like to check that I'm correctly understanding OpenColorIO's intention.

Is it intended that it will handle the color transforms and that those
transforms
will be stored in it's own XML based format?

If so, would it be within the scope of the project to build importers
and exporters that for various formats? I'm thinking of cases where
I want to bring in a LUT to apply to footage or when I want to supply
a LUT from OpenImageIO to another application.

Of course, in the next few months I'd like the library to be entirely
self documenting (doxygen), and if anyone would like to help get the
ball rolling, i'd be very appreciative. (i'm happy to write them all,
I just dont have doxygen formatting / makefile experience).
I can probably throw in with the doxygen style comments - they're
pretty easy so if you're cool with me passing some dumb questions
(like the ones above) I'd be happy to help out ther.

I'd also like to have the color profiles be self documenting. (I
picture a command-line tool that will load a config, and generate an
html page outlining its use, options, etc).
That sounds like a fantastic idea - LUT formats don't seem to have
info needed to really know how to use them. Like what stage they're
intended for, the direction of the transform, whether the user will want
to offset/multiply/whatever afterward.

Cheers,

Alan.

Re: Luma attr error checking

Jeremy Selan <jeremy...@...>

Alan,

Good catch. I've updated the git repo and the downloads site (
configs will work with the latest trunk release.

Unfortunately, I'm also a bit behind in the publishing the docs. (I
have a version internally, but they're a but out of date). I'll do my
best to repost them all within a day or two.

Of course, in the next few months I'd like the library to be entirely
self documenting (doxygen), and if anyone would like to help get the
ball rolling, i'd be very appreciative. (i'm happy to write them all,
I just dont have doxygen formatting / makefile experience).

I'd also like to have the color profiles be self documenting. (I
picture a command-line tool that will load a config, and generate an
html page outlining its use, options, etc).

-- Jeremy

On Aug 5, 12:25 pm, Alan Jones <sky...@...> wrote:
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

Luma attr error checking

Alan Jones <sky...@...>

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

Birds of Feather Tomorrow (wed)

Jeremy Selan <jeremy...@...>

It was great seeing some of you at today's Siggraph class!

If anyone is interested in more detailed info (or just wants to say
hello in person) we'll be having a BOF tomorrow. Hope to see some of
you there!

Birds of a Feather : OpenColorIO
WEDNESDAY, 28 JULY | 2:30 PM - 3:30 PM | ROOM 506

Cheers,
Jeremy

Re: Supporting 1D luts which are different per channel

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

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

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

Re: [ocs-dev] Unit Tests

Larry Gritz <l...@...>

I've been using that lately on OIIO and OSL, and for our simple needs it works just fine. Also nice because if you're already using Boost for anything else, you can use its unit tests without adding any new dependencies.

-- lg

On Jul 21, 2010, at 8:57 AM, Jeremy Selan wrote:

-- Jeremy

On Wed, Jul 21, 2010 at 7:31 AM, Bruno Nicoletti
<bruno.j....@...> wrote:
We use boost's unit test suite here as well, a few quibbles but it
works fairly well.

b

On 21 July 2010 15:23, Malcolm Humphreys <malcolmh...@...> wrote:
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

--
Bruno Nicoletti
--
Larry Gritz
l...@...

Re: [ocs-dev] Unit Tests

Jeremy Selan <jeremy...@...>

-- Jeremy

On Wed, Jul 21, 2010 at 7:31 AM, Bruno Nicoletti
<bruno.j....@...> wrote:
We use boost's unit test suite here as well, a few quibbles but it
works fairly well.

b

On 21 July 2010 15:23, Malcolm Humphreys <malcolmh...@...> wrote:
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

--
Bruno Nicoletti

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

Jeremy Selan <jeremy...@...>

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

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

Re: [ocs-dev] Unit Tests

Bruno Nicoletti <bruno.j....@...>

We use boost's unit test suite here as well, a few quibbles but it
works fairly well.

b

On 21 July 2010 15:23, Malcolm Humphreys <malcolmh...@...> wrote:
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
--
Bruno Nicoletti

Unit Tests

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

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

Supporting 1D luts which are different per channel

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

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

OCIO @ Siggraph

Jeremy Selan <jeremy...@...>

Friends,

So Siggraph is just around the corner, which means OpenColorIO is
going public! Both this google group, as well as the git repo are
now completely open to all.

If you're attending Siggraph, please come check us out:

Course: Color Enhancement and Rendering in Film and Game Production
TUESDAY, 27 JULY | 9:00 AM - 12:15 PM | ROOM 502 A
(my presentation time is tentatively 9:55 - 10:15, a portion of which
i'll use to introduce OpenColorIO).

Birds of a Feather : OpenColorIO
WEDNESDAY, 28 JULY | 2:30 PM - 3:30 PM | ROOM 506
integration schedule.

Imageworks will also have an official OCIO press-release on Monday.

If you're not able to make either of these, but are still interested
flexible, and I'd love to meet everyone interested in this subject.

Also - not related to OCIO - but for those interested in open source
projects I'd highly recommend checking out:
Panel: Large Steps Toward Open Source
THURSDAY, 29 JULY | 9:00 AM - 10:30 AM | ROOM 408 AB
The speaker are excellent, representing such graphics projects as OSL,
Alembic, OpenEXR, PTex, etc.

Cheers,
Jeremy

Re: Dynamic color configuration

srluka <srl...@...>

I view these as two separate problems. One is gathering color
information. The other is performing color transforms. OCIO seems to
be focused on the latter. I would like to see the OCIO API stay open
enough to where we can use its color transform capability outside the
confines of a fixed color pipeline. The hybrid approach Jeremy
described may be just what we are looking for.

Another thing I would like to maintain the option for, and that was
hinted at in Jeremy's first response, is different mappings between
color spaces. As an example, when converting two RGB spaces with
different white points you have the option of preserving absolute
colorimetry or performing some form of chromatic adaptation. With a
static configuration, it seems like you have to pick one or the other
since each half of the conversion is built into the color space
definition. So you either have a chromatically adapted workflow, or
you don't. Also, it's a little weird in the sense that the chromatic
adaptation (if you were to use it) would have to be already built into
each colorspace definition (ICC D50 anyone? or maybe you would prefer
ACES D60?) but it may not be explicitly stated. I think this may be
problematic so long as the colorspaces define the halfway conversion
to the reference ("linear") space. There may need to be some
additional option for defining the connection space if we expect to
use anything other than a straightforward colorimetric transform.

On Jun 28, 10:44 am, Rod Bogart <bog...@...> wrote:
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

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

ocio 0.5.9 posted

Jeremy Selan <jeremy...@...>

Version 0.5.9 (June 28 2010):
* Renamed project, classes, namespaces to OpenColorIO (OCIO)