No.7514[Last50 Posts]
Project thread for the banners.kissu.moe system
Source code:
https://github.com/ECHibiki/Community-Banners-2.0Feedback on banners:
https://feedback.kissu.moe/public/forms/Banners_Feedback/10Original Text
We should make banners or something, or rather someone other than that one guy that makes 90% of them. Do you have any ideas? We should think of new stuff to add to the clickable longer banners, too.
Or maybe if you're lazy you can come up with ideas and other people can make them.
Well? No.7517
>>7515That's part of the fun making banners. Sometimes it works, other times it doesn't, but typically you can adjust whatever you're trying to make into a banner by taking the height or width axis, dividing by the corresponding height and width of what the final size of your banner should be and then multiplying either your height or width by that number. Depending on the source, that'll usually leave whitespace on either side so you'll have to be creative on how to deal with that.
Otherwise, the more simple method is to just crop and frame to the scaled dimensions of either banner size. So, if your source is 1920 x 1080, for instance, you would do a crop of either 1920 x 346 or 1920 x 896. Small banners will always be easier to make because by their very nature, their aspect ratio is much closer to 16:9 than wide banners are.
Pic related is an example of what I mean. The dimensions of the source GIF is 600 x 337. So, to make a small banner we would divide the width by 300, which gives us 2. Multiplying that by the height of what a small banner should be gives us 280. Therefore, if we we're going to crop our image to the dimensions of a small banner, our image would be 600 x 280. Obviously, we then need to scale our image down, so just scale it to 300 x 140. Before scaling, remember to set the image mode to RGB instead of leaving it on "indexed". This is so that there's no color artifacts when downscaling. In general, for GIMP, I would recommend using the NoHalo scaling algorithm.
Bear in mind, however, that scaling will not always be as clear as the example I gave. It was unique because the scaling was by an integer multiple, meaning the clarity of the downscale will be close to the source, but this will not always be the case. If you're paranoid about quality preservation, I would recommend scaling to very large dimensions by multiplying the dimensions by an integer number and using "None" as the scaling algorithm. Then, scale to the final dimensions using NoHalo. This will result in minimal quality loss, but will be very memory intensive depending on the number of frames.
No.7521
>>7518It might be difficult to tell any meaningful difference in quality between them, but this also gives perspective into what details a viewer will notice and what they won't.
The stars look virtually identical in all examples. This is because human vision isn't particularly suited to picking up details on objects in motion. If you look at Tenshi, however, the results are much more striking; going from worst to best, the image gets progressively clearer.
What this means practically is that if you're scaling something that's high detail and static, you may want to preserve those details by upscaling it first and then downscaling. If you have a lot of motion, however, then it may be fine to instantly downscale.
>>7519The reason this works is down to the scaling algorithm. In effect, it's doing some of nearest neighbor scaling to determine what pixels should end up where. A smaller distance between pixels will result in more blurring because that's the nature of nearest neighbor scaling. So, if you have a black pixel next to a blue one, you'll get a blue-black blur. If there's a greater distance between pixels due to upscaling, the nearest neighbor is much more likely to be the "pixel" itself.
To give an analogy as to why there's greater quality preservation, if you've played video games, you might have noticed that some games can look cleaner with anti-aliasing off than on. Same thing. A more direct comparison would super-sampling resolution, as this effectively does the same thing as an anti-aliasing algorithm but at next to no quality loss because more pixels are being rendered to fill the gaps rather than blurring jagged edges.
No.7523
I almost forgot to mention, if you're doing any scaling at all, it's very important to unoptimize the GIF!
Most GIFs will be optimized by default to reduce filesize, however, they achieve this by introducing transparency. For example, If frame 1 is just a single red pixel, and so is frame 2, frame 2 can be made transparent, but if frame 3 is a blue pixel, then obviously frame 3 will contain that blue pixel. GIFs effectively do this across every single pixel of the image between frames. When you're scaling, however, the edges of pixels can become blurred. But! Because your frame will have transparency instead of being the whole image, you'll get blurred edges into nowhere. Moreover, GIFs also crop individual frames to reduce filesize, but when scaling, these cropped frames can get nudged, resulting in the animation appearing "wobbly".
For some GIFs, not unoptimizing may not be a problem at all, whereas other times it can result in very ugly artifacts. Again, this comes down to the manner of optimization: if there's a lot of motion, there may not be anywhere that the can be optimized, and thus every frame would be set to "replace" rather than "combine" (this is the setting where transparency is involved).
This is also very important for a specific plugin I'll mention that will greatly increase the speed at which you can make GIFs if you decide to work mostly in GIMP rather than using a video editing program, be it out of necessity, such as making pixel art edits, or out of comfort.
No.7524
Furthermore, whenever you're working with GIFs, you should make sure that you have the color mode set to "RGB" and not "Indexed".
This is another one of the ways that GIFs reduce their filesize. By design, GIFs use a reduced color palette of at most 256 unique colors. So, for instance, if you have a GIF that's black and white, if you tried drawing something that's green on it, your green will suddenly be converted to gray! The reason for this is the aforementioned indexed color palette: because green wasn't one of the colors included in the indexed color palette, it'll instead show up as gray. But, when you change the color mode to RGB, however, you'll be able use that green to your heart's content.
As you might imagine, this indexed color palette stuff can cause issues with scaling as well. Assume you're scaling something and forget to change from indexed to RGB, what would happen? Well, when the scaling algorithm tries to blur two pixels together akin to anti-aliasing, if the resulting color isn't in the color palette, you'll get a color artifact. Sometimes this colored pixel won't stand out, but other times it can be quite apparent.
No.7526
>>7518>>7521>>7523>>7524>>7525Very informational Anon, thanks!
No.7528
When making animations in GIMP, you'll often want to combine two separate pieces of animation, or maybe you want to add a background to something. To do this, you can use a script called animation merge!
To install this script, simply extract the ZIP and drop sf-will-animerge_0.scm into C:\Program Files\GIMP 2\share\gimp\2.0\scrip
ts\
When you're ready to use it, it can be found under Filters -> Will's Script Pack -> Animation Merge
>>7526I'm still not done!
No.7531
>>7528The principle usage of the Animation Merge script is pretty simply to understand. Instead of spending an hour duplicating a background and merging down the top layer into the background for every frame, you would simply have your background open in one tab in GIMP, and your animation in another.
When you use the Animation Merge script a window will appear. Fairly obviously, select the file that you want to be bottom image as the bottom image and the one to be the top as the top image. In the image example, the Kissu background is the bottom image and Maribel spinning around is the top image.
As for the other settings:
Merge Type: this does not do anything. Just leave it on normal.
Boundary behavior: "Expand as needed" will cause the resulting image to be as large as the largest frame. In other words, you can merge a smaller image with a larger one. "Crop to bottom layer" will make the resulting image only as big as the bottom later. In general, I'd say just leave it on "Expand as needed".
This next one is important!!Number of frames: "LCM of frames" will create an animation using the least common multiple of frames between the two images. So, if you have one animation and one background, it will apply the background to every frame and the resulting image will have as many frames as the animation because the least common multiple between 1 and X is X. If you have two animations, however, it will merge them so that there is a perfect loop between the two, so that if you don't have the same number of frames, that one does not end early. In effect, it means that it will create an animation that has the least common multiple number of frames as between X and Y; for instance, if one image has 4 frames and the other 5, the resulting image will have 20 frames. If one has 9 and the other 36, the resulting image will have 36.
In the VAST majority of cases, you should always use "LCM of frames" over "Min of frames". Using "Min of frames" will result in an image that will contain the same number of frames as whichever image has less, but this also means that one animation may not not loop. The previous example of creating a background will also not work, since the background image only has one frame, meaning the resulting image would only be a single frame instead of X number of frames.
You can technically use the provide X and Y offsets, but I would recommend against it. In general, when making animations that require positioning, it's much better to either link layers together and move them manually, or use the "Canvas Size" tool and adjust the position of the image that way. For example, in every example image I've created, I used the Canvas Size tool to adjust the image to its position and then used the Animation Merge tool to combine the animations together into a single image.
No.7532
Finally (I think?), GIFs can get large, so once you've made your masterpiece, you should probably optimize it so that it takes up less space. You can use the default GIF optimizer in GIMP, but it might not always reduce the filesize that much.
Because of this, I would recommend that you use:
https://nikkhokkho.sourceforge.io/static.php?page=FileOptimizer No.7533
>>7531Some thoughts if its a potential banner: the entrance and exit timings look kind of off... not sure what though.
No.7539
Got some ideas but I always keep procrastinating. Maybe I'll maybe good use of the info posted ITT and finally get around to them.
No.7542
>>7541Well, the size would be the obvious thing. The 'random banner size' thing that kissu had went away a while back. Looks good, though, just needs resizing
No.7543
>>7542What's the size standard now?
No.7544
500x90
300x140
No.7547
I reopened account creation for banners.kissu.moe
To go with this I've set the rules for the wide banners as such to account for the possibility of annoying people lurking to create junk that I don't think reflect current Kissu.
Must be 500x90
Rules: SFW, Does not promote other social platforms
This is a general guideline that specifies that some banners that link to other imageboards, textboards or what I consider to be spam sites can be expected to be removed.
No.7561
>>7547Huh, isn't that already covered by global rules? (no advertising without permission)
No.7562
>>7561the banners are kind of under a system of common sense...
No.7563
>>7518Tried 50000 scaling, had to force reboot my PC :/
Is 50000 just an arbitrary number? Or did you get it via some formula or something?
No.7564
>>7563It's arbitrary. Normally GIMP will try and warn you and say something along the lines of "Are you sure you want to do this? Creating this image will require 50GB" or something like that. Bear in mind, when it says it'll need that much storage, it's talking about
system memory, not hard drive space.
No.7572
>>7571Text is good, don't think kissu is necessary.
No.7573
>>7564>GIMP will try and warn youI tried it with ImageMagick's convert.exe. Will that not work?
No.7574
>>7572I'll submit it this way, then. Truth be told, I only felt like I should add it somewhere to make it less low-effort... I'll try to take it less easy for my next banner.
No.7575
>>7573It should, I'm just familiar with GIMP.
No.7585
I just realized I can click the small banners to change them
Also why aren't they their full size on the new UI?
No.7621
So many cute gif banners, hard to think of how to compete with static images.
No.7622
>>7621Static images are good, too much movement is distracting.
No.7623
>>7621Animations tend to skimp on details. Not necessarily a truth but a rule of thumb
No.7676
pngquant for the png banners. I dont know about gifs but surely there's a similar tool
No.7677
Maybe make a banner size limit rule or something. Best the creator optimized their creations themselves, I think.
No.7678
>>7677It's a good idea because I didn't have one in the first place and set it to 2MB for now, but ideally the limit should be based around the maximum value of current creations after optimization, not based around unoptimized creations
So basically I need to optimize what people have not already optimized to figure out what the max filesize I want to allow is. Biggest issue is .gif, but .png should also be checked I guess.
No.7683
>>7674Not necessarily for Linux, but I use:
https://nikkhokkho.sourceforge.io/static.php?page=FileOptimizerThe only way to really conserve on space for GIFs, outside of typical lossless optimization relies on decreasing quality by reducing the palette, and applying more aggressive dithering. Needless to say, I don't think people would entirely take too kindly to their banners becoming lower quality for the sake of optimization.
No.7695
I put the idea of board specific banners into my backlog since it's been asked
No.7876
Do you guys have any good fonts you've downloaded that you want to share? I have trouble finding fonts that look soft and less "business-like" like the old standards.
I just used Chocolate Cookies for a banner as an example of a font I like:
https://www.dafont.com/chocolate-cookies.font No.7877
anyone use comic sans yet?
No.7974
>>7923just now saw it
very nice!
No.8924
>>8923the heart
and a stock image of a scroll
font is aihara hudemoji kaisho
No.9246
Giving people a heads up that in 24 hours(or however long it take me to get the site to work if it's disabled) I'm going to be turning off the banner application until I remake it without Laravel. Could be offline for a month, most likely before the next season.
No.9247
This will likely mean that the URLs won't connect to the assigned locations anymore, but I'll see about making them available.
No.9264
While I'm remaking the submission application in Golang,
I'll add board specific banners as a compensation to anyone who is annoyed(who?) that it's down.
No.9278
Banner port from PHP-Laravel into Golang-Gin is going smoothly.
https://github.com/ECHibiki/Community-Banners-2.0/I honestly wonder why Laravel(or frankly Symphony or any other PHP framework) even exists when you get more performance and easier development time out of other language alternatives. The only thing I sort of miss is how easy it was to write unit tests...
No.9306
Banners should be active again roughly tomorrow sometime.
Downtime and change from laravel to golang was in order to deal with security issues.
In the meantime I added two themes(dark and light mode) which make it easier on the eyes and less generic.
Changing some of the text around
Feature for people with donation tokens allowing them to set banners for specific boards(thereby allowing them to potentially add NSFW banners)
No.9629
I made a banner just now.
No.9631
>>9629that one should be a wide
No.9931
>>9930A /jp/ -vs- /qa/ edit for this might make a nice banner.
No.9959
>>9958i quite like this idea, hmmm
No.10072
>>10071I think this one might be too big
No.10073
>>10072What resolution do you need?
No.10075
>>10073Oh, sorry. I was making a joke about the "hires" one being too big because it's 1200x560
No.10311
>>10157Akshually, the sokuon only represents a glottal stop when used at the end of a word, after a vowel. Its more common form is that of a geminate archiphoneme. Either way, キッス works, there's plenty of gairago that geminates just because the English word is written with two consonants.
No.11362
what's the reasoning behind being unable to attach links to small banners?
No.11363
>>11362because they're public site logos and clicking on those is to cycle through them
No.11396
Maybe the one "Goodbye Kakashi-Nenpo" banner should point to the new nen link at
https://www.kakashinenpo.com/ No.11398
someone can do it if they want then i'll remove the one that's under my name
No.11403
>>11396I prefer keeping them as is and treating them like historical monuments like
>>10812 said.
No.11414
https://archive.is/2eglbif anyone wants to collect archive.is or archive.org links of whatever is 404 then please do. Also tell me what banners they connect with beforehand
No.11420
>>11397The very first banner was literally a link to /what/, wasn't it? And the whole thing was/is slated as community advertisement, right?
No.11660
>>11658I'll see about changing this starting in about 3hr
No.11661
>>7695>>9264>>9306>>9930I wonder who's been making hay about board-specific banners when I'm the only one who's ever used the feature.
No.11662
>>11661It was asked a few times over a long enough time, but not really used. Probably because I paywalled it for a bit but no one made a fuss either way.
No.11663
Board list updated
No.11664
>>11663yes hello i'd like to report a bug is this hotline open
No.11666
Not quite related to making banners, but I'm curious about how banners are displayed to the user; as in, is it purely random, or is there some method to the madness? Because I swear I see some banners way more often than others.
No.11667
>>11665ah well you see sir i'm over here trying to create a benner, yes? the one i made before
but i have run into a weird issue that stops me from creating it
In short, /megu/ and /secret/ aren't functional as options. Trying to make a banner for them gives the following message:
>The given board is invalidOn the other hand, /trans/, /test/, /win/, Kissu, and /ec/ all work. I used the exact same file every time.
No.11668
uh hm... odd...
No.11669
Hell, I went ahead and tested all the other boards as well, I can confirm that only /megu/ and /secret/ give the above error. Dunno y.
No.11670
>>11669because i forgot to set the board in the json config file
works now
No.11673
it's appearance chance is kind of low. That might be another bug
No.11674
mm, nvm I get it a bit. Maybe I want to tune it so that specific banners are chosen more often... I'll consider this as a future plan since I might end up rewritting hazuki.kissu.moe into Rust anyways
No.11839
I have a question to people: Has any particular Elle image anyone has posted jumped out to you as kissu banner material? (She has a thread on /ec/
>>>/ec/10984 ) You might have a good screenshot, too?
Her little floating hammock thing has potential because I could do a curved font around it and it's her unique form of transportation, but her cutest faces are outside of it.
There's also something like pic related where I could edit the book to say 'KISSU'.
Hmm... decisions, decisions...
No.11840
>>11839>>>/ec/13100 has a nice uhhh composition but it's got rainbow colors so I dunno
maybe it'll be best to wait until the show ends
No.11841
I'll make a banner when inspiration strikes, you don't need to do a big vote or whatever.
No.12181
>>12180Awesome, thank you.
It basically means eternity, 永久 inverted, but it also sounds like /qa/ and that's funny.