I just installed a new widescreen flat-panel monitor for my computer; I'm
currently in the process of adjusting its colors, tint, gamma, etc. (This never
seems to be easy; it used to be a LOT easier on my older CRT monitors.)

But I've noticed-- after all these years!--a strange phenomenon when using
POV-Ray's 'gamma adjustment' instructions at  "3.2.3.2 Setting your Display
Gamma" -- specifically concering the image there, that goes from gamma 0.0 to
gamma 3.0 in steps.

That image has been part of POV-Ray for a long time-- probably created when the
world still used CRT monitors(?) But I'm wondering if a new 'kind' of image may
be required, for setting up modern monitors.  In a nutshell, it seems that the
'proper' visual gamma of the chart *changes*, depending on the visual SIZE of
the chart on the (discreet-pixel) monitor, vis a vis the monitor's chosen
resolution (and/or the number of discrete pixels it has)--  specifically, the
appearance of the black/white horizontal 'comparison' lines next to the gray
swatches.  I could be wrong, but their appeance seems to depend on whether the
lines actually 'line up' with the monitor's pixels...the result being an
apparent change in what should be the 'proper' gamma.

As an experiment, I downloaded the gamma chart image and brought it up in
several of my image apps. There, it's an easy matter to reduce the screen size
of the chart... not by actively reducing its pixel count, but by simply using
the app's 'magnifier' tool. A *smaller* appearance of the chart changes what WAS
a proper 2.2 gamma appearance to a gamma of 1.0! Of course, the app itself (or
the monitor or computer?) must be using some kind of internal 'blending' to do
this, which may be the reason--so I could be wrong about my method. But it's
something I noticed-- in a less extreme way-- when using just the POV-Ray help
file and  its chart, when I changed the monitor's resolution.

All in all, this is technical mystery to me. Comments are welcome; I'd LIKE to
be proven wrong ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> That image has been part of POV-Ray for a long time-- probably created when the
> world still used CRT monitors(?)

That is indeed the case.

> But I'm wondering if a new 'kind' of image may
> be required, for setting up modern monitors.  In a nutshell, it seems that the
> 'proper' visual gamma of the chart *changes*, depending on the visual SIZE of
> the chart on the (discreet-pixel) monitor, vis a vis the monitor's chosen
> resolution (and/or the number of discrete pixels it has)--  specifically, the
> appearance of the black/white horizontal 'comparison' lines next to the gray
> swatches.  I could be wrong, but their appeance seems to depend on whether the
> lines actually 'line up' with the monitor's pixels...the result being an
> apparent change in what should be the 'proper' gamma.

That's a perfectly correct observation: Setting your operating system's display
resolution to something other than the monitor's /native resolution/ will cause
the monitor to perform interpolation, which means averaging pixel values.
Depending on how this is implemented, it will rarely be a linear interpolation
of physical brightness.

(The striped patter in itself is a means to force linear interpolation of
physical brightess: Squinting your eyes a bit, your vision is blurred, blending
the black and white stripes to a uniform patch of grey with the same total
brightness.)

While this fact is indeed not mentioned in the reference section, the tutorial
section on gamma handling (?.3.4) does sport a note to this effect.


> As an experiment, I downloaded the gamma chart image and brought it up in
> several of my image apps. There, it's an easy matter to reduce the screen size
> of the chart... not by actively reducing its pixel count, but by simply using
> the app's 'magnifier' tool. A *smaller* appearance of the chart changes what WAS
> a proper 2.2 gamma appearance to a gamma of 1.0! Of course, the app itself (or
> the monitor or computer?) must be using some kind of internal 'blending' to do
> this, which may be the reason--so I could be wrong about my method. But it's
> something I noticed-- in a less extreme way-- when using just the POV-Ray help
> file and  its chart, when I changed the monitor's resolution.

In this experiment, the interpolation is indeed performed before the image even
reaches the monitor, namely by the image displaying software; and indeed this is
also rarely done linearly with respect to physical brightness, and thus also
messes with the original intention of the image.

This issue is also explicitly taken into account by the tutorial section on
gamma handling.


> All in all, this is technical mystery to me. Comments are welcome; I'd LIKE to
> be proven wrong ;-)

No, you're perfectly right in your observations.

Post a reply to this message

"clipka" <nomail@nomail> wrote:

> That's a perfectly correct observation: Setting your operating system's
> display resolution to something other than the monitor's /native
> resolution/ will cause the monitor to perform interpolation...

Yes, that occured to me as well (even though I didn't know or remember about the
documentation alluding to it.) In my case, I had changed my 1920 X 1280
monitor rez to 1600 X 900-- the obvious root cause of the problem. (The easiest
way around this is for me to do the gamma calibration at the native
resolution, *then* change it to 1600 X 900.)
>
> ...which means averaging pixel values. Depending on how this is
> implemented, it will  rarely be a linear interpolation of physical
> brightness.
>
Indeed; the 'gamma' video you posted previously-- with its explanation of a
'darkening' effect when blurring colors in gamma 2.2 space-- was on my mind when
I was writing my post ;-) My experiment of reducing the visual size of the gamma
chart (on the monitor)-- and seeing a darker result for the chart's horiziontal
lines-- now seems like a direct result of that. Although, it didn't occur to me
that such a thing happens at the monitor/graphics driver level; I naively
thought it was the fault of my image-viewer apps.
>
> (The striped pattern in itself is a means to force linear interpolation of
> physical brightess: Squinting your eyes a bit, your vision is blurred,
> blending the black and white stripes to a uniform patch of grey with the
> same total brightness.)
>
Yep, that's how I've always done it-- sometimes standing back as far as 15 feet
from the monitor, then blurring my eyes (which isn't difficult, at my age!)
>
> While this fact is indeed not mentioned in the reference section, the tutorial
> section on gamma handling (?.3.4) does sport a note to this effect.
>
I'll take another look there; I must have glossed over that bit of info.

This 'non-linear' blending/blurring phenomenon on a typical gamma 2.2 monitor
could conceivably have deeper ramifactions-- for example, when rendering
a particular kind of scene in POV-Ray. Here's a thought experiment: Let's say
that a flat surface there, facing the camera, has a gradient-y pigment or
'normal' pattern applied to it-- a very *small* pattern with a 'sharp' color_map
and high frequency, like ...
[0.5 rgb 0]
[0.5 rgb 1]

If that object is positioned way off in the distance (relative to the camera), I
could forsee it having a *darker* blended appearance in the final image than if
it were closer to the camera (where the alternating black/white pattern could
actually be seen as individual lines.) Due solely to the 'non-linear' blending
by the monitor of the black/white combination. Micro-normals come to mind as
well, the darker blending effect depending on the orientation of the object and
its distance. But all of this is guesswork, of course.

Post a reply to this message

Am 16.10.2017 um 16:41 schrieb Kenneth:

> This 'non-linear' blending/blurring phenomenon on a typical gamma 2.2 monitor
> could conceivably have deeper ramifactions-- for example, when rendering
> a particular kind of scene in POV-Ray. Here's a thought experiment: Let's say
> that a flat surface there, facing the camera, has a gradient-y pigment or
> 'normal' pattern applied to it-- a very *small* pattern with a 'sharp' color_map
> and high frequency, like ...
> [0.5 rgb 0]
> [0.5 rgb 1]
> 
> If that object is positioned way off in the distance (relative to the camera), I
> could forsee it having a *darker* blended appearance in the final image than if
> it were closer to the camera (where the alternating black/white pattern could
> actually be seen as individual lines.) Due solely to the 'non-linear' blending
> by the monitor of the black/white combination. Micro-normals come to mind as
> well, the darker blending effect depending on the orientation of the object and
> its distance. But all of this is guesswork, of course.

If you use a non-native display resolution, then this can indeed happen,
due to the non-linear blending by the monitor.

In POV-Ray's anti-aliasing, this is already taken into account:
Anti-aliasing nowadays works in linear colour space (presuming you're
using `assumed_gamma 1.0`, which is a prerequisite for POV-Ray behaving
properly with respect to anything gamma-related).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> If you use a non-native display resolution, then this can indeed happen,
> due to the non-linear blending by the monitor.

Ah, so it seems that the only way to avoid these 'blending' problems is to leave
the monitor at its native resolution. I understand now. Thanks.

It's worth mentioning that I never saw these kinds of problems on my old CRT
monitors, when adjusting gamma in POV-Ray. (Or, if present, it was subtle, or
else I never noticed.) I'm *guessing* that the reason has to do with the
arrangement of a CRT's red/green/blue phosphors (and its 'shadow mask'),
compared to a modern LCD/LED monitor. If I'm not mistaken, a CRT has something
like a triangular(?) arrangement of phosphors (depending on the brand), whereas
modern monitors have pixels in a strict linear X/Y configuration. I'm thinking
that the gamma chart's thin horizontal lines have a better chance of being
'faithfully' reproduced on a CRT (well, in some sense.) Or so my mind's eye
tells me ;-)
>
> In POV-Ray's anti-aliasing, this is already taken into account:
> Anti-aliasing nowadays works in linear colour space...

Excellent! That's a subtle bit of re-work magic that most of us would never have
thought of. (OK, maybe just me!)

Post a reply to this message

Le 17-10-16 à 15:20, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
> 
>>
>> If you use a non-native display resolution, then this can indeed happen,
>> due to the non-linear blending by the monitor.
> 
> Ah, so it seems that the only way to avoid these 'blending' problems is to leave
> the monitor at its native resolution. I understand now. Thanks.
> 
> It's worth mentioning that I never saw these kinds of problems on my old CRT
> monitors, when adjusting gamma in POV-Ray. (Or, if present, it was subtle, or
> else I never noticed.) I'm *guessing* that the reason has to do with the
> arrangement of a CRT's red/green/blue phosphors (and its 'shadow mask'),
> compared to a modern LCD/LED monitor. If I'm not mistaken, a CRT has something
> like a triangular(?) arrangement of phosphors (depending on the brand), whereas
> modern monitors have pixels in a strict linear X/Y configuration. I'm thinking
> that the gamma chart's thin horizontal lines have a better chance of being
> 'faithfully' reproduced on a CRT (well, in some sense.) Or so my mind's eye
> tells me ;-)
>>
>> In POV-Ray's anti-aliasing, this is already taken into account:
>> Anti-aliasing nowadays works in linear colour space...
> 
> Excellent! That's a subtle bit of re-work magic that most of us would never have
> thought of. (OK, maybe just me!)
> 
> 
> 
> 

On a CTR monitor, each pixel is spread over several groups of phosphore 
patches. Also, the edges of the pixels are somewhat fuzzy, making them 
blend toggether, at least, a little.
There are two way the phosphore patches are aranged : Triangular array 
of circular spots (apperture mask), and groups of rectangular "spots" 
ranged side by side (whire mesh).

The charts need to be displayed at one image pixel = one screen pixel. 
If not, you always get some interpolation that will ruin the test.

When using an LCD monitor, it's always beter to use it's native 
resolution, or an integer fraction of that.
In your case, that would be 1920 X 1280, 960 x 640, 640 x 427,...
ANY other resolution will require the use of interpolation.

If that makes things to small, then, you can adjust the PPI setting of 
your display, or use larger fonts.

Post a reply to this message

Am 16.10.2017 um 21:20 schrieb Kenneth:

> Ah, so it seems that the only way to avoid these 'blending' problems is to leave
> the monitor at its native resolution. I understand now. Thanks.
> 
> It's worth mentioning that I never saw these kinds of problems on my old CRT
> monitors, when adjusting gamma in POV-Ray. (Or, if present, it was subtle, or
> else I never noticed.) I'm *guessing* that the reason has to do with the
> arrangement of a CRT's red/green/blue phosphors (and its 'shadow mask'),
> compared to a modern LCD/LED monitor. If I'm not mistaken, a CRT has something
> like a triangular(?) arrangement of phosphors (depending on the brand), whereas
> modern monitors have pixels in a strict linear X/Y configuration. I'm thinking
> that the gamma chart's thin horizontal lines have a better chance of being
> 'faithfully' reproduced on a CRT (well, in some sense.) Or so my mind's eye
> tells me ;-)

It's not related to the arrangement of "display pixels"; with CRTs, both
the standard triangular grid as well as Sony's "trinitron" side-by-side
arrangement were fine with respect to blending.

Which is good, because controlling the cathode ray to such a precision
that it would exactly line up with the grid would be unreasonably difficult.

As a matter of fact, in a CRT there is a lot of blending going on,
because the dot projected by the cathode ray is necessarily a bit fuzzy,
and doesn't hit the grid openings precisely.

But this blending occurs on a number-of-electrons basis, to which the
physical brightness of the phosphors is (almost, I guess) directly
proportional, so it's linear.


(Vertical lines would be a different matter on a CRT, because they
demand quick modulation of the cathode ray intensity, which may
introduce additional non-linear distortions. That's why gamma test
images favour horizontal lines over vertical ones or a checkerboard
pattern.)

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
>
> On a CTR monitor, each pixel is spread over several groups of phosphore
> patches. Also, the edges of the pixels are somewhat fuzzy, making them
> blend together, at least, a little.

There's one aspect of a CRT that I still don't quite understand: The electron
gun(s)--their beams--can be *deflected* using buttons on the CRT... meaning, you
can 'squash and stretch' the image, so that it completely fills the screen (or
not!) But the acreen's aperture mask or wire mask (with its discrete holes for
the phosphors)is a fixed thing. So, I'm wondering how the squashed-and-stretched
electon beams still manage to correctly 'line up' with those phophors (and it
seems that they do, or the color mix on the screen would be completely messed
up-- which it isn't.) I had always assumed that the magnetic bending of the
beams was done in a continuously smooth way; it *appears* to be smooth. But is
the squashing-and-stretching actually done in discreet steps, so that the
individual  electron beams always *see* their own proper phosphors?

>
> The charts need to be displayed at one image pixel = one screen pixel.
> If not, you always get some interpolation that will ruin the test.
>
> When using an LCD monitor, it's always better to use its native
> resolution, or an integer fraction of that.
> In your case, that would be 1920 X 1280, 960 x 640, 640 x 427,...
> ANY other resolution will require the use of interpolation.

Yes, I see now that my use of 1600 X 900 was causing blending/interpolation (the
'incorrect' color blending, due to the non-linear 2.2-gamma of the monitor).
>
> If that makes things too small, then, you can adjust the PPI setting of
> your display, or use larger fonts.

Yes, the small text size (and overall smaller image presentation) was my
original reason for choosing a non-native resolution. It was an old habit, based
on my CRT days (and the fact that my eyes aren't what they used to be!) But I
can change at least the text size in other ways.

I used to set my CRT monitors at 800 X 600!

Post a reply to this message

On 17/10/2017 12:23, Kenneth wrote:
> Alain <kua### [at] videotronca> wrote:
>>
>> On a CTR monitor, each pixel is spread over several groups of phosphore
>> patches. Also, the edges of the pixels are somewhat fuzzy, making them
>> blend together, at least, a little.
> 
> There's one aspect of a CRT that I still don't quite understand: The electron
> gun(s)--their beams--can be *deflected* using buttons on the CRT... meaning, you
> can 'squash and stretch' the image, so that it completely fills the screen (or
> not!) But the acreen's aperture mask or wire mask (with its discrete holes for
> the phosphors)is a fixed thing. So, I'm wondering how the squashed-and-stretched
> electon beams still manage to correctly 'line up' with those phophors (and it
> seems that they do, or the color mix on the screen would be completely messed
> up-- which it isn't.) I had always assumed that the magnetic bending of the
> beams was done in a continuously smooth way; it *appears* to be smooth. But is
> the squashing-and-stretching actually done in discreet steps, so that the
> individual  electron beams always *see* their own proper phosphors?
> 
Just guessing here. The current going to the Focusing coils and 
Deflection coils are controlled digitally. I think the conversion would 
happen before the coils and use a lookup table for the different parameters.



-- 

Regards
     Stephen

Post a reply to this message

Am 17.10.2017 um 13:23 schrieb Kenneth:
> Alain <kua### [at] videotronca> wrote:
>>
>> On a CTR monitor, each pixel is spread over several groups of phosphore
>> patches. Also, the edges of the pixels are somewhat fuzzy, making them
>> blend together, at least, a little.
> 
> There's one aspect of a CRT that I still don't quite understand: The electron
> gun(s)--their beams--can be *deflected* using buttons on the CRT... meaning, you
> can 'squash and stretch' the image, so that it completely fills the screen (or
> not!) But the acreen's aperture mask or wire mask (with its discrete holes for
> the phosphors)is a fixed thing. So, I'm wondering how the squashed-and-stretched
> electon beams still manage to correctly 'line up' with those phophors (and it
> seems that they do, or the color mix on the screen would be completely messed
> up-- which it isn't.) I had always assumed that the magnetic bending of the
> beams was done in a continuously smooth way; it *appears* to be smooth. But is
> the squashing-and-stretching actually done in discreet steps, so that the
> individual  electron beams always *see* their own proper phosphors?

The trick is that there's nothing special about the squashing and
stretching.

During normal operation, the electron beam traces a zig-zag pattern
across the screen (of which only the zig is visible, as the electron gun
is effectively turned off during the zag). This would be virtually
impossible to align with the aperture mask, so no such attempt is even made.

The squashing and stretching is just a linear scaling of the beam's
current deflection on its way across the screen, so no magic is
happening there to the beam.

This regular deflection is achieved by one set of deflection elements
(either charged plates or magnets).

The real magic is that the three electron guns in the CRT are carefully
arranged (and possibly equipped with additional tunable deflection
elements and associated electronics), such that each beam hits the
aperture mask at a specific well-defined angle. The mask is carefully
aligned with the phosphor dot matrix and has only one aperture per
phosphor dot triplet, with the angles of the beams chosen in such a
manner that each hits its corresponding dot from the triplet as
precisely as technically feasible.

Post a reply to this message