Answers are inlined.
On Sat, Jul 13, 2013 at 10:21 PM, Andrew Hunter <[email protected]> wrote: > Hi Sergey, > > On Jul 10, 2013 4:34 AM, "Sergey Sharybin" <[email protected]> wrote: > > > > Render engine should be a black box for the pipeline actually, it could > use > > any color space, any alpha mode it wants to. But when result goes out > from > > the engine to the pipeline it shall stick to current color management. > > Could you clarify what you mean my this? > It means blender part of render pipeline shouldn't know in which space render engine itself is working. it's only matter of agreeing i which space render [partial] result is passing from the engine to blender. Couple of ways here: - Either render engine itself bothers with converting stuff to Scene Linear (this is the most flexible way which i initially thought of, which makes tihngs behave as real pitch-black box, but requires all the engines to worry about this stuff which is not so much nice) - Provides color space to the blender via some api (this way we still supports engines which could potentiall work in different spaces) - Renderer's color space is defined as a role in OCIO config. This way renderer is not technically speaking a black-box, but this requires no changes to the render engines and it's still enough of control over the color pipeline. - It could also be a per-engine role or colorspace defined in blender itself, so different engines could have different spaces. But in fact i don' think supporting different spaces for different engines working at the same is crucial. It's unlikely you'll mix different renderers on the same pipeline. So i would think of ocio.config-defined rendreer's color space is the way to go. You'll just have different configs for different projects (if needed ofcourse, you could use the same config if there're no differences in color pipelines). > > > Which means if Scene Linear is set to ACES, render result need to be > > converted to ACES space before it's used in compositor or getting saved > to > > the file. > > If the render result needs to be converted to ACES, then the renderer is > not a black box if scene linear is ACES. Am I misunderstanding what you are > saying? > At this point it's not so much clear who would actually do a conversion: engine itself or blender's side of pipeline, or some api or whatever else. See above. But the thing is: image buffer in render result structure shall always be in scene linear space. > > > Color picker is also kind of an issue, but it's not as much biggie. > > Currently it's just using some kind of approximation of ColorPicker space > > by assuming default View of display transform is always invertible and > uses > > it for picking the color. Works reasonably fine, and does not bother > normal > > artists being with extra options which are just confusing for 95% of > > blender artists. > > "normal" is contextual. > Yes. And context is clear enough from the mailing list. If some option is only used by few commercial studios and which keeps rest of the smaller studios and other blender artists just confused -- it's rather bad option. Now, if you'll add color picker space, what would you set it to? And whether/how do change it when someone changes current display/view? This is rather rhetorical questions for now and i don't want to discuss them for until someone is gonna to implement this feature. But keep in mind: if changing one option (which is display/view) requires changing other things (which is color picker space) to just keep behavior sane, it's rather counter-intuitive and confusing. There're also couple of ways to deal with this. Like, using either some "default" choose which will have current behavior and allow to choose other color space if needed. Or try to somehow approximate which colorspace fits best current display and so. > > > Agree those are indeed bigger tasks (comparing with just adding color > space > > conversion on file save), but we don't choose easy way, we d choose the > > right way. > > As I understand it, Exr renders from blender are unsuitable for exchange > with other applications without first taking into account the peculiar > notion that float buffers must be saved to disk untransformed. > > That isn't what I would call the "right" way. > All the software in a pipeline shall be configured in a way they work with the same color space settings. For exrs which are used for interchange they shall be saved in Scene Linear space. So this way you just configure blender and whatever-else-software to use the same ocio.config (which is the whole idea of ocio library btw) and you wouldn't need to ensure you're saving stuff in the proper space from blender. It's probably still would need to support color space transform on save, but that's rather and exceptional case and wouldn't give it a high priority. > > > > > On Wed, Jul 10, 2013 at 6:10 AM, Troy Sobotka <[email protected] > >wrote: > > > > > On Jul 9, 2013 1:15 PM, "Sergey Sharybin" <[email protected]> > wrote: > > > >The root of the issue goes to the fact, that renderer always > > > > outputs stuff in rec709 space (or in your language it'll be linear > space > > > > with rec709 primaries). > > > > > > ? > > > > > > The renderer only renders with the values assigned, no? > > > > > > Given that out color picker has yet to get proper management, this > still > > > seems like a curious statement given that we can color light to any > value > > > under assumed primaries? > > > > > > With respect, > > > TJS > > > _______________________________________________ > > > Bf-committers mailing list > > > [email protected] > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > -- > > With best regards, Sergey Sharybin > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
