Help With Fir Filters Needed


notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
The hardware scaler in pandora uses poly-phase 5-tap 8-phase filter. It is described in 15.4.2.3.4 and 15.6.1.3 sections of TRM. There are 40 coefficients programmable for both horizontal and vertical resampling (vertical resampling might also use 3 taps/24 coefficients, it depends on available pixel clock).

The default 5-tap coefficients for upscaling are:
Code:
  0   0 128   0   0
 -1  13 124  -8   0
 -2  30 112 -11  -1
 -5  51  95 -11  -2
  0  -9  73  73  -9
 -2 -11  95  51  -5
 -1 -11 112  30  -2
  0  -8 124  13  -1
These are used regardless of input/output resolutions, and result is divided by 128 for each phase from what I understand. DaveC's comments are "it's bi-linear blurr filter", "making everything blurry like it is out of focus", "honestly looks awful", "nothing is sharp anymore and the contrast is gone".

Using the ones bellow seem to make it nearest neighbor filter:
Code:
  0   0 128   0   0
  0   0 128   0   0
  0   0 128   0   0
...
But I'm not sure using that one is technically correct.

So the question is, can it be tuned to look better? Exophase made a comment here but I'm not sure it's applicable.
 
Last edited by a moderator:
Solution: stop listening to DaveC ;P

dspguru describes polyphase interpolation here: http://www.dspguru.com/dsp/faqs/multirate/interpolation

The filters you're using for nearest neighbor should be correct.

The filter you gave deinterleaves to this I think:

0 -2 -1 0 0 -1 -2 -5 -9 -11 -11 -8 0 13 30 51 73 95 112 124 128 124 112 95 73 51 30 13 0 -8 -11 -11 -9 -5 -2 -1 0 0 -1 -2

It's linear phase (if you ignore the left hand 0), and it starts attenuating around 0.02 fs, hits stop band around 0.1 fs, and has a -3dB point around 0.05 fs. For 2x upsampling this is probably not a very good filter, I think it's more useful for higher ratios. But there's no real point optimizing it, if DaveC will complain with anything not nearest neighbor.
 
I've never looked into this; time fo me to do some reading.. very slick :)

Are you thinking of putting something in like "cat /etc/dspfilters/nearestneighbour > /proc/filters/poop" so the user can select a preferred filter from a ED bootscript?

jeff
 
The coefficients (and other filter parameters) should definitely be added to the fbdev ioctls. Unfortunately, if some user method isn't available then DaveC will nag every last developer who doesn't include the option, but a standalone program should be fine (procfs interface not necessary)
 
I'm going for a simple shell script that loads the coefficients from a file specified, with some files included in firmware. I think it's more accessible than custom ioctls, will not get restricted to developers.
 
notaz said:
I'm going for a simple shell script that loads the coefficients from a file specified, with some files included in firmware. I think it's more accessible than custom ioctls, will not get restricted to developers.

Ultimately it'll be both, right? Or are you saying procfs interface instead of ioctl? Eventually I want to stop calling shell scripts from my programs.
 
Last edited by a moderator:
Exo -- not that theres anything wrong with a sh-script (except during time critical points, and they do have their uses for out of program standardization/customiation).. but theres not much really wrong with doing open(2) and write(2) to a procfs (its not lke ioctl's are really type-safe or anything anyway.) Not that I'm against ioctl+procfs both, but I'm just surprised to see an anti-sh-script sentiment :)

jeff
 
I understand the advantages of procfs over ioctl and am not really complaining about one or the other, it's just my personal experience with writing Linux drivers that procfs interfaces are a lot more work to setup and have some drawbacks (like not being tied to a specific device, hard to multi-instantiate them). I used it on an embedded Linux platform just because someone else indoctrinated me against ioctl and I saw later how that was stupid and how most of the complaints with ioctl didn't apply there.

As for anti-sh, doing system() calls in my program just feels a little dirty, I dunno. It's not a very big deal.
 
Exophase said:
Solution: stop listening to DaveC ;P
Except that it is not just me that dislikes the filter. Read the Ginge thread and you will see several other posts of people who also dislike the fuzzyness.

This filter not only makes things too soft but also adds "ringing" to the edges of some color transitions, and makes bits of certain color text disappear. Some of us care more how things look. I am not saying to never use the filter, just saying an option to not use it is best for those that prefer more sharpness.

I also think the non filtered mode is really only good for integer scale (2X etc) and that 2X should be an option in many cases. When doing the fractional stretch the filter looks better than unfiltered.
 
Last edited by a moderator:
Exophase said:
I understand the advantages of procfs over ioctl and am not really complaining about one or the other, it's just my personal experience with writing Linux drivers that procfs interfaces are a lot more work to setup and have some drawbacks (like not being tied to a specific device, hard to multi-instantiate them).
In this particular case it was much easier to do sysfs interface as layers are already instantiated by DSS2, I only needed to stick few attributes to the object.

Exophase said:
As for anti-sh, doing system() calls in my program just feels a little dirty, I dunno. It's not a very big deal.
Same as using custom ioctls, that part will be pandora specific anyway.

DaveC said:
This filter not only makes things too soft but also adds "ringing" to the edges of some color transitions, and makes bits of certain color text disappear. Some of us care more how things look. I am not saying to never use the filter, just saying an option to not use it is best for those that prefer more sharpness.
ok DaveC, if you want to get rid of that filter, you must complete a quest (you don't mind helping out, do you, why do I have to be alone making it happen?). The scaler uses 40 magic numbers to decide how it works. There is a combination of 40 numbers, similar to one in post #2, that will turn off filtering. Find that sequence of numbers, and you'll get an option to turn off filtering in next hotfix, or fail it, and your pandora will stay in blurry out-of-focus world for eternity :)
All required info to complete this quest is in this thread.
 
Last edited by a moderator:
DaveC said:
Except that it is not just me that dislikes the filter. Read the Ginge thread and you will see several other posts of people who also dislike the fuzzyness.

Tell me who. The only person I've seen against it is Eniko who only was on principle.

DaveC said:
This filter not only makes things too soft but also adds "ringing" to the edges of some color transitions, and makes bits of certain color text disappear. Some of us care more how things look. I am not saying to never use the filter, just saying an option to not use it is best for those that prefer more sharpness.

I also think the non filtered mode is really only good for integer scale (2X etc) and that 2X should be an option in many cases. When doing the fractional stretch the filter looks better than unfiltered.

I do admit the filter coefficients are really not correct for 2x. The cutoff is way too low (ie, too soft), and the ripple in both the stop-band (past 0.25 fs, where you want full attenuation) and what I'm calling the pass-band (where it looks like it's trying to be flat) is way more than half a bit (1 / 512) so it's possible that's causing the ringing you're talking about, although I doubt it since you'd never see it in anything less than 24bpp color, and your eyes would have to be pretty sensitive. Maybe you can better describe it. Too bad there isn't a way to take a screenshot. I'm skeptical about this part about making things disappear.

What notaz posted really should be right to "turn off" the filtering like you want. We'll have to wait for the next hot fix, I guess, but I imagine it won't be long coming now.

I'll have access to some good filter design software really soon, I'll post the coefficients (probably in a day or two). I could do it with Octave but I want to make sure they're done right and Octave tends to crash on me when I do Parks-McClellan design in it. But I'm only going to do it if you'll try it, tell me if it's better or worse than the existing one (since quite honestly I don't think most care enough or can even tell the difference) and not just say that it's automatically shit because it's not you've long since decided is the only acceptable option. In order to be helpful in this thread I'd be relying on people who are accurately discerning, because I don't know for sure if the filter specifications I'm after are appropriate or not.

I may have to post a few with different tradeoffs of transition band vs ripple.
 
Last edited by a moderator:
Exophase said:
Tell me who. The only person I've seen against it is Eniko who only was on principle.

Below:

Tobriand said:
...
Finally, I'd like to echo DaveC's request for an unfiltered version. W&W looks MUCH fuzzier than it need do, given how nice it looked on the 2x screen. It may be low down the list of things to do, but it'll make me happy when it turns up :)

God Ginrai said:
Tobriand said:
Finally, I'd like to echo DaveC's request for an unfiltered version. W&W looks MUCH fuzzier than it need do, given how nice it looked on the 2x screen. It may be low down the list of things to do, but it'll make me happy when it turns up :)
I actually kind of agree on this.

-God Ginrai

Eniko said:
I'll chime in and say I agree with DaveC about the blur filter. But then I'm a pixel artist and thus by definition a bit of a purist. Also, this is absolutely awesome!

PokeParadox said:
Filtering - I wouldn't mind a simple doubled mode without any filtering, but I also don't mind the current option.
The last one is kind of a weak agreememnt but I will take it. This doesn't mean that more don't feel the same way but didn't post it. This number will obviously grow when more Pandoras are out there as well. Seems a worthwile option. Well enough of that.
Exophase said:
But I'm only going to do it if you'll try it, tell me if it's better or worse than the existing one (since quite honestly I don't think most care enough or can even tell the difference) and not just say that it's automatically shit because it's not you've long since decided is the only acceptable option. In order to be helpful in this thread I'd be relying on people who are accurately discerning, because I don't know for sure if the filter specifications I'm after are appropriate or not.

I may have to post a few with different tradeoffs of transition band vs ripple.
Yes I will try it. I will try to be as helpful as I can but not being a coder hurts. I can only run pre-done code then look at the result. You also stated that your Pandora Temper used a milder filter too. If you wanted to send me a beta I will let you know there too. I know those games real well. Speaking of that the filter you used for that on the GP2X was decent. It only did it in the fractional scale direction. If something like that could be done on Pandora (filter horizontal, straight 2X vertical) it might look good.

I am not really familiar with what "transition band vs ripple" means but I do know what looks decent.

It appears this filter has allot of parameters. It also looks as if it could be used for such things as simulating scan lines, aperature grilles etc but I am not too sure. It would be really cool if emus could have a set of options somewhere for various settings as well as no filter.

EDIT:
Oh yeah the "ringing". Some color transistions add another color between them that was never there. This Ringing is like a shadow to the right of a light to dark transition. I also see it as a lighter outline around a dark color on a medium background. Say like the "credit" text (black outline on grey background)in outrun MAME.
 
Last edited by a moderator:
I might have been off on the filter anyway, I mean, what I said only really applies if you use it as a full 5x. The less of an up ratio you have, the less taps are actually used effectively. A 2x filter should only be using 10 taps.
 
notaz said:
ok DaveC, if you want to get rid of that filter, you must complete a quest (you don't mind helping out, do you, why do I have to be alone making it happen?). The scaler uses 40 magic numbers to decide how it works. There is a combination of 40 numbers, similar to one in post #2, that will turn off filtering. Find that sequence of numbers, and you'll get an option to turn off filtering in next hotfix, or fail it, and your pandora will stay in blurry out-of-focus world for eternity :)
All required info to complete this quest is in this thread.
I don't mind helping out. I helped with fixing the LCD gamma but that was easy. I would do what I am capable of here.

I started out on the quest but a magic voice said "Decryption skill too low". "Need more INT points to continue". I don't have a +50 INT potion :( Maybe I need to consult the oracle.

So Oracle, what do those numbers represent? I tried reading that link but it was all beyond my scope of knowledge. I am more of an art type, code and deep math not so much :( If I knew what did what and how it was structured it would help. Is there some kind of way to fiddle with them and see a result? Some kind of script to run then see the result in Ginge or something else?

It would be nice if some kind of "filter factory" could be made so users and devs could play with settings to get the desired result.
 
Last edited by a moderator:
I think we have to wait for a hot fix or patch because it'll need a new kernel. I doubt notaz wants to hobble together some user level /dev/mem style hack on it.

To explain band-pass filters you'd have to understand how fourier analysis works and various time domain vs frequency domain relationships and Nyquist's theorem and stuff.
 
Exophase said:
I think we have to wait for a hot fix or patch because it'll need a new kernel. I doubt notaz wants to hobble together some user level /dev/mem style hack on it.

To explain band-pass filters you'd have to understand how fourier analysis works and various time domain vs frequency domain relationships and Nyquist's theorem and stuff.
Yeah that sounds out of my league.

You guys can let me know what I could do to improve the filter or to shut it off etc if there is anything, but it doesn't look good.

Does there need to be a hotfix to have an option for 2X double mode to be turned off through the app? I would think Notaz's example could be used couldn't it?

By the way here is a pic of that text that has bits dropping out, it is in Descent:
Notice the areas where there are single pixel elements and corners, they are almost completely gone. This is worse than other stuff but it shows the effect well.

filtertext.png
 
Last edited by a moderator:
Let me try to design a few and you can test them and see how they look. Bearing in mind that I fully expect you to favor the pure pixel doubling one, but it'd be helpful to know if anything is considered an improvement. 10 taps isn't really a lot to work with so you're probably going to end up with a kind of crude filter no matter what.

On the other hand, I'm starting to think that there's a difference between standard time domain signal processing and pixels you look at on a screen. On the other other hand, fourier analysis is the basis of almost all serious lossy image, video, and audio compression, so we shouldn't so easily discount it!
 
Exophase said:
Let me try to design a few and you can test them and see how they look. Bearing in mind that I fully expect you to favor the pure pixel doubling one, but it'd be helpful to know if anything is considered an improvement. 10 taps isn't really a lot to work with so you're probably going to end up with a kind of crude filter no matter what.
Well I do think the filters are helpful when doing fractional scaling. Unfiltered looks bad with the blocky uneven pixels. Obviously nothing is "perfect" when doing fractional scale but a filter of some kind is the best option in my opinion there. This means that, yes, your work on designing filters would indeed be helpful. I think the one used now is a bit too aggressive but you could tweak that. This is also why I think a global setting to enable/disable the filter is a bad idea. Sometimes you may want a filter sometimes not, it depends on source material you are running. I think it should be a setting in each app or at the least a utility you could run to quickly toggle it on/off.

It would be nice to see a horizontal only filter (only apply to horizontal stretch, unfiltered vertically)too as some systems like Turbo Grafx, SNES, NES, and some modes on Genesis could use it.

Since the Pandora is powerful enough to "easily" emulate many older systems now, less time is needed to optimize. So what is left for authors to enhance? I would think the time to develop different filters (no harm in giving users a choice of a few) and menus etc could be a benefit to Pandora emus. If you come up with some good ones they could be used by others.

The time when I (and others as seen in above post) would like to have a choice to not have a filter is when using an even 2X pixel double. In that case a filter is not really needed for some tastes in many cases (for something super low res like GBA or Lynx then again some sort of filter would be desirable) and just adds fuzzyness to normally clean pixels. Your expectation that I would prefer pure pixel doubling may be correct in the 2X case but I will hold judgement until I see some examples.
 
Last edited by a moderator:
Exophase said:
On the other hand, I'm starting to think that there's a difference between standard time domain signal processing and pixels you look at on a screen. On the other other hand, fourier analysis is the basis of almost all serious lossy image, video, and audio compression, so we shouldn't so easily discount it!
discount Fourier? are you by any chance a Lagrange disciple?
 
Last edited by a moderator:
Maybe this pretty recent OMAP Zoom patch should be looked at?

http://dev.omapzoom.org/?p=kishorey/L23x-display.git;a=blob;f=0001-OMAP-DSS-Fix-FIR-scaling-issues-by-def-new-co-eff.patch;h=0c64b7b98bcbedc05696fedba9f53b09f48ce807;hb=d5a938edc059d1b65d94f270533f0922186d64cc

There are several filters for different resample ratios there.

What I posted earlier about the filter characteristics of the coefficients we're currently using only applies if you use a 5x upsample ratio. The TRM isn't 100% clear on the operation of the filter but it probably chooses phase based on the fractional value of an increment. For 2x it probably alternates between the first and second set of coefficients every pixel. So the effective coefficients are:

0 -1 0 13 128 124 0 -8 0 0

For left pixels you'd get something that looked the same as nearest neighbor, and for right pixels you'd get something that's mixed. This form of truncating the coefficients probably gives you a better response than I initially expected but also a pretty dirty (but also pretty subtle) one.

But it could be something pretty different if it chooses phase differently.
 
Back
Top