clipka wrote:
> Hey, get real: You need to press the "shift" key for quite a host of
> things, I guess. As a German, for instance, I need to press "shift" to
> get a multiplication asterisk, dividing slash, opening or closing
> parentheses, quotes etc,

And for all nouns too, right? :)

Post a reply to this message

Mike Raiford schrieb:
> That would be neat to have... But, how to implement? How would you 
> convert from an rgb-specified color to a spectrally specified color?

Oh, I guess that shouldn't be too difficult: Just multiply each color 
component with the spectral output of some standard phosphor for that 
color - et voila. It would boil down to an 3xN matrix multiplication.

Generating the output image should be just as easy: Using an Nx3 matrix 
based on the CIE tristimulus curves would give the color in XYZ color 
space. From there it's just another 3x3 matrix multiplication to csRGB. 
Consequently, there must also exist some Nx3 matrix to take us directly 
to sRGB.)

Of course, to make any /real/ use of this feature, there would neet to 
be an additional color syntax to have more control over a color's spectrum.


> fluorescence would be quite fun to have. Impractical, but fun to play with.
> 
> At least with spectral colors and lights you could simulate metameric 
> failure.

Whatever that may be...

Post a reply to this message

clipka wrote:
> Because POV-Ray currently uses the same construct to check for presence 
> of a gAMA chunk?
> 
> No other reason.
> 

Ah, OK then.


> So, in other words, it is indeed just a recommendation for viewing 
> software? Something like, "guys, this encoding scheme makes sure you can 
> reconstruct the linear data - we suggest however you don't just 
> compensate for actual hardware gamma, but also for viewing environment; 
> if in doubt, we suggest trying to achieve those 1.125". Did I get that 
> right?

Yes sir. But it might be the reason why the beta from the sRGB transfer 
function was chosen the way it is, but this is also something we do not 
need to care about.

Note to myself: reread the sRGB specs.
Answer from myself: has to wait 'till tomorrow.

-Ive

Post a reply to this message

Le 14/09/2009 19:53, Mike Raiford nous fit lire :
> clipka wrote:
> 
>> Yeah, that would be something nice to have.
>>
>> Including fluorescence, please :-)
> 
> That would be neat to have... But, how to implement? How would you
> convert from an rgb-specified color to a spectrally specified color?
> 
> fluorescence would be quite fun to have. Impractical, but fun to play with.
> 

You would need to separate real spectrum (color of light) from
transformation matrix (square matrix) (color of pigments).
If using more than one color space (light using spectrum, some pigments
using rgb... ) you need an internal adaptation to convert the matrix
into the dimension/base of the light-ray. You need one anyway at the
camera to return to rgb. (linear or gamma corrected...) (well, not rgb
per se, but whatever the image format would be using... usually rgb so far)

Currently, we have pigment on diagonal matrix (Or r'= (I(p)).r )
(r=ray, p=pigment, I=Identity matrix). Not a big difference, just r'=p.r
with p [n,n], r[1,n] instead.

The basic trick is to propagate on the color/base of the light source.
Merging lights is another part of the fun, you either propagate the
light color as a collection of lights color until the camera (applying
the weights along the ray progression), optionnaly optimising each
color-spectrum system (only 1 spectral component, only 1 rgb, only one
cmyb... ) to reduce the stack size. Or you convert all to an internal
comprehensive base without loss (if such beast can exist ?)

The camera/file writing endpoints just convert that collections of
partial ray-color into the expected component system.

Wondering, is ambient light (global setting) in rgb or just gray ?

> At least with spectral colors and lights you could simulate metameric
> failure.
> 
See you had already the answer: spectral light is a 1-D vector, spectral
color is a 2-D vector,aka matrix (usually only the main diagonal is
used, but frequency converter, bichromism... ). You knew it needed two
different concepts/objects.

In fact the reflection's colour is a matrix, and the refraction's colour
is another. (Today, refraction = coef*reflection ... known as filter)
Transmit should remains a single number, right ?

Post a reply to this message

Nicolas Alvarez schrieb:

>> Hey, get real: You need to press the "shift" key for quite a host of
>> things, I guess. As a German, for instance, I need to press "shift" to
>> get a multiplication asterisk, dividing slash, opening or closing
>> parentheses, quotes etc,
> 
> And for all nouns too, right? :)

Which makes me think - isn't it remarkable that the most common word in 
the English language that is capitalized happens to be a particularly 
egoistic one?

In the German language, on the other hand, it happens to be the 
respectful variant of the 2nd person pronouns that stand out capitalized 
over all their kin ;-)

Post a reply to this message

Le_Forgeron schrieb:
> In fact the reflection's colour is a matrix, and the refraction's colour
> is another. (Today, refraction = coef*reflection ... known as filter)
> Transmit should remains a single number, right ?

Are you sure about this?

For diffuse reflection you're right: That one would need a matrix, to 
account for fluorescence effects. The material absorbs light, and 
re-emits the energy of it at a different wavelength in random 
directions. But do there exist any (practically relevant) effects where 
a photon loses or gains energy without being scattered quite randomly?

Post a reply to this message

clipka wrote:
> Mike Raiford schrieb:
>> That would be neat to have... But, how to implement? How would you 
>> convert from an rgb-specified color to a spectrally specified color?
> 
> Oh, I guess that shouldn't be too difficult: Just multiply each color 
> component with the spectral output of some standard phosphor for that 
> color - et voila. It would boil down to an 3xN matrix multiplication.
> 
> Generating the output image should be just as easy: Using an Nx3 matrix 
> based on the CIE tristimulus curves would give the color in XYZ color 
> space. From there it's just another 3x3 matrix multiplication to csRGB. 
> Consequently, there must also exist some Nx3 matrix to take us directly 
> to sRGB.)
> 
> Of course, to make any /real/ use of this feature, there would neet to 
> be an additional color syntax to have more control over a color's spectrum.
> 

You would definitely want a way to define the observer and the pigments. 
One thing you would need to be careful of is colors defined simply by 
RGB would be susceptible to metameric failure under light sources that 
have strong lines in their spectrum (see below)

>> fluorescence would be quite fun to have. Impractical, but fun to play 
>> with.
>>
>> At least with spectral colors and lights you could simulate metameric 
>> failure.
> 
> Whatever that may be...

http://en.wikipedia.org/wiki/Metamerism_%28color%29
-- 
~Mike

Post a reply to this message

Ive schrieb:
> What I have to add are a few notes about file-format gamma handling:
...
> did I forget something, GIF? not much to say there but usually gamma 
> corrected in between 1.4 and 2.4 - its a matter of guessing again.

How about TIFF? Not that it would probably matter much, if the support 
is as broken as you say, but still...

Would it be a safe bet to presume sRGB for those as well?

Post a reply to this message

Le 14/09/2009 20:38, clipka nous fit lire :
> Le_Forgeron schrieb:
>> In fact the reflection's colour is a matrix, and the refraction's colour
>> is another. (Today, refraction = coef*reflection ... known as filter)
>> Transmit should remains a single number, right ?
> 
> Are you sure about this?

Today, reflection is just a 1D-vector (3 components: R,G,B), and docs says:

The 4th component, called filter, specifies the amount of filtered
transparency of a substance. Some real-world examples of filtered
transparency are stained glass windows or tinted cellophane. The light
passing through such objects is tinted by the appropriate color as the
material selectively absorbs some frequencies of light while allowing
others to pass through. The color of the object is subtracted from the
light passing through so this is called subtractive transparency.

The 5th component, called transmit, specifies the amount of non-filtered
light that is transmitted through a surface. Some real-world examples of
non-filtered transparency are thin see-through cloth, fine mesh netting
and dust on a surface. In these examples, all frequencies of light are
allowed to pass through tiny holes in the surface. Although the amount
of light passing through is diminished, the color of the light passing
through is unchanged.

### end of citation

I would expect transmit to not suffer ior, whereas filter to do. [see
later **]

For filter handling, look at source/backend/render/trace.cpp, circa line
928 : the filtering accumulator get added with the product of single
filter by surface colour (vector rgb). If it was independent, it would
use a different information instead of multiplying for that.
(and it might be more memory consuming, but saving 3 "*" each
ray/intersection, but that would not matter i guess)

at least, it looks like ambient finish can be colored, sort of a good
news for me.

** : it seems that whatever, filter or transmit, both get ior in play,
as a single ray is shot (line 963, trace.cpp again). Which somehow is
not what I would expect from my reading of the docs.

Transmit is refracted, unfiltered;
Filter is refracted, filtered by layer colour (!?)

Reflected colour is special (according to metallic reflection and such
fancy), but basically has far more control (ambient, diffuse, reflection...)

The fishy thing here seems to be that the same colour for reflection is
used for refraction/filter.

I might wish for a second Transmit, straight line for incoming rays, for
at least semi-refracting objects (real see-thru when ior come into play)




> 
> For diffuse reflection you're right: That one would need a matrix, to
> account for fluorescence effects. The material absorbs light, and
> re-emits the energy of it at a different wavelength in random
> directions. But do there exist any (practically relevant) effects where
> a photon loses or gains energy without being scattered quite randomly?

The notion of diffuse refraction (sort of) could be a perturbation of
the normal, or some integration of a sampled cone...

For straight refraction, I know at least of laser-protection filter.

And whether a laser-beam is obtained from excitation of peripheral
(reflection) or of internal (refraction)

For the SDL, at least it would allow a refraction on a black reflecting
glass.

Now, the real question might be to modelise the refraction at the
surface, or in the media only ? Should the surface_color*filter be
dropped for an additional refracted transmit (bis, sort of) ?
Should we continue to fake a "filtering" (the actual refraction) ?




And should we bother for pleochroism ? what about birefringence ?

(from wikipedia, handle with care: Cotton (Gossypium hirsutum) fiber is
birefringent because of high levels of cellulosic material in the
fiber's secondary cell wall.

If Cotton is not everywhere... )

Maybe that's a part for media, not pigment.

Post a reply to this message

clipka wrote:
> How about TIFF? Not that it would probably matter much, if the support 
> is as broken as you say, but still...
> 
> Would it be a safe bet to presume sRGB for those as well?

Given the facts that the used RGBA-interface from libtif applies a 
simple gamma correction of 2.2 before returning the RGBA 8bit values 
when the original image data did use color formats like L*a*b or Luv 
(linear ones) and most of the libtif code dates back to times long 
before sRGB was even specified I would vote for just an inverse 2.2 
correction. Should be at least close for almost 90% of randomly selected 
TIFF's.

TIFF has for 'everything' some tags but does not have some simple gamma 
tag like PNG. Instead it has tags that would contain complete LUT's for 
each color channel. But the RGBA-interface ignores those anyway. And 
most contemporary TIFF's rely on embedded ICC profiles and this is also 
not supported when using this interface.

-Ive

Post a reply to this message