Storing an image in scene linear RGB in 8 bit is not going to work, there's not enough precision for that.
Are we really sure this is a color management issue, and not simply a bug somewhere? For float painting there indeed may be missing some conversions. But the intention of the 8 bit painting code at least was to do all painting in sRGB space, no scene linear colors involved. I think it would be good to compare the blending behavior and code with e.g. mypaint or gimp. Do they suffer the same problems, do they use scene linear <-> sRGB colors when painting on 8 bit images, or do they somehow manage to get better results without that? Brecht. 2011/5/27 Dahlia Trimble <dahliatrim...@gmail.com>: > 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 > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers