I would think that there would be precision losses and possibly color gamut clipping on successive conversions to/from linear and srgb color space. This may not be visible if internal formats have a high precision, such as 32 bit floats for each pixel color, but if they are stored as low precision such as 8 bit integers, then you would see visible steps in color gradients which would become worse with each conversion.
2011/5/26 Ρυακιωτάκης Αντώνης <kal...@gmail.com> > Hi everyone, as part of my GSOC I started working on a certain bug that has > to do with color correction and image/projection painting, In particular, > strange colors/fringes appear when painting in image/texture projection > mode. After testing it seems that the correct behavior occurs by first > converting brush color from srgb to linear rgb, doing the painting and then > converting back to srgb for display. Converting brush colors to linear rgb > is fairly easy, however there are complications when it comes to images. > > Currently there is no color correction applied to texture images before > they > are sent for display, with one exception: Float textures, when doing > projection painting are sent for display color-corrected. What this means > is > that Imbuf->rect is filled with color corrected values. > > This is all fine and well but it implies that Imbuf's used for rendering > must be linearized before rendered or used in calculations by GLSL shaders. > Is this already happening (based on Imbuf->profile flag?) or am I risking > breaking something by storing sRGB values in Imbuf->rect? > > A search for IB_PROFILE_SRGB shows a result in pipeline.c that indicates > that, at least for rendering purposes this is accounted for. Is this also > true for GLSL? > > Another consideration is performance: If Imbuf->rect stores sRGB values > then > these will have to be converted again to linear rgb when texture painting, > lowering performance. > Another option is to store linear values in Imbuf->rect but upload sRGB > values to OpenGL. This is better performance-wise and feasible but again, > values must be converted back to linear in GLSL. > > Any suggestions observations and thoughts are really welcome, since I > haven't got too much experience with all the different parts of the code > and > time is precious. > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers