GP2X Follow To Discussion About An Image Scaling

[Radek]

Hi,

There somewhere on the GP32x's forums was discussion about a scaling. I made point about using each individual RGB subpixel of LCD matrix to those uses. I tried to find more about this topic yet I did fail.

So... I made some algos myself! Here are the results:

You have here two series of bitmaps. The first ones are an original (not scaled nor anything). Then they were filtered using my little program which actually does implement three different methods of scaling.

The algo1 wasn't really my goal however I had to have something I'd use as a point of reference.
The LCD1 was my first attempt at making subpixel scaling. It gives a higher "pseudo" horizontal resolution by factor of 2.
The LCD2 was my goal target. It gives a "pseudo" horizontal resolution up to 3 times higher.

I experimented on more bitmaps of course. My own findings are the actuall usefullness of subpixel scaling are that this is very limited. It doesn't (at least my own routines) degrade an image by a lot (actuall imho the LCD2 is very clean of an artifacts) but it rarely improve it either. But it must use lot of multiplies (the algo1 can be coded just using additions and bit shiftings) and has need of addressing 3x more memory locations (for a every RGB component).

So it isn't worth the effort. However I'm happy as I did the experiment myself.

For the intrigued I coded in the Python (can do it in C but for just a prototyping why?), used floatpoints (again for my comfort) and had lots of fun.
(technically these algos can scale at almost any ratio thought it's done by a hack and not proper filtering like the bilinear or bicubic)

 

[iignotus]

"algo1" is vastly superior to LCD1 and LCD2. The latter two introduce a number of very undesired artifacts for even such simple images.

Any chance of seeing some time figures, as well as some source (not that it's wildly difficult, but it'd be a nice accompaniment)?

 

[Radek]

"algo1" is vastly superior to LCD1 and LCD2. The latter two introduce a number of very undesired artifacts for even such simple images.

What kind of monitor are you using? It must be a LCD with horizontal and RGB order of its subpixels. Otherwise it'll not work.

On my LCD it's a fine and LCD2 for the fonts looks much better (sharper) than algo1.

Any chance of seeing some time figures, as well as some source (not that it's wildly difficult, but it'd be a nice accompaniment)?

​

Yes, I will made it available. Just add one (or two) things to it. For a profiling info I can say algo1 is fastest but any perfomance measurement of this code doesn't have a sense. It's pure Python using some "pythonic" tricks unthinkable in the C. Certainly an implementation for a practical uses will look way different than now.

Thanks for your interest.

 

[iignotus]

What kind of monitor are you using? It must be a LCD with horizontal and RGB order of its subpixels. Otherwise it'll not work.

I have to be using an LCD? I'm using a CRT. If you zoom in with an image editor, you can see the strange artifacts that popped up.

 

[Tobriand]

Hmm... I think LCD2 is much nicer for the font, but for the picture, I'd agree with iignotus for the most part (although LCD2 is certainly superior to LCD1).

The really interesting question is how it handles a scrolling close pattern (e.g. bricks), since these are what make stretching look especially bad imo in emulated games where its most needed (most algorithms result in quite bad tear/shimmer effects on bricks, roofs, grass, etc.)

 

[Radek]

What kind of monitor are you using? It must be a LCD with horizontal and RGB order of its subpixels. Otherwise it'll not work.

I have to be using an LCD? I'm using a CRT. If you zoom in with an image editor, you can see the strange artifacts that popped up.

​

Yes a LCD monitor is a mandatory here and the artifacts must be present (and image must be be on screen at 1x1 ratio). It's them what can give an illusion of higher horizontal resolution. It's a trading between colour distortions and improved sharpness. Nothing for a free unfortunately.

LCD is specifically needed because of its regular order of RGB subpixels.
You have (usually) something like this in LCD screen line:
|RGB|RGB|RGB|RGB|RGB|RGB|... -> to the right side of screen
but actually there a three combinations of colour triad: RGB, GBR and BRG.
So on LCD screen by shuffling the order of components a "pseudo" higher resolution can be achieved. Actually 3x higher for horizontal axis as there are three subpixels inside each pixel. So...
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|RGB|

And so on...

It's a basis of LCD1 and LCD2 scalers. The subpixel fonts smoothing build in a windows (Mac and Linux's desktops too) also depends on this trick. Yep, it's not ideal but as I didn't find anything about this for an image scaling I had to try myself.

I will experiment with this further and it can be tuned up but must rest for a day of an all this thinking.

 

[skeezix]

Sub-pixel rendering can be _very_ good. I've not implemented it myself (shoudl look into it , but I've tried turning it on and off on various platforms.. Palm OS, Pocket PC, Windows XP, with various mixes of display technology; on the whole, it made _text_ (my main interest at the time) enormously more readable .. a gorgeous anti-aliased smoothness. That was high contrast though, and not photos or the like.

Coincidentally I just wrote a brute-force scaler last night for doing stretch-blits; I need to look into various smootyh techniques soon to improve it

jeff

 

[Rik]

Sub-pixel rendering can be _very_ good. I've not implemented it myself (shoudl look into it , but I've tried turning it on and off on various platforms.. Palm OS, Pocket PC, Windows XP, with various mixes of display technology; on the whole, it made _text_ (my main interest at the time) enormously more readable .. a gorgeous anti-aliased smoothness. That was high contrast though, and not photos or the like.

Coincidentally I just wrote a brute-force scaler last night for doing stretch-blits; I need to look into various smootyh techniques soon to improve it

jeff

​

The GP32's screen is rotated, right? In otherwise the ordering of the RGB will be vertical instead of horizontal. That's not so useful for text. Does the 2X use the same screen?

 

[Radek]

Sub-pixel rendering can be _very_ good. I've not implemented it myself (shoudl look into it , but I've tried turning it on and off on various platforms.. Palm OS, Pocket PC, Windows XP, with various mixes of display technology; on the whole, it made _text_ (my main interest at the time) enormously more readable .. a gorgeous anti-aliased smoothness. That was high contrast though, and not photos or the like.

Coincidentally I just wrote a brute-force scaler last night for doing stretch-blits; I need to look into various smootyh techniques soon to improve it

jeff

​

The GP32's screen is rotated, right? In otherwise the ordering of the RGB will be vertical instead of horizontal. That's not so useful for text. Does the 2X use the same screen?

​

Funny that someone made a post for such old topic...

Anyway - because the GP32's screen is rotated it doesn't mean that RGB subpixel rendering will be useless. Just instead a higher horizontal resolution there is vertical one. Horizontal is preferable for fonts but still vertical should help to smooth fonts a bit.

 

[chris_r]

The screen isnt actually rotated otherwise you would end up with a tall handheld. It just scan from top to bottom instead of from left to right. I think at least

 

[Radek]

The screen isnt actually rotated otherwise you would end up with a tall handheld. It just scan from top to bottom instead of from left to right. I think at least

​

By rotation I had in a mind order of RGB subpixels

In the GP2x it's like that:
|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|
|RGB|RGB|RGB|RGB|

By rotating it would be:

R|R|R|R|
G|G|G|G|
B|B|B|B|
R|R|R|R|
G|G|G|G|
B|B|B|B|

 

[paeryn]

The screen isnt actually rotated otherwise you would end up with a tall handheld. It just scan from top to bottom instead of from left to right. I think at least

​

Yes it is rotated. The gp32's screen is a 240x320, designed more for PDA's. When gamepark made the gp32 landscape screens were few and far between.

 

[FluffyPanda]

Sub-pixel font rendering (like cleartype) could still be used on the gp32, but you'd have to turn your screen 90 degrees to get the best out of it.

Using it for anything other than text isn't such a good idea. Personally I find cleartype rendered text a little odd since you can often see the colours at the edges of a letter. It does look nice though and might be a good thing to have on a future gp2x ebook reader.

 

[chris_r]

The screen isnt actually rotated otherwise you would end up with a tall handheld. It just scan from top to bottom instead of from left to right. I think at least

​

Yes it is rotated. The gp32's screen is a 240x320, designed more for PDA's. When gamepark made the gp32 landscape screens were few and far between.

​

Ah right, obviously my understanding of the situation was way off. Thanks for the correction