(L) [2014/06/13] [tby ypoissant] [Re: Color space: when to multiply by the matrix] Wayback!>> tarlack wrote:as long as there is no fluorescence, incomplete linear color spaces can be used (such as sRGB), but what about fluorescence ? Couldn't this cause out-of-gammut colors to appear ?
Probably yes. But aren't gammuts only of concern for an input and output devices? What matter does it make if the calculations produce out of gammut values during calculations? The real gamut that count is the output gamut. The end result is that those out of gamut calculation values will be clipped when transformed to output color space. But there are little we can do about that.
I see the gammut issue somewhat similar to HDR data being mapped to LDR of the output device. As long as the internal calculations can represent HDR data. I'm good. As long as the internal calculations can represent as much out of gamut values as is required, I feel I'm good too.
>> Would a complete color space such as XYZ be better for this specific case
I experimented with different color spaces a few years ago, and XYZ turned out to be not too far from the worse color space to use for internal calculations. And I think this is due to the metameric property of XYZ space. The color spaces that produced the best results are spaces based on filtering the spectrum into equal width bands similar to the filters used in digital cameras. If most of your input colors come from digital cameras, then you would be better use the raw RGB data from the camera and an equal spaced 3-bands RGB representation for your internal calculations.
(L) [2014/06/16] [tby tarlack] [Re: Color space: when to multiply by the matrix] Wayback!I see your point, and agree with you, even if negative values may seem strange in the middle of computations [SMILEY :)] Maybe that's why RGB rendering is close to a standard for non-spectral rendering, as your experiments have shown. At least, now I understand why !
(L) [2014/08/08] [tby Chaos] [Re: Color space: when to multiply by the matrix] Wayback!Hi,
Thanks everyone for your insights, all interesting comments! To add some context, one of the reason people are trying to render 'with the color space X', instead of converting all colors to a more standard (CIE) RGB space is because of 'plates'.
Basically, a client would give you a backplate in a particular color space A. You want to use this plate as a light, or reflect it, or as a 2D element. However, you want to make sure that the areas of your render the directly show the plate *exactly* match with the plate that was given to you. It means you can't go from color space A to color space B (and clamp negatives), then (after the render) from B back to A, because you wouldn't retrieve your original colors.
Now of course, you could try and hack things such that you do all your computations in color space B, by internally converting everything from A to B, apart from the parts where you are projecting the plate (i.e. do not convert and/or clamp on areas using the plate color, but only for camera rays, etc...), so that the final render matches the plate on all relevant areas. But then you are just moving the issue into the pure mirror reflections (that may be slightly off compared to the plate), or into pure specular transmission (changing the plate colors when see through a window), etc...
All-in-all, quite a pain to accomodate ^^'
Cheers,
Jonathan