Pixelation
General => General Discussion => Topic started by: QuaziGNRLnose on June 18, 2010, 08:11:02 pm
-
well i do pixel animations sometimes, and nothing is more annoying than dirty rotation tools, when your using rotation to speed things up, either its puts AA everywhere, that you dont want, or it just messing everything up, even if it doesn't add new colours. i was on Wikipedia and i found this when looking at sprite scaling algorithms.
(http://upload.wikimedia.org/wikipedia/commons/6/61/Tv_rotsprite.png)
heres a picture of the rotation in action, the first image, non rotated, the second, badly rotated, the third, with rotsprite
as you can see it does a beautiful job, adds no new colours, and im sure some animators who make use of rotation would love it, since it barely needs clean up work.
RotSprite is a scaling and rotation algorithm for sprites developed by Xenowhirl. It produces far fewer artifacts than nearest-neighbor rotation algorithms, and does not interpolate or anti-alias, so it does not introduce new colors into the image.[6]
The algorithm first scales the image to 8 times its original size with a modified Scale2x algorithm which treats similar (rather than identical) pixels as matches. It then calculates what rotation offset to use by favoring sampled points which are not boundary pixels. Next, the rotated image is created with a nearest-neighbor scaling and rotation algorithm that simultaneously shrinks the big image back to its original size and rotates the image. Finally, overlooked single-pixel details are restored if the corresponding pixel in the source image is different and the destination pixel has three identical neighbors.[7]
an excerpt from wikipedia ^
http://info.sonicretro.org/RotSprite
-
I experimented a lot with this a few years ago, although I scaled up a few times and cleaned up by hand and then drew down scaled in-engine (games can easily do this on the fly). I suggested it for Cortex Command but we ended up not doing it.
Another thing I experimented with was sampling a couple of pixels rather than just one (crisp) or all (blur).
Mipmapping is another technique that works well, because sampling a small blurry image (at a distance) results in less flicker (more representative sample points).
-
im curious, does cortex command use per-pixel sampling for its rotation or something else/similar?, from what i remember it was quite well done even in the early demo i have.
-
I think it uses plain unfiltered 1x rotation. Pieces of junk are of course irregular with all sorts of angles, but since it's already noisy junk, rotation doesn't hurt much. For weapons and other stuff, a lot of 90 degree angles are used and those survive rotation pretty well. Also, since the things move a lot, some of the ugly rotation artifacts are averaged out.
Raiden II looked pretty good even though it used unfiltered rotation. I think it used a lot of 90 degree angles too.
-
Wonderful, I did not know about this. Will no doubt find use for it, danke!
-
Yes, this is awesome!
-
im quite a fan - wondering how amazing it would be with a more proper ui and some batch processing capabilities <_< >_>
-
I just wish this was built into Graphics Gale or Promotion. Oh man...That would rock so hard. Barring that, what st0ven said. I've used it so much since I got it! Great tool.
-
Yeah I'd love to see this part of graphics gale or something.
-
Integration in any app would require a reference implementation, for a start.
The exe is not sufficient.
Since it's an exe, I want to make my own implementation anyway (Running windows stuff in linux is a bit awkward).
The following parts of the description are not precise enough, IMO:
"It then calculates what rotation offset to use by favoring sampled points which are not boundary pixels."
(are we talking about what position to treat as the image centre?)
"Finally, overlooked single-pixel details are restored if the corresponding pixel in the source image is different and the destination pixel has three identical neighbors."
('single-pixel details' isn't really well enough defined here. Isolated single pixels? single pixels terminating a line? single pixels comprising a 1pix-thick line?)
Though his last activity on that site was in 2007, I'm hoping to get some more specifics out of Xenowhirl.
-
http://forums.sonicretro.org/index.php?showtopic=8848&st=15&p=159754&#entry159754
is that more specific?
-
That's better, thanks alspal :)
I'll implement it and see if I get similar results. I suspect I may still need to talk to Xenowhirl to get it just right.
UPDATE: I've just implemented a working scale2x and the specified adaptation to it. The latter produces some weird patterning at times, however it's true that it does overall smooth more.
-
I just found out about this the other day. Pretty cool.
-
Ai, when that ui'd program is ready id love to see it :D sounds awesome.
-
Ai, when that ui'd program is ready id love to see it :D sounds awesome.
Try reading what I actually said, rather than what you want to hear. I'm interested in writing a reference implementation (that is, code that performs the transformation), so I have no particular commitment to implementing a GUI. I just want this to be implemented in eg. Grafx2
I've been working on the rotation today. So far nothing makes sense about it, I'm just getting blank output. I've never written a rotation routine before though.
EDIT: To clarify, I plan on releasing the code under BSD license, so you would be able to use parts of it directly if you so choose.
-
Keep us posted Ai.. I'd be interested in what you can develop (if you let it be freely available) for implementation in Pixe.
-
Edited my post with intended license info.. and, back at ya : What about releasing the source for your Auto-AAing software?
-
I can't say I have any plans to release any of my source code (asides from what is already available for other projects).
-
I just wanted to add this:
(http://www.argylebox.com/images/mustacheintegrity.gif)
Even pre-touching up, it maintains mustache integrity. As the most important feature, I did not want this to go overlooked. Good day!
(thanks for linking this!)
-
totally awesome!!! this tool is nuts!!!... i tried with few of my pixels and all of them got really "smooth" result.
thx for sharing the link
if you guys got any result, plz post it here or in a new Post :D....
-
I'm currently looking for a tool that allows me to rotate and rescale pixelart. Photoshop seems to do an awful job at that. Maybe I'm using it wrong but can I assume based on your positive reaction to the Rotsprite tool that there isn't any better tool for such tasks yet? If not, what exactly makes rescaling/transforming pixelart so hard to do that there are no decent tools for the job?
(Sorry if I sound ignorant. I tried a web-search on that topic but I didn't find usefull info on that topic.)
-
If not, what exactly makes rescaling/transforming pixelart so hard to do that there are no decent tools for the job?
It's the limited amount of data, in this case pixels.
-
Aye, pixels are the small graphical units in computer graphics, and we just happen to be working with that. If you work with an image 1000x1000 pixels large, rotating and such is no problem because it has a lot more data to work with. However, an image 32x32 pixels large only provides so much data for the algorithms to work with, so it's a lot easier to mess up.
In fact, I'm pretty sure what rotsprite does(from what I remember reading) is scale it up 4x and then rotate it, then scale it back down.
-
It also includes some use of the scale2x algo and some restoration of certain kinds of 'corner/point' pixels.
I concluded it wasn't good enough quality for me (because of the amount of fiddling involved -- generating multiple fractionally different rotations and manually comparing them visually to pick the a good result).
making a more cooperative algo that doesn't require anywhere near as much manual work is on my agenda.
-
Well, I understand that Nearest Neighbour produces undesirable artefacts: The source image is allready highly aliased (loss of information due to low sample frequency) and thus the nearest neighbours color isn't necessarily the best. To find the best more neighbouring pixels have to be evaluated.
Bilinear and Bicubic Interpolation do just that but their flaw is that they return a mix of the colors of pixels found in the neighbourhood and thus introduce new colors. Bad for pixel art where you work with a limitted set of colors.
So it's understandable that the interpolation methods offered by Photoshop don't work well. What got me confused is that I found no algorithm (or rather a tool that implements such an algorithm) that considers all the pixels in the neighbourhood like Bicubic Interpolation and then results the neighbours color that best fit's the averaged value.
Such an approach shouldn't be too hard to do... and wouldn't it give acceptable results when applied to pixel art? From what I understand from that forum post linked above the ROTSPRITE does something similar?
I wouldn't even mind to code my own tool but even then I would have expected to find established algorithms that I could work with. If you all agree that such algorithms have yet to be found I'm intrigued to make it a little side project of mine. (I just thought I'd reinvent the wheel if I tried)
-
So it's understandable that the interpolation methods offered by Photoshop don't work well. What got me confused is that I found no algorithm (or rather a tool that implements such an algorithm) that considers all the pixels in the neighbourhood like Bicubic Interpolation and then results the neighbours color that best fit's the averaged value.
That's cause such a naive algorithym is ineffective.
Rotsprite takes various measures to improve the preservation of SHAPE -- something which an average will not help with. AFAICS the minimum effective filter would have to, for each output pixel, examine the pattern of 3x3 input pixels to choose the best, with some kind of line/isolated point recognition.
-
@lithander, did you tried ROTSPRITE????... it actually do A REALLY DECENT (better) result than the photoshop scale/rotation. I have about 12 years using photoshop and i though the rotation/scale was decent, but ROTSPRITE actually do a LOT BETTER JOB!... so, if your loocking for rotation/scale QUICK, ROTSPRITE would be defenily the first option.
And... as Dusty said......If you work with an image 1000x1000 pixels large, rotating and such is no problem because it has a lot more data to work with. However, an image 32x32 pixels large only provides so much data for the algorithms to work with, so it's a lot easier to mess up....
so, bigger images works better for rotation and scale. And... if you scale x2.x3.x4.x5 and so on, you will be always in the safe place. Now, if you GO DOWN, you will start to get problems with the "new pixels" since the algorithm will put pixels mathematically. Also remember than pixelart is the smaller extent. So knowing this you will understand than some pixels will not exist or will appear a new ones, this if you go from bigger to smaller. And, Rotations with numbers with decimals will get problems for the altorithm too, so to be on the safe zone with rotation, try to use... 90/70/50/30° or numbers with no decimals or sharps angles.
-
@UI: Yes, I've tried rotsprite and the results look good indeed. Way better then photoshop for reasons allready discussed here. But it's hard to integrate that into your workflow when you're working on an image/spritesheet. I hoped for some image editor that rotation and rescaling, ideally with an WYSIWYG interface.
But it's okay if such a tool doesn't exist I just thought I was to blame for not being able to find it.
-
It seems nobody's going to get an open-source version anytime soon, so I guess I'll already implement the simplified algorithm in the interactive brush-rotation tool of Grafx2.
The simplified algorithm consists in:
- perform scale2x 3 times on the image,
- then use a standard "rotozoom" to rotate and divide size by 8 at the same time.
-
It seems nobody's going to get an open-source version anytime soon, so I guess I'll already implement the simplified algorithm in the interactive brush-rotation tool of Grafx2.
The simplified algorithm consists in:
- perform scale2x 3 times on the image,
- then use a standard "rotozoom" to rotate and divide size by 8 at the same time.
why not to send that to the ppl who is developing Grafx2???? im sure they will integrate that in the next version! :DDDD (another reason to get into Grafx2 sometime soon!)
lithander
...But it's hard to integrate that into your workflow when you're working on an image/spritesheet. I hoped for some image editor that rotation and rescaling, ideally with an WYSIWYG interface.
But it's okay if such a tool doesn't exist I just thought I was to blame for not being able to find it.
agree!!!!... soon! if the algorims is that simple i think it will be integrate sometime soon in the most used programs... and to be honestly.. wouldn't be strange that Adobe would integrate it in the future (when they get into this post! JAJAJA)
-
if the algorims is that simple i think it will be integrate sometime soon in the most used programs...
This went into my todo list for Brick Atelier. I hope it's simple enough to implement:)
-
You'll all have noticed that, as yet, there is no open release of implementation code for this, and so you don't see it in any common pixel tools.
The reason is that the approach is perhaps not as simple to decipher as the author, Xenowhirl, would make it appear. He glosses over the logic but doesn't describe the intent, which is more important when documenting an algorithm.
I managed to get Alan Paeth's "A Fast Algorithm for General Raster Rotation" running in about a day -- the shearing approach to rotation is much more amenable to a sane mind than approaching this through direct use of matrix math, or the sample-plot approach which leaves holes. My implementation doesn't do any blending, since the point is to try and avoid anything but the original colours used in the source image (which, AFAICT, is what RotSprite does).
Paeth's approach is not bad and very fast to process, but you will still the get the occasional "toothed jaggies" that are typically seen on aliased rotations (see OP). It is prior to this step that I would need to implement the entirety of something like RotSprite's approach -- the scaling part's already done, but it's the approach to smoothing (aliased smoothing, that is, i.e. no blending of neighbouring pixels) that I need to figure out, and also the approach Xenowhirl takes to resampling the expanded image using offsets, prior to pushing those back into a rotated image.
I think that it's enough to say, "Its been done by someone who wasn't a PhD in computational geometry," so it cannot be that hard to implement an alternative approach with as good or nearly as good results. It's more about recognising where rotated, aliased images tend to go wrong, and using code to fix those errors in the outputted image as a post-processing step. That's what I intend to try as my next step, anyway.
-
Hi Guys!
I tried to implement this algorithm myself.
I integrated the code into my Map Editor for The Forgotten Planet ( http://theforgottenplanet.blogspot.com )
I'm using pretty much the same approach, but don't use any of the "mumbo-jumo" extra stuff he mentions where he describes the algorithm.
Here's the result:
(http://dream-code.se/theforgottenplanet/spriterotate2.png)
(this alien on screen is the main character in the game ;) )
As you can see for your self, this result is quite ok, and looks very similar to the results his program produces.
Scaling to 8x then rotate and scale down to 1x was the best result in most cases. However, Small details are sometimes better preserved with the other conversions.
For example, If you look at the Image you can see that the eyes look better in some versions, then all you have to do is copy & paste the eye, and you're done.
Stand Alone Sprite rotater in this thread:
http://www.wayofthepixel.net/pixelation/index.php?topic=13052.0
- Linux Binary
- Windows Binary
- C Source Code (SDL)
SolarStrings