Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. osu!
  3. Help
  4. Resolved Issues

Osu resize takes color value from fully transparent pixels [invalid]

posted
Total Posts
12
ziin
2,632 posts
Joined January 2010
Topic Starter
ziin
The original image is alternating white lines with black lines. The black lines are 100% transparent.
image
When resized in osu, it includes the black, making it look darker (this is on top of a white background).

I think that the alpha channel is not being applied properly when calculating the new color.
peppy
19,301 posts
Here since the beginning
peppy
Because it's not break time?
ziin
2,632 posts
Joined January 2010
Topic Starter
ziin
That's definitely not it.
http://osu.ppy.sh/ss/326041

Take a look at the files and this osz. http://puu.sh/wTMM

white.png and black.png pixel for pixel identical when opened in an image editor.
peppy
19,301 posts
Here since the beginning
peppy
Is the image 1px? If so that is your issue. Make it at least 2x2 (or maybe 4x4).
ziin
2,632 posts
Joined January 2010
Topic Starter
ziin
it's 640x480, alternating 1 pixel horizontal lines of these two colors in RRGGBBAA format:
FFFFFFFF
00000000
FFFFFFFF
00000000
etc...

The 00000000 is a fully transparent black pixel. When the image is being resized, osu sees that the transparent pixel is black and mixes the two colors (white and black) to make a partially transparent gray color.

This happens most often when using text:
How it looks in osu!:


Image with white transparency:


Image with black transparency:


Notice how these two are identical when viewed in a browser? or an image viewer?

What the previous image looks like without transparency:


The top "TEXT" perfectly merges with the white background. The middle "TEXT" has a gray outline from the resize that osu puts on the image. The bottom "TEXT" is just to show you what osu is actually seeing when it is resizing.
peppy
19,301 posts
Here since the beginning
peppy
This is because texture scaling is done using a bilinear algorithm. Not avoidable unless nearest-neighbour is used instead (which would have to be an extra toggle).
ziin
2,632 posts
Joined January 2010
Topic Starter
ziin
Firefox does not exhibit this behavior and uses bilinear interpolation. Why is it unavoidable? Simply add the weight of the alpha channel into the color data. If you've got a fully transparent pixel, it shouldn't be adding anything other than its alpha channel to neighboring pixels. FFFFFF00 would add nothing. FFFFFF80 would add its color at half the normal effectiveness.

Nearest neighbor would be a step down and would look horrible.
peppy
19,301 posts
Here since the beginning
peppy
This isn't actually handled by osu!; it's a direct x/opengl function. The actual colour data is read from the png file bit-exact. If you want it to look better, can you not specify FFFFFF00 pixels for the transparent area?

In fact, it could just be your graphics driver settings causing what you are seeing. Also for the texture you provided above (scanlines), nearest neighbour would look better for sure.
ziin
2,632 posts
Joined January 2010
Topic Starter
ziin
http://www.gamedev.net/topic/393854-ble ... -textures/

Looks like a common problem actually.

The reason I don't specify FFFFFF00 is because the image won't always be that. Sometimes it may have a different transparency, like 00000005 which extends out in a gradient off a crisp white edge. Sure it's a temporary fix, but it's a dirty fix with limitations.
peppy
19,301 posts
Here since the beginning
peppy
It may be a "temporary" fix, but this is the correct way. I can't do anything to improve this without heavy preprocessing.
mm201
osu! Alumni
4,495 posts
Joined August 2008
mm201
I actually have a fix for this in mind.
peppy
19,301 posts
Here since the beginning
peppy
Make the GDI text your first target for fixing, then :P.
Please sign in to reply.

New reply

0
1 / 12