[Bf-committers] regarding color correction and images

[Brecht Van Lommel]

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 <dahliatrimble at 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 Ρυακιωτάκης Αντώνης <kalast at 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 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>