 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Klebs <skl### [at] gmail com> wrote:
> I use POV for graphics work, so I often rely on it to match rgb values
> irrespective of lighting conditions. For example, in 3.6 a 50% gray with no
> light source and ambient 1 is always accurately rendered as RGB 128, 128, 128,
> as long as Display_Gamma in povray.ini is the same as assumed_gamma in
> global_settings or if no assumed_gamma is declared. This is true of image-mapped
> pigments or declared colors.
> In 3.7, however, with the suggested Display_Gamma and File_Gamma set to 2.2, a
> 50% gray (rgb 0.5) with no light source and ambient 1 comes out as RGB
> 186,186,186 or a gray of about 0.73, much lighter. This does not make sense to
> me. I would expect that if ambient is set to 1 with nothing else affecting the
> color, that the rendered output would match the value called for.
The problem is that RGB 128,128,128 is *not* 50% gray, in other words,
exactly half-way between black and white, in any display system (except
perhaps very exotic ones). RGB does not map linearly to brightness in
most displays.
If your monitor has a gamma of 2.2, then RGB 186,186,186 ought to be
pretty close to 50% brightness. If it's not, then you should use a gamma
which matches your display system.
Moreover, RGB 186,186,186 may look exactly 50% bright in your display
system but not somebody else's. For example, there are systems where
display gamma is 1.8 instead of 2.2. In this case the gamma meta-information
in a PNG file exists to display such an image properly in such a system with
a different display gamma. It helps the system make the proper corrections
to make the 50% bright pixels look 50% bright on the target system.
If you are dealing with literal pixel values rather than how they look
on screen, eg. because you are using these pixel values as data for some
purpose, then setting gamma to 1.0 is the proper way of achieving that,
as it stops gamma correction from being made.
Currently if you specify #version 3.6 in your scene, it should make the
current beta to assume 3.6's way of handling gamma (IIRC), but this is still
under discussion and development to make backwards compatibility work better.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bluntly put. You're making this much too complicated. It's certainly less
complicated than dealing with color management for print. You make a picture
that looks good on your computer. It doesn't matter how you do it. (The beauty
of POV, for me at least, is that you have almost complete control to do almost
anything you want. From photo-realism to fractals, from cartoons to caustics.)
If it looks right, it IS right. So you set the gAMA chunk in the PNG to say that
this picture was made on a system with gamma 2.2 or 1.8 or whatever so that
other systems and programs will know how to compensate. If someone's display
gamma is off, then that's a problem with their system display, not with the
picture or how it was made. If another program doesn't read it properly, that's
a problem with how it's understood not how it was written. What you are doing is
pre-correcting the correction. An example: I want to create a simple continuous
gradient from white to black so I tell POV I want a simple series of boxes or
whatever from rgb 1 to rgb 0 in, say, 10% increments. Since POV is a programming
language and not a GUI, I have to blindly tell it what I want it to do. I have
to say something like:
#local i = 0;
#while (i <= 10)
object {box {0 1}
pigment {rgb 1-(i/10)}
finish {ambient 1}
translate (i-5.5)*x
}
#local i = i + 1;
#end
Now what do I get? Not a straight, smooth, gradual gradient from light to dark
but a parabolic curve of values from light to slightly darker but still light to
abruptly skewed to black. It's the relative relation of values not the
brightness that's off. This is not what I asked it to do and if this is how it
will be then you have to change the language to say it differently. As if you
can make something smaller by measuring it with a ruler made longer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen Klebs wrote:
> Bluntly put. You're making this much too complicated.
There is probably some merit both in making things
simple and making them work right. Ideally, of course,
they should be both.
> If it looks right, it IS right.
On the other hand, the amount of time needed to get something
to look right in the first place might depend on whether the
process of rendering is realistic.
> Now what do I get? Not a straight, smooth, gradual gradient from
> light to dark but a parabolic curve of values from light to slightly
> darker but still light to abruptly skewed to black.
I have to admit I don't understand this either. Until now I
thought that since 3.7 now uses a linear color space, 0.5 would
represent a true midgray and all the nifty gamma handling ensures
that everyone perceives that midgray on their display when viewing
the image file. So I'd also have expected the end result of your
test scene to visually yield evenly spaced brightness steps.
Looking at the png itself it seems the upper two rows use 127
for midgray while the lower uses 186. From all I heard so far
186 should appear as midgray on a calibrated gamma 2.2 display
so that would appear to be correct. But I too perceive the
upper two rows as more visually correct. It's as if my lcd
used linear color space. I wonder if the Windows 7 built-in
display calibration is somehow playing tricks on me.
You can get the old behavior with assumed_gamma 2.2 or
by replacing rgb x with rgb pow(x,0.45).
Independent of this issue: Would it be useful to have a
setting of "color_gamma" that tells POV-Ray how to interpret
literal color values specified in SDL? The default value of 1.0
would yield the current behavior while e.g. 2.2 would internally
convert a value as rgb 186/255 to rgb 0.5 without the need for
plastering your code with gamma macros.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> Stephen Klebs wrote:
>
> > Now what do I get? Not a straight, smooth, gradual gradient from
> > light to dark but a parabolic curve of values from light to slightly
> > darker but still light to abruptly skewed to black.
>
> I have to admit I don't understand this either. Until now I
> thought that since 3.7 now uses a linear color space, 0.5 would
> represent a true midgray and all the nifty gamma handling ensures
> that everyone perceives that midgray on their display when viewing
> the image file. So I'd also have expected the end result of your
> test scene to visually yield evenly spaced brightness steps.
I too had assumed the same thing. (But I haven't yet tried out the relevant 3.7
beta and its gamma change, so I don't want to say too much more, because my
assumption could be wrong.) Yet Stephen's result does seem unexpected (that is,
based on my experience with v3.6.1 using assumed_gamma 2.2, not 1.0--I *thought*
the new 3.7 change was meant to match that, at least when viewing POV-Ray's
preview image.)
>
> [clip] I too perceive the
> upper two rows as more visually correct.
Same here (viewing it on my CRT monitor, BTW.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 30.11.2010 23:58, schrieb Christian Froeschlin:
>> Now what do I get? Not a straight, smooth, gradual gradient from
>> light to dark but a parabolic curve of values from light to slightly
>> darker but still light to abruptly skewed to black.
>
> I have to admit I don't understand this either. Until now I
> thought that since 3.7 now uses a linear color space, 0.5 would
> represent a true midgray and all the nifty gamma handling ensures
> that everyone perceives that midgray on their display when viewing
> the image file. So I'd also have expected the end result of your
> test scene to visually yield evenly spaced brightness steps.
>
> Looking at the png itself it seems the upper two rows use 127
> for midgray while the lower uses 186. From all I heard so far
> 186 should appear as midgray on a calibrated gamma 2.2 display
> so that would appear to be correct. But I too perceive the
> upper two rows as more visually correct. It's as if my lcd
> used linear color space. I wonder if the Windows 7 built-in
> display calibration is somehow playing tricks on me.
No, it's your eye playing tricks on you.
Our eyes are highly calibratible optical measurement tools - they work
as well at a brightness of 10% as at 1,000% (and then some), and get
object colors right regardless of lighting conditions.
There's the key.
Grab a piece of 100% white cardboard and another piece of 90% gray
cardboard.
Now dim the light to half brightness. Obviously, your white cardboard
will now reflect only 50% of full-brightness white into your eye, and
your gray cardboard will reflect only 45% of full-brightness white.
So the absolute difference between the two pieces of cardboard has
diminished from 10% full brightness to 5% full brightness. But our eyes
are designed and trained to look not for the absolute light intensity,
but for /relative/ difference, so that we can identify the "pigment" of
objects irrespective of lighting conditions. The /apparent/ brightness
difference between 45% and 50% is therefore roughly the same as between
90% and 100%.
As a result, a truly linear gradient doesn't /appear/ linear to us: The
"distance" between 10% and 20%, for instance, is percieved as roughly
equal to that between 50% and 100%. Go figure.
(Theoretically this would imply that a /logarithmical/ gradient would
appear "linear" to us; however, that's not exactly the case either, as
human vision is a bit more complicated than that. My point here is that
perception of brightness is surprisingly non-linear.)
> You can get the old behavior with assumed_gamma 2.2 or
> by replacing rgb x with rgb pow(x,0.45).
... or by "rgb x gamma 2.2".
> Independent of this issue: Would it be useful to have a
> setting of "color_gamma" that tells POV-Ray how to interpret
> literal color values specified in SDL? The default value of 1.0
> would yield the current behavior while e.g. 2.2 would internally
> convert a value as rgb 186/255 to rgb 0.5 without the need for
> plastering your code with gamma macros.
While the idea is compelling, there's a nasty catch to it: With
POV-Ray's SDL being as powerful as it is, while lacking a clear
distinction between colors and vectors, it is pretty difficult - if not
impossible - to draw a clear boundary between "gamma land" and "linear
country" that is both safe, sane and self-consistent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.12.2010 00:55, schrieb Kenneth:
>> [clip] I too perceive the
>> upper two rows as more visually correct.
>
> Same here (viewing it on my CRT monitor, BTW.)
Perfectly normal, and perfectly wrong (from a physical viewpoint that is).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This whole issue of "realistic" is somewhat unrealistic. Photo-realism or
whatever one calls it is as much an artificial convention as any other means of
artistic expression. But this gets us into a relativistic riddle about light and
perception and pictures and how the brain processes visual sensations and how we
see things that's well beyond this issue. Even when we assume that we want to
make a picture that "looks just like" say a sunset over a lake we are in effect
not reproducing how we would see such a sunset but how we think we see it. We
are making a picture of it.
Lecture follow so you can skip to step w: The history of visual representation
has only recently adopted the notion that we see in pictures. As if we could see
ourselves seeing. Like a little observer standing behind our retina looking out
as if viewing a motion picture or a computer screen. As the state of perception
theory stands now the model of a "realistic" picture on the retina is being
replaced by the idea of the retina as just a converter box, while it's the
visual cortex that post-processes those visual sensations in ways that alter
their purely physical or mathematical input. Note, for example the banding on
the gradient example. That scalloping effect that enhances edge, is not in the
physical input but in the way the brain processes patterns of light and one
could say distorts the purely, as Steve Jobs would say, "retinal display". There
are several artificial notions in POV that do not exist in the real perceptual
world. Like ambient. Nothing has color without light unless it's a source of
light. It's just adjust control Sorry for the lecture here but I've been
fascinated with how we see for a long time. How the "human machine" sees is
truly a mystery.
With regard the new gamma model that's being applied to POV, two points: POV is
first a description language not like Photoshop were you just slide sliders back
and forth until things look right. There is nothing wrong and even wonderful
about this approach as long as you have immediate visual feedback. In POV you do
not. It's like taking photographs in the pre-digital age. You use an educated
guess to adjust aperture and f-stop or whatever and only in the darkroom do you
finally see what develops. Add to this add the fact that rendering and parsing
do not take a few minutes but sometimes days or even weeks. So as a description
language you have to learn techniques to anticipate what you want to come out or
at least to get something that after a week is not going to look like crap. So
when you tell the program draw a straight line from point A to point B, you
don't want to see at the end of the process something that not only looks like a
curve but is a curve. So to get to the point of the gradient example. It tells
POV that we want a linear succession values over a certain distance what it does
is give an exponential curve. That's fine but not what I intended and, if you
can't depend on 1 plus 1 plus 1 etc coming out a 3 or 4 or what ever, how do you
use a language that's going to be retranslated to mean something totally
different than what you expected it to say.
In 3.6 the evenly ramped gradient looked right. The values reported in Photoshop
or whatever said yes indeed 1 plus 1 is two. I've used POV in every possible
way, on Macs and PCs, to make images that looked fine in IE and FireFox or
Chrome or in print, and have in fact never encountered problems as serious as
this major revision seems to solve. I would like to see a concrete scene we
could render in both versions where it is demonstrated the need for the change.
But now there seems no way of predicting but more trial and error. I've used POV
for a long time because I love it like an addict, it's surprises and limitless
control. Now everything feels even more unpredictable and confusing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> No, it's your eye playing tricks on you.
>
> Our eyes are highly calibratible optical measurement tools - they work
> as well at a brightness of 10% as at 1,000% (and then some), and get
> object colors right regardless of lighting conditions.
>
>
This is not correct. You only understand the physics of the optical system, but
not the physiology nor the psychology. This is not how we see. You are talking
as if you could see yourself seeing and you can not. What you are seeing is a
model of how you think things appear. This is a very subtle and complex mystery.
The eye does not see. The lens, the retina or whatever. The are merely
transmission and conversion mechanisms. It's the brain and, to be more exact,
it's the visual cortex that perceives things. And it is nothing like a camera --
a long time but antiquated model for perception. It is not a camera but a
complex post-processing system, that enhances edges, exaggerates movements, etc.
that are not part of the optical or sensory input. And even to call it a machine
is not accurate. I suggest you read some more current literature on the
physiology of perception, how the visual cortex works, and in the artist realm a
book like Gombrich's Art and Illusion. Your are right about the so-called
"constancies" but this is not a matter of optics but of psychology and much of
that psychology comes to the conclusion that what we see less about how we see
"reality" but how we see what we think we see.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I wonder if the Windows 7 built-in
> display calibration is somehow playing tricks on me.
>
Actually Windows 7 is the first version of Windows that is not completely
color-blind. The color management and monitor calibration tools in Color
Management in the Control Panel are really as sophisticated as those long
existing in Mac. There you can choose to adjust your color model to match
several possible viewing situations: monitors, offset, web or print
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Grab a piece of 100% white cardboard and another piece of 90% gray
> cardboard.
>
> Now dim the light to half brightness. Obviously, your white cardboard
> will now reflect only 50% of full-brightness white into your eye, and
> your gray cardboard will reflect only 45% of full-brightness white.
>
> So the absolute difference between the two pieces of cardboard has
> diminished from 10% full brightness to 5% full brightness. But our eyes
> are designed and trained to look not for the absolute light intensity,
> but for /relative/ difference, so that we can identify the "pigment" of
> objects irrespective of lighting conditions. The /apparent/ brightness
> difference between 45% and 50% is therefore roughly the same as between
> 90% and 100%.
>
> As a result, a truly linear gradient doesn't /appear/ linear to us: The
> "distance" between 10% and 20%, for instance, is percieved as roughly
> equal to that between 50% and 100%. Go figure.
>
What you are missing here is that this ability for the brain to retain a
constant relation between widely varying changes in size, shape, colors or
perspective is not something you need to correct in the picture. The brain does
it. It works in a photograph as well, which is just a neutral recording device.
The Greeks made this error in their temples, for example. They thought by
flaring out the upper proportions in a trapezoid they were "correcting" the
dimension to make them look right.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
