<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Dec 10, 2017 at 12:23 PM Matthew Heimlich <<a href="mailto:matt.heimlich@gmail.com">matt.heimlich@gmail.com</a>> wrote:</div><div dir="ltr">> It definitely sounds like output formats are being confused with texture authoring formats here.</div><div><br></div><div>Not at all.</div><div><br></div><div>You are talking about linearization of a transfer function here. While that is part of the issue, that isn't the whole thing.</div><div><br></div><div>When authoring for wider gamut references, you have to take into account the reference primaries of the source. For example, every camera out there today can capture well larger than the REC.709 gamut. It is quite trivial to generate a wider gamut texture for example.</div><div><br></div><div>If you are mastering to a wider reference space, the material is constrained by the reference primaries it is in. It is rather like making a high quality digital recording of a cassette tape (for those of us out there that know what that is).</div><div><br></div><div>TL;DR: The assets need to be generated in at least the reference space or larger.</div><div><br></div><div>> Mari, Substance, and Quixel all suggest (and in some cases even force) a linear -> sRGB workflow.</div><div><br></div><div>This would be ridiculous. It also ignores the fact that you can't get to a scene referred linear via sRGB, so forcing this via some baked in hard coded math would be absolute, abject failure.</div><div><br></div><div>Further, there's a good deal of confusion around what the sRGB OETF is and how it relates to colour management. Not going to get into that, but I will say that as more folks understand the impact on the work, the more that move over to re-generating assets required for 2017 era input and output. Remember Tears of Steel? That work began in 2011 and in fact rammed face first into these issues.</div><div><br></div><div>With respect,</div><div>TJS</div></div></div>