Not my usual polish, but I wanted to [very roughly] spruce up this doodle a bit by throwing on some color/effects to the scan.
(Just another doodle I made in the last several weeks of regularly getting to/from that facility I go to for groups. In case you wanted to see the other two sketch dumps, they’re just nameless characters: there’s this and there’s that.)
how do you keep your gifs under a MB? ive been having issues where my gifs have increased in size an insane amount even thought they are still 500x500 and 90 frames.
First, a few months ago, I started using 400x400 instead of my previous typical size of 480x480 (fitting into the 500x500 size bracket) because Tumblr had just started allowing GIFs to be 2MB at 400x400. Then, about a month after that, I heard that Tumblr started allowing 2MB @ 500x500, but I had already found that by scaling my animations down to 400x400, which trimmed an extra 70400(the extra 80 on each edge - it’s late, I don’t know if I math’d that right) pixels per frame, allowed me to turn my quality up a lot higher. But higher quality AND twice the file size? LIFE CHANGING. I went from being able to store between 16 to 36 frames of animation to 48 - 72, and that’s been really nice. 500x500 with 90 frames is probably not going to happen for you unless there are fewer than 300 total pixels of change going on per frame, and you have transparency enabled.
So, here are some fundamentals about the GIF algorithm.
First, one of the ways that GIF saves file size is by reducing the total number of colors saved in the images. Most modern day computer graphics are displayed in 24 bit color - that’s (8 bits/1 byte) to represent 256 levels of brightness for the Red, Green and Blue channels of a pixel. GIF says “You know, I can store a palette of colors which are 24 bit themselves, but I’ll only build an list of up to 256 of them, and then just refer to each of them with a single byte as its index.” So we go from 16.7m allowed colors in an image down to 256 of them - but we can pick exactly which colors we want those to be, based on image content. The more total pixels of the same color you have in an image, the more likely it is to make in into that palette. Let’s say the color palette builder spent 255 of your total colors by the time it was 50 pixels from the end of the image. Let’s say that those colors in the palette are all in the green to blue range. Then let’s say you have two shades of orange at the end of your image, and they’re really similar to each other. One of those shades covers 30 of the remaining pixels, and the other shade covers 20 of them. The orange which covers more pixels will be the one between the two that is fit into the palette, and the remaining colors will be “close enough” and replaced with the color of orange that covered more image area.
Next, GIF compresses with LZW, or run-length encoding, meaning that the more repetitive data you have you have in a row, eg; the more pixels of the same color you have in a row, the smaller the resulting file size will be.
It’s like: “Show color #5 for the next 50 pixels in a row. Next, show color #120 for 20 pixels.” Those 2 color change instructions covered 70 pixels worth of image space, and that file is going to be rather small.
If you have a lot more image detail going on, the instructions would be more like: “Show color #5 for one pixel. Next, show color #8 for one pixel. Okay, now color #20 for two pixels. Now a single pixel of color #5 again.” Those 4 color change instructions covered only 5 pixels of image space, and that file is going to be HUGE.
Try this experiment. Create a 256x256 image which has a black to white gradient from left to right. and save it as a GIF. Then create an image which is a black to white gradient from top to bottom and save that as a GIF too. The left to right gradient will be much larger because it be like: “White for 1 pixel! Next shade darker than white for one pixel! Next shade darker for one pixel!” and it will take 256 color change instructions to store a single row of pixels, and that’s 256 instructions on 256 rows. That’s not a small number. The top to bottom image on the other hand, will be like “Oh hey, a whole row of white 256 pixels. Let’s see, next row is a shade darker, and look, it’s 256 of those in a row too!” - So what would be stored in that image would be 256 color change instructions total, with one per row.
Next, if you’re using Blender’s Cycles as your render engine, the higher the number of samples you give your render, the smaller the file size is going to be. Why? Because noise. What you need to do is render your animations with a level of noise that’s low enough that the color differences between any two pixels next to each other are not different enough that they would get their own unique colors on the palette. Go ahead and set your samples up higher than you normally would, and let your animation render for 8 or 16 hours starting when you go to sleep, through when you go to school or work or whatever. Get back home at in the evening, and you have a super crispy animation ready to GIF an post.
It’s crucial to render to a lossless image format so you’re not getting weird DCT/JPEG/MPEG artifacts in your animations before you convert them to GIFs. I use these formats, for these reasons: AVI RAW(8bits per channel, smallest file size, fastest to load into other GIF exporting apps if image is perfect and needs no additional processing), PNG(16bits per channel, nice if you want to do some basic levels, curves or color correction on it after the fact), or Open EXR[not multi-layer](32bits per channel, fantastic for post-processing in both Blender and After Effects); When in doubt, use Open EXR, because while those files are a bit larger - the time you spent waiting for the render is more precious than the extra bits you spent to store the file, and you can’t go back and get the extra render data that would normally be in the EXR after the fact if you’ve already saved it as an AVI or PNG.
Protip: If you have an animation that’s on a white or black background, adjust your levels so that some of the unnecessary noise at the top and bottom if your histogram is clipped to pure white or pure black, producing more pixels in a row of the same color. This works best with 16 or 32 bit images because there is more intermediate data between the clipping points to stretch out, and you’ll get less banding in the final image. I used that trick just recently in the “Insomnia Attacks Again” design.
Last tip, and then I go bed. Photoshop has a “Lossy” setting in its GIF export dialog. Using lossy is like getting the color palette picker drunk. “[hic] Eh, this sequence of colors is (orange, orange, yellow-orange, orange, red-orange, orange), but it all looks orange to me! Orange for 6 pixels in a row![spills drink on bartender]”. The more lossy you have, the more drunk the color picker. The less lossy, the more discerning the color picker. DO NOT CROSS LOSSY WITH TRANSPARENCY. NOT EVEN A LITTLE BIT. Try it out, and you’ll see why. It looks like someone covered a pair of Crocks with Glitter. Double bad taste.