Death Egg's HD Sprite Project

[Hyllian]

hey hillian,
just wanted to ask if you're still looking into it. I guess an interpolated pixel of the result image is a weighted sum of colors of the original in your algorithm.
can't you just check if one of the components is transparent and then set the result to transparent?
the other idea would be to remove the transparent term in the sum and rescale the weights so that it only consists of non-transparent colors.

Hi. I've got mixed results for now. Here's a tentative:

https://anonfiles.com/file/968ace51f06f ... 7304996b03

It works like this: first convert your png file to 32bits. Choose the color to have alpha (any value different of 255). The rest of the sprite must have alpha = 255.

In this zip I made three execs: 2xBR-t, 4xBR-t and 2xBRh-v2-t. It doesn't touch transparencies, though they're not so accurate as the 3xBR I've used.

Usage:
2xBR-t <input 32bit png> <output png>
4xBR-t <input 32bit png> <output png>
2xBRh-v2-t <input 32bit png> <output png>

Now you don't need the 2 12 args.
Sorry, I hadn't time to make only one exec. So, there's one exec for each filter.
PS: I didn't have time to make a hybrid-v1 version yet.

[Sp00kyFox]

thanks, this modification will definitely help.
test result looks good so far.



I'm gonna make a new sprite package tomorrow.

[Death Egg]

Oh, yeah, that does look a lot better.

[Sp00kyFox]

@Hyllian
ok I took a closer look now at the scaled images (2xBRh-v2-t) and found here and there a few issues.
for the most part the transparency color is ignored but sometimes there is a little pixel which seems to be still affected by it.
see the following images, where I replaced RGB(0,255,255) with RGB(255,0,255) to make the problem visible (you probably have to zoom in):



the two (not quite RGB-perfect) cyan pixels under the hell barons arm, the few ones between the archvile fingers and the green pixel at the left side of its hips.

here are the ones I used with transparency:

[Hyllian]

Ok, that's a known issue. Try this fix to see if no other collateral effects happen:

https://anonfiles.com/file/3e3d59fe5e7a ... 65a751f77b

Screenshot:

---

[Sp00kyFox]

hmm it seems worse. many more sprites have the problem now where before there were fine.
not gonna post new examples. to verify it, the archvile still has the green pixel at its hips (the ones between his fingers are gone though).

well I don't have the source, but could you explain why it is not trivial to fix (don't have to do in detail)? like I said, I thought one could just check if one of the terms in the weighted sums is transparent and just set the result to transparent or set the corresponding weight to 0 and rescale the others. on the other hand I'm just talking out of my ass without fully understanding the cg shader code in the first place.

in the worst case I have to go through all the sprites manually and fix the pixels, but it's still way better than the non transparent xBRh version.

[Hyllian]

The problem is: in the hybrid, I have to swap between algorithms (ReverseAA/xBR) depending on certain conditions. To filter a pixel using ReverseAA, the algorithm needs to "look" a region of radius 2 pixels, that is, all pixels in the image borders (distant a max of 2 pixels from there) only can be filtered by xBR, otherwise the transparent pixels (beyond image borders) will influence the result of ReverseAA (for example, those green shades of some examples posted in this thread).

I'm having problems in regions like fingers and small transparent spots or places where the width is smaller than 3 pixels, as you showed in your examples.

I need to think more about it tonight after work.

EDIT: it seems the same problems happen to the pure xBR-t versions...

EDIT: I know where's the problem. I'll fix it tonight, I hope so...

[Hyllian]

Ok, try this new fix:
https://anonfiles.com/file/2918cf2054c0 ... 5f44ffafe8

[Sp00kyFox]

it's an improvement, not so many sprites with issues as before.
just wanna say that I appreciate you work and at this stadium there is still a manual correction necessary but it's not too much work.
I'm feelin kinda guilty that you're spending so much time on it

if you still wanna look into it though, here are some pictures:

scaled:

originals:


the line of red pixels at the left side of the torsor from the baron.
the green pixel at the right side of the chaingunners head.

[Hyllian]

This problem doesn't happen with this source: http://spriters-resource.com/pc_compute ... heet/27869

Scaled:

[Sp00kyFox]

hmm that is weird, I'm gonna check my work flow and report in later.

[Blox]

What's happening on that sprite sheet?
Whatever it is, it's performing worse than bicubic restricted to the doom palette:

---

And certainly much worse than just vanilla XBR.

---

[Sp00kyFox]

@hyllian
nothing wrong with my workflow, it seems that the sprites from this site were poorly ripped.
I ripped it from the latest version of the doom2.wad and zoomed in to compare mine with the one from this site:

---

correct / wrong:


notice the differences at the yellow ammunition, it's like the interior of the sprite slipped one line down.
here is a correctly ripped sprite sheet (where the mentioned xBRh problem also occurs):
http://i.imgur.com/g4sYuXw.png

@Blox
can't agree with you on that. bicubic is too blurry for pixelart upscaling and xBR has the same problem with fine shades like hqNX. it flattens those areas too much.
try and play for example mortal kombat or donkey kong country with xBR or hqNx, it's terrible. xBR-hybrid on the other hand seems like the real deal with good sharpness
while keeping the detail and shades of the original pixelart intact.
here I took two sprites (scaled and converted to doom palette) I think are good examples why xBRh is superior. well you can't go wrong with a cybies ass. guess the scalers:

---

[Hyllian]

@hyllian
nothing wrong with my workflow, it seems that the sprites from this site were poorly ripped.
I ripped it from the latest version of the doom2.wad and zoomed in to compare mine with the one from this site:

Ok, I`m not an expert in sprites, so I need to use some of your samples to fix bugs.

I'll look into that issue tonight.

[Sp00kyFox]

ok I made a few more sprite sheets to make sure that you're using correctly ripped ones for testing:

---

http://i.imgur.com/sFtPwCm.png
http://i.imgur.com/9fsU8bL.png
http://i.imgur.com/FtnHQSl.png
http://i.imgur.com/jwjvTCB.png
http://i.imgur.com/izB6WkK.png
http://i.imgur.com/YrCEjZ8.png
http://i.imgur.com/q7jZdjg.png
http://i.imgur.com/jn4vDxC.png