Pixelation
Critique => Pixel Art => Topic started by: Kafka on August 15, 2016, 07:27:45 pm
-
(http://www.mediafire.com/convkey/ab8c/60ndfads1h73vjt6g.jpg)
(http://www.mediafire.com/convkey/d708/lpualdab4rm8yp16g.jpg)
-
Wait a second.... that V isn't pixelated... :P
-
sshhh :P
-
(http://www.mediafire.com/convkey/7e4e/8fyllkdvk8ahmdf6g.jpg)
Finished the trilogy, although I'm not too keen on the last one.
-
Not much to critique here with it blown up like this besides how the numbers still aren't pixelart when they can be.
-
I like the contrast between pixel art and non pixelated text. I did try it with pixelated text but it just didn't look right to me.
(http://www.mediafire.com/convkey/6237/ozm9bkgdwwxalnk6g.jpg)
Am I posting the images too large?
is this any better?
(http://www.mediafire.com/convkey/0ca5/ofsak55spfpn4146g.jpg)
-
It's easier to see what's wrong with stuff and make edits to it if you upload at 1:1 resolution. Please keep that in mind when you post on this site. As for the Episode 7 piece, I think there's a tad bit too much noise on Rey and the engines she's sitting on, but I'm pretty new to pixel art so take my opinion with a grain of salt. Also, I think your better off making the roman numerals pixel art as it looks weird with regular text to a pixel art backround.
-
In any case, the software (or method) that you're using to produce the large-scale one completely destroys your pixels. Zoom in a little, and you'll see that there are imprecise soft edges at the limits of the black circle, and considerable "static noise" in many colors.
Remember that GIF is a 256-color format. Even if your main picture is originally low-color (for example using only 20 colors + 120 for a sky gradient), any non-pixel-perfect operation will create/need considerably more colors, for example :
- working with alpha brush, or tools with opacity < 100%
- anti-aliased text
- scaling by a non-integer factor
- smooth
- gradient
Saving as GIF forces your program to settle for only 256 colors, and use dither to mix them (it's a lossy transformation). Now if you re-open the same GIF image later and do more changes (which also need more colors) the dither patterns become worse and worse over time. I think it's what happened for the speeder animation. If you want to work on high-color-count images, be sure to use a "work format" which is loss-less. I don't think there is any standard one for animation, so you'll have to use the native format for your program (ex: PSD for Photoshop), and "Save a copy as ..." GIF to share the result.
-
In any case, the software (or method) that you're using to produce the large-scale one completely destroys your pixels. Zoom in a little, and you'll see that there are imprecise soft edges at the limits of the black circle, and considerable "static noise" in many colors.
Remember that GIF is a 256-color format. Even if your main picture is originally low-color (for example using only 20 colors + 120 for a sky gradient), any non-pixel-perfect operation will create/need considerably more colors, for example :
- working with alpha brush, or tools with opacity < 100%
- anti-aliased text
- scaling by a non-integer factor
- smooth
- gradient
Saving as GIF forces your program to settle for only 256 colors, and use dither to mix them (it's a lossy transformation). Now if you re-open the same GIF image later and do more changes (which also need more colors) the dither patterns become worse and worse over time. I think it's what happened for the speeder animation. If you want to work on high-color-count images, be sure to use a "work format" which is loss-less. I don't think there is any standard one for animation, so you'll have to use the native format for your program (ex: PSD for Photoshop), and "Save a copy as ..." GIF to share the result.
Hey, thanks that's really helpful. I'll keep working on it.