Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Mon, Oct 22, 2018, 10:28 AM Brecht Van Lommel 
wrote:

> Here are the notes from today's developer meeting. Next meeting is Monday,
> 29 October 18:00 CEST (16:00 UTC).
>
> 1) Blender 2.8
>
> * Work continues towards the beta, an update on the current status will be
> posted on the code blog and presented at Blender Conference.
>

Can we put, even if we miss wide gamut, a full cleanup of the OCIO colour
config on the table?

Right now it is a horrible mess, and I think anyone familiar with it would
agree.

To this end, I've tried to add in the bare minimum for 2018, including
Apple P3 displays, to Filmic over at
https://github.com/sobotka/filmic-blender/tree/AppleP3?files=1

Having a streamlined config reduces complexity for the folks newer to the
subject, and encourages interaction as a result.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Brecht Van Lommel]

The targets for the 2.80 release are quite fixed already, it's too late to
make disruptive changes.

If you want to submit a patch that adds P3 support to the existing config,
or remove some legacy things, we could accept that. For a completely
different config, we would need to provide some level of backwards
compatibility and agree on the naming, I don't think there is time for that.

On Mon, Oct 22, 2018 at 7:35 PM Troy Sobotka  wrote:

> On Mon, Oct 22, 2018, 10:28 AM Brecht Van Lommel <
> brechtvanlom...@gmail.com>
> wrote:
>
> > Here are the notes from today's developer meeting. Next meeting is
> Monday,
> > 29 October 18:00 CEST (16:00 UTC).
> >
> > 1) Blender 2.8
> >
> > * Work continues towards the beta, an update on the current status will
> be
> > posted on the code blog and presented at Blender Conference.
> >
>
> Can we put, even if we miss wide gamut, a full cleanup of the OCIO colour
> config on the table?
>
> Right now it is a horrible mess, and I think anyone familiar with it would
> agree.
>
> To this end, I've tried to add in the bare minimum for 2018, including
> Apple P3 displays, to Filmic over at
> https://github.com/sobotka/filmic-blender/tree/AppleP3?files=1
>
> Having a streamlined config reduces complexity for the folks newer to the
> subject, and encourages interaction as a result.
>
> With respect,
> TJS
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Tue, Oct 23, 2018, 4:07 AM Brecht Van Lommel 
wrote:

> For a completely
> different config, we would need to provide some level of backwards
> compatibility and agree on the naming, I don't think there is time for
> that.
>

I was under the impression 2.8 was a clean break?

It strikes me as a horrible idea keeping something like the busted up RRT
and other crazy things in that config, doubly so that anyone can download
any configuration they want, or better, revert to an older version of
Blender?

The configuration really is a horrible mess and could be cleaned up in no
time.

With respect,
TJS

>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Ricardo Nunes]

If I've understood correctly the first "public" release for 2.8 is supposed
to be couple weeks after Bcon'18 so less than 3 weeks from now?

I do agree, though, it'd be nice if color management could be cleaned up in
2.81.

ti 23. lokak. 2018 klo 17.40 Troy Sobotka (troy.sobo...@gmail.com)
kirjoitti:

> On Tue, Oct 23, 2018, 4:07 AM Brecht Van Lommel  >
> wrote:
>
> > For a completely
> > different config, we would need to provide some level of backwards
> > compatibility and agree on the naming, I don't think there is time for
> > that.
> >
>
> I was under the impression 2.8 was a clean break?
>
> It strikes me as a horrible idea keeping something like the busted up RRT
> and other crazy things in that config, doubly so that anyone can download
> any configuration they want, or better, revert to an older version of
> Blender?
>
> The configuration really is a horrible mess and could be cleaned up in no
> time.
>
> With respect,
> TJS
>
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Bassam Kurdali]

I think that would be a really good goal for 2.81 also. I'm personally not to 
sure how important backwards compatibility is, especially when fixing 
problems-in this case it's kind of a shame that it's not a good goal for 2.80 
at this point, since there's more of an expectation that things will break.
Bassam

On October 23, 2018 11:42:21 AM EDT, Ricardo Nunes <3rto...@gmail.com> wrote:
>If I've understood correctly the first "public" release for 2.8 is
>supposed
>to be couple weeks after Bcon'18 so less than 3 weeks from now?
>
>I do agree, though, it'd be nice if color management could be cleaned
>up in
>2.81.
>
>ti 23. lokak. 2018 klo 17.40 Troy Sobotka (troy.sobo...@gmail.com)
>kirjoitti:
>
>> On Tue, Oct 23, 2018, 4:07 AM Brecht Van Lommel
>> >
>> wrote:
>>
>> > For a completely
>> > different config, we would need to provide some level of backwards
>> > compatibility and agree on the naming, I don't think there is time
>for
>> > that.
>> >
>>
>> I was under the impression 2.8 was a clean break?
>>
>> It strikes me as a horrible idea keeping something like the busted up
>RRT
>> and other crazy things in that config, doubly so that anyone can
>download
>> any configuration they want, or better, revert to an older version of
>> Blender?
>>
>> The configuration really is a horrible mess and could be cleaned up
>in no
>> time.
>>
>> With respect,
>> TJS
>>
>> >
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>>
>___
>Bf-committers mailing list
>Bf-committers@blender.org
>https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[lukas.stock...@freenet.de]

Maybe a compromise would be to kick out the old and broken stuff (e.g. the old 
Film looks) for 2.8 (since that is the step that actually breaks compatibility) 
and then have an updated config as a target for 2.81 (since that is the step 
that needs discussion/review/etc.)?-- Originalnachricht--Von: Bassam 
KurdaliDatum: Di., 23. Okt. 2018 18:20An: bf-blender developers;Ricardo 
Nunes;Cc: Betreff:Re: [Bf-committers] Blender developers meeting notes - 
2018-10-22I think that would be a really good goal for 2.81 also. I'm 
personally not to sure how important backwards compatibility is, especially 
when fixing problems-in this case it's kind of a shame that it's not a good 
goal for 2.80 at this point, since there's more of an expectation that things 
will break.BassamOn October 23, 2018 11:42:21 AM EDT, Ricardo Nunes 
<3rto...@gmail.com> wrote:>If I've understood correctly the first "public" 
release for 2.8 is>supposed>to be couple weeks after Bcon'18 so less than 3 
weeks from now?>>I do
  agree, though, it'd be nice if color management could be cleaned>up 
in>2.81.>>ti 23. lokak. 2018 klo 17.40 Troy Sobotka 
(troy.sobo...@gmail.com)>kirjoitti:>>> On Tue, Oct 23, 2018, 4:07 AM Brecht Van 
Lommel>> >>> wrote: > For a completely>> > different config, we would need 
to provide some level of backwards>> > compatibility and agree on the naming, I 
don't think there is time>for>> > that.>> > I was under the impression 2.8 
was a clean break? It strikes me as a horrible idea keeping something like 
the busted up>RRT>> and other crazy things in that config, doubly so that 
anyone can>download>> any configuration they want, or better, revert to an 
older version of>> Blender? The configuration really is a horrible mess and 
could be cleaned up>in no>> time. With respect,>> TJS >>> 
___>> Bf-committers mailing list>> 
Bf-committers@blender.org>> 
https://lists.blender.org/mailman/listinfo/bf-committers>>>__
 _>Bf-committers mailing 
list>Bf-committers@blender.org>https://lists.blender.org/mailman/listinfo/bf-committers--
 Sent from my Android device with K-9 Mail. Please excuse my 
brevity.___Bf-committers mailing 
listBf-committers@blender.orghttps://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Brecht Van Lommel]

We do not break compatibility when we can reasonably avoid it.

I don't personally mind removing the old RRT and Film transforms for
example, as Filmic provides a good replacement. But renaming e.g. "sRGB" to
"sRGB Native 2.2" or "Filmic" to "Filmic Log Encoding Base" is in my
opinion not an improvement, and certainly not worth breaking compatibility
over. It also changes American to British spelling for example.

As we have discussed before, I also do not think we should require a look
to be specified for the Filmic view transform to give correct results, the
None look should work too.

None of these things are very difficult to fix, all I'm asking is if you
want to contribute an improved configuration, please do it in a way that
tries to preserve compatibility where reasonable and with an explanation of
why the cases that break compatibility are acceptable.


On Tue, Oct 23, 2018 at 6:43 PM lukas.stock...@freenet.de <
lukas.stock...@freenet.de> wrote:

> Maybe a compromise would be to kick out the old and broken stuff (e.g. the
> old Film looks) for 2.8 (since that is the step that actually breaks
> compatibility) and then have an updated config as a target for 2.81 (since
> that is the step that needs discussion/review/etc.)?--
> Originalnachricht--Von: Bassam KurdaliDatum: Di., 23. Okt. 2018
> 18:20An: bf-blender developers;Ricardo Nunes;Cc: Betreff:Re:
> [Bf-committers] Blender developers meeting notes - 2018-10-22I think that
> would be a really good goal for 2.81 also. I'm personally not to sure how
> important backwards compatibility is, especially when fixing problems-in
> this case it's kind of a shame that it's not a good goal for 2.80 at this
> point, since there's more of an expectation that things will break.BassamOn
> October 23, 2018 11:42:21 AM EDT, Ricardo Nunes <3rto...@gmail.com>
> wrote:>If I've understood correctly the first "public" release for 2.8
> is>supposed>to be couple weeks after Bcon'18 so less than 3 weeks from
> now?>>I do
>   agree, though, it'd be nice if color management could be cleaned>up
> in>2.81.>>ti 23. lokak. 2018 klo 17.40 Troy Sobotka (
> troy.sobo...@gmail.com)>kirjoitti:>>> On Tue, Oct 23, 2018, 4:07 AM
> Brecht Van Lommel>> >>> wrote: > For a completely>> > different config,
> we would need to provide some level of backwards>> > compatibility and
> agree on the naming, I don't think there is time>for>> > that.>> > I
> was under the impression 2.8 was a clean break? It strikes me as a
> horrible idea keeping something like the busted up>RRT>> and other crazy
> things in that config, doubly so that anyone can>download>> any
> configuration they want, or better, revert to an older version of>>
> Blender? The configuration really is a horrible mess and could be
> cleaned up>in no>> time. With respect,>> TJS >>>
> ___>> Bf-committers mailing
> list>> Bf-committers@blender.org>>
> https://lists.blender.org/mailman/listinfo/bf-committers
> >>>__
>  _>Bf-committers mailing list>
> Bf-committers@blender.org>
> https://lists.blender.org/mailman/listinfo/bf-committers-- Sent from my
> Android device with K-9 Mail. Please excuse my
> brevity.___Bf-committers
> mailing listBf-committers@blender.orghttps://
> lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Tue, Oct 23, 2018, 9:53 AM Brecht Van Lommel 
wrote:

>
> I don't personally mind removing the old RRT and Film transforms for
> example, as Filmic provides a good replacement. But renaming e.g. "sRGB" to
> "sRGB Native 2.2" or "Filmic" to "Filmic Log Encoding Base" is in my
> opinion not an improvement, and certainly not worth breaking compatibility
> over. It also changes American to British spelling for example.
>

I'm fine with these sorts of changes in the bigger picture.

As we have discussed before, I also do not think we should require a look
> to be specified for the Filmic view transform to give correct results, the
> None look should work too.
>

None does work. It delivers a log base image, which is rather important for
plenty of folks, not the least of which was the BI's Agent.

Specifically, if the config defaults to a look on top of the log base, it
would be impossible to replicate what the actual BI did for Agent. That
seems odd, no?

None of these things are very difficult to fix, all I'm asking is if you
> want to contribute an improved configuration, please do it in a way that
> tries to preserve compatibility where reasonable and with an explanation of
> why the cases that break compatibility are acceptable.
>

I'm not resisting this. At all.

I'll push a branch that tries to maintain compatibility on naming.

T
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Brecht Van Lommel]

On Tue, Oct 23, 2018 at 7:25 PM Troy Sobotka  wrote:

> I'm fine with these sorts of changes in the bigger picture.
>

Ok, great.


> As we have discussed before, I also do not think we should require a look
> > to be specified for the Filmic view transform to give correct results,
> the
> > None look should work too.
> >
>
> None does work. It delivers a log base image, which is rather important for
> plenty of folks, not the least of which was the BI's Agent.
>
> Specifically, if the config defaults to a look on top of the log base, it
> would be impossible to replicate what the actual BI did for Agent. That
> seems odd, no?
>

Does this refer to saving a render in log color space for loading into
software that does not support OpenColorIO? I think it is using the Look
feature for something it was not designed to do, to work around
limitations. The proper solution would be to allow saving images in a
specified color space directly (Filmic Log in the current config?), without
being affected by the display device or view transform.

None of these things are very difficult to fix, all I'm asking is if you
> > want to contribute an improved configuration, please do it in a way that
> > tries to preserve compatibility where reasonable and with an explanation
> of
> > why the cases that break compatibility are acceptable.
> >
>
> I'm not resisting this. At all.
>
> I'll push a branch that tries to maintain compatibility on naming.
> 


Ok, great.

Thanks,
Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Tue, Oct 23, 2018, 10:41 AM Brecht Van Lommel 
wrote:

> On Tue, Oct 23, 2018 at 7:25 PM Troy Sobotka 
> wrote:
>
> Does this refer to saving a render in log color space for loading into
> software that does not support OpenColorIO? I think it is using the Look
> feature for something it was not designed to do, to work around
> limitations.

The proper solution would be to allow saving images in a
> specified color space directly (Filmic Log in the current config?), without
> being affected by the display device or view transform.
>

I don't disagree that we need a file encoding transform stack, much like a
texture box has a stack of texture elements. The current implementation is
unworkable. Default could simply default to the current behaviour, with an
"Advanced" cascade panel that exposes the transforms.

All of that said, the design of the configuration is perfectly in line with
OCIO's design. The reference encoding is the Filmic Base Log, and the rest
are aesthetic twists on it. This has been confirmed multiple times via OCIO
folks. _It is using the Look precisely as it was designed_.

The Blender implementation of colour management should mature a little, but
sadly we are strained for developers. Short term, an OCIO node solves
99.95% of the issues. I'm reasonably certain that folks like Sebastian
would agree it is a crucial node to mitigate the Blender shortcomings in
the short term.

T
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Brecht Van Lommel]

We've had this discussion before, and I still did not see the explanation
from OCIO looks about looks being intended for this. The documentation
seems to say something else.

But even besides that, it's just poor user interface design to use the Look
setting for both artistic looks and saving to an intermediate file format.
And when switching between Default and Filmic it's not good for None to
have a a different purpose, settings should generally be orthogonal.

An OCIO node would solve the issue as well, I'd be fine if that got added
to the compositor.

On Tue, Oct 23, 2018 at 8:01 PM Troy Sobotka  wrote:

> On Tue, Oct 23, 2018, 10:41 AM Brecht Van Lommel <
> brechtvanlom...@gmail.com>
> wrote:
>
> > On Tue, Oct 23, 2018 at 7:25 PM Troy Sobotka 
> > wrote:
> >
> > Does this refer to saving a render in log color space for loading into
> > software that does not support OpenColorIO? I think it is using the Look
> > feature for something it was not designed to do, to work around
> > limitations.
>
> The proper solution would be to allow saving images in a
> > specified color space directly (Filmic Log in the current config?),
> without
> > being affected by the display device or view transform.
> >
>
> I don't disagree that we need a file encoding transform stack, much like a
> texture box has a stack of texture elements. The current implementation is
> unworkable. Default could simply default to the current behaviour, with an
> "Advanced" cascade panel that exposes the transforms.
>
> All of that said, the design of the configuration is perfectly in line with
> OCIO's design. The reference encoding is the Filmic Base Log, and the rest
> are aesthetic twists on it. This has been confirmed multiple times via OCIO
> folks. _It is using the Look precisely as it was designed_.
>
> The Blender implementation of colour management should mature a little, but
> sadly we are strained for developers. Short term, an OCIO node solves
> 99.95% of the issues. I'm reasonably certain that folks like Sebastian
> would agree it is a crucial node to mitigate the Blender shortcomings in
> the short term.
>
> T
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Wed, Oct 24, 2018, 2:23 AM Brecht Van Lommel 
wrote:

> We've had this discussion before, and I still did not see the explanation
> from OCIO looks about looks being intended for this. The documentation
> seems to say something else.
>

You don't see it, yet it has been discussed with the lead developers and
many other OCIO folks ad nauseum.


This is a resolved point, and the documentation confirms the position.

> A “look” is a named color transform, intended to modify the look of an
image in a “creative” manner (as opposed to a colorspace definition which
tends to be technically/mathematically defined). An OCIO look typically
exists as a flexible addendum to a defined viewing transform.

But even besides that, it's just poor user interface design to use the Look
> setting for both artistic looks and saving to an intermediate file format.
>

That's Blender's design problem, not the design of the configuration. That
is something that needs to be redesigned within Blender.

I don't disagree, but that is the poor way that Blender integrates colour
management.

And when switching between Default and Filmic it's not good for None to
> have a a different purpose, settings should generally be orthogonal.
>

I don't believe this is asserted in OCIO. I can think of a number of
situations where this wouldn't be the case.

With that said, the Apple P3 branch works fine like this, and the various
contrasts behave identically under each display type.

T
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Brecht Van Lommel]

Saving to an intermediate file format is not part of "modifying the look of
an image in a creative manner" in my opinion. I can not find public
discussion about using looks for other purposes.

I agree Blender OCIO integration has limitations, but I'm not sure how
integrating looks in a different way would help improve the UI.

Anyway, it was relatively easy to change Filmic to work with looks this way
before, it should be possible to keep it working the same.

On Wed, Oct 24, 2018 at 3:38 PM Troy Sobotka  wrote:

> On Wed, Oct 24, 2018, 2:23 AM Brecht Van Lommel  >
> wrote:
>
> > We've had this discussion before, and I still did not see the explanation
> > from OCIO looks about looks being intended for this. The documentation
> > seems to say something else.
> >
>
> You don't see it, yet it has been discussed with the lead developers and
> many other OCIO folks ad nauseum.
>
>
> This is a resolved point, and the documentation confirms the position.
>
> > A “look” is a named color transform, intended to modify the look of an
> image in a “creative” manner (as opposed to a colorspace definition which
> tends to be technically/mathematically defined). An OCIO look typically
> exists as a flexible addendum to a defined viewing transform.
>
> But even besides that, it's just poor user interface design to use the Look
> > setting for both artistic looks and saving to an intermediate file
> format.
> >
>
> That's Blender's design problem, not the design of the configuration. That
> is something that needs to be redesigned within Blender.
>
> I don't disagree, but that is the poor way that Blender integrates colour
> management.
>
> And when switching between Default and Filmic it's not good for None to
> > have a a different purpose, settings should generally be orthogonal.
> >
>
> I don't believe this is asserted in OCIO. I can think of a number of
> situations where this wouldn't be the case.
>
> With that said, the Apple P3 branch works fine like this, and the various
> contrasts behave identically under each display type.
>
> T
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers