The main purpose of the superabsurd_res tag is to offer an easy way to blacklist images that are too hefty for some platforms and browsers. The wiki simply lists the requirements as >10000 pixels for either width or length, but because of that, it's getting tagged for comics:

post #806288 post #787937

While the height is indeed over 10000, those are far less likely to cause any problems. Maybe we should change the requirements? Something like >10000 in one dimension, and at least >2500 in the other?

Also, a related question: should we have a tag for large filesize (something like >30MB)? That might also be useful for blacklisting, and most other boorus tag it. For instance, Danbooru has the huge_filesize tag. Might be helpful to users who pay by MB or simply have a slow connection.

When it was proposed, I think I suggested that the square root of (W * H) was used, or an MPix value. I understand that's harder to work out than the current definition... OTOH in my opinion the fact that we currently tag *_res at all is a workaround for a missing feature in the uploading system (automatically adding basic image characteristic tags)

An alternative definition is 'Take the minimum of W and H; If it's >7500, superabsurd_res.'
(this is based on the same 10000 figure, and a rough estimate that the typical picture is 3:4 or 4:3... It might need adjustment downward, if that assumption is wrong (images that should be tagged superabsurd_res wouldn't be))

Either that or (width + height) / 2... it's about as awkward though

I do like the idea of huge/large filesize (and it would be extremely easy to mass tag them).

parasprite said:
Either that or (width + height) / 2... it's about as awkward though

That would make it tough to add those by tag scripting, and to check if they're tagged correctly.

parasprite said:
I do like the idea of huge/large filesize (and it would be extremely easy to mass tag them).

Indeed, though it would be even better if such tags were added automatically when uploading.

What would be a good filesize threshold? It's 10MB on Danbooru and Gelbooru, but that seems kind of lowish to me.

EDIT: I started adding it, after noticing that post #690023 actually crashes my browser. And based on the comments, I'm not the only one. For now I've only tagged it for >50MB, but we probably want to lower that a bit?

I actually lol'd a bit when someone tagged these as hi res:
post #809193 post #810103
Both are also under 1 MB

Filesize would serve the purpose, there are always few morons which think that making 50 MB gifs is good idea.

I've recently conversed with Parasprite regarding that bulk tagging that I recall Wodahseht did in regards to the dimensional size of an image.

According to the wiki regarding hi_res only posts that are equal to or greater than 1600x1200 (and therefore 1200x1600) should be tagged hi_res. But after typing "width:<1200 height:<1600 hi_res", I'm greeted to over 95,000 images that are sized below those margins.

I'm not implying that Wodahseht made a mistake with size tagging, but I do know that he did an immense amount of tagging regarding it.

My proposal is that images with pixels from BOTH the length and width should be greater than or less than the necessary dimensions to be tagged. Otherwise, we may get what I'm assuming is a colossal mistake based on potential misdirection.

GameManiac said:
According to the wiki regarding hi_res only posts that are equal to or greater than 1600x1200 (and therefore 1200x1600) should be tagged hi_res.

No, it says:

Posts with this tag should be at least 1600 pixels wide or 1200 pixels tall.

One or the other, not both. Same as all the other resolution tags, except low_res. Larger than a standard monitor in at least one dimension. I'm not saying that it's the best way to tag those, but it's how those have been tagged since they were created.

Come to think about it, that's pretty low by modern standards. The most common resolution on Steam is 1920x1080, so 1600 is no longer larger than a standard monitor.

Genjar said:
One or the other, not both.

But then what if the image is narrow or stretched out, such as this image, with a size of 329x1280 (86.5 KB)?

post #2356

Is tagging based on the dimensions of the image itself even valid anymore?

GameManiac said:
Is tagging based on the dimensions of the image itself even valid anymore?

As I said in the opening, it kind of defeats the purpose of those tags.

Under the current definition, those are tagged correctly. But we probably should change the definitions. Not just for superabsurd_res (although the problem is worst for that one), but for the whole group. So that those don't get tagged for extremely narrow posts.

Genjar said:
As I said in the opening, it kind of defeats the purpose of those tags.

Under the current definition, those are tagged correctly. But we probably should change the definitions. Not just for superabsurd_res (although the problem is worst for that one), but for the whole group. So that those don't get tagged for extremely narrow posts.

What if we multiply the dimensions together and base tagging the file size off of that?

For example, 500x500 would be 250,000 pixels. Anything less than that would be marked with the low_res tag.

GameManiac said:
What if we multiply the dimensions together and base tagging the file size off of that?

Sounds logical, but on top of a lot of retagging, it will also be annoying to tag future posts with resolution tags because you have to calculate it every time.

I think only superabsurd red should need a little improvement.
I also find it odd that there's no tag inbetween hi res and superabsurd res, since there is a good deal of posts around 5000 pixels tall.

Someone say superabsurd rez?
post #86667

On subject, I think those should be automated aliases for the mpixel metatag instead of user-added tags. This could be done easily when calculating the image size when generating thumbnail/getting image meta data/etc.

GameManiac said:
What if we multiply the dimensions together and base tagging the file size off of that?

Anything that involves math is both time-consuming to tag, and difficult to check for mistags. It'd be better to add minimum sizes, since those would be easily searchable.

Something like... hi_res:
Posts with this tag should be at least 1600 pixels wide or 1200 pixels tall, and the other dimension should be at least 400 pixels.

That would weed out these posts: height:<400 hi_res and width:<400 hi_res, and would be easier to check.

Genjar said:
Anything that involves math is both time-consuming to tag, and difficult to check for mistags. It'd be better to add minimum sizes, since those would be easily searchable.

Something like... hi_res:
Posts with this tag should be at least 1600 pixels wide or 1200 pixels tall, and the other dimension should be at least 400 pixels.

.. If you go with that, I don't see how it's substantially different from the minimum, maximum principle I suggested (other than what you define here is MORE complex).

Maybe I should reword my previous suggestion to illustrate; for hi_res eg. Posts with this tag should be at least 1400 pixels along the larger dimension, and at least 400 pixels along the smaller dimension.

(unless aspect ratio is actually important to people? I don't think we can really count on a 4:3 ratio (as 1600x1200 is) making sense for all platforms)

savageorange said:
.. If you go with that, I don't see how it's substantially different from the minimum, maximum principle I suggested (other than what you define here is MORE complex).

Having *set* values will be less complex from a tagging standpoint than something where math is required, because a simple search string can find everything matching and can be tagged using scripting.

Problem is that *any* additional riders/rules for a tag that people already have trouble with is going to make maintenance that much more time-consuming.

As it is, even once I got everything caught up by current guidelines, it's still not uncommon to see 5+ pages a day of new images that need appropriate *_res tags added (or removed).

Wodahseht said:
Having *set* values will be less complex from a tagging standpoint than something where math is required, because a simple search string can find everything matching and can be tagged using scripting.

It's clear that you didn't actually read my post, which uses *less* math than Genjar's proposed definition.

savageorange said:
It's clear that you didn't actually read my post.

I did actually. Summed up: "Instead of looking at largest dimension, look at smallest and tag based on that."

I didn't say I was more interested in either option, yours or the one you were replying to. I was making an observation that as long as set values are used it'll be relatively easy to tag.

---

As to mistagging, the thing most often resulting in mistags is people don't tend to pay attention to which dimension is which, so just having same value for each side would clear a lot up. Something like (going with your approach):

> 7500 both directions -> superabsurd_res
> 5000 both directions -> absurd_res
> 2500 both directions -> hi_res
< 500 both directions -> low_res

Wodahseht said:
I did actually. Summed up: "Instead of looking at largest dimension, look at smallest and tag based on that."

That's was my original suggestion. My subsequent post adjusted it to allow for aspect ratio.

I didn't say I was more interested in either option, yours or the one you were replying to. I was making an observation that as long as set values are used it'll be relatively easy to tag.

Which I can certainly agree with

As to mistagging, the thing most often resulting in mistags is people don't tend to pay attention to which dimension is which, so just having same value for each side would clear a lot up. Something like (going with your approach):

> 7500 both directions -> superabsurd_res
> 5000 both directions -> absurd_res
> 2500 both directions -> hi_res
< 500 both directions -> low_res

I think I could get behind this.

• 2500 is more or less in the vicinity of WQXGA
• 5000 is roughly 4K (the standard, not the number)
• 7500 is whatever (standards are nowhere near this yet, but 1.5x of absurd_res seems fair enough)
• the whole lot's fairly easy to memorize (500 * 1, 500 * 5, 500 * 10, 500 * 15)

There's barely any practical difference between 5000x5000 and 7500x7500: both are likely to crash mobile browsers, and both are far too large for a standard monitor.

Which is why I suggested the 25 megapixel threshold in the opening (10000 x 2500). If we make it even higher than that, superabsurd_res would be useless as a blacklist tag. The minimum of 7500 in both would far beyond what's causing problems. And posts such as post #539400 (74 megapixels) would no longer be tagged as superabsurd_res. ...I think that one needs the tag.

2500x2500 is also too much, considering that hi_res is currently the 'larger than an average monitor' tag. Heightwise, that'd more than double the standard.

Maybe we should just scrap the current way of tagging those by the resolution, and switch to the megapixels. The mpixels:<size> search exists, so those would be easy to tag script. (Not so easy to tag while uploading, though.)

For instance, we could tag superabsurd_res for >25 megapixel, absurd_res for >8 megapixel, hi_res for >2.5 megapixel, and low_res for <0.25 megapixel... As an example, these would fit just fine under low_res: mpixels:<0.25 -low_res.

I think I (and possibly others) were avoiding suggesting MPix too seriously at least partly because most users don't have tag-scripting privileges. That wouldn't stop some of us -- and I guess it wouldn't be that hard to add automatic tagging on upload to E6Extend -- but that still leaves the average user.

Adding a visible Mpixels measure, after the 'filesize' measure could aid tagging, but presumably would only be visible *after* the upload.

Yeah, there's that. If only it were possible to add such tags automatically to uploaded posts..

But even leaving it to tag scripters might be more accurate than the current system. Under the current standard, post #785992 isn't low_res, and post #466580 isn't superabsurd_res... Tsk. With a focused effort, we could tag script everything by megapixels in a few days, and then there'd only be new posts to worry about.

I would almost like the huge_filesize to be much lower. 50 MB is huge for sure, but I can see scenario where someone with mobile data plan opens up gif which is 30 MB large, eating the bandwidth significantly. Lowering the value there would also discourage posting massive gifs just because it's possible instead of using better alternatives or using sensible values. With images even 30 MB is rare to see so that wouldn't be huge bump to it.

I would go as low as 20 MB, but even 30 MB sounds much better.

Also would be nice to have large_filesize aliased to -> huge_filesize.

Here's another idea:
I have seen many times artists taking down their super HD PNG because they have issues with certain machines and browsers because of their size, but those are the versions that some are even willing to pay money for and sites general rule is to have best version up. Could huge_filesize actually be used in a sense that if someone actually posts that huge version, they could still keep it up and post another version, which is much smaller for those with huge_filesize possibly blacklisted? After all PNG and high resolution images with lots of variation are large.

Yeah, 50MB is probably too high, since that's only fourty posts. With that few, it's not too useful for blacklisting.

Does anyone object to lowering it to 30MB?