I'm posting this here cause I'd like wide exposure... Maybe its better for the dev forum, but we'll see.
Anyone know anything about Sub-Pixel rendering? I found a tutorial on GRC.com, but my attempts don't look so great yet.
For those of you who don't know what sub-pixel rendering is.... microsoft calls it "ClearType", and it really makes fonts crisper and sharper on color LCD displays.
I'm toying with the idea of a Sub-pixel rendering hack, but so far I haven't made much progress. My attempts give me more burry text than the sharp, crisp text I'm used to in WinXP.
Anyhow, if anyone knows anything about Sub-pixel rendering algorithms, send me some mail.
When I read your post I was concerned that maybe the LCD in the i300 was rotated 90 degrees (vertical instead of horizontal).
This is obviously not the case (copying Gibson's diamond examples to the i300 clearly illustrates that LCD is oriented appropriately for text, left-to-right).
Although I am not famliar with any algortihms for use with text, could it be that the standard color palette for the i300 is an issue. With only 256 colors you do not have the range you might with a standard desktop machine. Granted, you really only to identify the index of the color that only activates the Red, the Green, and the Blue individually.
The indexed color palette is an issue. However, there is a PalmOS function to convert an RGB value to the closest index.
The problem I have is this. Say you're talking about the letter "T", the verical part is 1pixel wide. in subpixels it would look like this:
000 000 111 000 000
When you apply the 1/9ths, you get this: (leaving off the denominator of 9)
000 013 676 310 000
Basically, there's no 9's there, which would be 9/9's... so the characters I get aren't black, but a shade of purple. I must be doing something wrong...
To avoid color fringes, every subpixel needs to be part of a subgroup with 3 or more adjacent subpixels of the same intensity level.
It doesn't matter where the group starts and where the group ends. Also, this doesn't mean that the group needs to be a MULTIPLE of 3 wide... just that the group needs to be at least 3 wide.
Suppose you have a total of 6 bits to work with per physical pixel (2 bits per subpixel, representing 64 varying combinations of intensity among the RGB subpixels). If you want a T with a black stem, it needs to be something like:
You'll notice that the main stem is 4 subpixels wide, the base is just 1 subpixel wider than the stem, and that the top of the "T" freely crosses 3-subpixel boundaries. The key rule is that any arbitrary spot ALWAYS has three or more horizontally-adjacent subpixels of the same intensity.
Last edited by miamicanes : 03-07-2002 at 10:34 PM.
OK, so I've got a font rendered at 3 times the horizontal resolution in bitmap. I've been basically doing this...
---sorry for poor pseudo code.---
make an output bitmap of the same size
for each pixel on the original bitmap
if this pixel is on then in the output bitmap
add 1/9th to the value of pixel 2 to the left of me
add 2/3rd to the value of the pixel 1 to the left of me
add 3/9th to the value of the my own pixel
add 2/3rd to the value of the pixel 1 to the right of me
add 1/9th to the value of pixel 2 to the right of me
end if
next
now, for each group of three (sub)pixels
use the RGBtoIndex function on the three (sub)pixels
draw a pixel to the screen of the given color index
--- end poor pseudo code ---
Am I doing something completely wrong here? It comes out more blurry than I'd expect from nice, Sub-Pixel rendered text.
I have no idea if this will help, but I ran across a doc reader a while back that supposedly employed font smoothing. I totally forget the name of the app though, it was pretty basic and I deleted it.
But I do remember its font smoothing ended up blurring the copy more than I cared for. Anyhow, thought I would add my non-developer 2 cents FWIW.
I want to say it was called smoothreader or something along those lines...
if you want to see a good example of this technology, get MobiPocket and enable "MobiType"... I think it makes things clearer, though I don't care for the reader.
If you want subpixel-rendered fonts to look good, you can't render the font at normal resolution, then use subpixel rendering to smooth it out. It'll just make it blurry and introduce random color fringes.
Remember -- subpixel rendering gives you the freedom to shift the start, midpoint, and end of strokes by 1/3 or 2/3 to either the left or right. It doesn't give you the freedom to make lines that are less than 1 physical pixel (3 subpixels) wide.
What you REALLY need to do is render the font from the vector at 3x the physical resolution (making sure that all strokes and white areas within the letters are three subpixels wide horizontally), then translate that into a subpixel-encoded bitmap.
If you ever did anything on the Apple II, you'll have an easier time envisioning the way subpixel rendering works. On the Apple II, bitmaps were encoded by using two bytes to encode 14 or 7 horizontal pixels (depending upon whether you used a color or green monitor for output). For every two-bit/pixel cluster, color was determined according to the following rules:
odd bit of even byte, even bit of odd byte: blue or green (depending upon whether the byte's most significant bit was 0 or 1)
even bit of odd byte, odd bit of even byte: red-orange or purple (once again, depending upon whether the byte's MSB was 0 or 1)
bits 0 + 1, 2 + 3, or 4 +5 of either odd or even byte, as well as bit 6 of odd byte + bit 0 of even byte -- white
neither pixel set: black pixel
(don't bother to correct me if I screwed up the odd/even bits, or which one was the MSB and LSB. I haven't touched graphics on an Apple II since middle school, and I'm also quite drunk at the moment. This is an illustrative metaphor, not a programming guide to Apple II graphics... :p )
The point is, the "real" resolution was only half the physical resolution, because you couldn't assign arbitrary colors to arbitrary pixels. If you tried to pretend that you could disregard the odd + even rule and create 1-pixel wide "white" areas, you'd end up with blue/orange or green/violet color artifacts alongside your white areas. In fact, this happened quite a lot. Sadly enough, it was actually EMULATED on some programs (like Pinball Construction Set) when they were ported from the Apple to other platforms (like the C64). What the f**k was EA's C64 porting team thinking...
Interestingly enough, this rather wacky scheme had even OLDER roots... the original Apple I. Long before color was remotely mainstream, Steve Jobs discovered that he could get color out of a monochrome display by displaying a high-resolution (by 1977 standards) monochrome bitmap on a crappy Trinitron monitor. As luck would have it, he discovered that by carefully adjusting the screen width, he could line up the pixels in such a way that "odd" pixels lit up the right half of each rgb triad (producing red-orange or violet), and "even" pixels lit up the left half of the triad (producing green or blue). When the Apple II was created, Jobs didn't want to lose compatibility with the "vast" quantity of software that had already been written for the Apple I, so he made the engineers EMULATE artifacting-on-a-crappy-monitor with the Apple II's video chipset (I'm not exactly sure where the MSB toggle came in... on the original Apple I, it might have tweaked the bit timing a bit, shifting the bits right or left by some tiny bit, nudging red-orange (red + a tiny bit of green) toward violet (red + a tiny bit of blue) and blue toward green.
Anyway, I think you get the idea The point I'm trying to get at is that regardless of what the physical resolution of the Apple II was alleged to be, it was really half that. The Apple II's physical resolution is analogous to the i300's subpixel resolution. The half-resolution is analogous to the i300's physical resolution. If you stick to physical resolution, you can freely use any color you want. If you want to use subpixel resolution, you need to carefully keep track of whether it's an even/odd (or, on the i300/ r/g/b) dot and follow the rules to make sure it comes out the color you want it to be.
Last edited by miamicanes : 03-10-2002 at 04:24 AM.
Hehe, never had an Apple II, but I do remember those artifacts from somewhere (C64?) I understand why now, almost 20 years later.
So, I haven't been trying to render smooth out a standard font using sub pixel rendering, but rather, I've been generating 1-bit bitmaps of characters using FreeType and then trying to subpixel render them. Here's my "x" at three times the horizontal resolution for example:
So, based on the "the rules", I'm violating the 3-subpixel rule at the last two 0's of the last line, since they're not a three-subpixel group, right?
Anyhow, I think I'm getting closer. Take a look at the attached image. Gotta figure out why my algorithm makes those funny left and right subpixel borders.
I'd love to get FreeType ported to the palm. Imagine being able to download a true type font to your palm and have a document reader render your text in that font using subpixel rendering. Looks like I'm a bit far off from that.
Right. Subpixel rendering gives you a little more freedom to nudge things to the left or right, but it doesn't "really" give you three times the horizontal resolution.
It's a nice enhancement, but it's not the Holy Grail of HiRes. It doesn't really let you make things narrower so you can fit more onscreen... it just enables you to make things look nicer in the same amount of space. It doesn't make ultra-tiny text possible... it makes normal-sized text (say, 10x12 matrix) look GREAT.
Last edited by miamicanes : 03-12-2002 at 03:01 AM.
The point I'm trying to get at is that regardless of what the physical resolution of the Apple II was alleged to be, it was really half that. The Apple II's physical resolution is analogous to the i300's subpixel resolution. The half-resolution is analogous to the i300's physical resolution. If you stick to physical resolution, you can freely use any color you want. If you want to use subpixel resolution, you need to carefully keep track of whether it's an even/odd (or, on the i300/ r/g/b) dot and follow the rules to make sure it comes out the color you want it to be.
Login
Panel
