Re: Previous comments (for posterity sake)
Jeremy Selan <jeremy...@...>
---- Commenter
You mention rgb and rgba. How is alpha handled? Is there a policy? ---- Jeremy Current policy is that alpha is always passed unchanged. For applications which wish to be more clever (such as special premult / unpremult handling), the hope is for this library to continue to be ignorant of the issue. In the next rev of the API, this will be explicitly documented in the header. (numChannels will be replaced with a pixelStride, and we will explicitly mention that the calls only modify the rgb triples for processing). This will also let us handle >4 channel images. ---- Commenter When you decline support for spatially varying color xforms, do you mean image space? So, things like histogram-based tone curves, or whatever. Or did you mean no RGB space deformation operators? ---- Jeremy Yes, I mean image space varying transforms are not supported. Histogram-based operations, while they dont currently exist, are fine. There is just a lot of code internally that processes in scanlines and I would prefer to keep all pixels independent internally. This is also required in the GPU pipeline, which makes this assumption as it bakes the color transform stack into a 3d lut(s). ---- Commenter After reading through the info a couple times, I am wondering about a few key terms. You use "reference" and "linear" and "log" occasionally, and I think these need to be dealt with more strictly. ---- Jeremy Agreed. I will scrub the document of all references to linear or log, except in sections that are explicitly discussion workflow conventions. (Where I feel the are appropriate, as long as the terms are qualified / clarified at their first introduction). ---- Commenter It appears that the "reference" color space (the working space, or connection space) is not ever specified. It only exists as a by- product of the to_linear and from_linear methods in the config file. Since that working space can (conceptually) be arbitrary, it seems weird that all the code refers to it as linear. Now, I'm not suggesting anyone use something other than linear, but you do in the README. So, the extreme request is: you should change all the "linear"s to "reference"s. Which might be a bad idea, but take a few moments and read thru the material you sent doing a mental replace of "reference" for "linear". I feel that you will find that the Reference space needs to be specified. ---- Jeremy This is an excellent suggestion, and definitely take it to it's logical conclusion. I will go ahead and remove all references to linear from the API and configuration file and substitute the term 'reference' as appropriate. Thinking about this further, the two API calls which probably caught your attention: ConvertColorspaceToLinear, and ConvertLinearToColorspace, are probably unnecessary anyways. The more general function ConvertColorspaceToColorspace should be sufficient, and then would remove a lot of ambiguity from the API. Along the same topic, there are bunch of calls to get the names of colorspaces corresponding to certain use cases: GetLinearColorspace, GetLogColorspace, GetColorTimingColorspace, etc. This is the only place colorspaces names are 'enshrined' in any way, I will probably refine this call to be more abstract. Something more like enum ColorspaceRole { SCENE_LINEAR, COMPOSITING_LOG, COLOR_TIMING, DATA, } GetColorspaceForRole(ColorspaceRole role); ... where the mapping from role to colorspace is defined in the show configuration file. Having a few predefined roles (rather than accepting arbitrary names as roles) has proven to be a useful abstraction. For example, if we were to write a LogConvert node from Nuke, with pre-defined role enums (which will be documented) our LogConvert node could assume something like, ConvertColorspaceToColorspace( GetColorspaceForRole(SCENE_LINEAR), GetColorspaceForRole(COMPOSITING_LOG) ), etc. In our experience new roles have not come along that often, and new ones can be added at any time. ---- Commenter On the phone we discussed the idea that two shows might be both linear, but have different color primaries (e.g. wide versus 709). I realize you don't work that way now, in particular avoiding reading assets from one config into another config. But where does the color primary part go? Is there an example buried in the sample config? ---- Jeremy We do not have an example of this in a current config, so here's a mockup of what it could look like: // Show 'A', native r709 <config> <colorspace name='lin709'></colorspace> <colorspace name='linP3'> <to_reference> <transform file='p3_to_709.mtx' direction='forward'/> </to_reference> <from_reference> <transform file='p3_to_709.mtx' direction='inverse'/> </from_reference> </config> // Show 'B', native P3 <config> <colorspace name='linP3'></colorspace> <colorspace name='lin709'> <to_reference> <transform file='p3_to_709.mtx' direction='inverse'/> </to_reference> <from_reference> <transform file='p3_to_709.mtx' direction='forward'/> </from_reference> </config> Assuming your linear files are tagged appropriately with "linP3" or "lin709" (either as tokens in the header or by dynamically inspecting other attributes) things will work out correctly. No matter which show you are set to use, images will be transfomed in the the appropriate working space as expected. Of course, this assumes that each show is setup in a complementary manner to allow this. This assumption would be broken if for instance two shows disagreed on what the p3_to_709 matrix was. ---- Commenter The other word is "log", which you use here: "converting log to linear is not knowable". I didn't follow this logic. There is a lg10.lut1d file somewhere, why is it more special than any other lut file? ---- Jeremy Ah, lg10.lut1d is not more special than any other lut files. I was trying to get across the concept that the contents of the <to_reference> / <from_reference> blocks are not queryable through the API by design. (The transforms are essentially a single black box externally). In terms of generality, there are no magic named colorspaces whatsoever inside the API. All configuration info comes from the single file. As discussed above, we do expect to allow for pre-defined Colorspace "Labels / Roles" which are geared towards the vfx / animation pipeline, but I think there is a strong argument in favor of this. -- Subscription settings: http://groups.google.com/group/ocs-dev/subscribe?hl=en
|
|