[Bf-cycles] Tonemapping

[David]

Okay, thanks.  I will keep the following (more minimal) patch applied locally
in the meantime, which does just that (except implementing the response curves
in the compositor).

(small note: session->pass was never updated and session->tile_manager.state.pass
is protected)

On Jun 23, 2011, at 12:59 PM, Brecht Van Lommel wrote:

> 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.
>>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: float_buffer_2.patch
Type: application/octet-stream
Size: 2226 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20110623/aa22af9d/attachment.obj