On 01/23/2014 11:19 AM, Mark Mueller wrote: > 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.
Oy. Let's not worry about things that hypothetically could be someday. We need to do what makes sense today.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
