Index Cleaning Scans Typesetting Saving Files Advanced Stuff

3. Saving Files

3.1) Black & White
 Some people simply use .jpg for everything (a declining phenomenon). However, for black and white images typical of manga scans, .png is superior in terms of getting a smaller filesize without losing image quality. Always use Save for Web, and it's probably a good idea to create presets for b&w as well as color pages. Black & white should be png8, adaptive, diffusion, NO transparency (box should be unchecked), NO interlaced, 17 colors, 100% dither, no matte, no web snap. The 17 color tradition, though flawed in its original reasoning (ookla's legacy, lol), works pretty well for most pages. Generally 15-20 is what you want for most pages, and theoretically there should be a stepwise drop in filesize from 17 to 16 colors beyond pure palette reduction, but in practice this difference is negligible (with 16 colors and appropriate processing, you can go down to a 4bit png instead of an 8bit, but there smaller filesize with 16 colors is almost completely due to the loss of the extra color, as opposed to going from 8 to 4bits). Feel free to use fewer or more colors as needed, or use other color reduction algorithms. Keep in mind, however, that if you use pngrewrite, the image will be converted to the minimum bitrate needed for the number of colors. If you do adjust the number of colors from page to page, try to keep them within the same bitrate bracket.

I want to stress leaving images uninterlaced. Interlacing png's produces "jaggies" in some image viewers, and more universally, is wasteful. It's designed to let you preview large images over the internet by loading them piece by piece (as staggered horizontal strips), which isn't an issue unless you're one of those wysiwyg sites (even then, manga pages are small enough to not need it, and viewers know what they're getting, so there's no need to preview). However, this added functionality comes at a cost, and has a larger filesize than an uninterlaced png.

3.2) Color
 Color pages should be saved as jpeg, very high, NO progressive, NO ICC profile, Yes optimized, 80 quality, 0 blur, no matte. While jpg is a lossy format, using png (a lossless format) for images with a larger palette results in much larger filesizes. Unless the color page is meant to serve as standalone art (poster/artbook scan or whatnot, sometimes even then), the disadvantages of jpg compression are negligible. Of course, as with the b&w recommendation, feel free to adjust the settings as needed by the individual page, but this is a pretty good starting point. A progressive jpg is the equivalent of an interlaced png, only previews by resolution rather than staggered strips; as with interlacing, it generally requires a larger filesize, and isn't all that useful for manga purposes.


Settings for Save For Web for black & white images as well as for color pages. There are reasons for these settings, and are mentioned in other guides, but really aren't all that important. Slight modifications to these settings may improve filesize somewhat, but it's generally not that big a deal.

3.3) Packaging
 Packaging your final images together is fairly easy. After your png's and jpg's are saved, use a program like pngcrush or optipng to further reduce png filesize (I personally use a combination of advdef, pngcrush, and pngrewrite).

Bundle your images in a .zip (don't use .rar, or cbr/cbz); zip is faster (more noticeable if you've worked with archives of several thousand files; if you don't believe me, make a zip of 10,000+ images and the equivalent rar, and time how long it takes to go from double click to viewing contents), indexes better (try extracting a few things from the middle of a huge zip, and compare it to extracting from the middle of a huge rar), and the size is comparable to rar since images don't compress much anyway. The superior corruption recovery of rar is lost on manga too, since usually every page counts, and it's not that much trouble to just redownload the whole thing. Plus, acdsee likes zips more than rars (for all you cdisplay fans, while cdisplay doesn't have this issue, cdisplay's UI is clumsy at best, and the way acdsee precaches images is much better). Cdisplay has advantages over acdsee as well, being free and more streamlined (you can streamline acdsee as well, but it takes a bit of setup), so I won't try and make anyone convert, but from a scanslator's perspective, be aware that some people prefer acdsee, and just use zip.

Make sure that pages are sequentially numbered and account for 2pg spreads, and that any color pages, covers, and credits are appropriately named to be at the beginning or end of the archive when viewed alphabetically (not just by file type). Make sure the page numbers have the same number of digits (use leading 0's), since people with older OS's (Win2k or older) will read things by the first digit (and thus 1,10,11,...,19,2,20, rather than 1,2,...20). Avoid image names of simply ##.png or ##.zip (be more descriptive) Name your .zip as specified by the group (typically a variation of "manga_name_v##_c###_[groupname].zip"). Ideally group names should be at the end, not at the beginning, that way things stay in order even if another group takes over the project in the future (you don't want [BBB]_blah_v01_c01 to come after [AAA]_blah_v01_c02).

If you're numbering by the volume, and page numbers are visible on the raws, make sure those numbers match up with the numbers in the filename. If you're using magazine raws, or numbering by chapter, this obviously isn't a concern, though I would recommend, when using tankoubon raws, to number by volume and not chapter.

Be consistent with your filenames and archiving. If you've been putting images directly into the zip, keep doing so. If you've been putting the images in a folder in the zip, that's fine too, but just be consistent. And for the love of god, make sure you get rid of the thumbs.db file.

Hopefully your group has some QC phase, or at the very least let someone else take a look at your work before things are released. As an editor, I usually find it helpful to have the translator of the chapter as one of the QCers, so if any of my rewordings butchered the original meaning, it can be caught and corrected. I've added a link to my QC guide here.

3.4) Other Points
 If at all possible, avoid splattering watermarks everywhere. No one likes having their scans stolen, but personally I would rather that than compromise quality by watermarking pages. This isn't to say you shouldn't put credits in, but put them separate (as most groups dictate) or in the margins, try not to obscure art with it unless instructed to do so (some people are more willing to sacrifice art to make their scans unstealable).

Another issue of debate is releasing 2nd versions (or more) of the same chapter. Personally I feel that if there is a large enough raw quality difference, it may be worth the time to release an improved version (e.g. tankoubon scans vs. magazine scans, though with a little work, magazine scans can be made practically indistinguishable from tankoubon scans). For things like typos, just don't make these mistakes and you won't have to worry about "what if". Mistakes do happen of course, though a minor typo can usually be forgiven (big things may call for a ver2, but just take into consideration how big a mistake it was).

Regarding fan color pages, first of all, manga pages not already colored are meant to be black & white. Replacing screentones with colors is one thing, but in the end, it almost always looks like a kid with a coloring book (the thicknesses of the lineart, having hard 'borders' rather than soft, etc). Secondly, it's fanart. You're releasing manga scanslations so people can enjoy the manga, not see how good a colorist someone is. I've seen some good fan colors out there, some really impressive stuff, but whether or not it belongs in the release is a separate issue. Especially when you start putting multiple versions of the same page, it really starts to take away from the release. And of course, 90+% of the fan colors out there suck. Just leave them out of the release; put them on your group website, or a forum, or something. Link it in the credits page if you want, but just leave them out of the zip.

Speaking of credits pages, you only need one. You don't need a group credits, a distro disclaimer, AND a project credits.

One last thing; for somewhat valid reasons, some "groups" insist on labeling their releases as lq/mq/hq, especially on a certain forum site. However, while the forum site may ask members to label their releases, it just seems amateurish. Let your release speak for itself. The only valid exception I've come across is hawks/omanga releases, where they sometimes release chapters in high res tiff format. While this 'hq' version is unnecessary for most, cases like this actually warrant hq/lq tags. Otherwise, organize an actual group, stop relying on forums with a dozen redundant versions of the same chapter, and lose the tag.

Index Cleaning Scans Typesetting Saving Files Advanced Stuff