Note: This text also appears as a forum post for the BYOND Pixel Art Society.
Staff members at Deviant Art recently posted a news article describing how any image containing partial transparencies (alpha channel), or which looks as though it was made using transparency effects, will be removed from the pixel art category. This follows a similar ruling from the folks over at Pixel Joint.
Now, what is Pixel Joint, you wonder? I most certainly did the first time I heard about them. Pixel Joint is an internet community which believes itself to be God's gift to pixel art, and the definitive voice concerning pixel art. Unfortunately, people all over the internet have been duped into believing this is true. Personally, I'm not familiar with their art, and don't care about what they say. How many video games has Pixel Joint ever produced?
This is an important point. Pixel art is defined by it's restrictions, in palette size, color choice, canvas size, and many other ways. But these restrictions aren't arbitrary, like the ones Deviant Art and Pixel Joint are forcing on the art. These restrictions stem from the functional nature of pixel art: Pixel art was born from the restrictions of computers, and had to perform it's function in that environment. Without a function for their output to perform, the folks at Pixel Joint (and now Deviant Art) are grasping at straws trying to keep cohesion. This is fine if a single website wants to say "These are the rules for this website", that's their prerogative. However, when anyone starts saying "These are the rules of pixel art", that's when I get pissed.
The greatest pixel art ever seen (arguably, of course) comes from the SNES era, which made alpha transparencies available as part of the platform. To rule out games like Final Fantasy 6 for it's use of alpha transparencies is a great way to undermine your own credibility. I don't think I'd be here were it not for the wonderfully moody wisps of steam rising above the town of Narshe; these were the first images I ever tried to reproduce as a game (and ran into Internet Explorer's inability to display alpha transparencies).
Now, what is the problem with transparency? The ruling from Deviant Art is that "the only tools used should be the pencil tool, the eye dropper and the eraser". Should I really spend any time going into how ignorant this statement is? God gave me a special finger for these cases, and I choose to use it. Digging into the comments unearths the feeling that transparency dilutes or cheapens the art... I guess this is the same way that I feel about unrestricted dithering, anti-aliasing, or color palettes. However, no one at Deviant Art or Pixel Joint ever says "unrestricted use", and that's really the heart of the matter.
A 1024x768px image using 400 colors certainly doesn't look very much like pixel art, and there's a good reason for that: there was no restriction in either canvas or palette. In the same way, unrestricted use of alpha transparency can cause an image to lose it's identity as pixel art. And that's all that alpha transparency really is, it's an entry in the color palette. If I have one color that's rgb(0,0,0,128), and another color that's rgb(0,0,0,64), these are two unique colors in my palette, not one color with two transparencies. If I use enough of these colors, I'm going to start reaching the grey areas of palette sizes vastly beyond 32 colors (which, by the way, the two sites mentioned above have no problems with; you can find images in the pixel art galleries with over a hundred colors).
We members of the BYOND community are enjoying a new revival of pixel art, in part because of the expanded functionality of the BYOND software, functionality that includes alpha transparency. While we are enjoying this Renaissance, pixel art elsewhere is suffering under new and arbitrary rules designed to stunt its growth, and keep it confined to the tastes of certain communities... communities that are not based in gaming, computing, or, hell, I'd even accept mosaic production at this point!
We at BYOND must never go that way, we must never loose sight of the identity of pixel art. We can't stop there, though. We must resist this trend in all communities of which we are members, for the sake of our art. I will not post another piece of pixel art to Deviant Art until this ruling is reversed, and I would call on every other member here (who is also a member there) to do the same. I will do the same in any other community I belong to which follows Pixel Joint's lead, and I exhort you to do the same.
Even if you aren't a fan of the yea/nay system, please vote here to show your support of pixel art.
Jmurph wrote:
Wow, that is absurd. On so many levels. I hope you're being sarcastic. Pixel art is done with three tools: The pencil and eyedropper, possibly the eraser. Adding other effects renders it to something else that is NOT pixel art. | |
To me (and to many others) the true art form of pixel art lies in how the image is created...
The limits of palette size, canvas size, etc. are only there as challenges to the talent of the artist to properly select colors and pixel placements in the image... How he/she makes those decisions is the true measure of their talent with pixels... Pixel art is the most manual of all digital art forms... It is a direct pixel-by-pixel manipulation to create an image... The use of any automated tools/effects is akin to cheating on this front... Once you allow the editor to do the work for you, you're no longer making what I'd consider to be true pixel art... You're just making a low-res Photoshop... The only automated tool that is forgivable is the fill tool, because it's just a time-saver that doesn't make any decisions for you... Using automated transparency tools is handing color selection to the editor... You have shirked your responsibility to hand-pick colors for each pixel and have let the program do it for you... And thus, it is not proper pixel art... It's as if a writer used an automated synonym tool (I don't know if any exist, but I'm sure they could) to spice up his writing... He didn't go through word-by-word and hand-pick the best one, he allowed the program to do it for him... Do you see that as cheating? Well... [Edit:] As for SNES and transparency: It is forgivable in this context, because it is a necessary evil to have programmatic transparency effects in video games... No graphic artist is going to want to draw the necessary frames to have something like animated transparent smoke/mist... However, in a still image (or even a simple animation), if you want transparency, as a pixel artist, you need to do the work on your own in selecting which colors each pixel needs to be... The end result will ultimately be the same (transparent white smoke over a red object will result in a pink pixel, whether the program does the calculation or the artist does), but you need to do the mental work manually... | |
BigBoiD wrote:
I hope you're being sarcastic. I seriously hope you are being sarcastic... at this point, I can't really tell. Perhaps you're just being facetious and I can't tell. I quote part of my original reply to the DA staff when this news was posted: "I use various tools to help me make my pixel art, but only if I feel that I do have complete control over every pixel. For example, I use a line tool which places a 1px wide line, without anti-aliasing. Now, I could have placed each pixel in that line by hand, or I could save the time and use the blasted line tool (just so long as it isn't anti-aliased, or has any other wierd 'features' ). Really, who uses the pixel tool to fill large areas with a single color? That's what the paint bucket is for! You know that each pixel is going to be filled with the same color (again, so long as it doesn't do any funky blending), so why be anal and use the pencil tool to fill an area? When you want to swap colors, do you use the swap function, or do you manually replace each pixel with the new color? If you want to move a region to the left by four pixels, do you manually redraw the entire thing, or do you just use the selection tool? In the end, it isn't the tool that makes a piece "pixel art". It's the artist's knowledge of each part of the image; it's the fact that each pixel was examined individually, and skillfully crafted to get the most out of that unit on the grid. Once you loose sight of this, you're just making arbitrary demands on the artist, and stunting the community." (end quote) I guarantee you that even these elitist snobs are using the selection tool, the paint bucket tool, and swap color functions (such as non-contiguous paint bucket options). | |
Alright, so I'd also forgive one-pixel, non-antialiased line drawing tools and any other time-saving tool in which you make all of the decisions...
But when dealing with transparency, the program is making the decisions by doing the color mixing for you... This is not forgivable... | |
SuperSaiyanGokuX wrote:
The use of any automated tools/effects is akin to cheating on this front... I completely agree with everything you have said here. However, I'm not advocating the use of complicated automatic filtering nonsense. I'm saying that the alpha channel is an aspect of a color, just like the red channel, or the blue channel (but not the green channel, they get an extra bit on some displays. Unfair!). Consider that I'm working on a piece, and I make the following selections for my palette: color_table[1] = rgb(0,0,0,255) color_table[2] = rgb(0,0,0,0) color_table[3] = rgb(0,0,128,0) color_table[4] = rgb(0,0,128,64) I then place each of those colors manually, pixel by pixel, nothing automated. Why would you throw out my image, just because I use some alpha transparency, in the exact same way SNES game makers did it? The only automated tool that is forgivable is the fill tool, because it's just a time-saver that doesn't make any decisions for you... Disagree. There are many other automated tools that don't make decisions for you, such as the selection tool, DM's line tool (the best one out there), and color swap functions. So long as I have control over my pixels, the tool is valid. But when dealing with transparency, the program is making the decisions by doing the color mixing for you... This is not forgivable... This is only true in some implementations. As noted above, I can use transparency and still have complete control over every color (rgba) in my piece. As for SNES and transparency... It is forgivable in this context, because it is a necessary evil to have programmatic transparency effects in video games... No graphic artist is going to want to draw the necessary frames to have something like animated transparent smoke/mist... I'd agree with you that the entire game being played out with smoke moving over other tiles and players walking around is not pixel art; it's a game. But to say that each individual frame of the smoke, on it's own and not above any other tile or image, is not pixel art because it uses alpha transparency, is just arbitrary. | |
IainPeregrine wrote:
I'm saying that the alpha channel is an aspect of a color, just like the red channel, or the blue channel (but not the green channel, they get an extra bit on some displays. Unfair!). Consider that I'm working on a piece, and I make the following selections for my palette: But you see, even though you've set up each color you're placing, you have not manually selected the color that each pixel in your finished piece will be; you're allowing the program to do the blending for you when you place a transparent pixel over another color... It is my opinion that you need to be doing those calculations manually... The Artist needs to be figuring out what a certain pixel should be based on the colors he wishes to be blended there... The only automated tool that is forgivable is the fill tool, because it's just a time-saver that doesn't make any decisions for you... Yeah, I can also forgive any other automated tool/function/effect that is nothing but a time-saving device that doesn't do any automated adjusting of the colors used... But when dealing with transparency, the program is making the decisions by doing the color mixing for you... This is not forgivable... Not really, though... Sure, you have direct control over what exact RGBA value your tool will be placing, but you only have indirect control over the interactions that color will have with whatever is underneath it... Again, figuring out mentally the proper shade of pink that "transparent" white over red will result in is much different than allowing the program to blend them for you, even if you have a good idea of what the result will be... I'd agree with you that the entire game being played out with smoke moving over other tiles and players walking around is not pixel art; it's a game. But to say that each individual frame of the smoke, on it's own and not above any other tile or image, is not pixel art because it uses alpha transparency, is just arbitrary. Actually, I agree on this point... That might not seem possible, given my stance on the overall matter, but in this case, the individual piece without any interactions with other colors, is purely pixel art... It's only when the program begins handling the interactions between the transparent pixels and those under them that it moves away from being pixel art... | |
To sum up my point, using a quote found in the comments for the DeviantArt post:
So if want to know which color something should behind a glass, I should figure it out myself? Yes | |
SuperSaiyanGokuX wrote:
But you see, even though you've set up each color you're placing, you have not manually selected the color that each pixel in your finished piece will be; This is why I worded my post the way I did. A pixel is a number which corresponds to a color in the color table (the palette). Were I to use a 'tool' to blend a transparent color on top of another transparent color, I'd be adding a new entry to my color table. However, If I place the value '4' (rgb(0,0,128,64)) into memory, I have not blended anything. Even if the number '3' used to reside in memory there, '4' resides there now. No blending. I am manually selecting each value in the grid from one in my color table. This is pixel art at it's purest, alpha transparency and all. you're allowing the program to do the blending for you when you place a transparent pixel over another color... It is possible to have alpha transparency in an image without ever using transparency-blending features. Were I to take two color_table values and replace one with the other in memory, this is what it might look like: rgba(255,0,0,128) is replaced by rgba(128,128,0,64). Each contains an alpha channel componant, yet no blending ever occurs. It seems the people at Pixel Joint and DA are ignorant to this fact, and that's why it pisses me off that they're making broad ranging decisions based on their ignorance. SuperSaiyanGokuX wrote: To sum up my point, using a quote found in the comments for the DeviantArt post: Yes, because in that case he's making an image by laying a semi-transparent image over another one. Were he just making an image of a semi-transparent piece of glass (perhaps to be used in a game) with nothing underneath it, and no blending occuring with anything else, then that is pixel art. | |
IainPeregrine wrote:
I seriously hope you are being sarcastic... at this point, I can't really tell. Perhaps you're just being facetious and I can't tell. Then I have accomplished my mission. | |
IainPeregrine wrote:
This is why I worded my post the way I did. A pixel is a number which corresponds to a color in the color table (the palette). Were I to use a 'tool' to blend a transparent color on top of another transparent color, I'd be adding a new entry to my color table. However, If I place the value '4' (rgb(0,0,128,64)) into memory, I have not blended anything. Even if the number '3' used to reside in memory there, '4' resides there now. No blending. I am manually selecting each value in the grid from one in my color table. This is pixel art at it's purest, alpha transparency and all. Forgive me, but I fail to see the point here... Pixel art is created by changing the color of the pixels in an image area, not by adding or changing colors in the palette... When you place a solid color, it changes that pixel to that solid color... This is the only pure pixel art... When you place a transparent color, it changes that pixel to a blend of that color and whatever color was already in that pixel (even if that pixel was completely void of value, IE transparent, beforehand) This is an automatic effect, calculated by the program, and that's what makes it "wrong"... It shouldn't be up to the program to say that transparent white over top of another color will make a light shade of that color... (255,255,255,128)+(255,0,0,0)=(255,128,128,255) I'm saying that instead of letting the program add the two colors for you, you should have manually selected (255,128,128) for that pixel... It is possible to have alpha transparency in an image without ever using transparency-blending features. Were I to take two color_table values and replace one with the other in memory, this is what it might look like: rgba(255,0,0,128) is replaced by rgba(128,128,0,64). Each contains an alpha channel componant, yet no blending ever occurs. It seems the people at Pixel Joint and DA are ignorant to this fact, and that's why it pisses me off that they're making broad ranging decisions based on their ignorance. If you are placing transparent-valued pixels over absolutely nothing underneath (IE blank canvas) then fine... But even in this case, a "blank canvas" is often white... Or, in the case of graphics displayed over a colored background, the blending will occur then... The fact is that at some point, every transparent pixel you place will be blended with another color... SuperSaiyanGokuX wrote: Sure, but this entire argument, and the sentiments of the rules that spawned it, wasn't started over people drawing images of single panes of glass over nothing, or images of transparent smoke... They're all talking about adding these things into "traditional" pixel art images/scenes... And in those cases, automatic blending will occur... New colors will be generated by the program... | |
I would think that if you placed all the pixels by hand, and personally chose the RGB and alpha levels for each pixel you placed, the result would be pixel art.
But then, I'm crazy. So crazy that if I ever try my hand at pixel art, I may even use tools like "fill circle" and "move selection". And none of you can prove a thing! Ha ha ha ha haaaaa! [Edit: When pixels of the future support additional features like "fluorescence" and "z coordinate", the argument will get really complicated, but my basic principle of hand-pickedness will abide!] | |
SuperSaiyanGokuX wrote:
Pixel art is created by changing the color of the pixels in an image area, not by adding or changing colors in the palette... Err, Wrong! Modern image formats, like the .png and .gif files that today's pixel artist are used to using store color information in the document. However, the formats used by pre-32bit consols did no such thing. An image was a grid of numbers, which corresponded to entries in a color table global to the program. Pixel artists needed to keep in mind both the individual image they were working on, and how the color table changed programatically. This is why all shop keepers in The Legend of Zelda get blue cloths the moment Link buys the blue ring. Link's image doesn't change, a value in the color table is swapped. To say that pixel art isn't about color tables is to disregard the increadible work of some of pixel art's greatest. But that's a side issue. When you place a transparent color, it changes that pixel to a blend of that color and whatever color was already in that pixel Err, Wrong again! If you programatically cange the value of a grid position, or use a tool that's designed to change a grid position's value without blending, then guess what? No blending occurs! The new value is placed down intact, without taking any color or opacity from the old value. This is an automatic effect, calculated by the program, and that's what makes it "wrong"... Ever used a program that gives the option of not automating this? From your arguments it would seem that you think it's impossible for a computer to place a pixel with alpha values without blending. This is patently false. The fact is that at some point, every transparent pixel you place will be blended with another color... Bloody hell. For the last time, no! I use tools that replace one color (rgba) with another color (rgba) without blending. No blending ever occurs until that graphic is put into a game. This is possible to do, so stop asserting that it isn't. [...] this entire argument, and the sentiments of the rules that spawned it, wasn't started over people drawing images of single panes of glass over nothing, or images of transparent smoke... Read the thread on Pixel Joint. This was started over a user who made an image with alpha transparency... over nothing. The image was only using alpha transparency to Anti-Alias with a variable background. Each value was hand selected and hand placed. That's what this entire post is about, is that the good is being thrown out with the bad, that these bones heads are ignorant to the fact that alpha values can be used without automation of color selection. Read and understand what I'm saying before responding. It is possible to lay down a pixel with alpha levels without blending with the value there before; I'm frustraited because I can't think of a way to convey this more clearely, and I hate repeating the same argument. Until you come up with a different basis for any anti-alpha argument, I don't want to hear the same tired assertion that you can't use alpha without automation. You just have to be using a program with a replace, instead of blend, option. Such programs exist. Even more importantly, it can be done programatically via the manipulation of a color table. If you want to hate on transparency for some other reason, go ahead, I'd love to hear it. But don't harp on the same damn tired rhetoric about uncontrollable alpha blending. | |
I have always seen pixel art as the simplist of art forms and should be untouched by filters/algorithms, layers, and alpha. I don't exactly care what people call it, it isn't that important and people need to allow the term to transform for the future.
I guarantee you that even these elitist snobs are using the selection tool, the paint bucket tool, and swap color functions (such as non-contiguous paint bucket options). But alpha isn't just mixing colors. It creates a whole new system of working with images, with multiple layers and automatic anti-aliasing etc. Sure, it's a little stupid to not allow people in their little club because of it, but alpha isn't just a shortcut like the rest of the tools; it's a more advanced form of art. You could say similar about vector art. Sure, it just allows things to be created faster, but it's a completely new art form that doesn't take as much skill to create and doesn't take as much time. You shouldn't mix the two together. | |
Why not just call pixel art without alphas "24-bit pixel art"? That clearly sets aside a well-delineated realm for the purists, since adding alphas requires an additional 8 bits.
| |
Kunark wrote:
But alpha isn't just mixing colors. It creates a whole new system of working with images, with multiple layers and automatic anti-aliasing etc. Perhaps I should be clearer. Please let me know if this makes my point more clear to you, because it's becomming apparent to me that most people arn't familiar with the distinction I'm making here. Most people use transparency options in image editing programs to create multiple layers with varying transparencies, which are then merged down to create a final image. I am completely in agreement that we shouldn't generally refer to this as "Pixel Art". These artists use transparency as a method in the production of an image. An example of this might be an isometric building which a blue window tinting the people standing behind it. There is another use of transparencies, though. This second use is rare outside of the production of video games, so most amature pixel artists have never had to encounter it. In this case, a single image is created on a single layer, with nothing behind it, and rgba values do not blend, they replace. In this second form, alpha values count toward the final color count, because each unique rgba color is indexed in a color table. Transparency is not used as a method in the production of an image. Transparency is a part of the image which allows other images to show through once the image is put into a game or program. An example of this might be a large cloud graphic, which, once added to a game, might show bits of the landscape behind it. In this second type of pixel art, nothing is ever blended, until it's put into a game. However, we're judging the art as based on the image outside of the game, so no blending ever takes place. This second form is pixel art. I'm not willing to say that the "purists" can have their pixel art without transparencies while the rest of us do what we want. You see, I am a pixel art purist. I've been working within the confines of 8bit and 16bit pixel art for ages, and I'm not willing to concede that their relatively recent, and completely arbitrary, rules are a more 'pure' form of the art. It's a subset trying to push out it's superset. | |
You see, I am a pixel art purist. I've been working within the confines of 8bit and 16bit pixel art for ages, and I'm not willing to concede that their relatively recent, and completely arbitrary, rules are a more 'pure' form of the art. It's a subset trying to push out it's superset. I am reminded of Emo Phillips: I said 'Are you a Christian or a Jew?' He said 'Christian.' I said 'Me too! Protestant or Catholic?' He said 'Protestant.' I said 'Me too! What franchise?' He said 'Baptist.' I said 'Me too! Northern Baptist or Southern Baptist?' He said 'Northern Baptist.' I said 'Me too! Northern Conservative Baptist or Northern Reform Baptist?' He said 'Northern Conservative Baptist.' I said 'Me too! Northern Conservative Fundamentalist Baptist or Northern Conservative Reform Baptist?' He said 'Northern Conservative Fundamentalist Baptist.' I said 'Me too! Northern Conservative Fundamentalist Baptist Great Lakes Region or Northern Conservative Fundamentalist Baptist Eastern Region?' He said 'Northern Conservative Fundamentalist Baptist Great Lakes Region.' I said 'Me too! Northern Conservative Fundamentalist Baptist Great Lakes Region Council of 1912 or Northern Conservative Fundamentalist Baptist Great Lakes Region Council of 1850?' He said 'Northern Conservative Fundamentalist Baptist Great Lakes Region Council of 1912.' I said 'Die heretic!' And I pushed him off the bridge! [Edit: I got the script off the Internet. Don't remember if it's the original version I heard on a tape of him, but it's close enough.] | |
The problem is that the sort of usage you're advocating, while perfectly valid if used exactly the way you've described, is of very little use to the majority of users of those sites, who concentrate their efforts on still images/scenes and not dynamic content...
For the purposes of nearly everyone using those gallery sites, transparency has no legitimate use... [Edit:] Note, though, that I don't think they've got the right to state it quite like they have... It's not their place to dictate this to anyone outside of the users of their site, and the uses they'll allow on those sites... But I think that's just a case of poor wording, rather than some effort to control everyone's definition of "pixel art"... [Edit 2:] However, I'd still say that even though the blending doesn't occur until the time of dynamic display, it is still handled entirely by the machine... To put in transparent pixels for anti-aliased edging allows the machine to do the blending for you later... It's still an automated method of getting nice edges... You're allowing the display program to do your edge blending for you... There's nothing inherently wrong about this, though... It is a nifty trick and almost necessary in a dynamic context (IE a video game), because it's all but impossible to select a solid color(s) to do your antialiasing with that will look good over every possible background, but it's still not quite a true showcase of pixeling ability, because you're shunting the real work off onto the graphics rendering with this shortcut... | |
SuperSaiyanGokuX wrote:
Lots of stuff. I think I'd have to agree with everything you've said there, including that using anti-aliasing for edges is just pushing the task onto the display program later. I just feel that little quirky features, the ones most abused and misunderstood, are often the most powerful. I've heard so much about "removing goto from DM" and "no put usr in proc", but I have been in looping situations where I needed some gotos, and I've made procs to be added as dynamic verbs. It's like killing off a character in a book. It's a cheap way to gain some quick emotional points, and it is tremendously overused, to the point where I hate plots that rely on it; but there are some fantastic stories out there that use it to great effect. I realize that most people who voted "yea" to my post don't understand the distinction I've made, and are voting "yea" to transparency as a shortcut, and I understand ShoneGold's (and others') reasons for this choice. Arbitrary restrictions like this are just one of my biggest pet peaves, though. No amount of explaining or experience can make me really understand how a person (not you, I'm talking about the original poster over at Pixel Joint) can recognize one thing as being valid, yet still place rigid restrictions on it. I can't understand it, and it just drives me right up the wall. | |
I can see nixing alpha trans for specific projects, contests, etc. But to say it is not pixel art? What a bunch of snobtards!