That'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.
It 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. >>7519
The 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.
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.
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.
Very informational Anon, thanks!
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
When you're ready to use it, it can be found under Filters -> Will's Script Pack -> Animation Merge>>7526
I'm still not done!
The 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.
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
Some thoughts if its a potential banner: the entrance and exit timings look kind of off... not sure what though.
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.
Well, 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
What's the size standard now?
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.
Huh, isn't that already covered by global rules? (no advertising without permission)
the banners are kind of under a system of common sense...
Tried 50000 scaling, had to force reboot my PC :/
Is 50000 just an arbitrary number? Or did you get it via some formula or something?
It'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.
Text is good, don't think kissu is necessary.
>>7564>GIMP will try and warn you
I tried it with ImageMagick's convert.exe. Will that not work?
I'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.
It should, I'm just familiar with GIMP.
I just realized I can click the small banners to change them
Also why aren't they their full size on the new UI?
So many cute gif banners, hard to think of how to compete with static images.
Static images are good, too much movement is distracting.
Animations tend to skimp on details. Not necessarily a truth but a rule of thumb
pngquant for the png banners. I dont know about gifs but surely there's a similar tool
Maybe make a banner size limit rule or something. Best the creator optimized their creations themselves, I think.
It'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.
Not necessarily for Linux, but I use:https://nikkhokkho.sourceforge.io/static.php?page=FileOptimizer
The 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.
I put the idea of board specific banners into my backlog since it's been asked
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
anyone use comic sans yet?
just now saw it
and a stock image of a scroll
font is aihara hudemoji kaisho
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.
This will likely mean that the URLs won't connect to the assigned locations anymore, but I'll see about making them available.
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.
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...
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)
I made a banner just now.
that one should be a wide