Am 26.08.2018 um 22:30 schrieb Kenneth:

>> Pretty much the only place where clipping occurs is saving the rendered
>> image to an actual file, and only if the file format is a classic
>> non-HDR format.
> 
> I assume that it also happens in the render preview (which is presented on a
> typical low-dynamic-range monitor). For example, rgb <0.3,0.5,0.7>  vs.
> 1.7*<0.3,0.5,0.7> for an object's color.  The latter would equate to
> <0.51,0.85,1.19>, with the blue being clipped to 1.0-- a shift in not only
> brightness but color. (And also depending on the scene's lighting intensity and
> color.)

Yes, of course. I forgot about that one.

> A curious question: Is such clipping of the preview done *by* POV-Ray prior to
> the scene being rendered? Or is it done strictly after-the-fact by the (LDR)
> monitor and its video card?

The clipping of the preview is currently done by the front-end portion
of POV-Ray (specifically, the `ImageMessageHandler` class). Passing HDR
data to the video card (and ultimately to the monitor) would probably
require the use of a special API such as DirectX or some such. If
someone were to pick up the glove of implementing the use of such an API
in POV-Ray, I'm sure we could change the internal interfaces without too
much effort.

However, in that case we should also consider investing more effort into
making sure that the preview is actually close to what will end up in
the image file. So for instance if the image is rendered to an LDR file,
we should show LDR data in the preview window even if the display system
is capable of displaying HDR material.

(A similar problem exists when rendering at low bit depth; currently
we're always previewing at a bit depth of 8 bpc. But since this bit
depth is by far the most common use case, we haven't made any effort to
fix this.)

Post a reply to this message