Investigate merging codebase or functionality of "ColorPipe-tools" in "Colour" or dependent repository.

[KelSolaar]

This is something I had in mind since Colour was born, @mfe & Mikros Image have created ColorPipe-tools a while back and as we discussed it again with @mfe today, Colour does not have LUT plotting capabilities, or much LUT related capabilities at all. @nick-shaw and I also talked about various LUT interpolation capabilities. I'm taking that opportunity to bump the priority of all that and maybe hear what people think about having either Colour extended with support for various LUT operations or probably better creating a new dependent repository.

[zachlewis]

Well, I'd really, really love to see this...

[KelSolaar]

@zachlewis : Do you have in mind precise capabilities you would like to see?

[zachlewis]

Woah -- sorry about that, I hadn't realized I actually posted that -- that's pretty useless feedback on its own :) (this is actually, i guess, the first line of a muuuch longer response I started writing two weeks ago, that I decided was better placed elsewhere).

I have a few different ways to answer this -- some practical, some hypothetical, some philosophical... but I'll try to keep this short

LUT Generation stuff

• a quick-n-dirty way of sampling transfer functions and writing 1D Luts. At work, I wrote a thing to spit out spi1ds (and, similarly, .spimtx files for npms / gamut transforms); and those are used for things like OCIO config generation and a custom drop-in replacement for Nuke's ColorSpace node... .spi1d / .spimtx / .spi3d luts are all sufficient for our OCIO needs, obviously, and we've written stuff to convert to other formats from there (mostly IRIDAS .Cube / .3dl flavors / csp / a couple of proprietary formats)...

• it would be interesting to working with CLF and maybe leverage some of the work HP has done; on one hand, dealing with complex processes involving multiple ordered transforms might be outside the scope of Colour; but on the other hand, it might be worth considering creating a Colour extension for CLF itself; which might provide a nice framework for applying various Colour methods directly to a process graph. Just a thought.

• For many, LUT generation might be the only way to turn Colour experiments and work into something immediately tangible and usable in a pipeline.

• On a philosophical level, Colour represents a wonderful abstraction of the "idea" or "concept" of specific color transforms / gamuts / colorspaces from any particular tangible representation or implementation of the underlying idea; I strongly feel there should be a way to differentiate (and reference) the concept of a transform from the myriad implementations (luts, shaders, expressions, cmstestpatterns, run-time methods, application or vendor implementations, etc)... but, by the same logic, it would also be helpful to have a be able to generate a baseline / control "reference" or "proxy" implementation ... it's very common to receive LUTs without knowing what the hell they actually are; or they claim to be one thing, but are actually another. Being able to generate LUTs from Colour directly provides a means to QC the color data we receive (or send), with precise knowledge of how the Colour lut was constructed.

Lut Reading stuff:

• Well... much more work than just writing to a single format, and letting other tools convert. But it would open avenues to all sorts of analytical / practical functionality -- format conversion, for sure, but also a means to compare LUTs and their differences / similarities, and whether an individual LUT is a representation of a higher level "concept", as described above... and from there, that could help to diagnose problems or identify idiosyncrasies with certain software or vendor math / representations...

• I guess LUT reading would necessarily be a prerequisite for plotting.

LUT Plotting stuff:

• It's really helpful to have visual representations of what a LUT does for any number of reasons; sometimes, just looking at a plot gives you enough information to know if a LUT is obviously going to clip the gamut or range inappropriately; is useful for visually communicating problems / information with vendors; helps to illustrate the difference between "LogC", ACEScc, ACEScct to colorists who were bitten by ACEScc response in their application of choice; determining if a LUT exhibits characteristics of concatenated shapers; determining if the lab gave us a LUT for an HDR trim, instead of SDR...

So -- LUT Plotting stuff, mostly useful to me for convenience, communication, and problem-solving; LUT Reading stuff, mostly useful to me for LUT database deduplication and verification, and LUT Writing stuff would provide enough functionality to serve as at least a start towards dynamic / bespoke color pipeline configs from a single Python package; the color-science behind which being unambiguously defined, because you've been doing such a good job of citing the crap out of your references :)

I can think of other stuff too, but I think that's enough for now.

FWIW, we've requested from the powers that be permission to contribute (or at least offer PRs) to Colour and its siblings -- but until I have permission, I don't think I can even provide example code without violating corporate intellectual property policies :/

[KelSolaar]

Thanks Zac!

This is great input, food for thoughts, I will try to answer your points.

LUT Generation Stuff

1. Yes, this is one of the main motivation to join with ColorPipe-tools.
2. I did not think about that one, at least not directly. I wanted mainly to refactor the current CLF python implementation so that it is fast, i.e. vectorise it and maybe through that use some of Colour functionality.
3. Yes! On a side note I do use Colour for a ton of tasks at work whether it be research and/or production.
4. I'm not sure I follow you entirely here but if I understand: the fact Colour is open source and peer reviewed establishes it as a kind of reference?

Lut Reading Stuff

1. Yes, the good thing overall is that those file formats don't change often, so if you have an implementation that is well written and tested, maintaining the code is almost free.
2. and Yes :)

LUT Plotting Stuff

1. All valid reasons to get that done!

we've requested from the powers that be permission to contribute (or at least offer PRs) to Colour and its siblings

That would be great :)

[KelSolaar]

Bumping that one as we have most of this covered except for the plotting: http://colour.readthedocs.io/en/develop/colour.io.html#look-up-table-lut-data

More to come soon!

[zachlewis]

Just wanted to say, this is really awesome work -- much appreciated!

[KelSolaar]

Thanks @zachlewis! The code is almost stable but we might rename a few things, namely the LUT2D class.

[KelSolaar]

Closing this one, there are a few things still to do but most of the critical stuff is addressed.