MiSTer FPGA Forum

After staring at CPS1 games for a while, I felt like something was a bit "off" when using the "Scanlines (Sharp)" filter. (And I was not much of a fan of "Scanlines (Soft)".) I was not sure if it was sharpening, or something else. I started to focus in on some of the character models, especially the brighter colors, and noticed what appears to be loss of detail in "highlights".

Looking at the "Scanlines (Sharp)", I noticed values were exceding the "128" maximum in the comments [of other filters] for some values in the vertical coefficients.

I ended up pasting the values in Excel, and charting them against Normal_Scanlines_030 [appears to be the equivalent without "brightness" applied]. I manually adjusted values in the upper regions of the curve and came up with values that do not have this loss of detail, at the expense of increased brightness for "bright" colors.

Only thing I am not sure of, if there is a formula that could produce smoother color transitions, or if just hand editing the curve is good enough.

Attached are images created using the PolyphasePreviewer tool [1], comparing the modified filter with the original "Scanlines (Sharp)".

(I also made a second filter with slightly higher values, but still not exceding the "128" maximum. The difference on my screen is very slight.)

Disclaimer: I grabbed the screenshots to use with PolyphasePreviewer from emuparadise.

[1] https://github.com/rikard-softgear/PolyphasePreviewer

 
Color ramps (modified vs original) - (e.g., the brighter colors)
   
SF2 (modified vs original) - (e.g., the roof)
   
SF2 (modified vs original) - (e.g., E. Honda's skin tone)
 

Your mod looks good. Would be good to see normal30 Vs your mod on the same screens in sf2

Here are the same images with Normal_Scanlines_030. Subjectively, looking at them on my computer monitor now, the brightness of the filters I modified, to me, feel about halfway between Normal_Scanlines_030 and the original "Scanlines (Sharp)" filter.

"Scanlines (Sharp)" is a copy of SL_Br_120_070_Sharp. I think I might go back and see how a modified version of the 130% brightness filter (SL_Br_130_070_Sharp) would look, or if the contrast between brighter colors starts to become too diminished (lost detail, even though under the "128" maximum).
 

Just tested your modifications out and I think I like them a lot more. I was always wondering why I had to set the gamma so high to get a natural looking image otherwise highlights looked overblown. With your mod there's a lot more detail and I can use a more moderate gamma value.

Well done. These should be included by default or entirely replace scanlines (sharp) for that matter.

These filters look awesome, thanks for sharing! =)

That is a really good improvement! The color ramps and light colors in the screenshots look a lot better. I do like the soft scan-line filters though. Any chance of you creating improved versions of those as well?

LamerDeluxe wrote: ↑Fri Feb 05, 2021 7:59 am That is a really good improvement! The color ramps and light colors in the screenshots look a lot better. I do like the soft scan-line filters though. Any chance of you creating improved versions of those as well?

I want to revisit the filters and put together a more complete set for a PR. I hope to get some time "soon". I will make a note to include the soft filters, too.

Right now, all of the brighter scanlines have a brightness boost applied. This has several effects

(1) The image is brighter overall
(2) Scanlines become thinned (the dark part is thinner) when the color is close to max
(3) The bright, center portion of the scanline will clip to 255 for bright or saturated colors.

(1) and (2) were desired and (3) is unavoidable side effect. But these were made as an alternative to scanlines with no boost for people that preferred the brighter image.

So what you've done is fix the clipping by making row sums not exceed 128. I haven't really looked to see exactly what math (or if you used math) you used. But I know what the result of this must be.

(4) Fixes clipped colors to avoid detail loss of brighter filters.
(5) Scanlines lose effect (2) above but are now thinner overall.

That may be a good trade-off, but the reason I hadn't done it before is because thin scanlines don't work as well with non-integer scaling factors. And I considered that to be more important than color shift/clipping in the center part of the scanlines because the user always had the option of using one of the scanline filters with lower (or no) brightness boost. That's why all the of the current scanlines are basically 50% bright/dark if you disregard the thinning when they clip to 255.

Having said that, I let discord people tell me the filters they liked best and used those as the "default" filters. I think it was probably a mistake to use one with that much of a brightness boost. But now I wonder what the best default is. Because the different filters have different drawbacks.

Anyway, I'm going to take a shot today at generating some new scanline filters with thinner lines. If I come up with something I like then I'll get that up on github. If the results aren't as good as your filters then we can do it the way you did. But I figure we don't want the entire brightness boosted scanline sets modified this way because that will be excessive.

I'm sure we can figure out something that works.

I put a set of filters on github, with the script I used. I do not have any actual science to back up what I did. I basically took the point on the curves where the slope started to decrease, and replace from that point on with curve from the top portion of a logistic function.

https://github.com/ash2hub/Filters_MiST ... ght%20PHL)

Script is here:
https://github.com/ash2hub/Filters_MiST ... Bright.ps1

ash2fpga wrote: ↑Tue Feb 09, 2021 4:03 pm I put a set of filters on github, with the script I used. I do not have any actual science to back up what I did. I basically took the point on the curves where the slope started to decrease, and replace from that point on with curve from the top portion of a logistic function.

https://github.com/ash2hub/Filters_MiST ... ght%20PHL)

Script is here:
https://github.com/ash2hub/Filters_MiST ... Bright.ps1

Looks good. I wanted to make something like this for a while since it seems like most people stick to integer scaling with scanlines.

I think we could have better names for them. And I want to fix up the names so that if something says 50% scanlines it actually is. Which probably requires me to recalculate the filters so that will happen after we apply your script.

So I'll try to get a script together that makes these filters with appropriate names and labels, make sure it puts your name in the files + scripts, and then get them up on github for you. I will try to do it today but no promises.

Soltan_G42 wrote: ↑Tue Feb 09, 2021 10:45 pm Looks good. I wanted to make something like this for a while since it seems like most people stick to integer scaling with scanlines.

I think we could have better names for them. And I want to fix up the names so that if something says 50% scanlines it actually is. Which probably requires me to recalculate the filters so that will happen after we apply your script.

So I'll try to get a script together that makes these filters with appropriate names and labels, make sure it puts your name in the files + scripts, and then get them up on github for you. I will try to do it today but no promises.

Thanks! I went ahead and closed the PR. Looking forward to seeing how it turns out.

I'm still looking at this. Your script does a lot more than I thought it would

So the thing is that you are effectively taking filters with above full brightness and mapping that back into the 0.0-1.0 range.

So for example a 130% brightness 50% scanline because, after your conversion, a 100% brightness 65% scanline filter.
That's fine of course, but 110% brightness 60% scanline filter also becomes a 100% brightness 66% filter.

So if you run your script on the entire brightness boosted scanlines effects you get a lot of very similar filters. So I want to make graphs of the scanline profile of all of them and see which ones should be kept.

Maybe just one full set from 0% scanlines to 100% scanlines (sharp and soft or maybe even sharp, medium, soft). Or more than one set if there is a reason to have that.

I took another look at the filters across more [most? all?] of the "spectrum". I wish I had done that sooner.

It seems like only a limited range of brightness were particularly useful. I personally use the 120% brightness / 70% scanlines, but I thought the 65% scanlines looked good, too.

At the "high" end (esp 125% and 130% brightness / 80%+ scanlines), there were basically no scanlines any more.

I am definitely OK with only keeping a handful of select filters.

For the future, I am also wondering if to get more "faithful" scanlines, we would need more specific handling, beyond what the parameters for a polyphase filter could provide. I played around a lot with values in the PolyphasePreviewer app, trying to produce "thicker" and "stronger" scanlines than the existing filters, and could not come up with a set of parameters that could do it. But maybe I just do not understand well enough.

The scaler filter was really only meant to implement scaling filters that are up to 4 taps like lanczos2 or bicubic interpolation. We're just lucky that you can make a scanline effect by darkening the phases corresponding to the center of the pixel.

But there are a few ways to calculate scanlines.

(1) Use a gaussian (bell curve) profile for the filter kernel. If the curve is narrow then you get the dark part between rows and if the peak is wider than it goes away. This works ok for darker scanlines but becomes soft/blurry scanlines that aren't as dark.

(2) Calculate the scaling (bicubic, lanczos, whatever) normally and then create a "scanline brightness profile" based on any curve you want and then just multiply teh scanline profile by the scaling coefficients for that row. This works ok too.

I ended up actually just using a cosine curve for the scanline profile because it looked better with non-integer scaling factors than calculating scaling and scanlines from the same gaussian curve. I should point out, in case you didn't see them, that there are regular, not over-bright scanlines in the Misc subfolder of Filters.

If, by "faithful" scanlines you mean scanlines that vary in thickness based on pixel brightness, then we can't do that with the current scaler. Otherwise we'd do that.

Soltan_G42 wrote: ↑Fri Feb 12, 2021 2:15 am The scaler filter was really only meant to implement scaling filters that are up to 4 taps like lanczos2 or bicubic interpolation. We're just lucky that you can make a scanline effect by darkening the phases corresponding to the center of the pixel.

But there are a few ways to calculate scanlines.

(1) Use a gaussian (bell curve) profile for the filter kernel. If the curve is narrow then you get the dark part between rows and if the peak is wider than it goes away. This works ok for darker scanlines but becomes soft/blurry scanlines that aren't as dark.

(2) Calculate the scaling (bicubic, lanczos, whatever) normally and then create a "scanline brightness profile" based on any curve you want and then just multiply teh scanline profile by the scaling coefficients for that row. This works ok too.

Thanks for the implementation details! I have worked with image scaling/resampling code in the past, and was wondering how the scanlines were done.

Soltan_G42 wrote: ↑Fri Feb 12, 2021 2:15 am I ended up actually just using a cosine curve for the scanline profile because it looked better with non-integer scaling factors than calculating scaling and scanlines from the same gaussian curve. I should point out, in case you didn't see them, that there are regular, not over-bright scanlines in the Misc subfolder of Filters.

Yes, I had seen and tried them originally.

Soltan_G42 wrote: ↑Fri Feb 12, 2021 2:15 am If, by "faithful" scanlines you mean scanlines that vary in thickness based on pixel brightness, then we can't do that with the current scaler. Otherwise we'd do that.

Thanks for confirming. I suspected as much. (I would be using my ossc for scanlines, but sample/phase issues have been keeping my from going that route.)

Soltan_G42 wrote: ↑Fri Feb 12, 2021 2:15 am If, by "faithful" scanlines you mean scanlines that vary in thickness based on pixel brightness, then we can't do that with the current scaler. Otherwise we'd do that.

Is it possible to do that with scandoubler? Instead of just darken the whole scanline there would be varying brightness on the doubled scanline. And for even more control could the scanlines be tripled or more?

@Soltan_G42 thanks for all your hard work on the filters and gamma!

Soltan_G42 wrote: ↑Thu Feb 11, 2021 11:01 pm So if you run your script on the entire brightness boosted scanlines effects you get a lot of very similar filters. So I want to make graphs of the scanline profile of all of them and see which ones should be kept.

Maybe just one full set from 0% scanlines to 100% scanlines (sharp and soft or maybe even sharp, medium, soft). Or more than one set if there is a reason to have that.

Are you still looking into applying @ash2fpga's ideas around highlight protection to produce this 0-100% set?

Like most people I'm using 6x integer scaling for CPS1+2 (via [atrac17's set](https://www.patreon.com/posts/updated-20210220-47704037)) and wondering what's the best filter and gamma to use in conjunction with these currently