So I have a few images floating around I was going to post...they are all pixel/sprite style, but because of that most of them are generally right at the edge of the image size lower threshold (around 300x300 or so on average, some a bit smaller).

I was just wondering, should I bother to post them at that resolution seeing as they might just get deleted? Is there any consideration taken for sprite/pixel art that is generally done in those smaller resolutions because they are going to be put into a game engine?

As long as they are bigger than minimum site requirements (200x200) and relevant to the site, go for it. If you want, you can also resample things that are smaller so that they are both clearer and abide by the rules.

Examples

Ratte said:
As long as they are bigger than minimum site requirements (200x200) and relevant to the site, go for it. If you want, you can also resample things that are smaller so that they are both clearer and abide by the rules.

Examples

I only ask because previsouly I posted a single image to test this, post #919822 and it was deleted. It was just within the 200x200 minimum at 333x282. It featured Peg Pete so I knew the content was safe to post here, however it was deleted due to not meeting quality standards.

I would contest that deletion were I you.

What's the intended viewing size (ie. 1x pixels, 2x pixels, 3x pixels?). IMO on a website that has no builtin zoom function (unlike eg https://pixelation.org ), uploading a carefully (integer factor, nearest neighbour) upscaled image is a sensible choice.

Even so, there must be some allowance for the smallness of pixeled sprites: we've got some individual sprites, which are below 300x300 even when upscaled.

It would be nice to have some guidelines, though.. because of stuff like this -- I mean, just no; that is blown up well beyond a reasonable size... something like 32x!. On a 4k screen, blowing up 5x might be ok, but no more than that. Even something like this is a bit too much.

Considering these factors, perhaps a guideline of "Pixel art can be upscaled with nearest neighbor interpolation only, to exactly 2x,3x,4x,5x,or 6x original size. Ideally, matching the intended display size. Pixel art larger than 800x600 should not be upscaled. Pixel art upscaled with non-nearest-neighbour upscaling, non-integer factors, or factors beyond 6x may be deleted."
(phew)
would cover all the major points.

Here's an example of 6x for reference, which sadly and ironically is full of jpeg compression artefacts (it's a gif).

All most users need to zoom is a Ctrl key and a scrollwheel. Although, Firefox seems to limit zoom to 300% by default.

Lance_Armstrong said:
All most users need to zoom is a Ctrl key and a scrollwheel. Although, Firefox seems to limit zoom to 300% by default.

Non integer zoom isn't any good for pixel art.
(Personally also I don't have a scroll wheel, but I've seen the feature you are talking about working on other computers that do.)

I'm not fond of the idea of having the uploader upscale the images, even if they do it correctly. I'd rather it be uploaded at 1x, and something done in the browser (my opinion does not reflect any official policy). I am looking into solutions now.

Pixelation has some javascript that does the integer zoom thing on click. Not sure if it's possible to make it activate only for images tagged pixel_(artwork), but if so, it would provide a nice incentive to get that properly tagged.

(I agree in principle that upscaling on upload is not very nice, but pixel art is generally lo-res enough that -not- upscaling means it may not be legible)

Lance_Armstrong said:
I'm not fond of the idea of having the uploader upscale the images, even if they do it correctly. I'd rather it be uploaded at 1x, and something done in the browser (my opinion does not reflect any official policy). I am looking into solutions now.

I actually fully understand the notion. However usually when talking about altering the work, you are doing something that can't be undone and thus should be avoided (which includes filtered upscaling). When doing upscaling with pixel art, as long as it has been upscaled with nearest neighbor (like savageorange said earlier), it's always possible to scale it back to what it was in 1x really easily. But if there would be some way to do it when browsing, all the better.

There are at least two cases I know that artist was bashed for uploading 1x version with "is this a gif for ants?!?" comments and downvotes, then they flagged and reuploaded upscaled version. So artists themselves sometimes do the upscaling. There is official policy that upscales should be avoided and are always replaced with non-upscaled version, but like said above, when it comes to pixel art many are under minimum resolution limit unless upscaled, then they are removed and bashed for being small.

savageorange said:
Here's an example of 6x for reference, which sadly and ironically is full of jpeg compression artefacts (it's a gif).

Would've been much better if who converted it would've downscaled it to 1x and then back to 6x to eliminate compression artifacting from ugoira.

Lance_Armstrong said:
I'm not fond of the idea of having the uploader upscale the images, even if they do it correctly. I'd rather it be uploaded at 1x, and something done in the browser (my opinion does not reflect any official policy). I am looking into solutions now.

With pixel art, especially sprites, you don't really have much of a choice.

Nearest-neighbor resampling to ensure that it meets the 200x200 minimum with work of quality, there should be no problem. Quality control still matters, so if something is done well and is site-relevant, there should be no issues.

Also, I have gone and undeleted/reapproved your linked post.

When doing upscaling with pixel art, as long as it has been upscaled with nearest neighbor (like savageorange said earlier), it's always possible to scale it back to what it was in 1x really easily

True with the caveat that if people mix resolutions (as in my '32x' example, which I see is deleted now), it's noticably more complicated and may not be possible. This includes things as simple as adding a border that isn't a multiple of the scaling factor in size.

Also the caveat that it really should be uploaded as a lossless format like PNG or GIF, not JPG. That gif-of-jpgs I linked.. scaling it down and then back up would eliminate artifacting, but it would still inflate the palette (many visually-identical but slightly different versions of each color). Well.. that's a pixel artist concern though, maybe e621 doesn't care about that.

With pixel art, especially sprites, you don't really have much of a choice.

+1. it's pretty much what people expect to have to do, you see it on every art site. Storage as an asset in a game and display on the web are very different contexts.

savageorange said:
That gif-of-jpgs I linked.. scaling it down and then back up would eliminate artifacting, but it would still inflate the palette (many visually-identical but slightly different versions of each color). Well.. that's a pixel artist concern though, maybe e621 doesn't care about that.

Apparently that post has only two sources: Pixiv and Twitter.
Pixiv converts gifs into ugoiras, which are bunch of compressed jpg images shown in HTML5 canvas. Twitter converts gifs into compressed AVC MP4. So if it's from those two, it becomes "pick your poison" situation and personally would've chosen inflated color palette over compression.

But nobody seem to have bothered going to artists own website and getting gif directly from there: http://hect.jp/smp7.html
Gonna upload those versions here now. I just hope whoever is handling the flags/approves realizes that half the resolution doesn't mean they're inferior.

Mario69 said:
Apparently that post has only two sources: Pixiv and Twitter.
Pixiv converts gifs into ugoiras, which are bunch of compressed jpg images shown in HTML5 canvas.

Oh, I thought ugoira also supported png.

Twitter converts gifs into compressed AVC MP4. So if it's from those two, it becomes "pick your poison" situation and personally would've chosen inflated color palette over compression.

Yeah it is almost certainly better (although most compressed video has a LOT of similar visual behaviours to JPG).
Like I said, palette inflation is a pixel artist concern. It makes no difference to a viewer.

There are actually other methods than straight downscale though. Just counting the number of 'proper' colors, converting the image to RGB, and then indexizing it to n_proper_colors, should perform decently while having no palette inflation.

But nobody seem to have bothered going to artists own website and getting gif directly from there: http://hect.jp/smp7.html
Gonna upload those versions here now. I just hope whoever is handling the flags/approves realizes that half the resolution doesn't mean they're inferior.

Excellent.

Ratte said:
Also, I have gone and undeleted/reapproved your linked post.

Ah, looks fairly human, I can see why it was originally deleted. Personally, knowing that post #919822 is "Canine" is outside information for me, are we really making an exception to TWYS here?

Furrin_Gok said:
Ah, looks fairly human, I can see why it was originally deleted. Personally, knowing that post #919822 is "Canine" is outside information for me, are we really making an exception to TWYS here?

well the character has black animal nose so its at least animal humanoid if nothing else. also it was originally deleted for being too small.

Furrin_Gok said:
Ah, looks fairly human, I can see why it was originally deleted. Personally, knowing that post #919822 is "Canine" is outside information for me, are we really making an exception to TWYS here?

It was deleted for quality, not content.