Am Montag, 17. Oktober 2016, 10:30:55 CEST schrieb Seweryn Niemiec: > On 13.10.2016 16:03, Tobias Ellinghaus wrote: > > Well, there are several places where a LUT can be applied. Once in the > > beginning, to get you recorded video data to a known state (kind of > > replaces input color profile), then there are final looks LUTs that are > > to be applied in the very end (to make the linear pixels look ok, adding > > a gamma curve and maybe some film emulation, so basically the final > > grading). And then there are intermediate ones like you ask for. > > That's true. If we want Darktable to process video footage (which happens to > me from time to time), then that would be the perfect way. There is usually > LUT converting from given camera's colour space characteristics to some > common space, like Cineon or rec709, then artistic grading or film > emulation LUT, then LUTs converting to colour spaces of distribution > mediums, like film print. For photography, since there are no LUTs (at > least known to me) that are designed to work with, for example, CR2 raw > files, then LUT module in the middle of the pipeline would be enough > (that's for me).
The output one might still be useful, I am not sure about that though. We will see about that. > > We discussed that a few times internally and while I would like to support > > that, there is the problem of WHERE to have such a module in the pipe. Or > > if we should add LUT support in a single new module plus the the > > input/output color profile modules? So many options ... If you have more > > insight I would like to hear about it. > > Could color profile modules be extended to do what they do now plus LUT > transformation? This and new module in the middle (after some basic luma and > colour correction modules, because LUTs are usually picky on what they get > on input) could be solution which does not increase UI entropy too much. As Johannes already wrote, there is the new LUT module very early in the pipe after input color profile already. Once we have a more robust way of converting regular LUT files (.cube, HaldCLUT, ...) for use in that module we might already be fine. It might be worth a try at least. > > I wouldn't like to add that dependency as it's a rather big one and > > somewhat opposed to the ICC based workflow we use. But we don't need it > > anyway, I already have written some test code that reads cube files and > > applies them. > Great! :) Tobias
signature.asc
Description: This is a digitally signed message part.
