POV-Ray

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.

Tasklist

FS#334 - HLS colors

Attached to Project: POV-Ray
Opened by Mike H (SharkD) - Saturday, 23 January 2016, 00:21 GMT
Last edited by William F Pokorny (wfpokorny) - Tuesday, 25 April 2017, 11:38 GMT
Task Type Feature Request
Category Backend → Texture/Material/Finish
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 release
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

It would be nice to be able to specify colors in HLS as well as RGB.

Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.

This task depends upon

Comment by Christoph Lipka (clipka) - Saturday, 23 January 2016, 01:48 GMT

Going by your specification of the feature, that's an absolute no-go. Here's why:

  • There is essentially only one colour model in which a raytracing engine can do its colour math properly: A linear spectral model. At present, POV-Ray uses a linear RGB model, which can pass as an extremely simple (3-band) spectral model. Any other 3-dimensional colour model is fundamentally unsuited for the type of operations most frequently used in a raytracer.
  • For performance reasons, a raytracing engine should not be burdened with supporting different colour models interchangeably.
  • Consequently, a raytracing engine should use linear RGB internally, and linear RGB only (or a spectral model with more bands in case higher colour fidelity is desired).
  • Therefore, linear RGB (or alternatively a spectral model) is, and will always be, the sole colour model by which the POV-Ray render engine interfaces to the outside world. For other colour models support may be provided by means of syntactic sugar in the parser (as in the case of sRGB) or standard macros (as in the case of HLS and others), but either way they will always be converted to linear RGB before passing them on to the render engine. (Even the assumed_gamma keyword is in some sense just syntactic sugar for "screw proper gamma handling in the conversion", and is there solely for legacy reasons anyway.)
  • The colour_map mechanism is indeed part of the render engine. Therefore, the colours in a colour_map will always be linear RGB behind the scenes, and no matter what colour model you originally specified the colours in, the "natural" interpolation will always be in linear RGB space. (Besides, what behaviour would you expect if you specified the colours in a single colour_map using multiple different models?)

In my book there is exatly one reasonable approach to achieve what you are trying to do: Implement a non-linear interpolation mode for colour_map (and also for pigment_map while we're at it), as a feature that is independent of the colour model originally used to specify the colours. it would explicitly take linear RGB colours, interpolate them non-linearly according to some special rule (which may or may not involve actual conversion to HSL), and explicitly produce linear RGB colours again.

As a matter of fact, the basis for such a feature already exists in POV-Ray 3.7.1 (currently in development, with source and semi-official Windows builds publicly available), in the form of the blend_mode keyword, which may already be doing what you're trying to achieve, as one of the modes available uses linear interpolation for chromaticity but non-linear interpolation for brightness.

Comment by William F Pokorny (wfpokorny) - Tuesday, 25 April 2017, 11:38 GMT
  • Field changed: Status (Unconfirmed → Tracked on GitHub)

Now tracked on github as issue #281.

Loading...