On 5 June 2010 18:06, Juan Vuletich <juan@...2357...> wrote:

Hi Michal,

Michal Suchanek wrote:

...

On 3 June 2010 18:45, Juan Vuletich <juan@...2357...> wrote:

...

Ok. Did it. Take a look at http://www.jvuletich.org/Morphic3/tigerWholePixel.png . I think it is closer to the subpixel rendered version than to Inkscape.

But I did something else. I opened the web page on several displays. Tried it in 3 LCD screens, with both DVI and VGA interfaces, and at native resolution and at lower resolution. In all cases the subpixel rendered version shows less pixellation and less color artifacts. Then I tried on 2 15" CRT screens, one Trinitron and the other regular, at 1024x768 and at 800x600. The whole pixel version looks consistently better than the Inkscape rendering, although both show some colored shadows that are due to the misalignment between logical pixels, the display's color mask and the actual colored phosphor on the screen. The subpixel version looks less pixellated and also with a slight colored shadow, but in different places. Overall, I find the subpixel version to also look better in these 2 CRT displays! Finally, I tried on an OLPC XO, both in color and b/w modes. There, all alternatives look equally good and it is hard to declare a winner.

So I say that given that the majority of displays sold and in use are RGB LCDs, given that it makes sense to obtain the highest possible quality from the best and most used displays, and given that the subpixel version looks better even in CRTs and doesn't hurt in the XO; it is advisable to use the subpixel version on any display, at least as a default.

I beg to differ.

I use a rotated screen and the subpixel rendered images look odd and the color shadows make examining the images quite hard on the eyes, even more than the pixelation present in the Inkscape images. This is the reason I don't use subpixel rendering. No sftware I know can do vertical subpixel rendering or even switch the subpixel direction as the window is moved to a different screen or the screen is rotated differently.

Thanks

Michal

I see you answered just to me, so I'll do the same. Anyway, it is ok for me to have any of these discussions in public, as others might have things to say...

Sorry, I meant to reply to the list and as the list does not provide reply-to headers and my mail client is not capable of processing list headers the message went only to you.

I see your points, they are valid issues. However, to me, avoiding subpixel rendering is perfectly ok as a personal choice to live with an unfortunate state of affairs, but there are better options for thechnology to evolve. I mean:

• WRT rotated screens and nonstandard subpixel geometries, ideally the

software should be able to query the hardware, do adjust the rendering as appropriate. My code can do vertical subpixel, as well as adapt to BGR or OLPC XO with just a few parameter tweaks.

Yes, that would be nice option to have. Actually the geometry is known (for most LCDs it is RGB) and the direction can be determined by examining xrandr and window position. It's just not done, and cannot be done for prerendered images.

• WRT to examining the images, I guess new tools are needed. The image zoom

software considers images as made of pixel as having the R, G and B

I intentionally did not use zooming for the comparison, only displayed the page as-is on two screens, one with the expected RGB direction and one rotated. The reason for crude zooming in bitmap viewers is speed I guess, few people want to wait tens of seconds for their image to show in the viewer. Also without additional information you cannot know how the image was rendered and how it should be scaled or resampled for different subpixel positions and different resolutions.

components on the same point. My claim is that this is not true. Thinking about it like digital audio, we have "the real thing", a continuous image not made of pixels, and sampled as appropriate for the current target device. So the idea of images made of rgb pixels is dead. And for examining and editing images, no music producer works with individual samples, although in the old times all of them did work cutting and gluing magnetic tape. The same

Working with pixels directly makes sense for very small low resolution images which are more akin to ASCII-art than actual pictures. As the resolution of display devices increases and images are getting more realistic the need for such low-level manipulation decreases as well. Still the low-res images strike back in the form of font glyphs and icons for pocket devices.

Actually there is real a problem of converting fonts from vector outlines to some bitmap form which can be used for simple drawing operations (in this particular case for use in a bootloader which should not be concerned with rendering vector graphics).

The current method freetype uses fails miserably for conversion to b&w (not grayscale) bitmaps but maybe there is no way how that can be done reasonably. Grayscale is the next thing on the list of things to try but I have not seen the results yet.

If your software can render some CJK/Indic/whatever TrueType/OpenType/whatever font glyphs that would be another thing where good antialiasing could be useful. Rendering of Latin or such is also of use but there drawing all the bitmaps by hand is less of an issue and many bitmap fonts already exist.

Thanks

Michal