On Thu, Jan 23, 2014 at 2:24 AM, Marek Olšák <mar...@gmail.com> wrote:
> On Thu, Jan 23, 2014 at 4:17 AM, Mark Mueller <markkmuel...@gmail.com> > wrote: > > Hi Merek, > > I'm Marek. > > > > > > > > > > > > > On Wed, Jan 22, 2014 at 2:49 PM, Marek Olšák <mar...@gmail.com> wrote: > >> > >> Hi Mark, > >> > > > [...] > > > > > >> Also, I have a proposal for SRGB formats. MESA_FORMAT_SRGB_UNORM8 and > >> MESA_FORMAT_SA8B8G8R8_UNORM > >> look weird, because they are not really UNORM and there is also no > >> stencil. :) How about this: MESA_FORMAT_RGB_SRGB8 (denoting an array > >> format of the SRGB type and 8 bits per channel) and > >> MESA_FORMAT_A8B8G8R8_SRGB (denoting a packed format of the SRGB type). > > > > > > I agree it could be better. My reasoning for avoiding what you suggested > is > > that it creates an ambiguity between color information and storage type. > For > > instance, sRBG color space values could feasibly be stored as floats, > half > > floats, snorms, or unorms, could they not? Thus the S is a color > component > > I don't think so. An sRGB channel is always a byte. You cannot store > both linear and sRGB values in an 8-bit format without losing > precision for either one of them, which I think is why there are sRGB > formats for sRGB values and other formats for linear values. Bigger > texture types do not suffer from this limitation so much. Also, sRGB > is not very well defined outside of the range [0, 1], which leaves > UNORM as the only suitable type. > That works for sRGB, but what about other color spaces that may be added in the future? I'm fine with leaving that to another day and with using the _SRGB decoration, as you say.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
