Pixelation
General => General Discussion => Topic started by: SolarStrings on August 23, 2011, 07:09:53 pm
-
Hello Guys!
I've created the stand alone program of my implementation of Xenowhirl's "rotsprite".
You can create the best output by:
- Choosing between 8 offsets
- Rotate with 0.1 degrees precision
In the .rar archive you find:
- the source code for the program for both windows & linux.
- windows & linux executable files.
Youtube Video (old 0.1b version):
http://www.youtube.com/watch?v=oEQT3hHyriw
Download here:
https://drive.google.com/open?id=1C3Is_mOTVbfHKWD7fxKPST6moQZP2oQ2
[update v0.2]
- Fixed a memory leak
- Toggle Fullscreen (F4)
- Removed 2x & 4x Image output
- It's now possible to tweak the image output to the best version using the following:
* Rotate image with 0.1 degrees (Keys Q/E)
* Manually choose offset 1-8 (Keys Z/C)
[update v0.1a]
I was linking to the wrong libpng lib.
Linux code blocks project was missing a path to the SDL include folder
[update v0.1b]
Added a/d keys to rotate the image one degree.
If working with a small sprite on a fast computer it could be hard to get the desired angle.
Feedback is welcome!
SolarStrings
-
I really like this, especially because whenever I used ROTSPRITE I end up just generating several images within the angle range I'm looking for, blindly hoping that one is a result that will be useful. Having a problem, however, where nothing is saving. I've only tried it with the example sprite at first, so I tried it with a PNG of my own, but it is still not outputting any files, and it never created an output folder. So I created an output folder into the root directory of where it was saved, and it did end up producing three output files (2x result, 4x result, 8x result) so at least that problem was solved. But it might be worth looking into why it wouldn't work out the folder creation on its own. Windows folder permissions maybe?
-
I updated the v0.1b rar file and added the missing output folder.
The code is not creating a "output" folder atm, so there was no windows folder permission problem :D, just me missing adding the output folder manually before release :)
-
I checked the code, you use only the first part of Xenowhirl's not-completely-documented algorithm (apply scale2x up to 3 times, rotozoom back to original size).
It's the same that I experimented with grafx2 as the interactive brush resizer. I have the same comment as Argyle:
I end up just generating several images within the angle range I'm looking for, blindly hoping that one is a result that will be useful
In my opinion you should think of the following 2 features:
1) Allow more precision than integer degrees. Sometimes 44.9? or 45.1? give much better results than 45?
2) Allow picking the offsets of subpixels : When you perform the rotozoom, instead of looping on 0, 1, etc. up to size-1,you can use 0.5, 1.5 etc. up to size-0.5 This would be an offset of 0.5, meaning you pick the middle of pixels instead of their left border. Since the picture is 8 times bigger than original, you can choose between 8 different offsets, and all will give subtle variations: 0, 0.125, 0.25, 0.375 etc... up to 0.875. Since you can choose different offsets on X and Y, there are 64 possibilities. It's impossible to predict which offsets will give the best visual result.
-
Thanks for the comments Argyle!
There is a lot that can be improved here. This is the first version I put together. I wanted to give the source code to every one as fast as possible so people could play around with it.
Argyle's was pointing at ROTSPRITE, not my sprite rotater:
"I really like this (my sprite rotater), especially because whenever I used ROTSPRITE: I end up just generating several images within the angle range I'm looking for, blindly hoping that one is a result that will be useful."
1) Allow more precision than integer degrees. Sometimes 44.9? or 45.1? give much better results than 45?
This is easy to fix, I'll just change the angle steps down to 0.1. I'll probably add two more keys for even more "finer rotation".
2) Allow picking the offsets of subpixels : When you perform the rotozoom, instead of looping on 0, 1, etc. up to size-1,you can use 0.5, 1.5 etc. up to size-0.5 This would be an offset of 0.5, meaning you pick the middle of pixels instead of their left border. Since the picture is 8 times bigger than original, you can choose between 8 different offsets, and all will give subtle variations: 0, 0.125, 0.25, 0.375 etc... up to 0.875. Since you can choose different offsets on X and Y, there are 64 possibilities. It's impossible to predict which offsets will give the best visual result.
True! I could add two keys that will change the offset between 1-8 pixels and give the result on screen. At the moment the preview in the middle of the screen is the 2x version.
Did you implement "Allow picking the offsets of subpixel" for graf2x?
-
Well if there is something to improve it's getting rid of magic numbers. It may not matter in a small project like this, but it's wise to improve your programming skills with good practices such as avoiding magic numbers.
-
Did you implement "Allow picking the offsets of subpixel" for graf2x?
No, I was really disappointed by the general result, and I'm not even sure I'll keep it because the extra memory needed for performing the rotation really bothers me.
The TV set sprite that serves as an example on Wikipedia (for example) was made by picking a "perfect" angle where the antenna has nice lines. With many other angles or offsets, there are many extra or missing pixels.
-
Yes, i agree, the general result is not the best possible outcome. However, it's still the best algorithm around to rotate pixel art.