[Bf-committers] Color management broken?

[Sergey Sharybin]

Answers are inlined.


On Sat, Jul 13, 2013 at 10:21 PM, Andrew Hunter <andrew at aehunter.net> wrote:

> Hi Sergey,
>
> On Jul 10, 2013 4:34 AM, "Sergey Sharybin" <sergey.vfx at gmail.com> 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 <troy.sobotka at gmail.com
> >wrote:
> >
> > > On Jul 9, 2013 1:15 PM, "Sergey Sharybin" <sergey.vfx at gmail.com>
> 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
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin