POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #1 : Re: Random POV-Ray 4 SDL proposal, #1 Server Time
18 Apr 2024 21:44:18 EDT (-0400)
  Re: Random POV-Ray 4 SDL proposal, #1  
From: Kenneth
Date: 15 Dec 2015 05:20:00
Message: <web.566fe81c2ab8183e33c457550@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

>
> My idea would be to use HTML colour format for colours in sRGB space,
> and some other syntax to specify linear colours; internally, they'd both
> be translated to a vector-like linear format, and math operations could
> be done on them.

Personally, as someone who just likes to make nice-looking images and animations
(and not being a 'programmer' per se), the use of HTML color formatting seems
*much* less intuitive than our current vector format. For example, <1,.4,.7> vs.
something like FFDFB  (I made up that last term!) With the vector approach, I
can write a 'first approximation' color quite easily if I want to, then tweak it
by eye. The hex(?) way of doing it requires either a lookup table, or else a
GOOD intuitive knowledge of that kind of coding approach and its visual results.
I suppose there are crack programmers who think in such terms, but I'm certainly
not one of 'em. ;-) (Long ago, I got into HTML coding-- before style sheets--
and even then I thought it 'odd' to have to specify colors in what seemed to be
such an arcane manner.)
>
> As for translating colours to "standard 5-D float vectors", that won't
> happen:
>
> (1) Vectors are vectors, and colours are colours. In my book, using one
> and the same type for them is one of the biggest blunders in POV-Ray's
> current SDL.
>

Here's a funny thing: I've always been under the impression that the original
developers actually *wanted* vectors and colors to use the same coding scheme,
explicitly. For ease of understanding and computation in the SDL. I.e., "A
vector is a color is a...." From a conceptual standpoint, such an arrangement
does make sense, to me.

Another question arises concerning dot-notation (i.e., pulling one of the color
components out of the color vector, for use.) I don't see how that would work
using the FFDFB approach. (I suppose it *could* simply be specified as
FFDFD.red, for example, with POV-ray's internal engine doing the hex-to-float
conversion invisibly. But again, that doesn't seem very intuitive from a user's
standpoint.)

I hope I haven't gotten into meaningless or extraneous details re: your
discussion.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.