ASC-CDL compliant adjustments and reference colorspace

that, the multiple references to “scene referred data”, and the fact that all the illustrative plots are in linear scale…

@Elle @agriggio here is some more math for your pleasure… :wink:

we have already seen that this chain of operations

linear RGB -> log2 RGB -> log2 RGB + offset -> linear RGB

is in fact equivalent to a simple scaling of the linear RGB values.

In fact, the properties of log functions are such that this other chain of operations

linear RGB -> log2 RGB -> (log2 RGB) * C -> linear RGB

is equivalent to

(linear RGB)^C

or in other words a linear scaling of the log2-encoded data is equivalent to a power function in linear RGB. This is because

x = 2^(log2(x))
2^(log2(x^c)) = x^c = (2^(log2(x)))^c = 2^(c * log2(x))

Hence

log2( x^c ) = c * log2(x)

There is therefore a very clear and direct relationship between CDL operations in linear and log2 encoding:

  • offset in log2 encoding → slope in linear encoding
  • slope in log2 encoding → power in linear encoding

However, there is I think now simple log2 equivalent of the offset in linear encoding. Moreover, power in log2 encoding does not correspond to any simple expression in linear encoding.

All-in-all, I am even more convinced that those CDL operations should be applied to linear RGB data.

Next question is: which RGB primaries should be used? A very wide colorspace like ACES, or a more narrow one like Rec.2020 or ACEScg?

@Carmelo_DrRaw - thanks! for posting above - I was wondering about what might be equivalent to what. The Wikipedia article says nine operations, slope/offset/power applied to each channel individually. I’m feeling very mathematically stupid at the moment, worse than usual! So is below correct?

  • Multiply/divide by a color (including gray):
    offset in log2 encoding ↔ slope in linear encoding

  • Add/subtract a color (including gray):
    offset in linear encoding → ??? in log2 encoding

  • Raise each channel to a (same or different per channel) power:
    slope in log2 encoding ↔ power in linear encoding

  • power in log2 encoding → ??? in linear encoding
    What does raising to a power in log2 do to the image? Similarly to linear but affecting different intensities by different amounts?

Also, the Wikipedia article says “out = ((in times slope) plus offset) raised to the power”. So assuming my verbal descriptions of each operation are correct, in linear RGB the result is multiply/divide by a color (aka change white balance), then add/subtract a second color, then raise the resulting channel values to the specified per-channel power for each channel?

Do you remember that email conversation we had regarding the effect of applying a gamma correction differentially affecting each RGB channel? Identity produced horrible results. I seem to recall ACES wasn’t much better. ACEScg or Rec.2020 would be better simply because of the primaries. Or user choice, depending on what standard(s) you might want to follow.

Edit: Speaking of standards, this page with the indicated search terms:

http://catalog.oscars.org/vwebv/search?searchArg=guide+to+digital+imaging&searchCode=GKEY^&limitTo=none&recCount=50&searchType=1&page.search.search.button=Search

brings up this book:

http://catalog.oscars.org/vwebv/holdingsInfo?searchId=9&recCount=50&recPointer=2&bibId=101887
The filmmaker’s guide to digital imaging : for cinematographers, digital imaging technicians, and camera assistants / Blain Brown.

which

covers new industry-wide production standards such as ASC-CDL and the ACES workflow.

My old Firefox browser doesn’t seem to show a button to show the table of contents. But I think when looking at the page using a newer version of Firefox, there was an entire chapter on ASC-CDL. FWIW, not sure if the book is available outside ASC channels. Oh, wait, here it is on Amazon so maybe libraries also might have a copy:

The handful of Amazon reviews are pretty funny. Maybe sending off to the ASC is the best way to get the actual equations and suggested color space encoding and primaries.

Oh heavens. Now I’m passing on information from Troy. I do wish he’d rejoin the forum and just change his methods of argument and discussion.

It does seem that linear or log are both OK to use, based on perusing what looks like totally reliable documentation. When used on log encoding, that offset thingy has to do with something called “printer points” that I seem to vaguely recall might be discussed in the ACES primer.

If I see anything about the actual primaries, I’ll add to this post - nope, no mention of any color space except Rec709 as far as I can tell.

Also see this link that Troy provided:
https://github.com/imageworks/OpenColorIO/issues/407

@troy_s who isn’t here anymore - did I miss anything that should be posted here? I haven’t looked at the actual equations, but hopefully you also sent/will send appropriate information to @Carmelo_DrRaw.

I haven’t been reading up on this topic or having a sharp mind for the past few months, so again my thoughts will be of the general and vague variety.

1. If you haven’t already, perhaps becoming involved in the discussions at acescentral.com, which has already been linked to several times, would be your best bet. Troy isn’t the only one with whom you could engage.

2. About log2(): just as jerk is the rate of change of acceleration, there are probably lower and higher orders of math for offset and power. I wonder whether offset could be embedded into the transforms… People from the OCIO camp seem to like their transforms a lot more than ICC adherents do with assign or convert. :stuck_out_tongue:

Awesomely good idea - even just the general conversations are interesting.

Hmm, you might be right, I don’t know. But I dare say or at least hope the people using OCIO have taken the time to understand what their LUT transforms actually do. Whereas it seems a fairly significant number of people using ICC profile color management just assume there’s nothing to learn, not even the absolutely basic difference between assign and convert.

Anyone who thinks using OCIO is simple, and your monitor isn’t calibrated to sRGB and you aren’t editing in sRGB, well, that’s the first hurdle - you need a LUT connecting your RGB working space to your monitor profile, which profile you almost certainly made using ICC profile tools.

The second hurdle is when you want to switch to a different monitor or you update the calibration and profile for your old monitor, now you have to make a new LUT connecting your new monitor profile to your old working space. And if you change your working space, you need yes, again a new LUT connecting your new working space to your new monitor profile.

FWIW, I think OCIO is really cool. But so far OCIO software doesn’t seem to offer anything that personally I need in my image processing workflow. If ever there comes a time when I find an “OCIO only” tool that I absolutely must have in my imaging toolbox, I’ll dust off that nice tutorial that Troy wrote, that I followed a long time ago, and set up some LUTS and some configuration files.

Oh, did I mention the configuration files? If you want to use OCIO, you have to have those files. And even with Troy and another person very experienced in using OCIO lending a helping hand, setting up the config file wasn’t easy for me to do, and I’m guessing a lot of people might find the task equally daunting.

Of course if you only edit sRGB images and you assume your monitor really is an sRGB monitor (maybe those Apple monitors Troy mentioned in another thread?), then there are default config files to help you on your way. But the same holds true when using ICC profile color management - just select sRGB for your monitor profile and also for your RGB working space and away you go. Equally simple. And if you decide to make a real monitor profile, just change the monitor profile from sRGB to the actual monitor profile, no need to mess with making a new LUT linking new monitor profile to old RGB working space. Likewise with changing RGB working spaces. That ICC PCS (profile connection space) is a very handy thing to have.

Yes, when I said “transforms”, I meant “transforms, luts and configs”. Without all these supporting files, the next team would not know what to do with the data. There is definitely more to keep track of. I can’t wait to see what you all discover about ACES. (Sorry about bringing in OCIO so frequently. I know that that is off-topic but I suppose that that is the community that works with ACES the most.)