Works like a charm. I had to remove the @4x from line 12 to preserve the original filename. I now have: @echo off setlocal enabledelayedexpansion for /r %%I in (*.png) do ( set RELDIR=%%~dI%%~pI set RELDIR=!RELDIR:%CD%\=! echo !RELDIR!%%~nI%%~xI set DESTDIR=..\output\!RELDIR! if not exist "!DESTDIR!" mkdir !DESTDIR! scalertest -4xbrz "%%I" "!DESTDIR!%%~nI.png" ) endlocal
diamond_sword.png is the default texture. x6 Default.png is diamond_sword.png through 6xBRZ. It's blocky near the border, and the border pixels are unnaturaly glued to the sides instead of forming smooth curves. Theory.png is an image based on diamond_sword.png, modified with an extra line of pixels around the border which represent how I believe xBRZ treats filtering the border. These added pixels I made are the out-of-bounds border pixels, and are a duplicate of its in-bounds border pixels. diamond_sword...
I'm not sure I understand the comic. What do you mean by it? I could privately guess to myself, but I'll give you an opportunity to prevent me from making unfavorable neurological connections. Also, the comic feels off-topic, but who am I to judge if I can't quite parse it? Edit: Please don't beat around the bush. I can take it. If I'm somehow a nuisance, please let me know.
I'm not sure I understand the comic. What do you mean by it? I could privately guess to myself, but I'll give you an opportunity to prevent me from making unfavorable neurological connections. Also, the comic feels off-topic, but who am I to judge if I can't quite parse it?
How do you know that 95% figure? What if there's an unknown but real market for glossy-smooth pixel art blown up to a wall? Can you deny the possibility like that existing? Lots of gamers that were playing in the old days of pixel art are now grown up with walls to decorate. What better than to decorate them with the artwork from their childhood? That's a dangerously decisive (Imagine a judge that was 95% sure) for being in the dark. Like was mentioned elsewhere on the forum, an 8xBRZ would be helpful,...
I just wanted to say thank you to the developer for making such a cool and useful utility. I know that I my sound harsh or demanding elsewhere, but I make requests because I want to see this utility reach its full functioning potential and thereby reach more people. Seeing pixel art look buttery-smooth is an art and an aesthetic, and this does it so well! I'm extrapolating that thank-you necro posts are welcome here!
In "Theory.png," I took it upon myself to extend the border of the default texture by one pixel-showing how the algorithm seems to treat the outside border pixels as merely an extension of the inside border pixels. I COPYPASTED THE BORDER OUT ONE PIXEL, because that's what the algorithm thinks is there. It's a demonstration of what the algorithm uses, then crops out. Out-of-bounds border = outside border pixels = the information that a scaling algorithm needs to extrapolate past the practical canvas...
This program does not work quite the way I would like it to. Specifically, I don't like the way it handles extrapolating the border beyond the boundaries of the given image. The file "Diamond Sword" is the default texture in Minecraft that I will be using as an example. From what I can tell, the xBRZ algorithm extrapolates the out-of-bounds border pixels to be based on the in-bounds border pixels, so I am guessing it treats the borders such that they have the same color, as seen in the "Theory" file...
What is the ideal location to request special licensing permission? How should an inquiring party contact you about alternative licenses? Are you currently consenting to alternative licences, so should people bother or give up?
Is there any chance that you could generalize the algorithm? To be specific, can you generalize the upscaling algorithm such that the given image can be upscaled to any user-chosen power of 2 (or better yet any integer?) If 2xBRZ upscales an image to twice the length in both directions, and 3xBRZ upscales an image to three times the length in both directions, then nxBRZ would upscale an image n times in both directions. For conventional real-time uses (such as in emulators) high-value vectorization...
Is there any chance that you could generalize the algorithm? To be specific, can you generalize the upscaling algorithm such that the given image can be upscaled to any user-chosen power of 2 (or better yet any integer?) If 2xBRZ upscales an image to twice the length in both directions, and 3xBRZ upscales an image to three times the length in both directions, then nxBRZ would upscale an image n times in both directions. For conventional real-time uses (such as in emulators) high-value vectorization...
What if I want to do a whole directory tree? Currently, the CMD file just spits out all the images into its own directory. How can I get it to preserve the directory structure of the images and spit everything out into a new directory with the old filenames? I am trying to use this to make a minecraft resource pack, and the graphics files there are in a non-trivial directory structure.
What if I want to do a whole directory tree? Currently, the CMD file just spits out all the images into its own directory. How can I get it to preserve the directory structure of the images and spit everything out into a new directory with the old filenames? I am trying to use this to make a minecraft resource pack, and the graphics files there are in a non-trivial directory structure.