[Mesa-dev] [V4 PATCH 0/7] mesa: Naming MESA_FORMATs to a specification

[Mark Mueller]

On Thu, Jan 23, 2014 at 2:24 AM, Marek Olšák <maraeo at gmail.com> wrote:

> On Thu, Jan 23, 2014 at 4:17 AM, Mark Mueller <markkmueller at gmail.com>
> wrote:
> > Hi Merek,
>
> I'm Marek.
>
> >
> >
> >
> >
> >
> > On Wed, Jan 22, 2014 at 2:49 PM, Marek Olšák <maraeo at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140123/8d584c83/attachment-0001.html>