camera log flavors and spi-anim

[Derek Flood]

Reading this in Jeremy's paper:

"Not all “log” spaces are equal. Most camera manufacturers customize a log encoding equation to optimize the usage of code values based on the camera’s dynamic range, noise characteristics, and clipping behavior. Examples of different log spaces include Sony S-Log, RED’s REDLog, Arri LogC, and the classic Cineon. Care must be taken during image handling to determine which log space is associated with imagery, and to use the proper linearization. If this metadata is lost, it is often challenging to determine after the fact which log flavor was using in encoding."

However, unless I am mistaken, spi-anim uses one log to linear conversion (the lg* space) for all cameras. I'm hoping someone might be able to explain the logic of this to me. Thanks.

[Dithermaster]

spi-anim doesn't directly support any of the specific log spaces you listed; you would need to convert those into a mathematical linear or log space to use in spi-anim. The curve is not your only issue; most of those camera-specific color space use primaries that are different too (e.g., S-Gamut) and that would need to be converted too. It is possible to use OCIO for all of those conversions, but you need to create a config that can do it.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Derek Flood]

Yes, I understand what would be involved in changing the config if desired. I was just curious as to the reasoning behind not including these camera specific log encoding in the spi-vfx config in the first place. I know a lot of thought went into it and SPI, and was wanting to better understand the thinking here in light of Jeremy's comments in the OP. I'm sure it was not an oversight.

To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+...@googlegroups.com.

[Derek Flood]

Also to clarify, I meant to say spi-vfx rather than spi-anim.

[Troy Sobotka]

On Sun, Jul 16, 2017 at 12:22 PM Derek Flood <dere...@gmail.com> wrote:

Yes, I understand what would be involved in changing the config if desired. I was just curious as to the reasoning behind not including these camera specific log encoding in the spi-vfx config in the first place. I know a lot of thought went into it and SPI, and was wanting to better understand the thinking here in light of Jeremy's comments in the OP. I'm sure it was not an oversight.

Because there are literally a potentially infinite number of log-like spaces out there in the wild. Everything from ACEScc, SLog1, SLog2, SLog3, Josh Pines Log, Arri LogC, Panasonic's VLog, Canon's CLog1, CLog2, CLog3, to... you get the idea.

Camera log-like encodings are designed to maximize the encoded values based on hardware and other considerations. Generic Log2 and such are used to encode values uniformly across a perceptual-like distribution.

With respect,

TJS 

[Deke Kincaid]

I believe SPI configs were examples to help people figure out how to use and configure ocio for their studio.  They were not made for wholesale use.  I think those examples are at least 8+ years old and I'm sure a lot has changed at Sony since then.

Once you start adding native camera formats you have to start dealing with camera primaries which opens a whole other can of worms and could render a example very confusing.  ACES makes this easier but pre-ACES this was a landmine of options.

--

[Derek Flood]

Thanks Troy and Deke, that's helpful.

So the way that spi-vfx works is by doing a generic log to lin conversion for footage, and then having a film emulation curve on the display transform. While some camera log encoding are just a log to lin conversion (RedLogFilm for example), many include a film emulation curve along with the lin to log (Arri, S-log3, etc.). It would of course make no sense to have two film emulation curves applied.

As far as I know, while RED does, other camera manufacturers like Arri or Sony don't supply a log encoding separate from their film emulation. Please correct me if that is wrong.

Nuke-default has no film emulation curve on the display transform, and so the camera specific log to lin + film emulation color spaces work fine (i.e. they are not doubled).

I'd be curious to understand how ACES handles this. Does ACES not apply a film emulation curve on the display transform?

On Sunday, July 16, 2017 at 12:04:10 AM UTC-7, Derek Flood wrote:

[Deke Kincaid]

RedLogFilm may be a straight cineon log2lin but that still leaves you in the primaries you set the decode colorspace to reddragon1/2, etc...  Same with any other cameras log curve.  If you are working with more then one camera type(who isn't these days) or even photographs from on set you still want to decide on a single set or primaries and bring all media into that when you linearize the footage and bake to EXR.

Acescg itself it a pretty good set of primaries which for the most part encapsulates most other camera primaries.  There are some very saturated colors Alexa wide gamut can capture which is outside Acescg but it tends to be rare.  The nice thing is they include a large number of IDT's for the major cameras these days.  If not you can usually talk to the manufacturer and get ahold of a log2lin formula or lut and a matrix which will do the conversion.

--

[Derek Flood]

Deke can you say a bit more about primaries. I'm not familiar with that. Is that something ACES has that the spi* configs do not?

[Troy Sobotka]

On Tue, Jul 18, 2017, 6:19 AM Derek Flood, <dere...@gmail.com> wrote:

Deke can you say a bit more about primaries. I'm not familiar with that. Is that something ACES has that the spi* configs do not?

To save Deke...

Primaries are the colour of the basis lights for RGB.

RGB is a relative encoding system that communicate intensities according to some scale, but it does not communicate the basis colours for each of the lights.

With respect,

TJS

[Deke Kincaid]

Look at slides 11-19 for a visual representation within the locus.

https://www.slideshare.net/hpduiker/acescg-a-common-color-encoding-for-visual-effects-applications

--

You received this message because you are subscribed to the Google Groups "OpenColorIO Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ocio-users+unsubscribe@googlegroups.com.

[Derek Flood]

Very helpful, thanks!