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 <[email protected]>: > > > > 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 <[email protected]>: > > > On Mon, Dec 11, 2017, 5:57 AM Sergey Sharybin <[email protected]> > > 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 > > [email protected] > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > 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> _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
