[Bf-cycles] Tonemapping

Brecht Van Lommel brechtvanlommel at pandora.be
Thu Jun 23 12:59:01 CEST 2011


Forgot to mention, I think you're right about tonemapping belonging in
the compositor, and eventually the film response curves should move
out of the renderer. The only reason we do tonemapping is for fast
drawing in the viewport, for final rendering it should just pass on
the linear color and let the compositor do it.

On Thu, Jun 23, 2011 at 12:55 PM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> Hi David,
>
> This is indeed something that needs to be fixed, but I think it should
> be done a bit different. For viewport rendering I'd prefer to still
> keep the texture as uchar4, and instead add a second tonemapping
> kernel that outputs float4 in linear color into a temporary float4
> buffer.
>
> Reason for that is to avoid doing the conversion to srgb and then back
> to linear in this case, and because for CPU rendering uchar4 uploads
> quicker to the GPU for drawing.
>
> Thanks,
> Brecht.
>
> On Thu, Jun 23, 2011 at 1:45 AM, David <erwin94 at gmx.net> wrote:
>> Hi,
>>
>> at the moment the tonemapping process is part of the renderer and not as good as it could be.
>> It casts the result to an uchar image, which limits the usefulness of the compositor (no HDR) and
>> completely bypasses dithering.
>>
>> IMHO tonemapping does not belong in the renderer, but rather in the compositor, or as an
>> additional option to the color management process that already exists in blender.
>>
>> In the meantime the attached patch would help make the renderer a lot more useful,
>> it switches the result of tonemapping from a uchar4* to a float4* (tested for cpu and cuda)
>>
>> till then, David.
>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>


More information about the Bf-cycles mailing list