[Bf-committers] Patch: OCIO Parse Colorspace From Filename

[Adriano Oliveira]

Hi people,

I think this is ok, but do not really address "the tedium of manual setting
of color spaces". No one would change two clicks in a drop down menu by a
lot of typing in texture names: "_sRGB", "_linear"...

It would be better to add sensitive conditions to names that we already use
in PBR texture workflow: "_albedo" or "_basecolor" (=sRGB/gamma 2.2);
"_rough", "metalic", "_ao"... (=linear).

And maybe we should separate the color management for textures nodes and
the color management in media input for composing purposes. In Blender
composition workflow, like in Natron em Nuke, beeing able to set color
spaces for incoming media is fundamental, and they can vary a lot and will
vary a lot more in future (REC2020...)

But textures at material setting context are not as complicated. We just
have two effective scenarios: linear or sRGB (gamma corrected). Everything
should be linear for maps, but as long as we stay with old 256 levels per
channel, gamma correct is needed for color textures due to compression. The
future in this area is everything linear texture at 16 or 32 bit, not a
profusion of color spaces (who knows...).

That is why a "[ ] sRGB" or "[ ] gamma corrected" check box in Texture
Image node is the ideal solution for the unnecessary drop down for only two
color space in this context.


*Adriano A. Oliveira*

2017-12-11 12:12 GMT-03:00 Xavier Thomas <xavier.thomas.1980 at gmail.com>:

> >
> > This patch seems to have the following priority:
> > - Image loader sets color space (based on either image header or other
> > assumptions)
> > - The higher level reader then might override the color space based on
> file
> > name.
> > If we allow such an automatic guess, it should be other way around. If
> the
> > file knows it's color space, it should be trusted, as it is more trustful
> > than a file name.
>
>
> Then it might be wiser to join all the "color space auto detection magic"
> at the same place (image loader) and only try to guess from the filename if
> the header/metadata detection failed.
>
> In any case, in my opinion, the colorspace displayed in the UI/RNA
> (possibly manually set by the user afterwards) should always be respected
> and never silently overridden.
>
> Xavier
>
> 2017-12-11 12:45 GMT-02:00 Troy Sobotka <troy.sobotka at gmail.com>:
>
> > On Mon, Dec 11, 2017, 5:57 AM Sergey Sharybin <sergey.vfx at gmail.com>
> > wrote:
> > > - Image loader sets color space (based on either image header or other
> > > assumptions)
> > > The higher level reader then might override the color space based on
> file
> > > name.
> >
> > > If we allow such an automatic guess, it should be other way around. If
> > the
> > > file knows it's color space, it should be trusted, as it is more
> trustful
> > > than a file name.
> >
> > >
> > Ok. So if we do that, what is the best method to set the defaults? Each
> > filetype has the colourspace set to the default role.
> >
> > Would the following order work?
> >
> >  * Set the filetype default to Null.
> >  * Test the colorspace variable for a Blender file setting.
> >  * If Blender file remains unset, test for filename.
> >  * If it remains unset, set to default role.
> >
> > Is there a means to differentiate between whether the colorspace variable
> > was set via default role or user based setting?
> >
> > With respect,
> > TJS
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Livre
de vírus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>