Topic: Online Slideshow Viewer

Posted under e621 Tools and Applications

Tarrgon

Janitor

This website allows you to create a slideshow from e621 images. It has a few powerful features that you can use to finetune what you want to see.

You can find it at https://yiff.today. The layout may look familiar, since I'm not a good designer, I lifted the overall frontend design from a now unmaintained general booru slideshow viewer. Which I had been maintaining for about 3-4 years now.

yiff.today is specific to e621, and will only work with e6.

Features

  • Auto playing slideshow
    • Timing control
    • Ability to set videos to play fully
    • Ability to have gifs/low duration videos to loop a specific number of times
  • Autofits to screen size (not tested on mobile, I use a 1080p monitor)
    • You can however set a max width and max height if you don't wish to use autofill
  • Client side filtering
    • Including all ratings
    • Media types including images, gifs, and videos
    • Whether to show images you've already seen before in previous sessions
    • Powerful client side tag system to evaluate tags that you can't normally do with e6.
      • The main power house being proper tag grouping using (), ex: ( male ~ female ) ( ambiguous_gender ~ gynomorph ), this means (male or female) AND (ambiguous_gender or gynomorph), think of it like PEMDAS, except more fun
        • At the moment only one level of group is supported, meaning you can't use groups inside of other groups, ex ( male ( female ~ ambiguous_gender ) ) won't work as expected.
      • Negation using -, ex: -female
      • Wildcard using *, ex: *male
      • Fuzzy using ~, ex:exam~
      • Local tags have no restriction on length, but more complex structure will mean it takes longer to filter and find slides. The system to fetch the slides from e6 uses a decay system, the hard rate limit on e6 requests is 2/s, however they prefer 1/s, so we start at 2/s to try and find posts as fast as possible, but it decays down to 1/s quickly. If your local tags aren't complex, and your seen list isn't skipping a bunch of images, this shouldn't matter at all to you.
  • Ability to supply a username/api key which are saved locally to gain access to images you can't see without an account
    • Eventually an option to favorite remotely will be added as well
  • Controls are pretty well optimized for one hand, if that matters to you...

CUSTOM SEARCH FORMAT

Over the last week or so, I've been developing a custom search format for e621. It's in a workable state now, and was implemented into this site.

See: https://e621.net/forum_topics/40732

This site does not use the default e621 search format. Requests to this site don't even go to e621 anymore.

New Search Syntax:

Search Syntax
a means -> a -a means -> not a a ~ b means -> a OR b a -b means > a, not b ( a b c) ~ ( d e f ) means -> (a & b & c) OR (d & e & f) a b ( c d ) means -> a & b & c & d (nothing special) -a b c means -> not a, b & c a b -( c d ) means -> a & b, not (c & d) (meaning it can have either c or d, but not both) a ~ b c means -> (a OR b) & c a ~ b ~ c d means -> (a OR b OR c) & d a ~ b ~ ( d e ) means -> (a OR b OR (d and e)) (either a or b or the post has both d and e) a ~ b ( -c ~ -e ) means -> (a OR b & (not c OR not e)) (meaning a or b AND the post doesn't have c or the post doesn't have e) ( -a ~ b ) means -> (not a) OR b a ( b ( c ) ) means -> a & b & c a ( b ~ ( c e ) ) means -> a & (b OR (c and e))

Notes:

  • * is the wildcard character
    • Wildcards can dramatically increase the search complexity as each tag which matches it is added to the search in an "OR" fashion. i.e. *male is like ( male ~ female ~ ... )
    • The database I'm using has a maximum complexity of 4096, which I increases from 1024. This doesn't really mean anything for most people as they probably wouldn't hit it anyways
  • Tag grouping parentheses (( )) must be preceded and succeeded by a space (unless it's the first character) (a b) is treated as (a and b), which are tags that don't exist. The proper format would be ( a b )
    • Same goes for ~ | (a ~ b)
    • -, however should be directly before the tag or open parenthesis | -a
  • More complex searches will take longer to resolve

Plans

  • Slideshow of favorites only
    • I'm debating on whether to use e621 favorites or a custom server-side favorite system. There is placeholder stuff hidden for a server-sided favoriting system, however I wanted to get the base slideshow viewer out beforehand.
    • The reason I want to use server-sided favorites is because it means I can save the tags and therefore bypass rate limits to check tags. And at 1 req/s, checking tags of your favorites could take a really long time.
  • Optimizations
    • Loading faster is always better
  • Tag autofilling
    • It's possible, so why not
  • Or groups for local tags
    • Meaning you can do ( tag1 tag2 ) ( tag3 tag4 ) ~ ( tag5 tag6 ) ~ ... since at the moment all groups must be passed and that may not be what you want. This would mean the first group must pass and any of the other groups

Source

If you want to make fun of me, or just run it yourself: https://github.com/DontTalkToMeThx/yiff.today

Any feedback is welcome!

  • The local tags are an implementation I made a while ago, and while they work for what I do, I haven't tested every combination and nuance. If you find any issues with it, let me know!

Why yiff.today? It cost me the least to buy.

Updated

  • 1