Am 25.03.2013 16:55, schrieb Simon Copar:

>>> and of course, a mapping function to get back from spectrum to rgb
>>> (nontrivial, there are several different spectral response function models that
>>> try to approximate the human eye, or a display device).
>>
>> Until now I'd have expected that to be the least problem: Just choose
>> one of the two CIE standard observers, use the response functions to
>> convert to XYZ, and from there to whatever color space is chosen for output.
>
> I have to say that I never really liked XYZ color space. Mapping from XYZ to RGB
> is linear, so there is no difference between converting to XYZ and then to a
> chosen RGB (+gamma correction after that), or precomputing RGB response
> functions and mapping directly to that. There is no additional information in
> XYZ color space, it's just defined to avoid negative values in standard (from
> year 1931, not very representative) rgb physiological response functions. We
> could remove the intermediate step and go directly to the target color space, we
> lose nothing.

Of course that intermediate step can be skipped by just pre-computing 
RGB response curves; but I consider that implementation details rather 
than part of the big picture.

> Sorry for the rant, I got very frustrated recently about the arbitrary
> definition of XYZ space and the difference between physiological and
> standardized color spaces (CIE rgb, scrgb,...).

Well, there's nothing wrong with XYZ as opposed to any other variation 
on the same theme (such as the various RGB color spaces), as long as you 
don't try to do compute color "distances" or do light computations in 
that color space.

> I think that it would make the most sense to let the user override the rgb
> response functions, because this opens the doors for color profile freaks that
> are never satisfied with the default settings. You could use a spectral response
> of a specific display device for maximum accuracy (for instance, if you know
> exactly what projector will display your movie). And for normal users, you would
> just keep scrgb as default.

Nah, color profile freaks wouldn't benefit from custom response 
functions; for that use case, a final conversion step from spectrum to 
XYZ (based on the standard observer) to whatever color profile they 
choose (based on a user-supplied CIE color profile) would be the way to 
go. In this respect, sRGB output would be just a special case of this 
final step.

Custom response functions might still be handy for creating false-color 
renderings of colors outside the visible spectrum, but I'd consider that 
pretty low priority.


> A related solution that also solves these problems, is to take the same set of
> linear equations described above, but instead of just taking the pseudo-inverse
> (and getting least-square solution), you can minimize
> abs(r-r0)+abs(g-g0)+abs(b-b0) and specify constraints a>0,b>0,c>0,d>0. This is a
> linear programming problem [algorithm can be taken straight from numerical
> recipes], which is also mathematically well-defined an will give you an optimal
> and physically meaningful result.

Not exactly what I was trying to achieve, but might be worth 
consideration nonetheless.

> This would of course all be done at parse
> time.

Nope, it's not an option for input images. But some pre-computed values 
and interpolation might do the trick.


> I vote for the second solution, I think it's as good as you can get :)

Sounds like this will cause the resulting spectrum to be governed by


> Just one thought. Now we have filter & transmit options. This works quite well
> for most cases, but is still restrictive. Basically, the light that hits the
> surface can be split in into reflected (seen by camera), transmitted and
> absorbed components in any possible way. Physically, energy conservation only
> requires reflected_color+transmitted_color<1. Right now, "transmit" gives you
> transmitted_color=constant and "filter" gives you
> transmitted_color=constant*reflected_color, and combination of filter and
> transmit gives you something in the middle.
> In rgb space, this is not so bad, but when you go spectral, you lose a lot of
> options.
>
> Instead of transmit & filter we could have a single color parameter
> pigment {
>    color rgb [mycolor] transmission [othercolor]
> }
> and a fallback with old syntax that generates the transmission color according
> to above model.

Absolutely. Internal representation of transmit+filter as full-fledged 
colors is a must for spectral rendering, and exposing this to the user 
is only natural and not a big deal.

The syntax

     color rgb COLOR transmit COLOR

would be perfect, as COLOR could still be a single numeric value, 
automatically giving you the old behaviour of plain white transmission. 
For backward compatibility, "filter" could also be retained, but would 
always expect a single numeric value.

Post a reply to this message