[ home / bans / all ] [ qa / jp / cry ] [ spg ] [ f / ec ] [ b / poll ] [ tv / bann ] [ toggle-new / tab ]

/b/ - Boson Technology

Also known as Boson /g/

New Reply

Options
Comment
File
Whitelist Token
Spoiler
Password (For file deletion.)
Markup tags exist for bold, itallics, header, spoiler etc. as listed in " [options] > View Formatting "


[Return] [Bottom] [Catalog]

File:Tsukuyomi -MOON PHASE- - C….jpg (47.98 KB,720x480)

 No.7514

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.7515

File:8cd0620c59.png (101.22 KB,671x418)

I had an idea, but I don't know how I'm going to make it work...

 No.7517

File:Screenshot 2021-07-01 0040….png (362.53 KB,1034x624)

>>7515
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.

 No.7518

File:Scaling.gif (242.55 KB,750x270)

Here's an example of what I mean by scaling quality using a banner I'm currently working on for reference.

 No.7519

File:[MoyaiSubs] Mewkledreamy -….jpg (299.09 KB,1920x1080)

>>7518
Wait, what the hell? How does giving it insane upscaling actually affect the final result? That doesn't make any sense, there's no new information

 No.7521

>>7518
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.

 No.7523

File:Fishy GIFs.gif (674.34 KB,700x404)

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

File:Colors.gif (905.85 KB,1075x1350)

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.7525

File:Scaling Larger.gif (952.25 KB,1120x1080)

>>7518
The details in this post might be a little difficult to see, so I've increased the size so you can better see the difference in quality between the different scaling methods. Bear in mind, that the size of each one was 500 x 90 prior to being upscaled to this size. Nothing was changed other than some minimal cropping.

 No.7526

>>7518
>>7521
>>7523
>>7524
>>7525
Very informational Anon, thanks!

 No.7528

File:sf-will-animerge_0.zip (2.15 KB)

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\scripts\

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!

 No.7531

File:Animation Merge.gif (1.72 MB,850x432)

>>7528
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.

 No.7532

File:Optimized.png (3.69 KB,709x54)

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

>>7531
Some thoughts if its a potential banner: the entrance and exit timings look kind of off... not sure what though.

 No.7536

File:Banner 38.gif (155.52 KB,300x140)

>>7533
You're right, I think. The actual banner itself has variable timings where as that example has the same timing for every frame.

 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.7541

File:Hazuki_Nyaa_Onee_a.gif (1.9 MB,550x240)

Created this one a year or so back, don't think it ever saw the light of /qa/ bannership... Or is it just bad?

 No.7542

>>7541
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

 No.7543

>>7542
What'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.7548

File:[SubsPlease] Higurashi no ….png (1.1 MB,1280x720)

Keiichi in his bed with his little feet and misshapen body has been shown at least three times now so I think it needs a banner, but it seems kind of bland on its own. Anyone have suggestions? (I figure 'kissu' can be written on his blanket, but it's still kind of bland)

 No.7561

>>7547
Huh, isn't that already covered by global rules? (no advertising without permission)

 No.7562

>>7561
the banners are kind of under a system of common sense...

 No.7563

>>7518
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?

 No.7564

>>7563
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.

 No.7571

File:Top o Nerae! Gunbuster - 0….jpg (46.22 KB,300x140)

Not sure if the text here is too small and if I should add "kissu" somewhere (and if yes, where.) Thoughts?

 No.7572

>>7571
Text is good, don't think kissu is necessary.

 No.7573

>>7564
>GIMP will try and warn you
I tried it with ImageMagick's convert.exe. Will that not work?

 No.7574

>>7572
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.

 No.7575

>>7573
It should, I'm just familiar with GIMP.

 No.7576

File:Hazuki_nyaa.gif (280.9 KB,300x140)

>>7541
Resized it, thankfully it went from 550x240 to 300x131 so I didn't have to mess around with it too much, or at all. How is it?

 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

>>7621
Static images are good, too much movement is distracting.

 No.7623

>>7621
Animations tend to skimp on details. Not necessarily a truth but a rule of thumb

 No.7624

File:banner6.png (75.98 KB,300x140)

made a couple years ago...

 No.7674

File:lJhCn4Z.png (198.3 KB,663x824)

Is there a good tool for me to optimize the banners that are >1MB

 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

>>7677
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.

 No.7683

>>7674
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.

 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.7923

>>7877
now there is

 No.7974

>>7923
just now saw it
very nice!

 No.8001

File:Pani_Poni_Dash!_-_04_[R2DV….jpg (74.01 KB,864x480)

That new Becky banner is very cool, thumbs up to the creator.

 No.8923

File:jZKMjImOxADAl0wdZNybdTZTdQ….png (89.46 KB,300x140)

what's the source of this banner?

 No.8924

>>8923
the 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.9566

File:[Serenae] Tropical-Rouge! ….jpg (179.46 KB,1280x720)

I think I'll make a Tropical Rouge Precure banner, but it's hard to decide on an image. I'm thinking of a 'girls looking at computer' one like this for the tall banner...

 No.9567

File:[Serenae] Tropical-Rouge! ….jpg (260.37 KB,1280x720)

>>9566
...and then maybe some link in the clickable banners to the OP or something. There's been a lack of new clickable banners since it's hard to find stuff to link. Like Mewkledreamy, the commercial break chibis are great material for this. I'm not sure...

 No.9629

I made a banner just now.

 No.9631

>>9629
that one should be a wide




[Return] [Top] [Catalog] [Post a Reply]
Delete Post [ ]

[ home / bans / all ] [ qa / jp / cry ] [ spg ] [ f / ec ] [ b / poll ] [ tv / bann ] [ toggle-new / tab ]