Date
1 - 2 of 2
Lut format chart
|
Jeremy Selan <jeremy...@...>
An additional clarification...
toggle quoted message
Show quoted text
There does need need to be some end-user ui for image display. (I didnt want to imply no UI was necessary). You just dont need lut- directory / browser / setup interface). For a display application, the most common ui would be to have two popdowns. One would be the ColorSpace corresponding to image state. (Such as identifying the file as genesis log, film log, scene linear, etc). The other popdown would be to specify the output display profile (such as rec709, p3 dlp, srgb, etc). -- Jeremy On May 25, 3:42 pm, Jeremy Selan <jeremy...@...> wrote:
Exactly. Clients apps will automatically have support for all lut |
|
|
|
Jeremy Selan <jeremy...@...>
Exactly. Clients apps will automatically have support for all lut
toggle quoted message
Show quoted text
formats. (It's about time!) To an end user, this should feel pretty automated. Apps shouldn't need ebd user options / dialogs, all of the lut-location mojo is internal to the ColorConfiguration file. Specifying which configuration to use is controlled via a single environment variable (which points at an ocs file). (Explicit initialization is also allowed, but this will probably be less common). The internals of the .ocs file are still in flux, but the rough idea is that there will be two flavors. One flavor will be a human- readable xml file, of which one element lut dir. The alternative will be a binary ocs 'package', where the lut dir is self contained in the file. (Think tgz of a config / lut dir). In the super common newbie-case, downloading a single .ocs binary file, and pointing to it with OCS_CONFIG will be all that's needed. -- Jeremy On May 25, 3:09 pm, Larry Gritz <l....@...> wrote:
Neat. So just to clarify, the big idea is that any app that uses your color library properly will, by extension, understand ALL of these luts (whichever happens to be available/used at the facility using the app)? |
|
|