 | |
#11
 
| |||
| |||
|
Re: Why not perfect alignment? -
10-25-2009
, 08:43 AM
|
In article <hc17as$3ik$1 (AT) news (DOT) eternal-september.org>, C A Upsdell <cupsdell (AT) nospam (DOT) not> wrote: ... I have Windows XP with an LCD monitor. I don't know what you see when you view the pages you cited, but what I see with FF 3.5 is fat dark grey text with coloured fringes where you overlaid the text. Turning off ClearType immediately transformed the text to its normal appearance. In fact, I did not test in my Opera 9.64. In Opera, there is no fringing or extra blackening. So, the browser is obviously some important factor. |
but crisp and without fringes. But this is likely something as simple
as Opera and Safari not using the APIs which result in Windows ClearType
being applied.
#12
| |||
| |||
|
|
dorayme wrote: http://dorayme.netweaver.com.au/alt/indexAlignment.html http://dorayme.netweaver.com.au/alt/indexAlignment2.html This is what we see. http://www.evandervaart.nl/news/indexAlignment.png [1920x1080 205kB] |
you the colours.
--
dorayme
#13
| |||
| |||
|
|
Here's a theory. Text at small sizes isn't pure black due to Mac OSX font smoothing. Instead the pixels forming the characters have various degrees of transparency. When you overlay two identical characters, a semi-transparent pixel will become darker (like overlaying two semi-transparent layers in photoshop). The lighter edge pixels become darker and make the font look jaggy. .... |
Yes, this is an intelligent idea. You are right that the grey comes from
small text sizes and we can sort of see why this is. Text characters are
clever little artifacts in computers and are defined by sets of
mathematical rules. When you add the factor of aliasing to fit the
technology of discrete pixel screens, at small sizes there is not much
left for the deep black bits, a lot of pixels are pressed into smoothing
services. Hence the slightly greyer look.
But there are still quite a few questions. I will come back on this very
shortly when I have more time, probably tomorrow, so don't go too far
away <g>
--
dorayme
#14
| |||
| |||
|
|
In article <1j853jh.sfvlrn1sdzk5yN%j1 (AT) macunlimited (DOT) net>, j1 (AT) macunlimited (DOT) net (j) wrote: ... Here's a theory. Text at small sizes isn't pure black due to Mac OSX font smoothing. Instead the pixels forming the characters have various degrees of transparency. When you overlay two identical characters, a semi-transparent pixel will become darker (like overlaying two semi-transparent layers in photoshop). The lighter edge pixels become darker and make the font look jaggy. ... Yes, this is an intelligent idea. You are right that the grey comes from small text sizes and we can sort of see why this is. Text characters are clever little artifacts in computers and are defined by sets of mathematical rules. When you add the factor of aliasing to fit the technology of discrete pixel screens, at small sizes there is not much left for the deep black bits, a lot of pixels are pressed into smoothing services. Hence the slightly greyer look. |
produce a black and set the layer opacity to less than 100% and have
multilple <100% opacity *layers*. This deepens the black. We can
understand why this would be wanted. How quite it is achieved is a very
technical question, it is not like spray painting which keeps filling in
bits that are missed. In spray painting this is possible because there
is randomness. But there is no randomness in the image editor case or
the HTML case. In the image editor case, they simply code for it look
blacker! It is to mimic painting and glass layers and things in the real
world. If this happens in the webpage context as well, then that would
explain the phenomena.
And indeed, it does seem to fit the case of text. But it does not fit
the case of a transparent gif of a letter, such inline elements happily
pile up, laying *exactly* on top of each other. There is no summing or
any such interaction between the pixels on the 'indexed layers'.
Interesting things, fonts! Given what we have observed, it looks like it
is not something that anything of the CSS 2.1 or HTML standards has much
to say about. It seems an interaction between platforms, platform
options or preferences and positioning. I leave the matter for now with
less niggles than I had before. <g>
--
dorayme
#15
| |||
| |||
|
|
In an image editor like Fireworks or PS or even Illustrator, you can produce a black and set the layer opacity to less than 100% and have multilple <100% opacity *layers*. This deepens the black. We can understand why this would be wanted. How quite it is achieved is a very technical question, it is not like spray painting which keeps filling in bits that are missed. In spray painting this is possible because there is randomness. But there is no randomness in the image editor case or the HTML case. In the image editor case, they simply code for it look blacker! It is to mimic painting and glass layers and things in the real world. If this happens in the webpage context as well, then that would explain the phenomena. And indeed, it does seem to fit the case of text. But it does not fit the case of a transparent gif of a letter, such inline elements happily pile up, laying *exactly* on top of each other. There is no summing or any such interaction between the pixels on the 'indexed layers'. Interesting things, fonts! Given what we have observed, it looks like it is not something that anything of the CSS 2.1 or HTML standards has much to say about. It seems an interaction between platforms, platform options or preferences and positioning. I leave the matter for now with less niggles than I had before. <g |
When Photoshop or Fireworks displays an image, the rgb value of each
pixel is the result of a complex mathematical calculation. In the case
of transparency, there is of course no real transparency as we look at a
2-dimensional screen. So any apparent transparency is the result of a
calculation which asks "What would *this* pixel look like if it was
partially transparent and the pixel underneath had *this* colour."
But even that is misleading because there is no colour in Photoshop!
There is just a collection of calculated numbers for each pixel. In the
case of rgb there are three numbers, each between 0 and 255, which
represent the three separate channels of red, green and blue.
What gets really confusing is how these semi-transparent overlaid
colours are calculated. And whether the same process is used in browsers
as in graphics programs.
I've replicated your absolute positioned text but with different colour
paragraphs. The top section now shows pure green over pure red. The
graphic below it shows that text magnified:
http://tinyurl.com/yj86auq
I would expect the edge pixels to show various shades of dirty yellow as
the values of red and green step up in tandem (see the colour picker and
notice the rgb values). However, if those edge pixels are sampled in
Photoshop the values contain a mix of red, green *and* blue.
So, although the edge pixels look roughly like the colours to be
expected (the shades of yellow on the right edge of the colour picker
shown), the actual rgb values seem to be calculated by some mysterious
algorithm. The whole thing is complicated further by taking screenshots
in indexed colour, though the same thing can be replicated in Photoshop
with similar results.
However, after seeing this video I no longer trust my eyes:
http://tinyurl.com/ydlhfb2
#16
| |||
| |||
|
|
I would expect the edge pixels to show various shades of dirty yellow as the values of red and green step up in tandem (see the colour picker and notice the rgb values). However, if those edge pixels are sampled in Photoshop the values contain a mix of red, green *and* blue. |
more transparent they head toward white (r255 g255 b255). So the blue
value also needs to increase along with the red and green. On the colour
picker shown the transition would be on a diagonal from bottom right to
top left
As to how it all ends up displayed on screen, I'll leave that to the
more technically minded.
#17
| |||
| |||
|
|
What gets really confusing is how these semi-transparent overlaid colours are calculated. And whether the same process is used in browsers as in graphics programs. .... ...after seeing this video I no longer trust my eyes: http://tinyurl.com/ydlhfb2 |
there are complex algorithms employed to implement those facilities with
perhaps many similarities to image editor ones. In the case we were
discussing, not employing any opacity rules, it seems that fonts alone
get this odd interaction... anyway, ...
The thing that I found particularly interesting in the last URL, thanks
for giving it, was the suggestion of sensing via sound for blind people.
I think this is quite fascinating!
--
dorayme
#18
| |||
| |||
|
|
In article <1j88xln.wtfbvd1lhlunuN%j1 (AT) macunlimited (DOT) net>, j1 (AT) macunlimited (DOT) net (j) wrote: ... What gets really confusing is how these semi-transparent overlaid colours are calculated. And whether the same process is used in browsers as in graphics programs. I have not examined the CSS 3 opacity facilities but I imagine that there are complex algorithms employed to implement those facilities with perhaps many similarities to image editor ones. In the case we were discussing, not employing any opacity rules, it seems that fonts alone get this odd interaction... anyway, ... |
http://nrkn.com/opacityExperiment
If you click through the links and it doesn't look like it's changing then
the overlaid colours are being calculated the same.
Looks like the browsers agree with not just with Photoshop in how to
calculate the overlaid colours, but with each other too.
Well, Firefox/Safari/Chrome/Opera. IE8 doesn't support any of the CSS3 that
I used for the last 3 variants.
The opacity relationship is:
One layer at 75% = 75%
Two layers overlaid @ 75% ea = 94%
Three layers overlaid @ 75% ea = 98%
One layer at 50% = 50%
Two layers overlaid @ 50% ea = 75%
Three layers overlaid @ 50% ea = 88%
One layer at 25% = 25%
Two layers overlaid @ 25% ea = 44%
Three layers overlaid @ 25% ea = 58%
This is classic alpha compositing, nothing too complex to implement, which
is why it looks the same everywhere:
new alpha = source alpha + ( 1 - source alpha ) * destination alpha
The colours are therefore likely calculated in a similar fashion
#19
| |||
| |||
|
|
"dorayme" <doraymeRidThis (AT) optusnet (DOT) com.au> wrote in message news:doraymeRidThis-CB1226.12270328102009 (AT) news (DOT) albasani.net... In article <1j88xln.wtfbvd1lhlunuN%j1 (AT) macunlimited (DOT) net>, j1 (AT) macunlimited (DOT) net (j) wrote: ... What gets really confusing is how these semi-transparent overlaid colours are calculated. And whether the same process is used in browsers as in graphics programs. I have not examined the CSS 3 opacity facilities but I imagine that there are complex algorithms employed to implement those facilities with perhaps many similarities to image editor ones. In the case we were discussing, not employing any opacity rules, it seems that fonts alone get this odd interaction... anyway, ... This caught my interest so I had a bit of a play around: http://nrkn.com/opacityExperiment If you click through the links and it doesn't look like it's changing then the overlaid colours are being calculated the same. .... ...classic alpha compositing, nothing too complex to implement, which is why it looks the same everywhere: The colours are therefore likely calculated in a similar fashion |
too surprising that when it comes to conscious use of opacity in
browsers that the makers would have borrowed heavily from the
algorithmic resources developed in image software.
--
dorayme
#20
| |||
| |||
|
|
It is mildly surprising that blurring occurs, that there is not perfect registration. |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.