I request the ability to use Scale() on an icon without performing anti-aliasing on it. This would be handy for things such as upscaling an icon for a zoom feature or whatnot.
I'm not entirely sure how much of a performance hit it provides when scaling something to around 1600x1000 but if it doesn't already avoid it, I'm sure it might help to not run AA when scaling an icon with only one color.
ID:99689
 Aug 3 2010, 9:37 am
|
|||||||
| |||||||
|
Aug 3 2010, 2:58 pm
|
|
Falacy
 |
Scale has AA o.O I would test, but I'm too lazy and tired right now =P
|
From the reference: "Scale() automatically performs antialiasing to avoid unwanted artifacts."
| |
It's not antialiasing. It's interpolation.
Maybe there can be a number of built in interpolation modes for BYOND, like Nearest Neighbor, Bilinear, and Bicubic? like Icon.Scale(width ,height, mode) where mode is a string or a number that denotes what kind of interpolation? | |
Does it automatically detect what it should use or does it use the same one all the time?
| |
I didn't realize this was the Scale proc's default behavior. I definitely support this request.
It's especially strange that Scale performs anti-aliasing and Turn doesn't. If you're not rotating by a multiple of 90 degrees the rotation will usually produce uglier artifacts than scaling. In this example the default behavior screws everything up: http://files.byondhome.com/Forumaccount/icon-procs.png like Icon.Scale(width ,height, mode) where mode is a string or a number that denotes what kind of interpolation? I'd settle for (and in some ways prefer) a global setting to control this. Adding parameters to the existing icon procs could screw things up, especially for procs like GetPixel that take a lot of arguments already. A global setting would also be more backwards compatible. Just a note: Anti-aliasing is a concept not a technique. Interpolation is one of many techniques used to achieve anti-aliasing. | |
The reason Turn() doesn't do antialiasing is largely that it's a much more difficult problem to solve. There was a dearth of ready-made solutions to the problem.
| |
Rotation has the same problem: a pixel may be moved in such a way that its new location doesn't have integer coordinates. Turn uses something like nearest neighbor while Scale uses some sort of interpolation. There's no reason you couldn't use interpolation to make rotations look nicer.
One thing I hadn't considered for this feature request is the icon editor. It would be nice to have the same options available in the editor so you can generate the same icons as you'd create at runtime. I wouldn't expect it to be easily possible to have the icon editor inherit settings defined in code so I'm not sure how this would work exactly. | |
Forum_account wrote:
Rotation has the same problem: a pixel may be moved in such a way that its new location doesn't have integer coordinates. Turn uses something like nearest neighbor while Scale uses some sort of interpolation. There's no reason you couldn't use interpolation to make rotations look nicer. Again, it's a much more difficult problem to solve. I'm all for doing it, but the math is kinda horrific. One thing I hadn't considered for this feature request is the icon editor. It would be nice to have the same options available in the editor so you can generate the same icons as you'd create at runtime. I wouldn't expect it to be easily possible to have the icon editor inherit settings defined in code so I'm not sure how this would work exactly. Yes, I'd like the two to have parity. There are still some things you can't do in soft code that the editor can, like setting the number of loops, and that I'd like to remedy. | |
The math is a little different but the process is very much the same. To apply a transformation to an icon:
1. For each (x,y) location in the new icon 2. Apply the inverse of the transformation to (x,y) to get (ox,oy). 3. Interpolate the four pixels overlapped by (ox,oy) For scaling you just divide by the scaling factor. For rotation you just rotate by the opposite angle. The math is a little more complicated but I wouldn't consider this to be "horrific". The messiest part of it is the interpolation which should be done for any transformation. | |
Yes, I'm familiar with the rotation matrix and transformations. It's entirely irrelevant to the issue of interpolation however. In what way is the interpolation simple?
Consider: Each pixel in the original icon represents a square. Each pixel in the result icon is a square. Rotating the original repositions all four vertices of the square, covering an area that may be as much as five pixels (perhaps more, but I'm not sure about that). To interpolate this, the transformed square must be intersected with the squares in the result icon, creating a two-dimensional shape with an arbitrary number of vertices (3-8). It's possible to work all this out, but it's not easy; it's also not likely to be very efficient, at least not when compared to any existing algorithms that already do this. If you're aware of such an algorithm, by all means let me know. As for the reason why scaling does interpolation and rotation doesn't, it's because the interpolation problem is a hundred times simpler; the overlapping areas are always rectangles. | |
Pixels are displayed on the screen as squares but think of them as points. An icon is a grid of points and colors are assigned to each point.
The reason for this is that the icon is really a discrete sampling of a "true image". The color values only tell us the color at a point. These samples have no area. We don't know that the underlying image has square regions of color, we only know the color values of the 32x32 sampled points. Assuming that each sample corresponds to a full square of color might not be correct and will end up causing artifacts if you treat it that way. Using this model the same interpolation can be used for any transformation becuase we're not worrying about shapes, just points. | |
I'm not aware of an algorithm in use right now that treats them strictly as points, nor am I sure how you'd handle interpolating them in that way.
While you're right that each pixel is just a discrete sampling, the true image still has to be reconstructed in some form so that at any continuous point, there is color. Treating each pixel as a square is one way of doing that. There may be others that are preferable, but the discrete square method at least corresponds to what we see on the screen so in that way it makes sense. If there is a simple algorithm for handling interpolation based on the sample points alone that does not produce weird artifacts, I'm open to learning and implementing it, but I can think of none. | |
The method I'm describing isn't very different than the current behavior of the Turn proc. It finds a location in the original image for each pixel in the new image it just doesn't do any interpolation. By treating the pixels as points you can easily use bilinear interpolation to get a color value that represents all nearby pixels.
I just updated my Handy Stuff library to include a proc that rotates icons using this method. but the discrete square method at least corresponds to what we see on the screen so in that way it makes sense As intuitive as it might seem, treating the pixels as having area can introduce artifacts because they don't have area. They are just point samples. | |
Pictures tend to work better for explaining things like this so I put this together: http://files.byondhome.com/Forumaccount/rotation.html
| |
I really need this as I use 16x16 icons for a 8-bit based game. Scaling blurs the image too much, and I refuse to upscale to 32x32 because it's not even necessary, let alone cuts down on image size by a load (from my experience with other image formats, haven't checked how significant it is with DMI). I should be able to scale to any size without such a horrendous effect, as screen resolutions are only to get larger in the future.
| |
Neblim wrote:
I really need this as I use 16x16 icons for a 8-bit based game. Scaling blurs the image too much, and I refuse to upscale to 32x32 because it's not even necessary, let alone cuts down on image size by a load (from my experience with other image formats, haven't checked how significant it is with DMI). I should be able to scale to any size without such a horrendous effect, as screen resolutions are only to get larger in the future. Are you using the Scale proc? It sounds like you're talking about the anti-aliasing done by the map display when icons are stretched to a larger size. If you're using the Scale proc at runtime to make 32x32 icons out of your 16x16 icons, you might as well just make them 32x32 in the icon editor. | |
I suspected you were in the wrong topic.
If you were using Scale at runtime to make 32x32 icons I suggested making the icons bigger in the editor because there is essentially no difference. The scaling is performed on the server so clients would have to download the 32x32 versions anyway (whether they're included in the .rsc or are downloaded later). I do agree that the option to change the way the map control scales icons would be useful, especially with the popularity of retro looking graphics on BYOND. I thought there was already a request for that, but if there ever was its probably long lost. | |
(BUMP)
For several reasons I have I'd like Scale() a lot better if antialiasing was completely optional. | |