MDenham schrieb:
> *goes off to figure out a good syntax for true spectral
> lighting and pigmenting, which is probably more in the realm of additions to
> 4.0 or later but would allow for "true" conversions both ways as well as other,
> odder effects*

Yeah, that would be something nice to have.

Including fluorescence, please :-)

Post a reply to this message

MDenham wrote:
> Eh, negative luminance + positive Cr/Cb = <+,-,+> potentially (forgive the
> massively bastardized variation on standard color syntax ;-D) - and negatives
> on green are, from looking at normal "RGB vs. real coloring" gamut diagrams,
> probably the most common colors that exist but aren't displayable.  Also, the
> engine already handles "impossible" colors (components all negative,
> hypersaturated colors that extend outside the gamut in the opposite direction,
> &c.) so it's not like that's necessarily an issue other than the obvious "it'll
> look weird and may not behave entirely correctly".
> 

Jpeg's YCbCr is a 1:1 adaption of the European standard tv signal 
encoding (CCIR/ITU Rec. 601 IIRC) with the advantage that you can just 
drop the CbCr part. This did make people happy who couldn't afford a 
color tv. Sending a signal with negative Y would have made people quite 
unhappy 'cause you just imploded their brand new tv set ;)
Seriously, jpeglib uses a strict range checking anyway (to avoid such 
issues as the DCT compression might introduce some noise) and YCbCr is 
just not *designed* to represent anything outside the gamut of a tv 
monitor from this time. Thats not as bad as it sounds because, if I'm 
not mistaken, this gamut was even defined wider than the currently 
accepted sRGB gamut.


> Isn't the "formula" for CMYK->RGB essentially specific to an "ideal" ICC
> profile?

An "ideal" CMYK ICC profile is somehow meaningless and does not exist.
Therefor such a 'formula' cannot exist and this was from the very 
beginning my point ;)
What we have is a bunch of numerous international standards within the 
printing business and an ICC profile is used to make clear to what 
standard the CMYK separation does refer, tells something about the 
intended ink set, raster...  and *a lot* more things.


> *goes off to figure out a good syntax for true spectral
> lighting and pigmenting, which is probably more in the realm of additions to
> 4.0 or later but would allow for "true" conversions both ways as well as other,
> odder effects*
> 

This is of course also something I would like to have, but as I'm not so 
patient I'll wait with such things until computing power evolves much 
more...


-Ive

Post a reply to this message

Ive wrote:

> I do also remember that I have a format specification 
> somewhere but as this might even be on some old 3.5" disk chances are 
> not very good that I will ever find it again.

http://www.wotsit.org/list.asp?al=I

Post a reply to this message

Ive schrieb:
> To make life easier that's the libpng call for getting the
> sRGB chunk information. For the sole purpose of gamma correction you can 
> safely ignore the value that is returned as sRGB_intent.

How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
that do the same job?

Another thing: The sRGB spec speaks of aiming to achieve an overall 
viewing gamma of 1.125; am I however correct in assuming that decoding 
sRGB-encoded material according to the sRGB decoding function will 
nonetheless reconstruct the /linear/ data?

Otherwise, if sRGB-encoded data was expected to already account for that 
desired viewing gamma, for raytracing purposes it would theoretically 
have to be compensated for, both when decoding and encoding.

Post a reply to this message

clipka wrote:

> How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
> that do the same job?
>

You are aware that you are breaking the poor mans idea of encapsulation 
by directly accessing the fields from png_inf ;)

And it's by no means time critical, so why not just use the API call?


> Another thing: The sRGB spec speaks of aiming to achieve an overall 
> viewing gamma of 1.125; am I however correct in assuming that decoding 
> sRGB-encoded material according to the sRGB decoding function will 
> nonetheless reconstruct the /linear/ data?
>

The sRGB viewing gamma of 1.125 is just another (poor mans) attempt of 
taking the environment illumination of some typical pc user into 
account. There are much more complicated attemps from the ICC and I 
really think we do not need to care about this.


-Ive

Post a reply to this message

clipka wrote:

> How about just checking for "png_inf->valid & PNG_INFO_sRGB"? Shouldn't 
> that do the same job?
>

You are aware that you are breaking the poor mans idea of encapsulation 
by directly accessing the fields from png_inf ;)

And it's by no means time critical, so why not just use the API call?


> Another thing: The sRGB spec speaks of aiming to achieve an overall 
> viewing gamma of 1.125; am I however correct in assuming that decoding 
> sRGB-encoded material according to the sRGB decoding function will 
> nonetheless reconstruct the /linear/ data?
>

The sRGB viewing gamma of 1.125 is just another (poor mans) attempt of 
taking the environment illumination of some typical pc user into 
account. There are much more complicated attemps from the ICC and I 
really think we do not need to care about this.


-Ive

Post a reply to this message

Ive schrieb:

> You are aware that you are breaking the poor mans idea of encapsulation 
> by directly accessing the fields from png_inf ;)
> 
> And it's by no means time critical, so why not just use the API call?

Because POV-Ray currently uses the same construct to check for presence 
of a gAMA chunk?

No other reason.

> The sRGB viewing gamma of 1.125 is just another (poor mans) attempt of 
> taking the environment illumination of some typical pc user into 
> account. There are much more complicated attemps from the ICC and I 
> really think we do not need to care about this.

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?

Post a reply to this message

Le_Forgeron wrote:
> color srgb <1.8,0.5,0.5,0.5>

Ugly. When I see four components, I already have my mind trained to expect
the first three are RGB and the fourth is transparency (which kind of
transparency depends on whether it's rgbf or rgbt).

Post a reply to this message

Warp wrote:
>   Of course if the user has not specified an assumed gamma for the input
> image either, then the default should probably be Display_gamma (ie. so
> that the image will look in POV-Ray the same it looks when viewed with
> some image viewing program).

Wouldn't this cause the scene to render differently on different computers,
in a way that cannot be easily corrected afterwards? (if the entire image
has wrong gamma, it can be corrected, but if a single texture image_map has
wrong gamma, you can't easily fix it by postprocessing the output image)

Post a reply to this message

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.

At least with spectral colors and lights you could simulate metameric 
failure.

-- 
~Mike

Post a reply to this message