The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Attached to Project: POV-Ray
Opened by Christoph Lipka - 2009-05-08
Last edited by Christoph Lipka - 2012-06-21

FS#9 - Add support for tuning brightness of image-mapped sky spheres

Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.

To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.

Closed by  Christoph Lipka
Thursday, 21 June 2012, 22:36 GMT
Reason for closing:  Implemented
Thorsten Fröhlich commented on Saturday, 16 May 2009, 17:11 GMT

Would adjusting the brightness not already be possible by using regular texture features? If not, the image_map statement seems like a good place to add it to.

Christoph Lipka commented on Sunday, 17 May 2009, 20:19 GMT

Only pigment features can be used with sky_sphere, which currently limits the options available; I won't rule out that it might already be possible to do it with some smart pigment feature combo, but even then I expect that to be a rather cumbersome solution.

Jonathon commented on Friday, 17 July 2009, 18:52 GMT

Why not permit some finish options for a sky_sphere, but make the default ambient be 1? It would let one tune the brightness in a way that is already familiar (from a texturing standpoint).

Grimbert Jérôme commented on Wednesday, 13 October 2010, 12:14 GMT

As pigment are not limited to 0.0 - 1.0 range for rgb value, what is the real issue here ?
(short of: "I do not want to pre-process my image map so that it actually do what I want")

Can it be reduced to applying a transformation (matrix ?) on the r/g/b components (what about alpha ? what about filter & transmit ?) ?
(Or do we need a 4x6 matrix transform ? as transmit seems very like alpha, maybe a 4x5 is enough ?)

Why do I talk about a matrix ? because it's the general solution for direct-mapping pictures.
(the usage of "filter Palette, amount"/"transmit Palette, amount" can remain for indexed color pictures)

On entry: R, G, B, Alpha;
On exit: R, G, B, Filter, Transmit
Default to

1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 0
0 0 0 1

(I tend to think of alpha as transmit: 100% alpha on black pixel is still transparent; Am I wrong ? should it be filter ?)

With such matrix (input form in SDL might be different, for instance 5 4D vector ? or 4 5D vector ? I do not know what is more convenient yet), if you need to boost the brightness, you could use a matrix like

10  0  0  0
 0 10  0  0
 0  0 10  0
 0  0  0  0
 0  0  0  1

Any thought on that proposal ?
(I prefer a general solution to a specific one)

Jonathon commented on Friday, 15 October 2010, 01:34 GMT

My take, when it comes to tuning sky brightness for scenes using radiosity, is that the finish statement would be very helpful. At times, increasing the number of bounces will affect the overall final brightness. As test renders are done, it doesn't seem to make a lot of sense to have to reprocess images or have different, yet similar pigment statements for use during brightness adjustment. With more recent changes and the distinction between ambient and emission, having a finish statement in a sky_sphere wuld be even more useful, since the apparent brightness of the sky is decoupled from the brightness of the radiosity rays.

That said, I can see the appeal of having a more general solution of a matrix or matrix-like feature. Personally, I lean toward user-defined vector functions. If you had a user-defined 5-vector function, you could do whatever you wanted with the pigment.

Grimbert Jérôme commented on Friday, 15 October 2010, 12:37 GMT

The more I think about it, and the more I believe the matrix is far too complex: to do it as I dream of it, you would need to push the RGBA into a homogeneous vector (similar to the 4D coordinates used for 3D transformation, but for 4D points), then apply a matrix (allowing rotations (change of hue ?),scale and translation (adding fixed value)), and finally converting it to RGBTF.

Which means that some (but not all) operations would be possible (such as swap red & green, or inverse blue) but things like change magenta to yellow, but keep red and green as they are would probably not (well not with a matrix; the idea of a function is another story). So probably it is simpler to just allow a linear, per channel, correction with a 5D vector: entry is RGBAA, output RGBFT (with A=1 for 100% transparency, not that in fact it could matter really for a skysphere, because there is no thing "behind", so F & T should probably be ignored there, but as it is a modifier to the image map generic code, it might impact other usages)

<R,G,B,T,F> := <x.r,y.g,z.c,f.a,t.a>

SDL would be something like "... corrected <x,y,z,f,t> ", applied to image_map

(The idea of trying to explain the homogeneous system for 5D rgbft is quite a headache, a 6x6 matrix is too much and yet you cannot do everything on the color space; at least with a <x,y,z,f,t> coefficient, you can adjust a bit the color (if you want it a bit more green or red)... better than nothing, IMHO))

I cannot understand the "finish" approach: there is no normal, no reflection... no secondary rays.
(I could understand the need for a finish_map, but that's another story, and its only for a real shape, not a skysphere)
Is there a need for a skysphere_for_radiosity (as opposed to visible skysphere ) ?

Christoph Lipka commented on Saturday, 30 October 2010, 08:55 GMT

All that was originally asked for was to tune the overall brightness of a image-based sky_sphere; I see no need for any more complex color manipulation (well, at least none that would be specific to a sky_sphere).

As for a "radiosity_sky_sphere", that would indeed come in handy, as you could use a blurred version of the image for this purpose, to get away with fewer radiosity rays to be shot even when there are small bright specks in the sky_sphere (as often found with HDRI light probes, whether it be the sun in an outdoor shot or a lamp indoors). Another option there would be to have POV-Ray automatically do some extensive interpolation on the sky_sphere for radiosity rays, but that would be less efficient than a preprocessing step.

Grimbert Jérôme commented on Saturday, 30 October 2010, 09:32 GMT

Is the solution to  FS#10  also suitable for this manipulation (adjusting the gamma factor) ?

Christoph Lipka commented on Saturday, 30 October 2010, 15:47 GMT

No, the gamma factor is absolutely unfit for (linearly) adjusting a sky sphere's brightness.

Grimbert Jérôme commented on Sunday, 31 October 2010, 08:05 GMT

Just a thought on the side (I'm still wondering a lot)... If the brightness is the thing to be adjusted (right ?), but the colour is specified as rgb<3D> (let's just forget the alpha/filter|transmit channel(s)), with values than can be out of the range [0,1] (at least for OpenEXR, right ?), wouldn't it make more senses to convert the colour to hsv or hsl, adjust v or l (according to the model), and back in rgb space ?

Now, the discussion in english wiki about HSL_color_space and its disadvantages :
In HSV, the blue primary and white are held to have the same value, even though perceptually the blue primary has somewhere around 10% of the luminance of white (the exact fraction depends on the particular RGB primaries in use). In HSL, a mix of 100% red, 100% green, 90% blue – that is, a very light yellow – is held to have the same saturation as the green primary , even though the former color has almost no chroma or saturation by the conventional psychometric definitions.

So, to adjust the brightness, we should turn to colour in CIELAB (CIE 1976(L*,a*,b*)) colour space, and back to rgb (as it's all we could keep the pixel colour) after adjustement to L*.
(in fact, rgb (gamma adjusted) to CIE 1931 XYZ to CIELAB and back). Formula from&to XYZ/LAB is there, and from/to RGB/XYZ is also available).

Nevertheless, I wonder if instead of adjusting L* we could not instead change the white point reference when converting back from CIELAB to CIEXYZ (this whitepoint must be expressed in CIEXYZ, it's not simply rgb<1,1,1>, but once again we have the formula, so it should not be a real problem to use a traditional boosted rgb-white (like rgb (1.3*<1,1,1>))

Any opinion ? (HSV, HSL, CIELAB with L'=kL or CIELAB with adjusted whitepoint on return)

Christoph Lipka commented on Sunday, 31 October 2010, 10:11 GMT

Conversion to a different color model is neither needed nor useful in this case: Increasing brightness (and by this I mean not perceptual brightness, but physical light intensity) while preserving the color (by which I mean not perceptual color, but the relation between light intensity in the different parts of the spectrum) is just as simple as multiplying the color by a constant.

At best, a transformation to some other color model, adjustment of brightness, and then transformation back to RGB would produce exactly the same result. At worst, that other color model might define "brightness" in a non-physical manner, making it a potentially good model for a color picker or maybe image manipulation, but an unfit one for use in a raytracing engine, where under the hood it's all about physical light intensities (or at least should be).

Grimbert Jérôme commented on Sunday, 07 November 2010, 13:22 GMT

One more question: should the adjustment occurs before or after the gamma correction ?

Christoph Lipka commented on Thursday, 11 November 2010, 17:00 GMT

Of course the brightness adjustment would have to be applied in linear color space, i.e. after gamma decoding (to use a less ambiguous term). Anything else would make little sense in the world of optics - not to mention that it would make the result file-format-specific, as different file formats use different gamma handling approaches. HDRI formats like Radiance HDR or OpenEXR, for instance, store the linear values, without any gamma-correction at all.

Christoph Lipka commented on Saturday, 03 December 2011, 02:56 GMT

implemented with change #5573


Available keyboard shortcuts


Task Details

Task Editing