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
re-read Poynton's Digital Video.

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-
Log_001_IO_EN.pdf)  (google search: sony slog)

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.