Reply 20 of 109, by Dominus
- Rank
- DOSBox Moderator
Moved to the patches forum DOSBox Patches
Moved to the patches forum DOSBox Patches
wrote:2. it calulates a scaling factor. E.g. if output screen width is 1024 pixel and the raw image with is 320 pixel, then we ideally need a scaling factor of 3.2. This factor is rounded to 3 and a 3xBRZ scaling is applied.
Can you make it scale evenly with nearest neighbor above the target resolution (in above example, 320 width would end up as 1280), and then start scaling down from there instead? This would provide better quality as the picture would get less blurred getting downscaled with the filter rather than upscaled (not only that but the proportions would be more even for the filter to begin its work); you could scale down to an exact width of 1024 if you add a second lanzcos or cubic filter to prevent distortion.
Don't understand why emulators and such don't scale this way (correct me if I'm wrong) since picture output would avoid the muddy interpolation that plagues uneven stretches; it would look razor sharp instead and not have black borders. It's really necessary in todays world of LCD's being stuck at one resolution.
Great filters by the way!
Regards
EDIT:
Did not mean to make duplicate posts! So sorry. Please remove the excess posts before this one; whoever is moderator. Sorry and thank you.
Kind regards
@Holering: xBRZ is a software scaler. Adding a second software scaler on top for high-quality image scaling is likely to become a CPU performance problem. Nearest-neighbor OTOH is super-fast and simple (but introduces visible artifacts).
Ideally, this second high-quality stretching step would run on the graphics card directly instead of the CPU. However if the emulator does not support D3D output natively, it's not a small task to retrofit this capability. But if there was "official" support for xBRZ, then this would likely be the way to go.
Works slow, but with the frame skipping in "1" works great.
Thanks :)
I tried out the xBRZ scaler, with some interesting results: http://imgur.com/a/UiF2W#7
It's entirely possible that I screwed up, though.
It seems you tested with "aspect=true", where Dosbox adds artificial lines (most noticeable with the numbers 81, 98, ect.). In contrast to the other scalers xBRZ is not really integrated into Dosbox, so this setting needs to be turned off, or it will give those artifacts.
PS: Please don't use lossy .jpg but .png files for comparison and include the non-scaled original image, so that it's possible to reproduce and verify the results.
[quote="ZenJu"] It seems you tested with "aspect=true", where Dosbox adds artificial lines (most noticeable with the numbers 81, 98, ect.). In contrast to the other scalers xBRZ is not really integrated into Dosbox, so this setting needs to be turned off, or it will give those artifacts.
PS: Please don't use lossy .jpg but .png files for comparison and include the non-scaled original image, so that it's possible to reproduce and verify the results. [/quote]
Thanks for the feedback. I redid the comparison: http://imgur.com/a/UiF2W
xbrz looks pretty good, and I like that there's less stretching than the other scalers, though I still prefer the aspect corrected.
(yeah I don't know why BBCode is off and I don't see how to turn it on)
Your input image is already pre-scaled to 977x777, but it should be 320 x 200 for a dos game. Try to find a 320 x 200 png screenshot, then do the comparison again for a real scaler test.
How do I do this? The dosbox settings are:
fullscreen=true
fulldouble=false
fullresolution=original
windowresolution=original
output=surface
usescancodes=true
overscan=0
frameskip=0
aspect=false
linewise=false
char9=false
multiscan=false
scaler=xbrz
autofit=true
I'm just taking screenshots with PRTSCR
Set
scaler=none
aspect=false
and start dosbox in window mode. Then take the screenshot at the native dos resolution.
Ideally non-scaled screenshots should be taken with internal screenshot function (CTRL-F5).
Just a quick note on xBR (I'm aware xBRZ is somewhat different). The new xBR algorithm uses a multi-pass shader, and therefor is incompatible with current shader patches for DOSBox. Would love to see a similar multi-shader approach allowed in DOSBox. The shader I'd probably be more excited to see for DOSBox would be Mdapt, a de-dithering shader that can make things like dithered transparency appear actually transparent, and significantly clean up other dither related patterns.
@oasis789:
If all you want to do is try out dosbox and xBRZ without messing with your settings, then use my dosbox build at the beginning of this post. It automatically does what's required (e.g. it sets internally aspect=false, ect.). Just copy the "dosbox+xBRZ.exe" into your dosbox directory and start.
If on the other hand you want to get xBRZ working with Taewoong's / ykhwong's SVN-Daum build then it's more difficult: You have to adapt certain dosbox settings related to xBRZ manually as described in the first post, otherwise it won't work or won't look good, like on your first screenshots.
I'm not sure if this is the correct place to post this. But oh well...
I made a C++ wrapper around xBRZ, using CImg because I couldn't figure out how Magick++ works.
My program is available at http://jimbo1qaz.ro.lt/files/xBRZ_Scaler.zip .
The problem is when I scale it multiple times, the antialiasing from the first scale causes blurriness in the next ones.
An example from classic xBR (not Z) is shown here: https://lh3.ggpht.com/-V56_DGAQv7Y/T1JopDbYRU … exponential.jpg
Is there a way to turn off antialiasing in the source code version of xBRZ?
jimbo1qaz, me too. I'm trying to make a wrapper for this code, but, between your Scaler and the ZenJu Scaler, generates diferent images, Zenju, Can you help us showing your ScalerTest source code? I'm coding it in MinGW
Using xBRZ is easy: just call xbrz::scale() on the input image and make sure the output image has the right dimensions. This is all explained in xbrz.h
yes but, i get different results using both. Look these.
This is from your ScalerTest (observe the yellow letters)
And this is my result
Did you make another step with the nearestNeighborScale() or equalColor() function?
The features on both images are the same, just some colors are different. Assuming you're using the default configuration paramaters for xBRZ (= default-constructed xbrz::ScalerCfg), maybe it has to do with the way you generate the .png image. The scaler test program uses wxImage for this purpose.
Thanks a lot, i will try with that library, for png images i use libpng.
Next i would consider the gamma factor in scaling operations, in games, is it necessary???
Question, does the scaler support 16bit and 24 bit color, or only 32bits?